[julia-users] Re: Questions regarding Julia for general purpose programming (strings, modules, dispatch, inheritance)

[Steven G. Johnson]

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 

[julia-users] Re: Questions regarding Julia for general purpose programming (strings, modules, dispatch, inheritance)

[Adrian Salceanu]

That's what I thought too Steven, thanks for confirming it. Can't find any 
updates re `String` though, still talks about `AbstractString`... 


miercuri, 24 august 2016, 15:29:56 UTC+2, Steven G. Johnson a scris:
>
>
>
> 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.
>

[julia-users] Re: Questions regarding Julia for general purpose programming (strings, modules, dispatch, inheritance)

[Steven G. Johnson]

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.

[julia-users] Re: Questions regarding Julia for general purpose programming (strings, modules, dispatch, inheritance)

[Adrian Salceanu]

Is the documentation available anywhere for 0.5? 

miercuri, 24 august 2016, 14:01:44 UTC+2, Steven G. Johnson a scris:
>
>
>
> 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
>

[julia-users] Re: Questions regarding Julia for general purpose programming (strings, modules, dispatch, inheritance)

[Adrian Salceanu]

> 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. 

miercuri, 24 august 2016, 14:01:44 UTC+2, Steven G. Johnson a scris:
>
>
>
> 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
>

[julia-users] Re: Questions regarding Julia for general purpose programming (strings, modules, dispatch, inheritance)

[Steven G. Johnson]

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

[julia-users] Re: Questions regarding Julia for general purpose programming (strings, modules, dispatch, inheritance)

[Adrian Salceanu]

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 

[julia-users] Re: Questions regarding Julia for general purpose programming (strings, modules, dispatch, inheritance)

[Chris Rackauckas]

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).

On Tuesday, August 23, 2016 at 5:39:26 AM UTC-7, JColn wrote:
>
> 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!
>
>
>