Hello,
Joining the group just to respond to this...
On Tuesday, February 11, 2014 10:20:38 AM UTC+7, Stefan Karpinski 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.
>
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 –
> 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
