Hacker News Reader

Comment by pjmlp | Hacker News Reader

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.

Reply on news.ycombinator.com