Groups 164 of 99+ julia-users › Questions regarding Julia for general purpose programming (strings, modules, dispatch, inheritance) 9 posts by 4 authors JColn Aug 23 Hello, I'm looking at Julia for general purpose programming and things look good so far. However, I want to see if I can elicit feedback from those that have ventured deeper into larger projects before moving further. Below are questions regarding areas of concern I've seen cited and I'm wondering if these issues are real. If anyone can provide experience I would be much obliged( My frame of reference is python). 1. Strings. Are they faster in 0.5 (python speed or better). How about ease of use? 2. Inheritance- Any issues with not being able to do concrete inheritance? 3. Module system and dispatch- Lots of Ink has been spilled on this, and I understand that organizing multi dispatch code is an open research question. However, it seems there are legitimate concerns about name clashes,ease of use etc I've also perused some open issues, but don't see a fundamental redesign. How does Julia fare for larger general projects compared to say python or java> 4. Multi dispatch. How do you find its utility for non numerical code? Thanks! Chris Rackauckas Aug 23 I don't necessarily have a large project, but there are a few tidbits I think I can share. I'm not familiar with all the things strings, so I'll let someone else take that. 2. You can always do composition instead of inheritance. For many it's a preferred coding practice anyways. In the end I find it leads to less breakage. 3. Instead of "using Module", you can just do "import Module" and the namespace will be cleaner, but you'll need to use Module.thing to reference them. If your package is mostly defining functions on your own types, then you don't need to worry about any clashes anyways (unless some package that you import has a type which is the same name, and defines a method with the same name and uses that same type). It's hard to know how Julia will fare for large projects since it's still young. For a good reference on organizing code really well using dispatch and metaprogramming, see Plots.jl's source. 4. Multiple dispatch isn't just a utility of code design, it's THE fundamental part of Julia which makes it look like a scripting language while being write strictly typed (hopefully type-stable) compiled functions every step of the way. You can think of it as a smart trick which makes what you're writing look like fluid Python, but in reality every time you call a function, it's actually calling a special-cased (and therefore well-optimized) compiled function for exactly the types you give it. Here's an analogy for multiple dispatch. Speaking to Python is like speaking to politicians: the words/syntax are nice and concise, but there's a lot of behind the scenes translations that are going on which makes it slower to "get to the point". You say "free-market", the politician hears "regulations" and after some discussion with advisers it can respond to you with what you want. Advantage: it gives you want you want with little effort. Disadvantage: it can be a slow process, and sometimes you don't know what exactly is going on behind the scenes (what is the interpreter actually doing when using a Float as an Int?). Speaking with Julia is like speaking with a professor at a coffee shop. You're talking and just say "yeah, take the derivative of that F to maximize u" which means "take the Frechet derivative of the functional to get the u which maximizes the ____ norm in the function space ____". Everything you are saying is shorthand which, when expanded, gets right to the point. Advantage: fast. Disadvantage: it will be slow and the conversation will meander if you don't actually know what the specific statement is supposed to mean (i.e. you don't write a type-unstable function). That turned out longer than I thought it would, but I think it gets the point across: multiple dispatch is always useful for getting you good clean performance if the functions you're writing are clean and type-stable (and if that's the case, you can get close to 1x with C). Whether you'll put in the effort to strictly type things and make the functions type-stable is up to you (in which case, Julia will still be expressive, but not the most performant). In the end, some mix where you prototype with less strict types but clean it up to end up with fast performant functions is a nice way to write code, and that's not an because of Julia: it's because of multiple dispatch (... so Julia is essentially taking a design philosophy based on multiple-dispatch on top of a compiler to an extreme. We've come full circle). - show quoted text - Adrian Salceanu Aug 24 Hi, A bit of context first. I'm working on building a full stack web framework in the tradition of Rails and Django (https://github.com/essenciary/Genie.jl). And not only that I use Julia for general purpose programming, I also come from a completely different background, doing almost exclusively web development for all my professional life (15 years now of Ruby, PHP, JS, etc). I'm building the framework from the outside in: developing a project and abstracting away common features into the framework. Here's the first project I deployed: http://genieframework.com/packages. It's been very stable, running for over 3 months now, no issues whatsoever. I'm now working on the second project, a blogging platform. Currently at about 5K lines of code, framework + implementation. It's not very big, but it's something. Now, to answer your questions: 1. I've had a good experience with Strings. Can't comment about 0.5 as I'm still on 0.4.6 but so far so good. The heaviest things I did with strings were part of a templating system, parsing HTML files, extracting markup, etc. Dealing with hundreds of lines of HTML or files of tens of KB like a hot knife through butter. Of course, depending on your use case, milage might vary. Some things that stroke me as weird-ish about Strings: a. ASCIIStrings vs UTF8Strings. Say you work with external generated content that you get from a DB (or web or whatever). Depending on the actual content of the string, Julia will generate an ASCIIString or a UTF8String. And they don't automatically convert between each other, so if you expect one type and get the other, you'll get an error. So I ended up using AbstractString everywhere the type of string I'll get was unknown (which was almost everywhere) - but using Abstract types is a performance no-no according to the docs. So if any of the experienced Julia users could recommended a way to deal with this, that'd be awesome! I kept pondering about this but could not find a definitive answer. b. indexing into UTF8 strings. Can bite if you're not careful, but Julia provides the necessary API to deal with this plus proper documentation. Just keep it in mind. 2. I did a bit of thinking on this one when implementing the ORM. You know, have your objects map to database tables, with one class per table and one instance per row, with properties mapped to table columns. So these types would be defined by the users of the framework, modeled according to their DB tables. And the framework provides a rich API for working with these objects and interacting with the underlying DB (all CRUD operations) without touching SQL. Traditionally, in Ruby or PHP, these models inherit from a base Model class and get all the needed behavior. In Julia I obtained the same effect by employing parametric methods. I have defined an AbstractModel and all the user models would extend it. And all the methods operate on {T<:AbstractModel}. Works great! 3. a common design pattern in web frameworks in the mainstream OOP languages is to map standard CRUD operations to certain controller methods (by convention). So you'll have index() for listing, show() for one item, create() for adding, update() for updating, etc. All these methods take the same single param, which provides them context (usually data related to the request). Another design pattern is that you'll have a controller for each business object - and each controller will have the mentioned methods for manipulating its data. You can probably see where I'm going with this: the need to have lots of methods with the same name and same param and having to invoke the right one. In standard OOP, you have a controller class for each business object and the methods are encapsulated (ClientController, UserController, ProductController). Then you invoke the one you need. I approached things in the same manner in Julia - but this was kind of bad. I was forced to create empty concrete controller types just to be able to use them as additional params, to allow me to invoke the correct method. That felt crappy so I refactored my code to use modules instead of types for defining the controllers and it works great! So the point is, sometimes (many times?) you can't port design patterns from another language using the exact implementation. In both cases above, ORM and Controller, you need to take the core idea and implement it the Julia way. Otherwise you'll just force yourself onto the language and the end result will be suboptimal. 4. I already touched this above - it's core, you can't live without it. And you should't try to. If you want to use Julia, that is core Julia and you need to embrace it as such. It takes a bit of getting used to, but once it clicks, it's natural. I'll close by touching on another aspect of Julia for general purpose programming. The community is great and all the Julia "seniors" are awesome, super-super helpful! I can't begin to explain how many times I reached for help and every single time I got the answer I needed. I want to thank everybody, again, for their time and their support. However, Julia, at this point, is by far and wide a language used for scientific computing. The vast majority of its users are doing this and only this. So until Julia becomes a mainstream language, be prepared for a lonely ride. From the perspective of web development for example, you can't expect the level of collaboration and enthusiasm that you'd get if you'd put your efforts into a language with a focus on web development, like say Elixir or JavaScript. But in order to get there eventually, somebody needs to start from scratch. And after looking very carefully at over 20 languages in the last 2 years, I truly believe Julia has the potential to be a game changer due to it being compiled, its speed, its parallel computing API, its simple syntax and least but not last its power in dealing with large amounts of data. Cheers! - show quoted text - Steven G. Johnson Aug 24 On Wednesday, August 24, 2016 at 5:18:05 AM UTC-4, Adrian Salceanu wrote: a. ASCIIStrings vs UTF8Strings. That distinction is going away in Julia 0.5; there is just one type, String. b. indexing into UTF8 strings. Can bite if you're not careful, but Julia provides the necessary API to deal with this plus proper documentation. Just keep it in mind. Yes, there is talk of making this less error prone; https://github.com/JuliaLang/julia/issues/9297 Adrian Salceanu Aug 24 > That distinction is going away in Julia 0.5; there is just one type, String. Yeee, that's great! I guess, with 0.5 RC3 now out, it's a good time to finally switch. - show quoted text - Adrian Salceanu Aug 24 Is the documentation available anywhere for 0.5? miercuri, 24 august 2016, 14:01:44 UTC+2, Steven G. Johnson a scris: - show quoted text - Steven G. Johnson Aug 24 On Wednesday, August 24, 2016 at 8:52:37 AM UTC-4, Adrian Salceanu wrote: Is the documentation available anywhere for 0.5? http://docs.julialang.org/en/latest/manual/ although this is technically the bleeding-edge git-master manual (but it is not too different from 0.5 at this point). Once 0.5 is out, http://docs.julialang.org/en/0.5/manual/ should have the stable manual. Adrian Salceanu Aug 24 That's what I thought too Steven, thanks for confirming it. Can't find any updates re `String` though, still talks about `AbstractString`... - show quoted text - Steven G. Johnson Aug 24 On Wednesday, August 24, 2016 at 9:56:29 AM UTC-4, Adrian Salceanu wrote: That's what I thought too Steven, thanks for confirming it. Can't find any updates re `String` though, still talks about `AbstractString`... Yeah, I just noticed that. Should be fixed now: https://github.com/JuliaLang/julia/pull/18216