[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: John's flame
- To: email@example.com
- Subject: Re: John's flame
- From: firstname.lastname@example.org (Ben A. Hyde)
- Date: Wed, 20 Jan 93 12:51:42 EST
> ... you write in part ...
> I come from the c++ world and, as a student, the $500 I paid for MCL was
> a significant investment in the hopes that I would be able to create
> distributable software. However, this I cannot do... most people
> who I sell to: (a) don't have 4 meg machines, (b) don't want 2 meg
> programs filling up their hd, (c) can't figure out how to install
> programs broken into two halves on two floppy disks, and (d) don't
> want to hear any excuses for any of the above.
I can see, as Mr. Rogers says: "When your sad, your angry." A lot of
us are sad, bitter, angry, scared, etc., about the situation with
dynamic languages today. Many of us have spent years of our lives and
millions of other people's money on programs that didn't quite work
Generally programs written in dynamic languages are twice the size and
half the speed. It is an ugly truth. A lot of people during those
fun years of great excess, the 80's, wrote commercial applications in
these languages. The cold mean market wiped most of them off the map.
This left the dynamic language community significantly smaller and
more polarized about what the lessons learned were. Opinions range
from despair thru denial. Many people believe that if we work harder
and are willing to jettison some ballast then this baby could fly. Some
idiots even think faster machines will solve the problem. The entire
experience left a bitter taste in a lot of people's mouths.
Those that despair include those people that while yearning for the
semantic pleasures of these languages decided they couldn't afford
them. They now program in C. Of course, these people are
obviously right, most programs are written this way.
A fraction from that camp believe that a two layered approach ala
Autocad, Emacs, and Interleaf is a good compromise. In this approach
the major data types in the application are implemented in C and then
a dynamic programming layer is added in on top. These people are
obviously right, major successful applications are written this way.
The jettison ballast camp believe that Common Lisp is the problem.
That a big language implies a big slow program. They argue that N
years have passed and smart hard working guys have yet to achieve lean
mean applications. These people are obviously right, you can fit
MacScheme applications on an 800K disk.
The work harder camp points out that keeping up with Common Lisp has
been hard work. They point out that we should follow thru on what we
now know: about structuring the implementation, about tree shaking,
about type inferencing, about runtime system design. They point out
that it is typical R&D Ivory Tower thinking to first say "we'll worry
about performance latter," and then go off and design a new language
instead. These people are obviously right, Common Lisp is a standard
and it would be extremely rude not to finish the job.
There are dozens of cool/bizarre little sub-camps/cults. For example
I'm in a camp that believes your dynamic language has to translate
thru the window of C semantics for pragmatic reasons that only a
somebody who ships products on dozens of platforms would care about.
While there is no consensus in the dynamic language community today
about these issues, I think we all agree, it not being our money, that
Apple should work a lot harder on making MCL leaner and meaner.
Meanwhile, they should pour lots of resources into Dylan so it can
wipe out that ugly blight which is C and C++.
- ben hyde