In article <···············@lambda.unlambda.com>, ·····@fredbox.com (James
A. Crippen) wrote:
> Spending time immersed in the Scheme language (and related Lispish and
> functional languages) and in historical documents of the AI lab
> cultures will invariably assist you in understanding not only the
> superficial culture of the hackish crowd, its lore, and history, but
> also will aid you in understanding the underlying ideas and motives
> that produced such languages as Scheme. Probably one of the simpler
> windows into the culture is a dated but still relevant paper by
> Richard Gabriel,
> http://www.ai.mit.edu/docs/articles//good-news/good-news.html
> . This is a somewhat non-technical, short paper describing why the
> Lisp community as of ten years ago failed to succeed as well as it
> could have in the face of microcomputers, Unix, and poorly educated C
> hackers. It's well worth the read, and RPG not only defends his
> thesis well but brings up many sensitive topics rarely broached
> amongst the Lisp hacker community.
I read this paper some years ago, but just now re-read it.
My questions for the assembled masses is:
- where are we now, ten years later?
- What is this "next LISP" of which he speaks? (in
<http://www.ai.mit.edu/docs/articles/good-news/subsection3.3.6.html>
-- Bruce
In article <···························@bruce.bgh>,
Bruce Hoult <··········@pobox.com> wrote:
>My questions for the assembled masses is:
>
> - where are we now, ten years later?
Not much better. The success of Unix, Windows, and C/C++ rather than MacOS
and Lisp are examples of the "worse is better" philosophy.
> - What is this "next LISP" of which he speaks? (in
> <http://www.ai.mit.edu/docs/articles/good-news/subsection3.3.6.html>
I don't think he had a specific Lisp in mind, but was describing an
approach to creating one. However, his description seems to have quite a
bit in common with ISLisp, the dialect that was being developed by the ISO
Lisp working group (Gabriel was X3J13's representative to that group for
several years), and Dylan also seems to have adopted some of this approach.
--
Barry Margolin, ······@genuity.net
Genuity, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
Barry Margolin <······@genuity.net> wrote in message
·····················@burlma1-snr2...
> The success of Unix, Windows, and C/C++ rather than MacOS
> and Lisp are examples of the "worse is better" philosophy.
MacOS isn't exactly an example to hold up as "better is better". It's just
as bogus as any other GUI API that I've seen. (I haven't looked into BeOS'
GUI stuff yet, so I'm holding out some hope of finding a clean, consistent,
powerful GUI API.)
> From: "Michael T. Richter" <···@igs.net>
> Organization: Bell Solutions
> Reply-To: "Michael T. Richter" <···@ottawa.com>
> Newsgroups: comp.lang.scheme,comp.lang.lisp,comp.lang.dylan
> Date: Mon, 01 May 2000 17:04:43 GMT
> Subject: Re: The Lambda Nature
>
> Barry Margolin <······@genuity.net> wrote in message
> ·····················@burlma1-snr2...
>> The success of Unix, Windows, and C/C++ rather than MacOS
>> and Lisp are examples of the "worse is better" philosophy.
>
> MacOS isn't exactly an example to hold up as "better is better". It's just
> as bogus as any other GUI API that I've seen. (I haven't looked into BeOS'
> GUI stuff yet, so I'm holding out some hope of finding a clean, consistent,
> powerful GUI API.)
It's not bad for 1984...
MacOS X has modern APIs and a cool new look. d2c can generate "Carbon"
compatible code, so programming MacOSX in Dylan should be cool.
- Rob.
In article <···················@198.235.216.4>,
Michael T. Richter <···@ottawa.com> wrote:
>Barry Margolin <······@genuity.net> wrote in message
>·····················@burlma1-snr2...
>> The success of Unix, Windows, and C/C++ rather than MacOS
>> and Lisp are examples of the "worse is better" philosophy.
>
>MacOS isn't exactly an example to hold up as "better is better". It's just
>as bogus as any other GUI API that I've seen. (I haven't looked into BeOS'
>GUI stuff yet, so I'm holding out some hope of finding a clean, consistent,
>powerful GUI API.)
My respect is for the underlying Macintosh OS architecture. It's very well
modularized, and Apple did a good job providing both high-level interfaces
for most applications and a reasonable number of low-level hooks where
needed. The API to the GUI itself has some warts, but it's not too bad.
Also, I was trying to use an example that most people could relate to.
Personally, I consider Multics and Genera much better, but most readers
would not know enough about them to understand what's so great about them.
--
Barry Margolin, ······@genuity.net
Genuity, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
In article <···················@198.235.216.4>, "Michael T. Richter"
<···@ottawa.com> wrote:
>(I haven't looked into BeOS'
> GUI stuff yet, so I'm holding out some hope of finding a clean,
> consistent,
> powerful GUI API.)
>
Hopefully making the following remarks will not make me enemies at Be,
but can serve as constructive criticism on how to improve the OS.
I have worked extensively with BeOS and its GUI API and
have been involved in two commercial applications.
One shipped (www.lcsaudio.com) and is a very successful product, the
other didn't.
IMO Be's strength is their OS kernel.
The threading model and priorities really work well.
Everyone loves the GUI API. At first. It's great for making toy programs.
Most people never work on large projects so never run into the
limitations. It is just not as well designed as Smalltalk or Nextstep or
MacApp. I think that this is the reason why there are still not very
many large commercial apps on it.
The UI framework seems to have been coded to a set of specs rather than
having had a paradigm in mind of how everything should work. Many basic
Design Patterns are not available directly in the framework meaning
everyone rolls their own.
The decision to force one thread per window on the programmer causes
needless synchronization implementation complexity for many apps.
There is also the C++ fragile base class problem. Be has already broken
binary compatibility once after they had committed to freezing it.
Many classes are padded out with dummy variables and virtual functions
for future expansion. For an OS that touts being a non-legacy OS, it has
a real legacy creating demon lurking in it in the form of the FBC
problem.
One of the things that is most celebrated about Be's framework is the
BMessage which implements IPC, dynamic binding, drag and drop,
copy-paste, etc. Most of those who celebrate it have never used a
dynamic language like Smalltalk or Objective-C where these features come
along with the language's built in message passing. So in a BeOS app you
are writing a lot of switch() statements to handle BMessages because C++
has no built in dynamic binding messaging. Writing these switch
statements becomes a real pain.
On top of that there is Be's scripting architecture which overcomes the
inabilities of C++ to query the messages an object can respond to, or
store messages for later sending.
So basically you have in the BeOS API a crude implementation in C++ of a
dynamic messaging system which requires a significantly greater
notational burden than if a dynamic language had been used.
I must say that at the beginning I was a true BeOS convert, and I
couldn't understand what all these Nextstep people were ranting about.
Well into my first large program I began to see the light.
All that said, BeOS is still potentially the best OS for real time media
applications because of its threading model.
"James McCartney" <············@THISio.com> wrote in message
·······································@news-server.austin.rr.com...
> In article <···················@198.235.216.4>, "Michael T. Richter"
> <···@ottawa.com> wrote:
>
> >(I haven't looked into BeOS'
> > GUI stuff yet, so I'm holding out some hope of finding a clean,
> > consistent,
> > powerful GUI API.)
My server doesn't have Michael's original post.
Michael, have you looked at GNUStep or OpenStep/Cocoa? I think you'll be
hard pressed to find fault, with the exception of the language.
Maury
Bruce Hoult wrote:
>
> - where are we now, ten years later?
Losing even more precious years because of the bottomless well of money
Sun uses to promote Java!
> - What is this "next LISP" of which he speaks?
Dylan, in my opion.