Hacker News Reader

Comment by dragontamer | Hacker News Reader

R > Matlab. But both suck as programming languages.

But that's because neither R nor Matlab are primarily programming languages. They're primarily mathematical exploration tools.

View on HN

Right. Julia is looking fairly promising as a "real" programming language that is still an excellent Matlab replacement, and possibly to a lesser extent an R replacement, and it does show that there is nothing about filling the exploratory math programming niche that requires it to have the warts that the incumbents have.

Fundamentally, R and Matlab are probably best comparable to Perl in terms of how they got popular. While they are rather ugly, they were the first to provide a simple solution to a few specific problems that a lot of people had, which snowballed them into popularity and network effect advantages

The fact that Julia requires compilation seems like such a huge hurdle to adoption in light of the above. When the alternatives are a REPL and the users aren't programmers, to use Julia they have to first learn the difference between code and compiled code.

Julia is JIT compiled and most people use it through a REPL. For a beginner there's hardly a difference in the experience.

No, there is a difference. My day-to-day use case is: start the REPL, start typing some code, wanna see a graph. I might literally only want to write a single command. If that takes a minute to compile, it's a problem. Julia is pushing hard to address this and I'm really interested to see where it goes - I tried it for the first time recently and saw a lot to like.

Project Jupyter's name is a reference to the three core programming languages supported by Jupyter, which are Julia, Python and R

https://en.wikipedia.org/wiki/Project_Jupyter

Right, compilation time went down a lot with 1.6 by avoiding method invalidations during compilation. The other thing they did is ensure that the package manager properly compiles all dependencies in topologically sorted order when you install a package, instead of doing a lazy compile on package load where it would often waste time recompiling the same method.

Julia isn’t compiled tho it has a REPL?

One isn't precluding the other. For example, SBCL is an implementation of Common Lisp that compiles everything ahead-of-time down to native code, and like all Common Lisp implementations, it offers a powerful REPL suited for interactive development. The compiler has low overhead, so you don't even notice that it compiles everything you type into your REPL.

Another common misconception is that AOT compilers can only be used to build libraries/executables, which then get executed. Again, SBCL is an example of an AOT compiler that works at function-level granularity[0], in accordance with Lisp heritage of image-based development, where you write your program by starting it, and then adding/removing/modifying code into a running instance. SBCL achieves this by having the compiler being a part of your application runtime.

I don't know how Julia is implemented internally, but since it's essentially a Lisp clothed in syntax that's more pleasant to the masses, it inherits a lot of Lisp family heritage. That could easily include a fast, to-native, in-process AOT compiler.

[0] - Or maybe even lower.

Julia's JIT is a just ahead of time method jit just like SBCL, and the language is designed around making idiomatic code as fast as possible with that approach.

So every function is a multimethod that gets compiled the first time any combination of types is first encountered, and at that point the type information is propagated to all function calls inside the method body, to eliminate dynamic dispatch on those & possibly inline the appropriate method. Julia has parametric polymorphism as well, so it's common for all types in the body to be inferable.

As a result, Julia code tends to make much more heavy use of polymorphism & multimethods than common lisp (where CLOS has a significant runtime cost instead of being a near-zero cost abstraction), since the language and the runtime were designed carefully together to make that fast.

A quick look an Julia’s get started guide shows it does not require compilation...

https://docs.julialang.org/en/v1/manual/getting-started/

Luckily, Python >> R > Matlab, and the fight between R and Python is core to data science. Last I did any real investigation, R still had the edge in highly-theoretical and new techniques, for whatever reason it was much more used by academics, but Python was eating R's lunch for non-academic data science.

I've given SciPy a try, but its performance is grossly lower than R and Matlab in my experience. SciPy also seems to be missing plenty of things. You get pretty far (basic filter design seems easier in SciPy than Matlab), but Matlab has so many different mathematical fields in it that Matlab vs Python are just incomparable in terms of mathematical usability. Matlab has way more features.

R is statistical-slant, so you have all sorts of distributions and statistical features.

Matlab is general mathematics (but especially matricies). So you can grab say... Galois Fields between 2^2 through 2^16 and just start working with them immediately.

Matlab itself is decently replicated by Octave (which is a great project), but it should be noted that Octave aims to be largely compatible with Matlab (so all of my complaints about how awful that programming language still applies).

Reply on news.ycombinator.com