Comment by simonster | Hacker News Reader

Comment by simonster | Hacker News Reader

Parent Full thread

I started out with MATLAB, played around enough with Python to realize that it wasn't enough better than MATLAB to be worth switching. (My impression was that Python was almost flexible enough as a language to make writing code that uses NumPy/SciPy feel natural, but it didn't quite achieve that.) I finally switched to Julia, which is both faster and (IMO) more enjoyable to write than either MATLAB or Python, although the current package ecosystem is pretty small. I think the main difficulty in creating a new programming language for numerical computing is that you need knowledgeable people to do it, and most of those people are more interested in analyzing their data than building a programming language (or core packages for a programming language) to do it better.

My impression on two small bits of this article:

Python is also somewhat restrictive with what you can say on a single line. In Matlab you would often load some data, start editing the functions and build you data analysis step by step, while in Python you tend to have files which you start from the command line (or at least that’s how I tend to do it).

I actually find that this kind of analysis is more conveniently done in IPython (or IJulia) Notebook than in MATLAB.

I still have dreams of a plotting library where the type of visualization is decoupled from the data (such that you can say “plot this matrix as a scatter plot, or as an image”).

This is the design goal of both R's ggplot2 and Julia's Gadfly.jl.

Similar to me. I started with MATLAB (I even worked for them for a time), but then moved to Python when I started working more in Bioinformatics and lately explore Julia a lot. The current issue with Julia is that most of the tutorials and docs available on the web are targeted at developers, not users, and therefore has a hard time converting the more casual MATLAB and, to a lesser degree, Python users. The major advantage of MATLAB over any of the other languages is its integration with the MATLAB Desktop and the casual simplicity for non-programmers. I don't really have to worry about data types, it seems to be working out of the box (which is an advantage for beginners but a serious handicap at a later stage). Julia has a higher initial barrier to adoption with its many different paths to success). Though I suspect that especially with its macros julia will be able to create extremely intuitive and expressive packages for all kinds of problem domains.

I think a good start for julia would be to include more workflow-oriented tutorials in the docs that also provide a path through the current mess of packages (220 at current count, with sometimes quite redundant functionality, e.g., Gadfly, Winston, pyplot, Gaston). Heck, maybe I should just help with it once I'm done with my current project.

Speaking as someone who has a lot of work invested in the numeric Python system I share a lot of the same sentiment. I'm unhappy with how lot of the current thinking is centered around building essentially large embedded DSLs to invoke C libraries. Although it's a technique that works and has been successful, it's become a big pain to maintain and extend over the years. Just look at how much work has been spent just trying to get simple things like NA values into NumPy.

My recommendation to other numeric Python devs is that if you don't have any investment in a specific numeric Python library think about moving your project to Julia, I suspect the ecosystem will bloom pretty rapidly and provide a much more future-proof set of tools for technical computing.

One of the nice things in Python is that it is nit limited to scientific computation.

I remember the days when I tried to do command line automation in Matlab, or tried to read some XML from some internet resource.

This stuff is super simple in Python, but very hard in Matlab, because Matlab focuses so much on science and so little on general usefulness.

Python is not as integrated with regards to the scientific core functionality, but it doesn't limit you to it, either.

Matlab leaves something to be desired for general programming tasks. If you can, it's sometimes nice to define stages and pipe between them. I love Python for text processing and XML, but I find Matlab way easier for shoving matrices around. I liked using the strengths of both by pre-processing raw text and XML files through a Python script, spitting out a CSV or tab-delimited file, and slurping that up in Matlab.

Matlab has come a long way though. Coming from a functional programming background, I was delighted to find that you can pass functions as arguments to some matrix operators and get some very terse map+reduce operations.

There's Oct2py and mlabwrap which lets you call octave and matlab functions from python. I've used Oct2py a few times just like you describe and it worked fine. Read, parse and format my data in python, passing it to some matlab functions (which happend to work in octave) and then formatting and writing the results back in python.

Yes, for many things, Python is better than MATLAB. But the choice of language is no longer dichotomous, and Julia manages to be better for command line automation than Python. A pipe operator combined with custom interpolation for command literals gives you really beautiful syntax:

  fname = "/tmp/myfile with spaces"
  f = open(fname, "w")
  run(`echo hi` |> f)
  close(f)
  pipe, process = readsfrom(`cat $fname`)
  cmdoutput = readall(pipe)
  println(cmdoutput)

I'd write all of my command line scripts in Julia, except the interpreter currently takes far too long to start. But people are working on that.

I have used MATLAB a little bit - it was indeed more concise for matrix math than Python + Numpy.

But pure matrix math is a small part of my analyses and workflow. Most of the code is in data preprocessing from SQL servers, CSV files, JSON files, and various cleanups. Once you have your data in an array, MATLAB can be great, but writing general-purpose code (or even a while loop) was horrible.

My only problem with the Julia language is that it requires code be written without vector notation in order to be fast:

In general, unlike many other technical computing languages, Julia does not expect programs to be written in a vectorized style for performance. http://docs.julialang.org/en/latest/manual/arrays/

In Fortan, MATLAB and Python, the opposite is true: vector notation is fastest.

I'm quite certain Mikio knows about ggplot2.

Ggplot2 and friends are great, but theres plenty of room for even better tools in the data vis space.

Definitely true, especially for >3D data sets.

Do you have any recommendations wrt getting started with Julia? It's a language I've wanted to explore a bit, but I haven't been able to find any good community resources or jumping-off points.

This "Learn X in Y minutes" snippet [1] showing a bunch of examples in Julia is the best starting point. I always return to this one as it is usually much faster to find what you're looking for than searching the docs.

1: http://learnxinyminutes.com/docs/julia/

I wrote Learn Julia in Y minutes. Is there anything unclear or that you'd find useful to have included/changed?

I might not be the best person to ask, since I don't generally have the attention span for tutorials and usually prefer to learn by reading/writing code. With that said, the manual (http://docs.julialang.org/en/release-0.2/manual/) is quite good.

This thread led me to search for updated information about Julia's maturity. I came across a pretty informative post from one of the devs and posted it at https://news.ycombinator.com/item?id=6782015.

Reply on news.ycombinator.com