Sudden interest in Dylan/Dylan should be open. 
Author Message
 Sudden interest in Dylan/Dylan should be open.

Originally the Newton was supposed to have been Dylan based but
Apple lamed out on us.  It seems like it would have been a perfect
marriage but the kool-aid just wasn't sweet enough I guess for the
management people at Apple.  There's still hope though... one of
the engineers recently e-mailed me and reminded me that it could
still be implemented at any level on the Dylan.  Still, having
been around Apple before I suspect that it will never happen.
Maybe I'm completely clueless though and some brilliant group of
engineers will pull it off no thanks to the company in general.

I have my paranoia about Dylan.  I REALLY like it, mind you.  I just
wonder if it really has a future.  It has a lot to offer... mainly
in that it allows you (evidently) to have a object-oriented language
that can be interpreted dynamically.  It doesn't have to carry it's
development system around with it like Lisp or Smalltalk normally
do.  It can be VERY SMALL which I still think is neat even though
a lot of people thing that "small software" is unimportant.

However it isn't completely open.  Apple ought to just let it go and
let us (the engineers) have our way with it.  (oooh.)  We don't need
to have another experience like the "objective-c" tragedy... where
a truly and obviously superior language falls prey to a terribly
inadequate language (i.e. C++).  

I think that Dylan really needs an "edge" in order to make it.  An
implementation for Newton might help if it were done well.  Opening
it up for development to the university and small-business crowd
also wouldn't suck.

my .02 worth...

--thomas--

--
Thomas Pfaff

(707) 794-1511
e-mailing you from Sonoma CoWnty, California.



Tue, 06 Feb 1996 05:35:28 GMT  
 Sudden interest in Dylan/Dylan should be open.

Quote:

>Originally the Newton was supposed to have been Dylan based but
>Apple lamed out on us.

Are you sure?  I thought it was originally C++ based (as it still is)
and the Dylan reimplementation came along later (too late, unfortunately).

Quote:
>There's still hope though... one of
>the engineers recently e-mailed me and reminded me that it could
>still be implemented at any level on the Dylan.  Still, having
>been around Apple before I suspect that it will never happen.

It already has.  It's being archived.  I heard that about 40% of the
system was reimplemented (smaller annd as fast or faster) as proof
that it could be done.  As I heard it, no technical obstacle remained
to prevent having a completely Dylan-based Newton.

Quote:
>Maybe I'm completely clueless though and some brilliant group of
>engineers will pull it off no thanks to the company in general.

Actually, the company funded the work, so I hear.  The decision not
to use it was an internal political squabble among the engineers at
first (not a technical disagreement, but rather a C++ programmer
dislike for Dylan).  Later, the amount of time it would take to
complete the system in Dylan would have required either supporting
two implementations of the same software for a little while or
further delaying the Newton.  So, the *obvious* choice was to make
C++ programmers out of the Dylan folks...

If you think that's bad, compare using Newton Script to using Dylan...

Of course, I don't work at Apple, so what do I know.  I probably just
made all that stuff up... :-)

D



Tue, 06 Feb 1996 15:03:41 GMT  
 Sudden interest in Dylan/Dylan should be open.
: However it isn't completely open.  Apple ought to just let it go and
: let us (the engineers) have our way with it.  (oooh.)  We don't need
: to have another experience like the "objective-c" tragedy... where
: a truly and obviously superior language falls prey to a terribly
: inadequate language (i.e. C++).  

No, no, no, no, no, no, NO! If Apple were to do this, we'd end up with
Lisp all over again. Every version of Dylan would be different, and
they'd all be incompatible. Standards are, in general, a Good Thing.
Trademarking "Dylan" is, IMHO, a Good Thing. Letting every random
implementor add new features to a language is, in general, a Bad
Thing. Just look at Lisp. Everybody just had their way with it and
eventually there were a million different, incompatible
implementations: Lisp 1.5, Lisp Machine Lisp, InterLisp, ZetaLisp,
Emacs Lisp, MockLisp, MacLisp, Spice Lisp,  NIL, ...

BTW, I'm not convinced that Objective-C is inherently better than C++.
Both languages have their share of problems, though admittedly C++ has
a bigger share than Objective-C :-) The reasons that C++ made it while
Objective-C did not are: AT&T is HUGE while Stepstone in not, and AT&T
gave universities a very big discount on CFront when the language was
originally made available.

: I think that Dylan really needs an "edge" in order to make it.  An
: implementation for Newton might help if it were done well.  Opening

Who cares if there is a Dylan implementation for Newton? Who cares if
the Newton Toolbox was implemented in Dylan? Currently, Newton is the
128K Mac of the '90s: it doesn't have enough RAM, it doesn't have
enough PCMCIA slots, it comes bundled with the only applications that
exist, the screen is too small (IMHO), there's no networking or
communication to speak of, and it's too expensive. Sound familiar?

Don't get me wrong, I think that Newton is a cool idea which will
eventually have a major impact on the market. But, Newton has
*absolutely nothing* to do with the success or failure of the Dylan
language.

What Dylan needs is for Apple to finish the language and kick it out
the door. IMHO, the language is losing serious momentum because it's
been on the Vaporware list for so long. We can debate all we want
about how great the language is, harangue our friends and co-workers
about the power of OODLS, have endless discussions of why dynamic
typing is cool, and compare it to Smalltalk (& Scheme & CLOS) ad
nauseum, but until people can actually ship products implemented in
Dylan the rest of the industry isn't going to give a hoot.

And that's *my* two cents worth...

                                                        -- Scott

--
==============================================================================
"The only thing necessary for the triumph  "DOS is proof that there *is*
 of evil is for good men to do nothing."    Evil in the world."
                        -- Edmund Burke                 -- James Plamondon
==============================================================================



Tue, 06 Feb 1996 15:47:14 GMT  
 Sudden interest in Dylan/Dylan should be open.

Quote:
>No, no, no, no, no, no, NO! If Apple were to do this, we'd end up with
>Lisp all over again. Every version of Dylan would be different, and
>they'd all be incompatible. Standards are, in general, a Good Thing.
>Trademarking "Dylan" is, IMHO, a Good Thing. Letting every random
>implementor add new features to a language is, in general, a Bad
>Thing. Just look at Lisp. Everybody just had their way with it and
>eventually there were a million different, incompatible
>implementations: Lisp 1.5, Lisp Machine Lisp, InterLisp, ZetaLisp,
>Emacs Lisp, MockLisp, MacLisp, Spice Lisp,  NIL, ...

Come on, Lisp has changed over time because new insights made
improvements possible. This is valid for most languages.
Most of the old lisp dialects are now obsolete. Competition
is always good. Let Common Lisp die, if we tommorrow have something
better.

Quote:
>: I think that Dylan really needs an "edge" in order to make it.  An
>: implementation for Newton might help if it were done well.  Opening

>Who cares if there is a Dylan implementation for Newton? Who cares if
>the Newton Toolbox was implemented in Dylan?

I would. But NewtonScript is nice too. It has a lot of features from Lisp.
An implementation of an OS in Dylan would help it in two ways:

1) it is always better to have complete integration of a language
and OS in order to have *complete* access to the environment.
It also would help in market aceptance. There should be an C++
compiler for the Newton. But the only (at least for me)
available development system uses NewtonScript. So programmers for
the Newton are forced to use NewtonScript.

2) designing such a complex software as parts of an OS would
help to improve the language implementation, since the pressure
on the language implementors would increase to create safe/fast/small
code from the compiler.

Quote:
> Currently, Newton is the
>128K Mac of the '90s: it doesn't have enough RAM, it doesn't have
>enough PCMCIA slots, it comes bundled with the only applications that
>exist, the screen is too small (IMHO), there's no networking or
>communication to speak of, and it's too expensive. Sound familiar?

That is complete nonsense. The Newton has enough RAM to be useful.
Data is being compressed by the Newton.
Adding memory is easy. Just use one of these PCMCIA cards. You must have
a very different computer in mind. The Newton/MessagePad design is very
practical for its tasks. And it has networking and communcation
functions. I have one. :-) I can tell you.

Quote:
>Don't get me wrong, I think that Newton is a cool idea which will
>eventually have a major impact on the market. But, Newton has
>*absolutely nothing* to do with the success or failure of the Dylan
>language.

Correct. I wouldn't call Dylan a failure if it doesn't
live up to the expectations (providing Dylan as an alternative
to programmers using "static" languages). But being pessimistic/realistic
as I am, I see no (absolutely **no**) chance for Dylan in the mainstream.
It remains to be see how many programmers can be converted from
C/Pascal/C++. And this is most of the time not a question of
the individual programmer, but this is decided by management.

Rainer Joswig



Tue, 06 Feb 1996 17:38:53 GMT  
 Sudden interest in Dylan/Dylan should be open.

   But being pessimistic/realistic
   as I am, I see no (absolutely **no**) chance for Dylan in the mainstream.
   It remains to be see how many programmers can be converted from
   C/Pascal/C++. And this is most of the time not a question of
   the individual programmer, but this is decided by management.

I agree that however unfortunate, Dylan (or Lisp or Scheme or Prolog or SML
or ...) has a slim chance of success in the mainstream market. Part of the
problem is run-time compiled-code efficiency. The Dylan effort is address that
very well. But an even bigger part of the problem is the momentum of the
marketplace and the education of programmers (more general than what you
called management). Most programmers are incredibly unsophisticated. They have
no notion of abstraction. No notion of a function which transforms one
representation into another. No notion of operators which combine
transformations. They write programs that move single values around in memory.
C++ is little more than glorfied assembler the way most people use it. Look at
real programmers out there and the code they write. Count the percentage of
lines of C++ programs that are assignment statements that move non-agregate
data. I don't mean to insult any person on this list. There are clearly many
good programmers out there who program and design algorithms at a much higher
level. (I bet there is a high correlation between the set of such people and
the set of readers of this list.) This can be done is Dylan, Scheme, Prolog,
Lisp, SML, Haskell, or C/C++ for that matter. We all believe that things in
OODLs and function languages make this more conducive than in C/C++, which is
why people are trying promote Dylan. But I guess that if you gave Dylan to the
vast majority of current programsers, they would use it like the way they used
 C++, which is in turn the way they used C, which is in turn the way they used
BASIC, ...

Let me give you an example. There is a grad student who recently showed me
some `nice OBJECT ORIENTED C++ code' she had written. Every, and I mean every,
procedure returned an error code. She claimed that she was familiar with
`professional industrial programming practise' had been taught that that was
the way to make robust code. That meant that she couldn't write a FUNCTION.
Every procedure had to return its results by side effecting either an argument
or a global data structure. (Not that that is bad, there are times whent that
is appropriate.) But with here style she couldn't combine functions, think
about the process of data manipulation here program was doing, or abstract
control structures. It turned out that the hundreds of lines of beautifull
object oriented C++ code that she had written, spread across a dozen files
repleat with #include headers, private protocol definitions and all the rest
WAS ALGORITHMICALLY NOTHING MORE THAN A *SINGLE* TABLE LOOKUP. The honest
truth: one line of properly written code in almost any language.

Now she is getting her PhD in computer science.

This is not an isolated example. I taught graduate AI here at UPenn last fall.
When I teach I use an extension of CommonLisp that I've written called
Screamer which adds backtracking and constraint satisfaction. The nice thing
about this is that it allows separating the search strategy from the
specification of the search space. I spent a good part of the semester showing
how many of the classic AI programs can be reformulated and solved in short
easily understood Screamer programs. I also show how much of the progress in
AI can be formulated as simple transformations on these programs. Things like
memoization, partial evaluation, lifting, partial-order vs. total order,
changes in evaluation order. I can show how the differences between many
parsing algorithms and grammer formalisms (like Early, CKY, Tomita, DCG, ATN)
can be expressed as small changes, often a single line or even A SINGLE WORD
change to a properly written program. How you can turn a parser into a model
of language acquition by a lifting transformation combined with a change of
search order. How you can perform the model-feature-point matching of model
based vision using the same constraint satisfaction techniques (and even code)
as nonlinear-planning.

With all of this I had to teach good programming style to many grad students
who had never learned Lisp. Moreover, most had never even learned how to
program recursively. Recursion, or structural induction forms the basis of
most of the logical foundation of AI and computer science. And I had to teach
this to grad students.

Towards the end of the course, several of the students commented to me that
they were getting into trouble because they were trying to solve their problem
sets and term projects in their operating systems course using the programming
style (and most of thaught) I had taught them. Their professor was criticizing
them. Some thought that they were `tainted' by having taken my course. I
simply smiled an felt successful in having made my modest conribution to their
education.

The biggest problem as I see it is in education. Sussman and Ableson tried to
change that with 6.001. Teach undergrads from the start how to *THINK* in high
level yet precise terms and bridge the gap via abstraction. But unfortunately
that has not caught on very much in the mainstream. Most universities have
given up or are giving up on teaching 6.001 derivatives. I personally have
experienced such debates at Berkeley, UPenn, Harvey Mudd. A big part of the
problem is that even most university professors of computer science lack
sophistication in their programming accumen. They aren't even aware of what
their missing. I've heard many famous professors vehemently argue for the
virtues of teaching C as the first programming language and how C is inherently
based on optimal design decisions, or how students don't need to know anything
that is taught is 6.001, or how a C-based course prepares the students better
for all subsequent non-AI courses in the curriculum and that only AI students
need to learn Lisp/Scheme. These are prominent professors in world-class
institutions saying this. It takes years, perhaps several academic
generations, to completely retrain professors to retrain their students in how
to think and program before Dylan will catch on.
        Jeff



Wed, 07 Feb 1996 00:19:46 GMT  
 Sudden interest in Dylan/Dylan should be open.

Quote:

> Most universities have
>given up or are giving up on teaching 6.001 derivatives. I personally have
>experienced such debates at Berkeley, UPenn, Harvey Mudd. A big part of the
>problem is that even most university professors of computer science lack
>sophistication in their programming accumen.

I don't know about those other places, but don't worry, we're not giving up
on SICP at Berkeley!  There are only about four hard-core right-wingers on
the faculty who don't understand the virtues of the course, and they always
bring up moving away from it, and they're always voted down.

(Sorry this doesn't really have anything to do with Dylan...  I do agree
that there will be more substantive talk about Dylan in the newsgroup once
Apple releases a product and we start having code to look at.)



Wed, 07 Feb 1996 01:41:34 GMT  
 Sudden interest in Dylan/Dylan should be open.

Quote:

>   But being pessimistic/realistic
>   as I am, I see no (absolutely **no**) chance for Dylan in the mainstream.
>   It remains to be see how many programmers can be converted from
>   C/Pascal/C++. And this is most of the time not a question of
>   the individual programmer, but this is decided by management.

>I agree that however unfortunate, Dylan (or Lisp or Scheme or Prolog or SML
>or ...) has a slim chance of success in the mainstream market. Part of the
>problem is run-time compiled-code efficiency. The Dylan effort is address that
>very well. But an even bigger part of the problem is the momentum of the
>marketplace and the education of programmers (more general than what you
>called management).

When I was in grad school I took a compilers course.  Everyone else in
the course did their work in Pascal or C.  I used Lisp.  Everyone else
was handing in printouts that were two inches thick.  My entire compiler
(parser and all) was about ten pages of code.

Dylan has a chance in the mainstream when people start to see that
the applications programmers using Dylan are producing more reliable code
ten times faster than those using C.

Erann Gat



Wed, 07 Feb 1996 02:52:09 GMT  
 Sudden interest in Dylan/Dylan should be open.

|> >
|> >   But being pessimistic/realistic
|> >   as I am, I see no (absolutely **no**) chance for Dylan in the mainstream.
|> >   It remains to be see how many programmers can be converted from
|> >   C/Pascal/C++. And this is most of the time not a question of
|> >   the individual programmer, but this is decided by management.
|> >
|> >I agree that however unfortunate, Dylan (or Lisp or Scheme or Prolog or SML
|> >or ...) has a slim chance of success in the mainstream market. Part of the
|> >problem is run-time compiled-code efficiency. The Dylan effort is address that
|> >very well. But an even bigger part of the problem is the momentum of the
|> >marketplace and the education of programmers (more general than what you
|> >called management).
|>
|> When I was in grad school I took a compilers course.  Everyone else in
|> the course did their work in Pascal or C.  I used Lisp.  Everyone else
|> was handing in printouts that were two inches thick.  My entire compiler
|> (parser and all) was about ten pages of code.
|>
|> Dylan has a chance in the mainstream when people start to see that
|> the applications programmers using Dylan are producing more reliable code
|> ten times faster than those using C.
|>
|>
|> Erann Gat

|>

  I too did my grad compiler course project on a subject related to lisp, garbage
collection. When done, the professor and the rest of the class decided that
garbage collection and run time systems had nothing to do with compilers and
language design. Oh well, some people (when I'm being cynical, I'd say all
people) are hopeless. :-)

  Mike McDonald                         Advanced Technology Dept.      
                                        Harris Corp.

  Voice: (407) 727-5060                 P.O. Box 37
  Fax:   (407) 729-3363                 Melbourne, Florida 32902



Wed, 07 Feb 1996 03:42:35 GMT  
 Sudden interest in Dylan/Dylan should be open.

    .... It takes years, perhaps several academic
    generations, to completely retrain professors to retrain their students in how
    to think and program before Dylan will catch on.

Well, then, we'd better get started.  :-)

At least we can provide some good options for those few people out there
with the sense to use them.  Maybe it will snowball from there; maybe not.

I think that Dylan has a shot at infiltrating the world from the grass
roots up if we can get good implementations and good teaching materials
into the hands of the high-school kids.  So getting that done somehow is an
important part of the picture.  (That's one reason why Apple might be the
right company to lead this crusade.)

-- Scott

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

Senior Research Scientist               Phone:     412 268-2575
School of Computer Science              Fax:       412 681-5739
Carnegie Mellon University              Latitude:  40:26:33 N
5000 Forbes Avenue                      Longitude: 79:56:48 W
Pittsburgh, PA 15213
===========================================================================



Wed, 07 Feb 1996 03:47:05 GMT  
 Sudden interest in Dylan/Dylan should be open.


Quote:

> I agree that however unfortunate, Dylan (or Lisp or Scheme or Prolog or SML
> or ...) has a slim chance of success in the mainstream market. Part of the
> problem is run-time compiled-code efficiency. The Dylan effort is address that
> very well. But an even bigger part of the problem is the momentum of the
> marketplace and the education of programmers (more general than what you
> called management). Most programmers are incredibly unsophisticated. They have
> no notion of abstraction. No notion of a function which transforms one
> representation into another. No notion of operators which combine
> transformations.

Don't forget Academic snobbery.  I don't understand how or why this
holier-than-
thou attitude persists amongst the functional/dynamic language communities
toward programers who use C/C++, Asm, & Pascal.  I always get this constant
sense of *OUR* way is *THE ONLY CORRECT WAY* to program.  Unfortunately it
is not only false, it reflects very unflatteringly on the community and
discourages people from using languages like LISP, ML, or now Dylan.

I think if you look at a significant number of the programmers in leading
software companies, you'd find that they are quite adept with sophisticated
methods of programming, but their work does not require it.  However, I
also think you should reconsider your definition of what constitutes a
sophisticated programmer. I think you would be surprised at the number of
commercial programmers relying heavily on theoretical computer sciece.

Quote:
> They write programs that move single values around in memory.
> C++ is little more than glorfied assembler the way most people use it. Look at
> real programmers out there and the code they write. Count the percentage of
> lines of C++ programs that are assignment statements that move non-agregate
> data.

This might be true, but it is certainly        has much more to do with the
models of data that most commerical programmers deal with, than it has to
do with their level of sophistication.  Most data is still delt with
numerically rather than symbollically.  Data, for the majority of
applications, is not much more than a chunk of bytes with no real relation
to the "object" represented.  Fonts, for example, are generally stored as
bit-maps or B-spline curves rather than in some symbolic form based upon
typographal discriptions.  With the advent of new languages such as C++,
the models of data in use are evolving toward object oriented and dynamic,
as they continue to evolve you will probably begin to see a shift in the
methods used by commericial programmers.

Quote:
> Let me give you an example.

[blah..blah..blah.. stuff about grad students who are clueless 'bout
recursion]

Since  y ou've already told us how poorly you graduate students are
prepared, it makes no sense to compare the majority of commerical
programmers to them.

Quote:
> Towards the end of the course, several of the students commented to me that
> they were getting into trouble because they were trying to solve their problem
> sets and term projects in their operating systems course using the programming
> style (and most of thaught) I had taught them. Their professor was criticizing
> them. Some thought that they were `tainted' by having taken my course. I
> simply smiled an felt successful in having made my modest conribution to their
> education.

ObUgradComment: As a university student I find it unfortunate that you have
this attitude toward your teaching because it seems like these students can
really benefit from your guidance , but that belongs elsewhere...

Quote:

> The biggest problem as I see it is in education.

Yup...education demands that we all get on with the serrious business of
real programming with all its formalisms and abstractions, and what not.
Students are no longer encouraged to just {*filter*} around with the machine and
see what happens and they become commerical programmers who are
uninterested in experimenting with something new.

BTW - they said C++ would never get adopted by the mainstream either.



Wed, 07 Feb 1996 13:19:01 GMT  
 Sudden interest in Dylan/Dylan should be open.

   Don't forget Academic snobbery.  I don't understand how or why this
   holier-than-
   thou attitude persists amongst the functional/dynamic language communities
   toward programers who use C/C++, Asm, & Pascal.  I always get this constant
   sense of *OUR* way is *THE ONLY CORRECT WAY* to program.  Unfortunately it
   is not only false, it reflects very unflatteringly on the community and
   discourages people from using languages like LISP, ML, or now Dylan.

I think the "snobbery" you decry is often the result of:

- A basic difference in bargaining position.  The dynamic-language
advocate must typically argue for a radical change from the
established ways of doing things; the static-language advocate need
only assert that the current ways are "good enough," and that any
more-than-cosmetic change is "risky."  Often the only effective
counter-argument is to assert that the current ways are fundamentally
wrong-headed.

- A major asymmetry in experience.  The dynamic-language advocate may
have extensive experience in several static languages, whereas the
static-language advocate may have no dynamic-language experience or
knowledge beyond vintage-1962 Lisp 1.5 (without an editor that can
count parentheses!).  It is often an appropriate and effective
argument in such a case to explicitly point out the other's lack of
knowledge of the subject matter.

- A serious difference in motivation.  The dynamic-language advocate
may have goals such as time to market, development cost, and
evolvability; the static-language advocate may have goals such as
political acceptability, maintenance of personal guru status, or
learning avoidance.  Again, it is often appropriate and effective in
such cases to point out that arguments like "Our peers will think
we're silly" and "Most of our people (who all have Master's degrees in
CS with amazingly high GPAs) can't program in that language" are not
in themselves sufficient reasons to reject all dynamic languages.

Clearly, these do not hold in every case, but I submit they are
partly, perhaps primarily, responsible for the "snobbery" you
perceive.
--
        Lawrence G. Mayka
        AT&T Bell Laboratories

Standard disclaimer.



Fri, 09 Feb 1996 06:23:22 GMT  
 Sudden interest in Dylan/Dylan should be open.

Quote:
>   But being pessimistic/realistic
>   as I am, I see no (absolutely **no**) chance for Dylan in the mainstream.
>   It remains to be see how many programmers can be converted from
>   C/Pascal/C++. And this is most of the time not a question of
>   the individual programmer, but this is decided by management.
>I agree that however unfortunate, Dylan (or Lisp or Scheme or Prolog or SML
>or ...) has a slim chance of success in the mainstream market. Part of the
>problem is run-time compiled-code efficiency. The Dylan effort is address that
>very well. But an even bigger part of the problem is the momentum of the
>marketplace and the education of programmers (more general than what you
>called management). Most programmers are incredibly unsophisticated. They have
>no notion of abstraction. No notion of a function which transforms one
>representation into another. No notion of operators which combine
>transformations. They write programs that move single values around in memory.
>C++ is little more than glorfied assembler the way most people use it. Look at
>real programmers out there and the code they write. Count the percentage of
>lines of C++ programs that are assignment statements that move non-agregate
>data. I don't mean to insult any person on this list. There are clearly many
>good programmers out there who program and design algorithms at a much higher
>level. (I bet there is a high correlation between the set of such people and
>the set of readers of this list.) This can be done is Dylan, Scheme, Prolog,
>Lisp, SML, Haskell, or C/C++ for that matter. We all believe that things in
>OODLs and function languages make this more conducive than in C/C++, which is
>why people are trying promote Dylan. But I guess that if you gave Dylan to the
>vast majority of current programsers, they would use it like the way they used
> C++, which is in turn the way they used C, which is in turn the way they used
>BASIC, ...
>Let me give you an example. There is a grad student who recently showed me
>some `nice OBJECT ORIENTED C++ code' she had written. Every, and I mean every,
>procedure returned an error code. She claimed that she was familiar with
>The biggest problem as I see it is in education. Sussman and Ableson tried to
>change that with 6.001.

                  ^^^^^

Excuse me, what is this?

--
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

------ C is a good language - for implementing programming systems -------



Fri, 09 Feb 1996 14:58:23 GMT  
 
 [ 14 post ] 

 Relevant Pages 

1. Dylan Barriers (was: Sudden interest in Dylan/Dylan should be open.)

2. archives of info-dylan/comp.lang.dylan available

3. Dylan vs DyLan

4. (fwd) harlequin's dylan-corba mailing list switching to MIT's info-dylan

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

6. Dylan and Java [was: Harlequin Dylan - Update]

7. Dylan Programming Book and Apple Dylan

8. Dylan, guys, Dylan.

9. Dylan is the Name was(Re: Dylan (Bob) eats rotten Apple (Computer))

10. Dylan alternative (was Dylan complexity)

11. c.l.dylan overlap with Dylan mailing lists?

12. Dylan, guys, Dylan.

 

 
Powered by phpBB® Forum Software