s/incredibly/highly/g – I got a little overly enthusiastic with my adjectives.
On Mon, Feb 10, 2014 at 10:20 PM, Stefan Karpinski <[email protected]>wrote: > 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 <[email protected]> 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 >> >> >> >
