Dylan article in BYTE 
Author Message
 Dylan article in BYTE

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



Mon, 03 Aug 1998 03:00:00 GMT  
 Dylan article in BYTE

Quote:

> 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.


Thu, 06 Aug 1998 03:00:00 GMT  
 Dylan article in BYTE


   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



Sun, 09 Aug 1998 03:00:00 GMT  
 Dylan article in BYTE


...

Quote:
>>    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.

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:      :-)
===========================================================================



Sun, 09 Aug 1998 03:00:00 GMT  
 Dylan article in BYTE

Quote:

> 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.  

Yes, I think when commercial compilers start fully supporting STL,
exceptions, RTTI, and all the new ANSI features, and suddenly
legions of C++ programmers find themselves trying to USE these
features to keep up, find out just how hard they are to use well
and correctly, and how hard it is to find a compiler that can implement
them all correctly, there will be a whole new wave of potential
Dylan converts!

-Paul-

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



Mon, 10 Aug 1998 03:00:00 GMT  
 Dylan article in BYTE
[About Pountain's article in BYTE]

Quote:
>He also was a bit quick to call the game on account of darkness and
>award the prize to C++

What disturbs me most about Pountain's conclusion is that his logic
could be extended to any new language.  He said, basically, "There can
never be another successful object oriented programming language
because C++ is so entrenched."  Given the number of successful
imperative languages the world's seen, I find this logic strange at
best.
--

-Nick Kramer



Tue, 11 Aug 1998 03:00:00 GMT  
 Dylan article in BYTE


   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



Tue, 11 Aug 1998 03:00:00 GMT  
 Dylan article in BYTE


Quote:
>Yes, I think when commercial compilers start fully supporting STL,
>exceptions, RTTI, and all the new ANSI features, and suddenly
>legions of C++ programmers find themselves trying to USE these
>features to keep up, find out just how hard they are to use well
>and correctly, and how hard it is to find a compiler that can implement
>them all correctly, there will be a whole new wave of potential
>Dylan converts!

It's going to take a while, though. They just started teaching C++ here at
MSU, and by the time people graduate, they basically know what a class is,
the very sketchy basics of public vs. private vs. protected, and maybe a
little vague idea of what a template is and what it does. However, asking
many to write a non-trivial C++ program is way too much.

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/



Wed, 12 Aug 1998 03:00:00 GMT  
 Dylan article in BYTE

Quote:


> [About Pountain's article in BYTE]
> >He also was a bit quick to call the game on account of darkness and
> >award the prize to C++

> What disturbs me most about Pountain's conclusion is that his logic
> could be extended to any new language.  He said, basically, "There can
> never be another successful object oriented programming language
> because C++ is so entrenched."  Given the number of successful
> imperative languages the world's seen, I find this logic strange at
> best.

The problem is that Object Oriented is now tied to C++.

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.



Wed, 12 Aug 1998 03:00:00 GMT  
 Dylan article in BYTE

Quote:



>> [About Pountain's article in BYTE]
>> >He also was a bit quick to call the game on account of darkness and
>> >award the prize to C++

>The problem is that Object Oriented is now tied to C++.

>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.

I think the proper keyword is clearly embedded in the name of the
language: Dynamic.  I think the proper move, and in fact the move that
Apple was making, would be to push Apple Dylan as a fully dynamic
environment.  I think Visual Basic has succeeded to a large extent
because of it's dynamic environment.  It presents an environment in
which it is easy to make changes and see the effects quickly.  This
appears to be exactly what Apple was working toward with Apple Dylan.
I think a really good environment, a good GUI class library, a good
interface builder, and a good language could create a real killer
product.  Too bad Apple appears to have dropped the ball.  I wish
Harlequin luck!

Seth



Sat, 15 Aug 1998 03:00:00 GMT  
 Dylan article in BYTE

Quote:

>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.

Doesn't Dylan also require two function calls for each iteration
through the loop?  I haven't seen the new syntax, but in the old
syntax, it's very similar to STL's loop:

(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



Sun, 16 Aug 1998 03:00:00 GMT  
 Dylan article in BYTE

Quote:

> I agree but I don't think language is a very important piece in
> this. Dynamism as you say is a feature of the environment. Not
> necessarily of the language. Such environments already exist under
> unix with C++ and to a certain extent Windows.  With Borland and
> other tool developers, there is no telling what new environments
> will bring. I really don't think a new language is needed.

You don't think a new language is needed by... who?  Yourself?  Fine.
You're the only one qualified to make that determination.  As for me,
I use c++ every day, and don't think I'm knocking it.. it's let me
write the code I needed to write, right now.  But I'm about fed up to
here with its idiosyncracies and ugliness.. although I can't see an
alternative right now that would let me do what I have to do any more
reasonably.

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



Wed, 19 Aug 1998 03:00:00 GMT  
 Dylan article in BYTE

Quote:

>: While the meaning is basically the same, the new syntax is much sexier:

>: for(i in some-collection)
>:   do-something(i);
>: end for;

>This is nice.  But can you have *simultaneous* loops through collections?
>(i.e. break out when either one reaches the end).  Can you return
>a new element using *run-time* computed quantities?  (i.e. next element
>greater than some value)

Yes on both counts.  The first is supported by the for() macro:

        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



Mon, 24 Aug 1998 03:00:00 GMT  
 Dylan article in BYTE

Quote:



>>The problem is that Object Oriented is now tied to C++.

>>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.
>The ability to edit a program's code while it is running will seriously
>shorten development time.  I'm not a marketer, but I'd recommend Dylan
>implementors to sell this particular feature.

That's what most Lisp vendors do these days. Especially Franz
Inc. talks about "dynamic languages".

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

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



Mon, 24 Aug 1998 03:00:00 GMT  
 Dylan article in BYTE

Quote:
> 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)

Can't you just use replace-elements!() to do this?  I thought that's
what it was for, and it'd get your code down to one line.

Rich Gillam
Taligent



Tue, 25 Aug 1998 03:00:00 GMT  
 
 [ 27 post ]  Go to page: [1] [2]

 Relevant Pages 

1. BYTE Magazine article

2. BYTE Magazine APL Article

3. Byte.com article on JVM and .NET CLR

4. BYTE mag article on unreliable PC's

5. BYTE article

6. Byte article! (fwd)

7. Byte article!

8. Article on Constraint Logic Programming from BYTE Feb 1995

9. BYTE article on scripting languages

10. German Dylan Article in www.linuxenterprise.de

11. SunWorld article on Dylan

12. Dylan Article...

 

 
Powered by phpBB® Forum Software