Newsgroups: comp.lang.dylan
   Date: Sun, 18 Feb 1996 19:13:41 +1300 (NZDT)
   Path: agate!howland.reston.ans.net!vixen.cso.uiuc.edu!uwm.edu!chi-news.cic.net!nntp.coast.net!news.dacom.co.kr!news.uoregon.edu!waikato!comp.vuw.ac.nz!actrix.gen.nz!hoult!Bruce

   Lines: 7

   > I didn't notice anyone mentioning it yet, but there's
   > a pretty good article in the February 1996 issue of
   > Byte - "What's the Future of Dylan", by{*filter*} Pountain

   Just what we need here -- the Pountain kiss of death.

Well thanks for the email address of the writer of the obituary.

to let him know (them) that his article made me drop my subscription :)
(Which of course raises the question:  why was I subscribing in the
first place? :) )

Cheers
--
Marco Antoniotti - Resistente Umano
===============================================================================

1947 Center STR, Suite 600                      | tel. +1 (510) 643 9153
Berkeley, CA, 94704-1198, USA                   |      +1 (510) 642 4274 x149
===============================================================================
        ...it is simplicity that is difficult to make.
        ...e` la semplicita` che e` difficile a farsi.
                                Bertholdt Brecht

...

But I must say that I thought the Byte article was pretty reasonable.
Pountain understood and conveyed many of the good points about Dylan.
His only real error, in my opinion, was in equating the demise of the
Dylan effort at Apple with the demise of Dylan in general, and that's
a reasonable mistake to make from a distance.

He also was a bit quick to call the game on account of darkness and
award the prize to C++, but that's a judgement call.  I disagree with
his view that the game is over, but it's up to CMU, Harlequin, and
others to prove him wrong.

-- Scott

===========================================================================

Principal Research Scientist            Phone:     412 268-2575
School of Computer Science              Fax:       412 268-5576
Carnegie Mellon University              Latitude:  40:26:46 N
5000 Forbes Avenue                      Longitude: 79:56:55 W
Pittsburgh, PA 15213                    Mood:      :-)
===========================================================================

-Paul-

--
Paul R. Potts - Technical Lead - Health Media Research Lab
University of Michigan - Comprehensive Cancer Center

-Nick Kramer

   Newsgroups: comp.lang.dylan
   Date: 21 Feb 1996 19:28:57 GMT
   Organization: School of Computer Science, Carnegie Mellon University
   Lines: 36
   NNTP-Posting-Host: clyde.boltz.cs.cmu.edu

   ...
   >>    Just what we need here -- the Pountain kiss of death.
   ...

   > to let him know (them) that his article made me drop my subscription :)
   > (Which of course raises the question:  why was I subscribing in the
   > first place? :) )

   I dropped my subscription to Byte sometime ago -- not a protest, just
   alarm that the stack of unread Bytes was on the verge of collapsing
   into a gravitational anomaly that might suck down innocent
   bystanders.

Well, actually I dropped it some time ago because of a number of
causes.  I did indeed have a growing mass of unread Byte in my
apartment.  However, the general attitude of Byte toward *anything*
which is not MSWindows/Visual Basic/C++ was really getting to be
annoying.  I remember the article they devoted to Linux.  It was
obvious that (a) they did not like the beast at all, (b) they did not
do any research on the overall phenomena and (c) they did not give the
basic info about how and where to get more info or order a CD.  Until
5 months ago, no article I can remember was devoted to FreeBSD et
similia.

   But I must say that I thought the Byte article was pretty reasonable.
   Pountain understood and conveyed many of the good points about Dylan.
   His only real error, in my opinion, was in equating the demise of the
   Dylan effort at Apple with the demise of Dylan in general, and that's
   a reasonable mistake to make from a distance.

I agree that the article was reasonable on many accounts (you cannot
dismiss Dylan easily).

   He also was a bit quick to call the game on account of darkness and
   award the prize to C++, but that's a judgement call.  I disagree with
   his view that the game is over, but it's up to CMU, Harlequin, and
   others to prove him wrong.

You could start by *requesting* BYTE to publish a response to the
article.  Possibly not in the stupid "Letters to the Editor".

Cheers

--
Marco Antoniotti - Resistente Umano
===============================================================================

1947 Center STR, Suite 600                      | tel. +1 (510) 643 9153
Berkeley, CA, 94704-1198, USA                   |      +1 (510) 642 4274 x149
===============================================================================
        ...it is simplicity that is difficult to make.
        ...e` la semplicita` che e` difficile a farsi.
                                Bertholdt Brecht

I've cranked {*filter*} C++, and I feel pretty competent using templates,
STL, exceptions, namespaces (as soon as MW supports them) and RTTI and so
forth. The whole trick, however, is that as soon as you start adding power
to C++ that comes within half of what Dylan has (e.g., STL), you start
seeing efficiency worse than that of Dylan. For example:

    for (i = collection.begin(); i < collection.end(); ++i)

generates a function call *every loop*, and it really ought not to have
to. You can get around it, but it's something you shouldn't have to do.
Also, a single file that uses a collection instiantiated on several
different types and several algorithms generates a huge amount of code.

I think what's going to happen is that once new C++ programmers start
having to contend with this stuff, *and* once people start realizing there
is stuff other than C++ out there (here, we're only taught LISP, and
that's not really viable -- and we're not taught much of it), then you'll
see some shift.

                                                    / ag

--
Andrew Geweke                           http://www.*-*-*.com/ ~gewekean/

What Apple, et al., have to do, is invent a new keyword that
encompasses some other cool aspect of Dylan that C++ doesn't have.
Then declare Dylan to be the only real contender in the class, and
sell it that way.

Then people won't be comparing it to C++ on C++'s terms, they'll be
looking at what defines the class that Dylan is a part of (possibly
the only member of), and why that's better/worse than Object
Orientation.

In other words, take some marketing cues from Microsoft.

        --Sam

--------------------------------------------------------------------------
Samuel J. Kass - "There is no {*filter*}Space, just a lot of people pretending"
Software Engineer, Visus (Visual Understanding Systems) Technologies, Inc.
Custom Image Recognition, Page Decomposition, and OCR technologies.

Seth

(for ((i (initial-state collection) (next-state collection i)))
     ((not i) #f)
  .. some operation on (current-element collection i) .. )

It's likely that in STL's case, the function calls will be inlined,
while in Dylan's case, it's much less likely.  (If you were to inline
them, you'd need to know the specific collection class, which would
give you a code explosion like C++ templates.)

(No, I'm not trying to argue that C++ is better; just that the
 particular example you gave is not inefficient.)

        - Amit

Dylan looks to me like a reasonable approach, and I think that the
language *is* important.  Maybe for trivial programs it doesn't matter
if it's lisp or c or c++ or Pascal or dylan or fortran or what.  But
for large bodies of code, with multiple threads of execution, with
distributed objects, with real-time performance requirements, with
reasonably complicated relationships between object types, with the
requirement to interface with other languages and with GUIs in a
portable and reliable manner, the nuances of the language can make the
difference between code being a dream and a nightmare.  I believe that
a decent dynamic language with a reasonable syntax, support for code
modularity, a real object system, threads, exceptions, powerful
macros, decent runtime footprint, and a good optimizing compiler can
go a long way towards making some things a little easier to swallow.
I haven't followed Dylan closely enough to know exactly which of these
it has, but my feeling is that it's a big step ahead of c++ in a lot
of them, especially syntax, objects, and macros.

Environment isn't everything.  It's important, but if you don't
have a good language underneath, a pretty environment is little
more than {*filter*}.

Bill Gribble

        for (x in collection1, y in collection2)
           ....
        end for;

This will terminate when either collection is exhausted.  The second
question one, if I'm interpretting you correctly, in a hypothetical
version of Dylan might look like this:

        for (elt satisfying predicate? in collection)  // not real Dylan

and would only iterate over those elements over collection that are
greater than 3.  In real Dylan, the for() macro can't do that, but you
can do it using the forward-iteration-protocol.  Why you'd want to is
beyond me; I'd think

        for (elt in collection)
          if (elt.predicate?)
            do-something();
          else
            // do nothing
          end if;
        end for;

would do the job.

One *useful* thing you can do with the forward-iteration-protocol but
not with the for() macro is modify the elements:

        for (elt in coll)
          if (elt.predicate?)
            elt := new-value();      // Doesn't do what you expect
          end if;
        end for;

That'll change the binding of elt, but it won't mutate coll.  If
that's what you want to do, you'll need to use the
forward-iteration-protocol.  (Fortunately, every time I've wanted to
do this I could use a vector and write for (i from 0 below vec.size)
instead)
--

-Nick Kramer

Martin
--
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

 BSD User Group Hamburg, Germany   http://www.bik-gmbh.de/~cracauer

Rich Gillam
Taligent