Hacker News Reader

Comment by peatmoss | Hacker News Reader

Julia (runner up R) feel like the lispyest non-lisps to do serious numerical work in. Julia’s at the point where it has some best-in-class libraries as well as some frustrating blind spots.

With Julia I can almost pretend I’m using a straight-up lisp. The multiple dispatch in Julia is quite nice and is sort of “the big idea” that Julia uses to be so magical.

View on HN

Similar to Dylan's experience, sadly Apple canned it and it never got that much uptake afterwards.

However there is OpenDylan for anyone that would like a go at it, including the old book describing the language.

I’ve heard people talk about how similar Dylan and Julia are for a long time, but have never used Dylan myself. Are there any things that are standouts for Dylan as compared to Julia that are worth checking out?

I feel like Julia is pretty great, and has a good amount of inertia behind it in the domains that I frequent, but I’m curious about (Open)Dylan from the perspective of someone who’s used both.

I feel like Dylan is much more dynamic and OO than Julia. I don’t think there’s a way to have parameterised types (like generics in Java or C#) and a lot of the arguments for Julia’s type system are about being able to generate efficient code by being informed by the types. The parameterising complicates the subtyping relationships needed to specify how multiple dispatch works.

Sorry, maybe I'm misreading your comment, but are you saying that julia doesn't have parameterized types? If so, that's untrue, but maybe you're saying Dylan doesn't have parameterized types? It's a little unclear in the text.

> The parameterising complicates the subtyping relationships needed to specify how multiple dispatch works.

I don't think it adds all that much complication actually, and it adds a ton of extra expressive power. For instance, our arrays are parameterized by their element type and their dimensionality, so

    Array{Int, 1}

is a 1D (vector) array of Ints whereas

    Array{Complex{Float64}, 2}

is a 2D (matrix) of Complex Float64s. This is really important for making the most of multiple dispatch imo because I can write methods which take advantage of as much type information as possible. This isn't just helpful for performance, but also helpful for just expressing your algorithm in a clear and general way.

Dylan doesn't have parameterized types.

You can get around it with multi-methods.

When I last wrote Julia I think it was unclear to me how subtyping worked with type parameters, or writing type specifiers for methods was complicated by them. I think all type constructors are invariant, so you couldn’t have T{X} < T{Y} unless X = Y (but I think you can have a rule like S{X} < T{X}). This makes sense in some cases as covariance or contravariance don’t work for arrays (suppose I want an Animal array but you give me a Dog array, then when I read elements I get Animals as expected but if I were to try to write a Cat there, it would be bad. Java has this rule and will throw a runtime extension in the case described), but it can work for immutable types, though Julia can’t enforce that all subtypes are immutable and type parameters needn’t be types anyway.

For many blindspots you can use PyCall (https://github.com/JuliaPy/PyCall.jl).

Reply on news.ycombinator.com