

Julia introspects: see the AST, LLVM IR, and native assembly for any function - astrieanna
http://blog.leahhanson.us/julia-introspects.html

======
haberman
This is very cool, and a direction that I hope more toolchains will go.

One problem, though, is that reading trees in text format is not very easy on
the eyes. In fact, this might be one of the biggest reasons that LISP is (to
people like me) not very readable. Trees in graphical form are orders of
magnitude easier to parse visually.

I'd love to see software that makes visualizing tree structures easier. At one
point I had a grand plan of porting graphviz to JavaScript, with SVG as an
output format so it could be easily styled with CSS.

I think that approaches like this will be a lot more usable (and deliver a lot
more "wow" factor) if you can view the trees graphically.

~~~
ori_b
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.

------
susi22
One thing that this kind of low level "interface" allows is a very rapid
development of coding tools. How long until we see a context-context sensitive
auto completion pop up? These language features would even allow more complex
hints. Language analyzers can find bugs and note them right when writing code.

Of course, this is nothing new and already done in a few languages. But these
features will make it easier (and hence faster) for the IDE to have some
awesome coding features.

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

~~~
KenoFischer
Mostly vim, emacs and sublime (there's plugins for all of those). The folks at
forio have also started an IDE for Julia, but last I looked they didn't have
much more than an editor (and their website hasn't been updated in a couple
months, so I'm not sure what the status is).

------
stevengj
A footnote mentions that @which is not as helpful for functions defined the
REPL, because it doesn't give a file and line number in that case. This is not
the case, however, in the new IJulia notebook interface (a REPL based on the
IPython notebook); there, each multiline input cell is named "In[nnn]" (like
Mathematica) and is treated like a file, so you can type "@which foo(3)" and
it will give "foo(x) at In[22]:1" if you defined foo on line 1 of input
In[22].

Note also that, in the latest versions of the REPL (and IJulia), you can
simply type "? foo(3)" instead of "@which foo(3)".

------
enupten
I'm not implying that their expression data structure is in anyway deficient,
but given that Julia is so lispy in the first place, why was a design decision
made to abandon (the more readable/familiar ?) S-expressions ? Can one of the
devels give us an insight ?

Edit: Can someone also comment on how Julia compares to Dylan in the semantic
sense ?

~~~
StefanKarpinski
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.

~~~
BruceM
Dylan doesn't have both single and multiple dispatch. Any method call is going
to be using multiple dispatch.

Dispatch is dynamic, except where the compiler has determined (perhaps with
hints from the programmer in the form of sealing) that it can be optimized
into a static dispatch. One mode of the compiler extends this to help further
eliminate runtime dynamic dispatch but that isn't enabled currently (as we
aren't sure of the state of that code).

Dylan's OO isn't traditional OO at all in that it isn't like Java, Smalltalk,
C++, Python, etc. Instead, it is CLOS-style OO. I wouldn't say that it was new
and hot and had to be included as the OO in Dylan is a direct descendent of
what was already in Common Lisp and going back from there to Flavors from
Symbolics on the Lisp Machine and so on. (In fact, some of the same people
were responsible...)

As for #2, I don't really see that at all. Dylan has a very intelligent and
hard working compiler that tries to let you have the freedom that you want,
but still be able to make things run efficiently. After all, it was targeted
originally at hardware from 15-20 years ago.

I'm not a Julia expert, so I won't try to address the other points.

~~~
StefanKarpinski
Thanks for the corrections, Bruce. As I said – I'm no Dylan expert.

------
andrewcooke
maybe this could go in the blank space under "introspection" in the current
manual? just sayin... [edit: sorry, yes, reflection]

(julia is my new crush. i haven't actually used it yet, i just keep reading
the docs and thinking how awesome it all sounds).

~~~
KenoFischer
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](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).

