Dylan?

[klamath]

Has anyone used Dylan? It looks pretty neat -- check out this Dylan tutorial (http://www.gwydiondylan.org/gdref/tutorial/tutorial.html). It's functional (like derivates of Lisp or ML), has multiple dispatch, a powerful OO system, conventional (infix) syntax that doesn't look as weird as OCaml's, etc.

Man, yet another cool language to learn!

[bdg1983]

Is it just me, or are new languages popping up much faster now than they used to? Or has it always been like this?

[klamath]

Well, since Dylan was invented ~1994, so it's not exactly new. As for the popularity of "alternative" languages, I dunno. There's more server-side programming now, which often means you can use any language you want (whereas, if you're shipping binaries to a client for desktop deployment, you need to compile your app to native code and you can't depend on a runtime environment being present). I guess people are also starting to be a bit more dissatisfied with C and C derivatives: now that the performance of the average computer has increased enormously, it often makes sense to sacrifice some processing time to allow for faster development. 10 years ago, it would probably be infeasible to use an interpreted or byte-compiled language for commercial apps, just because of the performance penalty you'd need to pay.

[jemfinch]

I can't say Dylan interests me. First, it's dynamically typed. I've gotten
very used to the safety of a statically typed language that O'Caml
provides. Second, I don't believe it compiles to native code, which, while it's
not that important, is still a disadvantage it has versus, say, O'Caml or
LISP. Thirdly, syntax is really a non-issue at this point in my choice of a
programming language: I know several programming languages and don't really have
any problems learning a new syntax. Finally, and most importantly, Dylan
doesn't seem to offer anything new over what I already know. I haven't used
multiple dispatch, personally, but if I do want to use that, I'll probably pick
Common LISP, which has not only multiple dispatch (in CLOS) but also macros,
which are more interesting to me than any other programming concept I don't yet
have experience with.

So in short, I can't see what's interesting about Dylan.

Jeremy

[Gnu/Vince]

Jemfinch: why learn Common Lisp? Learn ELisp and customize your Emacs. I don't think that it would then be very difficult to switch from Elisp to CMUCL. Learning Elisp would be useful in your case.

[jemfinch]

Originally posted by Gnu/Vince:
Jemfinch: why learn Common Lisp? Learn ELisp and customize your Emacs. I don't think that it would then be very difficult to switch from Elisp to CMUCL. Learning Elisp would be useful in your case.

Elisp isn't a good LISP. It doesn't compile to native code; it's tied to a large interpreter;
it isn't Common LISP; doesn't have many of the features of Common LISP; doesn't
have the performance of nearly any of the LISPs available; doesn't support CLOS,
the Common LISP Object System, which is one of the most expressive object
systems available; it doesn't have namespaces or packages; it doesn't support
reader macros; it doesn't support proper CL numerics (rations and bignums);
and most importantly, it's dynamically scoped, not lexically scoped,
which is utterly crippling, at least for me.

Jeremy

[Gnu/Vince]

Originally posted by jemfinch:
<STRONG>Elisp isn't a good LISP. It doesn't compile to native code; it's tied to a large interpreter;
it isn't Common LISP; doesn't have many of the features of Common LISP; doesn't
have the performance of nearly any of the LISPs available; doesn't support CLOS,
the Common LISP Object System, which is one of the most expressive object
systems available; it doesn't have namespaces or packages; it doesn't support
reader macros; it doesn't support proper CL numerics (rations and bignums);
and most importantly, it's dynamically scoped, not lexically scoped,
which is utterly crippling, at least for me.

Jeremy</STRONG>


You could suggest that to RMS. I had CMUCL a while ago, but I couldn't find how to compile a program. So I apt-got ocaml

[ 22 October 2001: Message edited by: Gnu/Vince ]

[klamath]

First, it's dynamically typed. I've gotten very used to the safety of a statically typed language that O'Caml
provides.

It's not quite accurate to call Dylan dynamically typed, since type declarations can certainly be made -- they're just completely optional (as in Lisp). So if you want to get the performance or safety of static type declarations, you're free to declare all your types; if you're interested in rapidly developing a prototype, you can leave off the type declarations and spend your time on something more worthwhile. I think this is a very good compromise in the static/dynamic debate, and is probably a better solution than either purely static or purely dynamic typing. Finally, I think that the time invested in adding type declarations is better spent writing unit tests. These catch the same types of errors, but they are much more effective: they catch more errors, they test both functionality and syntax and they document the code they're testing very well.

Second, I don't believe it compiles to native code, which, while it's not that important, is still a disadvantage it has versus, say, O'Caml or LISP.

Incorrect; the most common way to develop Dylan code is using the native code compiler, 'd2c'. Bytecode compilers and interpreters exist (e.g. 'mandy'), but they are used mainly for prototyping and development: the vast majority of "production" code is natively compiled (and achieves good performance, too: one of the goals of Dylan is to remain high-level and allow useful abstractions, but still achieve as good or better runtime performance than C++).

Thirdly, syntax is really a non-issue at this point in my choice of a
programming language: I know several programming languages and don't really have
any problems learning a new syntax.

Well, considering that the syntax of the language is the main way the programmer interacts with the computer (i.e. type new code in the syntax, read code in it, prototype ideas in it, etc), I'd say it's pretty important. The syntax of a language often has a lot to do with how easy it is to understand ideas expressed in that language, and to express new ideas yourself (the difference between, say, writing a paper on economics in iambic pentameter versus straight prose). Finally, one of the major advantages that Python programmers cite over Perl is the consistency and readibility of Python's syntax, compared to Perl's. Isn't it hypocritical of you to criticize Perl for something you dismiss in other languages?

I'll probably pick Common LISP, which has not only multiple dispatch (in CLOS) but also macros, which are more interesting to me than any other programming concept I don't yet have experience with.

Dylan has macros as well. In fact, Dylan is often described as a Lisp derivative (although since it uses infix rather than prefix notation, it looks quite different visually).

So in short, I can't see what's interesting about Dylan.

First off, I think I've dismissed a lot of your objections (since the claims that Dylan can't compile to native code, and that it doesn't contain macros, are simply incorrect). Dylan's type system is, IMHO, one of its best features. Syntax, I suppose is a matter of personal choice, but I like Dylan's (and Ruby's, for that matter).

As for what's new in Dylan, I think that question is a bit of a red herring. Consider Python: it's features are a strict subset of those supported by Common LISP circa 1993 (and it's VM implementation is significantly less mature -- it is substantially slower than modern Lisps and can't compile to native code). Why then, should anyone bother learning Python? The same applies even moreso to Java, which has an even more limited set of features than Python.

I don't think a language should be evaluated on what new it brings to the table -- since the number of genuinely new ideas in CS is pretty low (most innovations are just refinements and improvements on already known, proven ideas).

[klamath]

You could suggest that to RMS.

I heard that RMS is eventually planning to switch from ELisp to Guile (a scheme variant) in some future version of Emacs, possibly by providing a compatibility mode for old ELisp code.

[jemfinch]

Pardon the paraphrase in certain spots, the Reply-with-quote function isn't
working and I'd rather not type too much (and I hate copying when line-endings
are going to make it look all nasty.)

Originally posted by klamath:
Incorrect; the most common way to develop Dylan code is using the native code
compiler, 'd2c'.


Oops, I didn't know one existed :)


Finally, I think that the time invested in adding type declarations is better
spent writing unit tests. These catch the same types of errors, but they are
much more effective: they catch more errors, they test both functionality and
syntax and they document the code they're testing very well.


First, in O'Caml and other type inferring languages, type declarations are
unnecessary, so there's really no time spent investing in type declarations.
Second, some things aren't easy to unit test -- for instance, how does one unit
test an IRC bot without using the same (possibly buggy) implementation to script
the tests?


The syntax of a language often has a lot to do with how easy it is to understand
ideas expressed in that language, and to express new ideas yourself


But learning the syntax of a language is a one-time cost. Once the syntax is
learned, expressing yourself in a language is no more complex than any other
language in which you have equivalent syntactical knowledge.

Syntax only affects the readability of a language insofar as it makes multiple
"natural" ways to express oneself. Perl is a pathological case: it allows
(heck, its goal) is to have innumerous "natural" ways to express a given
solution. This, of course, is the problem: when reading Perl code, a programmer
has to carry around in his head all these "natural" ways of writing code, and if
he can't, he stalls while trying to figure out something that might be entirely
natural to the programmer who wrote it, but is horribly obfuscated to the the
one reading the code. Syntactical comlexity isn't a function of the number of
tokens in the language; it's a function of the number of natural ways to write a
given construct. That's why Python syntax is considered "simple" whereas Perl
is considered "pathological" -- there's generally one (or maybe two) natural
ways to write a certain piece of code in Python, whereas there are hundreds of
"natural" ways to write the same code in Perl. In that respect, O'Caml has a
more baroque syntax than Python, but is only very slightly more complex
-- there are not very many natural ways in which to express a given concept.

There are very few syntaxes that can approach Perl's as far as the number of
ways in which an idea can be represented naturally. From my experience, that
number is exactly 0. That's why, in general, until shown otherwise, I'll assume
a language has a sane syntax, and will continue to complain about Perl's
pathological syntax. And in that sense, most languages are equals -- I'm sure
Dylan syntax is as easy to get a grip on as O'Caml's or Ruby's.


Dylan has macros as well.


I didn't know that, can you show an example?


Consider Python: its features are a strict subset of those supported by Common
LISP circa 1993 (and its VM implementation is significantly less mature -- it is
substantially slower than modern Lisps and can't compile to native code.) Why
then, should anyone bother learning Python?


Yes, but its learning curve is significantly smaller. People might find
it useful to learn Python because it'll take them a couple hours. It'll take
them months to really get Lisp.


I don't think a language should be evaluated on what new it brings to the table
-- since the number of genuinely new ideas in CS is pretty low


Ah...but I don't learn languages based on what they bring to the table, I learn
languages based on what they bring to my table. Dylan brings nothing
new, from my point of view, that I can't get (along with several other features)
in a good implementation of Common LISP.

Jeremy

[klamath]

First, in O'Caml and other type inferring languages, type declarations are
unnecessary, so there's really no time spent investing in type declarations.

You're right, type interference is cool -- it's one of the coolest features of ML variants. Still, you do lose the flexibility of dynamic typing.

Second, some things aren't easy to unit test -- for instance, how does one unit
test an IRC bot without using the same (possibly buggy) implementation to script
the tests?

If I understand you correctly, you could use mock objects: an object (say, representing an IO stream, database, or other external resource) that conforms to the same interface (say, reading and writing streams of data) but actually only contains test data and no real implementation. So your IRC bot's unit tests wouldn't connect to a server somewhere -- the unit tests would use a mock object that fed the bot the input it was expecting, and examined its output. Also, remember that unit tests are very specific: you're testing individual classes and individual methods, not the whole application. So you wouldn't write unit tests for "an IRC bot" -- you would test very small chunks of the bot, usually broken down according to its class hierarchy.

Dylan has macros as well.

I didn't know that, can you show an example?

I just started learning Dylan yesterday, so no, I can't personally -- but there's an example here: http://www.gwydiondylan.org/fragments/macros.phtml

Yes, but its learning curve is significantly smaller. People might find
it useful to learn Python because it'll take them a couple hours. It'll take
them months to really get Lisp.

I'd argue a large part of this learning cycle is disregarding the iterative way of thinking that they've become used to, and learning Lisp's unusual syntax. Dylan has a more conventional syntax -- plus, if we're talking about first languages, there are fewer old habits to break. I'll admit that Common Lisp is not a good learning language, because it is enormous: however, Scheme is much more compact.

And if the only reason to learn Python over Common LISP is the learning curve, then what use is Python than as an introductory languag for newbie programmers?

Dylan brings nothing
new, from my point of view, that I can't get (along with several other features)
in a good implementation of Common LISP.

That may be true -- or one could just as easily say "As a Dylan programmer, [Python|Common Lisp|Ruby|etc] brings nothing new that I can't get from a good Dylan implementation."

[Strike]

&lt;2 cents&gt;
I looked through your links and their attack of the problem at the ICFP, and I have to admit I was intrigued. If I hadn't already been introduced to Scheme (and thus, the quirkiness of the LISP-like functional languages), I would strongly consider learning this language simply as a good primer for functional programming (though it seems that it is not so "purely functional", as it makes compromises such as the infix notation even though this is nothing but syntax). And I am no language expert like jemfinch (who still blows me away with the fact that he is not even a Computer Science student, yet understands more about CS than ... every CS major I know), so I can't accurately compare the "behind-the-scenes" stuff. So, when it really comes down to it, languages only really make the cut (for me opting to learn them) if they can beat the simple test of learning curve versus strength/usability. I learned C and C++ because those are fairly ubiquitous even though I still don't fully grok every little detail (read: high learning curve). I learned a smattering of Perl until its usability versus the time spent on learning more wore out - result: I can read a fair amount of Perl (accompanied with the approriate documentation of course), but don't really know it well enough to build something in Perl from the ground up. I learned/am learning Python (at a rather slow pace due to issues in meatspace ;)), because it is really easy to "get", and it seems like it could be one of the new "ubiquitous" languages (under which I would group C, C++, Java, and Perl, among others).

Dylan isn't very widespread, so being able to read it at a second's notice isn't that important. While it doesn't seem as bad as other languages as far as the learning curve, it's still to steep for me to really bother "dabbling" in it (mostly because my time is sort of at a premium these days).

One thing's for sure though - it does seem like a unique language, and I do like hearing about new languages :D

[jemfinch]

Originally posted by klamath:
Still, you do lose the flexibility of dynamic typing.


I've yet to see a situation where dynamic typing provides any significant
advantages over static typing. I'd love to hear of some.

(Actually, there's one that I know of: format strings cannot be done in a static
typesystem. This has, however, been "hacked" into O'Caml, and in addition,
there are other methods of accomplishing the same task which I prefer. And as
an added benefit, formats are typechecked.)


what use is Python other than as an introductory language for newbie
programmers?


Rapid application development, easy integration with C, and one of the most
robust and capable "real world" standard libraries in existence are all great
reasons.


That may be true -- or one could just as easily say "As a Dylan programmer, [Python|Common Lisp|Ruby|etc] brings nothing new that I can't get from a good Dylan implementation."

Sure, you can say that. That's exactly what I'm saying, except of O'Caml and
Python. (And you won't hear me saying it about Python much these days :))

If I didn't know O'Caml, there's a good possibility that Dylan could replace
Python. However, since I now know O'Caml, and use it to write anything I write
of significance, that demotes Python to a "quick scripting" solution, in which
role I'm fairly sure it's superior to Dylan, due to the greater library support.
And as a fairly lazy/undisciplined programmer, I need the static typing O'Caml
provides for my more sizeable projects.

Jeremy

[pinoy]

I've yet to see a situation where dynamic typing provides any significant
advantages over static typing. I'd love to hear of some.


I can't think of how'd you implement polymorphism without dynamic binding.

[jemfinch]

Originally posted by pinoy:
I can't think of how'd you implement polymorphism without dynamic binding.

Well, it's certainly a good thing some people can :)

Sum types are one way -- the class system in O'Caml implements another way.
Believe me, it's quite possible to be both statically typed and
polymorphic.

Jeremy

[pinoy]

okay, I've looked at the OCaml docs (only briefly, so I may be wrong). OCaml can declare virtual methods (by virtual they actually mean abstract). This means the type is not fully defined, if you have a pointer/reference to this class, you will not know the real type of the object until runtime. Isn't that dynamic typing?

What are sum types? Can you point me to some docs?

[jemfinch]

Originally posted by pinoy:
okay, I've looked at the OCaml docs (only briefly, so I may be wrong). OCaml can declare virtual methods (by virtual they actually mean abstract). This means the type is not fully defined, if you have a pointer/reference to this class, you will not know the real type of the object until runtime. Isn't that dynamic typing?

What are sum types? Can you point me to some docs?

You're honestly best off just learning O'Caml :)

Jeremy

[pinoy]

As much as I'd like to, I just don't seem to have time to learn yet another language. I started learning it, but got bored of something I may never use at all, maybe one of these days I'll pick it up again. Anyway, I still see OCaml using late binding on abstract classes. This is just how polymorphism is implemented. This is not a bad thing. Very loose types such as variant types or scalar (whatever you want to call it) are another matter, they are just unacceptable, but for polymorphism to work, you have to be slightly dynamic in your type.

Most object oriented designs are like this. Look at the class factory design, it is used to decouple the real type of the object so it can be more dynamic.

[jemfinch]

Originally posted by pinoy:
but for polymorphism to work, you have to be slightly dynamic in your type.


You'll have to explain to me why this is true.

I can tell you this: you will never be able to write an O'Caml
program that compiles and when run calls a function with the wrong type, or with
a class that doesn't implement all the methods required by the function.

Jeremy

[pinoy]

As I don't know OCaml let me give you an example in C++. But I do know that OCaml supports OO.

suppose I have an abstract class Shape:


class Shape {
public:
virtual void draw() = 0;
};

class Square : public Shape {
public:
virtual void draw()
{ ... }
};

class Circle : public Shape {
public:
virtual void draw()
{ ... }
};


And I have a function that uses shape, or even a collection of Shapes.

e.g.

void renderShapes(ShapeCollection& coll)
{
coll::iterator it = coll.begin;
for (; it != coll.end(); coll++) {
Shape* shape = *it;
// I have no idea what the real type of this shape is, but I know it is a shape.
shape-&gt;draw();
}
}


As you can see the renderShapes() function only knows of Shapes, it doesn't know the real type of the Shape. It can enquire on it, if it's a specific type.

e.g.

Square* square = dynamic_cast&lt;Square&gt;(shape);
if (square) {
cout &lt;&lt; "object is a square" &lt;&lt; endl;
}


It is not exactly very loose typed, that is, it's not a variant that coerces itself to a different type depending on the operation, e.g. a number that gets turned into a string if you're concatenating a string (like Perl or VB).

This is what happens when you start doing Object Oriented, you loose some of that typing. It is not bad, this is how it's supposed to work, you only care about interfaces not real types. On the other hand if you go generic programming you get a lot of static typing. And types are resolved at compile time.

[jemfinch]

Does C++ enforce that inheritance hierarchy?

O'Caml does things a bit differently. Let's say I define these three classes:


class foo =
object
val mutable x = 0
method set i = x &lt;- i
method to_string = string_of_int x
end

class bar =
object
val mutable x = None
method set i = x &lt;- i
method to_string = match x with None -&gt; "None" | Some s -&gt; "Some " ^ s
end

class baz =
object
val mutable x = 0.5
method add i = x &lt;- x +. i
method to_string = string_of_float x
end

let obj_to_string o = o#to_string
let obj_set v = o#set v


obj_to_string can take any of those objects, despite the fact that they have
different signatures, because they implement the necessary method (to_string)
that obj_to_string requires. obj_set, on the other hand, can only take
instantiations of foo or bar, since baz doesn't implement a "set" method. This
is all checked at compile time, of course. obj_set is also fully polypmorhpic:
it can take any type, as long as the type required by the object's set method is
the same as the type obj_set is called with.

There's no particular inheritance hierachy that's required (as I believe is the
case in Java and *maybe* C++.) As long as the objects implement the proper
methods, they can be used in any function which expects just those methods.

I think I may have answered your question. If not, clarify, and I'll try to do
better next time :)

Jeremy

[pinoy]

Yes the compiler can check that you pass an object that implements the interface. It still however have to resolve the actual type at runtime. This is basically late binding. For most cases this is okay as this follows the Liskov Substitution Principle, however in Java where containers are basically containers of "Object"s, you'll have to downcast the elements back to their original type.

As you already know, this is not a problem, it can be checked by the compiler whether an object passed support the interface. It is still however not fully strictly typed. This is more problematic in Java though, with as I mentioned the containers.

e.g.

Stack stack;
stack.push(cat);
stack.push(dog);

Object obj = stack.pop();
// not sure whether obj is Cat or Dog, but I know it supports Object
System.out.println(obj.toString()); // this works
Cat cat = (Cat)obj; // may fail, in fact will fail as last one pushed was dog

[jemfinch]

Originally posted by pinoy:
It is still however not fully strictly typed.


I can't see how there's any type information left to be determined at runtime.

Jeremy

[pinoy]

Because given an abstract type there is no way for a compiler to know ahead of time what type of object will be used, all it knows is it is going to be derived from that type. This is not a problem so long as we don't violate Liskov's Substitution Principle, the compiler can enforce that the object must conform to the interface, and you pretty much get what you have with static typing. However the true type of the object will have be resolved at run time (ie late binding).

For example:

void render(const Shape& shape);

render(rectangle); // rectangle is derived from shape - OK
render(5); // oops an int, (unless there is a conversion constructor somewhere) this will fail at compile time.


As you can see the compiler can enforce that only of type Shapes can be passed to render(). However render() does not what type of objects it will be called with, all it knows is it supports Shape.

Violating LSP (which can be done in C++ and Java via casts), is generally bad code, and this is where dynamic typing really shows. If OCaml doesn't support downcasting an object good for you (or bad for you, depending on how you look at it).


void render(const Shape& shape)
{
if (typeid(shape) == typeid(Rectangle)) {
// a rectangle, handle this differently
drawRectangle(shape);
}
else
shape.draw();
}


This way we can actually determine the type of the object at run time (albeit safely, ie not just a direct cast).

Back to your original question, "where dynamic typing provides any significant
advantages over static typing". This is one, but this is probably different to the type of "loose typing" you're referring.

variants such as those in Perl are another matter, for scripting languages they're fine, for most other languages, they're unnecessary, and I hate these variants myself.


Does C++ enforce that inheritance hierarchy?


Yes, but you can get around it by using casts. You can get around anything by casting, casts are powerful, but easy to misuse in the wrong hands. But you shouldn't be casting anyway.

Also STL actually supports this static typing very well. In fact containers are usually only polymorphic at compile time. The only way to have polymorphic containers at runtime is to have a container of pointers. Generic programming is heavy into static typing, the nice thing about this is if it compiles it will most likely work (assuming the logic is correct of course).

[jemfinch]

Originally posted by pinoy:
As you can see the compiler can enforce that only of type Shapes can be passed to render(). However render() does not what type of objects it will be called with, all it knows is it supports Shape.


O'Caml functions only require the the object they're called with maintain
whatever interface they require, rather than an inheritance hierarchy.


If OCaml doesn't support downcasting an object good for you (or bad for you, depending on how you look at it).


O'Caml supports casting an object to a smaller interface (I do this, for
instance, with my irc_connection object in my IRC bot, because it has to have
present certain methods to the asynchronous networking poller, and certain other
methods to the callbacks -- so I downcast it to the proper set of functions so
neither can adversely affect the other.


Back to your original question, "where dynamic typing provides any significant
advantages over static typing". This is one, but this is probably different to the type of "loose typing" you're referring.


I must be missing something -- I'm seeing neither dynamic typing nor an
advantage.

If a function supports objects of various type as long as they have the
necessary methods implemented, then that's not dynamic typing, it's
polymorphism. And the compiler can (and does, in O'Caml) determine that this
requirement is met at compile time.

Polymorphism is fully compatible with a static type system.


variants such as those in Perl are another matter, for scripting languages they're fine, for most other languages, they're unnecessary, and I hate these variants myself.


Variants?

Jeremy

[pinoy]

It's not static typing, it's dynamic. The compiler does not know the *real* type, only the abstract type.

Consider again if you have a type Object where all objects are derived from, you can create a container (list for example) of objects, and any objects can be put into that. Now you also have two classes derived from object Cat and Dog.

e.g.

Cat cat1, cat2;
Dog dog1, dog2;
ObjectList objList;
objList.push_back(cat1);
objList.push_back(dog1);
objList.push_back(dog2);
objList.push_back(cat2);

Now all the compiler knows is that it is a list of Objects which Cat and Dog are derived from, this compiles perfectly. But how do you get the Cats and Dogs back without casting?

Cat cat = objList.get_head();

Compiler CANNOT enforce this. Cat is an Object, but Object is NOT a Cat. Given the example though we know that it is a Cat because that's the order we pushed it in so let's cast it.

Cat cat = (Cat)objList.get_head();



O'Caml supports casting an object to a smaller interface (I do this, for
instance, with my irc_connection object in my IRC bot, because it has to have
present certain methods to the asynchronous networking poller, and certain other
methods to the callbacks -- so I downcast it to the proper set of functions so
neither can adversely affect the other.


Well as soon as you have casting, you basically lose your static typing enforcement.

[pinoy]

Here are a couple of links on OCaml and late binding for polymorphism to work:

http://pauillac.inria.fr/~remy/cours/appsem/ocaml-mixins.html
http://caml.inria.fr/tutorials/objectdemo.html

Look for late binding