Why not MCL? 
Author Message
 Why not MCL?

Uh, why not use MCL? It's better than Dylan, it's mature, stable and PPC
native.

Really neat would be the Dylan IDE for MCL, which *does* need a little
IDE polish.

Just wondering,

Ken



Sun, 08 Nov 1998 03:00:00 GMT  
 Why not MCL?

Quote:

> Uh, why not use MCL? It's better than Dylan, it's mature, stable and PPC
> native.

I think the "it's better than Dylan" part is the one that I have a hard
time swallowing. Are you just out to troll for flames? Dylan:

- has a syntax that is more comfortable to the majority of the world's
software developers (not infix);

- has features that are designed to produce optimized and reasonably-
sized compiled code;

- is much more suited for delivering finished applications.

Don't get me wrong - MCL is very nice, but it's an enormous language,
not optimized for delivery, and too bizarre to capture C++ programmers.

-Paul-

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



Sun, 08 Nov 1998 03:00:00 GMT  
 Why not MCL?



: > Uh, why not use MCL? It's better than Dylan, it's mature, stable and PPC
: > native.

: I think the "it's better than Dylan" part is the one that I have a hard
: time swallowing. Are you just out to troll for flames? Dylan:

: - has a syntax that is more comfortable to the majority of the world's
: software developers (not infix);
                           ^^^^^

I think Paul meant to say "not prefix". And I agree to a fair extent.
Actually, I think what makes LISP harder for C/C++ programmers is that to
do it really well you tend to do most everything in a very recursive
style. LISP lends itself to recursion (and so does Dylan though it's less
obvious) and that just isn't how C/C++ programs are usually coded. The
programming mindset for LISP is the big kicker in this for C/C++ programmers.

By the way, I'm not knocking MCL. I do think the UI could be much better
(Dylan's IDE is much nicer for me to work with).

  ** Ken **

--
****     Kenneth Knight    IA, Inc.   Software Engineer    ****
****     voice: (313)-995-9338     fax: (313)-995-9338     ****



Sun, 08 Nov 1998 03:00:00 GMT  
 Why not MCL?


: I think Paul meant to say "not prefix". And I agree to a fair extent.
: Actually, I think what makes LISP harder for C/C++ programmers is that to
: do it really well you tend to do most everything in a very recursive
: style. LISP lends itself to recursion (and so does Dylan though it's less
: obvious) and that just isn't how C/C++ programs are usually coded. The
: programming mindset for LISP is the big kicker in this for C/C++ programmers.

That was a big reason I liked Dylan more than LISP. We had Franz
Allegro Common Lisp installed on our machines here at MSU; I learned
it to a small degree for an AI course. By the end of the semester,
I'd learned enough LISP to begin to understand how you attack
problems in it -- it's totally backwards from how you attack them
in C++. (Better in some cases, worse in others; in many, just 'different'.)

As a C++ programmer, Dylan was eminently easier to write stuff in
once I learned the whole bit about how variables were *references*,
not *value objects*. (Interestingly, Java works this way too except
for the built-in types.) LISP still left me baffled -- I guess it was
that in a month or so I could easily learn enough Dylan that when
I got to something new I could figure out how to do it easily, while
after a semester some things in LISP still left me clueless.

No language wars here; all this is saying is that Dylan is a lot
easier for C++ programmers to pick up than LISP. (Java's even easier,
but then again, Java's significantly less powerful and elegant than
Dylan, while LISP is not.)

                                        / ag



Sun, 08 Nov 1998 03:00:00 GMT  
 Why not MCL?

[Andrew Robert Geweke]

|   That was a big reason I liked Dylan more than LISP.  We had Franz
|   Allegro Common Lisp installed on our machines here at MSU; I learned it
|   to a small degree for an AI course.  By the end of the semester, I'd
|   learned enough LISP to begin to understand how you attack problems in
|   it -- it's totally backwards from how you attack them in C++.  (Better
|   in some cases, worse in others; in many, just 'different'.)
|  
|   As a C++ programmer, Dylan was eminently easier to write stuff in once
|   I learned the whole bit about how variables were *references*, not
|   *value objects*.  (Interestingly, Java works this way too except for
|   the built-in types.)  LISP still left me baffled -- I guess it was that
|   in a month or so I could easily learn enough Dylan that when I got to
|   something new I could figure out how to do it easily, while after a
|   semester some things in LISP still left me clueless.
|  
|   No language wars here; all this is saying is that Dylan is a lot easier
|   for C++ programmers to pick up than LISP.  (Java's even easier, but
|   then again, Java's significantly less powerful and elegant than Dylan,
|   while LISP is not.)

this is very interesting.  personally, I cannot bring myself to wrap my
head around C++.  I have been programming in a Lisp-like fashion in most
languages for the past 17 years, only I didn't know it until I had the
opportunity to use Lisp for real two years ago.  (not counting two more
years of Emacs Lisp.)  to me, C++ is backwards, and I just can't hack what
I perceive as irrationalities in the design.  obviously, this is not the
common impression.

my conclusion: there are differences between people that dictate their
"mode of thinking about programming" -- some lean towards prefix and words,
other towards infix and special syntactic symbols.  obviously, the prefix
type programmers are far fewer than the infix type programmers, and I draw
no conclusion from numbers alone (please), but I think we should realize
that these differences may be like personality types in that they are
partly innate and that one can only benefit from knowing what one's type
is.  the next step is, of course, recognition in the market that neither is
inherently superior to the other, nor that all problems should be solved in
only one language by only one type of programmer.

there is most probably something far deeper than taste or first exposure to
all this.  I'd love to find out what, if only to understand the "language
wars" that rage so often, as well as the operation of "popularity" (which I
have never quite grasped, either).  incidentally, I think Dylan's infix
syntax is ugly, but it's far easier to write Dylan from a Lisp program than
to write C++ from a Lisp program.



Mon, 09 Nov 1998 03:00:00 GMT  
 Why not MCL?

Quote:


> [snip]
> : Actually, I think what makes LISP harder for C/C++ programmers is that to
> : do it really well you tend to do most everything in a very recursive
> : style.

I think that was true in the old days. And I first encountered Lisp in the form of a Logo which indeed
offered *only* recursion as a way of iterating. But Common Lisp now has quite a few ways to iterate and
loop without getting into recursion. And some rough benchmarks I did suggested they were *faster* than
recursion (in MCL, anyway) so I use them a lot.

 LISP lends itself to recursion (and so does Dylan though it's less

Quote:
> : obvious) and that just isn't how C/C++ programs are usually coded.

Oops. I guess my Logo experience affected my C, because I am comfortable with recursion and use it in
my C code, or any language (such as VAX Basic) that supports recursion. So I am probably a little
out-of-synch with those who progressed from fortran to Basic to C.

 The

Quote:
> : programming mindset for LISP is the big kicker in this for C/C++ programmers.

> That was a big reason I liked Dylan more than LISP. We had Franz
> Allegro Common Lisp installed on our machines here at MSU; I learned
> it to a small degree for an AI course. By the end of the semester,
> I'd learned enough LISP to begin to understand how you attack
> problems in it -- it's totally backwards from how you attack them
> in C++.

I wonder if it wasn't the AI algorithms that led to heavy recursion and the radical shift you
experienced in "how you attack". ie, I am wondering if you would have experienced the same paradigm
shift had the AI course been undertaken in C.

Quote:

> No language wars here; all this is saying is that Dylan is a lot
> easier for C++ programmers to pick up than LISP.

Agreed, no language war. My orignal remark was, well, *if* Dylan does not make it to daylight *and* one
still wants a dynamic, GCed, awesome OOed, fast, compiled, powerful language with macros (sorry
Smalltalk <g>)--why not look at Common Lisp, esp Mac Common Lisp? (I promise (1) you will come to love
prefix and (2) after a week you will not even *see* the parentheses--but you will love them too.

That was how I "discovered" CL last year. I was giving up on Dylan when an MCL fan tipped me off.

I owe him *big*, and try to pass on the favor when I can.



Tue, 10 Nov 1998 03:00:00 GMT  
 Why not MCL?

Quote:

> Uh, why not use MCL? It's better than Dylan, it's mature, stable and PPC
> native.

Yes, why not use MCL?

Dylan was a mistake in the first place (IMHO).
Apple did not have the resources to do it (no dedication,
non existent market place, few companies supporting it, no
learning materials, etc.). It would have meant to
start a whole new market. But they were not ready
to do an "Open Dylan". Stupid enough, they depended on Common Lisp
and were not able to have it on PowerPC on time for their needs.

The better way is to improve known technology. Just like "Java",
which is not a revolution, but an evolution. Java appeals
to people working with C++ or people having the need to
do web programming.

My (and probably) others opinion is, that an evolution of Common Lisp
would have done it. Some of the technology developed for Dylan
could be more or less easily transported to Common Lisp:

- Application Framework
- C Interface
- parts of the development environment

Some would mean more of work:
- remote development (developement environment <-> application nub)
- application delivery (define a simple core CL engine)

Additionally:
- define a subset of CL without many of the dynamic features,
  which can be compiled efficiently
- type checking via type inferencing

Digitool seems to be interested in doing *some* of these things for MCL.
If you have any special ideas, then you should contact them.
They have done the basic PowerPC port of MCL and we clearly
see progress there (PowerPC MCL on the 604 is shockingly fast).
Some very nice code runs in MCL (recently I had fun with the Common Lisp
Music package for sound rendering - and don't forget CL-HTTP, the
web server written in Common Lisp).

---

So, what do we have? There seems to be some interest in Dylan, often
from people who have see the Apple Dylan TR. One company is
actively working on Dylan (Harlequin), one company (Digitool) is
porting Apple Dylan to PPC MCL and one university
group. This is not much.

If people are interested in Dylan on the Mac, I think it is best
to get in touch with Digitool (and Apple). If there is enough interest
somebody might see a real business. It also depends how the interest
in the upcoming PowerPC version is. The development environment
will run a lot faster (as a demo at Object World has indicated).
I'll buy a copy once it is available.

But otherwise looking at Common Lisp might be a good idea. Dylan
was heavily influenced by CL (Dylan is kind of a repackaged CL).
We will see some improvement on Common Lisp implementations
this year (Allegro CL on PCs will get threads and a different
compiler, Harlequin's LispWorks will appear on the PC and Digitool's
MCL will improve with the forthcoming 4.0 version).

---

Btw., the syntax is a non issue. Just see the Lisp traffic on the
AutoCad news group.

What you REALLY need is a "killer application". Here it
means a technology in combination with real products people
actually use and depend on.

- AI was the "killer" application for CL.

- WWW is the killer application for Java.

- "Rapid application development with delivery" could be the
  killer application for Dylan.

- Complex software development on PCs and Macs could be a killer
  application for CL.

Rainer Joswig



Wed, 11 Nov 1998 03:00:00 GMT  
 Why not MCL?


Quote:

>My (and probably) others opinion is, that an evolution of Common Lisp
>would have done it. Some of the technology developed for Dylan
>could be more or less easily transported to Common Lisp:

It would be interesting to see what would have happened if Apple had
taken all the energy it spent on Dylan and threw it toward MCL instead.
MCL already existed; they wouldn't have had to start from scratch.
Common Lisp is already a standardized language, so they wouldn't have had
to spend so much time on language design.  And there would already be a
good supply of textbooks for people to learn the language.

Quote:
>- Application Framework
>- C Interface
>- parts of the development environment

It wouldn't be too hard to port the app framework.  I actually prototyped
parts of the framework in MCL before Dylan was stable enough to use.  The
trickiest part was trying to get the new framework and the built-in MCL
framework to run in the same environment.  All of MCL's tools rely on the
existing framework, so I had to play games to get them both to run at the
same time.

Porting Creole to MCL would be really cool.  The biggest problem I had
with MCL was lack of typechecking when calling the toolbox.  It was easy
to pass in a ControlHandle instead of a WindowRecord to a toolbox call,
and crash into MacsBug.

While we are at it, lets add an interface builder and source level
de{*filter*} to the MCL wish list :-)

Quote:
>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Mike Lockwood (former Dylan framework engineer)



Thu, 12 Nov 1998 03:00:00 GMT  
 Why not MCL?


Quote:

> It would be interesting to see what would have happened if Apple had
> taken all the energy it spent on Dylan and threw it toward MCL instead.

Well, I suppose Mike would know better than I, but I thought the point of
Dylan was to improve MCL by providing:

1. More efficient compilation.
2. Separation of development and delivery environments.
3. Simplification of the language and set of standard objects/functions.

After studying Dylan, I gained an appreciation for MCL, but I still see
Dylan as the smaller, faster language I'd really like to use to replace
C++.

--
Chris Page        | Internet chain letters, adverti{*filter*}ts and SPAMs suck...
Don't Panic!      |



Thu, 12 Nov 1998 03:00:00 GMT  
 Why not MCL?



Quote:
> this is very interesting.  personally, I cannot bring myself to wrap my
> head around C++.  I have been programming in a Lisp-like fashion in most
> languages for the past 17 years, only I didn't know it until I had the
> opportunity to use Lisp for real two years ago.  (not counting two more
> years of Emacs Lisp.)  to me, C++ is backwards, and I just can't hack what
> I perceive as irrationalities in the design.  obviously, this is not the
> common impression.

I've been using C for 12+ years, and Lisp for about 10 years,
tho not as heavily. I started using C++ about 5 years ago. So,
I can see how both languages work, and I have little difficulty
with them. I'd _prefer_ to use Lisp (either CL or Scheme), but
the implementations available to me (e.g for Windows) aren't
suitable (e.g. not enough Win32 support).

So, I'm using C++ for commercial development, and Lisp for
personal use, which is generally apps of a "trivial" nature.
I'm including a "toy" Lisp to C compiler as one of these apps.
It's unlikely that I'm a typical Windows developer, as they
tend to use C/C++ and/or VB almost exclusively. A few of them
may use Smalltalk, but only if they're lucky. You're definitely
not what I'd call a typical developer, for any platform, as you
program in Lisp. Many people will find it hard to believe that
you can do what you're doing, because you're doing it in Lisp.

I'm sure that you've also seen this scepticism, as it used to
be a common sight in threads crossposted to this newsgroup.
The question is not, "Which language is technically better?",
coz most people don't care, and those who do (like me) can't
do anything about it. The real question is, "Which language
can I justify using to develop the software that I'm paid to
write?", or possibly, "How do I get my boss to give me the
development software that I'd _like_ to use, instead of merely
the software that 1) is available to me 2) that my boss will
give me to develop with?"

I'd say that the reason I'm using VC++ to develop software with
instead of ACL/Win is simply that VC++ has better support for
the kind of apps I'm writing, and it's thrust into the face of
every Windows developer, via full page adverts in mainstream
development magazines, and generally heavily promoted by a very
large marketting engine. I suspect that something similar could
be said about C++ & CL/Scheme systems for Unix.

Have you ever seen a blank look cross the face of another
programmer when you tell them that you code in Lisp? I have.
I'd see it more often, but I generally don't tell people
anything about what I use to write software with, in order
to avoid silly "advocacy" arguments. Too many people either
don't want to know about tools they don't use, and some will
try and convince you to use the tools _they_ use, when you
tell them that you use something different. Sad, innit?

Quote:
> my conclusion: there are differences between people that dictate their
> "mode of thinking about programming" -- some lean towards prefix and words,
> other towards infix and special syntactic symbols.  obviously, the prefix
> type programmers are far fewer than the infix type programmers, and I draw
> no conclusion from numbers alone (please), but I think we should realize
> that these differences may be like personality types in that they are
> partly innate and that one can only benefit from knowing what one's type
> is.  the next step is, of course, recognition in the market that neither is
> inherently superior to the other, nor that all problems should be solved in
> only one language by only one type of programmer.

I've _always_ been uncomfortable with infix, and yet I use it
far more often than prefix (in Lisp) or postfix (in Forth).
That's coz my dislike for infix is irrelevant - there are far
more significant characteristics of the tools I use, like full
support for the platform on which the code must be delivered.
I've yet to use a Lisp that gave me full support for Windows,
while C++...

I'm not claiming that C++ has any technical merits other than
being _very_ well supported by vendors and other developers.
_That's_ enough to make it worth using it. The merits of Lisp
are enough for my personal use, but not for the commercial work
I do, alas. Until I see DylanWorks, and the price tag, I won't
even know if I'll be able to use Dylan. That'll be too bad,
but what can I do about it? I'm not about to change my job just
so I can code in Dylan - I'm far too happy working where I am
to do that!

Quote:
> there is most probably something far deeper than taste or first exposure to
> all this.  I'd love to find out what, if only to understand the "language
> wars" that rage so often, as well as the operation of "popularity" (which I
> have never quite grasped, either).  incidentally, I think Dylan's infix
> syntax is ugly, but it's far easier to write Dylan from a Lisp program than
> to write C++ from a Lisp program.

See above. I code in C++ because I _can_, not coz I like it. It
just does what I require of it, in order to do my job. The vendors
of C++ compilers for the platform(s) I code for understand what
I need, and provide it. I wish I could say the same for Lisp vendors,
and I've yet to discover if it's true for Harlequin. Nothing on
their website fills me with hope. Perhaps if they told me that
LispWorks could be used to develop apps for low end machines
(8 MB of RAM or less, 486 CPU etc), I might feel better, but I
get the impression that Harlequin have never had to worry about
the users of such machines.

Sadly, developers like myself have to, and if DylanWorks makes
big enough demands of the hardware on which apps developed with
it will run, then I won't be able to use it. Not for some time,
anyway! In 5 years, things might not bad.

While I'm a Windows developer, and this is a thread asking "Why
not MCL?", many of these arguments may also apply to the Mac.
Apple's interest in Java reflects this, I think. I'll start using
Java very soon, for the _same_ reasons as Mac developers. Coz
it does what we need...
--
<URL:http://www.enrapture.com/cybes/> You can never browse enough.



Thu, 12 Nov 1998 03:00:00 GMT  
 Why not MCL?



Quote:
> My (and probably) others opinion is, that an evolution of Common Lisp
> would have done it. Some of the technology developed for Dylan
> could be more or less easily transported to Common Lisp:

> - Application Framework
> - C Interface
> - parts of the development environment

A decent and standard FFI would be a _great_ help. Supporting
existing C code and tools from other sources is often vital.

Quote:
> Some would mean more of work:
> - remote development (developement environment <-> application nub)
> - application delivery (define a simple core CL engine)

Delivery is vital. C++ has that, but is very weak in other areas.
CL is very strong in those areas, but delivery is very costly, or
in some case, even non-existant. The cost of a full system that can
deliver stand-alone apps is another issue. If the full system costs
4 times as much as a developer can afford, and 8 times as much as
a C++ system, they might not choose to use Lisp. The choie may be
made for them by the economics of the market, or the budget within
the company where they work.

Quote:
> Additionally:
> - define a subset of CL without many of the dynamic features,
>   which can be compiled efficiently
> - type checking via type inferencing

Stripping out the "introspection" features of CL would've been
a good start. It's already non-PC to use EVAL in a CL app.
Simplifying CLOS, or at least adding class sealing, would have
very big impact! It might hurt a few power developers, but few
of us can afford that kind of luxury. Either the delivered app
can perform on the require hardware spec of the machine of a
typical user of that app, or it can't be done using that
development system.

Putting the enture runtime system into a shared library would
also be vital. I'm told that a certain vendor now ships their
runtime support code with the _OS_. Ouch. Static linking is dead.
The byte-counters will just love to attack any language system
with statically linked runtime, coz it'll be so easy to measure!
This shouldn't be important, but while people still count these
these metrics, the metrics still count (if you'll excuse the pun).
Distribution media have a finite capacity, and modems have a
finite bandwidth, and some of us have to pay for these things.
While the cost of bandwidth and disk capacity remains worth
measuring, so the code size metric will remain.

If you've never had to worry about these issues, then you might
not appreciate how "mainstream" programmers look at the tools
you use. For years I've seen Lisp programmers whinging about how
little impact Lisp has on the mainstream world, and this may be
one of the major reasons. There are often very tight constraints
place on what you can do, with mainstream apps. Break one of
those constraints, and your product may fail. If you're really
unlucky, the product may simply be "killed", as it's costing
the company too much money to develop/maintain/market/etc.
Constraints like these can apply even before the project begins.

Perhaps this is why Apple have shifted their priorities regarding
Dylan. It may be short-sighted, but they may feel that the risks
are too great. That's their responsibility, not ours. Look at IBM.
I'm sure that Apple would like to avoid that happening to _them_.
When you put it into that kind of perspective, questions about
the future of Dylan can seem pretty insignificant. Why worry
about a single product when the company might not exist in a few
year's time? Keep the company floating, and _then_ worry about
little luxuries like new development languages.

Quote:
> Btw., the syntax is a non issue. Just see the Lisp traffic on the
> AutoCad news group.

Agreed. That's what I've been saying about Lisp for some time.

Quote:
> What you REALLY need is a "killer application". Here it
> means a technology in combination with real products people
> actually use and depend on.

Most people I meet don't even realise that Lisp can still be
used - that it _is_ still being used. That's odd, considering
how "popular" Cobol still is today, but there you go. Lisp has
an incredibly low profile, while Cobol development is still
well known.

Quote:
> - AI was the "killer" application for CL.

Perhaps it still is - look at how MS have used it. Compiler
writing might be another use. Lisp is very good at creating
development tools, even when the tools support a language
other than Lisp. I've been writing such "compilers" for years
(the first was written in Basic, and wrote assembler code),
but it's very natural to Lisp, Prolog, and Forth programmers
to write code that writes code.

Quote:
> - WWW is the killer application for Java.

> - "Rapid application development with delivery" could be the
>   killer application for Dylan.

> - Complex software development on PCs and Macs could be a killer
>   application for CL.

Definitely! Any software that is too "complex" (whatever
that means) to write in C++ or Java could be written in
Lisp or Dylan.
--
<URL:http://www.enrapture.com/cybes/> You can never browse enough.


Thu, 12 Nov 1998 03:00:00 GMT  
 Why not MCL?


   Newsgroups: comp.lang.dylan
   Date: 26 May 1996 00:55:37 GMT
   Organization: Metrowerks Corp
   Lines: 36
   Distribution: world
   NNTP-Posting-Host: voodoo.shore.net
   Mime-Version: 1.0
   Content-Type: text/plain; charset=ISO-8859-1
   Content-Transfer-Encoding: 8bit
   X-Newsreader: Nuntius 2.0.4_PPC

   X-XXDate: Sat, 25 May 1996 00:58:07 GMT



   >My (and probably) others opinion is, that an evolution of Common Lisp
   >would have done it. Some of the technology developed for Dylan
   >could be more or less easily transported to Common Lisp:

   It would be interesting to see what would have happened if Apple had
   taken all the energy it spent on Dylan and threw it toward MCL
   instead.

        ...

Unfortunately this question belongs to the "hypothetical histories"
category.  Just like the one "what if CLIM had been *freely*
available?" :)

   >- Application Framework
   >- C Interface
   >- parts of the development environment

        ...

   Porting Creole to MCL would be really cool.  The biggest problem I had
   with MCL was lack of typechecking when calling the toolbox.  It was easy
   to pass in a ControlHandle instead of a WindowRecord to a toolbox call,
   and crash into MacsBug.

   While we are at it, lets add an interface builder and source level
   de{*filter*} to the MCL wish list :-)

MCL had an interface builder and source level de{*filter*} since 1988.
MCL was definitively a very good system since its introduction in
1987.  (I remember running the developing environment on a Mac Plus
with 1Mb - of course 4 were better.)

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



Thu, 12 Nov 1998 03:00:00 GMT  
 Why not MCL?

Quote:

>What [Dylan] REALLY needs is a "killer application". Here it
>means a technology in combination with real products people
>actually use and depend on.

>- AI was the "killer" application for CL.

>- WWW is the killer application for Java.

>- "Rapid application development with delivery" could be the
>  killer application for Dylan.

....

I finally figured out what grates me so much about the "killer app"
argument: People say "killer app" when they mean "niche market."
"Killer app" implies a single program, which is patently ridiculous as
a model of language adoption (the only plausible example I've ever
heard is Unix promoting C).  Niche markets, on the other hand, have a
very well established history of supporting fledgling technologies.
--

-Nick Kramer



Thu, 12 Nov 1998 03:00:00 GMT  
 Why not MCL?

Quote:

>why not look at Common Lisp, esp Mac Common Lisp?  I promise
> (1) you will come to love prefix and
> (2) after a week you will not even *see* the parentheses--but
>you will love them too.

This was my experience a couple of years ago.

I did it because it became clear to me that experience in CL
raises one's consciousness.  And it certainly did mine.

Dave

--
Dave Yost



Thu, 12 Nov 1998 03:00:00 GMT  
 Why not MCL?



Quote:
> I finally figured out what grates me so much about the "killer app"
> argument: People say "killer app" when they mean "niche market."
> "Killer app" implies a single program, which is patently ridiculous as
> a model of language adoption (the only plausible example I've ever
> heard is Unix promoting C).  Niche markets, on the other hand, have a
> very well established history of supporting fledgling technologies.

Supporting a fledgling technology is fine, but you could say that
Smalltalk-78 did that. Smalltalk-80 ran one a few other machines,
and more significantly, machines that were used outside Xerox PARC.
However, it was the Mac that brought those ideas (the GUI, that is)
to most of our desktops. If we all had to wait until we got a Xerox
Alto, the GUI idea might not be nearly so popular as it is today.

Fortunately, Steve Jobs changed that. I hope that someone can do the
same thing for Dylan, but until the products are released, I'll be
asking myself when and _how_ it'll become a "reality", i.e. hit
enough desktops to make a difference. So far, the only description
I've seen of what a Dylan system will be like is the Gwydion overview,
which makes Gwydion sounds pretty tasty to me. However, if it means
using Unix, or even a particular Unix & machine, then few of us will
be lucky enough to use it. A Mac version would be better, assuming
there are more Mac developers than Unix developers. By the same logic,
it would be even better if there was also a Windows (NT?) version.

Of course, I'm not suggesting that a specific Dylan vendor should
do this or that. I'm just hoping that there will be someone with
enough vision, nay business sense, as some would say Steve Jobs did,
with the Mac. My argument is simply that if you could make Dylan
a success for Windows development, you would be guaranteeing its
success on _any_ platform. Put another way, if Dylan could take over
from C++ as the mainstream development language, and C++ would be
that much weaker as a rival choice of for developers.
--
<URL:http://www.enrapture.com/cybes/> You can never browse enough.



Fri, 13 Nov 1998 03:00:00 GMT  
 
 [ 26 post ]  Go to page: [1] [2]

 Relevant Pages 

1. Enterprise Edition - Why/Why not???

2. Why (or why not) one module per file?

3. why TCL and why not TCL with JAVA

4. Is this legal and if not why not?

5. why why why oh why why baby

6. Why did not Smalltalk catch on? Why is it not replacing Java?

7. Why did not Smalltalk catch on? Why is it not replacing Java?

8. Why did not Smalltalk catch on? Why is it not

9. Why, Why Why????

10. why why why (mouse related question)

11. Why not embedded java?

12. Why not LABEL EQU * ?

 

 
Powered by phpBB® Forum Software