Some thoughts on Dylan vs. ML 
Author Message
 Some thoughts on Dylan vs. ML

Having had the opportunity to try both Dylan and ML now for several weeks (3
mos on Dylan, 2 wks on ML) I have some interesting observations to make:

1. ML, of course, throroughly lacks any kind of dynamic dispatch. I can't
help but feel like I'm stepping backward in time somewhat when I write ML.
It addresses structured programming par excellant, but I miss CLOS!

2. Dylan's type inferencing seems rather weak in comparison to ML. There are
many instances where, say a collection of vectors containing nothing but
<double-floats> causes Dylan to decide it must use dynamic dispatch on a
fetched collection element. I find myself doing some gratuitous assignments
with strong type marking just to get Dylan to realize it doen't need dynamic
dispatch. By contrast, ML has a remarkable ability to ferret out the exact
type relationship no matter (seemingly) how deeply buried a datum lies.

3. Higher order functions in Dylan seem to require rather more overhead in
application to collections than the same in ML. I find that higher order
(composed, curried) functions in ML get applied as though the code were
inlined. By contrast, it appears that Dylan must perform a function call
with all the concommittant type checking of its arguments at runtime.

4. Dylan is actually closer to my prior experience (I suspect that is true
for many of us) than ML. As a consequence, I find that I can write Dylan
quite rapidly to achieve the desired effect. Maybe I should hold my opinion
on ML until I have 3 months of ML under my belt as well, but I find myself
struggling harder in a few lines of ML than in a whole page of Dylan.

5. The verbiage in Dylan is comparable to that in Lisp/CLOS, and I find
myself complaining about the wordiness of both languages in comparison to
ML. I am hoping to find a language that allows abstract thinking about a
problem, and that considerably reduces the code-bloat that I have endured
writing C++/COM/ATL. All of these (ML, Dylan, and Lisp/CLOS) are wonderful
languages, and they all leave me feeling somewhat humble -- even though I
used to write C compilers for a living.

Oh well, what do you all think?

--
David McClain
Sr. Scientist
Raytheon Missile Systems Co.
Tucson, AZ



Sun, 03 Jun 2001 03:00:00 GMT  
 Some thoughts on Dylan vs. ML

Quote:

>2. Dylan's type inferencing seems rather weak in comparison to ML. There are
>many instances where, say a collection of vectors containing nothing but
><double-floats> causes Dylan to decide it must use dynamic dispatch on a
>fetched collection element. I find myself doing some gratuitous assignments

There's a language construct to cope with that problem, and it's known
as a limited type. Basically you say

let my-vector = make(limited(<vector>, of: <double-float>));

and the compiler knows that any element access to my-vector results in
a <double-float>.

At least in theory. Gwydion Dylan doesn't support limited types yet,
and as far as I know, Harlequin Dylan won't support them before 2.0.

But yes, type inferencing is a little weaker in Dylan. The current set of
limited types makes up for that in the worst places like in the case
you described.

Quote:
>3. Higher order functions in Dylan seem to require rather more overhead in
>application to collections than the same in ML. I find that higher order
>(composed, curried) functions in ML get applied as though the code were
>inlined. By contrast, it appears that Dylan must perform a function call
>with all the concommittant type checking of its arguments at runtime.

That is an implementation issue as well. If you use a limited type, the
compiler should be able move the type check out of the loop, and also
to inline the higher order function, except when it can't prove anything
about the function. Again, with the current implementations, we're not
there yet.

Quote:
>5. The verbiage in Dylan is comparable to that in Lisp/CLOS, and I find
>myself complaining about the wordiness of both languages in comparison to
>ML. I am hoping to find a language that allows abstract thinking about a

Well, at least it's not COBOL ;). Actually I find a little wordiness helps
in reading the code, and I'm making heavy use of word auto-expansion
and automatic closing of open statements in emacs (so when I already
typed *some-very-long-variable-name-that-explains-what-it-is-about*
somewhere in an open buffer, it only takes *som and M-/ to expand it,
and pressing C-c ) inserts "end method foo-bar;" for me when I'm
finished with the function).

Andreas

--
"Java requires the programmer to declare types and exceptions, simply to
make the compiler's job easy.  Which just seems like the wrong approach
to me:  CPU-cycles we have plenty of, good programmer cycles we don't."



Sun, 03 Jun 2001 03:00:00 GMT  
 Some thoughts on Dylan vs. ML

Quote:
> "Java requires the programmer to declare types and exceptions, simply to
> make the compiler's job easy.  Which just seems like the wrong approach
> to me:  CPU-cycles we have plenty of, good programmer cycles we don't."


I've seen this quote a few time now, and I'm wondering whether that's
true about exceptions.  So far as I've been able to tell, when I fail
to declare an exception in Java, the compiler tells me that I need to
declare it.  So it must have already figured it out and not need my
declaration to tell it about the exception.  (Which makes it even
more of a pain that I have to declare it.)

-- jd



Mon, 04 Jun 2001 03:00:00 GMT  
 Some thoughts on Dylan vs. ML

Quote:

>> "Java requires the programmer to declare types and exceptions, simply to
>> make the compiler's job easy.  Which just seems like the wrong approach
>> to me:  CPU-cycles we have plenty of, good programmer cycles we don't."

>I've seen this quote a few time now, and I'm wondering whether that's
>true about exceptions.  So far as I've been able to tell, when I fail
>to declare an exception in Java, the compiler tells me that I need to
>declare it.  So it must have already figured it out and not need my
>declaration to tell it about the exception.  (Which makes it even
>more of a pain that I have to declare it.)

I've also seen that quote a few times, and with my ML programmers hat on, I
almost entirely disagree with it.  The point of static typing is not to make
the compiler's job easy, it's to produce well-structured and robust code, and
to clearly define interfaces between modules.  Programmer cycles *should* be
spent thinking about program structure, and from early on in the design.  This
is not a waste; it's a benefit.  Especially as it reduces the need for
QA-cycles, and programmer bug-fixing cycles.

I think the advantage of Lisp is not the dynamically-typed language, per se,
but the highly-dynamic programming environments.  These let programmers test
and fix quickly and cheaply.  ML environments tend to be less good at this;
they have some of the interactivity for testing, but rarely the full debugging
and interactive update abilities of Lisp environments.  This is what I wanted
to provide when I started work at Harlequin; we've got some of the way, but
not all.  I think the Harlequin Dylan environment gets further, and (speaking
personally) I'd really like to see us leverage this technology in MLWorks.

Where I do agree with Tucker's quote is that programmers shouldn't have to
declare types and exceptions everywhere.  The language should specify a type
inference system that does much of the work.

(None of this is in any way indicative of Harlequin policy towards any of our
products.  I want all our language products to succeed, and see plenty of
scope for co-operation between them).

Dave.



Mon, 04 Jun 2001 03:00:00 GMT  
 Some thoughts on Dylan vs. ML

Quote:

>>> "Java requires the programmer to declare types and exceptions, simply to
>>> make the compiler's job easy.  Which just seems like the wrong approach
>>> to me:  CPU-cycles we have plenty of, good programmer cycles we don't."

>I've also seen that quote a few times, and with my ML programmers hat on, I
>almost entirely disagree with it.  The point of static typing is not to make
>the compiler's job easy, it's to produce well-structured and robust code, and
>to clearly define interfaces between modules.  Programmer cycles *should* be

Right. This is why static typing is in Dylan.

Quote:
>spent thinking about program structure, and from early on in the design.  This

Wrong. During prototyping, having to think about types tends to get
in the way. That's why static typing is optional in Dylan.

Quote:
>Where I do agree with Tucker's quote is that programmers shouldn't have to
>declare types and exceptions everywhere.  The language should specify a type
>inference system that does much of the work.

That's the point of it.

Andreas

--
If you think C++ is not overly complicated, just what is a protected
abstract virtual base pure virtual private destructor, and when
was the last time you needed one?
                -- Tom Cargil, C++ Journal.



Tue, 05 Jun 2001 03:00:00 GMT  
 Some thoughts on Dylan vs. ML


Quote:
>I've also seen that quote a few times, and with my ML programmers hat on, I
>almost entirely disagree with it.  The point of static typing is not to make
>the compiler's job easy, it's to produce well-structured and robust code,
>and to clearly define interfaces between modules.

[I think my 15 minutes of internet fame must be up by now, so perhaps
Andreas will quote someone else for a while.]

If you read what I said carefully, I did not say that the point of static
typing was to make the compiler's job easy.  I said that was what it was
used for in Java (and C, and C++, etc.)  As you rightly clarified, with a
decent inferencing system, you can have all the benefits of type
declarations enforcing good code design and structure without burdening
the programmer to the extent that C descendants do.

I stand by my claim that in C and it's descendants type declarations to a
large part are required to make the compiler simple to implement.  In C
and C++, it is nearly impossible to do inferencing because of the
aliasing problem.  Java eliminates aliasing, but doesn't take advantage
of that to reduce the number of declarations required.  From that I
conclude that they are kept to make the compiler simpler to implement.

________________________________________________________________
Callitrope/The Art of Computing      <http://www.callitrope.com>


post:Callitrope/168 Old Sandwich Road/Plymouth/MA/02360-2507/USA



Tue, 05 Jun 2001 03:00:00 GMT  
 Some thoughts on Dylan vs. ML

Re the discussion of:
  "Java requires the programmer to declare types and exceptions, simply to
  make the compiler's job easy.

Quote:

> I stand by my claim that in C and it's descendants type declarations to a
> large part are required to make the compiler simple to implement.  

(Just out of curiosity, why "C and its descendants" rather than some
more general class?  It looks to me like the same could be said about
Pascal, for instance.   Even for Dylan (for example), there seemed
to be the idea that declarations could allow more efficient code to
be produced in certain cases.)

Quote:
> In C
> and C++, it is nearly impossible to do inferencing because of the
> aliasing problem.  Java eliminates aliasing, but doesn't take advantage
> of that to reduce the number of declarations required.  From that I
> conclude that they are kept to make the compiler simpler to implement.

But do you think that's so for Java's requirement that exceptions
be declared?  It appears that the JDK compiler, at least, determines
which exceptions need to be declared and complains if those
declarations have not been supplied; so it doesn't look like the
declarations make the compiler simpler in this case.  Perhaps
the aim is to make things easier for other compilers, but that
doesn't look like the most likely explanation.

The Java designers appear to think that explicit type and exception
information is a good thing, hence (for example) the requirement
for explicit casts even when the destination class is obvious
and even though there's a run-time check that the object has
a class that fits.  The requirement that exceptions be declared
(though, actually, some kinds of exceptions don't need to be
declared) appears to be because this was thought to be something
programmers ought to do.  The aim, then, would be to enforce a
certain discipline, rather than to make the compiler simpler.

Even for type declarations, making things easier for the compiler
does not appear to be the only factor at work.

-- jd



Wed, 06 Jun 2001 03:00:00 GMT  
 Some thoughts on Dylan vs. ML


Quote:

>>Programmer cycles *should* be
>>spent thinking about program structure, and from early on in the design.

>Wrong. During prototyping, having to think about types tends to get
>in the way.

I've never understood this idea of an 'untyped prototyping phase' in
development. The first thing I do after thinking about the problem domain
is to work out a class hierarchy. Then I'll start writing generic
functions or their equivalents. Nowhere will I do anything resembling
untyped prototyping. Among my complaints with the languages I work with
(C++, Java) are that the typing isn't strong enough or expressive enough,
not that they aren't loose enough.

Perhaps I should learn ML...

Now Dylan is a language that should be as strongly or as weakly typed as
the programmer desires (stated design goal). I've been pushing to extend
the 'strong typing' end because I see languages not so much as for
telling the computer what to do, but for formally describing the problem
domain so that the computer itself can work out what to do.

--
Ashley Yakeley, Seattle WA



Wed, 06 Jun 2001 03:00:00 GMT  
 Some thoughts on Dylan vs. ML

Quote:

>I've never understood this idea of an 'untyped prototyping phase' in
>development. The first thing I do after thinking about the problem domain
>is to work out a class hierarchy. Then I'll start writing generic
>functions or their equivalents. Nowhere will I do anything resembling

If you are able to come up with the correct class hierarchy before
writing your first line of code, you're much smarter than me. I often
have to try out how things work out.

Besides, we're not talking untyped, but dynamically typed. Why should I
restrict the return type of some generic function if I'm not sure
what types it will return when the program is finished?

Andreas

--
If you think C++ is not overly complicated, just what is a protected
abstract virtual base pure virtual private destructor, and when
was the last time you needed one?
                -- Tom Cargil, C++ Journal.



Thu, 07 Jun 2001 03:00:00 GMT  
 Some thoughts on Dylan vs. ML

Quote:

> But do you think that's so for Java's requirement that exceptions
> be declared?  It appears that the JDK compiler, at least, determines
> which exceptions need to be declared and complains if those
> declarations have not been supplied; so it doesn't look like the
> declarations make the compiler simpler in this case.  Perhaps
> the aim is to make things easier for other compilers, but that
> doesn't look like the most likely explanation.

> The Java designers appear to think that explicit type and exception
> information is a good thing, hence (for example) the requirement
> for explicit casts even when the destination class is obvious
> and even though there's a run-time check that the object has
> a class that fits.  The requirement that exceptions be declared
> (though, actually, some kinds of exceptions don't need to be
> declared) appears to be because this was thought to be something
> programmers ought to do.  The aim, then, would be to enforce a
> certain discipline, rather than to make the compiler simpler.

> Even for type declarations, making things easier for the compiler
> does not appear to be the only factor at work.

I don't know if this is what motivated the designers of Java, but
explicit type & exception declaration is very useful when using
3rd party code libraries.

Libraries are good because they save me the effort of writing code,
but against that I have to weigh the time required to learn how
to use them, and to integrate them into my own programs.
Before I decide to use a library I definitely want to know what
exceptions it may throw - if I have to wait until I'm commited to
using it, and only then discover that all the important functions
have three exception cases that must be handled, that's far too
late!

Mark Bassett



Fri, 08 Jun 2001 03:00:00 GMT  
 Some thoughts on Dylan vs. ML


Quote:

> >I've never understood this idea of an 'untyped prototyping phase' in
> >development. The first thing I do after thinking about the problem domain
> >is to work out a class hierarchy. Then I'll start writing generic
> >functions or their equivalents. Nowhere will I do anything resembling

> If you are able to come up with the correct class hierarchy before
> writing your first line of code, you're much smarter than me. I often
> have to try out how things work out.

> Besides, we're not talking untyped, but dynamically typed. Why should I
> restrict the return type of some generic function if I'm not sure
> what types it will return when the program is finished?

Another argument against too much explicit typing (although not necessarily
against strong typing) is that it reduces the opportunities for code reuse.
That is, you would like to be able to write an abstract piece of code that
gets compiled efficiently when its reused in particular programs.

__Jason



Fri, 08 Jun 2001 03:00:00 GMT  
 Some thoughts on Dylan vs. ML


Quote:
>Another argument against too much explicit typing (although not necessarily
>against strong typing) is that it reduces the opportunities for code reuse.

I think it reduces the opportunities for bad code reuse. If you reuse
code, you need to reuse the types involved.

Quote:
>That is, you would like to be able to write an abstract piece of code that
>gets compiled efficiently when its reused in particular programs.

I don't see how omitting types helps.

--
Ashley Yakeley, Seattle WA



Fri, 08 Jun 2001 03:00:00 GMT  
 Some thoughts on Dylan vs. ML



Quote:

> >Another argument against too much explicit typing (although not necessarily
> >against strong typing) is that it reduces the opportunities for code reuse.

> I think it reduces the opportunities for bad code reuse. If you reuse
> code, you need to reuse the types involved.

Sure, but those types can be high level. Think polymorphic.

Quote:
> >That is, you would like to be able to write an abstract piece of code that
> >gets compiled efficiently when its reused in particular programs.

> I don't see how omitting types helps.

Because that allows the surrounding programs that are reusing the code to
constrain the types as desired.

__Jason



Fri, 08 Jun 2001 03:00:00 GMT  
 Some thoughts on Dylan vs. ML

Quote:


> > >Another argument against too much explicit typing (although not
> > >necessarily against strong typing) is that it reduces the
> > >opportunities for code reuse.
> > I think it reduces the opportunities for bad code reuse. If you reuse
> > code, you need to reuse the types involved.
> Sure, but those types can be high level. Think polymorphic.

Perhaps an example would help?  Without one it is not clear to me why
the polymorphic code (at least in ML) would not use explicit type
variables instead of explicit ground types and hence still be useable
in different contexts.

Quote:
> > >That is, you would like to be able to write an abstract piece of code that
> > >gets compiled efficiently when its reused in particular programs.
> > I don't see how omitting types helps.
> Because that allows the surrounding programs that are reusing the code to
> constrain the types as desired.

In ML all that would happen is that the explicit type variables would
be unified in the new context.  If it did not unify, then it probably
means that the code was not as reusable as was first thought :-)


Fri, 08 Jun 2001 03:00:00 GMT  
 Some thoughts on Dylan vs. ML


    Date: Mon, 21 Dec 1998 03:41:45 -0800


    >Another argument against too much explicit typing (although not necessarily
    >against strong typing) is that it reduces the opportunities for code reuse.

    I think it reduces the opportunities for bad code reuse. If you reuse
    code, you need to reuse the types involved.

This is not strictly true.

In Dylan, I often write untyped "utility" functions, and then get the
compiler to "copy them down" to other places (by using inlining, e.g.).
You can think of such functions as being template-like.



Fri, 08 Jun 2001 03:00:00 GMT  
 
 [ 24 post ]  Go to page: [1] [2]

 Relevant Pages 

1. lazy.dylan 0.1 -- add ML/Scheme-style lazy evaluation to Dylan

2. AKCL vs Fortran vs ML time test

3. Dylan vs DyLan

4. Some thoughts on using Dylan

5. A few thoughts from a new Dylan user..

6. Let-form vs where-form--preferences and thoughts?

7. Lisp vs ML

8. Functions vs values in ML

9. RE : Lisp vs ML

10. Haskell vs ML (or O'Caml)

11. ML Vs Haskell

12. Erlang vs ml, haskell

 

 
Powered by phpBB® Forum Software