Hacker News Reader

Comment by geofft | Hacker News Reader

> Julia says:

> A language must compile to efficient code, and we will add restrictions to the language (type stability) to make sure this is possible.

> A language must allow post facto extensibility (multiple dispatch), and we will organize the ecosystem around JIT compilation to make this possible.

> The combination of these two features gives you a system that has dynamic language level flexibility (because you have extensibility) but static language level performance (because you have efficient code)

Given those constraints, the first language that comes to mind is Java. Why is Java basically not a player in the scientific-computing game?

View on HN

That’s a really good question and I’m not sure I fully understand all the reasons. One big one is that Java intentionally has made interop with native libraries quite difficult. One cannot take a language seriously for numerical computing if you can’t easily call BLAS, LAPACK and FTTW just to start, and there’s a neverending supply of such efficient native libraries. Julia, on the other hand makes it easy to write efficient code in Julia but also makes it easy to call native libraries written in other languages. Easy interop with numerical libraries was pretty much the first design criterion.

There’s also some unfortunate choices Java made like standardizing one specific semantics for reproducible floating point code. That’s unfortunate because adjusting for native SIMD widths sacrifices reproducibility but improves both accuracy and speed. The only choice if you want perfect reproducibility on all hardware that Java supports is the worst performance model with the worst accuracy.

There’s also the fact that Java integers are 32-bit and Java arrays are limited to 2GB, which was reasonable when Java was designed, but is pretty limiting for modern numerical computing.

I also think that the JVM object model is quite limiting for numerical computing. They still don’t support value types, but value types are precisely what you want to represent efficient numerical values like complex numbers, or quaternions or rationals, and so on. Java forces all user-defined types to be heap-allocated reference types. Julia solves this by defaulting to immutable structures, which is exactly what you want for numerical values: the semantics are still referential (if you can’t mutate you can’t distinguish value semantics from reference semantics), you just can’t change values, which is exactly how you want numbers to behave (you don’t want to be able to change the value of 2).

Lack of value types in Java also makes memory management unnecessarily challenging. You can’t make a user-defined type with an efficient C-compatible array layout in Java. Because the objects are references, so the array is an array of pointers to individual heap-allocated objects. The ability to subtype classes forces that, but even with final classes, the ability to mutate objects also forces it, since pulling an object reference out of an array and modifying it is required to modify the object in the array (reference semantics), and that’s incompatible with the inline array layout.

And finally, this same lack of value types puts a LOT of pressure on the garbage collector.

> I also think that the JVM object model is quite limiting for numerical computing. They still don’t support value types

This is mostly true, but the primitives are value types and you can get some things done with them. (Not enough to make Java good for these use cases, no.) I.e. write float[] instead of Float[] and you have a contiguously allocated region of memory that can be efficiently accessed.

the fact that they couldn't make primitive vs object invisible is just incredibly dumb though. it's one of the many ways c# is purely superior.

C# is certainly more flexible in this regard but I wouldn’t say they made the distinction between primitive and object invisible, they just allowed user-defined “primitives” in the sense that users can define C-style structs that have value semantics. The type system is still bifurcated between value types and reference types. That’s ugly but livable in a static language where you can just disallow mixing the two kinds of types. And it’s not just theoretically ugly: it means you cannot write generic code that works for both kinds of types. Or you can yolo it like C++ templates and just allow whatever by textual substitution—to hell with the semantic differences. But of course then you get all kinds of surprising differences in fundamental behavior based what kinds of types you try to apply your generics to. Which is exactly what happens with C++ templates.

What do you do in a dynamic language where no such separation can be enforced? Or in a static language where you just don’t want that kind of ugly anti-generic bifurcation of your type system? The classic static PL answer is to just make all objects have reference behavior. (Which is the approach Java takes with a pragmatic ugly exception of primitive types.) This is the approach that ML and its derivatives take, but which is why they’re unsuitable for numerical computing—in ML, Haskell, etc. objects have “uniform representation” which means that all objects are represented as pointers (integers are usually represented as special invalid pointers for efficiency), including floating point values. In other words an array of floats is represented in ML et al. as an array of pointers to individual heap-allocated, boxed floats. That makes them incompatible with BLAS, LAPACK, FFTW, and just generally makes float arrays inefficient.

So what does Julia do? Instead of having mutable value and reference types, which have observably different semantics, it has only reference types but allows—and even defaults to—immutable reference types. Why does this help? Because immutable reference types have all the performance and memory benefits of value types! Yet they still have reference-compatible language semantics, because there’s no way to distinguish reference from value semantics without mutation. In other words immutable structs can be references as far as the language semantics are concerned but values as far as the compiler and interop are concerned. And you can even recover efficient mutation whenever the compiler can see that you’re just replacing a value with a slightly modified copy—and compilers are great at that kind of optimization. So all you give up is the ability to mutate your value types—which you don’t even want to allow for must numeric types anyway—and which you can simulate by replacement with modification. This seems like a really good trade off and it’s a little surprising that more languages don’t make it.

> C++ templates and just allow whatever by textual substitution

The Julia approach is indeed elegant. An in-between position taken by F# is statistically resolved type parameters, where type safety is maintained and semantics largely preserved by constraints on members. It's a pain to write but trivial to consume though errors can be obstruse. More type level flexibility on the CLR (which seems to be planned) will further improve things when it comes to generic programming.

Because people in that game value simplicity of use over anything else (performance, safety, maintenance) and Python is a top performer in that KPI while Java is not very good at this (though it is getting better but still)

This is a big part of it. People who are scientists write code that we would think is disgusting and don’t care that much about abstraction outside of mathematical functions. There’s a lot to learn with Java. I helped classmates in my intro to programming class when I went to college, because I already knew how to code, and I have no idea why they picked that language as an introduction language. After weeks people were still struggling because on top of the ideas like loops/variables/control flow now they are having to learn classes.

Python was written with people like scientists in mind. Professionals write fast C libraries and then people who know just enough to get by use python to glue it all together.

> People who are scientists write code that we would think is disgusting and don’t care that much about abstraction outside of mathematical functions.

- plenty of scientists write good code; I think the "scientist can't code" meme is harmful.

- most of the people that write PyTorch code aren't necessarily scientists - they're software developers (data scientists, ML engineers, research engineers, whatever title - but their main job is to write code)

> Python was written with people like scientists in mind.

Python had nothing to do with scientists when it started. It was written to be readable and easy to use and it started as a hobby project. It existed for over 15 years until the data science / ML ecosystem started growing around it.

I'd flip that meme slightly; it is true that scientists write shitty code...but it turns out computer scientists do exactly the same, and with less humility.

The difference is programmers write shitty abstractions to abstract shitty code

I should have been more clear, I didn’t mean python was written for scientists I meant it was designed with simpler syntax so people can pick it up and write a script in a few hours, scientists need to do some simple algorithm so they use python instead of fighting with a language with more terse syntax. People wrote their math libraries for python because it was a simple language (on the surface) with a C api. It was at the right place at the right time.

> Python was written with people like scientists in mind.

Having just taught a bunch of scientists Python, I'm skeptical of this.

Stuff that is obvious to me, but really hard to explain to coding beginners:

* why `len(list)` but `str.join(...)`? I.e. why are there two ways to call functions?

* why does `[]` do so many different things? List comprehensions, list construction, subsetting, sometimes it secretly calls a method....

* why in the name of god is the first row called 0?

* and then why does [0:3] mean rows 1, 2 and 3, not rows 0, 1, 2, 3 or 1, 2, 3, 4?

* ... except in pandas where sometimes [foo:bar] includes bar...

* in general, why is pandas so damn complex?

I thought it'd be easier to teach than R, but I'm not quite so certain now.

For once it's impossible to work in Java without an IDE and without creating a project.

But you can just write a simple 20 line Python script to do some data mangling, no project with 30 IDE files required.

Between 1996 and 1999 there were hardly any IDEs available for Java outside Windows, and Forte was Solaris only.

Visual J++, Visual Cafe and JBuilder were the main ones but not everyone was eager to buy them, while the JDK was free beer.

The main reason is that a lot of scientific computing depends on ancient libraries written in Fortran or C, and a lot of newer libraries depend on GPUs for their matrix operations so need to be able to make calls to C/C++ modules that run directly to the GPU. This probably isn’t impossible for Java but that was never meant to be it’s niche, it doesn’t compile to machine instructions and prefers portability.

I know FFI in Java is certainly possible and I’ve seen it at least a few times personally; is it that much harder than in Python or just less common due to the need?

Python doesn’t compile to machine instructions either and there’s nothing that prevents GPU access from Java. In fact I’d bet in many cases pure Java beats Python + C library though it obviously depends on how much has to be written in pure python.

no data types, no operator overloading, no extendability of new functions to existing objects, no C/Fortran interop, mediocre performance. Need I go on?

Also no (official) REPL.

Actually Java has had a repl called Jshell since JDK 9.

The Julia crowd really need to hang less value on the REPL - people writing serious production code don't use one, and scientists using Python have moved on to notebooks. At this point, having Julia be so focused on the REPL is a weird affectation.

Julia has great notebook support, the Ju in Jupyter stands for Julia after all. There's also the fantastic Pluto.jl for reactive notebooks.

And the VSCode extension isn't quite IDE level, but that's just a matter of resources.

IMO, the REPL is really nice for exploration. I would never write code in it, but it serves as a really good doc search tool and quick way to check things. It helps that the Julia REPL is more inspired by the Lispy ones than python/R.

I used notebooks when I did my PhD using Python, but have moved to the REPL using Julia on my PostDoc. The Julia REPL experience is so much nicer than Python's, it removes the need for notebooks completely for me.

I'm a scientist, I use REPL a ton. Notebooks are fine too, but there's a thing called exploration and nothing beats REPL speed for that.

In future it would be great to mashup something like repl.it with Jupyter notebooks, maybe with Medium-style wysiwyg. That might really win.

Mediocre performance compared to what?

Julia is designed with interactive use and REPL in mind. Java is designed with enterprise software written by large teams and IDEs in mind. The first one, among other things, leads to valuing terseness. The seconds leads to valuing verbosity. I wouldn't want to deal with the usual Java boilerplate in an interactive session.

Java falls apart on the point about post factor extensibility.

See this talk for examples: https://www.youtube.com/watch?v=kc9HwsxE1OY

one day OCaml will win ;-;

Not with its Unicode handling.

Reply on news.ycombinator.com