Comment by ScottBurson | Hacker News Reader

Comment by ScottBurson | Hacker News Reader

Parent Full thread

There is a lot to like about Julia. It's obviously heavily influenced by Common Lisp. I see offhand only one thing I really don't like: they are using object semantics rather than value semantics for arrays. So for example:

  A = [0, 1, 2, 3]
  B = A
  A[1] = 2
  // now B[1] == 2

Their manual section on arrays says this:

In Julia, all arguments to functions are passed by reference. Some technical computing languages pass arrays by value, and this is convenient in many cases. In Julia, modifications made to input arrays within a function will be visible in the parent function.

but as the above example shows, it's really the semantics of assignment we're talking about here, not just that of function calls.

I believe that value semantics is easier to understand and less bug-prone, particularly for nonexpert programmers. It can also be implemented well enough that the small efficiency cost is worth paying in most cases. For one take on how to do this, see my my FSet functional collections library for Common Lisp[0]. For another, see the Clojure collection types.

[0] http://common-lisp.net/project/fset

Using value semantics for arrays is lovely in concept but ends up being really annoying and impractical for writing really high-performance array code. This is one of the most common complaints of library authors attempting to write fast, efficient code in Matlab and is one of the many reasons why one ends up having to write all performance-critical code in C using Matlab data structures.

Clojure is reputed to get remarkable performance on a broad variety of data structures, but I've had a hard time finding benchmarks comparing Clojure's purely functional arrays with normal linearly indexed arrays – if you have some references to such comparisons, I'd love to see them. In my experience, nothing beats a plain old linearly indexed, mutable array when that's what you need. Making that basic structure unavailable in a language intended for high-performance numerical computing strikes me as utterly perverse.

Clojure gets great performance with its immutable data structures, but no one pretends they're as fast as plain native java arrays or using mutation. It's normal in the Clojure community to drop down to using arrays or transients (http://clojure.org/transients) in high performance functions and then convert the result back to an immutable data structure. As long as you still present a pure interface, no one knows or cares what kind of mutation you do internally.

Oh, I wouldn't suggest making plain old mutable arrays unavailable. I totally agree that library authors and sophisticated users need access to them (and preferably not by dropping into C).

I just think the array and other collection types presented to users for ordinary application-level programming should be functional. Mutable types should stay in an "advanced topics" section of the manual.

That's a bad an completely not intuitive trade-off for a language that is expected to be fast.

I've first studied Julia today, but just by knowing its niche I already expected it to use reference semantics, not value. It'd be quite confusing if the examples demonstrated otherwise.

As long as it's not exceedingly difficult to drop down to using mutation, having immutability by default is ridiculously nice. I don't think I appreciated it fully until I used Clojure a significant amount, but using languages with reference semantics feels disgusting now.

Iirc clojure lets you get your hands on a mutable array for performance via the transient keyword. The contract is such that you can do what you want (fast things) in the transient block, but it's a black box to outside callers who never see the array in its mutable form. Ie the function is still a pure function since no side effects leak.

http://clojure.org/transients

I'm going to nitpick horribly here: in Clojure, an array is just a Java array. But what most people use are vectors, which are immutable. 'transient' returns a mutable vector, not an array.

The Julia team has made it a convention to end functions with a '!' that alter your input variables.

http://docs.julialang.org/en/latest/stdlib/base/ (4th point)

I love the Clojure collection types: basing a whole language around persistent data structures is an unbelievable win.

There is a library for Julia that adds collection types similar to Clojure's[1]. My understanding is it's not very thoroughly optimized right now, but it could be a promising place to look if lack of persistent data structures is keeping you away from Julia.

[1] https://github.com/zachallaun/FunctionalCollections.jl

I teach scientific programming and this is always the point in the class where the students really start to appreciate the tradeoffs between speed/efficiency, and readability. Passing around large arrays and matrices by value is much more readable, but obviously slower and less efficient than passing by reference, which is in turn more difficult to keep track of, if you're used to languages like matlab and octave.

This is also the point in our introduction to python and scipy/numpy where they realize, if they have to contend with passing by reference in this "high level language" then why to just contend with it in C and be 400x as fast?

Python is typically more like 40x slower than C, not 400x.

Passing arrays by reference really just isn't that big of an issue in practice. We tend to write both non-mutating and mutating versions of most array functions, distinguished by whether they end in ! or not. Typical development procedure is to write an algorithm using non-mutating APIs and get that right; then you figure out where argument copying is slowing things down (using e.g. the built-in profiler) and modify the code to avoid copying, sometimes by simply adding a ! or sometimes by pre-allocating some work array and using a mutating function on it. Compare this with a similar scenario in Matlab where there simply is no straightforward way to avoid copying – if the JIT is clever enough to avoid copying you're in luck, but often it's not that smart and you're forced to live with the copying or drop into C.

I've never used Matlab and know little about it, but in general, there are much better ways to implement value semantics than by copying entire collections. Clojure's collections probably reflect the state of the art here. You might also find Chris Okasaki's book on functional data types of interest (I think Clojure's sequence type was been borrowed from Okasaki).

FSet does it with balanced binary trees, which gives log-time update and log-time indexing, which are acceptable for many applications but not the best you can do for sequences.

Representing vectors, matrices or general arrays as anything other than a single contiguous chunk of inline values is a complete non-starter for numerical work since you can't call BLAS, LAPACK, FFTW or any other high quality numerical library on e.g. Clojure's vectors. Without those libraries, you lose many orders of magnitude performance on crucial operations like matrix multiplication.

The problem is that for arrays, most non-trivial datastructures have a high cost because of indirection. Memory is already the main bottleneck in many numerical operations, and adding pointers is often terrible for memory performance.

For arrays, even large, reasoning in terms of O(N) for access patterns is useless, because the constants are what matters.

Reply on news.ycombinator.com