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.


On Mon, Feb 10, 2014 at 6:51 AM, Gour <g...@atmarama.net> wrote:

> 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
>
>
>

Reply via email to