Julia introspects: see the AST, LLVM IR, and native assembly for any function (opens in new tab)

Regarding Dylan, there are many similarities, but I'm not a Dylan expert so take it with a grain of salt (or some fact checking).

Both languages are fully dynamic and support multiple dispatch. But whereas Dylan opted to have both single and multiple dispatch, as well as dynamic and static dispatch, Julia only has one kind of dispatch: full dynamic multiple dispatch.

I'm not sure how Dylan passes variables and whether it separates reference types and values types, but Julia doesn't, instead opting to distinguish immutable versus mutable types. Immutables have many of the benefits of value types for the compiler, plus a few more. Mutable and immutable values have identical semantics other than that fact that you can't change an immutable value, which makes the programming model much simpler (all values have reference semantics), while giving the performance of value types for immutables since the compiler is free to pass them by value when it sees fit.

I believe Dylan allows you to inherit from concrete types by structural inheritance – i.e. tacking fields onto the fields of the parent type. in Julia all concrete types are final – you cannot inherit from them. I haven't found that tacking fields onto a structure is all that useful; sharing behavior is far more useful than sharing structure, and delegation is generally a better way to share structure.

Abstract types in Julia are essentially what OO researchers call traits: abstract types that you can program to. I don't think that Dylan has traits. These are crucial to much generic programming (the other kind of generic programming is writing generic code for parametric types; although these are actually the same thing in Julia).

Dylan supports multiple inheritance, while Julia does not. We might add multiple inheritance in the future – or not: so far it's not terrible to live without it, although there are a few places where it might be nice. In the meantime, duck typing will suffice, and once the standard library is complete and stable it will be much easier to assess if we really need multiple inheritance or not; if the standard library doesn't need it, I think the rest of the world can live without it.

The biggest philosophical differences seem to stem from:

1. Dylan was created in a time when OOP was new and hot and had to be included; Julia doesn't really care much about OOP – generic and functional programming are much more important.

2. Dylan tends to give you lots of options (e.g. single or multiple dispatch, static or dynamic), whereas Julia tends to give you a single option, but it's the most powerful one (only dynamic multiple dispatch). This keeps the language simpler and easier to learn and use, but no less powerful.

The introduction in the documentation implicitly answers this question: http://docs.julialang.org/en/release-0.1-0/manual/introducti...

In short, they are looking to be the go-to language for scientific and high performance computing. Programmers in that domain will have some expectations, and S-expressions are not it. They also consciously mimicked Matlab's syntax.

While it's certainly possible to write numerical code in S-expressions, it's often not very pleasant. Compare Julia's "2x^3n - 2y^2 + 1" with the S-expression for the same:

  (+ (- (* 2 (^ x (* 3 n))) (* 2 (^ y 2))) 1)

(I think I got that right.) Which would you rather write – or read? Mathematical notation and code tend to lean rather heavily on syntax to lessen the mental burden on the programmer. It's far less egregious but I also prefer `f(x)` to `(f x)`.

In general, we all felt that basic Matlab syntax is pretty good for numerical programming and linear algebra and would actually be fine if you got rid of some of the weirder choices (like indexing with parens and required trailing semicolons).

It appears that this post seems have been interpreted as questioning the design choice of infix vs prefix. I do think that infix is far easier to deal with, and that the array slicing syntax is a joy; what I meant was more about how picking a infix-y datastructure (like Julia) for storing expressions, would seem to limit one's ability to manipulate them ?

I thought the only reason lisp's macros were as powerful, was because one didn't spend all his time parsing stuff.

not really an answer, but there was lush - http://lush.sourceforge.net/ - in that space, and it never really caught on.

update: actually, it moved, and there was a release in 2011 - http://sourceforge.net/p/lush/news/

BBN Lisp had context sensitive error correction at least four decades ago. It was called the DWIM (Do What I mean) facility. It operated (in 1971) on unbound atoms and undefined function errors. If you misspelled a function name, typed an 8 or 9 instead of a left or right parenthesis, or typed an extra parenthesis, and then ran the incorrect code, the DWIM facility was called to help you. If you ran DWIM in "Trusting" mode, then changes would be made for you automatically. If you ran it in "Cautious" mode, you would be prompted to confirm proposed changes. If you didn't respond to the suggested changes within a certain time limit, the changes were made for you. BBN Lisp also had an "UNDO" function undid the side effects of any specific event, so there was no danger of it DWIM permanently munging your code. If you misspelled a command in the REPL (e.g PRETTYPRNT instead of PRETTYPRINT), the DWIM would understand that it was a misspelling and would then execute the right command.

BBN Lisp Manual (see section 17, which starts on page 335):

http://www.softwarepreservation.org/projects/LISP/bbnlisp/Te...

Yes, certainly, our current REPL is somewhat inflexible, but the (fully functional, but not something we want to drop in last minute - probably next release cycle) version of the REPL in the REPL.jl package as well as the IJulia Notebook already do some of this for e.g. completion of fields of a composite type.

If you're interested you can see the code for that completer here: https://github.com/loladiro/REPLCompletions.jl/blob/master/s...

btw, what ide or editor are people using with julia?

The problem I find is that graphical trees don't scale. They turn into a splayed out mess that is difficult to skim visually.

Personally, I'd far rather see a textual dump, with nesting denoted by indentation.

Such a tool has been written and I've been trying to convince the author to open source it, but if that doesn't work out I might have a go at it myself. We can already look at the LLVM-level calling graph since llvm includes functionality to output GraphViz dot code.

We're currently working on documentation. I assume you're talking about the reflection section? There's issue https://github.com/JuliaLang/julia/issues/2886 open about that and it will probably be addressed by the end of the week (since it's tagged for 0.2).

This actually wasn't the kind of reflection I had in mind when I put that stub header in there, but it certainly does belong. I was thinking more along the lines of traditional "what fields does this data type have?" reflection. But yes, large parts of this would be good to have in the manual.