“One way to think about Julia is that they took Python, and made it fast,”
this makes me angry.
I don’t know if it is true or not, but it should really be put some effort into public perception to get rid of this view, that Julia is a fast Python.
Here I quote myself:
Hmm, this is one of my biggest gripes I have with Julia: that Julia is nearly always compared to Python. But I experience this as mainly driven from us (this community, actually not me, but them
). I see that Julia has its strongest arguments in the data analysis world (where I am too) but on the other side I see this as the biggest obstacle for Julia to be more widely adopted. There are still some features missing (slim standalone executables, modern GUI,…) for this to become real and the focus on data analysis puts these features into the low priority queue.
The result is: Julia is only good for data analysis, thats what it is made for, so it is the natural thing to compare it to Python, when ever it comes to some articles or blogs.I want to see Julia to overcome this burden and free itself into more than just data analysis.
One way to think about Tesla is that they took a Car, and made it run by electricity…
Now it looks like, that I said this “One way to think about Julia…” thing. would you mind to edit it?
One way to think about Tesla is that they took a Car, and made it run by electricity…
This is degrading the engineering effort, too. If this is just a valid way of thinking of it, than why did it took years for the other car manufacturers to bring something equal onto market?
I totally agree with you. Good journalism make analogies without losing the essence… Bad journalism makes analogies because it can’t explain or comprehend and screws it up.
The quote, in context:
“One way to think about Julia is that they took Python, and made it fast,” he says. “With LFortran, we are trying to go the opposite route: take a fast language like Fortran and see how interactive you can make it.”
Certainly nothing I’d get angry about. And I don’t think “made it fast” is meant to be any more denigrating than “make it interactive”.
The statement isn’t really accurate, in that Julia was never slow and didn’t start from Python. It always used LLVM and was designed from the ground up, semantics and all, to produce code with competitive performance.
Tacking on a JIT after a language and its semantics were already defined is trying to make it fast.
But there’s better things to get worked up about. And getting bogged down in details like this is a great way to lose anyone who wasn’t already invested enough to have joined the choir.
If I take the route “take a fast language like Fortran and see how interactive you can make it” I wouldn’t claim that “they took Python and made it fast”.
It’s fine to take Fortran and try to make it interactive.
But what does this have to do with “One way to think about Julia is that they took Python, and made it fast” ?
It’s wrong and unrelated. It acually doesn’t make sense at all. It’s something which sounds good if you read fastly over it, but it doesn’t provide any additional motivation for making Fortran interactive.
Well, this part is just bad writing, and that’s not what makes me angry.
What the point is, that the existence of Julia seems to be only justified when compared to Python and what Julia solves in respect to that language.
And for this I see the main reason how the Julia creators and this community is advertising Julia.
So, I claim, that the Julia community (including creators and all) do see Julia mainly as a better Python and this view is bad for the further evolution of Julia.
It could be worse, for example, “They took Matlab and made it free”
But I agree with you, this kind of comparison hurts language a lot. Multiple dispatch for example is way more important feature, then pure speed. But it makes no sense to say something like “They took XXX and added multiple dispatch”.
Being a previous Fortran programmer, I would say “They took Fortran and made it cool.”
Yesterday I was talking to an old Fortran programmer. He had heard about Julia a lot, and for him the reason for Julia is “you can write fast code and use a lot of numerical libraries easily”. Not enough to justify learning a new language for him. Yet, I have shown him another side of the story: How Documenter builds a documentation, how the function comments get automatically into the documentation, how one can see the comments as a help entry in the REPL. Then he was really impressed. It was not Julia itself, I guess other high-level languages have similar features and tooling. But we should not underestimate the importance of these things when showing off to an audience which may not be very impressed by the possibility of writing fast code, if that is what they already do.
In fact, to make an analogy with Fortran, many of the very first cars were electric.
Petroleum spirit was sold in pharmacies as a house cleaning solvent. When Mrs Benz took the first useful trip by car she bough the petrol from shops along the way.
I would say that julia is all the things above. It is a bit like a fast python, a bit like a free matlab, a bit like a cool fortran. What makes it amazing is that it is everything above and more.
I agree. As is well-known, they took Lisp, added native parametric types with aggressive devirtualization, and replaced S-expressions with M-expressions as bait for unwary programmers
I couldn’t resist adding my two cents worth to the comments on the article.
Regardless of the specifics, it is nice to see Julia popping up in non-Julia related articles.
What I find intriguing in that article is the mention of the compiler from FORTRAN to LLVM (Ondrej Certik @certik), the LFortran. This might make it possible to include FORTRAN source files in a Julia program, might it not?
Well, the same reasoning should extend to C source files, no?
Actually the quote is due to Certik:
“One way to think about Julia is that they took Python, and made it fast,” he says. “With LFortran, we are trying to go the opposite route: take a fast language like Fortran and see how interactive you can make it.”
From the article MSN
So if someone so conversant with Python has trouble distinguishing between those two,
I think we have a communication problem.
Tesla? Checkout the timeline.
My name is OndĹ™ej ÄŚertĂk, who was quoted in the article.
I did a video interview with the author of the article, but I have not seen any draft prior to publication. When I read it, I wish I was quoted a bit differently, or to put more context into it, not just a short quote. Note that I told this exact quote to @StefanKarpinski several years ago (in person at a NumFOCUS meeting in NYC) and he did not object to it being completely inaccurate.
But it seems that a lot of people in the Julia community do object to this characterization.
Would any of you be willing to do a video call with me to discuss this further, so that next time I mention Julia, I characterize it more accurately?
Let me try to put it in context as I see it:
-
Julia: let’s keep the advantages of Python being interactive, easy to learn, “duck typing”, etc. Now let’s see how we can fix the main flaw: speed. To do that, one has to introduce types, use LLVM from the beginning, figure out the semantics in a way so that it can be compiled to be fast, etc. Modify the language a bit. Since we are introducing a new language, let’s also do some other cool stuff, such as multiple dispatch.
-
LFortran: let’s keep the advantages of Fortran being very fast, simple language, easy to learn and possible to write large codes in. Now let’s see how interactive we can make it.
I can do others too:
-
Rust: let’s take C++ and keep: fast, ahead of time compilation, generic programming. Now let’s fix some of the flaws: fix unreadable template error messages and provide excellent error messages in general, fix memory safety bugs, provide a good build system and a package manager (Cargo). Things that Rust didn’t fix (in my subjective opinion): slow compilation, large language with a steep learning curve.
-
Go: take Python, keep easy to learn, small language. Make it faster (but not necessarily as fast as possible) and ahead of time compiled, to better support building and maintaining larger code bases. (I think there is more to say about Go, I am not too familiar with it.)
I know that the above is necessarily simplified, but for people that know Python, C++ or Fortran and their pros/cons, it provides a quick intro into the other languages (Julia, Rust, Go) and where their strengths and weaknesses could be relative to the languages that they know.