There's an interesting post made by Philip Greenspun on his weblog
(http://blogs.law.harvard.edu/philg/2003/09/20#a1762). It is based on
his experience in teaching seniors and graduate students in MIT's
computer science program and he compares programming in Java to
driving an SUV:
"A project done in Java will cost 5 times as much, take twice as long,
and be harder to maintain than a project done in a scripting language
such as PHP or Perl. People who are serious about getting the job done
on time and under budget will use tools such as Visual Basic
(controlled all the machines that decoded the human genome). But the
programmers and managers using Java will feel good about themselves
because they are using a tool that, in theory, has a lot of power for
handling problems of tremendous complexity. Just like the suburbanite
who drives his SUV to the 7-11 on a paved road but feels good because
in theory he could climb a 45-degree dirt slope. If a programmer is
attacking a truly difficult problem he or she will generally have to
use a language with systems programming and dynamic type extension
capability, such as Lisp. This corresponds to the situation in which
my friend, the proud owner of an original-style Hummer, got stuck in
the sand on his first off-road excursion; an SUV can't handle a true
off-road adventure for which a tracked vehicle is required."
So, does this mean that Lisp is the Bradley Fighting Vehicle of
programming tools?
--
Bill Clementson
···············@yahoo.com (Bill Clementson) writes:
> capability, such as Lisp. This corresponds to the situation in which
> my friend, the proud owner of an original-style Hummer, got stuck in
> the sand on his first off-road excursion; an SUV can't handle a true
> off-road adventure for which a tracked vehicle is required.
This is might be offtopic, but:
Maybe the person did not know how to drive the Hummer in off-road
conditions? I remember once reading an article, where the offroad
capabilities of Hummer were described -- the test driver could not
pass some obstacle (a ditch). With a little help from more
experienced driver (or was it a teacher in Hummer's drivings school, I
don't remember) he could pass that very obstacle without problems.
The trick was to get all-wheel driving to work -- using both
accelerator and brake simultaneously. I guess this same trick would
help to get the poor man out of the sand, too.
This relates to Lisp and programming in general because good
programmers should know their tools. And the ones who do will get
better results with tools they know than with some presumably better
tools they do not know.
--
Janis Dzerins
Common Lisp -- you get more than what you see.
Looks like lisp is getting another dose of publicity.
Greenspun's Java/SUV blog posting got slashdotted:
http://developers.slashdot.org/developers/03/09/22/1054200.shtml?tid=108&tid=126&tid=156
Now he's posted another one:
http://blogs.law.harvard.edu/philg/2003/09/22#a1844
"... my personal preference is a much darker, uglier, and more
shameful secret: Common Lisp, CLOS, plus an ML-like type inferencing
compiler/error checker (with some things done in a sublanguage with
Haskell semantics and Lisp syntax). Common Lisp dates from around 1982
and ML from 1984.
I try to keep this preference concealed from young people who've been
raised on a diet of C, Java, C#, Perl, etc. They just wouldn't find it
credible that 20-year-old systems and ideas are actually better than
the latest and greatest from Microsoft and Sun.
Imagine my delight in running into a friend yesterday. She's a
23-year-old graduate student in computer science at Harvard.
Conversation rolled around to programming tools. Unprompted she said
'What I think would be best is Common Lisp Object System with a modern
type system'. I was stunned. I thought it was only dinosaurs like me
that clung to Lisp.
I had a second ephiphany for the week... Believing that Lisp circa
1982 plus some mid-1980s ML tricks thrown in is better than all of the
new programming tools (C#, Java) that have been built since then is
sort of like being a Holocaust denier."
--
Bill Clementson
···············@yahoo.com (Bill Clementson) writes:
> Looks like lisp is getting another dose of publicity.
>
> Greenspun's Java/SUV blog posting got slashdotted:
> http://developers.slashdot.org/developers/03/09/22/1054200.shtml?tid=108&tid=126&tid=156
>
> Now he's posted another one:
> http://blogs.law.harvard.edu/philg/2003/09/22#a1844
>
> "... my personal preference is a much darker, uglier, and more
> shameful secret: Common Lisp, CLOS, plus an ML-like type inferencing
> compiler/error checker (with some things done in a sublanguage with
> Haskell semantics and Lisp syntax). Common Lisp dates from around 1982
> and ML from 1984.
> I try to keep this preference concealed from young people who've been
> raised on a diet of C, Java, C#, Perl, etc. They just wouldn't find it
> credible that 20-year-old systems and ideas are actually better than
> the latest and greatest from Microsoft and Sun.
> Imagine my delight in running into a friend yesterday. She's a
> 23-year-old graduate student in computer science at Harvard.
> Conversation rolled around to programming tools. Unprompted she said
> 'What I think would be best is Common Lisp Object System with a modern
> type system'. I was stunned. I thought it was only dinosaurs like me
> that clung to Lisp.
> I had a second ephiphany for the week... Believing that Lisp circa
> 1982 plus some mid-1980s ML tricks thrown in is better than all of the
> new programming tools (C#, Java) that have been built since then is
> sort of like being a Holocaust denier."
I would bet that LISP will still be there in 20 or 30 years, while
Java and C++ will have long been forgotten (ie. reached a bellow
FORTRAN and COBOL level). Perhaps old C++ programmers will have a
last flare in 2037.
--
__Pascal_Bourguignon__
http://www.informatimago.com/
Do not adjust your mind, there is a fault in reality.
> I would bet that LISP will still be there in 20 or 30 years, while
> Java and C++ will have long been forgotten (ie. reached a bellow
> FORTRAN and COBOL level). Perhaps old C++ programmers will have a
> last flare in 2037.
You say that is if C++ is some kind of fad. C++ has been widely used
for nearly 20 years now, and doesn't show any signs of slowing down.
Now, whether C++ will be around for another 20 years really depends on
what kind of programming you're considering. The vast majority of
software is composed of "back-end" applications. These are the ones
following the trends of whatever language is most hyped at the moment.
However, if you look at the apps that most users (games, office
suites, productivity tools, etc) interact with on a dialy basis,
they're all still written in C or C++. The major application
developers (aside from Microsoft, which is forced to eat its own
dog-food) haven't embraced Java/C#, and show no signs of doing so.
So, the merits of the language aside, its unfair to group C++ into the
same boat as Java. It is clearly not just a fad. Unless you're one of
those people who considers this whole Unix/C thing to be one big 3
decade long fad that's bound to end Real Soon Now (TM)...
From: Joe Marshall
Subject: Re: Java is the SUV of programming tools
Date:
Message-ID: <wubzv42e.fsf@ccs.neu.edu>
·······@mindspring.com (Rayiner Hashem) writes:
> So, the merits of the language aside, its unfair to group C++ into the
> same boat as Java. It is clearly not just a fad. Unless you're one of
> those people who considers this whole Unix/C thing to be one big 3
> decade long fad that's bound to end Real Soon Now (TM)...
Hope springs eternal.
"Rayiner Hashem" <·······@mindspring.com> schrieb im Newsbeitrag
·································@posting.google.com...
> The major application
> developers (aside from Microsoft, which is forced to eat its own
> dog-food) haven't embraced Java/C#, and show no signs of doing so.
Do you have any statistics to back this? There *are* indeed lots of Java
developers around, at least that's my impression from the publicity and
the amount of web space devoted to Java.
Regards
robert
"Robert Klemme" <········@gmx.net> wrote
>
> "Rayiner Hashem" <·······@mindspring.com> schrieb
> > The major application
> > developers (aside from Microsoft, which is forced to eat its own
> > dog-food) haven't embraced Java/C#, and show no signs of doing so.
>
> Do you have any statistics to back this? There *are* indeed lots of Java
> developers around, at least that's my impression from the publicity and
> the amount of web space devoted to Java.
Sure, they need lots of Java programmers to do what one Common Lisp
programmer can do!
Ahem, sorry, couldn't resist... (BTW it's true)
OK back to boxes and glue...
Marc
"Marc Battyani" <·············@fractalconcept.com> writes:
> "Robert Klemme" <········@gmx.net> wrote
> >
> > "Rayiner Hashem" <·······@mindspring.com> schrieb
> > > The major application
> > > developers (aside from Microsoft, which is forced to eat its own
> > > dog-food) haven't embraced Java/C#, and show no signs of doing so.
> >
> > Do you have any statistics to back this? There *are* indeed lots of Java
> > developers around, at least that's my impression from the publicity and
> > the amount of web space devoted to Java.
>
> Sure, they need lots of Java programmers to do what one Common Lisp
> programmer can do!
>
> Ahem, sorry, couldn't resist... (BTW it's true)
> OK back to boxes and glue...
Or, y'know, one Pascal programmer.
PS You couldn't pay me enough money to reimplement TeX in Pascal. As
for CL, well, double my rent would do...
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
···@famine.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
> PS You couldn't pay me enough money to reimplement TeX in Pascal.
TeX _is_ written in Pascal, so I wouldn't pay you a dime for doing
that ;-)
--
(espen)
Espen Vestre <·····@*do-not-spam-me*.vestre.net> writes:
> ···@famine.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
>
> > PS You couldn't pay me enough money to reimplement TeX in Pascal.
>
> TeX _is_ written in Pascal, so I wouldn't pay you a dime for doing
> that ;-)
Right, but AFAIK it hasn't been *re*written in Pascal. I'm not saying
it makes any sense ... :)
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
Espen Vestre <·····@*do-not-spam-me*.vestre.net> writes:
> ···@famine.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
>
> > PS You couldn't pay me enough money to reimplement TeX in Pascal.
>
> TeX _is_ written in Pascal, so I wouldn't pay you a dime for doing
> that ;-)
Well, web, iirc, which is a format that can be run through a
preprocessor to either output pascal, or a book. (I tried cweb for a
while, a variant that works with C, but found that I am not
particularly talented at writing a meaningful book while writing a
program...)
--
I'm awfully glad I'm a Beta, because I don't work so hard.
> Do you have any statistics to back this? There *are* indeed lots of Java
> developers around, at least that's my impression from the publicity and
> the amount of web space devoted to Java.
There are tons of Java developers, yes. But they work on different
types of apps from what I'm talking about. I made it clear that I was
referring to the types of applications that people buy in
shrink-wrapped packages from CompUSA, like Photoshop, Office, Quake
III, etc. These are still written mostly in C and C++.
"Rayiner Hashem" <·······@mindspring.com> schrieb im Newsbeitrag
·································@posting.google.com...
> > Do you have any statistics to back this? There *are* indeed lots of
Java
> > developers around, at least that's my impression from the publicity
and
> > the amount of web space devoted to Java.
> There are tons of Java developers, yes. But they work on different
> types of apps from what I'm talking about. I made it clear that I was
> referring to the types of applications that people buy in
> shrink-wrapped packages from CompUSA, like Photoshop, Office, Quake
> III, etc. These are still written mostly in C and C++.
I didn't read it that way. Thanks for clarification!
Kind regards
robert
>>>>> "Rayiner" == Rayiner Hashem <·······@mindspring.com> writes:
Rayiner> You say that is if C++ is some kind of fad. C++ has been widely used
Rayiner> for nearly 20 years now, and doesn't show any signs of slowing down.
That is probably true. On the other hand I think[1] that C++ is in a
disappointing state of affairs. If C++ had been the success it alluded
to be, Java would never have become the big hot thing it seems to have
become.
Java is perhaps only on par with C++ right know, but given C++'s 10-15
years headstart plus it being the natural successor to the previous
big thing (that being C) one may wonder what went wrong for the C++
guys.
[1] and this is really just thinking, I haven't any statistics and I
am not a C++ programmer so I do not know whats happening in the
C++ community
------------------------+-----------------------------------------------------
Christian Lynbech | email: christian ··@ defun #\. dk
------------------------+-----------------------------------------------------
Hit the philistines three times over the head with the Elisp reference manual.
- ·······@hal.com (Michael A. Petonic)
> That is probably true. On the other hand I think[1] that C++ is in a
> disappointing state of affairs. If C++ had been the success it alluded
> to be, Java would never have become the big hot thing it seems to have
> become.
>
It was inevitable. C++ is a systems programming language. The scope of
applications for which C++ is suited is much narrower than the scope
of applications for which Java (or more appropriately, a real high
level language) is suited. The reason Java has become so much of a
success is because it embraced a new direction for computer languages
--- giant class libraries and network computing.
> Java is perhaps only on par with C++ right know, but given C++'s 10-15
> years headstart plus it being the natural successor to the previous
> big thing (that being C) one may wonder what went wrong for the C++
> guys.
Oh, Java will undoubtedly become much larger, in numbers, than C++.
But I doubt Java will have longevity. C++ will be like C --- Doom IX
will still be programmed in it.
·······@mindspring.com (Rayiner Hashem) wrote in message news:<····························@posting.google.com>...
> Oh, Java will undoubtedly become much larger, in numbers, than C++.
> But I doubt Java will have longevity. C++ will be like C --- Doom IX
> will still be programmed in it.
My thoughts on this aren't totally on topic, but I think when talking
about the future of languages we also need to look at where things are
headed.
Of Java's longetivity, time will tell. It's well situated now and has
a huge user base.
On C/C++ I think you are right in that the shrink wrapped applications
(Doom, Quark, etc.) all use it now and may very well continue to do so
in the future. But if any language were to be tied solely to that
wagon, then it will _not_ have much of a future, simply because the
future for those types of applications is limited.
The whole application/document split is slowly but surely
disappearing. More and more users don't understand the difference
between running an application and using a web page. And more and more
applications are some sort of web page or web service. I'm not sure
of the timeframe, but there may be a day when C/C++ will be used for
systems programming _only_ because the shrink wrapped applications of
today have transmogrified to become some sort of web thingy.
This trend is in part why so many new languages are being developed
and old ones (like Lisp) are being unearthed. You can write great web
server stuff with Lisp. As applications move online you run into
tricky problems involving concurrency and scope that don't fit well to
traditional programming methods. And thus people are looking for more
flexible languages. Maybe later, when the problem space is better
understood some programmers will prefer less flexible languages that
are better mapped to what they are doing.
On 24 Sep 2003 13:31:36 -0700, ········@medialab.com (Chris Perkins)
wrote:
>
>The whole application/document split is slowly but surely
>disappearing. More and more users don't understand the difference
>between running an application and using a web page. And more and more
>applications are some sort of web page or web service. I'm not sure
>of the timeframe, but there may be a day when C/C++ will be used for
>systems programming _only_ because the shrink wrapped applications of
>today have transmogrified to become some sort of web thingy.
>
I don't believe this for one second. The only users who can't tell
the difference between an app and a web page are ones who haven't used
either. New users pick up on the difference very quickly.
I also don't think the convergence of look and feel is necessarily a
good thing - IMO users should always be aware of whether they are
crossing machine boundaries - for security and privacy reasons if for
nothing else. Such awareness also explains perceived performance
differences.
WRT personal software going web: imagine you are on deadline, sitting
at your (budget friendly) web terminal, just finishing your job
critical report using the MSWebWord service that your company leases
(at an irresistable price) from some local ISV. Now imagine a moth
flies into the server ...
George
George Neuner <········@no.comcast.spam.net> wrote in message news:<··································@4ax.com>...
> >
>
> I don't believe this for one second. The only users who can't tell
> the difference between an app and a web page are ones who haven't used
> either. New users pick up on the difference very quickly.
The point I'm trying to make is that users don't care or need to make
the distinction. For example, last year I saw a newspaper article
listing the "Top 10 Utilities" for computers. All 10 had URLs, but 5
of them were applications that you downloaded/installed/ran, and 5
were web pages you visited and used. They were just listed among each
other because they were all useful or interesting. The distinction as
app vs. web app was not noticed by the writer and presumably the
readers.
>
> I also don't think the convergence of look and feel is necessarily a
> good thing - IMO users should always be aware of whether they are
> crossing machine boundaries - for security and privacy reasons if for
> nothing else. Such awareness also explains perceived performance
> differences.
I tend to agree. Windows XP, for example, is really just Internet
Explorer on steroids. It uses the IE HTML renderer to display nearly
everything that the OS shows the user (directory listings, control
panels, etc.). Its vaguely unsettling (and vaguely slow).
>
> WRT personal software going web: imagine you are on deadline, sitting
> at your (budget friendly) web terminal, just finishing your job
> critical report using the MSWebWord service that your company leases
> (at an irresistable price) from some local ISV. Now imagine a moth
> flies into the server ...
I think you're not making the point you think. You are describing a
"single point of failure" problem - very risky. But, which scenario
really fits that description? Using files on a desktop machine or
using a web machine as a front to files that are "on the net"? We
can't really know, but I'd be inclined to say that the second scenario
at least sounds like it has less of a chance of suffereing the single
point of failure problem. If nothing else you hopefully have a local
copy and a copy on a server someplace. If my web service company is
professional, there may be several copies all around the world.
Anyway, now we are even further off topic.
For good or bad, many applications are becoming web applications and
most new applications written are web applications. As this trend
occurs people are moving away from some established languages like
C/C++ and using either languages that are supposedly better positioned
for web app work (Java/C#) or to more flexible languages (Python/Lisp)
or to certain domain specific ones (Perl/Ruby).
Chris Perkins
Media Lab, Inc.
[ More interesting (to me) is that as this happens the now dominant
paradigm of a split between document vs. application is slowly
beginning to wane. And, my crystal ball says that files as they exist
now (pathnames, extensions, custom data streamed to disk) are the next
domino to fall, though it'll take a long long time and they'll never
go away 100% - just marginalized away from user experience. But this
is not the place to discuss this. I'll go post a write up on
comp.predictions.stupid and discuss it with the denizens there. -CP]
On 26 Sep 2003 12:24:00 -0700, ········@medialab.com (Chris Perkins)
wrote:
>George Neuner <········@no.comcast.spam.net> wrote in message news:<··································@4ax.com>...
>> >
>>
>> I don't believe this for one second. The only users who can't tell
>> the difference between an app and a web page are ones who haven't used
>> either. New users pick up on the difference very quickly.
>
>The point I'm trying to make is that users don't care or need to make
>the distinction. For example, last year I saw a newspaper article
>listing the "Top 10 Utilities" for computers. All 10 had URLs, but 5
>of them were applications that you downloaded/installed/ran, and 5
>were web pages you visited and used. They were just listed among each
>other because they were all useful or interesting. The distinction as
>app vs. web app was not noticed by the writer and presumably the
>readers.
I concur that users, for the most part, don't really care from where a
program runs or where the data is stored. I disagree about the need
for them to know and to make the distinction.
WRT newspapers, most science and technology articles today are so
poorly written that it is difficult to figure out what the writer
knows or does not. Most read like rewrites of company press releases
rather than thoughtful analysis or even simple reporting of fact.
Please don't tempt me to comment on the atrocities commited upon
spelling and grammar ...
>> WRT personal software going web: imagine you are on deadline, sitting
>> at your (budget friendly) web terminal, just finishing your job
>> critical report using the MSWebWord service that your company leases
>> (at an irresistable price) from some local ISV. Now imagine a moth
>> flies into the server ...
>
>I think you're not making the point you think. You are describing a
>"single point of failure" problem - very risky ...
The illustration was intentionally absurd. However, it obviously
failed to convey the intended message. My bad.
If we are going to ask the average business to depend heavily on
remote or distributed Web applications, those applications, the
servers and the networks that support them are going to have to be
reliable. But right now, the last mile of the Internet is anything
but reliable and too few developers have experience in writing
"reliable" applications (e.g., the kind that can run 24/7 for several
months without crashing or leaking resources).
WRT web services, if they become a popular way to deliver business
services, I expect most will be hosted locally on their developer's
ISP or even directly by the developer. Minor developers will be
unlikely to pay gobs of money for Akamai, or similar companies, to
provide fault tolerant hosting of their services.
>Anyway, now we are even further off topic.
We're theoretically discussing Java in comp.lang.lisp,
what else is new? 8-)
>[ More interesting (to me) is that as this happens the now dominant
>paradigm of a split between document vs. application is slowly
>beginning to wane. And, my crystal ball says that files as they exist
>now (pathnames, extensions, custom data streamed to disk) are the next
>domino to fall, though it'll take a long long time and they'll never
>go away 100% - just marginalized away from user experience. But this
>is not the place to discuss this. I'll go post a write up on
>comp.predictions.stupid and discuss it with the denizens there. -CP]
The idea of a virtual workspace which exists "in the network" is not
new - IIRC, it used to be called the "infinite memory" concept. It
proposed that users don't care and shouldn't have to know where their
programs and data are kept, but rather "the network" should handle all
naming, storage and access transparently. URLs and hyperlinking are
outgrowths of this concept as are the current attempts at enterprise
wide resource naming services.
George
George Neuner <········@no.comcast.spam.net> writes:
> I concur that users, for the most part, don't really care from where a
> program runs or where the data is stored. I disagree about the need
> for them to know and to make the distinction.
Politically, economically, and from a survival stand point, they may
be interested and sometimes should better know where their programs
run and where their data is stored.
Assume you've got an artificial heart implanted. Wouldn't you rather
have the software running it being executed inside it rather than on a
computer on the other side of this planet, thru the Internet, and
depending on layers and layers of communication and powersupply
infrastructure that is rather wobbly?
The same is true for any user of any software.
> WRT newspapers, most science and technology articles today are so
> poorly written that it is difficult to figure out what the writer
> knows or does not.
No, this one is easy: assume he does not now the first thing of the
subject.
> If we are going to ask the average business to depend heavily on
> remote or distributed Web applications, those applications, the
> servers and the networks that support them are going to have to be
> reliable. But right now, the last mile of the Internet is anything
> but reliable and too few developers have experience in writing
> "reliable" applications (e.g., the kind that can run 24/7 for several
> months without crashing or leaking resources).
>
> WRT web services, if they become a popular way to deliver business
> services, I expect most will be hosted locally on their developer's
> ISP or even directly by the developer. Minor developers will be
> unlikely to pay gobs of money for Akamai, or similar companies, to
> provide fault tolerant hosting of their services.
Not to mention that AFAIK, the most problematic point of a 24/7 is not
the 24 or the 7, but the corporation closing down, either itself or
the service.
> The idea of a virtual workspace which exists "in the network" is not
> new - IIRC, it used to be called the "infinite memory" concept. It
> proposed that users don't care and shouldn't have to know where their
> programs and data are kept, but rather "the network" should handle all
> naming, storage and access transparently. URLs and hyperlinking are
> outgrowths of this concept as are the current attempts at enterprise
> wide resource naming services.
There is some bluring and confusion between the NETWORK and THE
INTER-NETWORK (Internet for short). Unfortunately, properties are not
the same within the local network and within the Internet. On the
local network, you can ensure any degree of reliability you need, and
you can protect your data and your programs. On the Internet, none of
this is true.
--
__Pascal_Bourguignon__
http://www.informatimago.com/
Do not adjust your mind, there is a fault in reality.
Pascal Bourguignon <····@thalassa.informatimago.com> writes:
> Assume you've got an artificial heart implanted. Wouldn't you rather
> have the software running it being executed inside it rather than on a
> computer on the other side of this planet, thru the Internet, and
> depending on layers and layers of communication and powersupply
> infrastructure that is rather wobbly?
>
Now that's enough to give anybody an artificial heart attack...
> This trend is in part why so many new languages are being developed
> and old ones (like Lisp) are being unearthed. You can write great web
> server stuff with Lisp.
You've got a good point there. C++ is not a great language for network
programming. The low-level memory model makes it irritating to use in
a networked environment, where you want to be able to ship objects
over the link without fussing about memory layout and where the
vtables are and whatnot. Note the gymnastics stuff like CORBA and COM
have to go through to present a distributed programming model to C++
code. In theory a language that abstracts the underlying memory model
could present some *very* clean distributed programming interfaces. I
don't know if any Lisps let you just transparently ship objects over a
link, but it would certainly be doable.
>>>>> "Pascal" == Pascal Bourguignon <····@thalassa.informatimago.com> writes:
Pascal> I would bet that LISP will still be there in 20 or 30 years, while
Pascal> Java and C++ will have long been forgotten (ie. reached a bellow
Pascal> FORTRAN and COBOL level).
That doesn't really say that much because there are still tons of
COBOL and respective amounts of FORTRAN out there.
I have the theory that no language who has ever made it out of the lab
will ever truly die. There are probably still professional programmers
doing stuff in APL, PL/1, RPG and FORTH even if it is only on a
small scale.
I do agree however that Lisp will only grow stronger over the
years. New languages will flame up and sweep over the masses and then
fade back into near nothingness, but each time they will add a bit
more of Lisp to mainstream programming and in the end the masses will
have matured to a level where they will be ready to embrace Lisp.
C++ added object orientation, Java has added the concept of garbage
collection, Extreme Programming is popularizing dynamic languages and
some of the stuff going on in the OO community (such Aspect Oriented
Programming) will add more sophisticated OO technology such as
multiple inheritance and generic functions.
It kind of feel goods to already be there, doesn't it :-)
------------------------+-----------------------------------------------------
Christian Lynbech | christian ··@ defun #\. dk
------------------------+-----------------------------------------------------
Hit the philistines three times over the head with the Elisp reference manual.
- ·······@hal.com (Michael A. Petonic)
From: Christopher C. Stacy
Subject: Re: Java is the SUV of programming tools
Date:
Message-ID: <uu173sfbd.fsf@dtpq.com>
>>>>> On Tue, 23 Sep 2003 09:47:53 +0200, Christian Lynbech ("Christian") writes:
Christian> There are probably still professional programmers doing
Christian> stuff in APL, PL/1, RPG and FORTH even if it is only on a
Christian> small scale.
There's a fair amount of APL and FORTH going on; I wouldn't call it
a "small scale". Probably a lot more than Common Lisp!
Christian Lynbech <·················@ericsson.com> writes:
> There are probably still professional programmers doing stuff in
> APL, PL/1, RPG and FORTH even if it is only on a small scale.
In addition to all the Say It Loud uses of Common Lisp, there are
quiet ones, too. Same goes for at least some of the above .. wanna
play with Forth? Get a Mac, and hold down Open-Apple+O+F when it
boots.
(What's up with calling Open-Apple "Command"? It still looks like an
open apple to me, and PC users understand "Open Apple", but "Command"?
How do either of those symbols mean that?)
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
···@famine.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
> play with Forth? Get a Mac, and hold down Open-Apple+O+F when it
> boots.
Or a Sun (since Open Firmware a.k.a. Openboot is a Sun invention).
> (What's up with calling Open-Apple "Command"? It still looks like an
> open apple to me, and PC users understand "Open Apple", but "Command"?
> How do either of those symbols mean that?)
Because you issue 'commands' with it, I guess.
I call it "The Museum Key".
--
(espen)
Espen Vestre <·····@*do-not-spam-me*.vestre.net> writes:
> ···@famine.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
>
> > play with Forth? Get a Mac, and hold down Open-Apple+O+F when it
> > boots.
>
> Or a Sun (since Open Firmware a.k.a. Openboot is a Sun invention).
One of my favorite quotations from the FreeBSD crowd:
Jordan Hubbard: We have a crash bug. It needs to be fixed. We DO NOT
need to know how to print 3000 spaces in 11 different languages! :-)
Daniel Sobral: I concur. But if anyone wants to do it with loader,
: 3kbl 3000 0 do bl emit loop ; 3kbl will do the trick.
Seems that lots of people like Forth for loaders.
--
Fred Gilham ······@csl.sri.com
I was storing data in every conceivable way, including keeping a chain
of sound waves running between the speaker and the microphone. There
was no more memory left to be had....