Julia and Python languages

[Pedro Rafael]

Gentlemen, how's it going?

Worth learning Python or Julia replaces python for scientific computing? I see many people encouraging the use of Python for scientific computing.

[Ivar Nesje]

As a general statement I would never recommend someone to not learn a language. Currently Python has a strong position in some areas of the scientific community, and loits of libraries and tools are available. Python also have a history so that old projects and coders are more likely to use it.

Julia is a young language with new ways of expressing problems that we keep on refining. In my opinion, the most important features in Julia is multiple dispatch and a very nice type system. Method overloading makes it easy to express generic algorithms. If a Julia program performs badly, it is usually fairly easy to code around some known rough edges and achieve runtime speeds about 2 times of a similar program written in C.

[Erik Engheim]

Given that Julia is not even in version 1 and has a lot less libraries than Python I don't think Julia is a serious contender in Scientific Computing today. But I am pretty sure it will be. But that wont happen over night.

I love programming Julia. It is great for doing hobby stuff and just have fun programming. There is a lot of opportunity to actually participate and make serious additions to the language or libraries because so many things don't exist yet or have not yet become finnished.

To me Julia is at the moment the language that maps best to how I like to think about programming problems. It has macros like LISP, but sane syntax for doing math. I wrote a blog entry about some of these points and on why I think Julia is more expressive and creates more readable code than Python or Ruby here.

[John Myles White]

Really nice post, Erik. Thanks for writing it!

 -- John

[Jacob Quinn]

I agree. Great post! It's great to hear other people's experiences coming from different languages/programming styles.

-Jacob

[Ivar Nesje]

Great post, it sums up very well the things I think is the strengths of Julia.

A few notes:

Julia does not look up the method at runtime if the types of the arguments to the function can be deduced from the types of the arguments to the surrounding function (but it behaves that way for the user, unless he redefines the method after the function was compiled #265).

Julia has 3 ways of grouping types with behaviours.

1. Abstract types (very lightweight inheritance)
2. Type unions (as you explain them)
3. Branching some compile time known property (eg the return of eltype(obj)).

[Erik Engheim]

Thanks for the nice comments all of you. I guess I have to keep writing more about my Julia experiences after this ;-)

On Tuesday, January 7, 2014 9:39:05 PM UTC+1, Ivar Nesje wrote:

Great post, it sums up very well the things I think is the strengths of Julia.

A few notes:

Julia does not look up the method at runtime if the types of the arguments to the function can be deduced from the types of the arguments to the surrounding function (but it behaves that way for the user, unless he redefines the method after the function was compiled #265).

That is cool I didn't know that. I assume this can make quite a big difference in performance for tight inner loops. 

[Steven G. Johnson]

On Tuesday, January 7, 2014 2:59:03 PM UTC-5, Erik Engheim wrote:

Given that Julia is not even in version 1 and has a lot less libraries than Python I don't think Julia is a serious contender in Scientific Computing today. But I am pretty sure it will be. But that wont happen over night.

Note, however, that you can call existing Python libraries from Julia.

[curiou...@gmail.com]

I think the ability to use existing Python libraries in Julia will immensely help Julia's growth. It will encourage people to try it out for serious tasks. I think there is comfort in knowing that if some important functionality is lacking (which a Python library provides), then one can always use the python library for that task in Julia code; that is, there is no need to rewrite everything in Python. 

Also, Julia community is truly awesome; amazing helpful people. Having played with Julia for some time now, I plan to use it soon on a serious project (at least for the purpose of creating the simulation model and running the simulations, and will perhaps use Pandas for the analysis of the data). 

[Matthias BUSSONNIER]

Some misc comment too :

> Julia is not object oriented

Is that True ? From the manual :

>  It is multi-paradigm, combining features of imperative, functional, and object-oriented programming.

I consider that Julia can be OO, the code just look different than in other languages.

Typo ?

> Polymorphis lets you

Missing m ?

Liked the blog post too otherwise thanks, I would also have mentioned code_lowered, code_llvm and  code_typed

not everyone is fluent assembler and those tool are really useful to, especially in metaprogramming.

-- 

M

[Stefan Karpinski]

It's a bit hard to say whether Julia is object-oriented or not. I suspect that for a lot of people, object-oriented means "do you write `x.f(y)` a lot?" By that metric, Julia is not very object oriented. On the other hand, everything you can do with single-dispatch o.o. in C++ or Java, you can easily simulate with multiple dispatch, but you'll have to get used to writing `f(x,y)` instead of `x.f(y)`. If your notion of object-orientation has more to do with encapsulation and/or message passing, then we start to look pretty non-o.o. again.

[Daniel Carrera]

My mental picture of OOP involves encapsulation and inheritance. Julia has a form of encapsulation in the form of modules, but Julia's abstract vs concrete types explicitly avoids inheritance. This is not a criticism btw! I think Julia's design makes a lot of sense for the problems that Julia wants to solve and I have enjoyed learning new concepts like multiple dispatch.

[Tobias Knopp]

Would be interesting to see some use cases where "Java-like" OO better fits than Julias OO. In C++ one can use both and usually choses based on whether the dispatching can be done at runtime or at compile time (i.e. classes with virtual function for runtime decisions and templates for compile time decisions).
There are many situations where I would have liked to use generic programming in C++ but it was not possible as the type was only known at runtime. In Julia this is no issue which makes it such a joy to use.

[John Myles White]

I think part of the appeal of dot-notation OO is that it reads left-to-right, which helps to make the code seem to read in the same order as the sequence of actions taken.

— John

[Tobias Knopp]

Well, I mean some "real" advantages beyond this small syntactical difference. In C++ there is a lot of mix between class methods and regular functions and it is good practice to only use class methods if this is really necessary, i.e. if access to private members is required.

One issue Julia seem to have is that it is not possible to subclass final types. This can be solved by turning the "is a" into a "has a" relation but currently there seem to be no way to carry over all generic methods from the member to the parent type.

[John Myles White]

I agree that it’s not a “real” advantage, but, in my experience, the intensity of people’s passion for a feature is often inversely proportional to its computational importance.

The “has a” relation problem is very close to the issue of delegation that’s come a bunch of times before. At some point I think we have to come up with a solution to this problem.

— John

[Daniel Carrera]

I don't know... is legibility a "real" advantage? A lot of the energy
spent in designing languages goes into making them feel natural or
clear in some sense. People have different views on what that means,
and so languages proliferate. Although I do not use OOP, I would not
dis anyone for wanting to write code in the form Subject+Verb+Object.
I think it is legitimate for someone to argue that this feels more
natural. For some kinds of problems I might even agree.

Cheers,
Daniel.

--
When an engineer says that something can't be done, it's a code phrase
that means it's not fun to do.

[Job van der Zwan]

Depends on what you mean with legibility.

For example (and not at all related to x.f(y) vs f(x, y)), if I look at my experience with the Go programming language, once you get used to its imposed One True Way of formatting it really makes reading other people's source code a lot easier. And talking about spending energy on the subject of legibility: setting up my editor to use go-fmt (the autoformatting tool) when building/saving code means I don't have to spend any time thinking about it when writing my own code either; it will automatically get fixed.

It's one of those things the Go developers are very enthusiastic about, and at first you go "really? That's a killer feature?" but after using it you do start to miss it in other languages.

Speaking of which, is there an autoformatting tool for Julia?

That might seem like a tiny thing, but those two things add up.

[John Myles White]

There is not yet, because there is still not a consensus on proper style. Hopefully once we have that, it will be easier to make a julia fmt tool.

— John

[Daniel Carrera]

That's an interesting example. I don't know Go, I've only watched a
couple of videos about it.

Cheers,
Daniel.

[Job van der Zwan]

The problem I see with that is that you can wait for a very long time before any consensus emerges. There are simply many choices to be made in that regard which at the end of the day are kind of arbitrary - that a choice is made and consistently followed is more important, and again the benefit of autoformatting is that you don't have to waste putting effort into doing so.

Having something something concrete to respond to also helps with the discussion - an autoformatting tool will impose a certain style, which will drive the discussion of standardising proper style. If people disagree with the formatting it provides, great! That means a discussion is triggered.

So instead of waiting for a consensus to emerge, I think that building an autoformatting tool with a "good enough first guess" in terms of style would be the place to start. Even if it starts out with terrible style choices otherwise.

(is this worth starting a separate discussion on the topic?)

[Stefan Karpinski]

I would be into having an auto-formatting tool. The way to do this would be to work on the printing of ASTs until the way the code prints is the standard way it should be formatted. Then you have an auto-formatter: parse the code and print the resulting AST. One missing thing is that parser currently discards comments.

[Matthias BUSSONNIER]

Le 9 janv. 2014 à 14:42, Stefan Karpinski a écrit :

I would be into having an auto-formatting tool. The way to do this would be to work on the printing of ASTs until the way the code prints is the standard way it should be formatted. Then you have an auto-formatter: parse the code and print the resulting AST. One missing thing is that parser currently discards comments.

Would that work with Macros ?

-- 

M

[Stefan Karpinski]

Yep:

julia> :(@foo bar)

:(@foo bar)

julia> xdump(ans)

Expr

  head: Symbol macrocall

  args: Array(Any,(2,))

    1: Symbol @foo

    2: Symbol bar

  typ: Any::DataType  <: Any

[Matthias BUSSONNIER]

Le 9 janv. 2014 à 14:53, Stefan Karpinski a écrit :

Yep:

julia> :(@foo bar)

:(@foo bar)

julia> xdump(ans)

Expr

  head: Symbol macrocall

  args: Array(Any,(2,))

    1: Symbol @foo

    2: Symbol bar

  typ: Any::DataType  <: Any

I need to review my Julia knowledge ! 

Thanks !

[John Myles White]

One could probably make a start at this using the deparse functions in Calculus.jl.

 -- John

[Marcus Urban]

I have some concerns about how prefix-style method invocations, as in Java, would work with the existing structure of Julia. I am not trying to shoot down anyone's idea. I would just like to point out some issues.

To be clear, the basic idea seems to be implicitly translating calls like obj.method(…) to a method with signature method(obj, …).

In Java, for example, methods are declared inside a class. Suppose that myObj is an instance of MyClass. In the method call myObj.myMethod(), it is only necessary to look at the methods belonging to the actual type (class) of myObject, or one of MyClass's ancestors for an inherited method.

If Julia were to allow prefix style method calls, such as myObject.myMethod() above, where would the system look for myMethod()? With Java, the answer is given above. WIth Julia, methods are not declared inside the type declaration, so the answer cannot be the same as with Java.

One possibility is to broaden the scope to look at all methods declared in the module where MyClass is defined. This would give special status to these methods. Would a user be able to add new methods without editing the module where MyClass is declared? If so, how would these methods be indicated?

[Erik Engheim]

On 08 Jan 2014, at 11:25, Matthias BUSSONNIER <bussonnie...@gmail.com> wrote:

> Some misc comment too :
>
> > Julia is not object oriented
>
> Is that True ? From the manual :
>
> > It is multi-paradigm, combining features of imperative, functional, and object-oriented programming.
>
> I consider that Julia can be OO, the code just look different than in other languages.

I did not mean that Julia does not support object oriented programming. I mean you can program object oriented in pretty much any programming language since it is mainly about a way of thinking. But given Julia’s feature set I would say it isn’t pushing object oriented thinking. To me it is similar to google Go. As far as I remember the authors say Go isn’t object oriented although it certainly supports object oriented programming.

I personally think Julia distinguish itself positively by not incorporating a lot of the traditional ways of doing Object Oriented Programming such as inheritance of concrete types. The google Go authors also realised this was a mistake. From my experience of programming C++ for many years on large projects, I think Julia will avoid the following problems I have experienced:

1. The fragile base class problem
2. The confusion about whether an overriding function should call it’s super class version or not.
3. Accidentally calling a virtual function in the constructor. This goes bad in C++, C# and Java in different ways. Usually resulting in difficult to debug bugs.
4. Deep class hierarchies. Your average developer seem to keep adding concrete subclasses for convenience until the code is a mess. I don’t consider a deep hierarchy of abstract types in Julia a problem, because they are much easier to reason about that a deep hierarchy of concrete classes.

But I agree that whether one should call Julia object oriented or not is a difficult issue, because it might make sense for marketing purposes. Many people don’t seem to want to touch programming languages which are not object oriented, as if there is something wrong with them then. I think the teaching of object oriented programming is much to blame for this, because Object Oriented programming is often taught as a better way of doing things in general rather than as better way for modelling certain problems.

>
> Liked the blog post too otherwise thanks, I would also have mentioned code_lowered, code_llvm and code_typed
> not everyone is fluent assembler and those tool are really useful to, especially in metaprogramming.
>

Hehehe I actually looked at those briefly but could not make immediate sense of them. Assembly code made more sense to me. For most people with my background from micro controllers, robotics, systems programming and such I think you would be more familiar with assembly code than abstract syntax trees. I learned about ASTs long after I learned Assembly. But I guess for the targeted audience of Julia there are not many micro controller programmers ;-)

I am playing around with julia meta programming at the moment, but I am not very good at it yet.

[Isaiah Norton]

If Julia were to allow prefix style method calls, such as myObject.myMethod() above, where would the system look for myMethod()? 

It would check all signatures for myMethod to see if one of them takes myObject as the first argument, just as now when when calling myMethod(myObject, ...)

[Marcus Urban]

To resolve the call myObject.myMethod(), the declaration of myMethod() would need to be in the scope of the caller. That would seem to require that the caller be in the same module as the declaration of myMethod() or a using-statement for the module containing myMethod() would need to be in effect. Using-statements seem can bring unwanted items into scope, and right now the Julia runtime does not complain if one item shadows another. If myMethod() were not in the current scope, what would the call look like? myObject.MyModule.myMethod() looks odd.

[Matthias BUSSONNIER]

Le 10 janv. 2014 à 17:42, Erik Engheim a écrit :

>
> On 08 Jan 2014, at 11:25, Matthias BUSSONNIER <bussonnie...@gmail.com> wrote:
>
>> Some misc comment too :
>>
>>> Julia is not object oriented
>>
>> Is that True ? From the manual :
>>
>>> It is multi-paradigm, combining features of imperative, functional, and object-oriented programming.
>>
>> I consider that Julia can be OO, the code just look different than in other languages.
>
> I did not mean that Julia does not support object oriented programming. I mean you can program object oriented in pretty much any programming language since it is mainly about a way of thinking. But given Julia’s feature set I would say it isn’t pushing object oriented thinking. To me it is similar to google Go. As far as I remember the authors say Go isn’t object oriented although it certainly supports object oriented programming.

At first read I understood that you couldn't do OO with Julia, but maybe it is due to my limited use of english.
Carefully re-reading I understand the meaning and what was your intension, but I think a development like
you made just below would be a nice addition.

> I personally think Julia distinguish itself positively by not incorporating a lot of the traditional ways of doing Object Oriented Programming such as inheritance of concrete types. The google Go authors also realised this was a mistake. From my experience of programming C++ for many years on large projects, I think Julia will avoid the following problems I have experienced:
>
> 1. The fragile base class problem
> 2. The confusion about whether an overriding function should call it’s super class version or not.
> 3. Accidentally calling a virtual function in the constructor. This goes bad in C++, C# and Java in different ways. Usually resulting in difficult to debug bugs.
> 4. Deep class hierarchies. Your average developer seem to keep adding concrete subclasses for convenience until the code is a mess. I don’t consider a deep hierarchy of abstract types in Julia a problem, because they are much easier to reason about that a deep hierarchy of concrete classes.
>
> But I agree that whether one should call Julia object oriented or not is a difficult issue, because it might make sense for marketing purposes. Many people don’t seem to want to touch programming languages which are not object oriented, as if there is something wrong with them then. I think the teaching of object oriented programming is much to blame for this, because Object Oriented programming is often taught as a better way of doing things in general rather than as better way for modelling certain problems.
>
>>
>> Liked the blog post too otherwise thanks, I would also have mentioned code_lowered, code_llvm and code_typed
>> not everyone is fluent assembler and those tool are really useful to, especially in metaprogramming.
>>
>
> Hehehe I actually looked at those briefly but could not make immediate sense of them. Assembly code made more sense to me. For most people with my background from micro controllers, robotics, systems programming and such I think you would be more familiar with assembly code than abstract syntax trees. I learned about ASTs long after I learned Assembly. But I guess for the targeted audience of Julia there are not many micro controller programmers ;-)

Assembly do not make sense to me, and I still need to practice my AST and llvm a lot.

> I am playing around with julia meta programming at the moment, but I am not very good at it yet.

Hope you'll made a post about it too :-)

--
M

[Erik Engheim]

What not just do it in a similar fashion to how Haskell supports infix notation? If the whole point is the readability from rearranging the function and arguments. Then you don’t have to deal with awkward issues like automatically including a module. That is just going to get messy. But honestly I think the regular Julia way is totally fine to read. It is a question of what you have gotten used to. I have changed my preferences several times based on what I have gotten used to. The only real advantage I can see from infix notation is how it naturally lends itself to function/method completion in an IDE. But I am sure one can achieve something similar in Julia. Writing the name of a variable and then hitting a hotkey could cause a method completion on methods where the first argument is of the same type as the variable.

[Cristóvão Duarte Sousa]

Reading from Wikipedia "Object-oriented programming" page I would say Julia is pretty object-oriented.

Sure it do not has the traditional syntax, but OO is not the syntax, it's the concept.

Julia has "objects" with "data fields", which are instances of "classes" (Types), it has "methods" which are polymorphic, etc.

About inheritance, Julia does not has field inheritance, but in some sense it has inheritance of properties, e.g., although not it is not enforced/explicit, subtypes of AbstractArray are supposed to implement the size() method/property (and it even hides the way each subtype stores/represents its size).

Maybe Julia lacks a way to define interfaces, to enforce that methods are implemented in concrete subtypes, but even for that I think that a runtime "ERROR: no method size(MyArray)" is more than enough.

The more I use Julia the more the abstract hierarchy makes sense to me. A "car" is "vehicle" and we can think of a "vehicle" as an abstract object, but a concrete "vehicle" has to be either a "car", a "plane" or something else. (Ok, in this case car is still an abstract concept...).

About the left to right reading, how about creating a syntax operator calls the function placed on its right side with the value placed on its left as the first argument?

Some thing like

    mystring..split('\n')     and    myarray..size()

where the .. syntax is the same as

    split(mystring, '\n')     and    size(myarray)

Something close to this can already be done, although for single argument functions only:

    "qwe\nasd" |> split

On Monday, December 30, 2013 11:04:02 PM UTC, Pedro Rafael wrote:

Gentlemen, how's it going?

Worth learning Python or Julia replaces python for scientific computing? I see many people encouraging the use of Python for scientific computing.

[Job van der Zwan]

So you are saying that the most of the tooling required for an auto-formatting tool is already there?

[Stefan Karpinski]

Kind of. I don't think that expression printing is even remotely good enough for this yet, but that's the basic idea that makes the most sense to me. No point in using separate parse or print code when there's already functions that do this stuff.

[Maxim Grechkin]

Was there any progress on this lately? I've noticed that atom-beautify plugin doesn't have Julia support(https://github.com/Glavin001/atom-beautify/issues/799), but there doesn't seem to be a tool that it can hook into.

[Tony Kelman]

Would maybe be better to start a new thread asking about this rather than adding to an old one.

But anyway, no there is not currently anyone working on a standalone Julia formatter as far as I know. The IDE's under development as Eclipse and Atom plugins are working on their own formatters, but they are somewhat specific to the IDE environment that they're written for. It would be great to have something command-line or a Julia package that looked into this, and could be used like clang-format or yapf.

[Cristóvão Duarte Sousa]

I don't know if it has been said here before, sorry if I'm repeating, but:

a way to represent the "concrete" syntax tree, convert it to AST and then back would be of great use here, see https://github.com/JuliaLang/JuliaParser.jl/issues/22 .

I actually thought a lot about that, and imagine that the `Expr` type could have an extra field to hold syntax delimiters (punctuation and whitespace) which is found around and between its arguments.

But a great knowledge of the parsers, both Flisp and Julia written ones, would be required.

Then I also wondered that maybe one formal, but incomplete, grammar could be useful to construct such tree, as in intermediate step between source code and real AST.

That would allow the creation of very powerful autoformatting tools, along with lints, refactoring and other advanced IDE functionalities.

[Erik Schnetter]

On Fri, Feb 12, 2016 at 5:17 AM, Cristóvão Duarte Sousa
<cri...@gmail.com> wrote:
> I don't know if it has been said here before, sorry if I'm repeating, but:
> a way to represent the "concrete" syntax tree, convert it to AST and then
> back would be of great use here, see
> https://github.com/JuliaLang/JuliaParser.jl/issues/22 .
>
> I actually thought a lot about that, and imagine that the `Expr` type could
> have an extra field to hold syntax delimiters (punctuation and whitespace)
> which is found around and between its arguments.

Adding to the `Expr` type is expensive, since it's used a lot.
Instead, you can add extra `Expr` objects, e.g. `Expr(:empty_line)`,
or `Expr(:block_comment, "text")`, or `Expr(:inline_comment, "text")`.

-erik

--
Erik Schnetter <schn...@gmail.com>
http://www.perimeterinstitute.ca/personal/eschnetter/

[Cristóvão Duarte Sousa]

Yes, but then where such Exprs will placed? Not inside the args array of other Exprs...

I guess that if it is necessary to revert back to source code from an AST, then a modification to Expr has to be made...

[Erik Schnetter]

Line numbers are already handled in this way:

julia> parse("f(x)=x") |> dump
Expr
head: Symbol =
args: Array(Any,(2,))
1: Expr
head: Symbol call
args: Array(Any,(2,))
1: Symbol f
2: Symbol x
typ: Any
2: Expr
head: Symbol block
args: Array(Any,(2,))
1: LineNumberNode
file: Symbol none
line: Int64 1
2: Symbol x
typ: Any
typ: Any

-erik

On Fri, Feb 12, 2016 at 10:25 AM, Cristóvão Duarte Sousa

[Cristóvão Duarte Sousa]

Hum, OK, it uses block Exprs... That may then work for punctuation and whitespace too.