I don't really see the need for the author to make himself into a "cowboy" coder and point out how they ignore all those valuable insights and enlightenments of programmers.
Julia is a kind-of-fine language that is designed to appeal Matlab users first of all by its syntactical looks. Just like Javascript was designed to appeal to C and Java users by imitating their look.
Under the hood, Julia is quite a smart development, not only in terms of code generation, but also in terms of datatypes and object models.
Multiple dispatch is something that more or less only Lisps typically offer natively (and Dylan). When working with types (especially in dynamically strongly typed languages) this is often something what I am missing in other languages. Consider Python:
if isinstance(x, Y):
...
elif isinstance(x, Z):
...
This feature alone shows that the authors of Julia are rather the thoughtful language-loving authors.
So I would like to leave the small scope of the article but look at the greater picture: Julia and its competitors. There are actually quite a few on the market. A few domain-specific numerical libraries exist for C/C++/Fortran for scientific purposes (ROOT at Cern, etc.). They are more or less falling out of fashion. For a long time, Matlab has been dominant in some faculties for evaluation and working with data, process signals and images. It is not by accident that Matlab was created as a convenient Wrapper to Fortran libraries at the time. From a software developer's perspective, Matlab is for Cowboys.
Next to its high price (and the vendor lock in forced upon college and university students who are trained for matlab when there exist suitable open source alternatives), the most appalling thing about Matlab is its poor performance as a programming language. While its easy to write small scripts, solve linear algebra problems and plot a few things, I have hardly seen well organized Matlab code and I just think that it is impossible. While Matlab licenses cost heaps of money, support is not good and upon a version change you have to spend considerable amounts of work getting around API changes.
The Matlab clones available (Octave) are generally unimpressive. I think this has to do with the big effort of copying Matlab and the need to develop the whole tool stack (parser, interpreter, libraries). Contributors are hard to find because octave hardly offers any benefit over the original, like ReactOS with Windows, Octave can only react. I still value the effort of the octave folks, they have done some great work!
Scientific Python has chosen a slightly different path. Taking the fairly uncontroversial programming language Python, the authors created an infrastructure of thematically separated modules. While eliminating the need to design and implement an own programming language, a lot of work could be spent on building useful libraries. Also, existing libraries were reusable (databases, XML, etc.) and Python is a really convenient programming languages for both Newbies and professional software developers. So with this pragmatic approach, the contributers have created one of the best environments for scientific software development and would be my suggestion for anyone at the moment who just wants to use one system.
What still amazes me: While working in an ipython notebook (http://ipython.org/notebook.html) on some numerical calculations, I can just pull up Sympy (http://sympy.org) and perform some symbolic computations (Fourier transforming some function analytically or taking the derivative of some other, etc.).
Oh, and have I told you about how Scipy can replace R for really cool statistical analyses?
The part where Julia kicks in now is the point that Matlab has a lot of market ground, especially with engineers who are not extraordinarily passionate about programing. For some people the burden of learning another syntax is just too big, they are not full time programmers but spend their time more with acquiring data and using the results. I really hope that some of them who are not willing to switch to scientific python can agree on switching to Julia.
Full Disclosure: I have occasionally been forced to work with Matlab (so I do have some experience with it without being an expert) and it was not fun. This is one of the reasons I would like all Scientists to have the chance of choosing a good environment that is suitable for them. If its Matlab for some, so be it ;-) I have never looked back.
> "The part where Julia kicks in now is the point that Matlab has a lot of market ground, especially with engineers who are not extraordinarily passionate about programing. For some people the burden of learning another syntax is just too big, they are not full time programmers but spend their time more with acquiring data and using the results. I really hope that some of them who are not willing to switch to scientific python can agree on switching to Julia."
As I see it, this will be Julia's main market. Younger engineers (read: "non-CS engineering students", i.e. electrical, mechanical, civil, etc) may encounter Python in college and become proficient in it, but because of historical reasons most of their assignments require some combination of Matlab, C, or Fortran. Even in group projects where the students have more independence with their choice of tools, if only one person in the group knows Python, the group will probably default to one of the common tools. When time is a scarce resource and time spent learning Python doesn't show much promise of improving your class performance, most students will neglect it.
Julia, at first glance, looks very familiar to a practicing engineer or scientist who is experienced with Matlab or Octave. It's the sort of thing that you could teach yourself in a weekend, and teach others at work if need be. Not necessarily the low level cleverness of the language or some of the more advanced uses of it, but enough to Get Stuff Done(TM). And that's what matters to most technical types without a background in CS. They will appreciate elegance and safety when they see it, but they're not going to decide what tools to use based on those factors.
You cannot overestimate enough how old folks growing up with Fortran just won't accept Array indizes starting at 0 instead of 1.
Then because professors demand it, colleges buy Matlab campus licenses and "encourage" their staff/students to use it, incorporate in teaching and research.
Sadly, when the student is not on campus anymore, he/she cannot reevaluate old date and in the new job they then demand a matlab license. Its the Matlab tax.
> The Matlab clones available (Octave) are generally unimpressive. I think this has to do with the big effort of copying Matlab and the need to develop the whole tool stack (parser, interpreter, libraries). Contributors are hard to find
What still amazes me: While working in an ipython notebook (http://ipython.org/notebook.html) on some numerical calculations, I can just pull up Sympy (http://sympy.org) and perform some symbolic computations (Fourier transforming some function analytically or taking the derivative of some other, etc.).
You can certainly do it with Matlab (provided you have purchased the symbolic toolbox of course).
Oh, and have I told you about how Scipy can replace R for really cool statistical analyses?
Sure, it can for some things, but why?
My thing with Python is that it kinda loses to Matlab for non-statistical work (except perhaps for select fields, like network analysis or language processing), and to R/SAS/Stata (depending on type of job and personal preference) for statistical stuff. Of course all of these (other than R) are proprietary and not cheap, but most universities have all of them anyway, and businesses just buy what they need.
btw: did you first learn Matlab, or Python? In my experience, there is a tendency for people who start with Matlab to dislike Python, and for people who start with Python to dislike Matlab :) Probably has something to do with some basic things being just so slightly different, and therefore bothersome.
Also, the Matlab IDE these days is actually quite decent -- does Python have something similar?
Sure enough there are parts of matlab where matlab is without serious competitors. I think however that a majority of needs is available for Python, although I know that I do not represent everyone's needs.
I switched to Sci.Python at the point where I had difficulty treating time series data with Matlab. I know there is a toolboxy-thingy from mathworks but it either was not available or I did not find the documentation. Anyway, I quickly got started with Pandas. I had prior knowledge of Python and other mainstream programming languages before.
Spyder is a Matlab-ish IDE with a variable explorer, etc. Some like the Ipython Notebook which I think is great for demonstrations and teaching, but eventually does not scale when projects grow bigger.
Yeah, networkx is pretty good -- I actually meant that network analysis and text processing are the two areas where I'd be quite comfortable recommending Python over Matlab.
For time series data, I'd personally pick R though, or perhaps SAS if it's large enough -- at least if any statistical analysis is involved...
R design is somewhat like perl in the sense that usually there are a lot of ways of doing anything. This includes time series of course. That being said, last time I did time series, I've used xts and was quite happy with it.
I grew up on Matlab. Entire PhD thesis work was all matlab. I started using python after leaving academia because it's much easier to put python into production, and I've never looked back. There are only 3 benefits to matlab. 1. Simulink, if you do that kind of stuff (I don't). 2. Some numerical algorithms in matlab are more efficient, but then some of the python ones are more efficient. 3. matlab array syntax is a bit more concise.
Python destroys matlab in all other regards. Once you've tried it for a while you'll understand the value of a general purpose programming language with advanced numerical capabilities
The biggest strength of matlab is the libraries, but you can very easy use those in python using an integration library like mlabwrap, and still have all the benefits of python.
And there's a python IDE called spyder which is similar to the matlab IDE.
Julia is a kind-of-fine language that is designed to appeal Matlab users first of all by its syntactical looks. Just like Javascript was designed to appeal to C and Java users by imitating their look.
Under the hood, Julia is quite a smart development, not only in terms of code generation, but also in terms of datatypes and object models.
Multiple dispatch is something that more or less only Lisps typically offer natively (and Dylan). When working with types (especially in dynamically strongly typed languages) this is often something what I am missing in other languages. Consider Python:
This feature alone shows that the authors of Julia are rather the thoughtful language-loving authors.So I would like to leave the small scope of the article but look at the greater picture: Julia and its competitors. There are actually quite a few on the market. A few domain-specific numerical libraries exist for C/C++/Fortran for scientific purposes (ROOT at Cern, etc.). They are more or less falling out of fashion. For a long time, Matlab has been dominant in some faculties for evaluation and working with data, process signals and images. It is not by accident that Matlab was created as a convenient Wrapper to Fortran libraries at the time. From a software developer's perspective, Matlab is for Cowboys.
Next to its high price (and the vendor lock in forced upon college and university students who are trained for matlab when there exist suitable open source alternatives), the most appalling thing about Matlab is its poor performance as a programming language. While its easy to write small scripts, solve linear algebra problems and plot a few things, I have hardly seen well organized Matlab code and I just think that it is impossible. While Matlab licenses cost heaps of money, support is not good and upon a version change you have to spend considerable amounts of work getting around API changes.
The Matlab clones available (Octave) are generally unimpressive. I think this has to do with the big effort of copying Matlab and the need to develop the whole tool stack (parser, interpreter, libraries). Contributors are hard to find because octave hardly offers any benefit over the original, like ReactOS with Windows, Octave can only react. I still value the effort of the octave folks, they have done some great work!
Scientific Python has chosen a slightly different path. Taking the fairly uncontroversial programming language Python, the authors created an infrastructure of thematically separated modules. While eliminating the need to design and implement an own programming language, a lot of work could be spent on building useful libraries. Also, existing libraries were reusable (databases, XML, etc.) and Python is a really convenient programming languages for both Newbies and professional software developers. So with this pragmatic approach, the contributers have created one of the best environments for scientific software development and would be my suggestion for anyone at the moment who just wants to use one system.
What still amazes me: While working in an ipython notebook (http://ipython.org/notebook.html) on some numerical calculations, I can just pull up Sympy (http://sympy.org) and perform some symbolic computations (Fourier transforming some function analytically or taking the derivative of some other, etc.).
Oh, and have I told you about how Scipy can replace R for really cool statistical analyses?
The part where Julia kicks in now is the point that Matlab has a lot of market ground, especially with engineers who are not extraordinarily passionate about programing. For some people the burden of learning another syntax is just too big, they are not full time programmers but spend their time more with acquiring data and using the results. I really hope that some of them who are not willing to switch to scientific python can agree on switching to Julia.
Full Disclosure: I have occasionally been forced to work with Matlab (so I do have some experience with it without being an expert) and it was not fun. This is one of the reasons I would like all Scientists to have the chance of choosing a good environment that is suitable for them. If its Matlab for some, so be it ;-) I have never looked back.