As a Lisp newbie, I found this essay very interesting:
http://www.dehora.net/journal/archives/000423.html (The thread subject
is taken from the title of the essay.)
I'm curious as to what folks in comp.lang.lisp might think about it.
adam connor wrote:
> As a Lisp newbie, I found this essay very interesting:
> http://www.dehora.net/journal/archives/000423.html (The thread subject
> is taken from the title of the essay.)
>
> I'm curious as to what folks in comp.lang.lisp might think about it.
I think it makes the classic mistake of looking at things as they are
today, Sunday, at 7:05PM EDT and at the same time talking "big picture".
He is a huge Lisp fan, concedes all its advantages, pronounces it the
best language available for serious work, but says Lisp has two problems:
1. The Savages of comp.lang.lisp. (well, I embroider a little)
2. More libraries, please.
Yet he says Python will do fine. Well what kind of libraries did Python
have ten years ago? See what I mean about the dangers of doing astronomy
with myopia?
Clearly c.l.l. is filling up nicely with new faces every day. And the
savage thing is a joke. Today's little mishap stands in bizarre contrast
to the way Lispniks normally smother newbies with contrast.
More newbies means more libraries, because they are liking Lisp so much
better than their old languages (see Highlight film in sig) that they
will pitch in on libraries (from scratch or via FFI work) rather than go
back.
More newbies also means jerks like me don't stand out so bad. We'll get
a nice dilution of us ragged old cranks with a more representative mix,
blander but more palatable.
If you want to play "big picture", play "big picture": The Lisp model
has won (see Python, Perl, PHP, Ruby, Groovy, VB(?!)). The copycats are
poor copies. cll is filling up with newbies. So far so indisputable. Now
what is going to stop more and more people from switching to Lisp and
devloping the libraries they need?
The big mistake in that piece is explaining why MegaCorp wont adopt Lisp
tomorrow morning, Monday, at 9am. That's not how it works. It will be a
grass roots thing. Where does he think Python came from?
kt
--
Home? http://tilton-technology.com
Cells? http://www.common-lisp.net/project/cells/
Cello? http://www.common-lisp.net/project/cello/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
Kenny Tilton wrote:
>
> 1. The Savages of comp.lang.lisp. (well, I embroider a little)
>
The outside world rarely hears about what savages we are--we usually eat
those who stray into cll inadvertently. :)
From: Bulent Murtezaoglu
Subject: Re: Better is better: improving productivity through programming languages
Date:
Message-ID: <87ekr33teu.fsf@cubx.internal>
>>>>> "DS" == David Sletten <·····@slytobias.com> writes:
DS> Kenny Tilton wrote:
>> 1. The Savages of comp.lang.lisp. (well, I embroider a little)
>>
DS> The outside world rarely hears about what savages we are--we
DS> usually eat those who stray into cll inadvertently. :)
After we torture them with knowledge capparently. Seriously, can any
of the regulars here point me to examples of the allegedly common
lisper [bad pun] arrogance that the article mentions? Just what is it
that we do that comes across as arrogance?
cheers,
BM
Bulent Murtezaoglu <··@acm.org> wrote in message news:<··············@cubx.internal>...
> After we torture them with knowledge capparently. Seriously, can any
> of the regulars here point me to examples of the allegedly common
> lisper [bad pun] arrogance that the article mentions? Just what is it
> that we do that comes across as arrogance?
I think that there are two classic scenarios:
1. Someone turns up, writing ill-informed, innacurate, and rude things
about Lisp. People are rude to them in return. I'll call this the
`lisp is slow' scenario, because for a long time that was the classic
contention.
2. Someone turns up as a fairly obvious newbie, and asks some
questions. Either (1a) they have dramatically misunderstood the
language or (1b) they are genuinely a newbie and appear to want to
learn. In either case, after some initial polite responses it becomes
apparent that they are not actually interested in learning, but repeat
their initial questions (1b) or confusions (1a). People lose
patience, and are rude. This is one version of the `mad person'
scenario.
3. (yes, the third one. Did I claim to be able to count? I think
not.) Basically, this is loonies. We all know who they are. They
may or may not know much Lisp, but they turn up periodically, fester
and bubble for a bit before wandering off into some other newsgroup to
cause disruption there. This is the other version of the `mad person'
scenario.
I think it's quite rare for there to be genuine unprovoked rudeness,
although I know some will disagree (I even know some of their
names...)
Bulent Murtezaoglu wrote:
>>>>>>"DS" == David Sletten <·····@slytobias.com> writes:
>
>
> DS> Kenny Tilton wrote:
> >> 1. The Savages of comp.lang.lisp. (well, I embroider a little)
> >>
> DS> The outside world rarely hears about what savages we are--we
> DS> usually eat those who stray into cll inadvertently. :)
>
> After we torture them with knowledge capparently. Seriously, can any
> of the regulars here point me to examples of the allegedly common
> lisper [bad pun] arrogance that the article mentions? Just what is it
> that we do that comes across as arrogance?
Snort milk out our noses when someone says something good about Java?
Outsiders hate it when we do that.
I have a friend, super bright, great sense of humor, innovator (the
person from whom I heard first about things like Smalltalk, VB, Python
(and yes I am going back decades)). Can't stand Lispniks, precisely
because of our snotty attitude.
The fact that we are right only makes it worse.
:)
kt
--
Home? http://tilton-technology.com
Cells? http://www.common-lisp.net/project/cells/
Cello? http://www.common-lisp.net/project/cello/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
From: Cameron MacKinnon
Subject: Re: Better is better: improving productivity through programming
Date:
Message-ID: <BtOdncvlyJuPMezdRVn-vg@golden.net>
Bulent Murtezaoglu wrote:
>>>>>>"DS" == David Sletten <·····@slytobias.com> writes:
>
> DS> Kenny Tilton wrote:
> >> 1. The Savages of comp.lang.lisp. (well, I embroider a little)
> >>
> DS> The outside world rarely hears about what savages we are--we
> DS> usually eat those who stray into cll inadvertently. :)
>
> After we torture them with knowledge capparently. Seriously, can any
> of the regulars here point me to examples of the allegedly common
> lisper [bad pun] arrogance that the article mentions? Just what is it
> that we do that comes across as arrogance?
Well, there's a .sig line here that says "Hit the philistines three
times over the head with the Elisp reference manual." [Which I like:
Please don't change it!]
We spend a fair bit of time analyzing the deficiencies of other
programming languages (and by extension, users thereof). Not exactly a
"live and let live" attitude.
Guests who dare to criticise emacs, syntax, lack of libraries or any of
several other sensitive topics are roasted to a turn.
Overall, I think c.l.l is 17.4% more arrogant that average for a
newsgroup devoted to a programming language. But this is Usenet, no
place for the meek or the timid.
[Ooh, definitive numbers just in, courtesy of Matthias. Thanks!]
--
Cameron MacKinnon
Toronto, Canada
Cameron MacKinnon wrote:
> We spend a fair bit of time analyzing the deficiencies of other
> programming languages (and by extension, users thereof). Not exactly a
> "live and let live" attitude.
The deficiencies of a particular programming language don't say a lot
about their users. Only about the users who should know better. A
considerable amount of time is also spent on deficiencies of Lisp
dialects. I appreciate such analysis - it makes you learn and widen your
horizon.
> Guests who dare to criticise emacs, syntax, lack of libraries or any of
> several other sensitive topics are roasted to a turn.
Have you ever started a discussion about macros on comp.lang.python? ;)
Seriously, I think your impression is wrong.
Parts of the behavior that you seem to think of as arrogant can be
explained by the fact that most Lispers have chosen Lisp because of very
rational reasons. These are currently the only reasons to choose Lisp.
Obviously, it cannot be because of popularity, can it?
On the other hand, it happens every now and then that users of other,
more popular languages come here and wonder what the fuzz is all about.
They think that to choose a language because of its popularity is a
rational reason. However, one can doubt that this is indeed rational,
and even if it were it would be the only reason they have. (Do I sound
arrogant? There you are. ;)
That a particular language allows expressing a certain set of idioms in
a concise and a convenient way isn't enough IMHO, because that's no
surprise - it is self-evidently clear that every language that is used
by a considerable number of people does provide certain advantages, at
least in relation to other languages. However, Lisp has a more
principled approach to providing concise and convenient abstractions,
and that's what's missing from most languages.
It's clear that the perceived (not necessarily real) lack of
infrastructure (libraries, and so on) can and will probably be solved
over time. Nothing (!) in Common Lisp prevents us from doing that. The
lack of sufficient abstraction facilities in most other languages can
only be solved by replacing them with yet other languages (including new
versions thereof).
Pascal
--
1st European Lisp and Scheme Workshop
June 13 - Oslo, Norway - co-located with ECOOP 2004
http://www.cs.uni-bonn.de/~costanza/lisp-ecoop/
"Pascal Costanza" <········@web.de> wrote in message
·················@newsreader2.netcologne.de...
> Cameron MacKinnon wrote:
> > Guests who dare to criticise emacs, syntax, lack of libraries or any of
> > several other sensitive topics are roasted to a turn.
>
> Have you ever started a discussion about macros on comp.lang.python? ;)
>
> Seriously, I think your impression is wrong.
>
> Parts of the behavior that you seem to think of as arrogant can be
> explained by the fact that most Lispers have chosen Lisp because of very
> rational reasons. These are currently the only reasons to choose Lisp.
> Obviously, it cannot be because of popularity, can it?
A lot of that arrogance may well be impatience as well. A blessing and curse
of the Lisp community is that the language hasn't changed dramatically in a
LONG time. And folks coming here to questions decision made and debated AGES
ago just plain get tired after you've waded through them a few thousand
times.
Finally, a lot of CL is experiential that is difficult to quantify until it
is used, particularly in a short USENET post, and most folks that come here
critiquing it don't have that foundation, which exacerbates the CL
afficianados even more so.
Regards,
Will Hartung
(·····@msoft.com)
From: Cameron MacKinnon
Subject: Re: Better is better: improving productivity through programming
Date:
Message-ID: <lvOdnZWyLugUVuzdRVn-iQ@golden.net>
Pascal Costanza wrote:
> Seriously, I think your impression is wrong.
Hey, I didn't exactly say "we're all arrogant here." I answered a post
that asked "what is it that we do that comes across as arrogance?"
> On the other hand, it happens every now and then that users of other,
> more popular languages come here and wonder what the fuzz is all about.
> They think that to choose a language because of its popularity is a
> rational reason. However, one can doubt that this is indeed rational,
> and even if it were it would be the only reason they have. (Do I sound
> arrogant? There you are. ;)
It is a rational reason, or perhaps even a sub rational one. We assume
that other people don't make stupid choices en masse, from which it
follows that if a large group chose x, x isn't a terrible choice. We say
"a million people can't be wrong." - it could be false, but it's usually
true. I think this behaviour is hardwired and biological, way below
"rational." Try not looking up the next time you see a crowd in the
street, all looking up. The mind is built to quickly make decisions
based on limited information, and seeing what everyone else does is one
way we cheat.
Also "there's safety in numbers" or "nobody ever got fired for buying
IBM." Making a technically inferior but popular choice is less risky,
from a career standpoint in a large organization, than betting on a
superior but unpopular technology. If the superior choice fails for
other reasons, your peers will tell your manager you made a poor choice.
Are those good reasons? The best reasons? Not really. But they're not
irrational.
Now, how those people wander into c.l.l in the first place is a bit of a
mystery...
> It's clear that the perceived (not necessarily real) lack of
> infrastructure (libraries, and so on) can and will probably be solved
> over time. Nothing (!) in Common Lisp prevents us from doing that. The
> lack of sufficient abstraction facilities in most other languages can
> only be solved by replacing them with yet other languages (including new
> versions thereof).
I'm in agreement with the following. It doesn't prevent us, but it
hinders us. Peter Seibel said:
"... And it only took a half-day to write.
Providing another data point for Thomas Burdick's contention that the
reason there aren't many fully polished libraries in Common Lisp is
because it's so easy (and fun) to reivent the wheel for oneself."
I can see how this is frustrating to guests, and telling them that it
would take half a day to rationally pick the best library from the nine
available over in Javaland won't make them feel better.
Now me, I reduce the search space by looking at what all the *arrogant*
people are doing. That's my heuristic.
--
Cameron MacKinnon
Toronto, Canada
Cameron MacKinnon wrote:
> Now, how those people wander into c.l.l in the first place is a bit of a
> mystery...
What part of my .sig have you not read? :)
I think Paul Graham is the biggest factor, tied with than "language
curiosity".
kt
--
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Cameron MacKinnon wrote:
> Pascal Costanza wrote:
>
>> Seriously, I think your impression is wrong.
>
> Hey, I didn't exactly say "we're all arrogant here." I answered a
> post that asked "what is it that we do that comes across as
> arrogance?"
OK, sorry.
> Now, how those people wander into c.l.l in the first place is a bit
> of a mystery...
MORPHEUS Do you want to know what [the Matrix] is, Neo?
Neo swallows and nods his head.
MORPHEUS It's that feeling you have had all your life. That feeling
that something was wrong with the world. You don't know what it is but
it's there, like a splinter in your mind, driving you mad, driving you
to me. But what is it?
The LEATHER CREAKS as he leans back.
MORPHEUS The Matrix is everywhere, it's all around us, here even in
this room. You can see it out your window, or on your television. You
feel it when you go to work, or go to church or pay your taxes. It is
the world that has been pulled over your eyes to blind you from the truth.
NEO What truth?
MORPHEUS That you are a slave, Neo. That you, like everyone else, was
born into bondage... ... kept inside a prison that you cannot smell,
taste, or touch. A prison for your mind.
Outside, the WIND BATTERS a loose PANE of glass.
MORPHEUS Unfortunately, no one can be told what the Matrix is. You have
to see it for yourself.
[...]
;-)
Pascal
--
1st European Lisp and Scheme Workshop
June 13 - Oslo, Norway - co-located with ECOOP 2004
http://www.cs.uni-bonn.de/~costanza/lisp-ecoop/
Pascal Costanza <········@web.de> wrote:
> It's clear that the perceived (not necessarily real) lack of
> infrastructure (libraries, and so on) can and will probably be solved
> over time. Nothing (!) in Common Lisp prevents us from doing that.
There is nothing inherent in the language that prevents it, but the
sheer scale of the task of keeping up with all the various platforms and
interfaces and the way they change can mean that a lack of popularity
prevents it. Common Lisp is usable for almost any task at this point,
but having libraries that make the obvious things as easy as they are in
some other popular languages takes a *lot* of work. If the language
community is not of a certain size, there may not be a lucrative enough
market for commercial developers, or enough people willing to donate
their code to keep up with the changes in the computing world as
effectively as the most popular languages can.
I think it's debatable which side of that critical mass common lisp is
on right now. I think it's clear that if CL were much less popular --
it could be clearly on the "never able to keep up" side. Fortunately, I
get the sense that lisp's popularity has recently started growing again,
so I expect CL to get to the right side of that line if it isn't there
already.
> The
> lack of sufficient abstraction facilities in most other languages can
> only be solved by replacing them with yet other languages (including new
> versions thereof).
That is certainly true. One problem is that a huge number of money
problems can be hack solved without getting into the kind of complex
design where an HLL (in the lisp sense) can really shine. This leads to
a philosophy where interesting problems become considered "impossible"
because of the exponential programmer time complexity of dealing with
them in languages with insufficient abstraction facility.
The idea of using a language with better abstraction facility doesn't
occur to people who have never grokked such a language. Although that
said, before I ever learned lisp, I struggled with the lack of such
facility in common languages. Until I understood lisp and scheme enough
to realize that they did the very things I had for 15 years wished I
could do in other languages, I had just assumed that such facility was
"too hard to implement correctly".
What's too hard is doing it while maintaining total backwards
compability with your braindead ancestor language -- a la STL in C++,
which tries hard and is clearly influenced by lispy ideas, but stops
*far* short of being as usable as any reasonable lisp dialect.
Michael
From: Jacek Generowicz
Subject: [OT] STL, Stepanov [Was: Better is better: improving productivity through programming]
Date:
Message-ID: <tyfy8p9y17u.fsf_-_@pcepsft001.cern.ch>
·······@bcect.com (Michael Sullivan) writes:
> What's too hard is doing it while maintaining total backwards
> compability with your braindead ancestor language -- a la STL in C++,
> which tries hard and is clearly influenced by lispy ideas, but stops
> *far* short of being as usable as any reasonable lisp dialect.
Indeed, I remember being excited about the STL when I first met it
(this was before my discovery of Lisp): it seemed such a right way of
doing things ... then, through actually trying to use it, the truth
struck me; it's actually impossible to use, unless you are using it to
satisfy some strong masochistic tendencies you might have.
However, I reacall reading an interview with Stepanov, where (IIRC) I
learned that he was responsible for Ada's generics (I don't have any
first hand Ada experience) and that he did a lot of work in Scheme
... but then he says ... OK, let's find the exact quote ... [1]:
So far, C++ is the best language I've discovered to say what I want
to say. It is not the ideal medium, but I can do more in it than in
any other language I tried.
Now, I'm finding this difficult to fathom ... coming from someone
apparently intelligent and having met languages outside the C family.
Does he _honestly_ believe this? Or does he have a penchant for
bondage? (His rigorous mathematical approach to the design of the STL
suggests that he might.) Is he just trying to suck up to Stroustup?
(Here's another quote from the same interview):
I would like to state quite clearly that Bjarne is the preeminent
language designer of my generation.
[1] http://www.stlport.org/resources/StepanovUSA.html
In article <··················@pcepsft001.cern.ch>,
Jacek Generowicz <················@cern.ch> wrote:
> However, I reacall reading an interview with Stepanov, where (IIRC) I
> learned that he was responsible for Ada's generics (I don't have any
> first hand Ada experience) and that he did a lot of work in Scheme
> ... but then he says ... OK, let's find the exact quote ... [1]:
>
> So far, C++ is the best language I've discovered to say what I want
> to say. It is not the ideal medium, but I can do more in it than in
> any other language I tried.
Check out the interview with Stepanov at:
http://www.sgi.com/tech/stl/drdobbs-interview.html
It contains lots of biographical material and details the
Scheme and Ada lineage of STL. Specifically:
(1) He first used Scheme to build a "toolbox":
===
Around 1983 I moved from GE Research to the faculty of the Polytechnic
University, formerly known as Brooklyn Polytechnic, in NY. I started
working on graph algorithms. My principal collaborator was Aaron
Kershenbaum, now at IBM Yorktown Heights. He was an expert in graph and
network algorithms, and I convinced him that some of the ideas of high
order and generic programming were applicable to graph algorithms. He
had some grants and provided me with support to start working with him
to apply these ideas to real network algorithms. He was interested in
building a toolbox of high order generic components so that some of
these algorithms could be implemented, because some of the network
algorithms are so complex that while they are theoretically analyzed,
but never implemented. I decided to use a dialect of Lisp called Scheme
to build such a toolbox. Aaron and I developed a large library of
components in Scheme demonstrating all kinds of programming techniques.
Network algorithms were the primary target. Later Dave Musser, who was
still at GE Research, joined us, and we developed even more components,
a fairly large library. The library was used at the university by
graduate students, but was never used commercially. I realized during
this activity that side effects are important, because you cannot really
do graph operations without side effects. You cannot replicate a graph
every time you want to modify a vertex. Therefore, the insight at that
time was that you can combine high order techniques when building
generic algorithms with disciplined use of side effects. Side effects
are not necessarily bad; they are bad only when they are misused.
===
(2) He duplicated wthis work in Ada, coming to appreciate
"strong" typing:
===
In the summer of 1985 I was invited back to GE Research to teach a
course on high order programming. I demonstrated how you can construct
complex algorithms using this technique. One of the people who attended
was Art Chen, then the manager of the Information Systems Laboratory. He
was sufficiently impressed to ask me if I could produce an industrial
strength library using these techniques in Ada, provided that I would
get support. Being a poor assistant professor, I said yes, even though I
didn't know any Ada at the time. I collaborated with Dave Musser in
building this Ada library. It was an important undertaking, because
switching from a dynamically typed language, such as Scheme, to a
strongly typed language, such as Ada, allowed me to realize the
importance of strong typing. Everybody realizes that strong typing helps
in catching errors. I discovered that strong typing, in the context of
Ada generics, was also an instrument of capturing designs. It was not
just a tool to catch bugs. It was also a tool to think. That work led to
the idea of orthogonal decomposition of a component space. I realized
that software components belong to different categories. Object-oriented
programming aficionados think that everything is an object. When I was
working on the Ada generic library, I realized that this wasn't so.
There are things that are objects. Things that have state and change
their state are objects. And then there are things that are not objects.
A binary search is not an object. It is an algorithm. Moreover, I
realized that by decomposing the component space into several orthogonal
dimensions, we can reduce the number of components, and, more
importantly, we can provide a conceptual framework of how to design
things.
===
(3) He came to appreciate C more than Scheme (or Ada) because
it minimally abstracts conventional hardware:
===
Let's consider now why C is a great language. It is commonly believed
that C is a hack which was successful because Unix was written in it. I
disagree. Over a long period of time computer architectures evolved, not
because of some clever people figuring how to evolve architectures---as
a matter of fact, clever people were pushing tagged architectures during
that period of time---but because of the demands of different
programmers to solve real problems. Computers that were able to deal
just with numbers evolved into computers with byte-addressable memory,
flat address spaces, and pointers. This was a natural evolution
reflecting the growing set of problems that people were solving. C,
reflecting the genius of Dennis Ritchie, provided a minimal model of the
computer that had evolved over 30 years. C was not a quick hack. As
computers evolved to handle all kinds of problems, C, being the minimal
model of such a computer, became a very powerful language to solve all
kinds of problems in different domains very effectively. This is the
secret of C's portability: it is the best representation of an abstract
computer that we have. Of course, the abstraction is done over the set
of real computers, not some imaginary computational devices. Moreover,
people could understand the machine model behind C. It is much easier
for an average engineer to understand the machine model behind C than
the machine model behind Ada or even Scheme. C succeeded because it was
doing the right thing, not because of AT&T promoting it or Unix being
written with it.
===
Seems like a logical progression in his thinking, though
not the one I would have followed.
From: Ray Dillinger
Subject: Re: [OT] STL, Stepanov [Was: Better is better: improving productivity through programming]
Date:
Message-ID: <40731D85.62BC803C@sonic.net>
He's got some good points.
I do about half my hacking in C and half in lispy languages (CL and Scheme).
Oddly, I don't use C++ at all, even though I know it fairly well. C++, to
me, hides too many things from the coder to preserve the tabula-rasa quality
of C that makes C valuable to me. When I'm willing to work without knowing
exactly what the memory map looks like or exactly what kind of machine code
implements the operations I'm asking for, I go straight to Lispy languages.
The great pain of C is memory management. It has several great benefits
as well, and among them are its absolutely minimal machine model. C is
like machine code that's lifted up with some abstraction facilities and a
surface veneer of syntax that makes it at least nominally portable between
architectures.
C's type system catches a kind of error I find myself particularly vulnerable
to making in C: that is, confusing levels of pointer indirection. It also
sets up a situation where the compiler can help me trace the effects of a change
in one part of the code on other parts of the code; I change a type declaration
for example, and new compiler errors and warnings tell me what other code is
affected now, immediately, without waiting for me to attempt to evaluate stuff.
Thus, when I want to start from tabula rasa and define fundamental things
like how values of a particular type will be represented in bytes, I go
to C code. C allows me to be precise, down to the level of the last bit
and byte, about what the memory image looks like and how it works, and
when I need that, there's no substitute.
When I don't care about exact binary data representations or about being
able to find my algorithms in a dump of the machine-code generated, or
about the size of the executable, I go to a lisp. When manual memory
management becomes too much of a pain in the tush, I go to a lisp. When
rapid development is the most important thing, I go to a lisp.
Lisp presents an abstract machine that has to be considered as a mathematical
entity, driven by theory; you can make it do anything, in its own terms, but
its relationship to the physical entity (sequential memory machine, register
CPU, etc) on your desk is at best tenuous and ill-defined. I wind up feeling
clumsy, like I've got padded gloves on. It's just a perception; Lisp is
still the best language there is for describing operations on _information_.
But there's something unsatisfying about it, I guess, in that it doesn't
describe operations on _the_machine_.
I guess that was part of the reason I set out to implement my own Lisp;
I wanted to have that feeling of precise control back, I wanted to know
exactly what machine code and what byte representation every lisp operation
and datum had. Instead, I can't shake the feeling that I just know more and
more about the gloves I'm wearing that make me feel clumsy.
Bear
Ray Dillinger <····@sonic.net> writes:
> The great pain of C is memory management.
And C++ can ease /some/ of that pain, even if you only use enough of
it to employ RAII. Types such as std::auto_ptr, boost::scoped_ptr, and
boost::scoped_ptr still require the author to think about memory
management, but they make mistakes much less likely.
--
Steven E. Harris :: ········@raytheon.com
Raytheon :: http://www.raytheon.com
"Steven E. Harris" <········@raytheon.com> writes:
> and boost::scoped_ptr
^^^^^^
s/scoped/shared/
--
Steven E. Harris :: ········@raytheon.com
Raytheon :: http://www.raytheon.com
From: Don Groves
Subject: Re: [OT] STL, Stepanov [Was: Better is better: improving productivity through programming]
Date:
Message-ID: <opr518geyx2i99y2@news.web-ster.com>
On Tue, 06 Apr 2004 21:13:25 GMT, Ray Dillinger <····@sonic.net> wrote:
>
> The great pain of C is memory management. It has several great benefits
> as well, and among them are its absolutely minimal machine model. C is
> like machine code that's lifted up with some abstraction facilities and a
> surface veneer of syntax that makes it at least nominally portable
> between architectures.
That's exactly what it is - PDP/11 machine code to be exact.
If PDP/11 registers hadn't had autoincrementing indirect modes,
*p++ may never have been.
--
dg
From: Bud Rogers
Subject: Re: [OT] STL, Stepanov [Was: Better is better: improving productivity through programming]
Date:
Message-ID: <3bvbk1-oj1.ln1@twocups.netride.net>
Don Groves wrote:
> That's exactly what it is - PDP/11 machine code to be exact.
> If PDP/11 registers hadn't had autoincrementing indirect modes,
> *p++ may never have been.
Gawd, that brings back a memory. About '85 or '86 I took a PDP-11
hardware course in Bedford. I spent more time than I should have
trying to work out how to test memory by toggling a single instruction
in through the front panel that would autoincrement and write itself to
successive locations in memory. I never quite got it, but I had a lot
of fun trying.
>> Let's consider now why C is a great language. It is commonly
>> believed that C is a hack which was successful because Unix was
>> written in it. I disagree. ... C succeeded because it was doing
>> the right thing, not because of AT&T promoting it or Unix being
>> written with it.
Well, I disagree too.
I maintain that what pushes a language to omnipresent greatness is a
combination of a bunch of things, including various hard-to-control
aspects of luck and timing.
C was greatly positioned, it was sitting on top of an algol heritage,
it provided a common hardware abstraction at a time lots of new
hardware was appearing and it was the system language of a killer
application (UNIX).
However it also arose at a time where a new generation where flocking
to computer science and the macho-appealing bare-metal and
hard-to-wield image probably appealed quite a bit to young people like
myself that were starting at universities during the 80's.
Also we shall not forget that C early on got the help of a quality and
free compiler (GCC) with quality toolchains (eg GDB).
And then of course the Linux revolution started.
The world is still waiting to see a language clear the table on its
technical merits alone. I for one is not holding my breath.
------------------------+-----------------------------------------------------
Christian Lynbech | christian ··@ defun #\. dk
------------------------+-----------------------------------------------------
Hit the philistines three times over the head with the Elisp reference manual.
- ·······@hal.com (Michael A. Petonic)
From: André Thieme
Subject: Re: Better is better: improving productivity through programming
Date:
Message-ID: <c57el6$luo$1@ulric.tng.de>
Pascal Costanza wrote:
> Parts of the behavior that you seem to think of as arrogant can be
> explained by the fact that most Lispers have chosen Lisp because of very
> rational reasons. These are currently the only reasons to choose Lisp.
> Obviously, it cannot be because of popularity, can it?
>
> On the other hand, it happens every now and then that users of other,
> more popular languages come here and wonder what the fuzz is all about.
> They think that to choose a language because of its popularity is a
> rational reason.
It is a paradox (not antonomy).
One would think, that if a language is really "good" it will allow one
to declassify competition. It will begin to dominate the market when it
really is so good. This is the reason why one should chose a language by
its popularity ;)
Andr�
--
From: David Steuber
Subject: Re: Better is better: improving productivity through programming
Date:
Message-ID: <87fzbai4oy.fsf@david-steuber.com>
Andr� Thieme <······································@justmail.de> writes:
> One would think, that if a language is really "good" it will allow one
> to declassify competition. It will begin to dominate the market when it
> really is so good. This is the reason why one should chose a language by
> its popularity ;)
For a cowboy like myself, a language that increases personal
productivity is a good thing. However, this is not the case in the
corperate world.
In the corporate world, you are just an employee. You do not want to
jeopardize your job by doing anything that will increase efficiency.
If switching from language A to language B means going from 10
programmers to 5, what are the odds that you will still have a job? A
50% chance of getting the sack is not good.
And what about the manager? Cutting his staff in half makes him less
important. That's not good. Then you have all the support personnel
from Human Resources to Office Management who rely on a large
headcount for their jobs.
Efficiency is fatal to bureaucracies like governments and
corporations.
--
It would not be too unfair to any language to refer to Java as a
stripped down Lisp or Smalltalk with a C syntax.
--- Ken Anderson
http://openmap.bbn.com/~kanderso/performance/java/index.html
From: Paul F. Dietz
Subject: Re: Better is better: improving productivity through programming
Date:
Message-ID: <lIqdnW12JftkIuTdRVn-vA@dls.net>
David Steuber wrote:
> In the corporate world, you are just an employee. You do not want to
> jeopardize your job by doing anything that will increase efficiency.
> If switching from language A to language B means going from 10
> programmers to 5, what are the odds that you will still have a job?
If you're on a deathmarch project with an impossible schedule, what's
the chance you'll have a job after it fails?
Paul
"Paul F. Dietz" <·····@dls.net> writes:
> If you're on a deathmarch project with an impossible schedule, what's
> the chance you'll have a job after it fails?
Surprisingly good, since management is used to projects that fail.
Listen to this delightful quote from "Learning by Doing: Why XP
Doesn't Sell" by Kay Johansen, Ron Stauffer, and Dan Turner (in
_Extreme Programming Perspectives_).
Events after completion of this project became rather surreal. At
the shipping party, the team that actually worked on the project
received no credit for shipping successfully. A new manager was
hired to take care of this team. When layoffs came shortly
thereafter, this team was the one that was let go, while the team
that had missed all their deadlines but had worked more overtime
was preserved.
Clearly, there was a difference in perception. The authors'
perception was that their team had delivered superior performance,
based on the fact that they accomplished the project according to
the schedule they had gotten management's agreement on, and had
team members who were happy and excited to work on the next
project. The company's perception was that the team had delivered
inferior performance---that they could have gotten the
product out sooner if they had put more effort into it.
The differences in perception became more clear after the authors
interviewed the other team members and management. The interview
responses were surprising at first. Some of the developers said
this project was the best work experience they had ever had;
others felt the project was average at best. Some of the evidence
the authors thought indicated success, such as the 40-hour week
and delivering on schedule according to a measured velocity, were
even considered negative factors by management and one of the
developers, who thought the team showed a lack of commitment for
not working overtime or faster than the estimates.
--
Alan Shutko <···@acm.org> - I am the rocks.
Call me anything, but don't call me late for dinner.
From: David Steuber
Subject: Re: Better is better: improving productivity through programming
Date:
Message-ID: <87hdvpg8w3.fsf@david-steuber.com>
"Paul F. Dietz" <·····@dls.net> writes:
> David Steuber wrote:
>
> > In the corporate world, you are just an employee. You do not want to
> > jeopardize your job by doing anything that will increase efficiency.
> > If switching from language A to language B means going from 10
> > programmers to 5, what are the odds that you will still have a job?
>
> If you're on a deathmarch project with an impossible schedule, what's
> the chance you'll have a job after it fails?
Forethought in scheduling vacation time should insure that someone
else gets the blame ;-)
--
It would not be too unfair to any language to refer to Java as a
stripped down Lisp or Smalltalk with a C syntax.
--- Ken Anderson
http://openmap.bbn.com/~kanderso/performance/java/index.html
From: Larry Elmore
Subject: Re: Better is better: improving productivity through programming
Date:
Message-ID: <tnkec.13984$_K3.50243@attbi_s53>
David Steuber wrote:
> Andr� Thieme <······································@justmail.de> writes:
>
>
>>One would think, that if a language is really "good" it will allow one
>>to declassify competition. It will begin to dominate the market when it
>>really is so good. This is the reason why one should chose a language by
>>its popularity ;)
>
>
> For a cowboy like myself, a language that increases personal
> productivity is a good thing. However, this is not the case in the
> corperate world.
>
> In the corporate world, you are just an employee. You do not want to
> jeopardize your job by doing anything that will increase efficiency.
> If switching from language A to language B means going from 10
> programmers to 5, what are the odds that you will still have a job? A
> 50% chance of getting the sack is not good.
This is the kind of thinking behind union featherbedding, and for that
matter, the Luddites.
I'm sure it might be that way at some companies, but with management
like that those companies will be circling the drain soon anyway, so
you're not really "protecting" much. If it comes to layoffs, it will
generally be the least productive employees laid off first at any
reasonably non-brain-dead company, unless it's government or unionized
or both.
> And what about the manager? Cutting his staff in half makes him less
> important. That's not good. Then you have all the support personnel
> from Human Resources to Office Management who rely on a large
> headcount for their jobs.
>
> Efficiency is fatal to bureaucracies like governments and
> corporations.
Until their inefficiency dooms them. Government can "survive" much more
inefficiency than a corporation, but even they are not immune to being
outcompeted or overthrown if they get bad enough.
--Larry
Cameron MacKinnon <··········@clearspot.net> wrote in message news:<······················@golden.net>...
> Overall, I think c.l.l is 17.4% more arrogant that average for a
> newsgroup devoted to a programming language. But this is Usenet, no
> place for the meek or the timid.
There are a few reasons that can help explain this.
- Cultural divide.
Programming is a means to express the world and oneself. The coding
world could stand more poets and fewer accountants, and I'm sure the
poets will sound arrogant to the accountants... but the accountants do
too in their own ways; they just aren't aware of it.
- Vocal non-lispers lie about lisp.
They will say it's only interpreted, or has no iteration, or...
Criticism is difficult, because it requires research and an
understanding of the target. But they just make things up.
- It was probably just a couple guys.
Grumpy, prolific people can often set the mood of an entire community.
And they bring out emotion in people who've wasted part of their
lives on other languages.
- Arrogance has second order relevance.
Less arrogance may win some friends... but then again it may lose more
choleric people. ;) Really, there really is no bad publicity, and as
long as people talk about it, some will be curious and perhaps watch
with morbid fascination until desensitized to the carnage. Of course,
many of them will storm away in a huff and complain to their friends
about it...
- Lispers are bad boys and girls.
"The programmers other programmers fear. Their reckless, dangerous
language gives them rope to hang themselves... rope does not frighten
them."
Now, before people storm away in a huff, I was partly joking... But I
did not start with lisp and do have some annoyance at my own
prejudices I have needed to rewrite, because my mind was bent by other
notations. I automate things, and lisp is a programmable programming
notation. I have little sympathy for fellow automators who will
gleefully lie about one of the best examples of their art.
Programming is not unemotional. We are not all Spocks. There are
programming domains where you will find rather extreme people, and
everyone can manipulate each other with words. Some just wear their
hearts on their sleeves.
Bulent Murtezaoglu <··@acm.org> writes:
> Seriously, can any of the regulars here point me to examples of the
> allegedly common lisper [bad pun] arrogance that the article
> mentions? Just what is it that we do that comes across as
> arrogance?
I looked how often the word "idiots" was used in different groups:
+------------------+----------------+--------+------+
|groups |postings |all |ratio |
| |containing |postings|*10^-4|
| |"idiots" | | |
+------------------+----------------+--------+------+
|comp.lang.lisp.* | 534 | 97,700 | 55 |
+------------------+----------------+--------+------+
|comp.lang.scheme.*| 43 | 44,700 | 9 |
+------------------+----------------+--------+------+
|comp.lang.python.*| 288 | 304,000| 9 |
+------------------+----------------+--------+------+
|comp.lang.ruby.* | 12 | 60,800 | 2 |
+------------------+----------------+--------+------+
on the other hand:
+------------------+----------------+--------+------+
|comp.lang.java.* | 2380 | 833,000| 286 |
+------------------+----------------+--------+------+
From: T.M. Sommers
Subject: Re: Better is better: improving productivity through programming languages
Date:
Message-ID: <Q6WdnS4oPtKbku_dUSdV9g@ptd.net>
Matthias wrote:
>
> +------------------+----------------+--------+------+
> |groups |postings |all |ratio |
> | |containing |postings|*10^-4|
> | |"idiots" | | |
> +------------------+----------------+--------+------+
> |comp.lang.java.* | 2380 | 833,000| 286 |
> +------------------+----------------+--------+------+
You are off by a factor of 10.
--
Thomas M. Sommers -- ····@ptd.net -- AB2SB
"T.M. Sommers" <····@mail.ptd.net> writes:
> Matthias wrote:
> > +------------------+----------------+--------+------+
> > |groups |postings |all |ratio |
> > | |containing |postings|*10^-4|
> > | |"idiots" | | |
> > +------------------+----------------+--------+------+
> > |comp.lang.java.* | 2380 | 833,000| 286 |
> > +------------------+----------------+--------+------+
>
> You are off by a factor of 10.
Uups. You are right. Embarrassing. I correct to
+------------------+----------------+--------+------+
|comp.lang.java.* | 2380 | 833,000| 29 |
+------------------+----------------+--------+------+
Then I only find the perl camp to have an "idiots"-occurrence-ratio
similar to cll:
+------------------+----------------+--------+------+
|comp.lang.perl.* | 2320 | 416,000| 56 |
+------------------+----------------+--------+------+
However, this can be explained by an unusually high number of "idiots
guide" occurrences. Taking these out we get:
+------------------+----------------+--------+------+
|comp.lang.perl.* | 2320 - 1730 | 416,000| 14 |
+------------------+----------------+--------+------+
Doing the same for cll (for some reason google reports way more
overall postings for cll today):
+------------------+----------------+--------+------+
|comp.lang.lisp.* | 536 - 21 | 106,000| 49 |
+------------------+----------------+--------+------+
Repeating the experiments for postings from the last 12 months only
hints that the idiots-occurrence-ratio in both communities is
declining. Esp. for cll the difference is remarkable:
+------------------+----------------+--------+------+
|comp.lang.lisp.* | 73 - 18 | 23,600 | 23 |
+------------------+----------------+--------+------+
|comp.lang.perl.* | 55 - 12 | 42,500 | 10 |
+------------------+----------------+--------+------+
From: Sunnan
Subject: Re: Better is better: improving productivity through programming languages
Date:
Message-ID: <87llla30hu.fsf@handgranat.org>
David Sletten <·····@slytobias.com> writes:
> The outside world rarely hears about what savages we are--we usually
> eat those who stray into cll inadvertently. :)
Well, I've gotten the notion that cll has a bad reputation even
outside usenet, for example on the c2 wiki (which on the other hand is
a place I really like, so don't go there flaming just because I
might've misunderstood something).
--
One love,
Sunnan
Kenny Tilton <·······@nyc.rr.com> writes:
> Python have ten years ago? See what I mean about the dangers of doing
> astronomy with myopia?
You need a Shuttle servicing mission.
> More newbies means more libraries, because they are liking Lisp so
Last fall I started to keep track of the number of new projects hosted
at Common-Lisp.net each month (some of which are umbrella projects).
I am happy to report that I have given up, I don't have time to track
them all.
Kudos to the nice Common-Lisp.net folks and the maintainers of the
projects hosted there.
Paolo
--
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
From: Cameron MacKinnon
Subject: Re: Better is better: improving productivity through programming languages
Date:
Message-ID: <9pOdnQcx6vZHSu3d4p2dnA@golden.net>
adam connor wrote:
> As a Lisp newbie, I found this essay very interesting:
> http://www.dehora.net/journal/archives/000423.html (The thread subject
> is taken from the title of the essay.)
>
> I'm curious as to what folks in comp.lang.lisp might think about it.
I wish the author had spelled my name correctly.
--
Cameron MacKinnon
Toronto, Canada
> Cameron MacKinnon
> I wish the author had spelled my name correctly.
Hi,
I just did - my apologies.
I wanted to respond to some comments here, and then go back to
lurking.
[[[ Kenny Tilton:
If you want to play "big picture", play "big picture": The Lisp model
has won (see Python, Perl, PHP, Ruby, Groovy, VB(?!)). The copycats
are poor copies. cll is filling up with newbies. So far so
indisputable. Now what is going to stop more and more people from
switching to Lisp and devloping the libraries they need?
The big mistake in that piece is explaining why MegaCorp wont adopt
Lisp tomorrow morning, Monday, at 9am. That's not how it works. It
will be a grass roots thing. Where does he think Python came from?
]]]
It's not my intent to play big picture there, but write a
representation of how a part of the industry I work seems to function,
for better or worse.
There was a part I took out of that entry: "It seems to be relative
popularity. I know programmers who would love Python or Ruby to be as
popular as Java. Heck, I'd love that." In fact, orginally that /was/
the entry. Maybe I should have left it at that. I'm not sure about
Lisp - I don't know if it's a grassroots thing now, or ever was. What
I do know is that Python can still be a very hard sell versus C# or
Java, and that the best tool for the job is not always given the
weight as much as other considerations. That's unfortunate but it is
the case.
I do take your point about the big picture (I mentioned language
evolution as being toward Lisp), but as Keynes observed, in the long
run we're all dead. In the meantime languages like Ruby and Python,
and to some extent Groovy, do represent progress of a sort.
[[[ Wade Humeniuk:
Its written by someone who wants to lead but does not want to do any
of the actual work. Don't get sucked in to someone's internal virtual
world.
]]]
I'm not sure what's meant by that, but as that someone, I'm not sure
it isn't true. Weirdly inoffensive.
[[[ Bulent Murtezaoglu:
I think it's quite rare for there to be genuine unprovoked rudeness,
although I know some will disagree (I even know some of their
names...)
]]]
Arrogance was what I was thinking about, rather than rudeness. Perhaps
I'd be arrogant too, under the circumstances.
Perhaps I've run across the wrong Lisp programmers, y'all are being
quite polite (or perhaps I'm perpetuating an urban myth and shoud be
ashamed). Fwiw, that entry is probably equally objectionable to people
who aren't using Lisp for paid work (esp in
middleware/integration/businessware).
cheers
Bill de h�ra
Bill de h?ra wrote:
> [[[ Kenny Tilton:
> If you want to play "big picture", play "big picture": The Lisp model
> has won (see Python, Perl, PHP, Ruby, Groovy, VB(?!)). The copycats
> are poor copies. cll is filling up with newbies. So far so
> indisputable. Now what is going to stop more and more people from
> switching to Lisp and devloping the libraries they need?
>
> The big mistake in that piece is explaining why MegaCorp wont adopt
> Lisp tomorrow morning, Monday, at 9am. That's not how it works. It
> will be a grass roots thing. Where does he think Python came from?
> ]]]
>
> It's not my intent to play big picture there, but write a
> representation of how a part of the industry I work seems to function,
> for better or worse.
Welll, I was reacting to this bit of crystal ball work:
"Honestly I don't see us rushing to embrace Lisp this decade. I think
the candidates today are clearly Ruby, Python, and perhaps on Java, Groovy."
Six years out is a lonnngggg way out, especially since it seems to me
the language pool is getting increasingly active and unstable, not less
so as one might expect.
> Perhaps I've run across the wrong Lisp programmers, y'all are being
> quite polite...
We were unchaining the hounds when someone noticed:
"Lisp seems to represent a pinnacle of achievement in programming
languages that is as yet, unmatched."
Now we have to wait for a Scheme bigot to come along so the the dogs can
get some exercise.
kt
--
Home? http://tilton-technology.com
Cells? http://www.common-lisp.net/project/cells/
Cello? http://www.common-lisp.net/project/cello/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
From: Paul Dietz
Subject: Re: Better is better: improving productivity through programminglanguages
Date:
Message-ID: <4072D843.572B2F4E@motorola.com>
Kenny Tilton wrote:
> Six years out is a lonnngggg way out, especially since it seems to me
> the language pool is getting increasingly active and unstable, not less
> so as one might expect.
One reason for that is:
It's getting easier to implement languages.
I think some of the pickup in lisp activity comes from
computers just being so darned fast these days. It's easier
to hack and test big programs (like, language implementations)
than it ever has been.
Paul
Paul Dietz wrote:
> One reason for that is:
>
> It's getting easier to implement languages.
>
> I think some of the pickup in lisp activity comes from
> computers just being so darned fast these days. It's easier
> to hack and test big programs (like, language implementations)
> than it ever has been.
>
> Paul
It's also harder to implement anything else- 99% of 'day job' software
engineering seems to be accidental, with only 1% on the conceptual
problem solving stuff. With a new language and no libraries, legacy
systems or integration issues you get back in control.
Pete
From: Ulrich Hobelmann
Subject: Re: Better is better: improving productivity through programming languages
Date:
Message-ID: <c4tulk$2mqevc$1@uni-berlin.de>
Kenny Tilton wrote:
> Welll, I was reacting to this bit of crystal ball work:
>
> "Honestly I don't see us rushing to embrace Lisp this decade. I think
> the candidates today are clearly Ruby, Python, and perhaps on Java,
> Groovy."
>
> Six years out is a lonnngggg way out, especially since it seems to me
> the language pool is getting increasingly active and unstable, not less
> so as one might expect.
Always good to see people doubt the mainstream "state of the art" :)
> We were unchaining the hounds when someone noticed:
>
> "Lisp seems to represent a pinnacle of achievement in programming
> languages that is as yet, unmatched."
>
> Now we have to wait for a Scheme bigot to come along so the the dogs can
> get some exercise.
Which leads me to: just what is it that you people here hate about
Scheme? (it was my first "alternative" language, and other than lack of
libraries I don't see that many shortcomings; the SRFIs are coming
along) Are some major problems (lack of power) with their macro system?
Is there a link which discusses Scheme vs CL?
Regards, Ulrich
Ulrich Hobelmann wrote:
> Kenny Tilton wrote:
>
>> Welll, I was reacting to this bit of crystal ball work:
>>
>> "Honestly I don't see us rushing to embrace Lisp this decade. I think
>> the candidates today are clearly Ruby, Python, and perhaps on Java,
>> Groovy."
>>
>> Six years out is a lonnngggg way out, especially since it seems to me
>> the language pool is getting increasingly active and unstable, not
>> less so as one might expect.
>
>
> Always good to see people doubt the mainstream "state of the art" :)
Sure, but I am curious about the first and second derivatives. You would
think that the herd would in moving to better and better languages stay
longer and longer before becoming restless and/or being enticed away to
a greener pasture.
Are they moving to worse and worser languages? My theory is that Lisp is
the black hole at the center of the computer language galaxy and that
everything is accelerating increasingly because the inverse square
thing. Which is why six years is a lonnnnnggg time, and why it is futile
for Java to do Groovy.
All your dynamic models are belong to us!*
>
>> We were unchaining the hounds when someone noticed:
>>
>> "Lisp seems to represent a pinnacle of achievement in programming
>> languages that is as yet, unmatched."
>>
>> Now we have to wait for a Scheme bigot to come along so the the dogs
>> can get some exercise.
>
>
> Which leads me to: just what is it that you people here hate about
> Scheme?
Hate? Well I /was/ joking, but of course the joke rests on the
occasional familial spat.
(it was my first "alternative" language, and other than lack of
> libraries I don't see that many shortcomings; the SRFIs are coming
> along) Are some major problems (lack of power) with their macro system?
Stuff like that. Scheme is this breakaway rebel group that headed off to
the mountains to start a revolution. <yawn> But Lisp needs the head
count so I like to count them as Lispniks. Until Common Lisp has
sufficient critical mass, then it's off with their heads.
kt
--
Home? http://tilton-technology.com
Cells? http://www.common-lisp.net/project/cells/
Cello? http://www.common-lisp.net/project/cello/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
From: Sunnan
Subject: Re: Better is better: improving productivity through programming languages
Date:
Message-ID: <87u0zx6zp0.fsf@handgranat.org>
> Stuff like that. Scheme is this breakaway rebel group that headed off
> to the mountains to start a revolution. <yawn> But Lisp needs the head
> count so I like to count them as Lispniks.
I can understand that there's lot of dirty water under the bridge
between the two camps (I've been reading _The Evolution of Lisp_) but
what about all the newbies that came along, found two camps and found
it to be a pretty hard choice?
I find both languages somewhat lacking when compared to each other.
--
One love,
Sunnan
Sunnan wrote:
>>Stuff like that. Scheme is this breakaway rebel group that headed off
>>to the mountains to start a revolution. <yawn> But Lisp needs the head
>>count so I like to count them as Lispniks.
>
>
> I can understand that there's lot of dirty water under the bridge
> between the two camps (I've been reading _The Evolution of Lisp_) but
> what about all the newbies that came along, found two camps and found
> it to be a pretty hard choice?
It's their fault, they should have come here to c.l.l. and we would have
straightened them out. Where are they?
The differences between the two languages are pretty dramatic, so I am
surprised to hear of hordes of newbies unable to choose between them.
My guess is that they are not actually writing code. Shopping for
clothes is pretty hard until I start trying things on and see how they
look on /me/.
kt
--
Home? http://tilton-technology.com
Cells? http://www.common-lisp.net/project/cells/
Cello? http://www.common-lisp.net/project/cello/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
From: Cameron MacKinnon
Subject: Re: Better is better: improving productivity through programming
Date:
Message-ID: <aKednXUU0MGmm-7d4p2dnA@golden.net>
Kenny Tilton wrote:
> Sunnan wrote:
>> I can understand that there's lot of dirty water under the bridge
>> between the two camps (I've been reading _The Evolution of Lisp_) but
>> what about all the newbies that came along, found two camps and found
>> it to be a pretty hard choice?
>
> It's their fault, they should have come here to c.l.l. and we would have
> straightened them out. Where are they?
>
> The differences between the two languages are pretty dramatic, so I am
> surprised to hear of hordes of newbies unable to choose between them.
No, the differences between the languages are miniscule, and magnified
out of all proportion by drama queens.
Consider:
- Lots of irritating superfluous parentheses[*]
- powerful macro system
- garbage collection
- CONS cells
- closures
- higher order and first class functions
- REPL
- recursion
- a user community full of smug weenies
- a standard and a number of conforming implementations
There's more, but I'm sure you get the idea.
In his first days, someone new to the field will be unable to tell
between Scheme and Lisp code. And if he's conscientious and tries
reading up on the technical differences, there's all manner of Lisp-1
versus Lisp-2 papers, which quickly start to look like irrelevent
theological discussions. Or he asks in a newsgroup, and gets an
irreverent theological discussion.
> My guess is that they are not actually writing code. Shopping for
> clothes is pretty hard until I start trying things on and see how they
> look on /me/.
So fifteen minutes with each one ought to be enough to choose?
Of course they're not writing code! They're spending time figuring out
which language to spend the next three months learning. And once they've
waded through a lot of discussions like this one in the archives,
they'll have to face round two, choosing which of a number of
implementations to use.
"Decisions in rearview mirror appear more obvious than they were at the
time."
There was a rumour recently that someone was going to put lipstick on
one of the pigs (I think OpenGL was mentioned) so that newbies could
tell them apart.
My advice: Find a text or tutorial that you like, and use the language
that's in that. Switching later is easy. For bonus self-flagellation
points, use the language that the text doesn't use: This is still pretty
easy (unless the text is "On Lisp"), but it highlights the differences.
Criminy, yesterday that "Who is Erik?" guy and today this. Maybe when
Sun and MS joined forces, it was to create an Abstract Usenet Troll
Factory class to distract Lispers. :-)
[*] From a newbie's perspective! No flames please.
--
Cameron MacKinnon
Toronto, Canada
From: Sunnan
Subject: Re: Better is better: improving productivity through programming
Date:
Message-ID: <87lll83mxl.fsf@handgranat.org>
Cameron MacKinnon <··········@clearspot.net> writes:
> And if he's conscientious and tries reading up on the technical
> differences, there's all manner of Lisp-1 versus Lisp-2 papers,
Where?! Where can these mythical papers be found?
I can only find the famous Gabriel/Pitman one.
> There was a rumour recently that someone was going to put lipstick on
> one of the pigs (I think OpenGL was mentioned) so that newbies could
> tell them apart.
I don't understand this paragraph. Both scheme and CL has OpenGL
support and neither is a pig.
> My advice: Find a text or tutorial that you like, and use the language
> that's in that.
Good idea.
> Switching later is easy. For bonus self-flagellation points, use the
> language that the text doesn't use: This is still pretty easy
> (unless the text is "On Lisp"), but it highlights the differences.
I didn't have trouble following "On Lisp" with scheme +
non-R5RS-extensions.
Similarly, if someone added first class continuations to CL I guess
Dorai's "Teach yourself Scheme" would be practical.
--
One love,
Sunnan
From: Cameron MacKinnon
Subject: Re: Better is better: improving productivity through programming
Date:
Message-ID: <wq2dncUETZSgh-7dRVn-jA@golden.net>
Sunnan wrote:
> Cameron MacKinnon <··········@clearspot.net> writes:
>
>>And if he's conscientious and tries reading up on the technical
>>differences, there's all manner of Lisp-1 versus Lisp-2 papers,
>
>
> Where?! Where can these mythical papers be found?
> I can only find the famous Gabriel/Pitman one.
There's interesting nuggets in
http://www8.informatik.uni-erlangen.de/html/lisp/mcc91.html
Maybe "papers" was too strong. I read a lot of web pages, old Usenet
threads, the Gabriel/Pitman paper. I came to these conclusions:
- esthetically, I prefer Lisp-1
- opinions are entrenched on both sides, it's a religious (or, if you
will, political) thing.
- expressing an opinion is an easy way to start a flamewar
- it doesn't really matter. Compare productivity in Lisp-1, Lisp-2,
Java and C++.
- because different researchers are attracted to each camp, each has
built up areas of expertise. It's wise to monitor both, so that you
recognise, for problem x, that "the other guys" have more code to study.
It isn't like deciding whether to learn latin or greek, it's more like
deciding whether to print in Times New Roman or Helvetica.
>>There was a rumour recently that someone was going to put lipstick on
>>one of the pigs (I think OpenGL was mentioned) so that newbies could
>>tell them apart.
>
> I don't understand this paragraph. Both scheme and CL has OpenGL
> support and neither is a pig.
"Putting lipstick on a pig" is an expression meaning to try to make
something ugly look beautiful. Kenny Tilton has been evangelizing here
for quite some time about Cello (see his .sig), his new OpenGL based GUI
framework. His opening gambit was mainly criticizing earlier efforts;
there were some entertaining flamefests.
> I didn't have trouble following "On Lisp" with scheme +
> non-R5RS-extensions.
I did SICP in CL. What did you learn from before "On Lisp"? Anything?
I'll likely tackle On Lisp next. Maybe I should do it in Scheme. What
extensions would you recommend?
--
Cameron MacKinnon
Toronto, Canada
Cameron MacKinnon <··········@clearspot.net> writes:
re Scheme vs CL --
> No, the differences between the languages are miniscule, and magnified
> out of all proportion by drama queens.
>
> Consider:
> - Lots of irritating superfluous parentheses[*]
> - powerful macro system
> - garbage collection
> - CONS cells
> - closures
> - higher order and first class functions
> - REPL
> - recursion
> - a user community full of smug weenies
> - a standard and a number of conforming implementations
>
> There's more, but I'm sure you get the idea.
Are the differences between C and Pascal miniscule? C++ and Simula?
Algol 60 and 68? I'm not sure what your metric is.
-- jd
From: Ray Dillinger
Subject: Re: Better is better: improving productivity through programming
Date:
Message-ID: <4073BF88.98100FBD@sonic.net>
Jeff Dalton wrote:
>
> Cameron MacKinnon <··········@clearspot.net> writes:
>
> re Scheme vs CL --
>
> > No, the differences between the languages are miniscule, and magnified
> > out of all proportion by drama queens.
> >
> > <snip list of Lispy similarities>
> >
> > There's more, but I'm sure you get the idea.
>
> Are the differences between C and Pascal miniscule?
Actually, yes. They're both imperative statement-oriented languages
with hardware-based static typing and explicit heap manipulation.
Pascal's type checking and bounds-checking are a little tighter than
C's, and Pascal has lexically scoped nested procedures to help manage
namespace better, but otherwise they have near-identical semantics.
Speaking as someone who has used both, they are essentially
misspellings of each other. Pascal is a little more restrictive/safer,
but they embody exactly the same ideas about what programming is.
I think Pascal is related to C just about as closely as Scheme is
related to Common Lisp, and in many of the same ways. The differences
in each case are trivial in terms of language semantics.
Bear
From: Chris Hall
Subject: Re: Better is better: improving productivity through programming
Date:
Message-ID: <87hdvvgio2.fsf@naia.homelinux.net>
Cameron MacKinnon <··········@clearspot.net> writes:
...
> No, the differences between the languages are miniscule, and magnified
> out of all proportion by drama queens.
>
> Consider:
> - Lots of irritating superfluous parentheses[*]
...
> - recursion
> - a user community full of smug weenies
> - a standard and a number of conforming implementations
>
> There's more, but I'm sure you get the idea.
>
...
>
> Of course they're not writing code! They're spending time figuring out
> which language to spend the next three months learning. And once
> they've waded through a lot of discussions like this one in the
> archives, they'll have to face round two, choosing which of a number
> of implementations to use.
>
...
>
> My advice: Find a text or tutorial that you like, and use the language
> that's in that. Switching later is easy. For bonus self-flagellation
> points, use the language that the text doesn't use: This is still
Describes my experience so far to a 'T'!
--
We learn from history that we do not learn from history.
-- Georg Friedrich Wilhelm Hegel
From: Sunnan
Subject: Re: Better is better: improving productivity through programming languages
Date:
Message-ID: <87vfkd3q78.fsf@handgranat.org>
Kenny Tilton <·······@nyc.rr.com> writes:
> It's their fault, they should have come here to c.l.l. and we would
> have straightened them out. Where are they?
Well, I once was in that position - I was delighted with emacs lisp
and wondered where to go next. (A couple of years ago - as I've just
found out from reading the archives, cll wasn't the nicest place back
then. It seems to have improved.)
Someone gave me SICP and that straightened me out (or crookened me,
YMMV).
> The differences between the two languages are pretty dramatic, so I am
> surprised to hear of hordes of newbies unable to choose between them.
I find the technical differences exaggerated and the cultural
differences striking. Your description, "went off to a mountain",
seems pretty accurate.
> My guess is that they are not actually writing code. Shopping for
> clothes is pretty hard until I start trying things on and see how they
> look on /me/.
If I'm writing practical code for my own use, it isn't so hard. (I'm
currently writing a small two-dimensional action game/passtime using
SDL, and I chose scheme for that particular project.)
But sometimes you come up with a good idea for a library (you must
know, you came up with Cells) and you wonder which community to
support (ok, that part's maybe not so hard in your case).
I kind of admire Dorai a bit since he (she?) wrote his regex package
for both CL and Scheme. From the same source.
--
One love,
Sunnan
From: Edi Weitz
Subject: Re: Better is better: improving productivity through programming languages
Date:
Message-ID: <m3zn9oubb7.fsf@bird.agharta.de>
On Tue, 06 Apr 2004 18:41:25 GMT, Sunnan <······@handgranat.org> wrote:
> I kind of admire Dorai a bit since he (she?) wrote his regex package
> for both CL and Scheme. From the same source.
AFAIK he wrote the package in Scheme and created the CL version with
an automatic translator (which incidentally was also written by him).
Edi.
"Ulrich Hobelmann" <···········@web.de> wrote in message
····················@uni-berlin.de...
> Which leads me to: just what is it that you people here hate about
> Scheme? (it was my first "alternative" language, and other than lack of
> libraries I don't see that many shortcomings; the SRFIs are coming
> along) Are some major problems (lack of power) with their macro system?
> Is there a link which discusses Scheme vs CL?
No doubt there is.
There are two key differences between CL and Scheme.
One, is that CL is a Lisp-2 whereas Scheme is a Lisp-1.
Two, is that Scheme requires full blown continuations, and CL does not.
If neither of these issues are compelling to you then you can easily write
"Scheme code" in CL and never look back.
The Scheme standard is not robust enough to do "real work" in unless your
"real work" is adding all of the stuff that makes CL capable of "real work".
Schemes strength and weakness is that while the stock Scheme standard is not
particularly useful, it can readily be layered upon to create an "industrial
strength" Scheme system. The down side is that as soon as an implementation
drifts from the standard, you lack portability and are essentially locked
into a single implementation environment.
This obviously isn't necessarily "bad", as perl and python are both single
implementation systems that have had good success.
Back In The Day when Lisp was diversifying to its many flavors, there was
the motivation for the creation of Common Lisp in order to better ensure
cross implementation portability. This process resulted in a standard that
documents an very powerful and rich language system on which a developer can
create reasonably portable code.
Scheme is now in the state where there are several very powerful
implementations that are pretty much incompatible with each other. It's not
clear whether there is any motivation to unify the Schemes, though there is
some movement to standardize certain parts through the SRFI process.
It is not clear to me that implementing some of the larger, feature rich
Schemes was any easier than implementing a Common Lisp. If that's true, then
it seems an awful lot of work was done to recreate a CL like environment
solely for the perceived benefits of having a Lisp-1 and/or full blow
continuations.
One can argue that these features in the big Scheme implementations were
made incrementally, rather than having to have been done "all at once".
Perhaps, but the point is that after all of the time they put in to the
projects, they're essentially where CL was 10-15 years ago. While it can be
argued that CL hasn't changed much in 15 years, it can also be argued that
despite all of the change in the Scheme implementations over the past 15
years, what does the fact that "they're just catching up" say?
Regards,
Will Hartung
(·····@msoft.com)
"Will Hartung" <·····@msoft.com> writes:
> It is not clear to me that implementing some of the larger, feature rich
> Schemes was any easier than implementing a Common Lisp. If that's true, then
> it seems an awful lot of work was done to recreate a CL like environment
> solely for the perceived benefits of having a Lisp-1 and/or full blow
> continuations.
To me, the major "perceived benefit" of using a Scheme instead of a CL
is it's teachability: These 50 pages of Scheme are _much_ easier to
teach than CL (which, IMHO, can only be understood if you know quite a
lot of history of Lisp). This is especially relevant when you teach
programming to beginners and when you teach "advanced" classes, where
programming is not the major focus (there you want a decent language
which students have to pick up on their own; Scheme is well-suited for
this job).
From: ······@nordebo.com
Subject: Re: Better is better: improving productivity through programming languages
Date:
Message-ID: <87zn9nx21k.fsf@pluto.elizium.org>
Matthias <··@spam.pls> writes:
> To me, the major "perceived benefit" of using a Scheme instead of a CL
> is it's teachability: These 50 pages of Scheme are _much_ easier to
> teach than CL (which, IMHO, can only be understood if you know quite a
> lot of history of Lisp).
What prevents you from presenting the basics of Common Lisp in 50
pages? You don't need to teach your students everything at once, you
can easily ignore most of CLOS, the pathname system, the type system,
the condition system, the loop macro, format, etc for the intro and
let the students learn these parts as they need or want them. Apart
from continuations, everything that is in Scheme is also in CL and is
just as easy to learn.
Of course you may feel that there are better textbooks and other
teaching materials available for Scheme, but that would be a
completely different issue, nothing to do with the relative size of
the specifications.
> This is especially relevant when you teach programming to beginners
> and when you teach "advanced" classes, where programming is not the
> major focus (there you want a decent language which students have to
> pick up on their own; Scheme is well-suited for this job).
Common Lisp was taught in my second programming course at university
(the first being Pascal), and was my first real contact with Lisp. I
didn't find it hard to grasp the whole language because it was not
necessary to do so. We were introduced to something that was pretty
much the functionality of Scheme minus continuations and with defmacro
for macros, and the vastness of CL never was an issue at all.
······@nordebo.com writes:
> Matthias <··@spam.pls> writes:
>
> > To me, the major "perceived benefit" of using a Scheme instead of a CL
> > is it's teachability: These 50 pages of Scheme are _much_ easier to
> > teach than CL (which, IMHO, can only be understood if you know quite a
> > lot of history of Lisp).
>
> What prevents you from presenting the basics of Common Lisp in 50
> pages?
It's work which doesn't pay off in my situation. Also, I don't
believe in teaching artificial subsets: Students will read other
people's code (I encourage them to do so!) and they have a right to
get their questions on that answered by me.
My original posting was just suggesting that continuations and lisp-1
may not be the main reasons why some people choose Scheme over CL:
Perceived simplicity, consistency in design and a reasonable naming
scheme are benefits in some situations (teaching). You can't extend
CL to support these features.
(Note that I completely agree that CL's perceived complexity, its
inconsistent design and unreasonable naming scheme becomes a non-issue
after a while of using it. It's just that it may be too long a time
for a class with only a couple of exercises.)
"Matthias" <··@spam.pls> wrote in message
····················@hundertwasser.ti.uni-mannheim.de...
> ······@nordebo.com writes:
>
> > Matthias <··@spam.pls> writes:
> >
> > > To me, the major "perceived benefit" of using a Scheme instead of a CL
> > > is it's teachability: These 50 pages of Scheme are _much_ easier to
> > > teach than CL (which, IMHO, can only be understood if you know quite a
> > > lot of history of Lisp).
> >
> > What prevents you from presenting the basics of Common Lisp in 50
> > pages?
>
> It's work which doesn't pay off in my situation. Also, I don't
> believe in teaching artificial subsets: Students will read other
> people's code (I encourage them to do so!) and they have a right to
> get their questions on that answered by me.
>
> My original posting was just suggesting that continuations and lisp-1
> may not be the main reasons why some people choose Scheme over CL:
> Perceived simplicity, consistency in design and a reasonable naming
> scheme are benefits in some situations (teaching). You can't extend
> CL to support these features.
Save for the Lisp-1 vs Lisp-2 dynamic, I disagree.
The most basic example of this is the book "Simply Scheme" which teaches
Scheme using its own "library" of functions, etc. You can't do any of even
the most basic excercises in the book without loading the compatability
layer. SICP also uses its own version of Scheme.
The Little Lisper/Schemer uses the smallest of vocabularies to teach
Lisp/Scheme.
Just because you are teaching a subset does not mean that you as teacher
have to only KNOW a subset and can't use the extended knowledge for those
who find other things. One of the most annoying comments I got once on a
programming project in school was "you don't know how to do this yet".
REALLY!??
Considering the utter lack of portability amongst the high end Schemes and
their extended functionality, if you teach a Scheme class and tell people to
go read others code, what happens when they come back with a construct that
isn't even available in the implementation you are using?
Again, save for the Lisp-1 vs Lisp-2 detail, 50 pages of CL is "just as
simple" as 50 pages of Scheme. If you want more naming consistency, etc,
then write a few functions or macros to clean it up. At the end students
will a) understand what substituitions you made and make them themselves
later, b) take your compatability layer with them on future projects or c)
never touch Lisp again for unrelated reasons, so teaching them "wrong" did
no harm one way or the other.
Perhaps the Lisp-1/Lisp-2 thing is THE sticking point and if that is the
case, you're right, CL isn't as simple as Scheme, and it is difficult to
tweak CL to get around that. But, IMHO, that's throwing the baby out with
the bathwater. Yes, CL Symbols are large objects with vast capabilities, but
if they're not presented that way, students won't know the difference. Those
who want to know will learn, those who don't won't miss the extra
functionality.
Regards,
Will Hartung
(·····@msoft.com)
"Will Hartung" <·····@msoft.com> writes:
> "Matthias" <··@spam.pls> wrote in message
> ····················@hundertwasser.ti.uni-mannheim.de...
> > My original posting was just suggesting that continuations and lisp-1
> > may not be the main reasons why some people choose Scheme over CL:
> > Perceived simplicity, consistency in design and a reasonable naming
> > scheme are benefits in some situations (teaching). You can't extend
> > CL to support these features.
>
> Save for the Lisp-1 vs Lisp-2 dynamic, I disagree.
>
> The most basic example of this is the book "Simply Scheme" which teaches
> Scheme using its own "library" of functions, etc. You can't do any of even
> the most basic excercises in the book without loading the compatability
> layer. SICP also uses its own version of Scheme.
The second (current) edition of SICP doesn't.
> Just because you are teaching a subset does not mean that you as teacher
> have to only KNOW a subset and can't use the extended knowledge for those
> who find other things. One of the most annoying comments I got once on a
> programming project in school was "you don't know how to do this yet".
> REALLY!??
I agree completely.
> Considering the utter lack of portability amongst the high end Schemes and
> their extended functionality, if you teach a Scheme class and tell people to
> go read others code, what happens when they come back with a construct that
> isn't even available in the implementation you are using?
I'd probably try to explain anyway. But I'm not sure: This scenario
so far has not happened.
> If you want more naming consistency, etc, then write a few functions
> or macros to clean it up.
So I write my own wrapper functions, my own documentation for it, my
own test code, my own examples and demonstration code. That's a lot
of work and I end up with something Schemish. What do I gain in
return? What do my students gain?
And am I still teaching CL after all? Or just another personal toy
language which happens to be implemented in CL?
> Perhaps the Lisp-1/Lisp-2 thing is THE sticking point and if that is the
> case, you're right, CL isn't as simple as Scheme, and it is difficult to
> tweak CL to get around that. But, IMHO, that's throwing the baby out with
> the bathwater. Yes, CL Symbols are large objects with vast capabilities, but
> if they're not presented that way, students won't know the difference. Those
> who want to know will learn, those who don't won't miss the extra
> functionality.
I see it that way: The classes I am involved in are not about
programming languages at all. They are not about training people to
write production code. They are about understanding computation and
basic algorithms (CS101) or concepts of computer graphics, computer
vision, machine learning. Every language that does not take away too
much time for its own is acceptable for either of these classes.
Scheme is an excellent choice in this regard. I have my doubts with
CL-as-we-know-it.
From: Tim Daly Jr.
Subject: Re: Better is better: improving productivity through programming languages
Date:
Message-ID: <87k70vbcmy.fsf@hummer.intern>
adam connor <···················@mail.com> writes:
> As a Lisp newbie, I found this essay very interesting:
> http://www.dehora.net/journal/archives/000423.html (The thread subject
> is taken from the title of the essay.)
>
> I'm curious as to what folks in comp.lang.lisp might think about it.
"A programming language is one thing, but a libraries is another."
I feel the same way sometimes.
--
-Tim
From: Wade Humeniuk
Subject: Re: Better is better: improving productivity through programming languages
Date:
Message-ID: <f72cc.10963$J56.313@edtnps89>
adam connor wrote:
> As a Lisp newbie, I found this essay very interesting:
> http://www.dehora.net/journal/archives/000423.html (The thread subject
> is taken from the title of the essay.)
>
> I'm curious as to what folks in comp.lang.lisp might think about it.
Its written by someone who wants to lead but does not want to do any of the
actual work. Don't get sucked in to someone's internal virtual world.
Wade
adam connor <···················@mail.com> wrote in message news:<··································@4ax.com>...
> As a Lisp newbie, I found this essay very interesting:
> http://www.dehora.net/journal/archives/000423.html (The thread subject
> is taken from the title of the essay.)
>
> I'm curious as to what folks in comp.lang.lisp might think about it.
I would say that more libraries would be good. The good news is that
they are in fact comming. A lot has changed for the better in the Lisp
world since my first abortive attempt to learn it back in 1998.
Another thing I would say is important is protocol support. This can
of course get wrapped up in libraries. As much as Lispers may not
like XML or whatever, Lisp should be very good at both digesting and
excreting it.
While I don't really think that the JVM or .NET thing are such hot ideas,
I think it would be cool to embed byte code interpreters in Lisp. I don't
know if it would actually be useful or sellable, but it might be interesting
if a Lisp image running on some server could deal with Java Beans or
accept and hand out Java interfaces for some form of RPC.
I also don't see a reason why Lisp can't generate class files. Although
I suspect that doing that would involve some macro voodoo and meta
programming that is both harder and less flexible than normal Lisp.
I would actually like to see Lisp become a more popular language. Not
just in terms of absolute numbers of users, but in % of mindshare. There
is something to be said for popularity. It doesn't have to be a bad thing.
That said, programming is a difficult art and I don't think there is a
language or methodology in existence that can change that. Those
tools that seem to make programming easier (WYSIWYG GUI tools)
are really just auto-genning boilerplate code. No real programming
actually gets done with such tools.
David Steuber wrote:
> Another thing I would say is important is protocol support. This can
> of course get wrapped up in libraries. As much as Lispers may not
> like XML or whatever, Lisp should be very good at both digesting and
> excreting it.
Yes, but every lisper writes their own library for the subset of XML
that they're expecting.
> I also don't see a reason why Lisp can't generate class files. Although
> I suspect that doing that would involve some macro voodoo and meta
> programming that is both harder and less flexible than normal Lisp.
When I wanted to much around with class files, I ended up with a lisp
dialect. I'm in the process of generalizing its model- so I can use it
to emit Java source & build an ASN.1 compiler out of it. Basically it
has a pattern matcher and a "macro expander" to do general transforms
for abstract syntax and metamodel. Sort of lisp as AST syntax with QVT
and some ideas from relational ML built in. There's no reason to have
one transformation language for metamodels, one for source code and one
for compiler optimisations, which is what QVT, automated refactoring
tools and current compilers seem to have- except you can only program qvt.
The lisp in armedbear-j also has some of a compiler implementation which
generates .class files; as do various schemes like bigloo (is there a
web page that summarizes lisps on JVM/CLI? a search for JVM on cliki
comes up with those two implementations only).
> Those tools that seem to make programming easier (WYSIWYG GUI tools)
> are really just auto-genning boilerplate code. No real programming
> actually gets done with such tools.
Up to a point- if you don't know the libraries, then auto generating the
boilerplate is many times faster than searching the manual; they reduce
some of the accidental, so you have a little more time for the real
programming, so it's sort of easier.
Pete
From: Pascal Costanza
Subject: Re: Better is better: improving productivity through programming languages
Date:
Message-ID: <c4v2va$sb0$2@f1node01.rhrz.uni-bonn.de>
Pete Kirkham wrote:
> The lisp in armedbear-j also has some of a compiler implementation which
> generates .class files; as do various schemes like bigloo (is there a
> web page that summarizes lisps on JVM/CLI? a search for JVM on cliki
> comes up with those two implementations only).
See http://www.robert-tolksdorf.de/vmlanguages.html#lispandco
Pascal
--
ECOOP 2004 Workshops - Oslo, Norway
*1st European Lisp and Scheme Workshop, June 13*
http://www.cs.uni-bonn.de/~costanza/lisp-ecoop/
*2nd Post-Java Workshop, June 14*
http://prog.vub.ac.be/~wdmeuter/PostJava04/
From: David Steuber
Subject: Re: Better is better: improving productivity through programming languages
Date:
Message-ID: <873c7gjrcu.fsf@david-steuber.com>
Pete Kirkham <·················@cafemosaic.co.uk> writes:
> David Steuber wrote:
> > Another thing I would say is important is protocol support. This can
> > of course get wrapped up in libraries. As much as Lispers may not
> > like XML or whatever, Lisp should be very good at both digesting and
> > excreting it.
>
> Yes, but every lisper writes their own library for the subset of XML
> that they're expecting.
Is this really better than having something like SAX?
> > Those tools that seem to make programming easier (WYSIWYG GUI tools)
> > are really just auto-genning boilerplate code. No real programming
> > actually gets done with such tools.
>
> Up to a point- if you don't know the libraries, then auto generating
> the boilerplate is many times faster than searching the manual; they
> reduce some of the accidental, so you have a little more time for the
> real programming, so it's sort of easier.
I'm not saying the interface building tools have no value. They are
certainly good for getting the ball rolling. The heavy lifting part
of an application is not going to be so simple, so you will just run
into the wall a little further down the road. For a really complex
application, it is even possible that usability studies will show a
need to make major UI changes. Cocoa has MVC, so if you do things
right that may not be such a big deal.
I'll stick with the theory that in general programming is hard.
However, Lisp has value because it has similar (or perhaps greater)
expressiveness to VHLLs like Python allowing so called rapid
prototyping combined with the perfomance of compiled languages like
C. I think that is Lisp's main win. Programming is still hard, but
the language is helping as much as it can (for now).
--
It would not be too unfair to any language to refer to Java as a
stripped down Lisp or Smalltalk with a C syntax.
--- Ken Anderson
http://openmap.bbn.com/~kanderso/performance/java/index.html
David Steuber wrote:
> Pete Kirkham <·················@cafemosaic.co.uk> writes:
>>Yes, but every lisper writes their own library for the subset of XML
>>that they're expecting.
>
>
> Is this really better than having something like SAX?
No, every now and then on XML mailing lists someone (occasionally me)
posts a mapping of XML to lisp, and says lisp is "better". What is
missing is a standard mapping (there is a scheme one that seems to be
very common '(' tagname '(' list of attribute pairs ')' content ')' )
and the ad-hoc ones don't support schema validation, or necessarily
allow text data to be read as the types defined in the data model on
parsing.
Pete
From: Jeff Dalton
Subject: Re: Better is better: improving productivity through programming languages
Date:
Message-ID: <fx4ad1pn5m6.fsf@todday.inf.ed.ac.uk>
adam connor <···················@mail.com> writes:
> As a Lisp newbie, I found this essay very interesting:
> http://www.dehora.net/journal/archives/000423.html (The thread subject
> is taken from the title of the essay.)
>
> I'm curious as to what folks in comp.lang.lisp might think about it.
Iteresting. Thanks for the pointer.
Still, a couple of things.
For inst:
Too often, expressing yourself in Java is tedious.
Very true.
You cannot easily change the code that exists already. ...
Why not? Java doesn't seem especially bad there.
Clearly lots of people agree with me, since the main innovation in the
middleware/enterprise space since the adoption of VMs and managed
runtimes has been a steady stream of languages whose interpreters are
written in Java and an attempt to shift data, contracts and
configurations out of software objects into XML documents.
Why *do* people do that? I think it's a major pain.
I would *much* rather write in Java than in XML.
I hate it when something requires that I write XML files in
addition to my program.
Once upon a time that was a controversial thing to say - now it's
just obvious that there is plenty of work we do not want to use Java
for.
Sure, but that doesn't mean we want to "shift data, contracts and
configurations out of software objects into XML documents."
I wonder what is causing that shift.
Also, most of the article is written in English. Yet every so
often we see something like this:
Python usage in the enterprise is growing
What is causing that shift?
Perhaps this is the connection:
In the game of building business systems, we have demonized
programming.
(XML documents aren't [seen as] programs.)
-- jd