Julia vs Dylan

[Gour]

Hello,

while reading different stuff about Julia I did stumble upon its
Wikipedia page (http://en.wikipedia.org/wiki/Julia_%28programming_language%29)
where there is table comparing Julia with Common Lisp, Fortress and
Dylan.

I'm not interested neither for Lisp nor for Fortress (which anyway seems
to be not alive), but wonder how does Julia compare with Dylan in
general.

Afaik, one of the differences is that Julia JIT-ed, while Dylan produces
native executables which might impact the performance for end user.

Anything else which might be important to know and/or some reasons why
the creators of Julia were not e.g. happy with Dylan (amongst many other
languages) and pursued designing Julia?

In the past I was playing with Haskel, but found that there is too much
monad talk and the language had too steep learning curve for some of
potential contributors to the project - multi-platfom GUI (desktop) app.

Later I was evaluating D, Ada, OCaml, F#, Nimrod, Rust...some are nice
languages, but most are lacking bindings for developing GUI desktop
applications and/or are more suitable as 'system' and not 'general
programming' language, iow. fiddling with low(er)-level stuff like
pointers etc. - we want to avoid C(++) - or have strange syntax like Rust.

Iow. we're looking for some 'general programming' language suitable for
desktop app which is has good-enough performance and provide more
type-safety than e.g. Python (we have to call 3rd party lib for
computing planetary ephemeris and would like to use sqlite3 as app's
storage format).

I saw a thread which 'claimed' that e.g. Julia is e.g not quicker than
Python/Cython although it seems it was due usage of int32.

So, anyone somewhat familiar with boh Julia & Dylan can share what would
be some of the Julia's advantage(s) to choose it over Dylan?

Are there some major features missing in either language which I am not
seeing or the two can't be easily compared at all?


Sincerely,
Gour

[Stefan Karpinski]

This post might be inappropriate. Click to display it.

[Stefan Karpinski]

s/incredibly/highly/g – I got a little overly enthusiastic with my
adjectives.

Post by Stefan Karpinski
We were never directly influenced by Dylan. As far as I know, neither Jeff
nor Viral nor I have done any Dylan programming. Any linguistic
similarities are due to common influences (e.g. Lisp, Pascal, Algol),
convergent design, or coincidence. I'm not sure what the reasons were for
Dylan choosing multiple dispatch, but for us it was a necessity to be able
to cleanly express the polymorphic behaviors that are rampant in numeric
programming. As the wikipedia page details, Dylan doesn't have parametric
types, which means, among other things, that you can't have a generic array
type that allows arrays that can only contains values of a particular
element type. In particular, that means that you can't store such an array
in C/Fortran-compatible form, which is a non-starter for numerical work
since that's the layout that all the numerical libraries expect. Not being
able to call BLAS is a show-stopper for technical computing. There are many
other benefits from both multiple dispatch and parametric types, and Julia
is unique in having the combination of (1) a dynamic type system, (2)
generic functions by default, and (3) parametric types that you can
dispatch on.
The fact that Julia is jitted is technically an implementation detail –
there's nothing that prevents Dylan and other languages from doing the same
thing (JavaScript and Lua both have excellent, fast production-quality jit
implementations that were built long after the languages were created).
That said, Julia's implementation has been jitted from the start, so its
design is particularly amenable to jit compilation and efficient execution
in general. I also personally find Dylan's syntax to be unfortunately
verbose, and feel that some of the object-oriented aspects of the language
are overly "featurey". It's kind of a shame, imo, that Dylan didn't stick
with its original S-expression syntax and adopt less of the object-oriented
thinking of the time.
The distinguishing factor between Julia and Python + Cython isn't
performance (the difference in that thread was, in fact, due to 32-bit vs.
64-bit arithmetic). Rather, it's the fact that Cython is thinly veiled C
programming that just happens to be embedded in Python with some clever
glue. Some people seem to love Cython, but there are many others who would
rather just write their performance critical code in C using CPython's
internal APIs. Cython is *not* Python code that runs fast. This isn't just
a nitpick: whereas Python code is highly polymorphic, Cython code is
inherently monomorphic just like C. You can write Cython code that is fast
or Python code that is generic, but you can't have both. In Julia, on the
other hand, it is perfectly standard to write very generic, abstract code
that runs fast. Even really basic things like adding an Int and Float64 are
handled via an incredibly abstract promotion mechanism.
[The sorting API <http://docs.julialang.org/en/latest/stdlib/sort/> is
another great example of this. It is incredibly generic: you can apply all
of these functions to arrays with different element types, use different
orderings of values, and different sorting algorithms – all in a way that's
completely composable. Plugging in a new sorting algorithm into the API is
trivial<https://github.com/JuliaLang/SortingAlgorithms.jl/blob/bf1e0f40b7581bff75223dbf45a89a32a8064eaf/src/SortingAlgorithms.jl#L22-L39>.
Yet it all runs as fast as if you'd written custom C code for that
particular combination of array element type, ordering, and sorting
algorithm. On top of that, the implementation of all of this is really clean
and simple <https://github.com/JuliaLang/julia/blob/master/base/sort.jl>.]
In general, it's unclear to me exactly what you're looking for. If you
want to build a portable GUI app and numerical work and performance isn't
really a big concern, Python seems like a sensible, mature choice. If you
only need a bit of performance here and there, you may be able to do what
you need with Cython, CPython's C API, and NumPy. Julia's GUI libraries are
nowhere near as mature, so if you choose Julia, you're going to be doing
some bushwhacking and building things yourself. On the other hand, Julia's
community is very active and responsive and the language itself is *very*
productive, so it may be easy enough build out the things that you need.

Post by Gour
Hello,
while reading different stuff about Julia I did stumble upon its
Wikipedia page (
http://en.wikipedia.org/wiki/Julia_%28programming_language%29)
where there is table comparing Julia with Common Lisp, Fortress and
Dylan.
I'm not interested neither for Lisp nor for Fortress (which anyway seems
to be not alive), but wonder how does Julia compare with Dylan in
general.
Afaik, one of the differences is that Julia JIT-ed, while Dylan produces
native executables which might impact the performance for end user.
Anything else which might be important to know and/or some reasons why
the creators of Julia were not e.g. happy with Dylan (amongst many other
languages) and pursued designing Julia?
In the past I was playing with Haskel, but found that there is too much
monad talk and the language had too steep learning curve for some of
potential contributors to the project - multi-platfom GUI (desktop) app.
Later I was evaluating D, Ada, OCaml, F#, Nimrod, Rust...some are nice
languages, but most are lacking bindings for developing GUI desktop
applications and/or are more suitable as 'system' and not 'general
programming' language, iow. fiddling with low(er)-level stuff like
pointers etc. - we want to avoid C(++) - or have strange syntax like Rust.
Iow. we're looking for some 'general programming' language suitable for
desktop app which is has good-enough performance and provide more
type-safety than e.g. Python (we have to call 3rd party lib for
computing planetary ephemeris and would like to use sqlite3 as app's
storage format).
I saw a thread which 'claimed' that e.g. Julia is e.g not quicker than
Python/Cython although it seems it was due usage of int32.
So, anyone somewhat familiar with boh Julia & Dylan can share what would
be some of the Julia's advantage(s) to choose it over Dylan?
Are there some major features missing in either language which I am not
seeing or the two can't be easily compared at all?
Sincerely,
Gour
--
In this endeavor there is no loss or diminution,
and a little advancement on this path can protect
one from the most dangerous type of fear.
http://www.atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810

[Gour]

On Mon, 10 Feb 2014 22:20:38 -0500

Post by Stefan Karpinski
We were never directly influenced by Dylan. As far as I know, neither
Jeff nor Viral nor I have done any Dylan programming.

This is really interesting info.

Post by Stefan Karpinski
Any linguistic similarities are due to common influences (e.g. Lisp,
Pascal, Algol), convergent design, or coincidence.

I did (Turbo) Pascal many years ago, but was, unfortunately, never
exposed to Lisp (in the last moment the course moved to Prolog instead.)

Post by Stefan Karpinski
As the wikipedia page details, Dylan doesn't have parametric types,
which means, among other things, that you can't have a generic array
type that allows arrays that can only contains values of a particular
element type.

Hmm, righ. That's cool features and brings nice type-safety to the whole
application.

Post by Stefan Karpinski
In particular, that
means that you can't store such an array in C/Fortran-compatible
form, which is a non-starter for numerical work since that's the
layout that all the numerical libraries expect.

I'm not 100% clear I got this one, maybe due to not being familiar with
numerical libs.

Post by Stefan Karpinski
The fact that Julia is jitted is technically an implementation detail
– there's nothing that prevents Dylan and other languages from doing
the same thing (JavaScript and Lua both have excellent, fast
production-quality jit implementations that were built long after the
languages were created). That said, Julia's implementation has been
jitted from the start, so its design is particularly amenable to jit
compilation and efficient execution in general.

Do you find that native executables (like the one provided by Dylan) are
not (much) superior peformance-wise due to it? (I know that Lua has
great jit, but never played with it.)

Post by Stefan Karpinski
I also personally find Dylan's syntax to be unfortunately verbose, and
feel that some of the object-oriented aspects of the language are
overly "featurey". It's kind of a shame, imo, that Dylan didn't stick
with its original S-expression syntax and adopt less of the
object-oriented thinking of the time.

I must say that I like Julia's clean syntax and, in general, like FP
approach more than OOP.

Post by Stefan Karpinski
The distinguishing factor between Julia and Python + Cython isn't
performance (the difference in that thread was, in fact, due to
32-bit vs. 64-bit arithmetic). Rather, it's the fact that Cython is
thinly veiled C programming that just happens to be embedded in
Python with some clever glue. Some people seem to love Cython, but
there are many others who would rather just write their performance
critical code in C using CPython's internal APIs. Cython is *not*
Python code that runs fast. This isn't just a nitpick: whereas Python
code is highly polymorphic, Cython code is inherently monomorphic
just like C. You can write Cython code that is fast or Python code
that is generic, but you can't have both. In Julia, on the other
hand, it is perfectly standard to write very generic, abstract code
that runs fast.

Yeah, that's right. Mixing those 2 languages is bad marriage -
abstraxction leaks.

Post by Stefan Karpinski
Even really basic things like adding an Int and Float64 are handled
via an incredibly abstract promotion mechanism.

I saw one of those MIT videos - nice ModInt example. Cool stuff. ;)

Post by Stefan Karpinski
In general, it's unclear to me exactly what you're looking for. If you
want to build a portable GUI app and numerical work and performance
isn't really a big concern, Python seems like a sensible, mature
choice. If you only need a bit of performance here and there, you may
be able to do what you need with Cython, CPython's C API, and NumPy.

I'm not sure whether my app is falling into the category of 'technical
computing', altough I believe it does.

We're interested to build Vedic astrology program (something like
http://saravali.de/screenshots.html) for which we need to call 3rd party
C library (http://www.astro.com/swisseph/swephinfo_e.htm?lang=e) which
calculates planetary ephemeris (based on NASA's JPL data).

On top of that, we need to write custom libraries (preferrably in native
(e.g. Julia) language) and then the GUI part of the app consists of
accepting user's input data, perform different calculations and render
result on the screen. There is some animation involved (for
simulations), then some calculus (finding extremes of functions etc.).
All that should be ready to operate with lot of data from the database
(plan is to use sqlite3) so that app can be, besides calculation, used
for research purposes as well.

Considering that some similar apps which started in Python were
abandoned to speed reasons (some moved to C++) and that I prefer
spending my time with some pleasant higher-level language instead of
fiddling with pointers' bugs, I tend to feel Julia might be great
candidate since, afaict, offers less steep learning curve (in comparison with
e.g. OCaml/Haskell) to program desired functionality with decent
performance or as you put on your slide:

power = performance / effort

Post by Stefan Karpinski
Julia's GUI libraries are nowhere near as mature, so if you
choose Julia, you're going to be doing some bushwhacking and building
things yourself.

I'm aware of it and that's why I asked about Qt bindings in devel list.

Otoh, do you believe Julia will become attractive to build GUI apps,
iow. to become first class general purpose prog. lang.?

Post by Stefan Karpinski
On the other hand, Julia's community is very active and responsive and
the language itself is *very* productive, so it may be easy enough
build out the things that you need.

That's very strong point - I see that Julia is building momentum,
community is much bigger than Dylan's, active development, etc.

Well, yesterday I built Julia on my Free/PC-BSD-10.0, but it was
complaining (gmake[2]:
/usr/home/gour/repos/external/julia/contrib/relative_path.sh: Command
not found) 'cause I use fish shell and there is no /bin/bash on my OS,
but I'll try to play with it more and see how it goes.

Thanks a lot for very elaborate reply and for being part of the team
designing very human language to help those who are not pro-coders to
have very valuable tool to accomplish their goals. It's very noble
achievement!

Post by Stefan Karpinski
s/incredibly/highly/g – I got a little overly enthusiastic with my
adjectives.

No problem, it's appreciated here. ;)


Sincerely,
Gour

[Bruce Mitchener]

Hello,

Joining the group just to respond to this...

Post by Stefan Karpinski
We were never directly influenced by Dylan. As far as I know, neither Jeff
nor Viral nor I have done any Dylan programming. Any linguistic
similarities are due to common influences (e.g. Lisp, Pascal, Algol),
convergent design, or coincidence. I'm not sure what the reasons were for
Dylan choosing multiple dispatch, but for us it was a necessity to be able
to cleanly express the polymorphic behaviors that are rampant in numeric
programming. As the wikipedia page details, Dylan doesn't have parametric
types, which means, among other things, that you can't have a generic array
type that allows arrays that can only contains values of a particular
element type. In particular, that means that you can't store such an array
in C/Fortran-compatible form, which is a non-starter for numerical work
since that's the layout that all the numerical libraries expect. Not being
able to call BLAS is a show-stopper for technical computing. There are many
other benefits from both multiple dispatch and parametric types, and Julia
is unique in having the combination of (1) a dynamic type system, (2)
generic functions by default, and (3) parametric types that you can
dispatch on.

Dylan chose multiple dispatch as it was a descendent of Common Lisp and
CLOS (and shared some of the same language designers). Dylan took things
further by making the object system a core part of the language rather than
bolted on as CLOS was with Common Lisp.

As for parametric dispatch, Dylan lacks full support for parametric
dispatch, but your statements about not having a generic array type and the
conclusions that follow from that are unfounded.

Dylan supported limited types as described in our language specification:

http://opendylan.org/books/drm/Limited_Types

The limited collection types are what are applicable here:

http://opendylan.org/books/drm/Limited_Collection_Types

These fully support laying out data in memory efficiently. When using a
size limit, the compiler can also optimize away some array bounds checks
(when the right information is present). The capabilities of limited
collections are used pretty extensively. (We also use them for passing
data to OpenGL.)

Julia may or may not be unique in the way that you described. I don't know
enough about Julia to venture a statement regarding that. Dylan certainly
has supported much of what you described (although with limited rather than
full parametric types) for the last many years.

There was also a thesis written which had an implementation of a parametric
type system extension to Dylan and it can be found linked from our
publications page:

Extending Dylan’s type system for better type inference and error
detection
http://opendylan.org/documentation/#publications
https://dl.acm.org/citation.cfm?id=1869643.1869645

This was presented at ILC 2010.

You might also find this master's thesis by James Knight on the addition of
parameterized types to Goo from 2002 interesting:

http://people.csail.mit.edu/jrb/goo/james-thesis.pdf

The fact that Julia is jitted is technically an implementation detail –

Post by Stefan Karpinski
there's nothing that prevents Dylan and other languages from doing the same
thing (JavaScript and Lua both have excellent, fast production-quality jit
implementations that were built long after the languages were created).
That said, Julia's implementation has been jitted from the start, so its
design is particularly amenable to jit compilation and efficient execution
in general. I also personally find Dylan's syntax to be unfortunately
verbose, and feel that some of the object-oriented aspects of the language
are overly "featurey". It's kind of a shame, imo, that Dylan didn't stick
with its original S-expression syntax and adopt less of the object-oriented
thinking of the time.

Two things here ...

The Windows version of Open Dylan can compile and update code in a running
executable. This feature isn't yet available on other platforms for a
variety of reasons, but there's nothing about the design of things that
prohibits it. This really doesn't matter though. These are implementation
details as you said.

The "original" S-expression syntax was just as object-oriented (and in the
same CLOS-like way) as modern Dylan is. The change in the syntax had
nothing whatsoever to do with how OO or not Dylan is. (And many would argue
that CLOS-like OO has little to do with the type of OO thinking that
flourished in the 1990s.)

Cheers,

- Bruce

[Stefan Karpinski]

Hi, Bruce!

Thanks for taking the time and effort to sign up for the list just to
correct my errors. I swear that I'm not intentionally spreading
disinformation about Dylan – my mistakes are purely due to ignorance, not
malice! Dylan is a great language.

Dylan's "limited types" do indeed appear to do the trick for allowing
efficient representation of numeric arrays (among lots of other cool
things). I was thrown off by the somewhat non-standard naming. Can you
clarify what distinguishes limited types from parametric types? Is it just
that the parameters are not considered part of the type, so you can't
dispatch on them? I had encountered Hannes Mehnert's thesis when looking
into this earlier, but obviously having a research implementation of a
non-standard feature doesn't count – by that criterion, Java has every
language feature ever invented.

My syntax and o.o. lamentations were really separate from each other. I
like the S-expression syntax better – I know, that's rich coming from a
designer of another language with clearly algol-derived non-S-expression
syntax. Completely unrelatedly, I also find some of the o.o.-related
aspects in Dylan too featurey. I mean things like slot and method
annotations – protected, private, `init-keyword: foo:`,
`required-init-keyword: bar:`, etc. There are a lot of these and it seems
like they can combine in a dizzying number of ways. I'm sure this is all
thoroughly documented somewhere and it works great, but it's just a lot of
*stuff*. The business of declaring attributes like this seems to have
started in Smalltalk and continued in most of its sphere of influence –
declaring this method to be virtual and that field to be private, etc. It
just strikes me as fiddly and that there are too many things that can
combine in too many ways. But like I said, this is a matter of taste.

Questions... Can one inherit from concrete types in Dylan, as you can in
most object systems? Is there a way to create user-defined immutable types?

Thanks again for stopping by!

Cheers,

Stefan


On Wed, Feb 12, 2014 at 4:29 AM, Bruce Mitchener

Post by Gour
Hello,
Joining the group just to respond to this...

Post by Stefan Karpinski
We were never directly influenced by Dylan. As far as I know, neither
Jeff nor Viral nor I have done any Dylan programming. Any linguistic
similarities are due to common influences (e.g. Lisp, Pascal, Algol),
convergent design, or coincidence. I'm not sure what the reasons were for
Dylan choosing multiple dispatch, but for us it was a necessity to be able
to cleanly express the polymorphic behaviors that are rampant in numeric
programming. As the wikipedia page details, Dylan doesn't have parametric
types, which means, among other things, that you can't have a generic array
type that allows arrays that can only contains values of a particular
element type. In particular, that means that you can't store such an array
in C/Fortran-compatible form, which is a non-starter for numerical work
since that's the layout that all the numerical libraries expect. Not being
able to call BLAS is a show-stopper for technical computing. There are many
other benefits from both multiple dispatch and parametric types, and Julia
is unique in having the combination of (1) a dynamic type system, (2)
generic functions by default, and (3) parametric types that you can
dispatch on.

Dylan chose multiple dispatch as it was a descendent of Common Lisp and
CLOS (and shared some of the same language designers). Dylan took things
further by making the object system a core part of the language rather than
bolted on as CLOS was with Common Lisp.
As for parametric dispatch, Dylan lacks full support for parametric
dispatch, but your statements about not having a generic array type and the
conclusions that follow from that are unfounded.
http://opendylan.org/books/drm/Limited_Types
http://opendylan.org/books/drm/Limited_Collection_Types
These fully support laying out data in memory efficiently. When using a
size limit, the compiler can also optimize away some array bounds checks
(when the right information is present). The capabilities of limited
collections are used pretty extensively. (We also use them for passing
data to OpenGL.)
Julia may or may not be unique in the way that you described. I don't know
enough about Julia to venture a statement regarding that. Dylan certainly
has supported much of what you described (although with limited rather than
full parametric types) for the last many years.
There was also a thesis written which had an implementation of a
parametric type system extension to Dylan and it can be found linked from
Extending Dylan’s type system for better type inference and error
detection
http://opendylan.org/documentation/#publications
https://dl.acm.org/citation.cfm?id=1869643.1869645
This was presented at ILC 2010.
You might also find this master's thesis by James Knight on the addition
http://people.csail.mit.edu/jrb/goo/james-thesis.pdf
The fact that Julia is jitted is technically an implementation detail –

Post by Stefan Karpinski
there's nothing that prevents Dylan and other languages from doing the same
thing (JavaScript and Lua both have excellent, fast production-quality jit
implementations that were built long after the languages were created).
That said, Julia's implementation has been jitted from the start, so its
design is particularly amenable to jit compilation and efficient execution
in general. I also personally find Dylan's syntax to be unfortunately
verbose, and feel that some of the object-oriented aspects of the language
are overly "featurey". It's kind of a shame, imo, that Dylan didn't stick
with its original S-expression syntax and adopt less of the object-oriented
thinking of the time.

Two things here ...
The Windows version of Open Dylan can compile and update code in a running
executable. This feature isn't yet available on other platforms for a
variety of reasons, but there's nothing about the design of things that
prohibits it. This really doesn't matter though. These are implementation
details as you said.
The "original" S-expression syntax was just as object-oriented (and in the
same CLOS-like way) as modern Dylan is. The change in the syntax had
nothing whatsoever to do with how OO or not Dylan is. (And many would argue
that CLOS-like OO has little to do with the type of OO thinking that
flourished in the 1990s.)
Cheers,
- Bruce