***************************************************************
Time for a Fresh Scheme Standard
And to Say Goodbye to the RnRS Relic
----------------------------------------------------
Is it time for a new scheme standard? Is it time to make a break from
the ossified RnRS document? Is it time to bring Scheme into the 21st
century?
Scheme has become very dated. The RnRS series of documents are a
relic of a more dynamic past but are now little more than a fossil
record of its ever slowing development. With each year that passes,
scheme becomes more irrelevant to the practical and academic software
development, education and research worlds.
So what should be done? Fix the uncertainties, clear up the undefined
areas. Don't be scared to admit weaknesses and mistakes in the
current standard. Solicit help from the Common Lisp community and
draw upon their extensive practical experience. Learn from the
Functional community and their many strong ideas. And ask the
compiler vendors about practicalities.
Its time for a fresh look at scheme. Its time to break away from the
RnRS and its brotherhood of old men in their isolated,
self-referential world. Its time to reinvigorate the language.
Its time for a new standard.
David Rush <····@bellsouth.net> wrote in message news:<···············@bellsouth.net>...
> So who the fuck are you anyway?
[...]
> This is such bullshit...
[...]
> This is such bullshit, it has to be a troll. You're secretly Erik
> Naggum aren't you?
[...]
> I did it in Scheme because I don't have to fuck around with
> a lot of stupid mis-features from 'advanced' languages like
> Perl, Python, Tcl, Ruby, or (God help us) C++ and Java
[...]
> the current generation of no-talent simps graduating into
> the CS business.
> > Solicit help from the Common Lisp community
[...]
> They're a bunch of losers who have bought and sold the
> lambda-nature for a profit.
[...]
> So who the fuck are you, Mr. Hotmail.com?
Your extreme pathologic response clearly demonstrates the problem with
the small, fundamentalist group of scheme "defenders of the faith"
that are being left further and further behind as the world moves
forward.
Anyone calling for injection of fresh ideas into the language is
attacked with a level of spite and religious vehemence rarely seen
outside of fundamentalist religious sects.
Rather than address the issues raised in the positing, you spent
considerable effort attacking me and others in your reply. You
attacked other languages such as Lisp, C++ and Perl.. You attacked
the other programming communities as if they were the devils own. I
can just imagine you frothing at the mouth, up on the pulpit declaring
that the evil sinners who do not follow the one true way of scheme
will rot in hell for all eternity.
Resisting the inevitable, sticking your head in the sand and yelling
obscenities at anyone and everyone who has the audacity to suggest
change is like pissing into an oncoming typhoon� you just end up with
wet pants, looking like a sad old man who has lost all bowel control.
Its time to reinvigorate scheme. See you in hell.
...
> david rush
> (who has just watched _the matrix_ for the first time and is feeling
> pretty radicalized just at the moment)
Congratulations on seeing the matrix; its only been out for, like,
three years. That explains alot.
-----------------------------------------------------------
David Rush <····@bellsouth.net> wrote in message news:<···············@bellsouth.net>...
> <posted-and-mailed why="cross-postings to cll and clf">
> <flame mode="on">
> ·········@hotmail.com (New Scheme) writes:
>
> So who the fuck are you anyway? I mean really, behind the
> freshly-minted hotmail alias. You sound like Tom Lord, but that's just
> my opinion.
>
> > ***************************************************************
> > Time for a Fresh Scheme Standard
> > And to Say Goodbye to the RnRS Relic
>
> This is such bullshit that I think I'm being trolled. Congratulations
> whoever, you have succeeded - but I don't agree with either your tone
> or your explicit opinions. R5RS is an excellent document, in spite of
> its need for revision. I have only two issues that I think *must* be
> fixed, and only one of them is truly controversial.
>
> No I'm not going to list them - If you don't know you can google for
> the info, but I suspect that you already do know. And I suspect that
> you have a particular wish-list...care to come out of the closet?
>
> > Is it time for a new scheme standard?
>
> No. It is time to open discussions.
>
> > Is it time to make a break from the ossified RnRS document?
>
> No. It has been one of the most successful language standards
> documents in history, at least by my criteria.
>
> > Is it time to bring Scheme into the 21st century?
>
> No. The 21st century still has a lot of catching up to do.
>
> > Scheme has become very dated. The RnRS series of documents are a
> > relic of a more dynamic past but are now little more than a fossil
> > record of its ever slowing development.
>
> This is such bullshit, it has to be a troll. You're secretly Erik
> Naggum aren't you? The RnRS series is converging on an idealized
> language; the changes are *bound* to become smaller over time.
>
> > With each year that passes,
> > scheme becomes more irrelevant to the practical and academic software
> > development, education and research worlds.
>
> Well I can't speak to academia, but I've got 7KLOC (and headed for the
> 20s) of very intelligent *commercially-developed* software which is
> very relevant to our business. I did it in Scheme because I don't have
> to fuck around with a lot of stupid mis-features from 'advanced'
> languages like Perl, Python, Tcl, Ruby, or (God help us) C++ and Java;
> all languages which will very quickly become dead-weight in legacy
> systems ensuring long-term pay stability for the current generation of
> no-talent simps graduating into the CS business.
>
> Scheme Lives!
>
> > Solicit help from the Common Lisp community and
> > draw upon their extensive practical experience.
>
> There are no good ideas over there. They've completely missed the
> boat. They're a bunch of losers who have bought and sold the
> lambda-nature for a profit. I mean really, who could take a language
> with that 'for' construct seriously. The 'do' is Scheme is bad
> enough. And CLOS, let's not waste time with that over-designed Sherman
> Tank. It's not even close to the bleeding edge of object-think.
>
> > Learn from the
> > Functional community and their many strong ideas.
>
> There is a *huge* cross-over from Scheme to the functional
> community. Scheme occupies a significant patch of the intellectual
> turf: untyped, eager-evaluation lambda-calculus.
>
> > And ask the compiler vendors about practicalities.
>
> There are 2: Chez (who seem to be taking the same tack that killed
> Smalltalk and charging $4000/seat), and Erian Concept (who I keep
> trying - and failing - to convince myself to try their free beer
> version). Scheme, in addition to advancing the pursuit of the
> lambda-nature is also essentially free: more free than any other
> language. Clearly freedom is too difficult for the mainstream software
> community to deal with, but so what? If I lived in New Hampshire I
> would put a motion to the State legislature to make Scheme the
> official computer language of the State (the State motto is 'Live Free
> or Die'), there are more high (and low) quality 'free speech' Schemes
> than exist for any other language. What does *that* tell you?
>
> > Its time for a fresh look at scheme. Its time to break away from the
> > RnRS and its brotherhood of old men in their isolated,
> > self-referential world. Its time to reinvigorate the language.
>
> Those are fucking *smart* old men. I just want to get them engaged
> again. I realize that the political infighting that got us a language
> as good as R5RS is a PITA - I have to deal with similar bullshit as a
> software architect at my day job. And it's a thankless job because at
> the end of the day, people are only going to pick the thing apart, but
> still somebody's got to do it.
>
> I'm not going to pretend that I can keep up with Shriram, Matthias F,
> Will, and Jonathan, or even Olin (no offense intended to Olin, I just
> am not aware of his contributions to R5RS), Matthias B, Oleg, and A*
> Petrofsky. I do care a lot about Scheme, though, and I wish that we
> could get some movement. I fear that Scheme might well suffer the fate
> of C and get replaced with something almost infinitely worse if these
> people are not involved.
>
> > Its time for a new standard.
>
> Only if we can get quality people to work on it. So who the fuck are
> you, Mr. Hotmail.com?
> </flame>
>
> david rush
> (who has just watched _the matrix_ for the first time and is feeling
> pretty radicalized just at the moment)
From: Erik Naggum
Subject: Re: Time for a Fresh Scheme Standard: Say Goodbye to the RnRS Relic
Date:
Message-ID: <3218013921984060@naggum.net>
* ·········@hotmail.com (New Scheme)
| Its time to reinvigorate scheme.
No, it is not. It is time to leave Scheme behind. It used to be a
language that brought many new ideas into _one_ language, but all of the
good ideas have been picked up by other, better languages. Common Lisp,
Perl, Python, Ruby, and Java have all benefited from the little group of
impractical purists who designed this minimalistic language experiment.
Look, Tengwar is more widely used than Scheme these days. The features
unique to Scheme today are those that are universally considered bad
ideas. Worse: Perl, Python, Ruby, and Java have more of the Lisp nature
than Scheme does, whether they admit to it or not, and better developed
and more widely used to boot. It is time to close the book on Scheme and
let it wither and die, which it will if you leave the kind of people you
have seen respond to you alone to destroy it from within.
If you still want a functional programming paradigm, there are lots and
lots of more recent academic experiments that should be at least as
useless as Scheme for real work, but which could be a little harder to
teach, since they actually try to do _something_ and are not just trying
to make a language optimized for reimplementation of itself by students.
If you are not welcome in the Scheme community, take a hint: Leave. They
do not even need to be provoked to attack individual people, as you have
seen, so they are clearly bad people. Do not try to change bad people:
It makes the bad people worse and wastes your time (that is the lesson I
learned from trying to deal with Scheme freaks as if they were people).
Try instead to find good people who welcome the ability to think.
Ask yourself what you actually _like_ in Scheme. Chances are you can get
it, better implemented and better understood, in any number of other
languages. The only thing you probably cannot get in other languages is
a full implementation of the language itself done as a student project.
If you want that, just create your own language like everybody else who
has ever actually tried to used Scheme does, anyway.
///
--
The past is not more important than the future, despite what your culture
has taught you. Your future observations, conclusions, and beliefs are
more important to you than those in your past ever will be. The world is
changing so fast the balance between the past and the future has shifted.
From: Kent M Pitman
Subject: Re: Time for a Fresh Scheme Standard: Say Goodbye to the RnRS Relic
Date:
Message-ID: <sfwadwbkrw5.fsf@shell01.TheWorld.com>
[ replying to comp.lang.lisp only
http://world.std.com/~pitman/pfaq/cross-posting.html ]
Erik Naggum <····@naggum.net> writes:
> * ·········@hotmail.com (New Scheme)
> | Its time to reinvigorate scheme.
>
> No, it is not. It is time to leave Scheme behind.
I'd recommend anyone who wants to reinvigorate Scheme consider Dylan.
It started out pretty much with that agenda, and though it's drifted some,
it's probably still in many ways close enough to be worth a look before
doing the work of starting over.
From: Hirotaka Yamamoto
Subject: Re: Time for a Fresh Scheme Standard: Say Goodbye to the RnRS Relic
Date:
Message-ID: <87vgeze7g4.fsf@yc5.so-net.ne.jp>
Erik Naggum <····@naggum.net> writes:
> Look, Tengwar is more widely used than Scheme these days. The features
> unique to Scheme today are those that are universally considered bad
> ideas.
Prove it by examples, please.
Yamamoto
From: Erik Naggum
Subject: Re: Time for a Fresh Scheme Standard: Say Goodbye to the RnRS Relic
Date:
Message-ID: <3218018336124724@naggum.net>
* Erik Naggum
> Look, Tengwar is more widely used than Scheme these days.
* Hirotaka Yamamoto
| Prove it by examples, please.
I am glad you asked. The Lord of the Rings: The Fellowship of the Ring,
has premiered recently all over the world. Tengwar is a writing system
devised by J.R.R.Tolkien in this monumental work. Millions of people all
over the world have taken a renewed interest in his works, including his
new languages and writing systems, because of this movie. I venture a
guess that more people were fluent in Tengwar than in Scheme before this
movie was announced, as well, but I am certain that the number has
exceeded Scheme fluency because of the movie. I certainly reread LotR
and took up my old calligraphic Tengwar skills in joyful anticipation of
the movie, and I did not reread RnRS nor take up my old Scheme skills in
anticipation of, um, anything. Q.E.D.
Note: Despite the fictitious "please", I consider the brevity, style, and
substance of your request to communicate hostility. Requests for proof
or references are never constructive on USENET, just mere tactics in a
rhetorical game. I have responded with ridicule. Please be pleased with
the results. Thank you and goodbye.
///
--
The past is not more important than the future, despite what your culture
has taught you. Your future observations, conclusions, and beliefs are
more important to you than those in your past ever will be. The world is
changing so fast the balance between the past and the future has shifted.
> Note: Despite the fictitious "please", I consider the brevity, style, and
> substance of your request to communicate hostility. Requests for proof
> or references are never constructive on USENET, just mere tactics in a
> rhetorical game. I have responded with ridicule. Please be pleased with
> the results. Thank you and goodbye.
Ouch. That was very damning. You gave him a bloody nose and all that.
Could you stop cross posting, though? We like to concern ourselves with
_relevant_ languages over here. LOL.
C//
From: Hirotaka Yamamoto
Subject: Re: Time for a Fresh Scheme Standard: Say Goodbye to the RnRS Relic
Date:
Message-ID: <87ofkrducp.fsf@yc5.so-net.ne.jp>
I don't realize why you are so mad, but I do have realized that
you intentionally changed my posting and neglect what I guess
is inconvenient to you. I wrote,
------------ cut here ----------
> Look, Tengwar is more widely used than Scheme these days. The features
> unique to Scheme today are those that are universally considered bad
> ideas.
Prove it by examples, please.
------------ cut here ----------
but you wrote,
------------ cut here ----------
> * Erik Naggum
> > Look, Tengwar is more widely used than Scheme these days.
>
> * Hirotaka Yamamoto
> | Prove it by examples, please.
------------ cut here ----------
Why could you claim that "the features unique to Scheme today
are those that are universally considered bad ideas." without
any proof?? Especially, why could you use the word "universally"??
Ah... maybe because you are the only person who lives in
"your universe"?
Yamamoto
On Sat, 22 Dec 2001 12:45:25 GMT, Erik Naggum <····@naggum.net> wrote:
> Look, Tengwar is more widely used than Scheme these days.
And an infamous Common Lisp user gives popularity as a reason to
choose a language ?
Wonders will never cease....
From: Erik Naggum
Subject: Re: Time for a Fresh Scheme Standard: Say Goodbye to the RnRS Relic
Date:
Message-ID: <3218018853244911@naggum.net>
* Erik Naggum
> Look, Tengwar is more widely used than Scheme these days.
* IsraelRT <········@optushome.com.au>
| And an infamous Common Lisp user gives popularity as a reason to
| choose a language?
No. That would be a rather spectacularly invalid conclusion. Since you
obviously have no idea what Tengwar is, suffice to say that a relatively
small group of people have adopted this artificial writing system from
J.R.R.Tolkien in order to enjoy communication within the secluded world
of ardent fans. Some therefore consider it a symptom of a cult. It was
the likeness of ardent fans in small number who keep the rest of the
world out through a measure of intended obscurity that prompted the
comparison, not the mere quantity of weirdos. Please confirm that you
have been enlightened by responding with another hostile grunt.
| Wonders will never cease....
That easily happens when you abandon rationality. Enjoy your wonders.
///
--
The past is not more important than the future, despite what your culture
has taught you. Your future observations, conclusions, and beliefs are
more important to you than those in your past ever will be. The world is
changing so fast the balance between the past and the future has shifted.
On Sat, 22 Dec 2001 14:07:35 GMT, Erik Naggum <····@naggum.net> wrote:
>* IsraelRT <········@optushome.com.au>
>| And an infamous Common Lisp user gives popularity as a reason to
>| choose a language?
>
> No. That would be a rather spectacularly invalid conclusion. Since you
> obviously have no idea what Tengwar is
You are either delusional or sadly lacking in rationality if you
believe that the second statement follows as a consequence of the
first.
Go take your medication.
From: Erik Naggum
Subject: Re: Time for a Fresh Scheme Standard: Say Goodbye to the RnRS Relic
Date:
Message-ID: <3218030326803537@naggum.net>
* IsraelRT <········@optushome.com.au>
| And an infamous Common Lisp user gives popularity as a reason to
| choose a language?
* Erik Naggum
> No. That would be a rather spectacularly invalid conclusion. Since you
> obviously have no idea what Tengwar is
* IsraelRT <········@optushome.com.au>
| You are either delusional or sadly lacking in rationality if you believe
| that the second statement follows as a consequence of the first.
As a _consequence_? No. Logic and rational thought is not quite your
thing, is it? But since your emotive invective is conditional upon your
false premise, I guess I am in the clear. Whew! That was _so_ close.
| Go take your medication.
I assume you have extensive experience with medication helping your own
behavioral problems since you think this silliness is an insult, but it
just goes to show that once again, the aggressiveness of Israel gets
blamed on those attacked. History is indeed repeating itself.
///
--
The past is not more important than the future, despite what your culture
has taught you. Your future observations, conclusions, and beliefs are
more important to you than those in your past ever will be. The world is
changing so fast the balance between the past and the future has shifted.
On Sat, 22 Dec 2001 17:18:50 GMT, Erik Naggum <····@naggum.net> wrote:
.
.
{ much spectacularly irrelevant , incoherent and grammatically
challenged psychotic ravings by Eroc Nogumshoe deleted }
> blamed on those attacked. History is indeed repeating itself.
No, the No Gum is repeating himself.
Erik Naggum <····@naggum.net> wrote:
> No, it is not. It is time to leave Scheme behind. [...]
Oh joy. I thought I saw the last Naggum post when I unsubbed from
comp.lang.lisp. Are you still sore that Scheme is installed on far more
computers than oxymoronically-named "Common" Lisp?
> If you are not welcome in the Scheme community, take a hint: Leave. [...]
The Scheme community is a warm and welcoming place compared to the Common
Lisp one, I think. The the open, academic-yet-practical, friendly spirit of
Lisp lives on in comp.lang.scheme and numerous general lisp mailing lists.
We just don't like anonymous posters saying that we got it all wrong.
··········@cloaked.freeserve.co.uk (MJ Ray) wrote in message
> The Scheme community is a warm and welcoming place compared to the Common
> Lisp one, I think.
Say what?? Let me just repeat Mr Rush's "warm and welcoming" post:
---------------------------------------------
David Rush <····@bellsouth.net> wrote in message news:<···············@bellsouth.net>...
> So who the fuck are you anyway? [...]
> This is such bullshit... [...]
> This is such bullshit, it has to be a troll. You're secretly Erik
> Naggum aren't you? [...]
> I did it in Scheme because I don't have to fuck around with
> a lot of stupid mis-features from 'advanced' languages like
> Perl, Python, Tcl, Ruby, or (God help us) C++ and Java [...]
> the current generation of no-talent simps graduating into
> the CS business.
> > Solicit help from the Common Lisp community [...]
> They're a bunch of losers who have bought and sold the
> lambda-nature for a profit. [...]
> So who the fuck are you, Mr. Hotmail.com?
--------------------------------------------
> The the open, academic-yet-practical, friendly spirit of
> Lisp lives on in comp.lang.scheme and numerous general lisp mailing lists.
> We just don't like anonymous posters saying that we got it all wrong.
hahaha the "friendly spirit" lives on does it?? hahaha
> Say what?? Let me just repeat Mr Rush's "warm and welcoming" post:
Please delete comp.lang.python from this thread. (and maybe
c.l.perl).
Terry J. Reedy
New Scheme <·········@hotmail.com> wrote:
>Say what?? Let me just repeat Mr Rush's "warm and welcoming" post:
[...]
>hahaha the "friendly spirit" lives on does it?? hahaha
How many places do you know that are warm and welcoming to anonymous idiots?
Followups set.
From: Erik Naggum
Subject: Re: Time for a Fresh Scheme Standard: Say Goodbye to the RnRS Relic
Date:
Message-ID: <3218081134224960@naggum.net>
* ··········@cloaked.freeserve.co.uk (MJ Ray)
| Oh joy. I thought I saw the last Naggum post when I unsubbed from
| comp.lang.lisp.
It was one of your own (David Rush) who called on me, blaming me for his
serious coping problems when that New Scheme fellow posted some heretical
comments that could threaten to undo the universe as he knew it. I am
sure that the Scheme religion needs a Devil figure and that you guys are
so irrational as to blame the Devil when you need to explain some of the
otherwise _inexplicable_ evil that happens to you (like reality invading
your nice little theories), but if I wanted to undo the Scheme community,
nobody would know it had even existed, OK? Such are my evil powers. I
_let_ you insufferable little freaks continue to have your community,
because you do less harm believing in and being preoccupied with Scheme
than if you were roaming free. Or perhaps this Devil imagery that you
guys seem to need is a bit stale and idiotic?
| Are you still sore that Scheme is installed on far more computers than
| oxymoronically-named "Common" Lisp?
No, never was. On the contrary, I am quite happy that all those who
install Common Lisp systems actually use them productively.
Have you thought about how _necessary_ it is for you Scheme freaks to be
hostile to those who do not agree with you? E.g., where _did_ the stupid
need to attack Common Lisp now come from? So immature and vindictive!
On the other hand, if you suffer form Perl envy, I am sure that it is
natural to think that other language communities must suffer from similar
problems, but so far, we have had a large number of Scheme freaks invade
Common Lisp fora to tell us how superior Scheme is, while no Common Lisp
programmers invade Scheme camps to tell you how good Common Lisp is. Why
is this? Well, we know that Common Lisp is better than Scheme, and so do
you, so there is no need to repeat the obvious, but any clueless Scheme
freak who feels the urge to rebel against authority and common sense must
try to provoke those better than him. That is why you had to include
that stupid attack on Common Lisp, too. So immature. So Scheme.
Incidentally, are you still raping preschool children? Scheme is the
favorite language of pedophiles, who love the pure and small, you know.
| The Scheme community is a warm and welcoming place compared to the Common
| Lisp one, I think.
Of course you think so. But let us ask this New Scheme fellow, or any of
the other people that Scheme freaks routinely attack on no basis at all.
Why did your David Rush need to attack me this time, for instance? Why
did you have to attack Common Lisp? I have not done anything to you
insane fucks, but you nutballs need no provocation to attack me. Why?
Do you think normal, sane people behave the way you do?
Anyone can see that a community of people who condone and support attacks
on others behind their back is neither warm nor welcome, no matter how
much you wish to be and lie that you are. Most religions have been warm
and welcome to those likely to be duped by their gospel, and extremely
hostile to those who would be a threat to them. Which one of them would
say that some _other_ religion is more warm and welcoming than they are?
So this vacuous phrase is sheer marketing. When you need to engage in
such marketing, you must know that you have a shitty product that nobody
would buy if they knew the truth about it. What a scheme!
| The the open, academic-yet-practical, friendly spirit of Lisp lives on in
| comp.lang.scheme and numerous general lisp mailing lists.
Of course you believe this. You have chased away every free-thinking
person who has ever discarded Scheme and you display _such_ hatred of
non-believers that you are like the biological end result of in-breeding.
The people who come to you in the first place are already converts and
are unlikely to question the gospel. Those who do not like Scheme do not
exactly have to deal with you -- which is also why you Scheme freaks have
to come to Common Lisp groups and fora and make a stupid scene.
| We just don't like anonymous posters saying that we got it all wrong.
Are you sure that is what he said? Are you sure that those who do not
believe in the Scheme religion would react the same way? Have you found
a rational person you could ask how would react to that article? I would
bet that not a single rational person would say that you got it all wrong
-- on the contrary, a reasonable reading is you got it right _eons_ ago,
but now you need do something more to keep doing the right thing. Of
course, a card-carrying Scheme nutcase would feel all defensive only if
he _knew_ that his favorite religion was all wrong, and therefore needs
to stop people from figuring it out. That is how organized religions
have reacted to "heretics" for ages.
It is quite amazing how fanatic and stupid you Scheme freaks are. Of
course you think you are friendly -- you only have people around you who
are in complete agreement on something _really_ stupid, and _anybody_ is
all friendly when they are never challenged by disagreement of any kind,
but challenge you guys and one gets to see what you are really made of:
Just watch David Rush in action, or your opening line. Just look at how
you treat people who disagree with your beliefs!
But trust me on this: Unless that psychotic David Rush character had been
so amazingly stupid as to blame me for this, _and_ that New Scheme fellow
had cross-posted it back to the newsgroups that coward little shit David
Rush did _not_ post to, none of this would have happened. Perhaps you
friendly Scheme freaks need to purge your own evils and excommunicate the
worst among your own? I would have started by frying David Rushs' balls.
It is increasingly obvious that Scheme is a mental disease, particularly
since you mental cases always make a point out of attacking non-believers
out of the blue. They do not even have to be posting to your newsgroup!
///
--
The past is not more important than the future, despite what your culture
has taught you. Your future observations, conclusions, and beliefs are
more important to you than those in your past ever will be. The world is
changing so fast the balance between the past and the future has shifted.
Erik Naggum <····@naggum.net> wrote:
> Have you thought about how _necessary_ it is for you Scheme freaks to be
> hostile to those who do not agree with you? E.g., where _did_ the stupid
> need to attack Common Lisp now come from? So immature and vindictive!
Sorry Erik. I attacked you, not Common Lisp. Or are you Common Lisp
itself?
> [...] so far, we have had a large number of Scheme freaks invade
> Common Lisp fora to tell us how superior Scheme is, while no Common Lisp
> programmers invade Scheme camps to tell you how good Common Lisp is.
I can only think of one Common Lisp forum, CLiki, and it contains little
about Scheme. Maybe you wish to make general Lisp fora "pure" and filled
only with your One True Lisp?
I've snipped the rest of your content-free post. Followups set.
From: Erik Naggum
Subject: Re: Time for a Fresh Scheme Standard: Say Goodbye to the RnRS Relic
Date:
Message-ID: <3218094071610401@naggum.net>
* Erik Naggum
> Have you thought about how _necessary_ it is for you Scheme freaks to be
> hostile to those who do not agree with you? E.g., where _did_ the stupid
> need to attack Common Lisp now come from? So immature and vindictive!
* MJ Ray
| Sorry Erik. I attacked you, not Common Lisp. Or are you Common Lisp
| itself?
Could you explain what "oxymoronically-named "Common" Lisp?" is if not an
attack? Do you think your immature and vindictive "opinions" do _not_
constitute an attack? If so, I understand better what you mean by "warm
and welcoming".
And just _why_ do you attack me? You are just warm and welcoming, right?
| Maybe you wish to make general Lisp fora "pure" and filled only with your
| One True Lisp?
No, that would be the Scheme way of dealing with diversity of opinion, as
we have seen from you guys already. This is one of the really important
differences between Common Lisp and Scheme. It is not suprising that you
do not know this, considering your "warm and welcoming" behavior.
By the way, you are probably right. The Scheme community is certainly
more "warm and welcoming" than the Common Lisp community."
| I've snipped the rest of your content-free post.
So you lack the courage to deal with all forms of counter-information.
///
--
The past is not more important than the future, despite what your culture
has taught you. Your future observations, conclusions, and beliefs are
more important to you than those in your past ever will be. The world is
changing so fast the balance between the past and the future has shifted.
From: Hirotaka Yamamoto
Subject: Re: Time for a Fresh Scheme Standard: Say Goodbye to the RnRS Relic
Date:
Message-ID: <87r8pmccee.fsf@yc5.so-net.ne.jp>
Erik Naggum <····@naggum.net> writes:
> So you lack the courage to deal with all forms of counter-information.
So you do too against my post.
From: Erik Naggum
Subject: Re: Time for a Fresh Scheme Standard: Say Goodbye to the RnRS Relic
Date:
Message-ID: <3218108581153077@naggum.net>
* Hirotaka Yamamoto <····@yc5.so-net.ne.jp>
| So you do too against my post.
"How can you say this without proof?" Do you know the future? Can I
have your crystal ball so I can see if you grow a brain in the future?
I thought you were full of shit when I got that moronic response from
you, but thank you for _proving_ it with this response. You are a credit
to the Scheme community, however, since you have the guts to post your
shit in full public view. Most of the spineless wimps who think Scheme
is not completely worthless seem to prefer to talk behind people's back.
///
--
The past is not more important than the future, despite what your culture
has taught you. Your future observations, conclusions, and beliefs are
more important to you than those in your past ever will be. The world is
changing so fast the balance between the past and the future has shifted.
On Sun, 23 Dec 2001 15:03:03 GMT, Erik Naggum <····@naggum.net> wrote:
>* Hirotaka Yamamoto <····@yc5.so-net.ne.jp>
>| So you do too against my post.
>
> "How can you say this without proof?" Do you know the future? Can I
> have your crystal ball so I can see if you grow a brain in the future?
At least we can be secure in the knowledge that you will not grow a
personality in any forseeable future.
On 23 Dec 2001 22:08:09 +0900, Hirotaka Yamamoto
<····@yc5.so-net.ne.jp> wrote:
>Erik Naggum <····@naggum.net> writes:
>
>> So you lack the courage to deal with all forms of counter-information.
>
>So you do too against my post.
Actually, Erik is dealing with it the only way that he know..
ie : with abuse and ad hominem attacks.
for example:
http://groups.google.com/groups?q=g:thl4036054936d&hl=en&selm=3185652157185910%40naggum.net
http://groups.google.com/groups?hl=en&threadm=raffael-1412001051410001%40raffaele.ne.mediaone.net&rnum=7&prev=/groups%3Fq%3Derik%2Bnaggum%2Babuse%26hl%3Den%26rnum%3D7%26selm%3Draffael-1412001051410001%2540raffaele.ne.mediaone.net
http://groups.google.com/groups?q=erik+naggum+abuse&hl=en&rnum=10&selm=3165478157379052%40naggum.no
Re: Disruptive Troll Warning: Erik Naggum - stolt av å være det
jævligste trollet på no*
http://groups.google.com/groups?q=erik+naggum+abuse&hl=en&rnum=2&selm=uEdt5.1017%24N4.315793%40juliett.dax.net
After all, he is an underemployed failed-PhD candidate who advocates a
failed language.
Erik Naggum <····@naggum.net> wrote:
> Could you explain what "oxymoronically-named "Common" Lisp?" is if not an
> attack? [...]
It's just a statement -- If Common Lisp were common, would we be having this
discussion?
> And just _why_ do you attack me? You are just warm and welcoming, right?
I didn't challenge you (cf OPN).
>| Maybe you wish to make general Lisp fora "pure" and filled only with your
>| One True Lisp?
> No, that would be the Scheme way of dealing with diversity of opinion, as
> we have seen from you guys already. [...]
Oh, I wonder what you're smoking. Just because we flame one gutless troll
doesn't mean that all diversity is lambasted. After all, without diversity,
is there progress?
>| I've snipped the rest of your content-free post.
> So you lack the courage to deal with all forms of counter-information.
Sorry, I lack the enthusiasm to devote time to attempts at decrypting the
side-effects of your latest medication dose increase. Ad hom. attacks and
repetition don't make the basis for an interesting response.
FUs set.
[ Ignoring the Follow-Up, because this is way more relevant on c.l.l ]
··········@cloaked.freeserve.co.uk (MJ Ray) writes:
> Erik Naggum <····@naggum.net> wrote:
> > Could you explain what "oxymoronically-named "Common" Lisp?" is if not an
> > attack? [...]
>
> It's just a statement -- If Common Lisp were common, would we be having this
> discussion?
Yes, because the discussion was about Scheme. Common Lisp destroyed
all the Lispy lisps. Schemey languages are a world unto themselves:
could you imagine trying to unify Scheme and CL? No one would use the
product. In the multidimensional space languages live in, they're
quite far apart. All of the lisps that were anywhere near CL are now,
for all intents and purposes, gone. Little one-implenetation Lisps
that are used as extension languages in specific products still exist,
but there are no active vendors, free or commercial, of non-CL Lisps.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
On 1 Jan 2002, Thomas F. Burdick wrote:
> Yes, because the discussion was about Scheme. Common Lisp destroyed
> all the Lispy lisps.
"Destroyed" seems so...raw! "Encompassed", "embraced", "superceded",
"succeeded" [sic], "unified", "replaced"...?
[snip]
> quite far apart. All of the lisps that were anywhere near CL are now,
> for all intents and purposes, gone. Little one-implenetation Lisps
> that are used as extension languages in specific products still exist,
> but there are no active vendors, free or commercial, of non-CL Lisps.
Hmm. How about the XLisp family? It doesn't have a standard, I don't
think, but there's something slighly more than a single
implementation. (I'm not sure you can get away with saying that ANSI CL
destroyed all the other *multiply implemented* *standardized* Lisps. :))
Interestingly, ELisp stands (perpetually) at the cusp of having multiple
implementations. (Kawa/JEmacs and the proposed Guile one). That it's an
extension language in a specific product doesn't remove it as a contender
for a wide variety of applications. It's hard to see it as *not* a Lisp,
and a fairly popular one. It's just not a very good one, especially next
to Common Lisp. Such a not good one, in fact, that it would be destroyed
by CL if it weren't driving a key application with a huge code base.
Cheers,
Bijan Parsia.
From: Kent M Pitman
Subject: Re: Time for a Fresh Scheme Standard: Say Goodbye to the RnRS Relic
Date:
Message-ID: <sfwitakx1n1.fsf@shell01.TheWorld.com>
Bijan Parsia <·······@email.unc.edu> writes:
> On 1 Jan 2002, Thomas F. Burdick wrote:
>
> > Yes, because the discussion was about Scheme. Common Lisp destroyed
> > all the Lispy lisps.
>
> "Destroyed" seems so...raw! "Encompassed", "embraced", "superceded",
> "succeeded" [sic], "unified", "replaced"...?
Indeed, it only outright destroyed some of them. Like Interlisp, the
seemingly specifically targeted enemy, since ARPA at the time was eyeing
it as a possible platform choice and it was up to CL to show that the
rest of the community had a common base. So, as I remember it anyway,
one was destroyed, most were embraced, A few were borrowed from and
otherwise selectively ignored, ... Heh.
There were some important things lost with Interlisp, I think. I feel
bad about that. Much more so today than I did at the time. It had a
much stronger end-user focus. The Maclisp family had a strong
implementor focus. A lot of the issues we wrestle with today relate
to lack of interface focus. I didn't ever really know Interlisp well,
but forgetting language semantics and looking only at patterns of
political advocacy, it's too bad we shunned a large group of people
that cared about interfaces and usage patterns as much as they did...
Every time you disenfranchise a group, e.g., as Dylan did with its
very callous change in syntax, intentionally ignoring the needs of
Lispers, you lose not only the group but the culture and concerns that
go with it. Likewise, in the design of early CL (pre-ANSI), I seem to
recall that we in the US somewhat disenfranchised Europe, not out of
meanness, but because those stupid uucp foo!bar!baz addresses took 3
days to make a round trip to Europe and it was slowing us down to
focus heavily on caring about what that community said, because we
needed fast same-day turnaround on too many issues. But the cost of
not including Europe was that the European cultural focus, I think due
to more limited financial resources at the time, leading to less
powerful available computers, was on "small and layered". And this
priority was, for a time, omitted from CL (and some would say it still
is today, though I think that's probably unfair). Eulisp was born as
a nearly retaliatory effort, or so it has always seemed to me. And it
not only competed with CL (stealing market share) but failed to have
its concerns heard in the CL design (by being a constituency we did
not seek to cater to). A pity.
These views of mine are obviously subjective and others might view
these situations radically differently. But I'd rather I (and others)
say something someone sometimes disagrees with than have all of us
with subjective opinions one day die and never have recorded them for
fear that someone would challenge their authenticity/correctness. I
think a lot is lost in the world academic community by excess
attention to making the writing of history rely so much on formal
footnoting... it feels to me always like I'm not supposed to just post
my thoughts because I can't offer a proper cite. Sometimes I just
rebel and do it anyway...
- - - -
Btw, speaking of Eulisp, and on the subject of taking potshots about
names, I had always thought "Eu" meant "European" (no wonder it didn't
go over well in the US), but they told me "Eu" was Greek for "Good".
Do the people having a problem with "Common Lisp" as a name for its
so-called questionable use of the word "Common" have a similar problem
with the use of the word "Eu" in Eulisp? Just a rhetorical question
really. No response required on that...
Kent M Pitman <······@world.std.com> writes:
> Bijan Parsia <·······@email.unc.edu> writes:
[ Oops, I lost this article before responding to it ... I'm glad Kent
responded ]
> > On 1 Jan 2002, Thomas F. Burdick wrote:
> >
> > > Yes, because the discussion was about Scheme. Common Lisp destroyed
> > > all the Lispy lisps.
> >
> > "Destroyed" seems so...raw! "Encompassed", "embraced", "superceded",
> > "succeeded" [sic], "unified", "replaced"...?
>
> Indeed, it only outright destroyed some of them. Like Interlisp, the
> seemingly specifically targeted enemy, since ARPA at the time was eyeing
> it as a possible platform choice and it was up to CL to show that the
> rest of the community had a common base. So, as I remember it anyway,
> one was destroyed, most were embraced, A few were borrowed from and
> otherwise selectively ignored, ... Heh.
It was actually Interlisp that I was alluding to with "destroyed". I
actually edited that sentence down from:
Common Lisp succeeded in "crushing, smashing to atoms, wiping off
the face of the earth" all the other Lispy lisps.
figuring that most people would not recongnize nor appreciate the
Lenin quote. I'd read about Interlisp recently, and I've been quite
impressed, and have played around with it under the Linux emulator a
bit.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
From: Erik Naggum
Subject: Re: Time for a Fresh Scheme Standard: Say Goodbye to the RnRS Relic
Date:
Message-ID: <3218921279807627@naggum.net>
* Erik Naggum
> Could you explain what "oxymoronically-named "Common" Lisp?" is if not an
> attack? [...]
* MJ Ray
| It's just a statement -- If Common Lisp were common, would we be having this
| discussion?
Your annoying beliggerence is just stupid, now. Cut it out.
> And just _why_ do you attack me? You are just warm and welcoming, right?
| I didn't challenge you (cf OPN).
Who do you think you are kidding? Some fellow Scheme retards?
| Oh, I wonder what you're smoking.
Your annoying beliggernce is growing more and more stupid. Cut it out.
| Just because we flame one gutless troll doesn't mean that all diversity
| is lambasted. After all, without diversity, is there progress?
Well, this _would_ explain the lack of progress in the Scheme family.
| Sorry, I lack the enthusiasm to devote time to attempts at decrypting the
| side-effects of your latest medication dose increase.
Your obviously superior experience with medication doses aside, please do
not project your personality problems onto others. Just because you have
never learned to cope with those who disagree with you and need medical
attention whenever you meet someone who does, does not mean that anybody
else suffers from your kind of mental illness, despite the preponderance
of victims in the Scheme community that makes it appear normal to you
guys, including the sense of appropriateness of your more than usually
stupid personal attack. What is _wrong_ with you Scheme freaks?
| Ad hom. attacks and repetition don't make the basis for an interesting
| response.
No, they certainly do not. Please return to your cave, now. Thank you.
Scheme is _clearly_ the language only of deficient minds.
///
--
On Wed, 02 Jan 2002 00:48:02 GMT, Erik Naggum <····@naggum.net> wrote:
>* Erik Naggum
>> Could you explain what "oxymoronically-named "Common" Lisp?" is if not an
>> attack? [...]
>* MJ Ray
>| It's just a statement -- If Common Lisp were common, would we be having this
>| discussion?
> Your annoying beliggerence is just stupid, now. Cut it out.
Coming from you Erik, that is mind bogglingly funny.
"beliggerence" !
··········@cloaked.freeserve.co.uk (MJ Ray) wrote in message news:<·························@cloaked.freeserve.co.uk>...
> Just because we flame one gutless troll
> doesn't mean that all diversity is lambasted.
Actually, most suggestions for improvements to scheme are lambasted by
the ignorant, defensive bullies of the scheme newsgroup. And
actually, most of the attacks are directed towards the people with the
intelligence, creativity, and courage to suggest improvemnts.
> After all, without diversity, is there progress?
There isn't any in regards to the RnRS document, that's for sure. Its
time for a new standard without the input of you sad, whining critics.
I've gots some news for you: arrogance does not equate to
intelligence.
New Scheme <·········@hotmail.com> wrote:
> I've gots some news for you: arrogance does not equate to intelligence.
You are demonstrating this adequately. Recent reasonable suggestions for
scheme improvements have been welcomed, eg in the "Scheme vs Perl" thread.
Perhaps if you could justify what you are trying to describe, it would help.
FUs set, once again.
From: Kent M Pitman
Subject: Re: Time for a Fresh Scheme Standard: Say Goodbye to the RnRS Relic
Date:
Message-ID: <sfwlmfgx2k4.fsf@shell01.TheWorld.com>
[ Ignoring requested followup to comp.lang.scheme, since I don't post
there and otherwise would not reply to this at all.
Plus all my usual mumblings about cross-posting still apply, as far
as I'm concerned: http://world.std.com/~pitman/pfaq/cross-posting.html ]
··········@cloaked.freeserve.co.uk (MJ Ray) writes:
> Erik Naggum <····@naggum.net> wrote:
> > Could you explain what "oxymoronically-named "Common" Lisp?" is if not an
> > attack? [...]
>
> It's just a statement -- If Common Lisp were common, would we be having this
> discussion?
There are a number of meanings to common. One of them is "commonplace", that
is "frequently occurring". CL is certainly that, just as "English Common Law"
is, even though it is not shared "literally in common" even with all places
that seek to employ it. I mean, gee, even the "common functionality" that
is supplied by a superclass in nearly every computer class system I've ever
seen allows some overriding, causing the word "commmon" again to be
inapplicable. I think quibbling over this is nutty. The name Common Lisp
is just a name. Historically, Common Lisp sought to unify a number of
disparate dialectal communities, and it did so well. End of story, IMO.
It's not worth fussing over the long-ago-dialect Portable Standard Lisp
(PSL)'s name either; it made sense in its time.
On Sun, 23 Dec 2001 09:33:59 GMT, ··········@cloaked.freeserve.co.uk
(MJ Ray) wrote:
>Erik Naggum <····@naggum.net> wrote:
>> Have you thought about how _necessary_ it is for you Scheme freaks to be
>> hostile to those who do not agree with you? E.g., where _did_ the stupid
>> need to attack Common Lisp now come from? So immature and vindictive!
>
>Sorry Erik. I attacked you, not Common Lisp. Or are you Common Lisp
>itself?
Only on weeksdays.
On weekends, Erik is God.
At least that is what he tells the men in the white coats...
From: Erik Naggum
Subject: Re: Time for a Fresh Scheme Standard: Say Goodbye to the RnRS Relic
Date:
Message-ID: <3218109204240366@naggum.net>
* israel r t <········@antispam.optushome.com.au>
| Only on weeksdays.
| On weekends, Erik is God.
|
| At least that is what he tells the men in the white coats...
You seem to have a disconcerting amount of experience in this particular
area of the human condition. You have been absent form our newsgroups
for quite a while, too. Have you recovered? Are you out on probation?
Anyhow, I am sorry that I have triggered your problems, again. Please do
not kill anyone this time. Instead, enjoy the peaceful holiday season,
and get some _better_ help to get over your personal problems, will you?
///
--
The past is not more important than the future, despite what your culture
has taught you. Your future observations, conclusions, and beliefs are
more important to you than those in your past ever will be. The world is
changing so fast the balance between the past and the future has shifted.
On Sun, 23 Dec 2001 15:13:26 GMT, Erik Naggum <····@naggum.net> wrote:
> You seem to have a disconcerting amount of experience in this particular
> area of the human condition.
Erik you seem to have become a pain in the rectum even in the
Norwegian groups....
http://groups.google.com/groups?q=erik+naggum+abuse&hl=en&rnum=2&selm=uEdt5.1017%24N4.315793%40juliett.dax.net
From: Erik Naggum
Subject: Re: Time for a Fresh Scheme Standard: Say Goodbye to the RnRS Relic
Date:
Message-ID: <3218166196287916@naggum.net>
* israel r t <········@antispam.optushome.com.au>
| Erik you seem to have become a pain in the rectum even in the Norwegian
| groups....
Your amzingly strong interest in me looks more and more unhealthy. How
much time do you spend every day searching the Net for stuff about me?
Do you have anyone who cares about you on this particular day that you
could talk to about your need to post messages to the whole world that
says _nothing_ but that you are _obsessing_ about me? Seek help, OK?
///
--
The past is not more important than the future, despite what your culture
has taught you. Your future observations, conclusions, and beliefs are
more important to you than those in your past ever will be. The world is
changing so fast the balance between the past and the future has shifted.
From: Brian P Templeton
Subject: Re: Time for a Fresh Scheme Standard: Say Goodbye to the RnRS Relic
Date:
Message-ID: <87n0zve479.fsf@tunes.org>
··········@cloaked.freeserve.co.uk (MJ Ray) writes:
> Erik Naggum <····@naggum.net> wrote:
>> Have you thought about how _necessary_ it is for you Scheme freaks to be
>> hostile to those who do not agree with you? E.g., where _did_ the stupid
>> need to attack Common Lisp now come from? So immature and vindictive!
>
> Sorry Erik. I attacked you, not Common Lisp. Or are you Common Lisp
> itself?
>
>> [...] so far, we have had a large number of Scheme freaks invade
>> Common Lisp fora to tell us how superior Scheme is, while no Common Lisp
>> programmers invade Scheme camps to tell you how good Common Lisp is.
>
> I can only think of one Common Lisp forum,
Then you're obviously not thinking very hard, since you just posted to
one. :)
> CLiki, and it contains little
> about Scheme. Maybe you wish to make general Lisp fora "pure" and filled
> only with your One True Lisp?
>
Why do you think that CLiki -- a Wiki devoted to Common Lisp, and for
the most part consisting of resources for Common Lisp developers on
Unix -- would include Scheme information? CLiki is *specifically*
about Common Lisp, not Lisp in general.
> I've snipped the rest of your content-free post. Followups set.
Followups ignored, since this is also relevant to Common Lisp.
--
BPT <···@tunes.org> /"\ ASCII Ribbon Campaign
backronym for Linux: \ / No HTML or RTF in mail
Linux Is Not Unix X No MS-Word in mail
Meme plague ;) ---------> / \ Respect Open Standards
Brian P Templeton <···@tunes.org> wrote:
>··········@cloaked.freeserve.co.uk (MJ Ray) writes:
>> I can only think of one Common Lisp forum,
>Then you're obviously not thinking very hard, since you just posted to
>one. :)
Sorry, I've looked at the available material about comp.lang.lisp and it
appears to be a forum for Lisp, not just Common Lisp. Am I mistaken? Can
you justify that?
>Why do you think that CLiki [...] would include Scheme information?
I don't, as it's the only CL forum I found, which is what I said. Please
try to parse in the spirit of the message. ;-)
>> I've snipped the rest of your content-free post. Followups set.
>Followups ignored, since this is also relevant to Common Lisp.
Followups reset, as this has nothing to do with perl, python, or religion.
Please be polite, even if you ignore my recommendation.
From: Brian P Templeton
Subject: Re: Time for a Fresh Scheme Standard: Say Goodbye to the RnRS Relic
Date:
Message-ID: <87heq01rbp.fsf@tunes.org>
··········@cloaked.freeserve.co.uk (MJ Ray) writes:
> Brian P Templeton <···@tunes.org> wrote:
>>··········@cloaked.freeserve.co.uk (MJ Ray) writes:
>>> I can only think of one Common Lisp forum,
>>Then you're obviously not thinking very hard, since you just posted to
>>one. :)
>
> Sorry, I've looked at the available material about comp.lang.lisp and it
> appears to be a forum for Lisp, not just Common Lisp. Am I mistaken? Can
> you justify that?
>
It is a forum for any Lisp, which makes it a possible forum for Common
Lisp, and for Scheme as well.
>>Why do you think that CLiki [...] would include Scheme information?
>
> I don't, as it's the only CL forum I found, which is what I said. Please
> try to parse in the spirit of the message. ;-)
>
>>> I've snipped the rest of your content-free post. Followups set.
>>Followups ignored, since this is also relevant to Common Lisp.
>
> Followups reset, as this has nothing to do with perl, python, or religion.
> Please be polite, even if you ignore my recommendation.
Sorry. I forgot about the original newsgroups header.
--
BPT <···@tunes.org> /"\ ASCII Ribbon Campaign
backronym for Linux: \ / No HTML or RTF in mail
Linux Is Not Unix X No MS-Word in mail
Meme plague ;) ---------> / \ Respect Open Standards
Brian P Templeton <···@tunes.org> writes:
> ··········@cloaked.freeserve.co.uk (MJ Ray) writes:
> > Brian P Templeton <···@tunes.org> wrote:
> >>··········@cloaked.freeserve.co.uk (MJ Ray) writes:
> >>> I can only think of one Common Lisp forum,
> >>Then you're obviously not thinking very hard, since you just
> >>posted to one. :)
> > Sorry, I've looked at the available material about comp.lang.lisp
> > and it appears to be a forum for Lisp, not just Common Lisp. Am I
> > mistaken? Can you justify that?
> It is a forum for any Lisp, which makes it a possible forum for
> Common Lisp, and for Scheme as well.
Seeing as how there exists a newsgroup specifically for Scheme,
discussions about Scheme should generally head to comp.lang.scheme.
Similarly, there are newsgroup specifically for Dylan and for Gnu
Emacs Lisp.
Those interested in discussing those variations are likely to be found
there.
That being said, if you've got a question about (say) Rep, ILisp, or
the likes, there's no place better than comp.lang.lisp. (There's a
severe paucity of questions about such Lisp variations, to be sure.)
It probably would have been a wise move to set up
comp.lang.lisp.common or comp.lang.cl, but I seriously doubt that a
CFV is in the near future...
--
(concatenate 'string "cbbrowne" ·@sympatico.ca")
http://www.ntlug.org/~cbbrowne/sap.html
ITS is a hand-crafted RSUBR.
In article <·······················@news20.bellglobal.com>,
········@acm.org wrote:
> > It is a forum for any Lisp, which makes it a possible forum for
> > Common Lisp, and for Scheme as well.
>
> Seeing as how there exists a newsgroup specifically for Scheme,
> discussions about Scheme should generally head to comp.lang.scheme.
> Similarly, there are newsgroup specifically for Dylan and for Gnu
> Emacs Lisp.
>
> Those interested in discussing those variations are likely to be found
> there.
>
> That being said, if you've got a question about (say) Rep, ILisp, or
> the likes, there's no place better than comp.lang.lisp. (There's a
> severe paucity of questions about such Lisp variations, to be sure.)
>
> It probably would have been a wise move to set up
> comp.lang.lisp.common or comp.lang.cl, but I seriously doubt that a
> CFV is in the near future...
There is already comp.lang.clos.
-- Bruce
From: Brian P Templeton
Subject: Re: Time for a Fresh Scheme Standard: Say Goodbye to the RnRS Relic
Date:
Message-ID: <87ell1czea.fsf@tunes.org>
········@acm.org writes:
> Brian P Templeton <···@tunes.org> writes:
>> ··········@cloaked.freeserve.co.uk (MJ Ray) writes:
>> > Brian P Templeton <···@tunes.org> wrote:
>> >>··········@cloaked.freeserve.co.uk (MJ Ray) writes:
>> >>> I can only think of one Common Lisp forum,
>> >>Then you're obviously not thinking very hard, since you just
>> >>posted to one. :)
>
>> > Sorry, I've looked at the available material about comp.lang.lisp
>> > and it appears to be a forum for Lisp, not just Common Lisp. Am I
>> > mistaken? Can you justify that?
>
>> It is a forum for any Lisp, which makes it a possible forum for
>> Common Lisp, and for Scheme as well.
>
> Seeing as how there exists a newsgroup specifically for Scheme,
> discussions about Scheme should generally head to comp.lang.scheme.
> Similarly, there are newsgroup specifically for Dylan and for Gnu
> Emacs Lisp.
>
Yes, there are other fora dedicated to specific Lisps; nevertheless,
discussion of other Lisps is by no means off-topic here, IMHO
(although people will probably get a quicker response for, e.g.,
Scheme questions if they post to c.l.s).
> Those interested in discussing those variations are likely to be found
> there.
>
> That being said, if you've got a question about (say) Rep, ILisp, or
> the likes, there's no place better than comp.lang.lisp. (There's a
> severe paucity of questions about such Lisp variations, to be sure.)
>
> It probably would have been a wise move to set up
> comp.lang.lisp.common or comp.lang.cl, but I seriously doubt that a
> CFV is in the near future...
> --
> (concatenate 'string "cbbrowne" ·@sympatico.ca")
> http://www.ntlug.org/~cbbrowne/sap.html
> ITS is a hand-crafted RSUBR.
--
BPT <···@tunes.org> /"\ ASCII Ribbon Campaign
backronym for Linux: \ / No HTML or RTF in mail
Linux Is Not Unix X No MS-Word in mail
Meme plague ;) ---------> / \ Respect Open Standards
Brian P Templeton <···@tunes.org> wrote:
>It is a forum for any Lisp, which makes it a possible forum for Common
>Lisp, and for Scheme as well.
Exactly. It is a Lisp forum, as I was originally trying to point out, not a
Common Lisp forum. I think we're actually agreeing, really...
··········@cloaked.freeserve.co.uk (MJ Ray) writes:
> Brian P Templeton <···@tunes.org> wrote:
> >It is a forum for any Lisp, which makes it a possible forum for Common
> >Lisp, and for Scheme as well.
> Exactly. It is a Lisp forum, as I was originally trying to point
> out, not a Common Lisp forum. I think we're actually agreeing,
> really...
comp.lang.lisp may be decently relevant to Scheme when there is a
discussion that involves matters that also relate to other Lisp
dialects.
If, however, a particular discussion is expected to solely be about
Scheme, it is far more sensible to direct it to comp.lang.scheme,
which exists for that exact purpose.
--
(reverse (concatenate 'string ·············@" "enworbbc"))
http://www.ntlug.org/~cbbrowne/unix.html
Rules of the Evil Overlord #64. "I will see a competent psychiatrist
and get cured of all extremely unusual phobias and bizarre compulsive
habits which could prove to be a disadvantage."
<http://www.eviloverlord.com/>
From: Andrew Hamm
Subject: Re: Time for a Fresh Scheme Standard: Say Goodbye to the RnRS Relic
Date:
Message-ID: <3c351b9e$1_2@news.iprimus.com.au>
Brian P Templeton wrote...
>··········@cloaked.freeserve.co.uk wrote:
>> Erik Naggum <····@naggum.net> wrote:
>>>[PROBABLY OTHER PEOPLE HAVE ALSO written:]
>
[FLAMEY STUFF ABOUT COMMON LISP AND SCHEME]
Guys, what makes you think that the rest of the newsgroups care to follow
this flame war? Us other language users don't give a damn. In fact, this
whole thing looks like a troll for a flame war. If you really must keep
flaming each other (and I'm not taking sides since I haven't been following
the thread, and I'm not trying to say that flaming isn't fun) then could you
please trim the list of newsgroups down to just the lispy ones?
Or better still, please arrange to meet behind the Gym building after school
and you can have a fist fight to decide which version of Lisp is better. If
you are too woosy to have a fist fight, have a pokemon battle on your
gameboys.
--
Space Corps Directive #997
Work done by an officer's doppleganger in a parallel
universe cannot be claimed as overtime.
-- Red Dwarf
Erik Naggum <····@naggum.net> writes:
> Have you thought about how _necessary_ it is for you Scheme freaks to be
> hostile to those who do not agree with you? E.g., where _did_ the stupid
> need to attack Common Lisp now come from? So immature and vindictive!
Many of the readers on the various cross-posted groups may think, "how
hypocritical of Erik Naggum to talk about hostility and vindictiveness!"
Not so, gentle readers. This cannot be the real Erik Naggum; it is an
imposter.
I've read real Erik Naggum postings in the past. Perhaps I didn't
follow those threads all the way through, but the postings I did read
were clever, witty, and genuinely amusing to read. The repetitive venom
in this recent thread pales by comparison.
To the imposter, let me say this: You have a long way to go to catch up
with Erik Naggum. Your postings include echoes of what he's posted in
the past, but that's actually what gave you away. The real Erik Naggum
would have come up with some new angle for deprecating the Scheme
community. You wouldn't catch him continuing to beat the "religious
cult" dead horse, though it was quite funny when he first introduced it.
And the references to mental institutions would be more clever.
Whenever he gets back from holiday, I'm sure he'll put you in your
place!
To the other groups, let me say that Common Lisp and Scheme are not
mutually hostile communities. There are certain high-profile
exceptions, but these (the real ones, at least) can be genuinely fun to
read.
As an act of self-sacrifice for the greater good, I'm setting followups
for this flame war to comp.lang.scheme. If the pathetic imposter
chooses to ignore followups, he'd better have a posting that's original
and witty.
--
<·······@[(if (brl-related? message) ; Bruce R. Lewis
"users.sourceforge.net" ; http://brl.sourceforge.net/
"alum.mit.edu")]>
On 24 Dec 2001 10:23:13 -0500, Bruce Lewis <·······@yahoo.com> wrote:
>Erik Naggum <····@naggum.net> writes:
>
>> Have you thought about how _necessary_ it is for you Scheme freaks to be
>> hostile to those who do not agree with you? E.g., where _did_ the stupid
>> need to attack Common Lisp now come from? So immature and vindictive!
>
>Many of the readers on the various cross-posted groups may think, "how
>hypocritical of Erik Naggum to talk about hostility and vindictiveness!"
>Not so, gentle readers. This cannot be the real Erik Naggum; it is an
>imposter.
>To the imposter, let me say this: You have a long way to go to catch up
>with Erik Naggum.
>Whenever he gets back from holiday, I'm sure he'll put you in your
>place!
At last !
Eric Naggum is impersonating Erik Naggum !
On 22 Dec 2001 01:02:35 -0800, ·········@hotmail.com (New Scheme)
wrote:
>Anyone calling for injection of fresh ideas into the language is
>attacked with a level of spite and religious vehemence rarely seen
>outside of fundamentalist religious sects.
Anyone ?
Or an anonymous troll who is too scared to use his real name ?
> See you in hell.
I am sure that a nice warm spot is being kept for you, Mr Troll.
IsraelRT <········@optushome.com.au> wrote in message news:<··································@4ax.com>...
> On 22 Dec 2001 01:02:35 -0800, ·········@hotmail.com (New Scheme)
> wrote:
>
> >Anyone calling for injection of fresh ideas into the language is
> >attacked with a level of spite and religious vehemence rarely seen
> >outside of fundamentalist religious sects.
>
> Anyone ?
> Or an anonymous troll who is too scared to use his real name ?
You obviously didn't read David Rush's rant. Are you suffering from a
bit of selective amnesia?
On 22 Dec 2001 06:07:37 -0800, ·········@hotmail.com (New Scheme)
wrote:
>> Or an anonymous troll who is too scared to use his real name ?
>
>You obviously didn't read David Rush's rant. Are you suffering from a
>bit of selective amnesia?
Still posting anonymously ?
Coward.
In comp.lang.scheme IsraelRT <········@optushome.com.au> wrote:
> On 22 Dec 2001 06:07:37 -0800, ·········@hotmail.com (New Scheme)
> wrote:
>>> Or an anonymous troll who is too scared to use his real name ?
>>
>>You obviously didn't read David Rush's rant. Are you suffering from a
>>bit of selective amnesia?
> Still posting anonymously ?
Oh, please! This is a totally irrelevant small detail.
> Coward.
It would have been nice of you to actualy refute his claims, and not just
namecall.
--
Sander
+++ Out of cheese error +++
Sander Vesik wrote:
>It would have been nice of you to actualy refute his claims, and not just
>namecall.
Except that the troll's claims are self-fulfilling. By posting an
essentially content-free rant under a pseudonym, he generated some annoyed
responses. He then used that as "evidence" in his argument:
>Anyone calling for injection of fresh ideas into the language is
>attacked with a level of spite and religious vehemence rarely seen
>outside of fundamentalist religious sects.
The problem with this is, had this person posted a reasoned message about
the issues in question, it's quite unlikely that the same kind of response
would have been generated.
Besides, if the troll is claiming that he's afraid to post under his real
name because of the response it would generate, is it because he's afraid of
a few flames? Or is he simply unwilling to tarnish his reputation, which
would certainly suffer if he posted messages like that first one, which was
an amateurish call-to-arms based on a faulty premise.
I support the idea of some movement in the standards area myself, but that
isn't the troll's motivation, you can be sure - or if it is, he has a very
strange way of going about it.
Anton
In comp.lang.scheme Anton van Straaten <·····@appsolutions.com> wrote:
> Sander Vesik wrote:
>>It would have been nice of you to actualy refute his claims, and not just
>>namecall.
> Except that the troll's claims are self-fulfilling. By posting an
> essentially content-free rant under a pseudonym, he generated some annoyed
> responses. He then used that as "evidence" in his argument:
Well... tthe original mail wasn't *THAT* bad - besides, trolls are
trolls, you don't have to feed them...
>>Anyone calling for injection of fresh ideas into the language is
>>attacked with a level of spite and religious vehemence rarely seen
>>outside of fundamentalist religious sects.
> The problem with this is, had this person posted a reasoned message about
> the issues in question, it's quite unlikely that the same kind of response
> would have been generated.
> Besides, if the troll is claiming that he's afraid to post under his real
> name because of the response it would generate, is it because he's afraid of
> a few flames? Or is he simply unwilling to tarnish his reputation, which
> would certainly suffer if he posted messages like that first one, which was
> an amateurish call-to-arms based on a faulty premise.
> I support the idea of some movement in the standards area myself, but that
> isn't the troll's motivation, you can be sure - or if it is, he has a very
> strange way of going about it.
> Anton
--
Sander
+++ Out of cheese error +++
From: David Rush
Subject: Re: Time for a Fresh Scheme Standard: Say Goodbye to the RnRS Relic
Date:
Message-ID: <okfwuzcscy1.fsf@bellsouth.net>
Sander Vesik <······@haldjas.folklore.ee> writes:
> In comp.lang.scheme Anton van Straaten <·····@appsolutions.com> wrote:
> > Sander Vesik wrote:
> >>It would have been nice of you to actualy refute his claims, and not just
> >>namecall.
>
> > Except that the troll's claims are self-fulfilling. By posting an
> > essentially content-free rant under a pseudonym, he generated some annoyed
> > responses. He then used that as "evidence" in his argument:
>
> Well... tthe original mail wasn't *THAT* bad - besides, trolls are
> trolls, you don't have to feed them...
Guilty. Gomen kudasaimasu. It's just that we've actually been having
some amount of serious discussion on the same topic recently, and I
felt that Mr. Hotmail.com was not actually helping the issue at
all. I'd hoped to get him out of the closet (anger sometimes works) or
to get him to shut up.
david rush
--
Java and C++ make you think that the new ideas are like the old ones.
Java is the most distressing thing to hit computing since MS-DOS.
-- Alan Kay
New Scheme <·········@hotmail.com> wrote:
>> So who the fuck are you, Mr. Hotmail.com?
>Your extreme pathologic response clearly demonstrates the problem with
>the small, fundamentalist group of scheme "defenders of the faith"
>that are being left further and further behind as the world moves
>forward.
Nice failure to answer the question, Mr Hotmail. In case you haven't
noticed while you've been constructing yet another alias, work to update
Scheme in many aspects continues apace.
As my experience should show, the Scheme community is very welcoming to
newcomers and it is possible to use Scheme for modern applications. If you
don't want to help it, that's your problem. It is small, clean and, yes,
relevant to today's work.
You are just a common troll and I'm sorry I replied, but some things
couldn't be left unsaid. Goodbye.
Follow-ups set.
From: Erik Naggum
Subject: Re: Time for a Fresh Scheme Standard: Say Goodbye to the RnRS Relic
Date:
Message-ID: <3217992508588876@naggum.net>
* New Scheme
| With each year that passes, scheme becomes more irrelevant to the
| practical and academic software development, education and research
| worlds.
Yes! This is good news.
| Solicit help from the Common Lisp community and draw upon their extensive
| practical experience.
Please keep Scheme impractical to retain its spriit.
///
--
The past is not more important than the future, despite what your culture
has taught you. Your future observations, conclusions, and beliefs are
more important to you than those in your past ever will be. The world is
changing so fast the balance between the past and the future has shifted.
From: israel r t
Subject: Time for a Fresh Lisp Standard: Say Goodbye to the ANSI Common Lisp standard (X3.226-1994)
Date:
Message-ID: <l91d2ucqplfm9auo2gi20pd74ktnl2utlp@4ax.com>
Lisp needs to reinvent itself.
The last standard was released in 1994, ie nearly a decade ago.
As Paul Graham said:
"It's about time for a new dialect of Lisp. The two leading dialects,
Common Lisp and Scheme, have not been substantially changed since the
1980s.
What a language is has changed since then. In 1985, a programming
language was just a spec. Now, thanks to Perl, it means not just (and
maybe not even) a spec, but also a good free implementation, huge
libraries, and constant updates."
Lisp is no longer taught * at leading universities.
Lisp jobs are increasingly scarce.
Lisp is viewed in the real world as akin to COBOL only less likely to
provide a paying job.
Lisp has a severe image problem . ***
Eventually, it will go the way of Jovial and the Titan command
language.
Paul Graham is moving in the right direction with his lisp dialect
Arc. From his talk at the Lightweight Languages Workshop
MIT Artificial Intelligence Lab :
" In The Periodic Table, Primo Levi tells a story that happened when
he was working in a varnish factory. He was a chemist, and he was
fascinated by the fact that the varnish recipe included a raw onion.
What could it be for? No one knew; it was just part of the recipe. So
he investigated, and eventually discovered that they had started
throwing the onion in years ago to test the temperature of the
varnish: if it was hot enough, the onion would fry.
We're going to try not to include any onions in Arc. Everything is
open to question. "
http://www.paulgraham.com/arcll1.html
Footnotes:
* except in increasingly marginalised AI courses .
** The mega-LOCs of COBOL in the finance sector will ensure jobs for
COBOL drudges well into the next millenium.
*** and I am not referring to Naggum either...
From: Frank A. Adrian
Subject: Re: Time for a Fresh Lisp Standard: Say Goodbye to the ANSI Common Lisp standard (X3.226-1994)
Date:
Message-ID: <CiyV7.1406$E93.201433@news.uswest.net>
israel r t wrote:
> Lisp needs to reinvent itself.
> The last standard was released in 1994, ie nearly a decade ago.
>
> As Paul Graham said:
> "It's about time for a new dialect of Lisp. The two leading dialects,
> Common Lisp and Scheme, have not been substantially changed since the
> 1980s.
Fine. Do you have (a) suggestions or (b) funding for people to participate
in such an effort?
> What a language is has changed since then. In 1985, a programming
> language was just a spec. Now, thanks to Perl, it means not just (and
> maybe not even) a spec, but also a good free implementation, huge
> libraries, and constant updates."
I guess. Inventors of Dylan, Curl, and AutoLisp, at the very least, would
tend to disagree with you.
> Lisp is no longer taught * at leading universities.
> Lisp jobs are increasingly scarce.
Sad. 90% of anything is crap, to quote Ted Sturgeon. I would assume this
applies to incomplete university educations and most jobs, as well.
> Lisp is viewed in the real world as akin to COBOL only less likely to
> provide a paying job.
Probably true, but see my last comment. When exposed to crap long enough,
even good people start having trouble telling the difference.
> Lisp has a severe image problem . ***
> Eventually, it will go the way of Jovial and the Titan command
> language.
Yup, just like Fortran. It's been around for 50 years. I guess it'll be
good for another 50. By then, if it hasn't been updated, I'll start to
worry.
> Paul Graham is moving in the right direction with his lisp dialect
> Arc.
It's nice to have an opinion. You're entitled to yours, no matter how
misguided.
[Obligatory anecdote about needless process step/ingredient snipped.]
There are many people that believe Common Lisp needs a bit of updating. Do
you have (a) suggestions or (b) funding? If not, are you just trying to
raise hackles, showing that people here are less friendly than on
c.l.scheme? If you have come here with that objective, you should have
also noticed that your comments were answered without rancor (albeit
briefly) and that most participants in this forum would answer you with
that tone (not, if you had come with the aforementioned goal in mind, you
should have been deserving of this much courtesy). Of course, cluelessness
in followups and arguments might be handled with much less forgiveness.
faa
From: Erik Naggum
Subject: Re: Time for a Fresh Lisp Standard: Say Goodbye to the ANSI Common Lisp standard (X3.226-1994)
Date:
Message-ID: <3218167440343017@naggum.net>
* israel r t <········@antispam.optushome.com.au>
| Lisp needs to reinvent itself.
| The last standard was released in 1994, ie nearly a decade ago.
How old are you?
///
--
The past is not more important than the future, despite what your culture
has taught you. Your future observations, conclusions, and beliefs are
more important to you than those in your past ever will be. The world is
changing so fast the balance between the past and the future has shifted.
From: Brian P Templeton
Subject: Re: Time for a Fresh Lisp Standard: Say Goodbye to the ANSI Common Lisp standard (X3.226-1994)
Date:
Message-ID: <87u1u4jbwf.fsf@tunes.org>
Erik Naggum <····@naggum.net> writes:
> * israel r t <········@antispam.optushome.com.au>
> | Lisp needs to reinvent itself.
> | The last standard was released in 1994, ie nearly a decade ago.
>
> How old are you?
>
He's probably sixteen - but if you listen to what he says, he's
``almost'' twenty!
:)
> ///
> --
> The past is not more important than the future, despite what your culture
> has taught you. Your future observations, conclusions, and beliefs are
> more important to you than those in your past ever will be. The world is
> changing so fast the balance between the past and the future has shifted.
--
BPT <···@tunes.org> /"\ ASCII Ribbon Campaign
backronym for Linux: \ / No HTML or RTF in mail
Linux Is Not Unix X No MS-Word in mail
Meme plague ;) ---------> / \ Respect Open Standards
Lisp needs to reinvent itself.
The last standard was released in 1994, ie nearly a decade ago.
As Paul Graham said:
"It's about time for a new dialect of Lisp. The two leading dialects,
Common Lisp and Scheme, have not been substantially changed since the
1980s.
What a language is has changed since then. In 1985, a programming
language was just a spec. Now, thanks to Perl, it means not just (and
maybe not even) a spec, but also a good free implementation, huge
libraries, and constant updates."
Lisp is no longer taught * at leading universities.
Lisp jobs are increasingly scarce.
Lisp is viewed in the real world as akin to COBOL **only less likely
to
provide a paying job.
Lisp has a severe image problem . ***
Eventually, it will go the way of Jovial and the Titan command
language.
Paul Graham is moving in the right direction with his lisp dialect
Arc. From his talk at the Lightweight Languages Workshop
MIT Artificial Intelligence Lab :
" In The Periodic Table, Primo Levi tells a story that happened when
he was working in a varnish factory. He was a chemist, and he was
fascinated by the fact that the varnish recipe included a raw onion.
What could it be for? No one knew; it was just part of the recipe. So
he investigated, and eventually discovered that they had started
throwing the onion in years ago to test the temperature of the
varnish: if it was hot enough, the onion would fry.
We're going to try not to include any onions in Arc. Everything is
open to question. "
http://www.paulgraham.com/arcll1.html
Footnotes:
* except in increasingly marginalised AI courses .
** The mega-LOCs of COBOL in the finance sector will ensure jobs for
COBOL drudges well into the next millenium.
*** and I am not referring to Naggum either...
israel r t <········@antispam.optushome.com.au> writes:
> Lisp needs to reinvent itself.
I suggest to take a look at Dylan. It's a pretty recent Lisp-like
language, and it's got a few things right (but on the other hand
omitted some features some people consider essential). I've also got
a list of things to do better on the next iteration.
You can learn a lot from Dylan when designing a new Lisp.
Andreas
--
"In my eyes it is never a crime to steal knowledge. It is a good
theft. The pirate of knowledge is a good pirate."
(Michel Serres)
Andreas Bogk wrote:
> I suggest to take a look at Dylan. It's a pretty recent Lisp-like
> language, and it's got a few things right (but on the other hand
> omitted some features some people consider essential).
I consider Lisp syntax (or something similarly elegant) to be
essential. I suspect that many proponents of Dylan-like languages would
consider it unacceptable. I strongly suspect there is no middle ground.
(Yes, I'm aware of Lisp-syntax Dylan, but I think there's a reason it
got abandoned.)
Jeffrey Siegal <···@quiotix.com> writes:
> I consider Lisp syntax (or something similarly elegant) to be
> essential. I suspect that many proponents of Dylan-like languages would
> consider it unacceptable. I strongly suspect there is no middle ground.
For the language user, there may be no middle ground. From the
perspective of the language designer, the syntax is just one issue of
many, so even if you prefer S-expressions, there's still a lot of Lisp
to discover in Dylan.
> (Yes, I'm aware of Lisp-syntax Dylan, but I think there's a reason it
> got abandoned.)
The reason was that a lot of people, especially those who should be
persuaded to use Dylan, consider infix syntax to be more readable.
I'm well aware that this is paid with increased complexity in macros,
and I'm still not firm enough in macrology to know whether this is a
substantial complaint or not. Still, Dylan provides valuable input
for designing the next Lisp/Scheme/whatever.
Andreas
--
"In my eyes it is never a crime to steal knowledge. It is a good
theft. The pirate of knowledge is a good pirate."
(Michel Serres)
Andreas Bogk wrote:
> > I consider Lisp syntax (or something similarly elegant) to be
> > essential. I suspect that many proponents of Dylan-like languages would
> > consider it unacceptable. I strongly suspect there is no middle ground.
>
> For the language user, there may be no middle ground. From the
> perspective of the language designer, the syntax is just one issue of
> many, so even if you prefer S-expressions, there's still a lot of Lisp
> to discover in Dylan.
Did you mean "A lot _for_ Lisp to discover?" There is little in Dylan
that didn't originate with Lisp, except the syntax. What does Dylan
have that Scheme + CLOS + "a collections library" doesn't have?
Jeffrey Siegal <···@quiotix.com> writes:
> > many, so even if you prefer S-expressions, there's still a lot of Lisp
> > to discover in Dylan.
> Did you mean "A lot _for_ Lisp to discover?" There is little in Dylan
> that didn't originate with Lisp, except the syntax.
No, I agree that most of Dylan originated in one Lisp dialect or
another. But I think that Dylan is a well-balanced blend of these
features, it feels good. That's why I suggest to at least take a look
at it when designing the next Lisp[0].
> What does Dylan have that Scheme + CLOS + "a collections library"
> doesn't have?
That would be conditions, type annotations and a useful module/library
system. Oh, and dynamism vs. performance tradeoffs like sealing,
primary classes and limited types.
Andreas
[0] Or "Lisp" or successor of Scheme which is "not a Lisp" or
whatever.
--
"In my eyes it is never a crime to steal knowledge. It is a good
theft. The pirate of knowledge is a good pirate."
(Michel Serres)
Andreas Bogk wrote:
> > What does Dylan have that Scheme + CLOS + "a collections library"
> > doesn't have?
>
> That would be conditions, type annotations and a useful module/library
> system.
I agree about modules, although I don't really like the way Dylan uses
multiple files to define a simple module. There should be a way of
doing that in-line. A CLOS-style object system does have type
annotations, at least at the method level (which is probably enough),
because they're necessary for dispatch. As for conditions, I prefer
passing condition handlers as explicit arguments. With proper tail
calls and limited use of call/cc to escape out of CPS, it works fine.
> Oh, and dynamism vs. performance tradeoffs like sealing,
> primary classes and limited types.
I think these are overhyped features which have been adaquately
addressed in Lisp/Scheme using either different implementations as
needed, declarations, etc.
Jeffrey Siegal <···@quiotix.com> writes:
> I agree about modules, although I don't really like the way Dylan uses
> multiple files to define a simple module. There should be a way of
The idea behind Dylan was that the source code resides in a code
database, and the file format is just used for interchange. Of
course, in reality there are source files, and the interchange format
is a little awkward to use. That should be easier, I agree.
> doing that in-line. A CLOS-style object system does have type
> annotations, at least at the method level (which is probably enough),
> because they're necessary for dispatch.
Having type annotations for bindings gives the optimizer a lot of meat
to work on.
> As for conditions, I prefer
> passing condition handlers as explicit arguments. With proper tail
> calls and limited use of call/cc to escape out of CPS, it works fine.
I don't think so. Having to pass around handlers for all sorts of
conditions is a nuisance. This is something CL and Dylan got right,
IMHO.
> > Oh, and dynamism vs. performance tradeoffs like sealing,
> > primary classes and limited types.
> I think these are overhyped features which have been adaquately
> addressed in Lisp/Scheme using either different implementations as
> needed, declarations, etc.
The point is that you can start writing code without caring about
performance. Once the design has settled, you can sprinkle some
adjectives here and there, and the code becomes fast, without having
to re-implement performance-critical code. I consider sealing to be a
good thing.
Andreas
--
"In my eyes it is never a crime to steal knowledge. It is a good
theft. The pirate of knowledge is a good pirate."
(Michel Serres)
Andreas Bogk wrote:
>>doing that in-line. A CLOS-style object system does have type
>>annotations, at least at the method level (which is probably enough),
>>because they're necessary for dispatch.
>>
>
> Having type annotations for bindings gives the optimizer a lot of meat
> to work on.
I'm not so sure about that, given good type inference, and methods that
are kept reasonably small. In any case, it is a trivially small matter
to add type bindings to let statements one they exist for methods.
>>As for conditions, I prefer
>>passing condition handlers as explicit arguments. With proper tail
>>calls and limited use of call/cc to escape out of CPS, it works fine.
>
> I don't think so. Having to pass around handlers for all sorts of
> conditions is a nuisance. This is something CL and Dylan got right,
> IMHO.
Chocolate and vanilla. I would add that explicitly passing condition
handlers around is a bit like explicit typing, becuase it prevents you
from leaving conditions unhandled.
>>>Oh, and dynamism vs. performance tradeoffs like sealing,
>>>primary classes and limited types.
>>>
>>I think these are overhyped features which have been adaquately
>>addressed in Lisp/Scheme using either different implementations as
>>needed, declarations, etc.
>
> The point is that you can start writing code without caring about
> performance. Once the design has settled, you can sprinkle some
> adjectives here and there, and the code becomes fast, without having
> to re-implement performance-critical code. I consider sealing to be a
> good thing.
I do this in Scheme today, and I don't even sprinkle adjectives here and
there, by developing in a developer-friendly environment and then
switching to a highly-optimized block compiler for tuning and production.
Andreas Bogk <·······@andreas.org> writes:
> Jeffrey Siegal <···@quiotix.com> writes:
> > As for conditions, I prefer
> > passing condition handlers as explicit arguments. With proper tail
> > calls and limited use of call/cc to escape out of CPS, it works fine.
>
> I don't think so. Having to pass around handlers for all sorts of
> conditions is a nuisance. This is something CL and Dylan got right,
> IMHO.
Wel I've not written any large reactive systems using CPS for
condition-handling, but it certainly seems to work well in my
data-mining code. As things stand today, I'd probably not choose
Scheme for a large GUI application, although I'm cooking up ideas to
try out in PLT Scheme just to see if there GUI support is as good as
it looks. Maybe sometime in this millenium I'll get around to it.
> > > Oh, and dynamism vs. performance tradeoffs like sealing,
Huh? What is this feature?
> > I think these are overhyped features which have been adaquately
> > addressed in Lisp/Scheme using either different implementations as
> > needed, declarations, etc.
>
> The point is that you can start writing code without caring about
> performance.
Surely you *don't* really mean this. Big-O issues will jump up and get
you if you don't think about them.
> Once the design has settled, you can sprinkle some
> adjectives here and there, and the code becomes fast, without having
> to re-implement performance-critical code. I consider sealing to be a
> good thing.
Do you not also get the same benefits if you develop using good
functional abstractions?
david rush
--
The beginning of wisdom for a [software engineer] is to recognize the
difference between getting a program to work, and getting it right.
-- M A Jackson, 1975
David Rush <····@bellsouth.net> writes:
> > I don't think so. Having to pass around handlers for all sorts of
> > conditions is a nuisance. This is something CL and Dylan got right,
> > IMHO.
> Wel I've not written any large reactive systems using CPS for
> condition-handling, but it certainly seems to work well in my
> data-mining code. As things stand today, I'd probably not choose
> Scheme for a large GUI application, although I'm cooking up ideas to
As soon as you pile up some layers of code, it quickly becomes tedious
to pass around handlers everywhere. Just imagine passing a GUI dialog
for resolving a "disk full" condition all the way through the GUI,
your application code, your storage abstraction down to the actual
disk access.
Imagine that you have some OS-agnostic code in the middle layers, and
that you don't even know that some condition might arise and that it
can be fixed. Proper exceptions allow code at distant places to
communicate efficiently.
> > > > Oh, and dynamism vs. performance tradeoffs like sealing,
> Huh? What is this feature?
It allows you to specify that you won't add a new method to a certain
generic function, or some application domain of that function. For
instance, the Dylan <integer> type is a regular class which cannot be
subclassed. The + function is a generic function sealed over the
domain (<integer>, <integer>), so nobody can override that definiton.
So you get all the performance benefits you'd get when implementing
integers specially, like Java does, but still <integer>s are regular
objects, and you can get the same kind of performance benefits for
your own classes.
> > The point is that you can start writing code without caring about
> > performance.
> Surely you *don't* really mean this. Big-O issues will jump up and get
> you if you don't think about them.
Actually, I usually nail down *what* I want to do with a naive
implementation, which isn't really intended to solve the problem, but
just serves me as some kind of formal specification of the problem,
which happens to be executable too. Starting from that, I can
experiment with *how* to solve certain aspects, at which time big-O
complexity comes into play. Only after having found the right
algorithms and a correct implementation for them I start to think
about low-level performance issues. And I want my language to support
this kind of process.
> > Once the design has settled, you can sprinkle some
> > adjectives here and there, and the code becomes fast, without having
> > to re-implement performance-critical code. I consider sealing to be a
> > good thing.
> Do you not also get the same benefits if you develop using good
> functional abstractions?
Of course you can. I just happen to prefer generic functions, and I
want them to be as fast as the functional approach, which can be sone
with sealing.
Andreas
--
"In my eyes it is never a crime to steal knowledge. It is a good
theft. The pirate of knowledge is a good pirate."
(Michel Serres)
Andreas Bogk wrote:
> As soon as you pile up some layers of code, it quickly becomes tedious
> to pass around handlers everywhere. Just imagine passing a GUI dialog
> for resolving a "disk full" condition all the way through the GUI,
> your application code, your storage abstraction down to the actual
> disk access.
What happens in Java is that you have to at least declare the exceptions
up the chain anyway (the compiler will reject a method that doesn't
catch or throw E which involves a method declared to throw E. It isn't
that much harder to explicitly pass the handler.
> So you get all the performance benefits you'd get when implementing
> integers specially, like Java does, but still <integer>s are regular
> objects, and you can get the same kind of performance benefits for
> your own classes.
Yes and no. They're not "regular objects" because they can't be
subclassed. I think what you'd see in any kind of production
environment if Dylan were used is that almost everything would get
sealed off, much the way a lot of Java code makes extensive use of
"final." At that point, you might as well just use a static block
compiler and let the compiler recognize what is subclassed and what
isn't.
Jeffrey Siegal <···@quiotix.com> writes:
> What happens in Java is that you have to at least declare the exceptions
> up the chain anyway (the compiler will reject a method that doesn't
Yes, and that bothers me to no end. I want to have specific code that
knows about an exception in exactly two places: where it is generated,
and where it can be handled. All the code inbetween doesn't need to
know more than that an operation has failed and that it needs to clean
up.
> Yes and no. They're not "regular objects" because they can't be
> subclassed.
That's true. The point of sealing is to offer the option of turning
off certain OO features while retaining the benefits of others (the
user can still specialize his own generic functions on integers, for
instance).
> I think what you'd see in any kind of production
> environment if Dylan were used is that almost everything would get
> sealed off, much the way a lot of Java code makes extensive use of
> "final." At that point, you might as well just use a static block
> compiler and let the compiler recognize what is subclassed and what
> isn't.
I'd hate to use a static block compiler, the turnaround time would be
a nightmare. And I'd like to keep the option of adding classes and gf
methods at runtime.
Adreas
--
"In my eyes it is never a crime to steal knowledge. It is a good
theft. The pirate of knowledge is a good pirate."
(Michel Serres)
Andreas Bogk wrote:
>>What happens in Java is that you have to at least declare the exceptions
>>up the chain anyway (the compiler will reject a method that doesn't
>
> Yes, and that bothers me to no end. I want to have specific code that
> knows about an exception in exactly two places: where it is generated,
> and where it can be handled. All the code inbetween doesn't need to
> know more than that an operation has failed and that it needs to clean
> up.
[This is also a reply to Bruce's earlier comments.]
You will find views on both sides, not unlike the issue of static
typing. It is not always the case that code that isn't written to be
thrown through is safe; it may not clean up. Making sure that each
method has the appropriate declarations is a way to catch these things
at compile time. (Some methodological discipline is required to get any
benefit out of this, of course, but when isn't it?)
>>I think what you'd see in any kind of production
>>environment if Dylan were used is that almost everything would get
>>sealed off, much the way a lot of Java code makes extensive use of
>>"final." At that point, you might as well just use a static block
>>compiler and let the compiler recognize what is subclassed and what
>>isn't.
>
> I'd hate to use a static block compiler, the turnaround time would be
> a nightmare.
You don't generally use a static block compiler when code is in active
development. For example, I develop in DrScheme and then block compile
with Stalin for performance tuning and production use.
> And I'd like to keep the option of adding classes and gf
> methods at runtime.
Then you can't use sealing (much).
Andreas Bogk <·······@andreas.org> writes:
> Jeffrey Siegal <···@quiotix.com> writes:
>
> > What happens in Java is that you have to at least declare the exceptions
> > up the chain anyway (the compiler will reject a method that doesn't
>
> Yes, and that bothers me to no end. I want to have specific code that
> knows about an exception in exactly two places: where it is generated,
> and where it can be handled. All the code inbetween doesn't need to
> know more than that an operation has failed and that it needs to clean
> up.
Well you actually do have the choice in Java. Just have your exceptions extend
from RuntimeException or Error, and they are no longer required to be declared
in the throws clauses.
Then you have the knowledge of the exception to be exactly in the desired
places.
To "hide" the fact that you are possibly abusing the notion of "error", have a
base application exception class extend from RuntimeException or Error, and
have all you other exceptions extend from that.
Personally, though, I prefer having the explicit throws clauses, for then the
compiler forces me to be aware of the error issues. At the very least I know to
put in the necessary "finally" blocks and rethrow if handling the error is not
appropriate.
I have not found the maintenance issue to be too bad. One trick is to rethrow
in terms of a more general exception class, so that the methods in between the
low level error and the final handler just have one or two exception classes in
their throws clauses, as opposed to a miriad of particular ones (which cause
the maintenance problem).
The mistake that a lot of Java programmers make is to simply swallow the
unexpected exceptions with a stack trace and continue. This is the worst of all
possibilities, defeating the purpose of exceptions in the first place.
--
Cheers, The Rhythm is around me,
The Rhythm has control.
Ray Blaak The Rhythm is inside me,
·····@telus.net The Rhythm has my soul.
Andreas Bogk <·······@andreas.org> writes:
> Jeffrey Siegal <···@quiotix.com> writes:
>
> > What happens in Java is that you have to at least declare the exceptions
> > up the chain anyway (the compiler will reject a method that doesn't
>
> Yes, and that bothers me to no end. I want to have specific code that
> knows about an exception in exactly two places: where it is generated,
> and where it can be handled. All the code inbetween doesn't need to
> know more than that an operation has failed and that it needs to clean
> up.
Well the `two endpoints' part of your desire is fairly easily met, but
the `cleaning up from the middle' is rather harder. I would speculate
that the only way to make that really work correctly is to have
language (& GC) support for finalizers, and even that is error prone.
In my experience, error-handling has to be designed in early. My
experience with exception-based systems (primarily Smalltalk w/some
C++) has not led me to believe that they are dramatically
cleaner.
Please note: I am talking about a matter of degree here. My biggest
beef with exception-based systems is that they end up getting used far
too generally (for unusual code paths rather than actual failure
handling). They're nice when used for communicating distant problems
(the canonical I/O system failure is ideal), but they're not as clear
as an if statement by any means. In the past I've dealt with this
through architectural constraints, but that experience was not wholly
satisfying.
david rush
--
Christianity has not been tried and found wanting; it has been found
difficult and not tried.
-- G.K. Chesterton
David Rush <····@bellsouth.net> wrote:
+---------------
| Please note: I am talking about a matter of degree here. My biggest
| beef with exception-based systems is that they end up getting used far
| too generally (for unusual code paths rather than actual failure
| handling).
+---------------
At least as I read it, Kent Pitman's 1990 survey paper on exceptions
<URL:http://world.std.com/~pitman/Papers/Exceptional-Situations-1990.html>
suggests that there's nothing wrong with using exceptions for "unusual
code paths":
It is important to recognize that this distinction between normal
and exceptional situations is in some sense contrived. Making this
distinction does not change the way programs behave; it simply
changes the way we reason about programs--hopefully for the better.
...
In some cases, there may be efficiency reasons for considering
some cases to be exceptional.
In particular, allowing some [presumably infrequent] non-error code
paths to be considered "exceptional" [and using inconspicuous flow
control primitives to access them, such as CATCH/THROW] can, in turn,
allow the "normal" code paths to be considerably simplified without
compromising program correctness.
-Rob
-----
Rob Warnock, 30-3-510 <····@sgi.com>
SGI Network Engineering <http://www.meer.net/~rpw3/>
1600 Amphitheatre Pkwy. Phone: 650-933-1673
Mountain View, CA 94043 PP-ASEL-IA
[Note: ·········@sgi.com and ········@sgi.com aren't for humans ]
[ replying to comp.lang.lisp only
http://world.std.com/~pitman/pfaq/cross-posting.html ]
····@rigden.engr.sgi.com (Rob Warnock) writes:
> David Rush <····@bellsouth.net> wrote:
> +---------------
> | Please note: I am talking about a matter of degree here. My biggest
> | beef with exception-based systems is that they end up getting used far
> | too generally (for unusual code paths rather than actual failure
> | handling).
> +---------------
>
> At least as I read it, Kent Pitman's 1990 survey paper on exceptions
> <URL:http://world.std.com/~pitman/Papers/Exceptional-Situations-1990.html>
> suggests that there's nothing wrong with using exceptions for "unusual
> code paths":
>
> It is important to recognize that this distinction between normal
> and exceptional situations is in some sense contrived. Making this
> distinction does not change the way programs behave; it simply
> changes the way we reason about programs--hopefully for the better.
> ...
> In some cases, there may be efficiency reasons for considering
> some cases to be exceptional.
>
> In particular, allowing some [presumably infrequent] non-error code
> paths to be considered "exceptional" [and using inconspicuous flow
> control primitives to access them, such as CATCH/THROW] can, in turn,
> allow the "normal" code paths to be considerably simplified without
> compromising program correctness.
But, further, I have frequently said (and it may be in the paper) that
error systems are protocols for programs not written as part of the
same project. They are not substitute for coordinating control
structure WITHIN a abstraction (however subjectively drawn).
I remember when conditions (and even programmable streams, in the form
of Maclisp SFA's :-) first came out, I played with putting ALL of my
programming into stream handlers and exception handlers trying to figure
out whether or why there was a good place to put certain parts of the
code. This is what I learned:
If you can look at a program and lexically know what will get
signaled and handled, and the purpose is not to also be
plug-compatible if called in other circumstances, then error handling
is probably overkill.
The mechanisms of stream handlers and error handlers are "packaging" not
"base functionality". (For one's own code, that's as silly as gift-wrapping
the leftovers from your evening's dinner for you yourself to open in the
morning when you want more of that pizza for breakfast...)
The PURPOSE of a protocol is to allow the writing of "half programs",
not "whole programs". Things that EITHER signal OR handle, but not
both. Error handling is matchmaking protocol, and code that is
already acquainted does not require it. (Of course, some code is
promiscuous and will both work with code it knows and code it doesn't,
and so may still need the flexibility of error handling for those
cases in which it must rely on matchmaking.)
Ultimately, the reason the convoluted control structure of condition
signaling and handling is not overkill when the system is used
correctly is that you have do do SOMETHING in order for matchmaking to
occur. There are many other places in programming where other kinds
of matchmaking services are used (CLOS method dispatch, CORBA, etc.)
Some such facilities trade off "more familiarity / stronger social
constraints" for faster execution, at the expense of less flexibility.
But that's always the trade. CLOS does not do "effective method resolution"
on every call the way condition handling does with finding a handler.
But then, CLOS is not as flexible as the error system; instead, it is faster
than the error system. You never get anything for free. (For a Lisp
programmer, flexibility and efficiency are the yin and yang of programming.
[A C programmer might statically simplify this statement a little to just
say, "Efficiency is all there is to programming." Heh.])
I make these observations about condition systems a lot but I often
wonder if people "get it" about the whole protocol thing, the speed
trade-off thing, the flexibility thing, etc. These things are not
just random handwaving but highly "concrete" design trade offs that
anyone giving serious thought to this kind of design should come to
grips with. The condition system paper I wrote is now quite old, yet
while people point to it now and then as a reference, I see the ideas
and concepts repeated back in few contexts other than simply quoting
me, and I often feel like the ideas are still new, perhaps because I'm
just explaining myself really, really badly.... I don't know. :( Well,
at least I take solace in the fact that people say they like the
condition system, even if they can't always articulate why. But
really, I think they should be able to articulate with a fairly high
degree of precision exactly what they are getting from it (and what
they are not). Hmmm. Then again, if I'm failing to articulate it
well, maybe it's not suprising that others are not...
I have another paper on conditions, by the way. It was published in a
book last year and I said I'd hold off on webbing it for the first
year, but I think that interval is at an end, so I'll probably web it
soon. If I get side-tracked and fail to do that, someone should
remember to pester me in a month or two about doing so... Meanwhile,
I'll check on what the anniversary date of that "promise" was...
····@rigden.engr.sgi.com (Rob Warnock) writes:
> David Rush <····@bellsouth.net> wrote:
> +---------------
> | Please note: I am talking about a matter of degree here. My biggest
> | beef with exception-based systems is that they end up getting used far
> | too generally (for unusual code paths rather than actual failure
> | handling).
> +---------------
>
> At least as I read it, Kent Pitman's 1990 survey paper on exceptions
> <URL:http://world.std.com/~pitman/Papers/Exceptional-Situations-1990.html>
> suggests that there's nothing wrong with using exceptions for "unusual
> code paths":
For certain values of "nothing wrong".
> It is important to recognize that this distinction between normal
> and exceptional situations is in some sense contrived. Making this
> distinction does not change the way programs behave; it simply
> changes the way we reason about programs--hopefully for the better.
An esthetic judgement.
> In some cases, there may be efficiency reasons for considering
> some cases to be exceptional.
These costs rarely dominate the costs of an exception system in the
first place. Now in some language RTEs the added cost of
exception-handling is quite small. In others (C++ in particular) it is
not.
> In particular, allowing some [presumably infrequent] non-error code
> paths to be considered "exceptional" [and using inconspicuous flow
> control primitives to access them, such as CATCH/THROW] can, in turn,
> allow the "normal" code paths to be considerably simplified without
> compromising program correctness.
But again, we're talking about slippery-slope issues here. I am not
going to advocate the banning of exceptions. I have found that they
are very easily subjected to 'GOTO considerd harmful'-like abuse. At
the end of the day, programmer discipline is the only answer to crappy
code. Exceptions don't help tremendously in view of their potential
for abuse. This may well change as the programming community at large
learns how to structure exceptional control structures so they don't
degenerate into unreadable spaghetti. Call me back in about 5 years.
david rush
--
Open source code "is like lobster, most people who haven't tried it
don't like the way it looks. But those who try it, like it."
-- Jim Johnson, The Standish Group International
[ replying to comp.lang.lisp only
http://world.std.com/~pitman/pfaq/cross-posting.html ]
David Rush <····@bellsouth.net> writes:
> ····@rigden.engr.sgi.com (Rob Warnock) writes:
> > David Rush <····@bellsouth.net> wrote:
> > +---------------
> > | Please note: I am talking about a matter of degree here. My biggest
> > | beef with exception-based systems is that they end up getting used far
> > | too generally (for unusual code paths rather than actual failure
> > | handling).
> > +---------------
> > ...
> > In particular, allowing some [presumably infrequent] non-error code
> > paths to be considered "exceptional" [and using inconspicuous flow
> > control primitives to access them, such as CATCH/THROW] can, in turn,
> > allow the "normal" code paths to be considerably simplified without
> > compromising program correctness.
>
> But again, we're talking about slippery-slope issues here. I am not
> going to advocate the banning of exceptions. I have found that they
> are very easily subjected to 'GOTO considerd harmful'-like abuse. At
> the end of the day, programmer discipline is the only answer to crappy
> code. Exceptions don't help tremendously in view of their potential
> for abuse. This may well change as the programming community at large
> learns how to structure exceptional control structures so they don't
> degenerate into unreadable spaghetti. Call me back in about 5 years.
I'm uncomfortable seeing more discussion on this without a worked example.
I don't see a slippery slope here.
* Rob Warnock
| In particular, allowing some [presumably infrequent] non-error code
| paths to be considered "exceptional" [and using inconspicuous flow
| control primitives to access them, such as CATCH/THROW] can, in turn,
| allow the "normal" code paths to be considerably simplified without
| compromising program correctness.
I have always thought of "exceptions" to refer to exceptions from the
expected control flow. That is, if I am prepared to handle something, it
obviously goes in the normal control flow, but if I have no idea what do
with a particular situation that I know could arise, use an exception.
E.g., in a low-level I/O function, reaching the end of file or a full
disk or whatever is to be expected, but code that reads or writes known
objects from or to a stream should not have to expect such things and
should be able to throw up it hands and ask an exception handler to take
over, perhaps recovering and continuing.
///
--
[ replying to comp.lang.lisp only
http://world.std.com/~pitman/pfaq/cross-posting.html ]
Erik Naggum <····@naggum.net> writes:
> * Rob Warnock
> | In particular, allowing some [presumably infrequent] non-error code
> | paths to be considered "exceptional" [and using inconspicuous flow
> | control primitives to access them, such as CATCH/THROW] can, in turn,
> | allow the "normal" code paths to be considerably simplified without
> | compromising program correctness.
>
> I have always thought of "exceptions" to refer to exceptions from the
> expected control flow. That is, if I am prepared to handle something, it
> obviously goes in the normal control flow, but if I have no idea what do
> with a particular situation that I know could arise, use an exception.
> E.g., in a low-level I/O function, reaching the end of file or a full
> disk or whatever is to be expected, but code that reads or writes known
> objects from or to a stream should not have to expect such things and
> should be able to throw up it hands and ask an exception handler to take
> over, perhaps recovering and continuing.
Well, consider that I hand you some mail to deliver. I might say
"deliver this mail and tell me if you have problems" but I'm likely to
do that only if I think all the mailboxes are there. If I know there
are missing mailboxes, I might say "deliver these to the mailboxes
that exist" in which case you wouldn't be pestering me all the time.
In this regard, I would make an analogy to the so-called error that
occurs in the opening theme of Star Trek classic: "to boldly go".
Some language purists think this is a split infinitive and that the
correct form is "to go boldly". I prefer to think of "boldly go" as
its own verb, with an atomic meaning, whereas "to go" + "boldly" is a
composition of a verb and some additional info. Likewise, I think
(ignore-errors (read stream)) is pretty similar to (read stream nil
nil) but one of them invokes a tolerant read and one invokes a read +
handler. You can probably use either in any context (modulo the blunt
nature of ignore-errors catching too many errors, which I'm glossing
as uninteresting to the analogy). I claim (as a point of style, not
requirement) you should not use signaler+handler as part of a single
system; in that case, you should use explicit dataflow since you know
you're expecting an error and it's more efficient to just pass the
args than to cons a condition and go searching for a handler you know
is right there. But this is just the same common sense as not doing
(car (list 3 4)) when you mean 3. Nothing forbids you from it, but
it's silly. The "list protocol", if you'll indulge me that strange
view/abstraction, is for the purpose of communicating to someone in a
different module (or for other purposes, like having a variable number of
variables); it is not for the purpose of having a place to store things
within a module. One doesn't do:
(let ((storage (list 1 2)))
(symbol-macrolet ((a (first storage)) (b (second storage)))
(+ a b)))
because that's silly. Peephole optimization is in order at the programmer
level. But a class system does JUST like that:
(defun make-foo (a b) (list a b))
(defun foo-a (foo) (first foo))
(defun foo-b (foo) (second foo))
(defun foo-sum (foo) (+ (foo-a foo) (+ (foo-b foo))))
(foo-sum (make-foo 1 2))
but it does that for the sake of generality--because you MIGHT connect
these "half-components" (the constructor at one end and the de-constructor
at the other) to one another elsewhere in different forms. At the point you're
instead writing:
(labels ((make-foo (x y) (list x y))
(foo-a (foo) (first foo))
(foo-b (foo) (second foo))
(foo-sum (foo) (+ (foo-a foo) (foo-b foo))))
(foo-sum (make-foo 1 2)))
you are doing the bad thing. Yet, even though there is LOTS of syntactic
similarity here between the good and bad parts, I see no slippery slope.
There are perhaps a few gray areas, and I think they are generally comfortable
to be on because I don't feel I'm going to descend into the bad places just
because I'm in a place where you can defend either using or not using
the general protocol form.
In article <·················@quiotix.com>, Jeffrey Siegal
<···@quiotix.com> wrote:
> Andreas Bogk wrote:
> > As soon as you pile up some layers of code, it quickly becomes tedious
> > to pass around handlers everywhere. Just imagine passing a GUI dialog
> > for resolving a "disk full" condition all the way through the GUI,
> > your application code, your storage abstraction down to the actual
> > disk access.
>
> What happens in Java is that you have to at least declare the exceptions
> up the chain anyway (the compiler will reject a method that doesn't
> catch or throw E which involves a method declared to throw E. It isn't
> that much harder to explicitly pass the handler.
That's perfectly true.
It's also true that dealing with exception specifications in Java
*sucks*. In large Java projects I've worked on the vast majority of cvs
commits end up being maintainance on the exception specifications. It's
just a lot of pointless makework.
Being "not much harder" than Java is no recommendation.
-- Bruce
Jeffrey Siegal <···@quiotix.com> writes:
> Andreas Bogk wrote:
> > As soon as you pile up some layers of code, it quickly becomes tedious
> > to pass around handlers everywhere. Just imagine passing a GUI dialog
> > for resolving a "disk full" condition all the way through the GUI,
> > your application code, your storage abstraction down to the actual
> > disk access.
>
> What happens in Java is that you have to at least declare the exceptions
> up the chain anyway (the compiler will reject a method that doesn't
> catch or throw E which involves a method declared to throw E. It isn't
> that much harder to explicitly pass the handler.
Not completely true for Java. If you use RuntimeException or an
instance of a subclasses of RuntimeException, you dont have to
declare it in throws clauses.
Ref.:
http://java.sun.com/j2se/1.3/docs/api/java/lang/RuntimeException.html
In article <·················@quiotix.com>, Jeffrey Siegal
<···@quiotix.com> wrote:
> Andreas Bogk wrote:
> > > What does Dylan have that Scheme + CLOS + "a collections library"
> > > doesn't have?
> >
> > That would be conditions, type annotations and a useful module/library
> > system.
>
> I agree about modules, although I don't really like the way Dylan uses
> multiple files to define a simple module. There should be a way of
> doing that in-line.
No one does. That was supposed to be just an interchange format, not
something that users had to deal with. That was the case in the Apple
IDE, where all the code was kept in a database.
We've had a bit of discussion recently on a way to put various modules
into the same source file. Nothing has been agreed yet, but in Gwydion
we have recently done a related thing in implementing a "single-file
mode" that lets you write small programs without a library or module
declaration at all, with a default set of imports. If/when your program
outgrows that you can always add the .lid file.
The ability to put imports/exports in the same file with code is
something we definitely plan for fairly soon.
-- Bruce
On Mon, 24 Dec 2001, Jeffrey Siegal wrote:
> Andreas Bogk wrote:
[snip]
> > For the language user, there may be no middle ground. From the
> > perspective of the language designer, the syntax is just one issue of
> > many, so even if you prefer S-expressions, there's still a lot of Lisp
> > to discover in Dylan.
>
> Did you mean "A lot _for_ Lisp to discover?" There is little in Dylan
> that didn't originate with Lisp, except the syntax. What does Dylan
> have that Scheme + CLOS + "a collections library" doesn't have?
I don't know if there's a *lot* for Lisp to discover, at least in the
sense of finding new constructs or general programming techniques. I
suspect that what there is to be learned from Dylan (for dynamic
langauges) are in the following three areas:
1) What compromises with conventionality work and
don't work.
To wit, if you're going to abandone Lispy syntax, a *Pascal
like* syntax probably isn't a good idea?
2) What compromises with staticness work and don't work.
Does sealing really help? How much? How constraining is it?
What does it permit by way of optimization that CL doesn't?
Both the above hold only for the limited range of compromises Dylan
actually made. But at least there's some more or less production
experience with this range.
3) How not to sell a language.
After all, Dylan is *substationally* worse off than Common
Lisp. Clearly, Dylan is the *much* more lost cause. One can blame
historical circumstances (e.g., Apple's dropping the ball), but,
after all, Dylan wasn't resiliant enough to take that blow easily.
It does make me wonder how much of the goals of Dylan would have
been better realized as an extention of Common Lisp (e.g., a bunch
of packages) rather than merely having been implemented in it.
I still have a soft spot for Dylan, not least because it was reading a
Dylan book that introduced me to generic functions, which I think are
*incredibly* cool, even if I don't use them :) It was eye-opening. The
Lisp (ok, mostly Scheme, but there was some CL in there) documentation I'd
read to that point either didn't mention them, or deferred discussion
until *much* later in the game. If I'd had Keene's book then, I suspect
it would have done the job (it's really quite hard to say enough nice
things about her book).
Cheers,
Bijan Parsia.
Bijan Parsia <·······@email.unc.edu> writes:
> To wit, if you're going to abandone Lispy syntax, a *Pascal
> like* syntax probably isn't a good idea?
I don't think that introducing a Pascal-like syntax was a bad idea.
Dropping the Lispy syntax was the bad idea.
In the static language camp, I can happily mix libraries from Fortran,
Pascal, C and C++. If there were interoperability between an infix
and a prefix Lisp-like language, that would be a huge win.
> Does sealing really help? How much? How constraining is it?
> What does it permit by way of optimization that CL doesn't?
One instance where sealing really helps is arithmetics. Witness Java
for a language that gives up it's OO approach for fast integers, and
the problems this introduces. In Dylan, integers are objects like all
others, still arithmetics is fast, because operations are sealed.
> It does make me wonder how much of the goals of Dylan would have
> been better realized as an extention of Common Lisp (e.g., a bunch
> of packages) rather than merely having been implemented in it.
I like the "objects from the grounds up" approach, and Dylan feels
very clean and consistent to me. That couldn't have been achieved by
a couple of libraries.
Andreas
(Followup-To set to comp.lang.dylan)
--
"In my eyes it is never a crime to steal knowledge. It is a good
theft. The pirate of knowledge is a good pirate."
(Michel Serres)
On 25 Dec 2001, Andreas Bogk wrote:
> Bijan Parsia <·······@email.unc.edu> writes:
>
> > To wit, if you're going to abandone Lispy syntax, a *Pascal
> > like* syntax probably isn't a good idea?
>
> I don't think that introducing a Pascal-like syntax was a bad idea.
> Dropping the Lispy syntax was the bad idea.
Well, it depends on what you want to do. If you abandon (or deprecate, or
hide) a Lispy syntax, presumably it's because you want to please or
placate folks who are turned off from Lispy syntaxes. *Developer* type
folks (i.e., we're not talking scripting langauges for
non-programmers). The only remotely Pascal like syntaxed language that's
gained traction in the past decade that I know of is Python, and it dumped
begin/end.
(Hmm. Ruby has a bit of that too, IIRC.)
(This is in contrast with Delphi, which is a *holdover*.)
Myself, I don't care at all for C like syntaxes, but I concede that
they're more popular. If you're goal is to be popular, you might try past
successful moves :) Dylan's syntax wasn't successful for *any* camp.
[snip]
> > Does sealing really help? How much? How constraining is it?
> > What does it permit by way of optimization that CL doesn't?
>
> One instance where sealing really helps is arithmetics. Witness Java
> for a language that gives up it's OO approach for fast integers, and
> the problems this introduces. In Dylan, integers are objects like all
> others, still arithmetics is fast, because operations are sealed.
Eh. I didn't mean these to be questions you answer, but I'll note that you
didn't answer 'em. The interesting question is sealing *vs.* a CL like
approach.
(Smalltalk looks to this question, too. Optional type declarations plus
inferencing are seen as wins; sealing isn't.)
> > It does make me wonder how much of the goals of Dylan would have
> > been better realized as an extention of Common Lisp (e.g., a bunch
> > of packages) rather than merely having been implemented in it.
>
> I like the "objects from the grounds up" approach, and Dylan feels
> very clean and consistent to me. That couldn't have been achieved by
> a couple of libraries.
Is that a *goal* of Dylan, or just something it did?
In any case, that makes me think that you don't know Common Lisp very well
:)
Reset followups to the newsgroup I read.
And I'm sorta done with this thread, FWIW.
Cheers,
Bijan Parsia.
In article
<··········································@login6.isis.unc.edu>, Bijan
Parsia wrote:
>On 25 Dec 2001, Andreas Bogk wrote:
>
>> Bijan Parsia <·······@email.unc.edu> writes:
>>
>> > To wit, if you're going to abandone Lispy syntax, a *Pascal
>> > like* syntax probably isn't a good idea?
>>
>> I don't think that introducing a Pascal-like syntax was a bad idea.
>> Dropping the Lispy syntax was the bad idea.
>
>Well, it depends on what you want to do. If you abandon (or deprecate, or
>hide) a Lispy syntax, presumably it's because you want to please or
>placate folks who are turned off from Lispy syntaxes.
Then you are no longer practicing technology, but psychology or politics.
Kaz Kylheku wrote:
> In article
> <··········································@login6.isis.unc.edu>, Bijan
> Parsia wrote:
>
>>On 25 Dec 2001, Andreas Bogk wrote:
>>
>>
>>>Bijan Parsia <·······@email.unc.edu> writes:
>>>
>>>
>>>> To wit, if you're going to abandone Lispy syntax, a *Pascal
>>>> like* syntax probably isn't a good idea?
>>>>
>>>I don't think that introducing a Pascal-like syntax was a bad idea.
>>>Dropping the Lispy syntax was the bad idea.
>>>
>>Well, it depends on what you want to do. If you abandon (or deprecate, or
>>hide) a Lispy syntax, presumably it's because you want to please or
>>placate folks who are turned off from Lispy syntaxes.
>>
>
> Then you are no longer practicing technology, but psychology or politics.
>
Successful language design is all these things.
On Tue, 25 Dec 2001 23:12:51 -0800, jeff
<·····@houseofdistraction.com> wrote:
>>>Well, it depends on what you want to do. If you abandon (or deprecate, or
>>>hide) a Lispy syntax, presumably it's because you want to please or
>>>placate folks who are turned off from Lispy syntaxes.
>>
>> Then you are no longer practicing technology, but psychology or politics.
>
>Successful language design is all these things.
True. Unless one gets mind share ( and consequent market share )
language design is meaningless.
In article <··································@4ax.com>, israel r t wrote:
>On Tue, 25 Dec 2001 23:12:51 -0800, jeff
><·····@houseofdistraction.com> wrote:
>
>>>>Well, it depends on what you want to do. If you abandon (or deprecate, or
>>>>hide) a Lispy syntax, presumably it's because you want to please or
>>>>placate folks who are turned off from Lispy syntaxes.
>>>
>>> Then you are no longer practicing technology, but psychology or politics.
>>
>>Successful language design is all these things.
A psychologically successful design arises out of psychology.
A technically successful design arises only out of good technology.
>True. Unless one gets mind share ( and consequent market share )
>language design is meaningless.
That is utter nonsense.
A machine can understand whatever language you want it to understand.
Users are usually not aware of what language a delivered program is
written in.
There have existed programming languages which were unique to the
application that they were integrated into. That application was
successful nevertheless, nonexistent mind share of the hidden language
notwithstanding. Thus even completely unknown, unique programming
languages can be used successfully in a program that has a shot at
becoming widely used.
It's nice to have a community surrounding a programming language; there
are benefits from not being the only one using it. You're unlikely to
have a high quality implementation for multiple platforms if you're
the only user. But if 99.999% of the apparent community is clueless,
then the real community is just the remaining 0.001%.
For instance, out of all the C++ programmers, how many really know the
ISO standard C++? Informally, one gets the impression that the proportion
is vanishingly small.
Somehow, the bulk of the remaining users don't manage to contribute to
the quality of the language or of the available tools. They don't even
know exactly what those tools are supposed to implement.
So in the end, popularity of a language is something that only matters to
the inventor and to some tool vendors. To the developer, it provides no
useful benefit. In fact, it is a liability. Language popularity makes the
tool vendors complacent, and at the same time ensures that the job market
is full of programers who all cite knowledge of that language on
their resumes. If you need a developer, you get a truckload of
resumes, most of which are chaff. If you need a job, your resume ends
up in such a truckload. Microsoft Visual C++ is undoubtedly the most
popular C++ implementation; perhaps not by coincidence, has the worst
standard compliance, and is packaged in a horribly inefficient, buggy,
unreliable development environment. There is zero motivation to do
anything about it.
The decision about what language to use should be made on purely
technical and economic grounds, because the success of the software
depends on it. There are sound technical reasons for preferring Lisp
syntax, whereas there is no technical reason for preferring, say, Pascal
or C syntax. People who only know non-reflexive languages think that
syntax is just such a matter of taste. Or worse, that its details are
somehow semantically significant: that, for instance, being able to
write while (*s) *d++ = *s++; is somehow inherently powerful, compared
to splitting the operation into several expressions, when in fact the
clueful user writes a call to strcpy(). People who understand Lisp know
that seemingly convenient syntax can actually become a huge barrier
between the user and the language. So the choice of syntax actually
has real implications; it's not just some emotional matter of taste,
but another techical decision. You're not selling the language, but
software. Catering to tastes may not be the best thing for the end result
you are trying to achieve.
Yes, psychology must be taken into account when designing software for
people. And there is a domain where those considerations are appropriate:
human-computer interface design.
There is another domain in which psychology is relevant: software
engineering. The success of large scale development is critically tied
to the limitations of the human brain. Programming languages which are
designed to exhibit a convenient syntax in tiny programming examples
are successful at seducing naive programmers, so on one level they
are the result of successful psychology. But the important psychology,
which has an impact on the technical success of software development,
is overlooked. Human beings require abstraction in order to avoid
cognitive overload: trying to understand the large scale pattern in
a morass of insignificant details. Therefore programming languages need to
be able to express abstractions. The choice of syntax becomes important,
because it affects how easy it is to make the syntax of the language
programmable, at the right level of abstraction, where the programmer
can have the illusion that he's working directly with that syntax,
rather than some translated representation of it.
In article <·······················@news1.calgary.shaw.ca>,
Kaz Kylheku <···@ashi.footprints.net> wrote:
>In article <··································@4ax.com>, israel r t wrote:
>>On Tue, 25 Dec 2001 23:12:51 -0800, jeff
>><·····@houseofdistraction.com> wrote:
>>
>>>>>Well, it depends on what you want to do. If you abandon (or deprecate, or
>>>>>hide) a Lispy syntax, presumably it's because you want to please or
>>>>>placate folks who are turned off from Lispy syntaxes.
>>>>
>>>> Then you are no longer practicing technology, but psychology or politics.
>>>
>>>Successful language design is all these things.
>
>A psychologically successful design arises out of psychology.
>A technically successful design arises only out of good technology.
Ergonomics and interface design are aspects of technology that take into
account the physiology and psychology of the users.
One could claim that assembly or machine language is the best technical
solution to programming computers, because it allows you to take advantage
of all the computer's features. But this discounts the psychological
effort that it takes to program in machine language compared to high level
languages. HLL's owe their existence to psychological needs.
--
Barry Margolin, ······@genuity.net
Genuity, Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
In article <··················@burlma1-snr2>, Barry Margolin wrote:
>In article <·······················@news1.calgary.shaw.ca>,
>Kaz Kylheku <···@ashi.footprints.net> wrote:
>>In article <··································@4ax.com>, israel r t wrote:
>>>On Tue, 25 Dec 2001 23:12:51 -0800, jeff
>>><·····@houseofdistraction.com> wrote:
>>>
>>>>>>Well, it depends on what you want to do. If you abandon (or deprecate, or
>>>>>>hide) a Lispy syntax, presumably it's because you want to please or
>>>>>>placate folks who are turned off from Lispy syntaxes.
>>>>>
>>>>> Then you are no longer practicing technology, but psychology or politics.
>>>>
>>>>Successful language design is all these things.
>>
>>A psychologically successful design arises out of psychology.
>>A technically successful design arises only out of good technology.
>
>Ergonomics and interface design are aspects of technology that take into
>account the physiology and psychology of the users.
That's correct; that's who you are trying to sell some product to,
or so I'm assuming.
>One could claim that assembly or machine language is the best technical
>solution to programming computers, because it allows you to take advantage
>of all the computer's features. But this discounts the psychological
>effort that it takes to program in machine language compared to high level
>languages. HLL's owe their existence to psychological needs.
Which is something that I mention at the bottom part that you snipped.
Those psychological needs are still driven by the need to create
sophisticated, reliable software. Making a language popular requires
a different use of psychology manipulation that has nothing to do
with enabling users to make software; it has to do with manipulating
their egos and insecurities, or appealing to what they find familiar.
There is a difference between using the psychology to create
acceptance, and using psychology to best adapt the machines and
tools to human capability.
So it boils down to what you mean by successful language design.
Israel R T, for instance, thinks that successful equals popular. Thus,
for instance, Visual Basic is a successful design.
···@ashi.footprints.net (Kaz Kylheku) writes:
> People who only know non-reflexive languages think that syntax is
> just such a matter of taste. Or worse, that its details are somehow
> semantically significant: that, for instance, being able to write
> while (*s) *d++ = *s++; is somehow inherently powerful, compared to
> splitting the operation into several expressions, when in fact the
> clueful user writes a call to strcpy().
To pick an OT nit, that won't do what strcpy() does; it won't copy the
null terminator. What you want is while (*d++ = *s++) ;
--
F*CK CENSORSHIP
···@ashi.footprints.net (Kaz Kylheku) writes:
> The decision about what language to use should be made on purely
> technical and economic grounds, because the success of the software
You mean economic reasons like e.g. "Who's going to maintain your
smart Lisp solution if you're hit by a bus?" Mindshare and the number
of available programmers _are_ important.
* Nils Kassube <····@kassube.de>
| You mean economic reasons like e.g. "Who's going to maintain your
| smart Lisp solution if you're hit by a bus?" Mindshare and the number
| of available programmers _are_ important.
That is why a smart Common Lisp programmer knows at least two other
Common Lisp programmers who are willing to take over the code if he dies
or whatever. Actually having an answer to this rhetorical question tends
to blow the minds of those who ask it. Just because there are more C++
or Java programmers in the world, does not mean that you can find one
that will _actually_ be able to take over a non-trivial project.
///
--
The past is not more important than the future, despite what your culture
has taught you. Your future observations, conclusions, and beliefs are
more important to you than those in your past ever will be. The world is
changing so fast the balance between the past and the future has shifted.
Erik Naggum <····@naggum.net> writes:
> to blow the minds of those who ask it. Just because there are more C++
> or Java programmers in the world, does not mean that you can find one
> that will _actually_ be able to take over a non-trivial project.
Yes. I've used that lines myself.
Still the probability of finding a replacement for a Java programmer
is an order of magnitude (probably a lot more) better than finding a
replacement for a CL wizard. So it's a valid concern for businesses to
evaluate if it's smarter to hire a bunch of mediocre Java programmers
or a few clever CL developers.
Business unfortunately means a lot of CYA [1]. I'm very happy to see
thriving Open Source implementations of Common Lisp for this very
reason.
[1] CYA = Pbire Lbhe Nff
* Nils Kassube <····@kassube.de>
| Still the probability of finding a replacement for a Java programmer is
| an order of magnitude (probably a lot more) better than finding a
| replacement for a CL wizard. So it's a valid concern for businesses to
| evaluate if it's smarter to hire a bunch of mediocre Java programmers or
| a few clever CL developers.
The situation is not Java vs CL, but mediocre vs wizard. CL programmers
who want to work for money have to be _good_, as they stand on their own.
Java programmers can be amazingly incompetent and ignorant and still get
jobs, because they rely on so many others around them. The problem may
be that it is hard to find CL mediocrities and Java wizards alike, so for
one who hires Java mediocrities, the fact that it may be easier to find a
CL wizard than a Java wizard is unimportant, because he is only looking
for CL mediocrities when he does not know anything else. In particular,
it is hard for someone who hires programmers by the truckload to believe
that one CL wizard can do the work of at least 10 Java men.
///
--
The past is not more important than the future, despite what your culture
has taught you. Your future observations, conclusions, and beliefs are
more important to you than those in your past ever will be. The world is
changing so fast the balance between the past and the future has shifted.
On Fri, 28 Dec 2001 14:10:18 GMT, Erik Naggum <····@naggum.net> wrote:
> CL programmers who want to work for money have to be _good_, as they stand on their own.
> Java programmers can be amazingly incompetent and ignorant and still get
> jobs, because they rely on so many others around them.
> it is hard for someone who hires programmers by the truckload to believe
> that one CL wizard can do the work of at least 10 Java men.
Is there any objective evidence for this statement ?
The only study that I am aware of that compared Lisp and Java
productivity found that the median development time with Lisp was half
of the development time with Java . While this is good, it does not
translate into a 10 : 1 advantage.
http://www-aig.jpl.nasa.gov/public/home/gat/lisp-study.html
The conclusions of the study ( done at JPL ) were interesting however:
"Our results suggest that Lisp is superior to Java and comparable to
C++ in terms of runtime, and superior to both in terms of programming
effort, and variability of results.
This last item is particularly significant as it translates directly
into reduced risk for software development.
Lisp provides nearly all of the advantages that make Java attractive,
including automatic memory management, dynamic object-oriented
programming, and portability.
Lisp is often considered an esoteric AI language. Our results suggest
that it might be worthwhile to revisit this view. "
israel r t <········@optushome.com.au> wrote in message news:<··································@4ax.com>...
> The only study that I am aware of that compared Lisp and Java
> productivity found that the median development time with Lisp was half
For real work Lisp might have a much bigger advantage than for
contests. If for a typical contest it's twice as productive, where
most of the power of Lisp is not even needed, it's easy to imagine
it's being 10 times as productive for real work. I don't know how we
would go about proving it. But can anyone prove the converse, that
the Lisp/Java productivity ratio for real work is less than 10 to 1?
Can anyone even prove it's less than 100 to 1?
On 28 Dec 2001 23:06:00 -0800, ··········@mailandnews.com (Software
Scavenger) wrote:
>israel r t <········@optushome.com.au> wrote in message news:<··································@4ax.com>...
>
>> The only study that I am aware of that compared Lisp and Java
>> productivity found that the median development time with Lisp was half
>
>But can anyone prove the converse, that
>the Lisp/Java productivity ratio for real work is less than 10 to 1?
>Can anyone even prove it's less than 100 to 1?
No.
However, if lack of disproof is adequate proof, then I could claim
that Lisp is Z times more productive than Java and might choose to
use a value of 10,0000 for Z.
That would be patently absurd.
From: Erik Naggum
Subject: Re: Comparing development effort : Lisp and functional languages versus Java.
Date:
Message-ID: <3218610469828899@naggum.net>
* israel r t <········@optushome.com.au>
| Is there any objective evidence for this statement?
* ··········@mailandnews.com (Software Scavenger)
> Can anyone even prove it's less than 100 to 1?
* israel r t <········@optushome.com.au>
| No.
:
| That would be patently absurd.
Please try to figure out that your request for "objective evidence" has
been shown to be nothing more than a hostile rhetorical device devoid of
constructive value when you answered "no" to a question that should be
much easier to prove on your part, "objective evidence" clearly being
instrumental in a proof. When you cannot dish up any "objective
evidence" for a counter-claim an order of magnitude stronger than the
one you request it for, what is patently absurd is your initial request.
People who are so ill educated in logic that they talk about "proof" and
"objective evidence" in informal settings, fail to understand that what
they are doing is simply being hostile idiots wielding a weapon that they
do not understand. In a formal setting, "evidence" and "proof" derive
their legitimacy on consensus and unanimity of both principles and
premises of the field. Since this is clearly very useful and valuable in
mathematics and physics, some people who do not understand _how_ it is
valuable have instead been seriously confused and think that failure to
"prove" something or failure to provide "objective evidence" is somehow a
weakness of the other party to their discussion until one starts to think
about how little of what we hold to be true that we can prove to a person
who has signalled not only disbelief, but a requirement to believe in it
that far exceeds any requirements satisfied by anything he already
believes.
Using "proof" and "objective evidence" in a rhetorical fashion like this
is nothing more than evidence of a person's lack of ability to deal with
his feelings of congitive dissonance -- the feeling of conflict between
what he already believes and what he is asked to believe. What this is a
good symptom of, is a person who has believed only the first thing he has
heard basically without evidence or proof whatsoever, but when it needs
to be disproven or replaced by another belief, he applies a standard of
truth to it that is intended to show only two things: (1) that what he
already believes remains unchallenged, and (2) that whatever challenged
it did not stand up under scrutiny. This would not be so bad if people
always believed true and proven things, but since they mostly believe a
lot of nonsense, and only those who believe a lot of nonsense use "proof"
and "objective evidence" to fight off challenges (those who know that
their own beliefs are true and proven, can simply provide some evidence
of their own beliefs to counter unfounded claims), using the tools of
logic in a petty and hostile reaction to things one does not want to hear
is somewhat ironically a strong signal to their surroundings that they
lack strength of conviction in their own beliefs.
How should we then face new information that challenges our current
beliefs? Assume it is true and see what follows. Of course, if we do
this, idiots who fail to understand that the level of goodwill required
by this methodology will waste a lot of our time. Idiots who refuse to
back down from their false beliefs and/or sheer insanity, then become a
source of flame wars and continued spurts of hatred on USENET.
///
--
The past is not more important than the future, despite what your culture
has taught you. Your future observations, conclusions, and beliefs are
more important to you than those in your past ever will be. The world is
changing so fast the balance between the past and the future has shifted.
From: Sander Vesik
Subject: Re: Comparing development effort : Lisp and functional languages versus Java.
Date:
Message-ID: <1009665707.163142@haldjas.folklore.ee>
In comp.lang.scheme israel r t <········@optushome.com.au> wrote:
> On 28 Dec 2001 23:06:00 -0800, ··········@mailandnews.com (Software
> Scavenger) wrote:
>>israel r t <········@optushome.com.au> wrote in message news:<··································@4ax.com>...
>>
>>> The only study that I am aware of that compared Lisp and Java
>>> productivity found that the median development time with Lisp was half
>>
>>But can anyone prove the converse, that
>>the Lisp/Java productivity ratio for real work is less than 10 to 1?
>>Can anyone even prove it's less than 100 to 1?
> No.
> However, if lack of disproof is adequate proof, then I could claim
> that Lisp is Z times more productive than Java and might choose to
> use a value of 10,0000 for Z.
Or you might treat Z as being a real and make it be some other value,
possibly much smaller than 1...
> That would be patently absurd.
The absence of comparisons of the style 'how does language x compare to
lisp' done by non-lispers shoul dbe a dead giveaway that lisp users are
the only ones who would give even a dead rat for knowing it.
Nobody will bother make a comparison to a language they don't feel
threatening to eat away their market share (or form which they would
try to claim it)...
--
Sander
+++ Out of cheese error +++
From: Kenny Tilton
Subject: Re: Comparing development effort : Lisp and functional languages versus Java.
Date:
Message-ID: <3C2E7733.5762AD7E@nyc.rr.com>
Sander Vesik wrote:
>
> Nobody will bother make a comparison to a language they don't feel
> threatening to eat away their market share (or form which they would
> try to claim it)...
I am puzzled. The idea was that a large enterprise -- a consumer of
languages, not a vendor -- would do a comparison to decide long-term
strategy re development. This seems to be a straw man about Bill not
being threatened by CL enough to test and see if...what, MS should halt
VC++ developemnt and do VCL?
Anyway, I agree that not even a user of C++ would attempt a side-by-side
experiment. If they are considering switching they are (1) early
adopters (ironic when applied to CL) (2) fully aware how badly C++
sucks, so: they need only a few hours toying with a free CL download to
realize they should switch.
kenny
clinisys
On Sat, 29 Dec 2001 22:41:49 +0000 (UTC), Sander Vesik
<······@haldjas.folklore.ee> wrote:
>Nobody will bother make a comparison to a language they don't feel
>threatening to eat away their market share (or form which they would
>try to claim it)...
Market share is not the most important goal.
It is more important to be able to use decent tools that have not been
dumbed down to the level of the "average programmer"
From: Sander Vesik
Subject: Re: Comparing development effort : Lisp and functional languages versus Java.
Date:
Message-ID: <1009745344.49992@haldjas.folklore.ee>
In comp.lang.scheme israel r t <········@antispamoptushome.com.au> wrote:
> On Sat, 29 Dec 2001 22:41:49 +0000 (UTC), Sander Vesik
> <······@haldjas.folklore.ee> wrote:
>>Nobody will bother make a comparison to a language they don't feel
>>threatening to eat away their market share (or form which they would
>>try to claim it)...
> Market share is not the most important goal.
> It is more important to be able to use decent tools that have not been
> dumbed down to the level of the "average programmer"
The continuing holier-than-thou attitude the average lisp programmer
(who is not any brighter than the average non-lisp programmer anyways)
never has and never will help improve the wider spread use of the language.
--
Sander
+++ Out of cheese error +++
From: Kenny Tilton
Subject: Re: Comparing development effort : Lisp and functional languages versus Java.
Date:
Message-ID: <3C2FCDF6.FB981BAD@nyc.rr.com>
Sander Vesik wrote:
> The continuing holier-than-thou attitude the average lisp programmer...
There are no average Lisp programmers. We are the Priesthood. Offerings
of incense or cash will do.
> (who is not any brighter than the average non-lisp programmer anyways)
yep, Lisp just makes us look smart.
> never has and never will help improve the wider spread use of the language.
What is deadly is a language community that is /not/ delighted with its
language and itself.
kenny
clinisys
On Mon, 31 Dec 2001 02:27:21 GMT, Kenny Tilton <·······@nyc.rr.com>
wrote:
>Sander Vesik wrote:
>> The continuing holier-than-thou attitude the average lisp programmer...
>There are no average Lisp programmers. We are the Priesthood. Offerings
>of incense or cash will do.
Occasional sacrifices of C++ and Java users would be appreciated.
"Sander Vesik" <······@haldjas.folklore.ee> wrote in message
·····················@haldjas.folklore.ee...
> In comp.lang.scheme israel r t <········@antispamoptushome.com.au> wrote:
> > On Sat, 29 Dec 2001 22:41:49 +0000 (UTC), Sander Vesik
> > <······@haldjas.folklore.ee> wrote:
>
> >>Nobody will bother make a comparison to a language they don't feel
> >>threatening to eat away their market share (or form which they would
> >>try to claim it)...
>
> > Market share is not the most important goal.
> > It is more important to be able to use decent tools that have not been
> > dumbed down to the level of the "average programmer"
>
> The continuing holier-than-thou attitude the average lisp programmer
> (who is not any brighter than the average non-lisp programmer anyways)
> never has and never will help improve the wider spread use of the language.
>
> --
It is worth pointing out that you make this comment in response to a posting
from the Scheme community.
That said, I also think "average lisp programmer" is not fair. It is a vocal
minority that tends to make its passion sound like arrogance.
That said, I think its not unfair to say the "average programmer" is not above
average intelligence and the tool market is generally aimed at helping
programmer shortcomings. This principle is independant of language.
--
Coby
(remove #\space "coby . beck @ opentechgroup . com")
From: Kent M Pitman
Subject: Re: Comparing development effort : Lisp and functional languages versus Java.
Date:
Message-ID: <sfwg05sclj6.fsf@shell01.TheWorld.com>
[ replying to comp.lang.lisp only
http://world.std.com/~pitman/pfaq/cross-posting.html ]
Sander Vesik <······@haldjas.folklore.ee> writes:
> In comp.lang.scheme israel r t <········@antispamoptushome.com.au> wrote:
> > On Sat, 29 Dec 2001 22:41:49 +0000 (UTC), Sander Vesik
> > <······@haldjas.folklore.ee> wrote:
>
> >>Nobody will bother make a comparison to a language they don't feel
> >>threatening to eat away their market share (or form which they would
> >>try to claim it)...
>
> > Market share is not the most important goal.
> > It is more important to be able to use decent tools that have not been
> > dumbed down to the level of the "average programmer"
I'm not sure if I totally agree with this analysis since it suggests that
tools are decent independent of their users. The best tools are those that
serve their users. Different users may require different tools.
But all of that notwithstanding, I also have a quibble with the reply you
got to this remark from Sander...
(Not that he'll necessarily hear it, since this discussion was so heavily
cross-posted and I'm only willing to reply to comp.lang.lisp, but so it
goes.)
> The continuing holier-than-thou attitude the average lisp programmer
> (who is not any brighter than the average non-lisp programmer anyways)
This parenthetical remark is made as if it were a statement of provable
and documented fact, attempting to counteract a statement of sheer
conjecture on the basis of wishful thinking. Absent any actual data, I
would be *very* surprised if there were no difference between the average
caliber of person using one language vs the average using another. Whether
that means language X or language Y is better is another matter, but you seem
to assert that these quantities are known to be equal, or may be best assumed
equal absent other evidence, and I doubt that. Saying that city X and city
Y have the same average temperature just because you have not measured city
X and city Y's avearge temperature is not going to get you a "fairer result".
It's going to mislead you into thinking you can work without this variable
when perhaps you should be trying to measure it.
I would further guess that, all other things being equal, any language that
requires a struggle to use (whether social--because friends object,
economic--because it's not available as cheaply, or educational--because it's
not taught in schools) is going to attract people who are independent,
have better average income or are more willing to invest in their future, and
more willing to self-teach or again to invest in their own education. This
is likely, I wouuld bet, to yield a higher average result not because there
is something better with the language but because the langauge's natural
obstacles weed out those who are shallow of spirit. As consequence, for
better or worse, I'd bet that at least right now, for no technical reason,
but for many sociological reasons, the average user of Lisp or pretty much of
ANY non-commodity language (i.e., any language other than C, C++, Java,
Visual Basic, Pascal, or something else offered by Microsoft and/or taught
routinely in many schools) is going to be sharper than the average user
of a commodity language. I don't know what that information buys you, since
it doesn't tell you about the technical goodness for purpose of the language.
But the fact that I don't know what to do with the statistic doesn't make it
not so.
Mind you, I'm not saying that Lisp users are now or ever have been smarter
than average, but I am saying that there are very reasonable reasons for
assuming such a thing while waiting for someone to come up with a more
reliable answer.
Wanting for political correctness reasons for it to simply be accidentally
equal is pretty ostrichlike. Head in the sand and all that.
> never has and never will help improve the wider spread use of the language.
Well, arrogance can be perceived where there is none.
But then, so can jealousy.
For whatever that might be worth.
From: Lieven Marchand
Subject: Re: Comparing development effort : Lisp and functional languages versus Java.
Date:
Message-ID: <m3sn9rpck7.fsf@localhost.localdomain>
Kent M Pitman <······@world.std.com> writes:
> I would further guess that, all other things being equal, any language that
> requires a struggle to use (whether social--because friends object,
> economic--because it's not available as cheaply, or educational--because it's
> not taught in schools) is going to attract people who are independent,
> have better average income or are more willing to invest in their future, and
> more willing to self-teach or again to invest in their own education. This
> is likely, I wouuld bet, to yield a higher average result not because there
> is something better with the language but because the langauge's natural
> obstacles weed out those who are shallow of spirit. As consequence, for
> better or worse, I'd bet that at least right now, for no technical reason,
> but for many sociological reasons, the average user of Lisp or pretty much of
> ANY non-commodity language (i.e., any language other than C, C++, Java,
> Visual Basic, Pascal, or something else offered by Microsoft and/or taught
> routinely in many schools) is going to be sharper than the average user
> of a commodity language. I don't know what that information buys you, since
> it doesn't tell you about the technical goodness for purpose of the language.
> But the fact that I don't know what to do with the statistic doesn't make it
> not so.
I'd say that is a well documented phenomenon [0]. There is a large
group of programmers that consider programming something they do to
earn money without getting actually involved or invested in it. They
will use what their boss/company tell them to use and after doing
their nine to five hours go home and occupy themselves with something
they really care about. So any non mainstream language/OS/... has
already self selected a "better" group of programmers.
[0] From Bjarne Stroustrups page http://www.research.att.com/~bs/blast.html
When C++ was new, one of the things that pleased me most was that
discussions about C++ were so much better informed than discussions
about most other languages, that the understanding of key concepts
were so much better in C++ groups than in, say, C and Pascal groups,
and that groups such as comp.lang.c++ were so much more polite and
supportive than that of other groups.
Clearly, I thought naively, C++ attracts a much better class of
programmers, learning C++ helps people to absorb the key concepts of
good programming/design, and the resulting success makes people more
tolerant and helpful.
I was wrong. The phenomenon was real, but it had little to do with
C++. In a small dedicated community, life is relatively easy. people
do their homework, people have access to reasonable sources of
information, gross errors and misconceptions are corrected before they
can cause significant harm, compilers and teaching materials are
up-to-date, etc.
This is not and cannot be the case in a multi-hundred-thousand member
community: Some will be taught out of outdated or unsuitable books,
some will use antiquated compilers and tools, some will be taught by
charlatans, some will be remote from current and reliable
news-sources, some will have unsuitable rules and regulations imposed
on their work, etc. Also, in a rapidly growing community, most users
will be novices.
...
Proponents of languages that still have relatively minute - and
therefore relatively close-knit and well-informed user communities -
are making the mistake I made: seeing the evident success and
enthusiasm of their fellow ``cult members'' as a direct consequence of
qualities of their favorite language. They are wrong; if - against all
odds - their language should escape into the mainstream the vastly
enlarged user community will get its share of the problems and
failures.
--
Lieven Marchand <···@wyrd.be>
She says, "Honey, you're a Bastard of great proportion."
He says, "Darling, I plead guilty to that sin."
Cowboy Junkies -- A few simple words
The great, pithy, comment:
"If Ada became the hot, in-language you would see a lot more bad code
in Ada."
-- Thaddeus L. Olczyk <······@interaccess.com>, comp.lang.C++
--
(concatenate 'string "aa454" ·@freenet.carleton.ca")
http://www.ntlug.org/~cbbrowne/spiritual.html
There's a new language called C+++. The only problem is every time
you try to compile your modem disconnects.
From: Kenny Tilton
Subject: Re: Comparing development effort : Lisp and functional languages versus Java.
Date:
Message-ID: <3C2E3A65.77C774DD@nyc.rr.com>
Software Scavenger wrote:
>
> israel r t <········@optushome.com.au> wrote in message news:<··································@4ax.com>...
>
> > The only study that I am aware of that compared Lisp and Java
> > productivity found that the median development time with Lisp was half
>
> For real work Lisp might have a much bigger advantage than for
> contests.
I had the same thought. Lisp supports meta-solutions which not only pay
off more and more in the long run, but which also require greater design
effort up front. If anything a Lisper tortoise seems to be going slower
than the hacker hare because the tortoise is still at the starting line
building a rocket sled.
This could be one small reason why cool languages are not widely
used--how many tasks require meta-solutions, and how many programmers
would come up with one even if the language supported such a thing?
kt
From: Thomas F. Burdick
Subject: Re: Comparing development effort : Lisp and functional languages versus Java.
Date:
Message-ID: <xcv7kr5lmez.fsf@famine.OCF.Berkeley.EDU>
Kenny Tilton <·······@nyc.rr.com> writes:
> Software Scavenger wrote:
> >
> > israel r t <········@optushome.com.au> wrote in message news:<··································@4ax.com>...
> >
> > > The only study that I am aware of that compared Lisp and Java
> > > productivity found that the median development time with Lisp was half
> >
> > For real work Lisp might have a much bigger advantage than for
> > contests.
>
> I had the same thought. Lisp supports meta-solutions which not only pay
> off more and more in the long run, but which also require greater design
> effort up front.
> If anything a Lisper tortoise seems to be going slower than the
> hacker hare because the tortoise is still at the starting line
> building a rocket sled.
I'm so saving that as a response for the next time someone asks me
why, if I've been working on something for a day or two, my program
still can't do anything.
> This could be one small reason why cool languages are not widely
> used--how many tasks require meta-solutions, and how many programmers
> would come up with one even if the language supported such a thing?
As for the first part of the question, I think a whole lot of tasks
require meta-solutions. I think the problem is that not many of the
tasks that a beginner in a given language can solve, do. As for the
second part, a lot, once they got used to the idea of "the first thing
I do when solving this problem is figure out what sort of framework I
should build myself within which I'll do the actual solving." Until
then, though, probably very few.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
From: Kenny Tilton
Subject: Re: Comparing development effort : Lisp and functional languages versus Java.
Date:
Message-ID: <3C2E7012.641281C6@nyc.rr.com>
"Thomas F. Burdick" wrote:
>
> Kenny Tilton <·······@nyc.rr.com> writes:
>
> > If anything a Lisper tortoise seems to be going slower than the
> > hacker hare because the tortoise is still at the starting line
> > building a rocket sled.
>
> I'm so saving that as a response for the next time someone asks me
> why, if I've been working on something for a day or two, my program
> still can't do anything.
Might not help. I once was brought in as a per diem consultant on a
COBOL project, first assignment was to make a browser-style app covering
nineteen nodes in a tree. I did not go for a fully table-driven
solution, but I did use COPY...REPLACING to the max so a single source
yielded all 19 browsers.
One Monday the project lead complained he had not even seen the first
screen yet. Reminded that i was working on all 19--the lead knew from
the get-go I was doing all-in-one -- he said good but he had to see the
first screen by Friday or else. Of course I gave him all nineteen. He
responded, "That's great, if it's true."
He then took the source home and the next day said he could not
understand it, so they might not be able to use it. At least he laughed
when I closed my eyes and banged my head against the wall.
Then we had a code review with another manager to see if the code could
be understood. 45 min, no questions, and when I was done the other
manager said, "pretty obvious stuff". |<:( |<:(
I agreed, pretty obvious, something anyone including the lead could have
done if they had reached that high. OTOH, the lead would see it as
venturing into the unknown when cloning one source 18 times (and
revisiting all 19 for any change/fix to the core) yields to
gruntwork--lots of it, but mindless so...wait for it.../safe/.
Programming is hard, yet the culture of corporate in-house development
has the Lone Programmer out there with Their head to be cut off if Their
code fails. Without the encouragement to try high-wire acts, few get the
experience of succeeding at same. Without that experience, the risk of
never getting ignition on that rocket is too great, esp. when the
gruntwork is a slam dunk.
The fun thing about what we are doing here at CliniSys is that there is
no gruntwork solution, one reason why no one has built the app we have
now. The app is a throw-away app; use it once (possibly for a few years)
then throw it away. But we want to sell hundreds a year, so we /had/ to
create a meta-app.
But that gets back to: how many tasks are like that? I do not know.
Perhaps they are out there waiting for the technology to catch up, just
as the CliniSys app is something the industry has been laying seige to
for many futile years. If so, the future is bright for Lisp and other
dynamic, reflexive, GCed languages with generic functions, procedural
macros and lots of parentheses.
kenny
clinisys
From: Brian P Templeton
Subject: Re: Comparing development effort : Lisp and functional languages versus Java.
Date:
Message-ID: <87wuyzca2z.fsf@tunes.org>
Kenny Tilton <·······@nyc.rr.com> writes:
> Software Scavenger wrote:
>>
>> israel r t <········@optushome.com.au> wrote in message news:<··································@4ax.com>...
>>
>> > The only study that I am aware of that compared Lisp and Java
>> > productivity found that the median development time with Lisp was half
>>
>> For real work Lisp might have a much bigger advantage than for
>> contests.
>
> I had the same thought. Lisp supports meta-solutions which not only pay
> off more and more in the long run, but which also require greater design
> effort up front. If anything a Lisper tortoise seems to be going slower
> than the hacker hare because the tortoise is still at the starting line
> building a rocket sled.
>
Considering the places where hacker culture originated, and assuming
that absenting alliterations is allowably acceptable, would `loser
hare' be a better phrase here?
(Other than that minor detail, I'm also saving this remark, probably
in my fortunes file.)
> This could be one small reason why cool languages are not widely
> used--how many tasks require meta-solutions, and how many programmers
> would come up with one even if the language supported such a thing?
>
> kt
--
BPT <···@tunes.org> /"\ ASCII Ribbon Campaign
backronym for Linux: \ / No HTML or RTF in mail
Linux Is Not Unix X No MS-Word in mail
Meme plague ;) ---------> / \ Respect Open Standards
From: Kenny Tilton
Subject: Re: Comparing development effort : Lisp and functional languagesversus Java.
Date:
Message-ID: <3C35466D.1E835E42@nyc.rr.com>
Brian P Templeton wrote:
>
> Kenny Tilton <·······@nyc.rr.com> writes:
>
> Considering the places where hacker culture originated, and assuming
> that absenting alliterations is allowably acceptable, would `loser
> hare' be a better phrase here?
Right, that usage is off base, unfortunately because I have my own
personal definition for "hacker" -- never a good thing when one wants to
communicate. It's just that when I regard the code of hoi polloi the
image of someone editing code with a machete springs to mind.
Curious, I sought and found on
http://www.webopedia.com/TERM/H/hacker.html
"hacker -- A slang term for a computer enthusiast, i.e., a person who
enjoys learning programming languages and computer systems and can often
be considered an expert on the subject(s). Among professional
programmers, depending on how it used, the term can be either
complimentary or derogatory, although it is developing an increasingly
derogatory connotation. The pejorative sense of hacker is becoming more
prominent largely because the popular press has coopted the term to
refer to individuals who gain unauthorized access to computer systems
for the purpose of stealing and corrupting data. Hackers, themselves,
maintain that the proper term for such individuals is cracker."
No support there, my derogatory spin was not about unauthorized access.
Though I am further alarmed to discover that the meaning I most closely
associate with "hacker" (breaker in) is that of the popular press.
I get a hare of support over here:
http://searchsecurity.techtarget.com/sDefinition/0,,sid14_gci212220,00.html
" Hacker is a term used by some to mean "a clever programmer" and by
others, especially journalists or their editors, to mean "someone who
tries to break into computer systems."
1) Eric Raymond, compiler of The New Hacker's Dictionary, defines a
hacker as a clever programmer. A "good hack" is a clever solution to a
programming problem and "hacking" is the act of doing it. Raymond lists
five possible characteristics that qualify one as a hacker, which we
paraphrase here:
A person who enjoys learning details of a programming language or
system
A person who enjoys actually doing the programming rather than just
theorizing about it
A person capable of appreciating someone else's hacking
A person who picks up programming quickly
A person who is an expert at a particular programming language or
system, as in "UNIX hacker" ...."
The support I see is in the association with "clever", which I also
consider a pejorative when it comes to programming. Quoth Spinal Tap:
"It's a fine line between clever..." "...and stupid."
I guess what I need is a word for craftless programmers. Wait, hang on:
From none other than http://www.tuxedo.org/~esr/jargon/
"hacker n.
[originally, someone who makes furniture with an axe] 1. A person who
enjoys exploring the details of programmable systems and how to stretch
their capabilities, as opposed to most users, who prefer to learn only
the minimum necessary. 2. One who programs enthusiastically (even
obsessively) or who enjoys programming rather than just theorizing about
programming. ...."
Makes furniture with an axe. I use that metaphor all the time. Also
lumberjack vs cabinetmaker. But it is hard to see lumberjack as an
insult, they're OK, they sleep all night and they work all day.
Suggestions for terms to denote craftless programmers still welcome, not
necessarily alliterative with hare.
"butcher"? The brits use "cowboy" in some unflattering sense. Others?
kenny
clinisys
From: Brian P Templeton
Subject: Re: Comparing development effort : Lisp and functional languagesversus Java.
Date:
Message-ID: <878zbc1pw0.fsf@tunes.org>
Kenny Tilton <·······@nyc.rr.com> writes:
> Brian P Templeton wrote:
>>
>> Kenny Tilton <·······@nyc.rr.com> writes:
>>
>> Considering the places where hacker culture originated, and assuming
>> that absenting alliterations is allowably acceptable, would `loser
>> hare' be a better phrase here?
>
> Right, that usage is off base, unfortunately because I have my own
> personal definition for "hacker" -- never a good thing when one wants to
> communicate. It's just that when I regard the code of hoi polloi the
> image of someone editing code with a machete springs to mind.
>
> Curious, I sought and found on
> http://www.webopedia.com/TERM/H/hacker.html
>
> "hacker -- A slang term for a computer enthusiast, i.e., a person who
> enjoys learning programming languages and computer systems and can often
> be considered an expert on the subject(s). Among professional
> programmers, depending on how it used, the term can be either
> complimentary or derogatory, although it is developing an increasingly
> derogatory connotation. The pejorative sense of hacker is becoming more
> prominent largely because the popular press has coopted the term to
> refer to individuals who gain unauthorized access to computer systems
> for the purpose of stealing and corrupting data. Hackers, themselves,
> maintain that the proper term for such individuals is cracker."
>
> No support there, my derogatory spin was not about unauthorized access.
> Though I am further alarmed to discover that the meaning I most closely
> associate with "hacker" (breaker in) is that of the popular press.
>
That's an incorrect meaning, IMO. The word `hacker' has been around
for a very long time (maybe the 1950s or 1960s), and the media's
misdefinition began only recently (partly due to the book _Hackers_!).
Also, if I had to choose one place where the meaning of hacker
originated, I would probably select MIT (TMRC and the AI Lab),
although that's only my opinion.
> I get a hare of support over here:
> http://searchsecurity.techtarget.com/sDefinition/0,,sid14_gci212220,00.html
>
> " Hacker is a term used by some to mean "a clever programmer" and by
> others, especially journalists or their editors, to mean "someone who
> tries to break into computer systems."
>
> 1) Eric Raymond, compiler of The New Hacker's Dictionary, defines a
> hacker as a clever programmer. A "good hack" is a clever solution to a
> programming problem and "hacking" is the act of doing it. Raymond lists
> five possible characteristics that qualify one as a hacker, which we
> paraphrase here:
>
> A person who enjoys learning details of a programming language or
> system
> A person who enjoys actually doing the programming rather than just
> theorizing about it
> A person capable of appreciating someone else's hacking
> A person who picks up programming quickly
> A person who is an expert at a particular programming language or
> system, as in "UNIX hacker" ...."
>
> The support I see is in the association with "clever", which I also
> consider a pejorative when it comes to programming. Quoth Spinal Tap:
> "It's a fine line between clever..." "...and stupid."
>
`Clever' doesn't *always* mean `bad', `stupid', or `hairy'. I've seen
some clever and ``airy'' programs.
> I guess what I need is a word for craftless programmers. Wait, hang on:
>
> From none other than http://www.tuxedo.org/~esr/jargon/
>
> "hacker n.
>
> [originally, someone who makes furniture with an axe] 1. A person who
> enjoys exploring the details of programmable systems and how to stretch
> their capabilities, as opposed to most users, who prefer to learn only
> the minimum necessary. 2. One who programs enthusiastically (even
> obsessively) or who enjoys programming rather than just theorizing about
> programming. ...."
>
> Makes furniture with an axe. I use that metaphor all the time. Also
> lumberjack vs cabinetmaker. But it is hard to see lumberjack as an
> insult, they're OK, they sleep all night and they work all day.
>
> Suggestions for terms to denote craftless programmers still welcome, not
> necessarily alliterative with hare.
>
How about `loser'?
______________
____/ `dict loser' \__________________________________________________
| [...]
| From Jargon File (4.0.0/24 July 1996) [jargon]:
|
| loser /n./ An unexpectedly bad situation, program,
| programmer, or person. Someone who habitually loses. (Even
^^^^^^^^^^
| winners can lose occasionally.) Someone who knows not and knows
| not that he knows not. Emphatic forms are `real loser', `total
| loser', and `complete loser' (but not **`moby loser', which
| would be a contradiction in terms). See {luser}.
|_____________________________________________________________________
> "butcher"? The brits use "cowboy" in some unflattering sense. Others?
>
> kenny
> clinisys
--
BPT <···@tunes.org> /"\ ASCII Ribbon Campaign
backronym for Linux: \ / No HTML or RTF in mail
Linux Is Not Unix X No MS-Word in mail
Meme plague ;) ---------> / \ Respect Open Standards
Brian P Templeton <···@tunes.org> writes:
> Kenny Tilton <·······@nyc.rr.com> writes:
[ in an on-line encyclopedia ]
> > Hackers, themselves, maintain that the proper term for such
> > individuals is cracker."
It's just too bad (no, actually I think it's a good thing) that people
don't use the word "cracker" that way. It's really not possible to
resurrect sords from slave days without their offensive connotations,
and I'm amazed that people actually try.
> > No support there, my derogatory spin was not about unauthorized access.
> > Though I am further alarmed to discover that the meaning I most closely
> > associate with "hacker" (breaker in) is that of the popular press.
>
> That's an incorrect meaning, IMO.
No, it's absolutely correct. Words can have multiple, even
contradictory meanings. That's the way languages work.
> The word `hacker' has been around for a very long time (maybe the
> 1950s or 1960s), and the media's misdefinition began only recently
> (partly due to the book _Hackers_!). Also, if I had to choose one
> place where the meaning of hacker originated, I would probably
> select MIT (TMRC and the AI Lab), although that's only my opinion.
So? Although that is _one_ meaning of the word, it's not the only
one. It doesn't really matter that you don't approve of the people
using "hacker" in a pejorative sense, the fact is that it is used that
way, and that's probably the most common usage.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
···@conquest.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
> Brian P Templeton <···@tunes.org> writes:
>
> > Kenny Tilton <·······@nyc.rr.com> writes:
>
> [ in an on-line encyclopedia ]
> > > Hackers, themselves, maintain that the proper term for such
> > > individuals is cracker."
> It's just too bad (no, actually I think it's a good thing) that
> people don't use the word "cracker" that way. It's really not
> possible to resurrect sords from slave days without their offensive
> connotations, and I'm amazed that people actually try.
Hum? Maybe the word was used that way in your little part of the
world, but not around here, and not around most of the planet. About
95% of the planet never experienced the US Civil War, and find it very
strange how your 5% seem to want to control the design of
international languages based on your past hang-ups.
--
(reverse (concatenate 'string ··········@" "enworbbc"))
http://www3.sympatico.ca/cbbrowne/advocacy.html
All generalizations are false, including this one.
········@acm.org writes:
> ···@conquest.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
> > Brian P Templeton <···@tunes.org> writes:
> >
> > > Kenny Tilton <·······@nyc.rr.com> writes:
> >
> > [ in an on-line encyclopedia ]
> > > > Hackers, themselves, maintain that the proper term for such
> > > > individuals is cracker."
>
> > It's just too bad (no, actually I think it's a good thing) that
> > people don't use the word "cracker" that way. It's really not
> > possible to resurrect sords from slave days without their offensive
> > connotations, and I'm amazed that people actually try.
>
> Hum? Maybe the word was used that way in your little part of the
> world, but not around here, and not around most of the planet. About
> 95% of the planet never experienced the US Civil War, and find it very
> strange how your 5% seem to want to control the design of
> international languages based on your past hang-ups.
Most of the planet are not native English speakers. Of around 400
million, 250 million live in North America. Not to mention that this
is a self-conscious attempt to create a meaning for a word, not a
spontaneous new usage. And I'm pretty sure most of its proponents are
in North America. If the word "cracker" had come about in another
country with the meaning its proponents want, I would object much
less, although I would still warn people that it's an offensive word
in North America, out of courtesy. If someone takes a pejoritive
race-class term, and tries to invent a new pejoritive meaning for it,
I hardly think it's unreasonable to object, and I certainly wouldn't
call it trying to "control the design of [an] international language
based on past hang-ups." The word comes from slavery time, but it's a
slur here and now.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
From: Ray Dillinger
Subject: Re: Comparing development effort : Lisp and functional languagesversus Java.
Date:
Message-ID: <3C38BEEC.41ABFBCC@sonic.net>
"Thomas F. Burdick" wrote:
>
> It's just too bad (no, actually I think it's a good thing) that people
> don't use the word "cracker" that way. It's really not possible to
> resurrect sords from slave days without their offensive connotations,
> and I'm amazed that people actually try.
>
Wow. The connotation to me was always
breaks (into) stuff
--> breaking
--> cracking
-->cracker.
I never made a connection to the derogatory for slaveowner until
you just mentioned it. It doesn't fit the use, applied to people
who are breaking things. If the term had been applied in the
context of people using the law for coercion or repression of
others, (such as the MPAA, RIAA, Adobe, Microsoft, etc) it would
fit the slaveowner connotation of "cracker". But that's not the
use we're seeing.
Like you say, words can have different (even contradictory) meanings.
Bear
From: Kenny Tilton
Subject: Re: Comparing development effort : Lisp and functionallanguagesversus Java.
Date:
Message-ID: <3C382FA7.F225BF31@nyc.rr.com>
Brian P Templeton wrote:
>
> How about `loser'?
Chess has a great word: patzer. Yiddish. Translated as "wood-pusher".
Exactly the right connotation I am after.
We could translate to "typist", or borrow patzer/woodpusher.
kenny
clinisys
From: Dorai Sitaram
Subject: Re: Comparing development effort : Lisp and functional languagesversus Java.
Date:
Message-ID: <a19qg4$qoq$1@news.gte.com>
In article <··············@tunes.org>,
Brian P Templeton <···@tunes.org> wrote:
>Kenny Tilton <·······@nyc.rr.com> writes:
>
>> I guess what I need is a word for craftless programmers. Wait, hang on:
>>
>> From none other than http://www.tuxedo.org/~esr/jargon/
>>
>> "hacker n. ...
>>
>> Suggestions for terms to denote craftless programmers still welcome, not
>> necessarily alliterative with hare.
>>
>How about `loser'?
> ______________
>____/ `dict loser' \__________________________________________________
>| [...]
>| From Jargon File (4.0.0/24 July 1996) [jargon]:
>|
>| loser /n./ An unexpectedly bad situation, program,
>| programmer, or person. Someone who habitually loses. (Even
> ^^^^^^^^^^
>| winners can lose occasionally.) Someone who knows not and knows
>| not that he knows not. Emphatic forms are `real loser', `total
>| loser', and `complete loser' (but not **`moby loser', which
>| would be a contradiction in terms). See {luser}.
>|_____________________________________________________________________
>
The cycling community has a (not always pejorative)
term for people who ride bicycles but are not adept at
it the way a dedicated cyclist is. That term is POB,
for Person On Bicycle. Rhymes with "Bob".
That suggests PUPL, Person Using Programming Language,
with a choice of at least three possible pronunciations
(pupil, pupple, poople) that usefully vary in the
amount of judgmentalness they pack.
--d
>
> The cycling community has a (not always pejorative)
> term for people who ride bicycles but are not adept at
> it the way a dedicated cyclist is. That term is POB,
> for Person On Bicycle. Rhymes with "Bob".
>
> That suggests PUPL, Person Using Programming Language,
> with a choice of at least three possible pronunciations
> (pupil, pupple, poople) that usefully vary in the
> amount of judgmentalness they pack.
>
> --d
The chess community has a word that really fits, I think. I am not
sure if POB has the same connotation... In chess, the term 'patzer'
basically means what I think of when I think of a "craftless
programmer"... It is not necessarily pejorative (I, for example, am a
patzer, in that I have no deep understanding/knowledge of the game,
but this does not prevent me from enjoying it)
From: Kenny Tilton
Subject: Re: Comparing development effort : Lisp and functional languagesversus Java.
Date:
Message-ID: <3C38946F.DE42655B@nyc.rr.com>
Dr Pibb wrote:
> The chess community has a word that really fits, I think. I am not
> sure if POB has the same connotation... In chess, the term 'patzer'
> basically means what I think of when I think of a "craftless
> programmer"... It is not necessarily pejorative ....
yeah, i was going to say that patzer has a tolerant warmth to it which
might come in handy when i want to critique a co-worker. "loser"
OTOH.... :)
kenny
clinisys
From: Michael Schuerig
Subject: Re: Comparing development effort : Lisp and functional languagesversus Java.
Date:
Message-ID: <a1rvh8$aqf$06$1@news.t-online.com>
Kenny Tilton wrote:
> Dr Pibb wrote:
>> The chess community has a word that really fits, I think. I am not
>> sure if POB has the same connotation... In chess, the term 'patzer'
>> basically means what I think of when I think of a "craftless
>> programmer"... It is not necessarily pejorative ....
>
> yeah, i was going to say that patzer has a tolerant warmth to it which
> might come in handy when i want to critique a co-worker. "loser"
> OTOH.... :)
You might call them dilettantes. Then they might even understand what
you're trying to say...
Michael
--
Michael Schuerig GPG Fingerprint
···············@acm.org DA28 7DEB 5856 3365 BED9
http://www.schuerig.de/michael/ 8365 0A30 545A 82D2 05D7
From: Kenny Tilton
Subject: Re: Comparing development effort : Lisp and functional languagesversus Java.
Date:
Message-ID: <3C41AB64.2B8AEF7B@nyc.rr.com>
Michael Schuerig wrote:
>
> Kenny Tilton wrote:
>
> > Dr Pibb wrote:
> >> The chess community has a word that really fits, I think. I am not
> >> sure if POB has the same connotation... In chess, the term 'patzer'
> >> basically means what I think of when I think of a "craftless
> >> programmer"... It is not necessarily pejorative ....
> >
> > yeah, i was going to say that patzer has a tolerant warmth to it which
> > might come in handy when i want to critique a co-worker. "loser"
> > OTOH.... :)
>
> You might call them dilettantes. Then they might even understand what
> you're trying to say...
I live in NYC...Yiddish is our second language.
And I'll be happy to break down "wood-pusher" for the others. :)
Dilettante isn't quite what I am after; these oafs perform craftlessly
with great energy and earnestness.
kenny
clinisys
From: Eric Moss
Subject: Re: Comparing development effort : Lisp and functional languagesversus Java.
Date:
Message-ID: <3C425623.80288CA9@alltel.net>
Kenny Tilton wrote:
> Dilettante isn't quite what I am after; these oafs perform craftlessly
> with great energy and earnestness.
"manager"
;)
Eric
On Sun, 13 Jan 2002 21:53:07 -0600, Eric Moss <········@alltel.net>
wrote:
>Kenny Tilton wrote:
>
>> Dilettante isn't quite what I am after; these oafs perform craftlessly
>> with great energy and earnestness.
>
>"manager"
CIO or CTO
-------------------
Direct all spam to:
·········@whitehouse.gov, ··············@whitehouse.gov,
·····@aol.com,·······@aol.com,
·····@yahoo.com, ·····@hotmail.com, ·····@msn.com,
·····@cia.gov , ·····@sprint.com, ·····@earthlink.com, ···@ftc.gov, ·······@spamcop.net
From: Kenny Tilton
Subject: Re: Comparing development effort : Lisp and functional languagesversus Java.
Date:
Message-ID: <3C42F16F.832CFB6D@nyc.rr.com>
israel r t wrote:
>
> On Sun, 13 Jan 2002 21:53:07 -0600, Eric Moss <········@alltel.net>
> wrote:
>
> >Kenny Tilton wrote:
> >
> >> Dilettante isn't quite what I am after; these oafs perform craftlessly
> >> with great energy and earnestness.
> >
> >"manager"
>
> CIO or CTO
watch it, buster.
kenny, cto
clinisys
p.s. i was going to be chief software architect so i could have as much
money as bill, but someone said it did not work that way
From: Kenny Tilton
Subject: Re: Comparing development effort : Lisp and functionallanguagesversus Java.
Date:
Message-ID: <3C3871FA.C43C6D45@nyc.rr.com>
Dorai Sitaram wrote:
>
> In article <··············@tunes.org>,
> Brian P Templeton <···@tunes.org> wrote:
> >Kenny Tilton <·······@nyc.rr.com> writes:
> >
> >> I guess what I need is a word for craftless programmers. Wait, hang on:
> The cycling community has a (not always pejorative)
> term for people who ride bicycles but are not adept at
> it the way a dedicated cyclist is. That term is POB,
> for Person On Bicycle. Rhymes with "Bob".
>
> That suggests PUPL, Person Using Programming Language,
or PUK, person using keyboard?
k
c
In article <··············@tunes.org>, Brian P Templeton wrote:
>That's an incorrect meaning, IMO. The word `hacker' has been around
>for a very long time (maybe the 1950s or 1960s), and the media's
>misdefinition began only recently (partly due to the book _Hackers_!).
You can't entirely blame the media. One problem is that it is the
crackers who refer to themselves as hackers, and they've been doing
that for over twenty years.
From: Friedrich Dominicus
Subject: Re: Comparing development effort : Lisp and functional languagesversus Java.
Date:
Message-ID: <873d1i1xpb.fsf@frown.here>
Brian P Templeton <···@tunes.org> writes:
> >
> That's an incorrect meaning, IMO. The word `hacker' has been around
> for a very long time (maybe the 1950s or 1960s), and the media's
> misdefinition began only recently (partly due to the book
_Hackers_!).
Don't know about what Hackers book you're talking. In Stephen Levys
book is is used in the sense, Hacker someone trying to understand
things and get them running. Well not always for legal purposes.
Friedrich
From: Patrick May
Subject: Re: Comparing development effort : Lisp and functional languages versus Java.
Date:
Message-ID: <m3pu4yqlb9.fsf@dagney.spe.com>
israel r t <········@optushome.com.au> writes:
> On Fri, 28 Dec 2001 14:10:18 GMT, Erik Naggum <····@naggum.net> wrote:
> > it is hard for someone who hires programmers by the truckload to
> > believe that one CL wizard can do the work of at least 10 Java
> > men.
>
> Is there any objective evidence for this statement ?
I noticed the following on the Haskell site,
http://www.haskell.org/aboutHaskell.html:
Haskell, a purely functional programming language, offers you:
- Substantially increased programmer productivity (Ericsson
measured an improvement factor of between 9 and 25 in one
set of experiments on telephony software).
I didn't dig further, but since it is Ericsson, I'd guess they were
using Erlang rather than Haskell or Common Lisp. Nonetheless, it may
be an interesting data point regarding productivity of functional
versus other paradigms in at least one application domain.
Regards,
Patrick
------------------------------------------------------------------------
S P Engineering, Inc. | The experts in large scale distributed OO
| systems design and implementation.
···@spe.com | (C++, Java, ObjectStore, Oracle, CORBA, UML)
On 29 Dec 2001 13:10:02 +0100, Patrick May <···@spe.com> wrote:
>> Is there any objective evidence for this statement ?
>
> I noticed the following on the Haskell site,
>http://www.haskell.org/aboutHaskell.html:
>
> Haskell, a purely functional programming language, offers you:
> - Substantially increased programmer productivity (Ericsson
> measured an improvement factor of between 9 and 25 in one
> set of experiments on telephony software).
>
>I didn't dig further, but since it is Ericsson, I'd guess they were
>using Erlang rather than Haskell or Common Lisp.
Many thanks.
I'll check the Erlang site and will post anything interesting I find
there.
On 29 Dec 2001 13:10:02 +0100, Patrick May <···@spe.com> wrote:
>I didn't dig further, but since it is Ericsson, I'd guess they were
>using Erlang rather than Haskell or Common Lisp. Nonetheless, it may
>be an interesting data point regarding productivity of functional
>versus other paradigms in at least one application domain.
Further to Erlangs productivity, I found an interesting article by Ulf
Wiger "Four-fold Increase in Productivity and Quality :
Industrial-Strength Functional Programming" at
http://www.erlang.se/publications/Ulf_Wiger.pdf
Once again, many thanks.
From: Stephan Tolksdorf
Subject: Re: Comparing development effort : Lisp and functional languages versus Java.
Date:
Message-ID: <a0kfft$2ki$03$1@news.t-online.com>
"israel r t" <········@optushome.com.au> schrieb im Newsbeitrag
·······································@4ax.com...
> On Fri, 28 Dec 2001 14:10:18 GMT, Erik Naggum <····@naggum.net> wrote:
>
> > CL programmers who want to work for money have to be _good_, as they
stand on their own.
> > Java programmers can be amazingly incompetent and ignorant and still
get
> > jobs, because they rely on so many others around them.
>
> > it is hard for someone who hires programmers by the truckload to
believe
> > that one CL wizard can do the work of at least 10 Java men.
>
> Is there any objective evidence for this statement ?
>
> The only study that I am aware of that compared Lisp and Java
> productivity found that the median development time with Lisp was half
> of the development time with Java . While this is good, it does not
> translate into a 10 : 1 advantage.
It is hard to make statements about productivity gains through the use of
certain languages. Something any experienced coder will agree upon is that
"good" programmers do have a productivity that is 10 times higher (or even
higher) than the productivity of a quite incompetent one. I think this
productivity difference is pretty seldom in other fields of the industry.
Keeping apart both effects makes judging language productivity hard.
Stephan
"Stephan Tolksdorf" <········@gmx.de> wrote in message news:<···············@news.t-online.com>...
> It is hard to make statements about productivity gains through the use of
> certain languages. Something any experienced coder will agree upon is that
> "good" programmers do have a productivity that is 10 times higher (or even
> higher) than the productivity of a quite incompetent one. I think this
> productivity difference is pretty seldom in other fields of the industry.
> Keeping apart both effects makes judging language productivity hard.
Productivity has to be defined better before we can even say that much
about it. The best programmers write much better programs. It
doesn't make much sense to compare those programs against inferior
programs on the basis of development speed. We have to take
maintenance into account, and how well the program meets the needs of
the users. Thus a 10-to-1 ratio of development speed might actually
be a 100-to-1 ratio of overall productivity.
It might also be useful to consider the productivity of large groups
of programmers working together. Their management and policies become
major factors. It seems to me that the management, policies, and
average level of skill and talent, are all likely to be much better
for a typical Lisp team than for a typical Java team. Thus the team
productivity might actually have a ratio of 1000 to 1, or some such
extreme.
Such factors might have made Lisp a lot more popular by now, except
for one big obstacle. When Lisp was first becoming somewhat popular
and well known in the 1980's, the average computer did not have enough
power to make the best use of it. From that and from other factors,
it gained a reputation as a purely academic language which was
considered useless for real work. Now it seems to be finally
overcoming that reputation, and may have a much better future.
From: Ray Dillinger
Subject: Re: Comparing development effort : Lisp and functional languages versus Java.
Date:
Message-ID: <3C2F81F7.9286277C@sonic.net>
Stephan Tolksdorf wrote:
> It is hard to make statements about productivity gains through the use of
> certain languages. Something any experienced coder will agree upon is that
> "good" programmers do have a productivity that is 10 times higher (or even
> higher) than the productivity of a quite incompetent one. I think this
> productivity difference is pretty seldom in other fields of the industry.
> Keeping apart both effects makes judging language productivity hard.
An interesting corollary of which is that if you can identify
a language that is preferred by a community of very good programmers,
and almost nobody else, you should be able to attract a cadre of
very good programmers by offering jobs working with that language.
Bear
(mindful of the crossposts, but allowing the
crossposting as this is in fact relevant to
all the newsgroups involved.)
From: Kent M Pitman
Subject: Re: Comparing development effort : Lisp and functional languagesversus Java.
Date:
Message-ID: <sfwell4xi7j.fsf@shell01.TheWorld.com>
[ replying to comp.lang.lisp only
http://world.std.com/~pitman/pfaq/cross-posting.html ]
Brian P Templeton <···@tunes.org> writes:
> ...The word `hacker' has been around
> for a very long time (maybe the 1950s or 1960s), and the media's
> misdefinition began only recently (partly due to the book _Hackers_!).
> Also, if I had to choose one place where the meaning of hacker
> originated, I would probably select MIT (TMRC and the AI Lab),
> although that's only my opinion.
When I got to the MIT AI Lab in 1978, this term was already in full use.
E.g., everyone's user info (INQUIR entry, feeding what FINGER/WHOIS would
show if you asked for long-form info about a user) had a field that said
"Hacking ... for ... " where they were to enter a project name in the
first part and a supervisor name in the second part. One was supposed to
say "Hacking parsers for Winston" though it was common to abuse the fields
to jokingly pervert things to say "Hacking small animals into little pieces
for lunch" or some such; yet such uses were always playing on the machete
kind of English use for humor, and were never part of the hacker-culture
meaning.
I have never seen it written down the way I understood it, but the
best way I can account for the myriad meanings of hacker that I saw at
the time was simply that "to hack" was a synonym for "to do", "a hack"
was "a deed", and "hacking" meant "doing". A great hacker would be
like a Doer, that is, one who does great deeds (worthy perhaps of
capitalization or empahasis). A "good hack" was a "deed well done".
I believe this simple interpretation is adequate to subsume all the other
more complex definitions that dance around but never quite span the full
space of meanings.
My understanding of how the confusion arose was a confusion of observation
of use with definition of use. Someone said, "who did that?" and the answer
was "those hackers". The person not knowing the word "hackers" presumably
thought this was a designation of the particular deed done, not a mere
term of designation with no correllation. It was repeated "Hackers did
blah blah" with a total lack of understanding of the utter vacuuousness
and/or internal redundancy of having said "doers did blah blah".
This is how language travels and myths arise. A giant game of "telephone",
each connection erasing a little bit of meaning.
Eric Raymond's association of the term with programming is an after-the-fact
interpretation that loses a great deal of the generality of the term as it
was in common use.
A person would simply enter a room and say "What are you hacking?" meaning
"what are you doing?" but not in a challenging sense. It had the sense of
"What's up?"
The reason I like the term "do" is that it captures the entire essence of
purpose in hacking--that its goal was merely the doing. Whether it was
translating the Bible into Klingon or getting a cow onto the top of the
Great Dome of MIT.
And, to my knowledge, it just about NEVER referred to anything related to
UNIX. That's historical revisionism on Raymond's part, IMO, because he was
too afraid to name the operating systems of the time and instead wanted to
say something anachronistic that would give a modern reader the sense of
what was revered back then.
In article <················@naggum.net>, Erik Naggum <····@naggum.net>
wrote:
> * Nils Kassube <····@kassube.de>
> | You mean economic reasons like e.g. "Who's going to maintain your
> | smart Lisp solution if you're hit by a bus?" Mindshare and the number
> | of available programmers _are_ important.
>
> That is why a smart Common Lisp programmer knows at least two
> other Common Lisp programmers who are willing to take over the
> code if he dies or whatever. Actually having an answer to this
> rhetorical question tends to blow the minds of those who ask it.
> Just because there are more C++ or Java programmers in the world,
> does not mean that you can find one that will _actually_ be able
> to take over a non-trivial project.
It's hardly an issue anyway, outside of the mind of a manager. If the
program is more than a few thousand lines then understanding *it* is
likely to be far more difficult than understanding the programming
language in which it is written. The programming language has the
advantage that it is likely to be well documented. And probably makes
some kind of sense, as well.
-- Bruce
Bruce Hoult <·····@hoult.org> writes:
> It's hardly an issue anyway, outside of the mind of a manager. If the
> program is more than a few thousand lines then understanding *it* is
> likely to be far more difficult than understanding the programming
> language in which it is written. The programming language has the
> advantage that it is likely to be well documented. And probably makes
> some kind of sense, as well.
Yes, and kudos to Kent and others who have worked to make CL
documentation so excellent!
When we bring in relative newbies to CL and have them start hacking,
presenting them with the hyperspec, a copy of ANSI CL from Graham, and
Sonya Keene's CLOS book covers alot of the questions. What I love
about all of these docs is that they aren't fluffy and over-verbose
like the O'Reilly stuff can get, nor are they overwhelming and dense.
The HyperSpec is such an impressive document too, that it gives the
newbie some confidence going forward into the unknown parts of the
language.
One thing I think is missing is something of a development guide that
gives people a better understanding of how the REPL works, how to
organize code in files (or elsewhere), how to start debugging, how to
track down common types of errors, and what some of the
pitfalls/advantages of peicemeal compilation are.
I also think a CL Hacker's Journal would be nice, a collation of news
and perhaps some extracts from c.l.l (which IMO has a good signal to
noie ratio).
Are there any people working in those directions? I recall someone
asking about such a journal on #lisp the other day.
--
Craig Brozefsky <·····@red-bean.com>
http://www.red-bean.com/~craig
Ask me about Common Lisp Enterprise Eggplants at Red Bean!
Craig Brozefsky <·····@red-bean.com> writes:
> Bruce Hoult <·····@hoult.org> writes:
>
>> It's hardly an issue anyway, outside of the mind of a manager. If the
>> program is more than a few thousand lines then understanding *it* is
>> likely to be far more difficult than understanding the programming
>> language in which it is written. The programming language has the
>> advantage that it is likely to be well documented. And probably makes
>> some kind of sense, as well.
>
> Yes, and kudos to Kent and others who have worked to make CL
> documentation so excellent!
>
> When we bring in relative newbies to CL and have them start hacking,
> presenting them with the hyperspec, a copy of ANSI CL from Graham, and
> Sonya Keene's CLOS book covers alot of the questions. What I love
> about all of these docs is that they aren't fluffy and over-verbose
> like the O'Reilly stuff can get, nor are they overwhelming and dense.
> The HyperSpec is such an impressive document too, that it gives the
> newbie some confidence going forward into the unknown parts of the
> language.
>
> One thing I think is missing is something of a development guide that
> gives people a better understanding of how the REPL works, how to
> organize code in files (or elsewhere), how to start debugging, how to
> track down common types of errors, and what some of the
> pitfalls/advantages of peicemeal compilation are.
>
> I also think a CL Hacker's Journal would be nice, a collation of news
> and perhaps some extracts from c.l.l (which IMO has a good signal to
> noie ratio).
>
> Are there any people working in those directions? I recall someone
> asking about such a journal on #lisp the other day.
>
There is something similar to that in the CLiki (I don't remember the
name, though).
> --
> Craig Brozefsky <·····@red-bean.com>
> http://www.red-bean.com/~craig
> Ask me about Common Lisp Enterprise Eggplants at Red Bean!
--
BPT <···@tunes.org> /"\ ASCII Ribbon Campaign
backronym for Linux: \ / No HTML or RTF in mail
Linux Is Not Unix X No MS-Word in mail
Meme plague ;) ---------> / \ Respect Open Standards
Brian P Templeton <···@tunes.org> writes:
> > I also think a CL Hacker's Journal would be nice, a collation of
> > news and perhaps some extracts from c.l.l (which IMO has a good
> > signal to noie ratio).
> >
> > Are there any people working in those directions? I recall
> > someone asking about such a journal on #lisp the other day.
> >
> There is something similar to that in the CLiki (I don't remember the
> name, though).
<http://ww.telent.net/cliki/Free The X3J Thirteen>
Edi.
Bruce Hoult wrote:
>It's hardly an issue anyway, outside of the mind of a manager.
Sir, I am a professional manager and I must object. It is an issue, but not
with Lisp...
>If the
>program is more than a few thousand lines then understanding *it* is
>likely to be far more difficult than understanding the programming
>language in which it is written.
Unless the language is C++ (the only language that needs almost an entire
book (ISBN: 02016156220) to explain how exception processing interacts with
other portions of the language, another book (ISBN: 0201633981) to explain
its IO abstractions, and yet another book (ISBN: 0201633981) to explain
it's generic programming capabilities, all on top of its rather pathetic
language description (ISBN: 0201514591). But then, I've been using the
beast professionally since the cfront 1.0 days, so what would I know about
its hideous mishmash of features that is still able to occasionally
surprise and trap me even to this day?
>The programming language has the
>advantage that it is likely to be well documented.
Perhaps too well...
>And probably makes
>some kind of sense, as well.
See above.
faa
On Wed, 26 Dec 2001, Kaz Kylheku wrote:
> In article <··································@4ax.com>, israel r t wrote:
> >On Tue, 25 Dec 2001 23:12:51 -0800, jeff
> ><·····@houseofdistraction.com> wrote:
> >
This is me I think :)
> >>>>Well, it depends on what you want to do. If you abandon (or deprecate, or
> >>>>hide) a Lispy syntax, presumably it's because you want to please or
> >>>>placate folks who are turned off from Lispy syntaxes.
> >>>
> >>> Then you are no longer practicing technology, but psychology or politics.
> >>
> >>Successful language design is all these things.
[snip]
> >True. Unless one gets mind share ( and consequent market share )
> >language design is meaningless.
>
> That is utter nonsense.
Let me just pull things back to my original point: *if* you're going to
adopt a non-Lispy syntax specifically for the purpose of attracting (or
merely not repelling) those repelled by a Lispy syntax, *then* a
Pascal/Ada one seems unwise. This is a lesson one may draw with *some*
(non conclusive) support from the Dylan experience. This is a very
specific lesson, but one I think can be learned from Dylan, and is thus
something Dylan has to offer to Lisp :)
[snip]
> So in the end, popularity of a language is something that only matters to
> the inventor and to some tool vendors.
Well, not entirely, but that is perfectly consistent with my point and
with the thread until now, since the question I was trying to answer is
"Does Dylan have any lessons to offer for those designing a new Lisp?"
> To the developer, it provides no
> useful benefit. In fact, it is a liability. Language popularity makes the
> tool vendors complacent,
There are a lot of local market issues that come up. In some markets,
popularity forces higher competition as vendors seek to differentiate
themselves.
[snip]
> Microsoft Visual C++ is undoubtedly the most
> popular C++ implementation; perhaps not by coincidence, has the worst
> standard compliance, and is packaged in a horribly inefficient, buggy,
> unreliable development environment. There is zero motivation to do
> anything about it.
This is not a *telling* example, as 1) it's consistent with Mircorsoft's
ethos across the board, 2) you're conflating popularity of
*implementation* with popularity of *language* (well, ok, I can see a
derivation that works, but I think the *force* of this example rests on
the conflation), 3) C++ is somewhat distorting due its use and
implemenational complexity, 4) this seems to be a *monopoly* problem, not
a popularity one.
[snip]
Cheers,
Bijan Parsia.
On Wed, 26 Dec 2001, Kaz Kylheku wrote:
> In article
> <··········································@login6.isis.unc.edu>, Bijan
> Parsia wrote:
> >On 25 Dec 2001, Andreas Bogk wrote:
> >
> >> Bijan Parsia <·······@email.unc.edu> writes:
> >>
> >> > To wit, if you're going to abandone Lispy syntax, a *Pascal
> >> > like* syntax probably isn't a good idea?
> >>
> >> I don't think that introducing a Pascal-like syntax was a bad idea.
> >> Dropping the Lispy syntax was the bad idea.
> >
> >Well, it depends on what you want to do. If you abandon (or deprecate, or
> >hide) a Lispy syntax, presumably it's because you want to please or
> >placate folks who are turned off from Lispy syntaxes.
>
> Then you are no longer practicing technology, but psychology or politics.
Well, some others have responded, and I'd hoped not to get dragged back
it, but I think that if this was intended as a criticism, it was
misguided. First off, I'm not sure what "practicing
technology" means. Second, presumably when you're designing something to
be used by humans, attending to psychology is important. Third, presumably
language design, if it is practically and production oriented, has to take
account of economic and political factors. From the postings of many,
e.g., Kent Pitman, I see the design of Common Lisp very strongly governed
by the psychology, politics, and economics of its varying user base. Pure
technical "goodness" is to be weighed against lots of other things.
I was trying to suggest that there may be stuff on the *political* side
for Lisp to learn from Dylan. Is it really controversial that it's a
fairly risky move to adopt a Pascal like syntax than can't be easily
mapped back into a Lispy one? I mean, who do you win over with that move?
OTOH, given Python's growing user base (and note, python's syntax is an
*issue* for many folks; witness the whitespace wars on
comp.lang.python) there might be some lessons to draw from Dylan for
either Python (how to smoothly integrate more Common Lisp stuff into
Python) or Common Lisp (how to layer a popular syntax on top). Not that
Dylan necessarily has to have the *answers*, but even if it screwed all
these up, it might be worth examining a worked out failure.
Cheers,
Bijan Parsia.
Bijan Parsia <·······@email.unc.edu> writes:
> I was trying to suggest that there may be stuff on the *political* side
> for Lisp to learn from Dylan. Is it really controversial that it's a
> fairly risky move to adopt a Pascal like syntax than can't be easily
> mapped back into a Lispy one? I mean, who do you win over with that move?
In this post, you should know that the company Harlequin (which I'll
call then-Harlequin) is not the same as the one that persists now. It
is under all new management now, thank goodness. The new Harlequin
and its related company Xanalys, that has become the caretaker of
LispWorks, Liquid CL, and various Lisp-based problems seems to me much
better management. The critical remarks I'll make here are of a
historical nature and do not reflect any discontent with present
management. And anyway, Dylan is spun off from all of these companies and
is under its own new management...
I was originally hired by then-Harlequin by Jo Marks when the US
office had only 8 people (it later grew to about 150) to be
then-Harlequin's liaison to the Dylan design ongoing at Apple. But Jo
never told anyone else this, as far as I ever knew. And when it
became clear that the design was going to be by an internal committee,
and that every detail was going to be some sort of group vote, I just
washed my hands of it and decided not to participate at all. It was
obvious that I was going to be unhappy not only with a LOT of the
Dylan design, but even with a lot of the then-Harlequin position on
the Dylan design. You should take the rest of my remarks in the
context of the obvious bias this situation established for me.
At some point, Apple gave up on Dylan and we (then-Harlequin) hired a
lot of its staff. But a number of them (not all) brought along an
intense anti-Lisp attitude. I routinely I complained about the
syntax, for example, which I consider central to the acceptance of
Dylan. I was told over and over again that my opinion simply did not
matter. Not only were Lisp folks not a target customer, and not only
did they have bad intuitions about what the customer base needed, but
also they were an active threat to Dylan if they showed up at
conferences and appeared to be too chummy with Dylan because it wanted
to make friends with C++ folks and one did not do that by admitting
you were pals with Lispers. And disenchanted C++ folks seemed to be
the target audience.
In fact, a tactical error made by Dylan (IMO) that I have yet to see
it materially recover from was to never react to Java when it came on
the market. As nearly as I can tell, Dylan was unaffected by the
introduction of Java and that was a serious error for several tactical
reasons:
- Java took market share away from there, and hence dollars.
- Jave specifically took away disenchanted C++ people, meaning that
assuming that one's base was going to come from that set of people
was more questionable.
- Java had another take on the C++ syntax that Dylan never reacted to.
In the absence of Java, a Dylan-like syntax might be something you
could make a case for. But Java, I think, created an expectation that
people disenchanted with C++ (and perhaps later with Java) would want
a syntax very much like what they already had. The decision of Dylan
to claim to cater to C++/Java folks and yet to also be gratuitously
incompatible on points it could have agreed with was, IMO, a terrible
move. I've said a million times, there are no good and bad design
decisions, all good and bad is measured in a context. And the new context
that Java established was that maximal C++ compatibility is Good. And
Dylan has ignored this, establishing a space that is both annoying to
C++/Java and annoying to Lisp. I think this is bad.
> OTOH, given Python's growing user base (and note, python's syntax is an
> *issue* for many folks; witness the whitespace wars on
> comp.lang.python) there might be some lessons to draw from Dylan for
> either Python (how to smoothly integrate more Common Lisp stuff into
> Python) or Common Lisp (how to layer a popular syntax on top). Not that
> Dylan necessarily has to have the *answers*, but even if it screwed all
> these up, it might be worth examining a worked out failure.
I would examine it more for this. Not that I expect it to fail utterly.
But I do think it has made a wrong decision by distancing its syntax
from every possible language. It could have, and I think should have,
made at least one ally on syntax.
Java did the smart thing, and the success of movement between the language
is apparent. Dylan, I think, can be studied for the opposite effect.
I also don't really see why Dylan had to leave the Lisp community
behind on the macro issue. Yes, it wanted infix, but I don't agree that
this had to lead to leaving Lisp syntax behind. I think a way to satisfy
both could have been achieved if it were made a serious goal. I think it was
tossed as a goal because the Lisp community was tossed, and that the syntax
is a mere metaphor for the politics.
The MACSYMA language is a pretty syntactically complex language and
had no difficulty accomodating Lisp-style macros both at the
Macsyma-level and in a Lisp-compatible way. I think Dylan could have
learned some things from MACSYMA, and had I been involved, I'd have
wanted to see that looked into. But I was not involved and I so something
else happened, for better or for worse.
It is probably easy to regard my attitude as being a kind of "sour
grapes" effect, and I won't really disagree that it's possible to take
that position. But IMO the designers and more particularly the
managers responsible for Dylan were arrogant and did a lot of saying
"we can do without you", so I think they kind of have to take their
lumps on this.
Dylan came out well enough to be worth a look. And there are some
good people trying to breathe some life into it. But I don't have any
serious expectation that it will take off because I think they've so
badly botched the politics that they burnt a bridge they shouldn't
have burnt and they haven't got sufficient allies left to move ahead.
Of course, never underestimate the ability of a killer app to rescue ANY
dead language, so maybe they'll find one. But the standard shoeleather
approach to just hawking Dylan a lot of places and hoping doesn't sound
to me like a strategy likely to take the world by storm.
On Wed, 26 Dec 2001 12:52:18 -0500, Bijan Parsia
<·······@email.unc.edu> wrote:
>I was trying to suggest that there may be stuff on the *political* side
>for Lisp to learn from Dylan. Is it really controversial that it's a
>fairly risky move to adopt a Pascal like syntax than can't be easily
>mapped back into a Lispy one? I mean, who do you win over with that move?
Considering the mind share that Java, C# and C++ have, it might be
better ( from a marketing perspective ) to adopt a C like syntax,
complete with curly braces.
Bijan Parsia <·······@email.unc.edu> writes:
[...]
> non-programmers). The only remotely Pascal like syntaxed language that's
> gained traction in the past decade that I know of is Python, and it dumped
> begin/end.
[...]
There is still Ada95 which I consider quite cool. A language that
really works platform-independently (Perhaps as there is only one
free compiler.... *g*) and deserves more attention.
Regards,
Julian Stecklina
PS. I come from the PASCAL camp, so don't blame me too much. ;)
In article
<··········································@login9.isis.unc.edu>, Bijan
Parsia <·······@email.unc.edu> wrote:
> To wit, if you're going to abandone Lispy syntax, a *Pascal
> like* syntax probably isn't a good idea?
I'm not sure what you mean here. Dylan is a lot closer to Modula-2 or
Ada than to Pascal. Would you prefer a {}-rich C syntax?
Some people might prefer that -- certainly everything from Perl to Java
to Corba has adopted a C-like syntax even if the semantics are way
different.
I'm not sure this is easily compatable with an extensible syntax,
though. Dylan gets a lot of parsing certainty and error-checking out of
having definition macros and statement macros *always* ending in "end".
You could easily enough change the parser to look for } instead, but
then where would you hang the name of the macro or of the thing being
defined e.g. "end" vs "end method" vs "end foo" vs "end method foo", all
of which are automatically valid (and checked) in Dylan.
Of course Lisp gets away with just ), so maybe this error checking is
overrated.
> 3) How not to sell a language.
>
> After all, Dylan is *substationally* worse off than Common
> Lisp. Clearly, Dylan is the *much* more lost cause. One can blame
> historical circumstances (e.g., Apple's dropping the ball), but,
> after all, Dylan wasn't resiliant enough to take that blow easily.
Well dispite that Dylan hasn't gone away. The number of users is small,
but it seems to be growing. I wonder if Andreas has any stats on the
number of hits or downloads at gwydiondylan.org?
Is the number of CL users increasing? Or has it just been around a lot
longer?
Hundreds of millions of dollars being spent promoting Java at the same
time that Apple dropped the ball certainly didn't help Dylan. But
people are starting to see through that, a little.
-- Bruce
Bruce Hoult <·····@hoult.org> writes:
> Well dispite that Dylan hasn't gone away. The number of users is small,
> but it seems to be growing. I wonder if Andreas has any stats on the
> number of hits or downloads at gwydiondylan.org?
I don't have reliable download stats, since there are a lot of
mirrors, but a new release generates a few hundred downloads at the
main FTP site. The web server served about a million requests since I
keep stats (beginning October 99), and currently about 1500 pages are
requested per day.
Andreas
--
"In my eyes it is never a crime to steal knowledge. It is a good
theft. The pirate of knowledge is a good pirate."
(Michel Serres)
In article <·················@quiotix.com>, Jeffrey Siegal
<···@quiotix.com> wrote:
> Andreas Bogk wrote:
> > > I consider Lisp syntax (or something similarly elegant) to be
> > > essential. I suspect that many proponents of Dylan-like languages
> > > would
> > > consider it unacceptable. I strongly suspect there is no middle
> > > ground.
> >
> > For the language user, there may be no middle ground. From the
> > perspective of the language designer, the syntax is just one issue of
> > many, so even if you prefer S-expressions, there's still a lot of Lisp
> > to discover in Dylan.
>
> Did you mean "A lot _for_ Lisp to discover?" There is little in Dylan
> that didn't originate with Lisp, except the syntax. What does Dylan
> have that Scheme + CLOS + "a collections library" doesn't have?
Perhaps not a lot that is radical, but simply a lot of nice cleaning up.
- having a "let" where the scope is implicit (to the end of the current
progn) is a big win in unclutering code
- Dylan's ":=" and CL's "setf" are the same idea, but := is easier to
read for some people.
- same goes for "[]" vs "element()".
- why do aref and gethash in CL have opposite argument orders?
I think you get the point.
None of these (or other) items are critical in themselves, but I find
that put all together they provide a cleaner, easier to use (and
remember) language.
-- Bruce
"Bruce Hoult" <·····@hoult.org> wrote in message
································@news.paradise.net.nz...
>
> - why do aref and gethash in CL have opposite argument orders?
>
>
aref is also opposite to nth. I think one "justification" if not "reason" for
this is the need to accomodate multiple indices in aref. For nth, the second
argument is the list but for aref, if not the first, it could be the 2nd,
3rd...etc..depending on how many array dimensions you have.
--
Coby
(remove #\space "coby . beck @ opentechgroup . com")
"Coby Beck" <·····@mercury.bc.ca> writes:
> "Bruce Hoult" <·····@hoult.org> wrote in message
> ································@news.paradise.net.nz...
> >
> > - why do aref and gethash in CL have opposite argument orders?
> >
> >
>
> aref is also opposite to nth.
So I have a little generic function, REF, that I'd had sitting around
unused for some time, and have recently been using all over the place.
Its usage is (ref thing index1 ... indexn), where THING is anything
that can be dereferenced. So, an array, a list, a hash table, etc.
I've been greatly appreciating the uniformity of syntax, plus the fact
that I can write a function without caring a bit what sort of thing
THING is, so long as it has a REF (and maybe a setter) defined for it.
Sort of like ELT for associations.
> I think one "justification" if not "reason" for this is the need to
> accomodate multiple indices in aref. For nth, the second argument
> is the list but for aref, if not the first, it could be the 2nd,
> 3rd...etc..depending on how many array dimensions you have.
Of course, this sounds like a good argument for everything following
AREF's syntax, since it needs to go in that order. But breaking all
previous usages and users of assoc was probably out of the question.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
Thomas F. Burdick <···@apocalypse.ocf.berkeley.edu> wrote:
> ...
> So I have a little generic function, REF, that I'd had sitting around
> unused for some time, and have recently been using all over the place.
> Its usage is (ref thing index1 ... indexn), where THING is anything
> that can be dereferenced. So, an array, a list, a hash table, etc.
> I've been greatly appreciating the uniformity of syntax, plus the fact
> that I can write a function without caring a bit what sort of thing
> THING is, so long as it has a REF (and maybe a setter) defined for it.
> Sort of like ELT for associations.
Why didn't you make it as a macro? (I just wonder.)
<·········@mail.ru> writes:
> Thomas F. Burdick <···@apocalypse.ocf.berkeley.edu> wrote:
> > ...
> > So I have a little generic function, REF, that I'd had sitting around
> > unused for some time, and have recently been using all over the place.
> > Its usage is (ref thing index1 ... indexn), where THING is anything
> > that can be dereferenced. So, an array, a list, a hash table, etc.
> > I've been greatly appreciating the uniformity of syntax, plus the fact
> > that I can write a function without caring a bit what sort of thing
> > THING is, so long as it has a REF (and maybe a setter) defined for it.
> > Sort of like ELT for associations.
>
> Why didn't you make it as a macro? (I just wonder.)
Because there's no need to, and since I don't need any delayed
evaluation, a generic function is more flexible.
(defgeneric ref (thing &rest subscripts))
Now, every time I define a new class (say, ENVIRONMENT for the
compiler I'm writing, or BINARY-TREE, or anything), I can define a
method for it, and use it with REF transparently. I suppose I could
have defined it as
(defmacro ref (thing &rest subscripts)
(cond
((and (consp thing)
(eq (first thing) 'quote)
(listp (second thing)))
`(cdr (assoc ,(first subscripts) ,thing)))
((stringp thing) `(char ,thing ,@subscripts))
;; ...
(t `(generic-ref ,thing ,@subscripts))))
but I don't see the point. Except in the most boring cases
[eg,
(ref '((a . 1) (b . 2)) some-letter)
]
REF can't know the type of THING until runtime. A more interesting
thing to do might be to write a compiler macro that would take
advantage of CMUCL's type inference to transform the call into a
direct call to the appropriate method, but unless I've missed a
section of the spec, there's no portable way to get at the contents of
an environment object.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
In article <···············@famine.OCF.Berkeley.EDU>,
···@famine.OCF.Berkeley.EDU (Thomas F. Burdick) wrote:
> Except in the most boring cases
> [eg,
> (ref '((a . 1) (b . 2)) some-letter)
> ]
> REF can't know the type of THING until runtime. A more interesting
> thing to do might be to write a compiler macro that would take
> advantage of CMUCL's type inference to transform the call into a
> direct call to the appropriate method
Then that's where you differ from Dylan's "element" GF. You can write
"element" and "element-setter" for your own data structure and the
compiler will select it at compile time if the type of the collection is
known at the point of use.
-- Bruce
Bruce Hoult <·····@hoult.org> writes:
> In article <···············@famine.OCF.Berkeley.EDU>,
> ···@famine.OCF.Berkeley.EDU (Thomas F. Burdick) wrote:
>
> > Except in the most boring cases
> > [eg,
> > (ref '((a . 1) (b . 2)) some-letter)
> > ]
> > REF can't know the type of THING until runtime. A more interesting
> > thing to do might be to write a compiler macro that would take
> > advantage of CMUCL's type inference to transform the call into a
> > direct call to the appropriate method
>
> Then that's where you differ from Dylan's "element" GF. You can write
> "element" and "element-setter" for your own data structure and the
> compiler will select it at compile time if the type of the collection is
> known at the point of use.
Well, if I used a Lisp with a better CLOS implementation than CMUCL's
PCL, I'd likely get this in CL, too.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
In article <···············@apocalypse.OCF.Berkeley.EDU>,
···@apocalypse.OCF.Berkeley.EDU (Thomas F. Burdick) wrote:
> "Coby Beck" <·····@mercury.bc.ca> writes:
>
> > "Bruce Hoult" <·····@hoult.org> wrote in message
> > ································@news.paradise.net.nz...
> > >
> > > - why do aref and gethash in CL have opposite argument orders?
> > >
> > >
> >
> > aref is also opposite to nth.
>
> So I have a little generic function, REF, that I'd had sitting around
> unused for some time, and have recently been using all over the place.
> Its usage is (ref thing index1 ... indexn), where THING is anything
> that can be dereferenced. So, an array, a list, a hash table, etc.
> I've been greatly appreciating the uniformity of syntax, plus the fact
> that I can write a function without caring a bit what sort of thing
> THING is, so long as it has a REF (and maybe a setter) defined for it.
> Sort of like ELT for associations.
I agree that such uniformity is great. Your REF would appear to be the
same as Dylan's "element" GF. Which is written as "element(collection,
key)" or using the sugar "collection[key]". Dylan also has
"element-setter(newVal, collection, key)", which can also be written as
"collection[key] := newVal".
As you say, it's better to use the AREF ordering if you're going to make
one order fit all.
Presumably your REF works with SETF?
-- Bruce
Bruce Hoult <·····@hoult.org> writes:
> In article <···············@apocalypse.OCF.Berkeley.EDU>,
> ···@apocalypse.OCF.Berkeley.EDU (Thomas F. Burdick) wrote:
>
> > "Coby Beck" <·····@mercury.bc.ca> writes:
> >
> > > "Bruce Hoult" <·····@hoult.org> wrote in message
> > > ································@news.paradise.net.nz...
> > > >
> > > > - why do aref and gethash in CL have opposite argument orders?
> > > >
> > > >
> > >
> > > aref is also opposite to nth.
> >
> > So I have a little generic function, REF, that I'd had sitting around
> > unused for some time, and have recently been using all over the place.
> > Its usage is (ref thing index1 ... indexn), where THING is anything
> > that can be dereferenced. So, an array, a list, a hash table, etc.
> > I've been greatly appreciating the uniformity of syntax, plus the fact
> > that I can write a function without caring a bit what sort of thing
> > THING is, so long as it has a REF (and maybe a setter) defined for it.
> > Sort of like ELT for associations.
>
> I agree that such uniformity is great. Your REF would appear to be the
> same as Dylan's "element" GF. Which is written as "element(collection,
> key)" or using the sugar "collection[key]". Dylan also has
> "element-setter(newVal, collection, key)", which can also be written as
> "collection[key] := newVal".
>
> As you say, it's better to use the AREF ordering if you're going to make
> one order fit all.
>
> Presumably your REF works with SETF?
Usually :-). When I write a getter method, I write a setter if it's
easy. Sometimes (alists), it isn't. In that case, I wait til I get
an error, then bite the bullet and write it. Or switch data
structures, if I don't want to wait.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
In article <···························@news.paradise.net.nz>, Bruce
Hoult wrote:
>- Dylan's ":=" and CL's "setf" are the same idea, but := is easier to
>read for some people.
Without some formal study, what is readable is just a guess.
Coming to Lisp after half a lifetime using programming languages that
have some kind of infix assignment, I have no problem reading setf at all.
(That is just anecdotal evidence based on my own experience, and does
not extrapolate into what people find readable, hint, hint).
Even if the := notation is found more readable, it may not be wortwhile.
What is more important is to be able to manage large, complex programs.
Having a simple, programmable syntax is a way of trading some small-scale
readability for a more significant goal.
The real question is whether the given language is a suitable target
language for one's abstractions.
···@ashi.footprints.net (Kaz Kylheku) writes:
> In article <···························@news.paradise.net.nz>, Bruce
> Hoult wrote:
> >- Dylan's ":=" and CL's "setf" are the same idea, but := is easier to
> >read for some people.
>
> Without some formal study, what is readable is just a guess.
>
> Coming to Lisp after half a lifetime using programming languages that
> have some kind of infix assignment, I have no problem reading setf at all.
> (That is just anecdotal evidence based on my own experience, and does
> not extrapolate into what people find readable, hint, hint).
The human visual systems has very low level feature dectors for finding
vertical and horizontal lines. You can easily pick out a horizontal line
hiding in a field of vertical lines. Just like picking out the green dot in
a field of yellow is pretty easy. Having the human visual system parse
"setf" takes quite a bit more work.
How many setfs? are in this string
skdjvsdkjjlksetflkasfjsflsklsdflkjwiescsfjeriosadflksetfkkfslkfjskfjskkksjdfliwasetf
How many := are are in this string
skdjvsdkjjlk:=lkasfjsflsklsdflkjwiescsfjeriosadflk:=kkfslkfjskfjskkksjdfliwa:=
Or this
---_+_+-==-=++-=-=--=-:==-=-=-=+=-=--=-++=-=--:=-=-=-=--0--=:=---+=--=-
Most people should find the middle tasks the easiest. If there's any
readability advantage to := I doubt it's an infix vs prefix issue. It's
probably more low level. Syntax highlighting probably makes the difference
go away completely.
> How many setfs? are in this string
>
>
skdjvsdkjjlksetflkasfjsflsklsdflkjwiescsfjeriosadflksetfkkfslkfjskfjskkksjdf
liwasetf
Do you come across strings like that frequently in your work? Are you using
a Lisp *without parentheses*?
J.B.
-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
Check out our new Unlimited Server. No Download or Time Limits!
-----== Over 80,000 Newsgroups - 19 Different Servers! ==-----
"Janos Blazi" <······@hotmail.com> writes:
> > How many setfs? are in this string
> >
> >
> skdjvsdkjjlksetflkasfjsflsklsdflkjwiescsfjeriosadflksetfkkfslkfjskfjskkksjdf
> liwasetf
>
> Do you come across strings like that frequently in your work? Are you using
> a Lisp *without parentheses*?
Even without parentheses the other task of picking out ":=" is *relatively*
easier than the "setf" task. I'm sure that with parentheses *both* tasks get
easier, but the relative difference is still there. You can argue that
adding parenthesese makes both tasks so easy that the relative difference
becomes meaningless. I personally do not think this is the case.
I don't have any Lisp code handy. However, if you take a larger piece of
source code and ask humans to underline every occurence of "setf" in it. It
will take them longer than a similar task where "setf" is replaced by ":="
even if you keep prefix notation... i.e.
(:= e1 e2)
is easier to visually recognize than
(setf e1 e2)
when dumped in a sea of program text.
If you let people syntax highlight things the task might get easier for
setf. Anyway, that just my take on it. I don't have any real experimental
evidence for it. However, I just described a relatively simple experiment
you can do yourself. I'd happy to hear any evidence either way.
The ease of visually parsing programs is one reason why I prefer { } to
BEGIN END. Picking out { and } is simply an easier task for the huuman
visual system when compared to BEGIN END.
"Daniel C. Wang" <············@cs.princeton.edu> writes:
> "Janos Blazi" <······@hotmail.com> writes:
>
> > > How many setfs? are in this string
> > >
> > >
> > skdjvsdkjjlksetflkasfjsflsklsdflkjwiescsfjeriosadflksetfkkfslkfjskfjskkksjdf
> > liwasetf
> >
> > Do you come across strings like that frequently in your work? Are you using
> > a Lisp *without parentheses*?
>
> Even without parentheses the other task of picking out ":=" is *relatively*
> easier than the "setf" task. I'm sure that with parentheses *both* tasks get
> easier, but the relative difference is still there. You can argue that
> adding parenthesese makes both tasks so easy that the relative difference
> becomes meaningless. I personally do not think this is the case.
>
> I don't have any Lisp code handy. However, if you take a larger piece of
> source code and ask humans to underline every occurence of "setf" in it. It
> will take them longer than a similar task where "setf" is replaced by ":="
> even if you keep prefix notation... i.e.
>
> (:= e1 e2)
> is easier to visually recognize than
>
> (setf e1 e2)
> when dumped in a sea of program text.
But how often are you looking at a sea of program text? I'm usually
looking at a specific part of a program, in which case setting is one
of many things that can be done, and I can't think of any reason I'd
care so much more about it than anthing else the program could be
doing. If you want to find all the instances where e1 is assigned to,
use your editor's search facility. And if you really prefer :=, you
can define
(defmacro := (&rest stuff) (cons 'setf stuff))
That's a bad idea, not the least because := is the symbol (intern "="
"KEYWORD"), but you could use the more visually telling <- if you
wanted:
(<- e1 e2
(gethash 'e h1) e2)
But I find that a lot uglier than
(setf e1 e2
(gethash 'e h1) e2)
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
···@famine.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
{stuff deleted}
> But how often are you looking at a sea of program text? I'm usually
> looking at a specific part of a program, in which case setting is one
> of many things that can be done, and I can't think of any reason I'd
> care so much more about it than anthing else the program could be
> doing. If you want to find all the instances where e1 is assigned to,
> use your editor's search facility. And if you really prefer :=, you
> can define
Scheme/Lisp has uniform syntax. This makes it easier to play all sorts of
crazy macro games with. The :=/setf example is one where Algol languages
trade the uniformity of syntax for readability. IMNHO readability has less
to do with infix/prefix issues than with uniform/non-uniform. My only claim
is that choosing too uniform a syntax can effect readability, and that these
readability issues are not just a matter of taste, but have some connection
with basic visual processing.
Graphic artist get paid to design logos and visual designs that are easy to
parse quickly. They manipulate color, layout, and shape to make things
easier to visually parse. Properly indented and syntax highlighted
Scheme/Lisp is pretty easy to read. Languages with non-uniform syntax that
use infix and more punctuation do not need to rely soo much on indentation
or color cues to acheive the same level of readability.
Daniel C. Wang wrote:
>
> ···@famine.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
> {stuff deleted}
>> But how often are you looking at a sea of program text? I'm usually
>> looking at a specific part of a program, in which case setting is one
>> of many things that can be done, and I can't think of any reason I'd
>> care so much more about it than anthing else the program could be
>> doing. If you want to find all the instances where e1 is assigned to,
>> use your editor's search facility. And if you really prefer :=, you
>> can define
>
> Scheme/Lisp has uniform syntax. This makes it easier to play all sorts of
> crazy macro games with. The :=/setf example is one where Algol languages
> trade the uniformity of syntax for readability. IMNHO readability has less
> to do with infix/prefix issues than with uniform/non-uniform. My only
> claim is that choosing too uniform a syntax can effect readability, and
> that these readability issues are not just a matter of taste, but have
> some connection with basic visual processing.
Please try to understand that "readability" is a person-specific facility.
Write _you_ can read such written syntax better but do not claim that
something is better readable by anyone.
The human brain is highly adaptive - you may be astonished how much your
brain adapts to a certain kind of syntax. At the start - coming from
algol-like languages - I had my problems reading lisp-syntax. But after
some months of using it I suddenly realized that I could read lisp-code
ways better than algol-like code. You may think that := is always better
readable than setf because it is smaller - I could respond that it is
actually maybe so small that it can be easier overlooked. If you really
want to emphasise an operator in your source-code you can even write SETF
instead of :=. You cannot upcase :=...
ciao,
Jochen
--
http://www.dataheaven.de
In comp.lang.scheme Thomas F. Burdick <···@famine.ocf.berkeley.edu> wrote:
> "Daniel C. Wang" <············@cs.princeton.edu> writes:
>> "Janos Blazi" <······@hotmail.com> writes:
>>
>> > > How many setfs? are in this string
>> > >
>> > >
>> > skdjvsdkjjlksetflkasfjsflsklsdflkjwiescsfjeriosadflksetfkkfslkfjskfjskkksjdf
>> > liwasetf
>> >
>> > Do you come across strings like that frequently in your work? Are you using
>> > a Lisp *without parentheses*?
>>
>> Even without parentheses the other task of picking out ":=" is *relatively*
>> easier than the "setf" task. I'm sure that with parentheses *both* tasks get
>> easier, but the relative difference is still there. You can argue that
>> adding parenthesese makes both tasks so easy that the relative difference
>> becomes meaningless. I personally do not think this is the case.
>>
>> I don't have any Lisp code handy. However, if you take a larger piece of
>> source code and ask humans to underline every occurence of "setf" in it. It
>> will take them longer than a similar task where "setf" is replaced by ":="
>> even if you keep prefix notation... i.e.
>>
>> (:= e1 e2)
>> is easier to visually recognize than
>>
>> (setf e1 e2)
>> when dumped in a sea of program text.
> But how often are you looking at a sea of program text? I'm usually
> looking at a specific part of a program, in which case setting is one
> of many things that can be done, and I can't think of any reason I'd
> care so much more about it than anthing else the program could be
> doing. If you want to find all the instances where e1 is assigned to,
Lots of people spend lots of time looking at a sea of program - usually
a sea of program they didn't write. And this can be for a wide number
of reasons, whetever to find or fix a bug or enhance some section.
> use your editor's search facility. And if you really prefer :=, you
> can define
> (defmacro := (&rest stuff) (cons 'setf stuff))
> That's a bad idea, not the least because := is the symbol (intern "="
> "KEYWORD"), but you could use the more visually telling <- if you
> wanted:
> (<- e1 e2
> (gethash 'e h1) e2)
Which assumes <- is more visually telling or easier to find than :=
> But I find that a lot uglier than
> (setf e1 e2
> (gethash 'e h1) e2)
> --
> /|_ .-----------------------.
> ,' .\ / | No to Imperialist war |
> ,--' _,' | Wage class war! |
> / / `-----------------------'
> ( -. |
> | ) |
> (`-. '--.)
> `. )----'
--
Sander
+++ Out of cheese error +++
* Sander Vesik
| Lots of people spend lots of time looking at a sea of program - usually a
| sea of program they didn't write. And this can be for a wide number of
| reasons, whetever to find or fix a bug or enhance some section.
I used to be doing that for a living, while I still thought C was cool.
Certain kinds of bugs stand out from the source like bad spelling. But
some people do not see spelling mistakes, so make a lot of them and need
machine help to signal them to their visual system, like wavy red lines.
This is not how you learn to spell correctly. It is as bad as singing
off key and having a computer beep back at you until you no longer get it
wrong in _its_ view -- it can never get _good_ that way. I also think
programmers who need color to see their code need to drop the keyboard
and pick up some crayons -- if color helps, it is _not_ a good thing.
Whatever your language is, if you cannot scan it quickly or slowly as
your needs require, you are not a production quality programmer, yet, or
maybe you are not reading production quality code written by another
immature specimen. If the goal is to increase the number of production
quailty programmers, you train them, reward them when they get closer to
that goal and get rid of those who refuse to improve when necessary.
Rewarding incompetence and ignorance increases the number of incompetent
programmers. Designing programming languages and tools so incompetent
programmers can feel better about themselves is not the way to go.
///
--
The past is not more important than the future, despite what your culture
has taught you. Your future observations, conclusions, and beliefs are
more important to you than those in your past ever will be. The world is
changing so fast the balance between the past and the future has shifted.
+ Erik Naggum <····@naggum.net>:
| I also think programmers who need color to see their code need to
| drop the keyboard and pick up some crayons -- if color helps, it
| is _not_ a good thing.
This reminds me of an often heard argument against the traffic
regulation requiring headlights to be on at all times: "If you can't
see an approaching car a hundred meters away in broad daylight, you
should not be driving a car in the first place." True, but this
misses the point: There are lots of valid reasons why your attention
may be momentarily directed elsewhere, and then those headlights alert
you to the presence of the approaching car earlier. If a dangerous
situation is averted that way, you are probably not even aware of the
fact, as you took appropriate action without a second thought. In the
same way, I find some use of colour quite helpful in reading code.
Like indentation, it's really just another pathway into your brain,
alerting you to structure that is not immediately apparent at first
glance. I certainly find it easier to concentrate on the essence of
any programming problem the more clues, like indentation and
colouring, are there to make structure apparent, allowing me to spend
less mental energy on discovering what the text actually says and
correspondingly more on why it says what it says. In Lisp, however,
colour definitely takes the back seat to indentation, which is at
least one or two orders of magnitudes more helpful in making structure
obvious to the eye. To consider two opposite extremes, I can happily
read and edit Lisp code without the use of colouring - but in working
with markup languages like TeX or HTML, I really appreciate having the
markup stick out from the text like a sore thumb - which, in many
cases, is an accurate description of its nature.
Another issue is that colouring done wrong is terribly distracting,
just like bad indentation. And font-locking code in emacs seems to
get it wrong just a bit too often: If I na�vely type
(let ((case :upcase))
...)
in a Lisp buffer with font-locking turned on, emacs will highlight
"case" as if it were a keyword. And then there are horrors like what
happens to latex.ltx, where everything after the dollar sign in
·····@argarraycr[#1]{%
\ifnum0=`{\fi}${}\ifdim #1>··@ ·@xargarraycr{#1}\else
·@yargarraycr{#1}\fi}
seems to be in math mode as far as emacs is concerned, turning the
final third of the file a uniform brownish colour. Ugh. You can tell
if the author used emacs for editing this file if a place like this is
immediately followed by a comment containing a lone dollar sign to get
the font-locking code back on the right track.
--
* Harald Hanche-Olsen <URL:http://www.math.ntnu.no/~hanche/>
- Yes it works in practice - but does it work in theory?
Harald Hanche-Olsen <······@math.ntnu.no> writes:
> This reminds me of an often heard argument against the traffic
> regulation requiring headlights to be on at all times: "If you can't
> see an approaching car a hundred meters away in broad daylight, you
> should not be driving a car in the first place." True, but this
> misses the point: There are lots of valid reasons why your attention
> may be momentarily directed elsewhere, and then those headlights alert
> you to the presence of the approaching car earlier. If a dangerous
> situation is averted that way, you are probably not even aware of the
> fact, as you took appropriate action without a second thought.
One of the most persuasive arguments against headlights during day
time is the false sense of safety that everything of importance will
announce its presence by headlights, which will make traffic more
dangerous for cyclists and pedestrians.
To track this back on topic, I've used emacs's lisp fontlock mode and
am now using LispWorks editor which doesn't have that functionality
and I don't miss it at all in Lisp.
--
Lieven Marchand <···@wyrd.be>
She says, "Honey, you're a Bastard of great proportion."
He says, "Darling, I plead guilty to that sin."
Cowboy Junkies -- A few simple words
Lieven Marchand wrote:
> Harald Hanche-Olsen <······@math.ntnu.no> writes:
>
>> This reminds me of an often heard argument against the traffic
>> regulation requiring headlights to be on at all times: "If you can't
>> see an approaching car a hundred meters away in broad daylight, you
>> should not be driving a car in the first place." True, but this
>> misses the point: There are lots of valid reasons why your attention
>> may be momentarily directed elsewhere, and then those headlights alert
>> you to the presence of the approaching car earlier. If a dangerous
>> situation is averted that way, you are probably not even aware of the
>> fact, as you took appropriate action without a second thought.
>
> One of the most persuasive arguments against headlights during day
> time is the false sense of safety that everything of importance will
> announce its presence by headlights, which will make traffic more
> dangerous for cyclists and pedestrians.
>
> To track this back on topic, I've used emacs's lisp fontlock mode and
> am now using LispWorks editor which doesn't have that functionality
> and I don't miss it at all in Lisp.
Sidenote:
The new 4.2 Release of LispWorks supports syntax-highlighting in the editor.
ciao,
Jochen
--
http://www.dataheaven.de
In article <················@naggum.net>, Erik Naggum wrote:
> * Sander Vesik
> | Lots of people spend lots of time looking at a sea of program - usually a
> | sea of program they didn't write. And this can be for a wide number of
> | reasons, whetever to find or fix a bug or enhance some section.
>
> I used to be doing that for a living, while I still thought C was cool.
> Certain kinds of bugs stand out from the source like bad spelling. But
> some people do not see spelling mistakes, so make a lot of them and need
> machine help to signal them to their visual system, like wavy red lines.
> This is not how you learn to spell correctly. It is as bad as singing
> off key and having a computer beep back at you until you no longer get it
> wrong in _its_ view -- it can never get _good_ that way. I also think
> programmers who need color to see their code need to drop the keyboard
> and pick up some crayons -- if color helps, it is _not_ a good thing.
>
> Whatever your language is, if you cannot scan it quickly or slowly as
> your needs require, you are not a production quality programmer, yet, or
> maybe you are not reading production quality code written by another
> immature specimen. If the goal is to increase the number of production
> quailty programmers, you train them, reward them when they get closer to
> that goal and get rid of those who refuse to improve when necessary.
> Rewarding incompetence and ignorance increases the number of incompetent
> programmers. Designing programming languages and tools so incompetent
> programmers can feel better about themselves is not the way to go.
>
From someone who is not a production quality programmer:
what is one?
how do I become one?
marc
> ///
> --
> The past is not more important than the future, despite what your culture
> has taught you. Your future observations, conclusions, and beliefs are
> more important to you than those in your past ever will be. The world is
> changing so fast the balance between the past and the future has shifted.
From: Erik Naggum
Subject: Re: what makes a production quality programer? (was Re: New Lisp ?)
Date:
Message-ID: <3218582578762837@naggum.net>
* ····@oscar.eng.cv.net (Marc Spitzer)
| From someone who is not a production quality programmer:
|
| what is one?
First, someone who knows the language well and who does not fight it, and
therefore can read it painlessly and effortlessly and who can also write
correct code in it, considering all specified implications of the code.
Second, someone who specifies his own functionality with at least as much
precision as the language specification and codes accordingly.
Third, someone who knows the implementation and the tools he uses well
and uses them to their fullest.
Fourth, someone who can deal with upgrades just as effortlessly and does
not remember things past after they have changed.
| how do I become one?
You internalize the specification of the language you use and subjugate
your desires for what the language should be like to what it really is
when you are using the language.
In other words, a production quality programmer is one who has figured
out that the language and the tools he is using are just as real as his
physical reality when he is using them to shape and build something new
within that reality. Those who believe in magic, in wishful thinking, or
in rebellion against physics are not good engineers. Similar failure to
understand the computing environment one lives in leads to broken code
and a serious lack of trustworthiness in both code and programmer.
In my view, a successful computing environment is one which lends itself
to exactly the same kind of hard science as physics, like the hardware,
but which becomes malleable if you go from "user mode" into "god mode".
The distinction between "god mode" and "user mode" is precisely where you
accept what is for what it is, instead of trying to change it before you
use it. The ability to relinquish the "power" that comes from changing
the computing environment in order to live in it is fundamental to one's
ability to live in the software creations of other people.
In "user mode", you look at something and decide whether to use it or not
according as it fits your desires and wishes. In "god mode", you look at
something and decide how to change it to fit your desires and wishes. It
should be obvious that trying to change something that is not changeable
must lead to serious frustrations -- like wanting the specification of
either language or application to be something else -- and that these
frustrations lead to extremely low quality code with random behavior,
depending on whether the programmer's wishes du jour were met or not.
///
--
The past is not more important than the future, despite what your culture
has taught you. Your future observations, conclusions, and beliefs are
more important to you than those in your past ever will be. The world is
changing so fast the balance between the past and the future has shifted.
From: Marc Spitzer
Subject: Re: what makes a production quality programer? (was Re: New Lisp ?)
Date:
Message-ID: <slrna2qeia.faj.marc@oscar.eng.cv.net>
In article <················@naggum.net>, Erik Naggum wrote:
> * ····@oscar.eng.cv.net (Marc Spitzer)
> | From someone who is not a production quality programmer:
> |
> | what is one?
>
> First, someone who knows the language well and who does not fight it, and
> therefore can read it painlessly and effortlessly and who can also write
> correct code in it, considering all specified implications of the code.
>
> Second, someone who specifies his own functionality with at least as much
> precision as the language specification and codes accordingly.
>
> Third, someone who knows the implementation and the tools he uses well
> and uses them to their fullest.
>
> Fourth, someone who can deal with upgrades just as effortlessly and does
> not remember things past after they have changed.
>
> | how do I become one?
>
> You internalize the specification of the language you use and subjugate
> your desires for what the language should be like to what it really is
> when you are using the language.
>
> In other words, a production quality programmer is one who has figured
> out that the language and the tools he is using are just as real as his
> physical reality when he is using them to shape and build something new
> within that reality. Those who believe in magic, in wishful thinking, or
> in rebellion against physics are not good engineers. Similar failure to
> understand the computing environment one lives in leads to broken code
> and a serious lack of trustworthiness in both code and programmer.
>
> In my view, a successful computing environment is one which lends itself
> to exactly the same kind of hard science as physics, like the hardware,
> but which becomes malleable if you go from "user mode" into "god mode".
> The distinction between "god mode" and "user mode" is precisely where you
> accept what is for what it is, instead of trying to change it before you
> use it. The ability to relinquish the "power" that comes from changing
> the computing environment in order to live in it is fundamental to one's
> ability to live in the software creations of other people.
>
> In "user mode", you look at something and decide whether to use it or not
> according as it fits your desires and wishes. In "god mode", you look at
> something and decide how to change it to fit your desires and wishes. It
> should be obvious that trying to change something that is not changeable
> must lead to serious frustrations -- like wanting the specification of
> either language or application to be something else -- and that these
> frustrations lead to extremely low quality code with random behavior,
> depending on whether the programmer's wishes du jour were met or not.
>
Well thought out, consistent and a lot of work to implement. About
what I expected.
Thanks
marc
> ///
> --
> The past is not more important than the future, despite what your culture
> has taught you. Your future observations, conclusions, and beliefs are
> more important to you than those in your past ever will be. The world is
> changing so fast the balance between the past and the future has shifted.
From: Paolo Amoroso
Subject: Re: what makes a production quality programer? (was Re: New Lisp ?)
Date:
Message-ID: <SAQuPMqmaloD4K98R1c+xUqtGUH+@4ax.com>
On Sat, 29 Dec 2001 02:43:01 GMT, Erik Naggum <····@naggum.net> wrote:
> * ····@oscar.eng.cv.net (Marc Spitzer)
> | From someone who is not a production quality programmer:
> |
> | what is one?
[...]
> Fourth, someone who can deal with upgrades just as effortlessly and does
> not remember things past after they have changed.
Can you elaborate on this? While I understand the literal meaning of the
last sentence, I'm not sure whether I also get its complete meaning. Do you
mean that, after a system upgrade, the programmer should no longer worry
about problems that have been fixed by the upgrade?
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://web.mclink.it/amoroso/ency/README
[http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/]
From: Erik Naggum
Subject: Re: what makes a production quality programer? (was Re: New Lisp ?)
Date:
Message-ID: <3218654884764918@naggum.net>
* Erik Naggum
> Fourth, someone who can deal with upgrades just as effortlessly and does
> not remember things past after they have changed.
* Paolo Amoroso
| Can you elaborate on this? While I understand the literal meaning of the
| last sentence, I'm not sure whether I also get its complete meaning. Do
| you mean that, after a system upgrade, the programmer should no longer
| worry about problems that have been fixed by the upgrade?
Many people learn through painful experiences and pain avoidance is a
very fundamental property of human behavior -- "once bitten, twice shy"
has an equivalent and very old idiom in every language. Failure to trust
a function because it once was buggy is very common among programmers who
learn through trial and error instead of through reading specifications.
Even those who do relate primarily to specifications get bitten by the
lack of conformance to those specifications by the vendors they trusted
to implement them. So instead of shying away from them, a production
quality programmer relearns and conditionalizes code on the specific
broken versions.
This is the hardest part of dealing with non-conforming systems that
evolve slowly towards full conformance. Some vendors also think that
their non-conforming behavior has made customers depend on it, so have a
hard time correcting conformance problems because they think their past
customers are unable to accept the painful experience of having to update
their code because they did not program according to the specification,
either, but according to "whatever works", discovered precisely through a
painful process of trial and error. This is one reason conformance to a
specification is so important.
To your direct question, a properly handled dependency chain for software
upgrades should in fact mean that once a dependent system has been
upgraded, the problems exhibited by prior versions should no longer be
the subject of worries. Absent properly handled dependency chains, there
is no hope of controlling any behavior at all, anyway.
///
--
The past is not more important than the future, despite what your culture
has taught you. Your future observations, conclusions, and beliefs are
more important to you than those in your past ever will be. The world is
changing so fast the balance between the past and the future has shifted.
From: Russell Wallace
Subject: Re: what makes a production quality programer? (was Re: New Lisp ?)
Date:
Message-ID: <3c2e8ae7.429599619@news.eircom.net>
On Sat, 29 Dec 2001 22:48:07 GMT, Erik Naggum <····@naggum.net> wrote:
> Many people learn through painful experiences and pain avoidance is a
> very fundamental property of human behavior -- "once bitten, twice shy"
> has an equivalent and very old idiom in every language. Failure to trust
> a function because it once was buggy is very common among programmers who
> learn through trial and error instead of through reading specifications.
On the other hand, this is not necessarily irrational. It's my
experience that software usually does not evolve from being very
unreliable to being very reliable. There are exceptions, but if a
program or module threw up lots of bugs in the past (unless it was an
early alpha version where that's to be expected) I've found it will
usually throw up lots more in the future, even if the currently known
ones are fixed; so I'm reluctant to ever rely on it.
--
"Pity for the guilty is treachery to the innocent."
···············@esatclear.ie
http://www.esatclear.ie/~rwallace
From: Erik Naggum
Subject: Re: what makes a production quality programer? (was Re: New Lisp ?)
Date:
Message-ID: <3218679521513316@naggum.net>
* Russell Wallace
| On the other hand, this is not necessarily irrational. It's my
| experience that software usually does not evolve from being very
| unreliable to being very reliable. There are exceptions, but if a
| program or module threw up lots of bugs in the past (unless it was an
| early alpha version where that's to be expected) I've found it will
| usually throw up lots more in the future, even if the currently known
| ones are fixed; so I'm reluctant to ever rely on it.
You gave us a scenario where an important property did not change. What
happens to your impression if it is completely rewritten?
"Experience is what you get when you do not get what you want." There is
no telling what kind of quality control there is to your "experience", or
indeed whether it was entirely invalid. All of these "experience" things
are great if you live in a world that does not change appreciably in your
lifetime. Most cultures are based in a false belief in constancy and
permanency and contain a lot of "material" that is basically there to
protect the culture from a changing world. So, too, with programming
cultures, only it is far worse in our field than in the world in general.
///
--
The past is not more important than the future, despite what your culture
has taught you. Your future observations, conclusions, and beliefs are
more important to you than those in your past ever will be. The world is
changing so fast the balance between the past and the future has shifted.
From: Russell Wallace
Subject: Re: what makes a production quality programer? (was Re: New Lisp ?)
Date:
Message-ID: <3c2fad2c.503920393@news.eircom.net>
On Sun, 30 Dec 2001 05:38:43 GMT, Erik Naggum <····@naggum.net> wrote:
>* Russell Wallace
>| On the other hand, this is not necessarily irrational. It's my
>| experience that software usually does not evolve from being very
>| unreliable to being very reliable. There are exceptions, but if a
>| program or module threw up lots of bugs in the past (unless it was an
>| early alpha version where that's to be expected) I've found it will
>| usually throw up lots more in the future, even if the currently known
>| ones are fixed; so I'm reluctant to ever rely on it.
>
> You gave us a scenario where an important property did not change. What
> happens to your impression if it is completely rewritten?
Then I'll treat it as a new product and try it out to see how reliable
the new version is.
> "Experience is what you get when you do not get what you want." There is
> no telling what kind of quality control there is to your "experience", or
> indeed whether it was entirely invalid. All of these "experience" things
> are great if you live in a world that does not change appreciably in your
> lifetime. Most cultures are based in a false belief in constancy and
> permanency and contain a lot of "material" that is basically there to
> protect the culture from a changing world. So, too, with programming
> cultures, only it is far worse in our field than in the world in general.
True; sometimes the past is a guide to the future, sometimes it's not;
it's a mistake to assume one where the other applies.
--
"Pity for the guilty is treachery to the innocent."
···············@esatclear.ie
http://www.esatclear.ie/~rwallace
··@eircom.net (Russell Wallace) writes:
> On Sun, 30 Dec 2001 05:38:43 GMT, Erik Naggum <····@naggum.net> wrote:
>
> >* Russell Wallace
> >| On the other hand, this is not necessarily irrational. It's my
> >| experience that software usually does not evolve from being very
> >| unreliable to being very reliable. There are exceptions, but if a
> >| program or module threw up lots of bugs in the past (unless it was an
> >| early alpha version where that's to be expected) I've found it will
> >| usually throw up lots more in the future, even if the currently known
> >| ones are fixed; so I'm reluctant to ever rely on it.
> >
> > You gave us a scenario where an important property did not change. What
> > happens to your impression if it is completely rewritten?
>
> Then I'll treat it as a new product and try it out to see how reliable
> the new version is.
I think you two are talking past eachother a bit here. Russell is
talking about a situation in which the user has been given reason to
think that the implementor is not competant to implement the function
to specs, or does not place a high value on conforming with the spec.
In such a situation, I'd say that it's a good idea to not fully trust
the function, even when a given bug is fixed, until you have reason to
believe that the real problem (the implementor) is fixed. If this
attitude on the part of the user persists, despite the implementor
having grown in competancy or changed priorities, then the problem is
user error. In this case, it's best to assume that things work as
specified, and fix/insist they're fixed, when they don't. Both of
these situations occur in production, and it's important to behave
appropriately in both.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
In article <·················@haldjas.folklore.ee>, Sander Vesik wrote:
>In comp.lang.scheme Thomas F. Burdick <···@famine.ocf.berkeley.edu> wrote:
>> "Daniel C. Wang" <············@cs.princeton.edu> writes:
>
>>> "Janos Blazi" <······@hotmail.com> writes:
>>> (:= e1 e2)
>>> is easier to visually recognize than
>>>
>>> (setf e1 e2)
>>> when dumped in a sea of program text.
>
>> But how often are you looking at a sea of program text? I'm usually
>> looking at a specific part of a program, in which case setting is one
>> of many things that can be done, and I can't think of any reason I'd
>> care so much more about it than anthing else the program could be
>> doing. If you want to find all the instances where e1 is assigned to,
>
>Lots of people spend lots of time looking at a sea of program - usually
>a sea of program they didn't write. And this can be for a wide number
>of reasons, whetever to find or fix a bug or enhance some section.
Pardon me if I'm overly skeptical here.
The difficulty in grappling with a sea (or shall we say ``morass'')
of code does not rest in the spelling of the operators, or trivial
issues of arrangement like prefix versus postfix.
A morass of code astounds the mind with a congnitive overload when it
is not arranged into abstractions that can be understood on multiple
levels of chunking.
A large program should be understandable at some level where you don't
have to worry about individual assignment operations.
If it isn't, then I don't believe that changing the spelling of these
operations, or their syntax from prefix to infix, is going to help much.
It is their sheer number and mind-boggling interdependencies that
are the problem, not their spelling.
At the magnification level at which these trivial spelling conventions
matter, *any* convention becomes readable when one is accustomed to it.
The most surprising element of readability is that, in the first place,
the human mind can be trained to automatically recognize letters and
words. Three sticks arranged in the shape of a roof jump out not as
three sticks but as the letter A. This jumping is pushed entirely into
low level ``subroutines'' in your brain so that it doesn't require any
conscious effort; you just perceive an entire independent signal path
related to the image in front of you. You are aware that there
is a shape, but also that it ``speaks'' to you. A similar adaptation
occurs to the detailed elements of the syntax of a programming language.
"Kaz Kylheku" <···@ashi.footprints.net> wrote in message
·························@news2.calgary.shaw.ca...
> In article <·················@haldjas.folklore.ee>, Sander Vesik wrote:
> >In comp.lang.scheme Thomas F. Burdick <···@famine.ocf.berkeley.edu> wrote:
> >> "Daniel C. Wang" <············@cs.princeton.edu> writes:
> >
> >>> "Janos Blazi" <······@hotmail.com> writes:
> >>> (:= e1 e2)
> >>> is easier to visually recognize than
> >>>
> >>> (setf e1 e2)
> >>> when dumped in a sea of program text.
> >
> >> But how often are you looking at a sea of program text? I'm usually
> >> looking at a specific part of a program, in which case setting is one
> >> of many things that can be done, and I can't think of any reason I'd
> >> care so much more about it than anthing else the program could be
> >> doing. If you want to find all the instances where e1 is assigned to,
> >
> >Lots of people spend lots of time looking at a sea of program - usually
> >a sea of program they didn't write. And this can be for a wide number
> >of reasons, whetever to find or fix a bug or enhance some section.
>
> At the magnification level at which these trivial spelling conventions
> matter, *any* convention becomes readable when one is accustomed to it.
>
Hear, hear. This sums up my feelings on this precisely. (along with the
arguments I snipped for brevity that lead here)
--
Coby
(remove #\space "coby . beck @ opentechgroup . com")
> Even without parentheses the other task of picking out ":=" is
*relatively*
> easier than the "setf" task.
But (:= a 5) is not very readable either and looks a bit clumsy as well. In
this case I should prefer (= a 5) and (eq a 5) or something like this.
J.B.
-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
Check out our new Unlimited Server. No Download or Time Limits!
-----== Over 80,000 Newsgroups - 19 Different Servers! ==-----
Janos Blazi wrote:
> But (:= a 5) is not very readable either and looks a bit clumsy as well. In
> this case I should prefer (= a 5) and (eq a 5) or something like this.
I prefer (setf a 5) or (set! a 5) because it reads naturally ("Set a to
five"). I'm not sure why being able to pick out these forms visually is
an advantage anyway, any more so than any of the other forms one might use.
In article <················@quiotix.com>, Jeffrey Siegal
<···@quiotix.com> wrote:
> Janos Blazi wrote:
>
> > But (:= a 5) is not very readable either and looks a bit clumsy as
> > well. In
> > this case I should prefer (= a 5) and (eq a 5) or something like this.
>
> I prefer (setf a 5) or (set! a 5) because it reads naturally ("Set a to
> five"). I'm not sure why being able to pick out these forms visually is
> an advantage anyway, any more so than any of the other forms one might
> use.
Because when you're programming in a mostly-functional language you want
to have the places that use mutation readily obvious.
-- Bruce
"Janos Blazi" <······@hotmail.com> writes:
> > Even without parentheses the other task of picking out ":=" is
> > *relatively* easier than the "setf" task.
> But (:= a 5) is not very readable either and looks a bit clumsy as
> well. In this case I should prefer (= a 5) and (eq a 5) or something
> like this.
This road leads towards throwing in APL symbols, such as "<-", which
more clearly expresses the notion of assignment. That strikes me as
being much more satisfactory than using "=", which feels a lot like a
relational operator, much like > or <.
Unfortunately, the order of things in Lisp doesn't fit very well with
this; while the "to-the-left" direction is appropriate, it would look
a lot more natural if the assignment operator actually went between
its arguments, as with:
(a <- 5)
And that just isn't going to fit with prefix notation...
--
(reverse (concatenate 'string ··········@" "enworbbc"))
http://www3.sympatico.ca/cbbrowne/functional.html
"It is easier to optimize correct code, than correct optimized code"
-- Yves Deville
········@acm.org writes:
> Unfortunately, the order of things in Lisp doesn't fit very well with
> this; while the "to-the-left" direction is appropriate, it would look
> a lot more natural if the assignment operator actually went between
> its arguments, as with:
>
> (a <- 5)
>
> And that just isn't going to fit with prefix notation...
While admitting that I haven't written working code to do this, I
would imagine that it would be possible to handle this syntax with the
current lisp reader by changing the reader macro for #\( and #\)
appropriately.
As to wether it fits with the rest of the syntax, I would agree,
peeping the cadr of a sexp for such a symbol is not somthing I would
like to do all day.
--
Craig Brozefsky <·····@red-bean.com>
http://www.red-bean.com/~craig
Ask me about Common Lisp Enterprise Eggplants at Red Bean!
Craig Brozefsky <·····@red-bean.com> writes:
> ········@acm.org writes:
>
> > Unfortunately, the order of things in Lisp doesn't fit very well with
> > this; while the "to-the-left" direction is appropriate, it would look
> > a lot more natural if the assignment operator actually went between
> > its arguments, as with:
> >
> > (a <- 5)
> >
> > And that just isn't going to fit with prefix notation...
>
> While admitting that I haven't written working code to do this, I
> would imagine that it would be possible to handle this syntax with the
> current lisp reader by changing the reader macro for #\( and #\)
> appropriately.
>
> As to wether it fits with the rest of the syntax, I would agree,
> peeping the cadr of a sexp for such a symbol is not somthing I would
> like to do all day.
There's actually an example in CLTL2 that (marginally) resembles this,
where Steele wrote some readtable code (section 22.1.5) implementing
CM Lisp "xapping." The direction of the arrows is a bit backwards,
but it's obviously doable.
I've been looking at that code a bit with a view to the thought of
perverting it to the end of building something resembling an XML
parser. Gonna have to think about it further, unless some struggling
to install CLLIB might lead to an alternative...
--
(reverse (concatenate 'string ··········@" "enworbbc"))
http://www.ntlug.org/~cbbrowne/lsf.html
"Objects keep things tidy, but don't accelerate growth: inheritance
does." -- James A. Crippen (after Alan Perlis)
········@acm.org writes:
>
> I've been looking at that code a bit with a view to the thought of
> perverting it to the end of building something resembling an XML
> parser. Gonna have to think about it further, unless some struggling
> to install CLLIB might lead to an alternative...
If you are trying to find a CL XML parser, you might want to have a look at the
following link:
http://www.garshol.priv.no/download/xmltools/plat_ix.html#plat9
This link lists a number of XML parsers for CL (as well as XML tools for
other languages). If none of the CL parsers listed suits your requirement, you
might want to have a look at the Emacs Lisp XML tools on the same page as a
starting point.
There is also a basic XML parser included as part of the Wilbur RDF toolkit:
http://wilbur-rdf.sourceforge.net/
--
Bill Clementson
Bill Clementson <·······@attbi.com> writes:
> ········@acm.org writes:
> > I've been looking at that code a bit with a view to the thought of
> > perverting it to the end of building something resembling an XML
> > parser. Gonna have to think about it further, unless some struggling
> > to install CLLIB might lead to an alternative...
>
> If you are trying to find a CL XML parser, you might want to have a look at the
> following link:
>
> http://www.garshol.priv.no/download/xmltools/plat_ix.html#plat9
Been there, looked at that. Haven't seen anything that has seemed
quite satisfactory. Well, I haven't seen anything I've been able to
get to _run_. The tools have either been platform-specific to
platforms I don't use, or haven't installed happily (or at all).
> There is also a basic XML parser included as part of the Wilbur RDF toolkit:
> http://wilbur-rdf.sourceforge.net/
Interesting link, and project. It's not clear how widely portable it
is; it's currently targeted just to MCL and ACL. (Two platforms is
obviously a lot better than just one, to be sure!)
--
(reverse (concatenate 'string ········@" "enworbbc"))
http://www.ntlug.org/~cbbrowne/unix.html
"C++ is more of a rube-goldberg type thing full of high-voltages,
large chain-driven gears, sharp edges, exploding widgets, and spots to
get your fingers crushed. And because of it's complexity many (if not
most) of it's users don't know how it works, and can't tell ahead of
time what's going to cause them to loose an arm." -- Grant Edwards
········@acm.org writes:
> Bill Clementson <·······@attbi.com> writes:
> > ········@acm.org writes:
> > > I've been looking at that code a bit with a view to the thought of
> > > perverting it to the end of building something resembling an XML
> > > parser. Gonna have to think about it further, unless some struggling
> > > to install CLLIB might lead to an alternative...
> >
> > If you are trying to find a CL XML parser, you might want to have a look at the
> > following link:
> >
> > http://www.garshol.priv.no/download/xmltools/plat_ix.html#plat9
>
> Been there, looked at that. Haven't seen anything that has seemed
> quite satisfactory. Well, I haven't seen anything I've been able to
> get to _run_. The tools have either been platform-specific to
> platforms I don't use, or haven't installed happily (or at all).
>
What platforms do you use & is it just an XML parser that you are after?
--
Bill Clementson
Bill Clementson <·······@attbi.com> writes:
> ········@acm.org writes:
>
> > Bill Clementson <·······@attbi.com> writes:
> > > ········@acm.org writes:
> > > > I've been looking at that code a bit with a view to the thought of
> > > > perverting it to the end of building something resembling an XML
> > > > parser. Gonna have to think about it further, unless some struggling
> > > > to install CLLIB might lead to an alternative...
> > >
> > > If you are trying to find a CL XML parser, you might want to have a look at the
> > > following link:
> > >
> > > http://www.garshol.priv.no/download/xmltools/plat_ix.html#plat9
> >
> > Been there, looked at that. Haven't seen anything that has seemed
> > quite satisfactory. Well, I haven't seen anything I've been able to
> > get to _run_. The tools have either been platform-specific to
> > platforms I don't use, or haven't installed happily (or at all).
> What platforms do you use & is it just an XML parser that you are
> after?
Mostly CLISP and CMU/CL on Linux, and an XML parser would pretty much
suffice. My _ideal_ would be to get something that, given a
stream/string of XML input, would produce a Lisp tree (e.g. - nested
set of lists) in much the manner of the ACL tool:
(parse-xml "<item1><item2 att1='one'/>this is some text</item1>")
-->
((item1 ((item2 att1 "one")) "this is some text"))
--
(concatenate 'string "cbbrowne" ·@sympatico.ca")
http://www3.sympatico.ca/cbbrowne/linuxdistributions.html
Rules of the Evil Overlord #70. "When my guards split up to search for
intruders, they will always travel in groups of at least two. They
will be trained so that if one of them disappears mysteriously while
on patrol, the other will immediately initiate an alert and call for
backup, instead of quizzically peering around a corner."
<http://www.eviloverlord.com/>
········@acm.org writes:
> Bill Clementson <·······@attbi.com> writes:
> > ········@acm.org writes:
> >
> > > Bill Clementson <·······@attbi.com> writes:
> > > > ········@acm.org writes:
> > > > > I've been looking at that code a bit with a view to the thought of
> > > > > perverting it to the end of building something resembling an XML
> > > > > parser. Gonna have to think about it further, unless some struggling
> > > > > to install CLLIB might lead to an alternative...
> > > >
> > > > If you are trying to find a CL XML parser, you might want to have a look at the
> > > > following link:
> > > >
> > > > http://www.garshol.priv.no/download/xmltools/plat_ix.html#plat9
> > >
> > > Been there, looked at that. Haven't seen anything that has seemed
> > > quite satisfactory. Well, I haven't seen anything I've been able to
> > > get to _run_. The tools have either been platform-specific to
> > > platforms I don't use, or haven't installed happily (or at all).
>
> > What platforms do you use & is it just an XML parser that you are
> > after?
>
> Mostly CLISP and CMU/CL on Linux, and an XML parser would pretty much
The CLOCC XML parser is supposed to work on both CLISP & CMUCL, so it might
meet your needs. I installed it on my PC (I use CLISP on a Windows2000 PC) and
got it to build and parse a simple xml file. Here are the steps I followed:
1. There are Makefile and Lisp-only installation instructions in the INSTALL
file in the main CLOCC directory - I followed the Lisp-only instructions to
do my install, running each line separately in CLISP so that I could make
certain that everything went ok.
2. The only mods I made to the installation instructions were to change the
location of *clocc-root* (as explained in the instructions) and to omit
building the f2cl (Fortran to CL) package.
3. I then exited & restarted CLISP.
4. I executed the 3 lines of lisp code (specified in the bottom of the INSTALL
document that were suggested to be added to your .clisprc init file). The
only changes I made were to chage the location of *clocc-root* again & to
load the xml file. Here are the commands I executed:
(setq *clocc-root* "c:/cygwin/usr/home/lisp/src/clocc/")
(load (concatenate 'string *clocc-root* "clocc"))
(load (translate-logical-pathname "clocc:src;cllib;xml"))
5. I then executed the following command to parse a simple test xml file:
(cllib:xml-read-from-file "test.xml")
6. The xml file was parsed ok & I got the following output:
[11]> (cllib:xml-read-from-file "test.xml")
[CLLIB:WITH-XML-FILE]
* [C:\cygwin\usr\home\lisp\src\clocc\src\cllib\entities.xml 20,741 bytes]...done [entities(%/&): 0/251] [bytes: 20,741] [run: 0.340 sec] [real: 0.390 sec]
[CLLIB:WITH-XML-FILE]
* [test.xml 354 bytes]...done [entities(%/&): 0/251] [bytes: 354] [run: 0.361 sec] [real: 0.410 sec]
* new XML name: "shipTo"
* new XML name: "QUERY"
* new XML name: "shipTo_rec"
* new XML name: "ShipName"
* new XML name: "NAME"
(#<CLLIB::XML-DECL xml [version="1.0" encoding="UTF-8" ?="true"] #x1A55F90D>
#<CLLIB:XML-OBJ
shipTo [QUERY="select ShipName, ShipAddress, ShipCity & ' '
& ShipRegion & ' ' & ShipPostalCode as
CompleteAddress, ShipCountry from orders where OrderID=10250"] 3 objects 19/215 chars
#x1A55FAD5>)
This corresponded to the elements & attributes in my test file, so it seemed to
work ok for me. Hopefully, this will help you get started.
--
Bill Clementson
Craig Brozefsky <·····@red-bean.com> writes:
> ········@acm.org writes:
>
> > Unfortunately, the order of things in Lisp doesn't fit very well with
> > this; while the "to-the-left" direction is appropriate, it would look
> > a lot more natural if the assignment operator actually went between
> > its arguments, as with:
> >
> > (a <- 5)
> >
> > And that just isn't going to fit with prefix notation...
>
> While admitting that I haven't written working code to do this, I
> would imagine that it would be possible to handle this syntax with the
> current lisp reader by changing the reader macro for #\( and #\)
> appropriately.
You don't need to, really:
·····@lambda:~$ lisp
; Loading #p"/usr/home/csr21/.cmucl-init.lisp".
Loaded subsystems:
Infix reader: version 1.3 28-JUN-96
* '#i"x:=2"
(SETQ X 2)
* '#i"f(x):=2"
(SETF (F X) 2)
Available from the CMU AI repository.
Christophe
--
Jesus College, Cambridge, CB5 8BL +44 1223 510 299
http://www-jcsu.jesus.cam.ac.uk/~csr21/ (defun pling-dollar
(str schar arg) (first (last +))) (make-dispatch-macro-character #\! t)
(set-dispatch-macro-character #\! #\$ #'pling-dollar)
········@acm.org wrote:
> Unfortunately, the order of things in Lisp doesn't fit very well with
> this; while the "to-the-left" direction is appropriate, it would look
> a lot more natural if the assignment operator actually went between
> its arguments, as with:
>
> (a <- 5)
>
> And that just isn't going to fit with prefix notation...
funnily enough when Sussman and Steele (AI memo no. 349) want to
demonstrate their "aset" primitive of their new SCHEME programming
language, they build a cons-cell function and use the "<-" symbol to
update the cell's contents.
Great minds think alike Mr. Browne.
Followups set to comp.lang.lisp only.
On 27 Dec 2001 14:21:51 -0500, Daniel C. Wang <············@cs.princeton.edu>
wrote:
>
> I don't have any Lisp code handy. However, if you take a larger
> piece of source code and ask humans to underline every occurence of
> "setf" in it. It will take them longer than a similar task where
> "setf" is replaced by ":=" even if you keep prefix notation... i.e.
>
> (:= e1 e2)
> is easier to visually recognize than
>
> (setf e1 e2)
> when dumped in a sea of program text.
Another data point:
At the LL1 workshop, Paul Graham said that he was using '=' instead
of SETF in his new Arc dialect of Lisp. He said he tried it as an
experiment, and was surprised by how much easier it made the code
read.
Neel
Neelakantan Krishnaswami wrote:
> At the LL1 workshop, Paul Graham said that he was using '=' instead
> of SETF in his new Arc dialect of Lisp. He said he tried it as an
> experiment, and was surprised by how much easier it made the code
> read.
This is strange. A good FPer does not use setf often enough for it to
matter. I think either an alien has taken over PGs body or PG has
undertaken a diabolical Scheme to lure Pythonites, Perlers and Rubyans
into the CL camp by creating a stepping stone from those hacks to CL.
kenny
clinisys
[Followups not obeyed, this is a pan-language issue]
·····@alum.mit.edu (Neelakantan Krishnaswami) writes:
> At the LL1 workshop, Paul Graham said that he was using '=' instead
> of SETF in his new Arc dialect of Lisp. He said he tried it as an
> experiment, and was surprised by how much easier it made the code
> read.
This is the worst thing to do, since = has a better meaning as a (kind of)
equality predicate. C/C++/Java aside, a dedicated assignment token is
preferred, whether :=, setf, set!, whatever.
Languages that change the historical meaning of = cause unnecessary bugs,
e.g. the classic "if (a = 0) ..." business.
--
Cheers, The Rhythm is around me,
The Rhythm has control.
Ray Blaak The Rhythm is inside me,
·····@telus.net The Rhythm has my soul.
In article <·················@blight.transcend.org>,
Ray Blaak <·····@telus.net> wrote:
>Languages that change the historical meaning of = cause unnecessary bugs,
>e.g. the classic "if (a = 0) ..." business.
PL/I and Fortran never had that problem, even though they use = for *both*
assignment and equality testing. This is possible in languages where
statements and expressions are distinct and not allowed in each other's
context. The test clause of an "if" statement is an expression, so = is
determined to be equality; a standalone "a = b" is a statement, so = must
be assignment.
I believe the historical reason for using = in assignments is due to
mathematicians. They indicate assignment by writing "Let <var> = <expr>",
and programming language designers then chose to elide the "let" for
brevity. BASIC originally required the LET verb, but the implementors
noticed that it could be disambiguated by context just as in Fortran, so
they made it optional. I guess assignments are so common that programmers
really prefer to keep them as terse as possible (this eventually led to C's
"x <op>= y" abbreviation for the "x = x <op> y" idiom).
--
Barry Margolin, ······@genuity.net
Genuity, Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
From: Jeffrey Siegal
Subject: Re: = for assignment (was Re: New Lisp ?)
Date:
Message-ID: <3C2D2DD9.6060906@quiotix.com>
Barry Margolin wrote:
> I believe the historical reason for using = in assignments is due to
> mathematicians. They indicate assignment by writing "Let <var> = <expr>",
Not exactly. Let var = exp in mathematics is an assertion of equality,
not assignment. Assignment is a different operation which doesn't exist
in traditional mathematics but can of course be represented
mathematically using e.g. denotational semantics.
Languages such as ML are slightly different, where the let var = exp
operator introduces a binding, which, absent subsequent assignement
(impossible in ML), is equivalent to a mathematical assertion of equality.
I do agree that <var> = <exp> in programming came about as a derivative
of the mathematical usage, but it shouldn't have, since the two are
fundamentally different in most programming languages.
Jeffrey Siegal <···@quiotix.com> writes:
> Barry Margolin wrote:
>
> > I believe the historical reason for using = in assignments is due to
> > mathematicians. They indicate assignment by writing "Let <var> = <expr>",
>
> Not exactly. Let var = exp in mathematics is an assertion of equality,
> not assignment. Assignment is a different operation which doesn't exist
> in traditional mathematics but can of course be represented
> mathematically using e.g. denotational semantics.
Some texts make a difference between assertions of equality between
already existing concepts like sin^2 x + cos^2 x = 1 and an assertion
of equality that introduces or defines a new concept, usually by using
:= or by = with def over it like tan x := sin x / cos x.
--
Lieven Marchand <···@wyrd.be>
She says, "Honey, you're a Bastard of great proportion."
He says, "Darling, I plead guilty to that sin."
Cowboy Junkies -- A few simple words
Barry Margolin wrote:
> PL/I and Fortran never had that problem, even though they use = for *both*
> assignment and equality testing.
I've never used PL/I, but in Fortran equality testing is done with .eq.
as in
if (a .eq. b) then
endif
Ray
On Fri, 28 Dec 2001 19:09:21 GMT, Ray Blaak <·····@telus.net> wrote:
>This is the worst thing to do, since = has a better meaning as a (kind of)
>equality predicate. C/C++/Java aside, a dedicated assignment token is
>preferred, whether :=, setf, set!, whatever.
They should be distinct symbols, but since assignment is used much
more often than equality testing, it should get the more concise
symbol.
Yes, this offends mathematicians. Here's a proposal: you
mathematicians stop using the Greek alphabet for variable names, and
we programmers will stop using = for assignment ^.^
--
"Pity for the guilty is treachery to the innocent."
···············@esatclear.ie
http://www.esatclear.ie/~rwallace
From: Jeffrey Siegal
Subject: Re: = for assignment (was Re: New Lisp ?)
Date:
Message-ID: <3C2E8354.3060805@quiotix.com>
Russell Wallace wrote:
> They should be distinct symbols, but since assignment is used much
> more often than equality testing, it should get the more concise
> symbol.
That depends very much on the language and style of programming. In
most Scheme programs, equality testing (though often not the numerical
equality that the = symbol is used to represent) is used *far* more than
assignment.
Agreed. Every (rare) time I find myself coding SETF I feel like Ace
Ventura handling the white bat. Yecch.
Shikaka!
kenny
clinisys
Jeffrey Siegal wrote:
>
> Russell Wallace wrote:
>
> > They should be distinct symbols, but since assignment is used much
> > more often than equality testing, it should get the more concise
> > symbol.
>
> That depends very much on the language and style of programming. In
> most Scheme programs, equality testing (though often not the numerical
> equality that the = symbol is used to represent) is used *far* more than
> assignment.
On Sat, 29 Dec 2001 19:00:36 -0800, Jeffrey Siegal <···@quiotix.com>
wrote:
>Russell Wallace wrote:
>
>> They should be distinct symbols, but since assignment is used much
>> more often than equality testing, it should get the more concise
>> symbol.
>
>That depends very much on the language and style of programming. In
>most Scheme programs, equality testing (though often not the numerical
>equality that the = symbol is used to represent) is used *far* more than
>assignment.
Okay, that's a fair point - if you're designing a language like
Scheme, where assignment is intended to be rare, then by all means go
ahead and use the shorter symbol for equality testing.
--
"Pity for the guilty is treachery to the innocent."
···············@esatclear.ie
http://www.esatclear.ie/~rwallace
··@eircom.net (Russell Wallace) writes:
> On Fri, 28 Dec 2001 19:09:21 GMT, Ray Blaak <·····@telus.net> wrote:
>
> Yes, this offends mathematicians. Here's a proposal: you
> mathematicians stop using the Greek alphabet for variable names, and
> we programmers will stop using = for assignment ^.^
Would it still be OK to use Hebrew letters for cardinal arithmetic?
:)
Edi.
On 30 Dec 2001 10:34:21 +0100, ···@agharta.de (Dr. Edmund Weitz)
wrote:
>Would it still be OK to use Hebrew letters for cardinal arithmetic?
Well, for a start how about replacing the terms "ordinal" and
"cardinal" in this context with something less cryptic? I can never
remember what the distinction is ^.^
--
"Pity for the guilty is treachery to the innocent."
···············@esatclear.ie
http://www.esatclear.ie/~rwallace
>On 30 Dec 2001 10:34:21 +0100, ···@agharta.de (Dr. Edmund Weitz)
>wrote:
>>Would it still be OK to use Hebrew letters for cardinal arithmetic?
Yes, in memory of Georg Cantor, you are permitted the odd aleph nul .
But then we get to use Hebrew too while programming.
At least variables named gimel and yod would be more memorable than
the usual X and Y. And we could have functions named Rambam and
Nachman :-)
In article <··································@4ax.com>,
israel r t <········@optushome.com.au> wrote:
>>On 30 Dec 2001 10:34:21 +0100, ···@agharta.de (Dr. Edmund Weitz)
>>wrote:
>>>Would it still be OK to use Hebrew letters for cardinal arithmetic?
>
>Yes, in memory of Georg Cantor, you are permitted the odd aleph nul .
>But then we get to use Hebrew too while programming.
>
>At least variables named gimel and yod would be more memorable than
>the usual X and Y. And we could have functions named Rambam and
>Nachman :-)
You'd probably enjoy reading the source code to Multics Emacs. It has some
Hebrew, Greek, and even references to Norse mythology (the CATCH tag that
the error handler threw to in order to get back to the top level is
YGGDRASIL, the tree upon which everything in the world is held).
--
Barry Margolin, ······@genuity.net
Genuity, Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
Russell Wallace wrote:
> Well, for a start how about replacing the terms "ordinal" and
> "cardinal" in this context with something less cryptic? I can never
> remember what the distinction is ^.^
Think "order" when you see "ordinal". Ordinals are for measuring
the lengths of well-ordered sequences. The word "cardinality" is
used to mean "size of a set", but I conjecture that if you were
familiar enough with that usage for it to be a helpful mnemonic
then you wouldn't have trouble remembering which of "ordinal"
and "cardinal" is which in the first place. :-)
--
Gareth McCaughan ················@pobox.com
.sig under construc
On Tue, 1 Jan 2002 22:25:56 +0000, ················@pobox.com (Gareth
McCaughan) wrote:
>Think "order" when you see "ordinal". Ordinals are for measuring
>the lengths of well-ordered sequences.
That was the mnemonic I originally tried to use, but then I saw it
being used the other way round; or was the place I read the reverse
usage in error?
What about infinite quantities? I've seen the terms used in that
context too, how does that relate?
--
"Pity for the guilty is treachery to the innocent."
···············@esatclear.ie
http://www.esatclear.ie/~rwallace
Russell Wallace wrote:
> On Tue, 1 Jan 2002 22:25:56 +0000, ················@pobox.com (Gareth
> McCaughan) wrote:
>
> >Think "order" when you see "ordinal". Ordinals are for measuring
> >the lengths of well-ordered sequences.
>
> That was the mnemonic I originally tried to use, but then I saw it
> being used the other way round; or was the place I read the reverse
> usage in error?
>
> What about infinite quantities? I've seen the terms used in that
> context too, how does that relate?
Anything that used "ordinal" for things that measure size
and "cardinal" for things that measure length got it backwards.
Ordinals measure length; cardinals measure size.
This applies *especially* for infinite quantities. Sizes of
finite sets and lengths of finite well-orderings are both
just the non-negative integers, so the distinction doesn't
matter so much for finite quantities as for infinite.
In the infinite realm, provided the axiom of choice holds,
there's an ordinal for every cardinal and also a whole lot
of ordinals in between.
--
Gareth McCaughan ················@pobox.com
.sig under construc
In article <··················@news.eircom.net>, ··@eircom.net (Russell
Wallace) wrote:
> On Fri, 28 Dec 2001 19:09:21 GMT, Ray Blaak <·····@telus.net> wrote:
>
> >This is the worst thing to do, since = has a better meaning as a (kind
> >of)
> >equality predicate. C/C++/Java aside, a dedicated assignment token is
> >preferred, whether :=, setf, set!, whatever.
>
> They should be distinct symbols, but since assignment is used much
> more often than equality testing, it should get the more concise
> symbol.
Not in any of the languages represented by the groups being crossposted
to.
-- Bruce
> Even without parentheses the other task of picking out ":=" is
*relatively*
> easier than the "setf" task. I'm sure that with parentheses *both* tasks
get
> easier, but the relative difference is still there. You can argue that
> adding parenthesese makes both tasks so easy that the relative difference
> becomes meaningless. I personally do not think this is the case.
>
> I don't have any Lisp code handy. However, if you take a larger piece of
> source code and ask humans to underline every occurence of "setf" in it.
It
> will take them longer than a similar task where "setf" is replaced by ":="
> even if you keep prefix notation... i.e.
>
> (:= e1 e2)
> is easier to visually recognize than
>
> (setf e1 e2)
> when dumped in a sea of program text.
(setf e1 e2) is good enough. Is this what constitutes programming language
improvements in peoples minds? Afraid to type a few extra characters? We
end up splitting hairs??? Infix, prefix or postfix, Lisp gets the job done
in a simple way. So there are a few inconsitencies, what is the problem.
Wade
there are some annoying inconsistencies...but...man!...:= vs set! ??
wow...now that is petty...
> > Even without parentheses the other task of picking out ":=" is
> *relatively*
> > easier than the "setf" task. I'm sure that with parentheses *both* tasks
> get
> > easier, but the relative difference is still there. You can argue that
> > adding parenthesese makes both tasks so easy that the relative
difference
> > becomes meaningless. I personally do not think this is the case.
Bob wrote:
>there are some annoying inconsistencies...but...man!...:= vs set! ??
>wow...now that is petty...
Daniel was talking about := vs. 'setf', and I think he's right about that:
it's easier to pick out := from a body of code. (How important that is, is
a separate question.) However, the exclamation mark in set! is similarly
easy to pick out, so the relative advantage of := which Daniel refers to,
doesn't really exist in languages with set!, i.e. Scheme.
Anton
I am neutral on whether its easier.
See some real code that I replaced the setf's. Careful, if your browser
tries to format the files as HTML looks funny, download the code instead.
http://www.cadvision.com/humeniuw/html-report.lisp
http://www.cadvision.com/humeniuw/html-report-nonsetf.lisp
HTML macros at
http://www.cadvision.com/humeniuw/primitive-html.lisp
:= might only stand out because it looks special. If all function-symbols
looked like it none would stand out either.
Wade
"Anton van Straaten" <·····@appsolutions.com> wrote in message
··························@newsread1.prod.itd.earthlink.net...
> Bob wrote:
> >there are some annoying inconsistencies...but...man!...:= vs set! ??
> >wow...now that is petty...
>
> Daniel was talking about := vs. 'setf', and I think he's right about that:
> it's easier to pick out := from a body of code. (How important that is,
is
> a separate question.) However, the exclamation mark in set! is similarly
> easy to pick out, so the relative advantage of := which Daniel refers to,
> doesn't really exist in languages with set!, i.e. Scheme.
>
> Anton
>
>
>
Wade Humeniuk wrote:
>I am neutral on whether its easier.
>
>:= might only stand out because it looks special. If all function-symbols
>looked like it none would stand out either.
Actually, in your example, I thought := *did* stand out better than setf,
but I agree, whether something stands out does depend on what it's
surrounded by, obviously. When I said "it's easier to pick out := from a
body of code", I admit I wasn't thinking of HTMLisp code, which to me, tends
to be hard to read "globally" whether you're using JSP, ASP, PHP, etc., or
some variety of HTML embedded in Lisp.
Anton
Wade Humeniuk wrote:
> I am neutral on whether its easier.
>
> See some real code that I replaced the setf's. Careful, if your browser
> tries to format the files as HTML looks funny, download the code instead.
>
> http://www.cadvision.com/humeniuw/html-report.lisp
>
> http://www.cadvision.com/humeniuw/html-report-nonsetf.lisp
>
> HTML macros at
>
> http://www.cadvision.com/humeniuw/primitive-html.lisp
>
>
> := might only stand out because it looks special. If all function-symbols
> looked like it none would stand out either.
Sidenote: := is the symbol named "=" in the KEYWORD package. So there are
other bad sideeffects on having an operator named like this in Common Lisp.
You _can_ define a function named by a keyword but those are not thought to
get bound to anything.
ciao,
Jochen
--
http://www.dataheaven.de
In article <·····················@newsread1.prod.itd.earthlink.net>,
Anton van Straaten wrote:
>Bob wrote:
>>there are some annoying inconsistencies...but...man!...:= vs set! ??
>>wow...now that is petty...
>
>Daniel was talking about := vs. 'setf', and I think he's right about that:
>it's easier to pick out := from a body of code.
I can't find any study which confirms this hypothesis. It's easier to
come up with hypotheses. For instance, perhaps it's more important to be
able to spot := in a body of code because it's not the leftmost element
of a form, and because there might not be any whitespace surrounding it.
setf's are quite easy to spot in Lisp code, because they are on the left,
because one rarely writes more than one setf on one physical line in Lisp,
and because they are separated by whitespace from what follows.
(How important that is, is
>a separate question.) However, the exclamation mark in set! is similarly
>easy to pick out, so the relative advantage of := which Daniel refers to,
>doesn't really exist in languages with set!, i.e. Scheme.
The Scheme operator set! is not really equivalent to the setf or to a
generic := in another language like Dylan.
The Lisp operator setf can assign to a generalized place. There are many
standard places, and the repertoire of places can be extended by the user.
For example, if you want to assign the integer 42 to the third element
of a list, in Lisp you can do that as
(setf (third L) 42)
or assign to the third element of an array:
(setf (aref A 3) 42)
or to a hash table entry keyed on the string "blorg":
(setf (gethash "blorg" H) 42)
replace characters in string S starting at position 3:
(setf (subseq S 3) "abc")
You see, setf is actually a macro which groks the place form and
generates code for storing a value to it, thus providing a concept
that other languages call an lvalue or whatever. You don't have to
remember a myriad of different assignment operations for every conceivable
data structure that can be destructively manipulated. Moreover, you
can invent new kinds of places and extend setf to handle them in
a standard way.
In scheme, you get a few things like set!, set-car!, set-cdr!
vector-set! and string-set! without any standard, extensible macro to
unify assignment.
Now we are talking semantics, the domain where the truly legitimate
improvements in programming languages happen.
Kaz Kylheku wrote:
> The Scheme operator set! is not really equivalent to the setf or to a
> generic := in another language like Dylan.
An extension to Scheme's set! operator to make it more like setf has
been proposed. See http://srfi.schemers.org/srfi-17/
Whether or not it is a good idea is another question. There doesn't
seem to be any consensus in the Scheme community. I don't know which
Scheme systems implement srfi-17.
>The Scheme operator set! is not really equivalent to the setf or to a
>generic := in another language like Dylan.
Happily, the ! convention easily extends to the names of other mutating
operations.
>The Lisp operator setf can assign to a generalized place. There are many
>standard places, and the repertoire of places can be extended by the user.
This is a nice feature for the level of language which Lisp is, in which the
details of operations are more commonly hidden from the programmer. Pity
it's not called set!, though! ;o)
Anton
In article <·····················@newsread1.prod.itd.earthlink.net>,
Anton van Straaten wrote:
>>The Scheme operator set! is not really equivalent to the setf or to a
>>generic := in another language like Dylan.
>
>Happily, the ! convention easily extends to the names of other mutating
>operations.
>
>>The Lisp operator setf can assign to a generalized place. There are many
>>standard places, and the repertoire of places can be extended by the user.
>
>This is a nice feature for the level of language which Lisp is, in which the
>details of operations are more commonly hidden from the programmer. Pity
>it's not called set!, though! ;o)
You know, many an assembly language allows you to use the same mnemonic
to move data into various kinds of locations. Which is a nice feature
for the level of language it is: one or two levels above binary opcodes.
Kaz Kylheku wrote:
>You know, many an assembly language allows you to use the same mnemonic
>to move data into various kinds of locations. Which is a nice feature
>for the level of language it is: one or two levels above binary opcodes.
That's probably a good analogy: Scheme is perhaps one level "above" the
lambda calculus, and Lisp is at least two. All their differences and the
reasons why those differences *should* exist can be explained by this. The
second level introduces many more choices, thus many more potential
differences in direction.
Anton
Kaz Kylheku <···@ashi.footprints.net> wrote:
+---------------
| > However, the exclamation mark in set! is similarly easy to
| > pick out, so the relative advantage of := which Daniel refers to,
| > doesn't really exist in languages with set!, i.e. Scheme.
|
| The Scheme operator set! is not really equivalent to the setf
| or to a generic := in another language like Dylan.
+---------------
I don't recall anyone saying it was. Scheme "set!" *is*
directly equivalent to the "setq" of Common Lisp, though.
(Though as someone else mentioned, there's a SRFI draft in
the works for adding some "setf"-like functionality to "set!".
So maybe someday...)
-Rob
-----
Rob Warnock, 30-3-510 <····@sgi.com>
SGI Network Engineering <http://www.meer.net/~rpw3/>
1600 Amphitheatre Pkwy. Phone: 650-933-1673
Mountain View, CA 94043 PP-ASEL-IA
[Note: ·········@sgi.com and ········@sgi.com aren't for humans ]
In article <··········@news.newsgroups.com>, Janos Blazi wrote:
>> How many setfs? are in this string
>>
>>
>skdjvsdkjjlksetflkasfjsflsklsdflkjwiescsfjeriosadflksetfkkfslkfjskfjskkksjdf
>liwasetf
>
>Do you come across strings like that frequently in your work? Are you using
>a Lisp *without parentheses*?
Maybe he's using Fortran. When people developed Fortran, compiler writing
was a completely new field. It didn't occur to anyone that removing
all spaces in an early phase of translation was a bad idea. This
led to atrocities, like the infamous:
DOI=1.3
versus
DOI=1,3
The first means assign 1.3 to variable DOI. The second indicates the
start of a DO loop over the variable I from 1 to 3.
In article <·················@quiotix.com>, Jeffrey Siegal
<···@quiotix.com> wrote:
> Andreas Bogk wrote:
> > I suggest to take a look at Dylan. It's a pretty recent Lisp-like
> > language, and it's got a few things right (but on the other hand
> > omitted some features some people consider essential).
>
> I consider Lisp syntax (or something similarly elegant) to be
> essential. I suspect that many proponents of Dylan-like languages would
> consider it unacceptable. I strongly suspect there is no middle ground.
I can happily use either. Or paren-less prefix (Logo, ML). Or postfix
(PostScript, Forth). But even after much use of the others I find that
I do prefer "conventional" syntax.
> (Yes, I'm aware of Lisp-syntax Dylan, but I think there's a reason it
> got abandoned.)
The reason as I understand it is that no one could figure out how to
bidirectionally map macros between infix and prefix.
I'm not sure whether this is impossible or merely hard.
It's interesting that some of the more complex macros in Common Lisp
look uncommonly like the "infix" syntax in Dylan. e.g. the "loop"
macro, which is nearly identical to the Dylan "for" statement macro.
Thus it might be acceptable to the Lisp-syntax people to essentially
retain (nearly?) the same syntax for statement macros in both modes.
Function macros are easy to translate. That leaves Dylan's declaration
macros to think about.
Another solution might be to explicitly define both syntaxes when you
define a macro. More work, but then you don't define new syntax quite
as often as you define functions.
-- Bruce
Bruce Hoult wrote:
>>Andreas Bogk wrote:
>>
>>>I suggest to take a look at Dylan. It's a pretty recent Lisp-like
>>>language, and it's got a few things right (but on the other hand
>>>omitted some features some people consider essential).
>>>
>>I consider Lisp syntax (or something similarly elegant) to be
>>essential. I suspect that many proponents of Dylan-like languages would
>>consider it unacceptable. I strongly suspect there is no middle ground.
>
> I can happily use either. Or paren-less prefix (Logo, ML). Or postfix
> (PostScript, Forth). But even after much use of the others I find that
> I do prefer "conventional" syntax.
It isn't a question of using. It is a question of being able to define
new syntax without stretching or breaking the inherent limits of the
existing syntax. Lisp lives essentially forever in the world of
computer languages because it almost can't be outgrown. To the extent
that Dylan lives at all, it will still die when the world decides that
objects aren't that central to programming after all, and moves on to
some other model, or when someone comes up with a new syntactic
construct that it is incompatible with Dylan's syntax. Lisp will live on.
>>(Yes, I'm aware of Lisp-syntax Dylan, but I think there's a reason it
>>got abandoned.)
>
> The reason as I understand it is that no one could figure out how to
> bidirectionally map macros between infix and prefix.
>
> I'm not sure whether this is impossible or merely hard.
And the reason the decision was made to drop prefix rather than infix
when that happened was the overriding goal of trying to sell Dylan
alongside Java or C as a language for the great masses. (Which today
seems utterly absurd.)
Many smart people have observed that when you encounter a "hard" (if not
impossible) problem, you have already made a mistake somewhere back down
the road. Trying to "add" an infix syntax without recognizing that this
almost certainly means losing expressive power and generality was just
such a mistake.
> Another solution might be to explicitly define both syntaxes when you
> define a macro. More work, but then you don't define new syntax quite
> as often as you define functions.
That would be very error prone.
In article <················@quiotix.com>, Jeffrey Siegal
<···@quiotix.com> wrote:
> Bruce Hoult wrote:
>
> >>Andreas Bogk wrote:
> >>
> >>>I suggest to take a look at Dylan. It's a pretty recent Lisp-like
> >>>language, and it's got a few things right (but on the other hand
> >>>omitted some features some people consider essential).
> >>>
> >>I consider Lisp syntax (or something similarly elegant) to be
> >>essential. I suspect that many proponents of Dylan-like languages would
> >>consider it unacceptable. I strongly suspect there is no middle ground.
> >
> > I can happily use either. Or paren-less prefix (Logo, ML). Or postfix
> > (PostScript, Forth). But even after much use of the others I find that
> > I do prefer "conventional" syntax.
>
> It isn't a question of using. It is a question of being able to define
> new syntax without stretching or breaking the inherent limits of the
> existing syntax. Lisp lives essentially forever in the world of
> computer languages because it almost can't be outgrown.
That's true only in the trivial sense that Lisp has no syntax, so Lisp
syntax can't be outgrown. Dylan has pretty much all the same semantics
as Lisp, and a malleable syntax.
> To the extent
> that Dylan lives at all, it will still die when the world decides that
> objects aren't that central to programming after all, and moves on to
> some other model, or when someone comes up with a new syntactic
> construct that it is incompatible with Dylan's syntax. Lisp will live on.
There is no such construct. If it can be fitted into Lisp's
functions-only notation then it can also be fitted into Dylan's
functions and function-macros. In Dylan in may well be *better* fitted
into statement macros, but that's an additional possibility, not a
restriction.
> >>(Yes, I'm aware of Lisp-syntax Dylan, but I think there's a reason it
> >>got abandoned.)
> >
> > The reason as I understand it is that no one could figure out how to
> > bidirectionally map macros between infix and prefix.
> >
> > I'm not sure whether this is impossible or merely hard.
>
> And the reason the decision was made to drop prefix rather than infix
> when that happened was the overriding goal of trying to sell Dylan
> alongside Java or C as a language for the great masses. (Which today
> seems utterly absurd.)
Why? Since that decision was made, the great masses have adopted both
Java and Perl, while Lisp has remained in the wilderness. I don't see
any reason to think that infix syntax is a *disadvantage* to the goal of
attaining popularity. The time may simply be not yet right. After all,
it is only just now that reasonably mature Dylan implementations are
becoming available.
> Many smart people have observed that when you encounter a "hard" (if not
> impossible) problem, you have already made a mistake somewhere back down
> the road.
Or no one had the correct "ah-ha" moment yet.
> Trying to "add" an infix syntax without recognizing that this
> almost certainly means losing expressive power and generality was just
> such a mistake.
In your opinion.
> > Another solution might be to explicitly define both syntaxes when you
> > define a macro. More work, but then you don't define new syntax quite
> > as often as you define functions.
>
> That would be very error prone.
A great many things in programming are error prone. In fact anything in
which it is impossible to make a mistake is almost certainly not
powerful enough to be useful. It is reasonable to expect that
programmers have *some* skill. Also, even if a compiler can't
reasonably translate an infix macro to a prefix macro (or the reverse),
it seems entirely reasonable for it to apply some consistency checks to
two such macros supplied by a human.
-- Bruce
Bruce Hoult wrote:
> That's true only in the trivial sense that Lisp has no syntax, so Lisp
> syntax can't be outgrown.
Hardly. It just has a syntax with a very simple and powerful basic
construction rule. However, on top of that construction rule,
enormously powerful syntactic abstractions can be (and are) built. What
Algol-like languages lack is the basic construction rule which allows
you to decompose the syntax down into elemental componets. That makes
any macro system either enormously complex or lacking in power, or both.
Consider, for example, what low-level Lisp macros would look like in an
Algol-like language. They can be done but the result is enormously
complex (and also fragile; if the language syntax is extended, macros
written that way will likely break).
> There is no such construct. If it can be fitted into Lisp's
> functions-only notation then it can also be fitted into Dylan's
> functions and function-macros.
Of course it can, just as you could write a Lisp interpreter in Dylan
and use that. But at some point it becomes language-abuse, not
language-use, becuause the facilities the language provides to help you
end up either being in the way, or being useless warts. I can tell you
from experience that trying to do extremely complex things with
function-style macros in an Algol-like language is far, far worse than
doing the same thing in Lisp, since such things are a natural extension
of the Lisp syntax but stronly conflict with the flavor of an
Algol-style langauge. Yes, it can be done that way, but it might as
well not be possible because no one will want to use it.
> > And the reason the decision was made to drop prefix rather than infix
> > when that happened was the overriding goal of trying to sell Dylan
> > alongside Java or C as a language for the great masses. (Which today
> > seems utterly absurd.)
>
> Why?
I didn't mean the decision was absurd at the time, just that the
possiblity of Dylan being sold to the great masses today is absurd.
Dylan is a useful niche language, which is all it will ever be. As a
niche language, though, you don't need to sell it with a candy-coated
syntax. I might be using it today if the Lisp syntax had been retained,
but I have no interest whatsoever in an Algol-syntax niche langauge. If
I'm going to use such a langauge, it is going to at least be a
mainstream one with all of the benefits that acrue from that status
(i.e., all things considered I'd rather use Java, and I do, than Dylan,
despite recognizing that Dylan is a much nicer language).
> Since that decision was made, the great masses have adopted both
> Java and Perl, while Lisp has remained in the wilderness. I don't see
> any reason to think that infix syntax is a *disadvantage* to the goal of
> attaining popularity.
I wasn't suggesting that.
> The time may simply be not yet right. After all,
> it is only just now that reasonably mature Dylan implementations are
> becoming available.
With all due respect, I think you are dreaming, and I think some honest
self-reflection would confirm that.
> > Many smart people have observed that when you encounter a "hard" (if not
> > impossible) problem, you have already made a mistake somewhere back down
> > the road.
>
> Or no one had the correct "ah-ha" moment yet.
Taking a path which requires an as-yet-unknown "ah ha" to suceed is a
design error. It is those moments which make new paths feasible. Blind
leaps occasionally do lead there (I'm a big fan of evoluationary
learning), but when they don't, you should be willing to accept that the
leap was a mistake and backtrack.
> > Trying to "add" an infix syntax without recognizing that this
> > almost certainly means losing expressive power and generality was just
> > such a mistake.
>
> In your opinion.
Absolutely true.
> > > Another solution might be to explicitly define both syntaxes when you
> > > define a macro. More work, but then you don't define new syntax quite
> > > as often as you define functions.
> >
> > That would be very error prone.
>
> A great many things in programming are error prone. In fact anything in
> which it is impossible to make a mistake is almost certainly not
> powerful enough to be useful. It is reasonable to expect that
> programmers have *some* skill.
Requiring a programmer to maintain two distinct pieces of code which are
supposed to have the same effect is something that experience shows to
be extremely difficult and error prone. As development practices go,
such an approach is best avoided.
Jeffrey Siegal <···@quiotix.com> writes Re: New Lisp ?
> Consider, for example, what low-level Lisp macros would look like in an
> Algol-like language. They can be done but the result is enormously
> complex (and also fragile; if the language syntax is extended, macros
> written that way will likely break).
I wonder what you think or someone who knows them as well as LISP macros
thinks of CamlP4 or of parse-tree filtering in Erlang.
These may not be as seamlessly integrated in their mother language as are
LISP macros, but they look very promising.
[ Fran�ois-Ren� �VB Rideau | Reflection&Cybernethics | http://fare.tunes.org ]
[ TUNES project for a Free Reflective Computing System | http://tunes.org ]
A language that doesn't affect the way you think about programming,
is not worth knowing. -- Alan Perlis
From: Jeffrey Siegal
Subject: Re: Macros in LISP and other languages
Date:
Message-ID: <3C2A3413.30206@quiotix.com>
Francois-Rene Rideau wrote:
>>Consider, for example, what low-level Lisp macros would look like in an
>>Algol-like language. They can be done but the result is enormously
>>complex (and also fragile; if the language syntax is extended, macros
>>written that way will likely break).
>>
> I wonder what you think or someone who knows them as well as LISP macros
> thinks of CamlP4 or of parse-tree filtering in Erlang.
I have not looked at them before so I am not very familar with them. I
looked quickly at CamlP4 and it looked very similar to what I've seen
before in terms of attempts to do this. In particular, fairly complex,
and requiring the programmer to understand quite a bit about parsing
theory and practice (an interesting field, but not one that every
programmer necessarily knows about or wants to know about).
Anyone who can not see that the complexity of such things is a strong
argument in favor of a simple Lisp-like syntax[*] is blind or
prejudiced. Perhaps not an overriding argument that would cause one to
use a Lisp-syntax despite other issues, but still...
[*] By "Lisp-like" syntax I mean a syntax that can be constructed and
decomposed using a few simple, easy-to-understand rules. It doesn't
neceessarily need to be Lisp-syntax itself. For example, it might use
indentation rather than parenthesis to indicate nesting. Or it might be
something else. But whatever it is, it should reduce to some sort of
logical and simple internal form, not some mostly random collection of
Algol-like constructs that exist largely the result of a string of
historical accidents.
In article <·················@Samaris.tunes.org>, Francois-Rene Rideau wrote:
>Jeffrey Siegal <···@quiotix.com> writes Re: New Lisp ?
>> Consider, for example, what low-level Lisp macros would look like in an
>> Algol-like language. They can be done but the result is enormously
>> complex (and also fragile; if the language syntax is extended, macros
>> written that way will likely break).
>I wonder what you think or someone who knows them as well as LISP macros
>thinks of CamlP4 or of parse-tree filtering in Erlang.
Once you introduce parse tree filtering, don't you think that users will
eventually want a way to specify any arbitrary parse tree, not just ones
that correspond to the few shapes determined by a hardcoded parser?
Then you are looking at some bracketed notation.
In article <·················@quiotix.com>, Jeffrey Siegal
<···@quiotix.com> wrote:
> Bruce Hoult wrote:
> > That's true only in the trivial sense that Lisp has no syntax, so Lisp
> > syntax can't be outgrown.
>
> Hardly. It just has a syntax with a very simple and powerful basic
> construction rule. However, on top of that construction rule,
> enormously powerful syntactic abstractions can be (and are) built. What
> Algol-like languages lack is the basic construction rule which allows
> you to decompose the syntax down into elemental componets. That makes
> any macro system either enormously complex or lacking in power, or both.
>
> Consider, for example, what low-level Lisp macros would look like in an
> Algol-like language. They can be done but the result is enormously
> complex (and also fragile; if the language syntax is extended, macros
> written that way will likely break).
There are examples of the same thing happening in reverse. When macros
get sufficiently complex and have enough combinations of different
possibilities, it becomes too difficult to follow a purely S-expresion
syntax. Consider the example of the Dylan "for" macro. How would you
map all that functionality and all those options onto an S-expression
syntax? Well, we can look at what is done in Common Lisp with the
"loop" macro. The same idea, very nearly exactly the same options. And
we find that in fact it does *not* use S-expression syntax, but instead
makes a little infix language that ends up very similar to that part of
Dylan.
As you say: "at some point it becomes language-abuse, not language-use".
Now, I happen to think that the "loop" macro is a *good* thing about
Common Lisp, but:
1) building such things yourself isn't well supported in CL (it is in
Dylan)
2) I find that I actually *prefer* this sort of thing to have infix
syntax, and prefer all loops and other control structures to use it. If
nothing else, it means that you know immediately whether you're looking
at a standard function application or a special form. That's what Dylan
does.
> > There is no such construct. If it can be fitted into Lisp's
> > functions-only notation then it can also be fitted into Dylan's
> > functions and function-macros.
>
> Of course it can, just as you could write a Lisp interpreter in Dylan
> and use that. But at some point it becomes language-abuse, not
> language-use, becuause the facilities the language provides to help you
> end up either being in the way, or being useless warts. I can tell you
> from experience that trying to do extremely complex things with
> function-style macros in an Algol-like language is far, far worse than
> doing the same thing in Lisp
Which algol-like language?
> I didn't mean the decision was absurd at the time, just that the
> possiblity of Dylan being sold to the great masses today is absurd.
> Dylan is a useful niche language, which is all it will ever be.
Presumably, then, you feel the same way about Lisp?
> As a niche language, though, you don't need to sell it with a
> candy-coated syntax. I might be using it today if the Lisp syntax
> had been retained, but I have no interest whatsoever in an
> Algol-syntax niche langauge.
*You* may not, but not everyone feels that way. Apart from Dylan, there
are people out there using OCaml, Haskell and a bunch of lesser-known
niche languages with Algol-like syntaxes. Not all of them intend to
remain niche languages.
> If I'm going to use such a langauge, it is going to at least be a
> mainstream one with all of the benefits that acrue from that status
> (i.e., all things considered I'd rather use Java, and I do, than Dylan,
> despite recognizing that Dylan is a much nicer language).
Half a dozen years ago Java wasn't mainstream. A dozen years ago (when
I started using it) C++ wasn't mainstream. The same goes for Perl
before the WWW happened. Plenty of languages have made the transition
from niche to mainstream in the past, and there is every reason to think
that plenty more will in the future. C++ and Perl and Java are not the
last word in language design for the masses.
> > The time may simply be not yet right. After all, it is only just
> > now that reasonably mature Dylan implementations are becoming
> > available.
>
> With all due respect, I think you are dreaming, and I think some honest
> self-reflection would confirm that.
Dreaming in what respect? Are you saying that reasonably mature Dylan
implementations are not yet available? Or that they have been for some
time? Or something else?
I'm certainly under no illusions that "a reasonably mature
implementation" is sufficient for market success. But it's surely
necessary.
> > > Many smart people have observed that when you encounter a "hard"
> > > (if not impossible) problem, you have already made a mistake
> > > somewhere back down the road.
> >
> > Or no one had the correct "ah-ha" moment yet.
>
> Taking a path which requires an as-yet-unknown "ah ha" to suceed is a
> design error.
I agree. And that path -- attempting to support both infx and prefix
syntaxes -- has *not* been taken. A clean switch was made from one to
the other.
> > > > Another solution might be to explicitly define both syntaxes
> > > > when you define a macro. More work, but then you don't define
> > > > new syntax quite as often as you define functions.
> > >
> > > That would be very error prone.
> >
> > A great many things in programming are error prone. In fact
> > anything in which it is impossible to make a mistake is almost
> > certainly not powerful enough to be useful. It is reasonable to
> > expect that programmers have *some* skill.
>
> Requiring a programmer to maintain two distinct pieces of code which are
> supposed to have the same effect is something that experience shows to
> be extremely difficult and error prone. As development practices go,
> such an approach is best avoided.
Mainstream programmers are expected to keep functions and prototypes in
synch. They are expected to maintain quite complex invariants over
large bodies of code, usually without benefit of anything more powerful
than "assert". They are expected to declare the type of a variable in
one place and then use it appropriately in other places. They are
expected to make sure that variables are correctly initialized over all
execution paths. They are expected to explicitly free dynamic memory at
those points -- and only those points -- where it is no longer needed.
Compared to some of those, correctly setting up alternate syntaxes in
the odd macro definition is hardly onerous or error-prone. And it might
be totally optional -- needed *only* if you want to use both. Most
mainstream programmers would presumably be satisfied with the Algol-like
syntax in the first place.
-- Bruce
Bruce Hoult wrote:
> There are examples of the same thing happening in reverse. When macros
> get sufficiently complex and have enough combinations of different
> possibilities, it becomes too difficult to follow a purely S-expresion
> syntax.
Not in my experience. YMMV.
> Consider the example of the Dylan "for" macro. How would you
> map all that functionality and all those options onto an S-expression
> syntax?
I haven't looked closely at the Dylan for macro, but I suspect by not
including all that functionality into a single construct.
> > > There is no such construct. If it can be fitted into Lisp's
> > > functions-only notation then it can also be fitted into Dylan's
> > > functions and function-macros.
> >
> > Of course it can, just as you could write a Lisp interpreter in Dylan
> > and use that. But at some point it becomes language-abuse, not
> > language-use, becuause the facilities the language provides to help you
> > end up either being in the way, or being useless warts. I can tell you
> > from experience that trying to do extremely complex things with
> > function-style macros in an Algol-like language is far, far worse than
> > doing the same thing in Lisp
>
> Which algol-like language?
C (preprocessor macros) and Java (a proprietary preprocessor). Other
people have done similar things with C++ templates and the result is
similarly unwieldy.
> > I didn't mean the decision was absurd at the time, just that the
> > possiblity of Dylan being sold to the great masses today is absurd.
> > Dylan is a useful niche language, which is all it will ever be.
>
> Presumably, then, you feel the same way about Lisp?
Absolutely.
> > If I'm going to use such a langauge, it is going to at least be a
> > mainstream one with all of the benefits that acrue from that status
> > (i.e., all things considered I'd rather use Java, and I do, than Dylan,
> > despite recognizing that Dylan is a much nicer language).
>
> Half a dozen years ago Java wasn't mainstream. A dozen years ago (when
> I started using it) C++ wasn't mainstream. The same goes for Perl
> before the WWW happened. Plenty of languages have made the transition
> from niche to mainstream in the past, and there is every reason to think
> that plenty more will in the future. C++ and Perl and Java are not the
> last word in language design for the masses.
That's all true, but for every language that "breaks out" there are a
zillion that don't, and those that break out generally have a big
promoter, though there are occasional exceptions, on the order of
perhaps one per decade. Not unlike pop artists.
> > > The time may simply be not yet right. After all, it is only just
> > > now that reasonably mature Dylan implementations are becoming
> > > available.
> >
> > With all due respect, I think you are dreaming, and I think some honest
> > self-reflection would confirm that.
>
> Dreaming in what respect? Are you saying that reasonably mature Dylan
> implementations are not yet available? Or that they have been for some
> time? Or something else?
That Dylan is going to go mainstream when "the time is right", and also
about reasonably mature implementations becoming available "just now."
I consider Harlequin's product to have been "reasonably mature" some
time ago.
Dylan will almost certainly never break into the mainstream without a
big promoter. The opportunity was largely lost when Apple dropped it.
Perhaps with Apple's backing it could have given Java a good run, but
without it, no way.
Jeffrey Siegal <···@quiotix.com> writes:
> Dylan will almost certainly never break into the mainstream without a
> big promoter. The opportunity was largely lost when Apple dropped it.
> Perhaps with Apple's backing it could have given Java a good run, but
> without it, no way.
It need not be a commercial promoter. I think there are enough people
out there (and I guess a lot of them are reading these newsgroups) who
wish there was something like a modern LISP machine, or more
realistically, an operating system running on commodity hardware that
was written from scratch in a dynamic language. There might be enough
people (and smart enough people) to start the next Linux, who knows?
If such an OS (and especially it's APIs) would allow for multiple
syntaxes, or even multiple languages, it would appeal both to the
experts and to the masses.
Andreas
--
"In my eyes it is never a crime to steal knowledge. It is a good
theft. The pirate of knowledge is a good pirate."
(Michel Serres)
Andreas Bogk wrote:
> It need not be a commercial promoter. I think there are enough people
> out there (and I guess a lot of them are reading these newsgroups) who
> wish there was something like a modern LISP machine, or more
> realistically, an operating system running on commodity hardware that
> was written from scratch in a dynamic language. There might be enough
> people (and smart enough people) to start the next Linux, who knows?
I agree with this.
However, Dylan is so far from that it might as well be in the next
universe. You've got a much better shot with Java, frankly.
Jeffrey Siegal <···@quiotix.com> writes:
> However, Dylan is so far from that it might as well be in the next
> universe. You've got a much better shot with Java, frankly.
Java might get the masses, but it's not in the heart of the wizards.
But it's the wizards who would be able to start such a project.
Andreas
--
"In my eyes it is never a crime to steal knowledge. It is a good
theft. The pirate of knowledge is a good pirate."
(Michel Serres)
On 27 Dec 2001 06:53:45 +0100, Andreas Bogk <·······@andreas.org>
wrote:
>Jeffrey Siegal <···@quiotix.com> writes:
>
>> However, Dylan is so far from that it might as well be in the next
>> universe. You've got a much better shot with Java, frankly.
>
>Java might get the masses, but it's not in the heart of the wizards.
>But it's the wizards who would be able to start such a project.
Dont be so sure...
The Demeter project and aspectj ( adaptive and aspect oriented
programming using extensions to java ) may spawn the next step after
oop and functional programming. It is certainly wizardly enough for
me
http://www.ccs.neu.edu/research/demeter/
http://aspectj.org
Andreas Bogk <·······@andreas.org> writes:
> I think there are enough people out there (and I guess a lot of them
> are reading these newsgroups) who wish there was something like a
> modern LISP machine, or more realistically, an operating system
> running on commodity hardware that was written from scratch in a
> dynamic language. There might be enough people (and smart enough
> people) to start the next Linux, who knows?
>
> If such an OS (and especially it's APIs) would allow for multiple
> syntaxes, or even multiple languages, it would appeal both to the
> experts and to the masses.
If C were a dynamic language, you wouldn't have to write the operating
system from scratch, since Unix is based on C. So, what do you regard
as a dynamic language? I'd guess: a memory-safe language with garbage
collection, dynamic types, dynamic code replacement, perhaps
persistence; what else?
Somewhat surprisingly, it's possible to give C these properties: I've
devised a scheme for translating C programs into memory-safe programs,
and I'm writing a C compiler to do this. The same technique could
also be used to turn filenames into capabilities (ie. object
references), which would be very useful for building the sort of
operating system you're talking about from existing Unix programs.
Have a look at <http://www.srcf.ucam.org/~mrs35/comp/safe-c/> for more
details.
--
Mark Seaborn
- ········@bigfoot.com - http://www.srcf.ucam.org/~mrs35/ -
``Every revolutionary opinion draws part of its strength from a secret
conviction that nothing can be changed'' -- George Orwell
Mark Seaborn wrote:
> Somewhat surprisingly, it's possible to give C these properties: I've
> devised a scheme for translating C programs into memory-safe programs,
> and I'm writing a C compiler to do this.
There was a C compiler for Lisp machines that worked this way.
Mark Seaborn wrote:
> If C were a dynamic language, you wouldn't have to write the operating
> system from scratch, since Unix is based on C. So, what do you regard
> as a dynamic language? I'd guess: a memory-safe language with garbage
> collection, dynamic types, dynamic code replacement, perhaps
> persistence; what else?
>
> Somewhat surprisingly, it's possible to give C these properties: I've
> devised a scheme for translating C programs into memory-safe programs,
> and I'm writing a C compiler to do this. ...
Have you seen Single-Assignment C?
http://www.informatik.uni-kiel.de/~sacbase/
Andreas Bogk <·······@andreas.org> writes:
> I think there are enough people
> out there (and I guess a lot of them are reading these newsgroups) who
> wish there was something like a modern LISP machine, or more
> realistically, an operating system running on commodity hardware that
> was written from scratch in a dynamic language.
Depends on what you mean by a 'Dynamic Language'. The Smalltalk
environment was (and still is) essentially a complete O/S. Java has a
similiar view of the world. Neither of those would satisfy me. What
I'd like to see is an O/S with kernel support for GC and continuation
capture, written in a language which make access to the hardware as
easy as C. Right now I think that some Scheme dialect is the best
contender for this, although SML is a close second.
> If such an OS (and especially it's APIs) would allow for multiple
> syntaxes, or even multiple languages, it would appeal both to the
> experts and to the masses.
This is why I define the O/S in terms of API features.
david rush
--
With guns, we are citizens. Without them, we are subjects.
-- YZGuy, IPL
In article <·················@quiotix.com>, Jeffrey Siegal
<···@quiotix.com> wrote:
> Bruce Hoult wrote:
> > Consider the example of the Dylan "for" macro. How would you
> > map all that functionality and all those options onto an S-expression
> > syntax?
>
> I haven't looked closely at the Dylan for macro, but I suspect by not
> including all that functionality into a single construct.
Which wouldn't be very satisfactory.
Both CL's "loop" and Dylan's "for" are basically similar to "do" in
Scheme, in that they allow you to iterate with a number of variables
updated in parallel. But unlike Scheme they allow not just "var = init
then update-expression", but also automatic stepping through numeric
ranges ("var from foo to bar by baz") and multiple termination tests.
CL allows stepping through lists and hashes, Dylan allows stepping
through arbitrary collections. CL allows collecting expressions into a
result list (or summing them).
It's hard to see how to decompose this functionality into different
constructs while still allowing different loop variables to
simultaneously be controlled in different ways. Which is very desirable.
On the other hand, Scheme's "do" is already near the limits of
S-expression comprehensibility. Trying to extend it to do what Dylan's
"for" or CL's "loop" do would I think take it well past.
> > > I can tell you
> > > from experience that trying to do extremely complex things with
> > > function-style macros in an Algol-like language is far, far worse
> > > than doing the same thing in Lisp
> >
> > Which algol-like language?
>
> C (preprocessor macros) and Java (a proprietary preprocessor). Other
> people have done similar things with C++ templates and the result is
> similarly unwieldy.
I agree in each of those cases.
None of those language syntaxes (well, basically the same one) were
designed to be amenable to sophisticated macro processing. Dylan's
*was*. All the declarations and control structures were designed from
the outset to be implemented as macros. And in d2c, at least, they are.
> > > I didn't mean the decision was absurd at the time, just that the
> > > possiblity of Dylan being sold to the great masses today is absurd.
> > > Dylan is a useful niche language, which is all it will ever be.
> >
> > Presumably, then, you feel the same way about Lisp?
>
> Absolutely.
Fair enough then.
> > > If I'm going to use such a langauge, it is going to at least be a
> > > mainstream one with all of the benefits that acrue from that status
> > > (i.e., all things considered I'd rather use Java, and I do, than
> > > Dylan,
> > > despite recognizing that Dylan is a much nicer language).
> >
> > Half a dozen years ago Java wasn't mainstream. A dozen years ago (when
> > I started using it) C++ wasn't mainstream. The same goes for Perl
> > before the WWW happened. Plenty of languages have made the transition
> > from niche to mainstream in the past, and there is every reason to
> > think
> > that plenty more will in the future. C++ and Perl and Java are not the
> > last word in language design for the masses.
>
> That's all true, but for every language that "breaks out" there are a
> zillion that don't,
Sure.
> and those that break out generally have a big promoter
Actually, that appears to be the exception. Java had huge promotion. C
and C++ might have been from AT&T but they can't really be said to have
*promoted* them. The authors pushed them personally, just as Larry Wall
did with Perl and Guido did with Python.
> > > > The time may simply be not yet right. After all, it is only just
> > > > now that reasonably mature Dylan implementations are becoming
> > > > available.
> > >
> > > With all due respect, I think you are dreaming, and I think some
> > > honest self-reflection would confirm that.
> >
> > Dreaming in what respect? Are you saying that reasonably mature Dylan
> > implementations are not yet available? Or that they have been for some
> > time? Or something else?
>
> That Dylan is going to go mainstream when "the time is right",
I certianly wouldn't put it as strongly as "is going to". "Might have a
shot" is more like it.
> and also
> about reasonably mature implementations becoming available "just now."
> I consider Harlequin's product to have been "reasonably mature" some
> time ago.
Yes, but it's only been on one OS -- and technical people's least
favourite one, at that.
They now have a Linux beta out, which is good.
Gwydion is on probably every interesting platform: Un*x, MacOS, MacOS X,
Windows (Cywwin), BeOS. But it's not as mature as Harlequin/Fun-O and
won't be in a position to even attempt to "break out" for a year or two
yet at the curren rate.
> Dylan will almost certainly never break into the mainstream without a
> big promoter. The opportunity was largely lost when Apple dropped it.
That was a sad day, yes. And it's taking a while to recover from. The
good news is that 1) the implementations are getting there, and 2) most
mainstream people have never even heard of it, so when we're ready it'll
be "new" to them, not recycled.
> Perhaps with Apple's backing it could have given Java a good run, but
> without it, no way.
It's a long shot, for sure. I think that probably OCaml has a better
shot at it. Maybe Erlang, with its big backer. Both those are probably
a bit cryptic for the average punter though. We get people turning up
on the Gwydion mailing list saying things like "I never saw Dylan before
but I just browsed through [the compiler | your ICFP entry] and I COULD
ACTUALLY UNDERSTAND IT".
-- Bruce
Bruce Hoult wrote:
> Which wouldn't be very satisfactory.
>
> Both CL's "loop" and Dylan's "for" are basically similar to "do" in
> Scheme, in that they allow you to iterate with a number of variables
> updated in parallel. But unlike Scheme they allow not just "var = init
> then update-expression", but also automatic stepping through numeric
> ranges ("var from foo to bar by baz") and multiple termination tests.
> CL allows stepping through lists and hashes, Dylan allows stepping
> through arbitrary collections. CL allows collecting expressions into a
> result list (or summing them).
>
> It's hard to see how to decompose this functionality into different
> constructs while still allowing different loop variables to
> simultaneously be controlled in different ways. Which is very desirable.
>
> On the other hand, Scheme's "do" is already near the limits of
> S-expression comprehensibility. Trying to extend it to do what Dylan's
> "for" or CL's "loop" do would I think take it well past.
It isn't as if I started programming yesterday, and I just don't see the
need for all that nonsense. Frankly, I rarely even use the Scheme do
macro. The basic iteration mechanisms are usually powerful enough for
me, and if I need something specific for a particular use, I build it.
If I want to step by 57 and I don't feel like doing it explicitly, I'll
build a loop-by-57 form.
Mostly, though, I don't explicitly iterate very much, prefering
map-style approaches, or when I have to use a collection that doesn't
implement that, and don't care much about performance, I'll just resort
to generating a list and using map or for-each themselves. (And with a
good compiler, the cost of doing this may be small anyway.) For example,
I have a private collection of map-style iterators for matrices that
allow various degress of control over stepping and so forth. I find the
overall approach far superior to a for or loop type widget. But, YMMV,
of course.
> > > > I can tell you
> > > > from experience that trying to do extremely complex things with
> > > > function-style macros in an Algol-like language is far, far worse
> > > > than doing the same thing in Lisp
> > >
> > > Which algol-like language?
> >
> > C (preprocessor macros) and Java (a proprietary preprocessor). Other
> > people have done similar things with C++ templates and the result is
> > similarly unwieldy.
>
> I agree in each of those cases.
>
> None of those language syntaxes (well, basically the same one) were
> designed to be amenable to sophisticated macro processing. Dylan's
> *was*. All the declarations and control structures were designed from
> the outset to be implemented as macros. And in d2c, at least, they are.
You've confused yourself. We were discussing your claim that Dylan
could do anything that Lisp can do because it has function-style
macros. Resorting to function-style macros leaves you in essentially
the same place as doing function-style macros in C or Java or C++.
> Actually, that appears to be the exception. Java had huge promotion. C
> and C++ might have been from AT&T but they can't really be said to have
> *promoted* them.
C was the exception of the 80s. C++ was heavily promoted by Microsoft
(and the other Windows compiler vendors, when there were any). Perl was
perhaps the exception of the 90s (I consider Perl marginal and Python to
be clearly niche).
In article <·················@quiotix.com>, Jeffrey Siegal
<···@quiotix.com> wrote:
> Bruce Hoult wrote:
> > Which wouldn't be very satisfactory.
> >
> > Both CL's "loop" and Dylan's "for" are basically similar to "do" in
> > Scheme, in that they allow you to iterate with a number of variables
> > updated in parallel. But unlike Scheme they allow not just "var = init
> > then update-expression", but also automatic stepping through numeric
> > ranges ("var from foo to bar by baz") and multiple termination tests.
> > CL allows stepping through lists and hashes, Dylan allows stepping
> > through arbitrary collections. CL allows collecting expressions into a
> > result list (or summing them).
> >
> > It's hard to see how to decompose this functionality into different
> > constructs while still allowing different loop variables to
> > simultaneously be controlled in different ways. Which is very
> > desirable.
> >
> > On the other hand, Scheme's "do" is already near the limits of
> > S-expression comprehensibility. Trying to extend it to do what Dylan's
> > "for" or CL's "loop" do would I think take it well past.
>
> It isn't as if I started programming yesterday, and I just don't see the
> need for all that nonsense. Frankly, I rarely even use the Scheme do
> macro. The basic iteration mechanisms are usually powerful enough for
> me, and if I need something specific for a particular use, I build it.
> If I want to step by 57 and I don't feel like doing it explicitly, I'll
> build a loop-by-57 form.
I suspect that this is pretty much where Scheme people on one hand and
CL and Dylan people on the other hand part ways. Everyone appreciates
generality and power when they need them, but the latter two groups also
value notational convenience for the common cases. Dylan expands the
"for" macro into a tail-recursive function (and CL does something
similar) precisely because many people find that easier to write, read,
and understand than the explicit tail-recursive form, for most common
cases.
> > > > > I can tell you
> > > > > from experience that trying to do extremely complex things with
> > > > > function-style macros in an Algol-like language is far, far worse
> > > > > than doing the same thing in Lisp
> > > >
> > > > Which algol-like language?
> > >
> > > C (preprocessor macros) and Java (a proprietary preprocessor). Other
> > > people have done similar things with C++ templates and the result is
> > > similarly unwieldy.
> >
> > I agree in each of those cases.
> >
> > None of those language syntaxes (well, basically the same one) were
> > designed to be amenable to sophisticated macro processing. Dylan's
> > *was*. All the declarations and control structures were designed from
> > the outset to be implemented as macros. And in d2c, at least, they
> > are.
>
> You've confused yourself. We were discussing your claim that Dylan
> could do anything that Lisp can do because it has function-style
> macros. Resorting to function-style macros leaves you in essentially
> the same place as doing function-style macros in C or Java or C++.
Rather better off, I think, since the C and C++ preprocessor is crap and
Java doesn't have one at all. Macro expansion in Dylan is *far* better
behaved, since it is hygenic and obeys lexical scoping (both with
respect to which macro is in scope where, and respecting the scoping of
arguments to the macro).
> > Actually, that appears to be the exception. Java had huge promotion.
> > C and C++ might have been from AT&T but they can't really be said
> > to have *promoted* them.
>
> C was the exception of the 80s.
So what was Pascal?
> C++ was heavily promoted by Microsoft
!!!
Microsoft didn't even *have* a C++ compiler until I'd been using the
language for three or four years. Wasn't 1.0 out in 1993 or so? Well,
it was total crap anyway, and VC++ wasn't really usable until 4.1 or 4.2
or something like that.
-- Bruce
Bruce Hoult wrote:
> I suspect that this is pretty much where Scheme people on one hand and
> CL and Dylan people on the other hand part ways. Everyone appreciates
> generality and power when they need them, but the latter two groups also
> value notational convenience for the common cases. Dylan expands the
> "for" macro into a tail-recursive function (and CL does something
> similar) precisely because many people find that easier to write, read,
> and understand than the explicit tail-recursive form, for most common
> cases.
What you snipped is that I rarely use explicit iteration in complex
programs. I strongly prefer map-like forms, which are both conceptually
powerful and notationally convenient. I don't usually write explicit
iteration beyond the standard (let loop ...) idiom.
>>C was the exception of the 80s.
>>
>
> So what was Pascal?
A flop basically. It had a short stint in academia, and as the
programming langauge for the Macintosh, before being overrun by C, but
there was very little use in commercial shops, which would be a
necessity for a mainstram language.
>>C++ was heavily promoted by Microsoft
>>
>
> !!!
>
> Microsoft didn't even *have* a C++ compiler until I'd been using the
> language for three or four years. Wasn't 1.0 out in 1993 or so? Well,
> it was total crap anyway, and VC++ wasn't really usable until 4.1 or 4.2
> or something like that.
That was well before C++ became a mainstream "hit."
In article <················@quiotix.com>, Jeffrey Siegal
<···@quiotix.com> wrote:
> Bruce Hoult wrote:
>
> > I suspect that this is pretty much where Scheme people on one hand and
> > CL and Dylan people on the other hand part ways. Everyone appreciates
> > generality and power when they need them, but the latter two groups
> > also
> > value notational convenience for the common cases. Dylan expands the
> > "for" macro into a tail-recursive function (and CL does something
> > similar) precisely because many people find that easier to write, read,
> > and understand than the explicit tail-recursive form, for most common
> > cases.
>
> What you snipped is that I rarely use explicit iteration in complex
> programs.
I snipped it because I agree with it.
> >>C was the exception of the 80s.
> >>
> >
> > So what was Pascal?
>
> A flop basically. It had a short stint in academia, and as the
> programming langauge for the Macintosh, before being overrun by C, but
> there was very little use in commercial shops, which would be a
> necessity for a mainstram language.
It may be different where you are, but here in New Zealand I see a *lot*
of commercial work being done in Pascal (Delphi) even today.
> >>C++ was heavily promoted by Microsoft
> >>
> >
> > !!!
> >
> > Microsoft didn't even *have* a C++ compiler until I'd been using the
> > language for three or four years. Wasn't 1.0 out in 1993 or so? Well,
> > it was total crap anyway, and VC++ wasn't really usable until 4.1 or
> > 4.2 or something like that.
>
> That was well before C++ became a mainstream "hit."
I believe you are using circular definitions here.
-- Bruce
Bruce Hoult wrote:
>>>>C was the exception of the 80s.
>>>>
>>>>
>>>So what was Pascal?
>>>
>>A flop basically. It had a short stint in academia, and as the
>>programming langauge for the Macintosh, before being overrun by C, but
>>there was very little use in commercial shops, which would be a
>>necessity for a mainstram language.
>>
>
> It may be different where you are, but here in New Zealand I see a *lot*
> of commercial work being done in Pascal (Delphi) even today.
You're right about Delphi, but that's certainly a case of a language
having a commercial promoter. I seem to recall that Delphi became
popular long after Pascal had all but died. Call it a second coming if
you like.
>>>>C++ was heavily promoted by Microsoft
>>>>
>>>>
>>>!!!
>>>
>>>Microsoft didn't even *have* a C++ compiler until I'd been using the
>>>language for three or four years. Wasn't 1.0 out in 1993 or so? Well,
>>>it was total crap anyway, and VC++ wasn't really usable until 4.1 or
>>>4.2 or something like that.
>>>
>>That was well before C++ became a mainstream "hit."
>>
>
> I believe you are using circular definitions here.
Huh? You speak of using C++ in 1989 or 1990. It was not mainstream at
that time, C was.
Jeffrey Siegal <···@quiotix.com> writes:
> C was the exception of the 80s. C++ was heavily promoted by Microsoft
> (and the other Windows compiler vendors, when there were any). Perl was
> perhaps the exception of the 90s (I consider Perl marginal and Python to
> be clearly niche).
C++ took off because C wasn't good enough for *and* wasn't changing to
meet the needs of application developers (as opposed to OS
developers). It also maintained the highest compatibility with the C
mind-set by not requiring an expensive (as GC was perceived at the
time) run-time environment and retaining some connection to the
underlying hardware structure of real computers.
There *is* a lesson to be learned here, and it's not that languages
need big promoters.
david rush
--
With guns, we are citizens. Without them, we are subjects.
-- YZGuy, IPL
David Rush wrote:
>>C was the exception of the 80s. C++ was heavily promoted by Microsoft
>>(and the other Windows compiler vendors, when there were any). Perl was
>>perhaps the exception of the 90s (I consider Perl marginal and Python to
>>be clearly niche).
>>
>
> C++ took off because C wasn't good enough for *and* wasn't changing to
> meet the needs of application developers (as opposed to OS
> developers). It also maintained the highest compatibility with the C
> mind-set by not requiring an expensive (as GC was perceived at the
> time) run-time environment and retaining some connection to the
> underlying hardware structure of real computers.
>
> There *is* a lesson to be learned here, and it's not that languages
> need big promoters.
Perhaps the lesson is that a language should not try to be all things to
all people. C is still heavily used for OS development.
David Rush wrote:
> Jeffrey Siegal <···@quiotix.com> writes:
>> C was the exception of the 80s. C++ was heavily promoted by Microsoft
>> (and the other Windows compiler vendors, when there were any). Perl was
>> perhaps the exception of the 90s (I consider Perl marginal and Python to
>> be clearly niche).
>
> C++ took off because C wasn't good enough for *and* wasn't changing to
> meet the needs of application developers (as opposed to OS
> developers). It also maintained the highest compatibility with the C
> mind-set by not requiring an expensive (as GC was perceived at the
> time) run-time environment and retaining some connection to the
> underlying hardware structure of real computers.
I think C++ took off because it came at the right time (the OOP Hype Boom)
and because it was so similar to what people already knew (C).
I still happens most of the time that I meet people that know for sure that
OOP is the one and only winning paradigm and that C++ combines "the fastest
language" with "the final paradigm"...
ciao,
Jochen
--
http://www.dataheaven.de
On Thu, 27 Dec 2001 17:14:40 +1300, Bruce Hoult <·····@hoult.org>
wrote:
>> Dylan will almost certainly never break into the mainstream without a
>> big promoter. The opportunity was largely lost when Apple dropped it.
>
>That was a sad day, yes. And it's taking a while to recover from. The
>good news is that 1) the implementations are getting there, and 2) most
>mainstream people have never even heard of it, so when we're ready it'll
>be "new" to them, not recycled.
Dylan's biggest liability is its name ( named after an elderly
has-been 1960's rocker that only my parents would have been seen dead
listening to ) and the perception that it was "dropped by Apple".
Perhaps renaming it and changing its Pascal like syntax either towards
Scheme or towards C might get some disillusioned Schemers , lispers
or even some apostates from Java and C#....
As for names Skylan / Skylark for the Schemefied version or Cyclan for
the C syntax version (I was a EC Tubbs fan...) Or if you want a
musical name, Bach or Fugue would be nice ( Mozart is already taken by
the Oz/Mozart language )
israel r t wrote:
> Dylan's biggest liability is its name ( named after an elderly
> has-been 1960's rocker that only my parents would have been seen dead
> listening to )...
Even I know that Dylan was named that after Dylan Thomas and because Dylan
was an acronym for DYnamic LANguage. Hell, the first Dylan compiler
(written in MIT Scheme) was named Thomas. Bob Dylan's lawyers also tried
to sue Apple for this mis-perceived naming idea and the case was won by
Apple.
> ... and the perception that it was "dropped by Apple".
Most people who the purveyors of Dylan are targeting aren't even aware of
the role Apple played with the language.
Not that any of this will help the language in the long run (just so no one
thinks I have any sort of soft spot for the language as it is now).
faa
Bruce Hoult <·····@hoult.org> writes:
> In article <·················@quiotix.com>, Jeffrey Siegal
> <···@quiotix.com> wrote:
>
> > Bruce Hoult wrote:
> > > That's true only in the trivial sense that Lisp has no syntax, so Lisp
> > > syntax can't be outgrown.
> >
> > Hardly. It just has a syntax with a very simple and powerful basic
> > construction rule. However, on top of that construction rule,
> > enormously powerful syntactic abstractions can be (and are) built. What
> > Algol-like languages lack is the basic construction rule which allows
> > you to decompose the syntax down into elemental componets. That makes
> > any macro system either enormously complex or lacking in power, or both.
> >
> > Consider, for example, what low-level Lisp macros would look like in an
> > Algol-like language. They can be done but the result is enormously
> > complex (and also fragile; if the language syntax is extended, macros
> > written that way will likely break).
>
> There are examples of the same thing happening in reverse. When macros
> get sufficiently complex and have enough combinations of different
> possibilities, it becomes too difficult to follow a purely S-expresion
> syntax. Consider the example of the Dylan "for" macro. How would you
> map all that functionality and all those options onto an S-expression
> syntax? Well, we can look at what is done in Common Lisp with the
> "loop" macro. The same idea, very nearly exactly the same options. And
> we find that in fact it does *not* use S-expression syntax, but instead
> makes a little infix language that ends up very similar to that part of
> Dylan.
But this is an intentional feature of LOOP, it's a little Algol-like
mini-language inside of CL. There are other non-standardized packages
that provide similar functionality, but use a more lispy approach.
One thing that's missing from LOOP as specified in the spec is any way
to extend it. Which is too bad, because that would make it even more
useful, but this is a (mis)feature of the spec, and isn't inherent in
a LOOP macro. MIT LOOP has such a feature, for example.
>
> Now, I happen to think that the "loop" macro is a *good* thing about
> Common Lisp, but:
>
> 1) building such things yourself isn't well supported in CL (it is in
> Dylan)
That's because it's a weird exception in CL. Complicated macros that
define a Lispy mini-language *are* well supported, and there's nothing
about iteration that makes it require a LOOP-like syntax.
> 2) I find that I actually *prefer* this sort of thing to have infix
> syntax, and prefer all loops and other control structures to use it. If
> nothing else, it means that you know immediately whether you're looking
> at a standard function application or a special form. That's what Dylan
> does.
I'm not sure what to say to this. It's usually pretty obvious if
something isn't a function call, unless it's supposed to behave like
one, in which case, I like that there isn't a visual distinction. If
you can't spot
(iterate ((i (interval :from 0))
(elt (list-elements some-list)))
...)
as a macro call, you just haven't read enough Lisp.
In a later post, you mention DO (which is also a Lisp macro). I tend
to think of it as a low-level iteration construct, mostly appropriate
for building sugary facilities on top of, much like TAGBODY and GO.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
Bruce Hoult wrote:
> In article <·················@quiotix.com>, Jeffrey Siegal
> <···@quiotix.com> wrote:
>
> > I consider Lisp syntax (or something similarly elegant) to be
> > essential. I suspect that many proponents of Dylan-like languages would
> > consider it unacceptable. I strongly suspect there is no middle ground.
>
> I can happily use either. Or paren-less prefix (Logo, ML). Or postfix
> (PostScript, Forth). But even after much use of the others I find that
> I do prefer "conventional" syntax.
The advantage of a language with significant syntax is that it allows the
programmer to quickly and easily write certain kinds of code. For example, ML
and Haskell syntax make it easy to write curried functions and function
applications, as well as infix operators. It would be quite annoying to call
a simple function by saying
(((foldl f) h) lst)
Infix is probably less important, but is convenient.
In article <·················@his.com>, Feuer <·····@his.com> wrote:
> Bruce Hoult wrote:
> > I can happily use either. Or paren-less prefix (Logo, ML). Or postfix
> > (PostScript, Forth). But even after much use of the others I find that
> > I do prefer "conventional" syntax.
>
> The advantage of a language with significant syntax is that it allows
> the programmer to quickly and easily write certain kinds of code. For
> example, ML and Haskell syntax make it easy to write curried functions
> and function applications, as well as infix operators. It would be
> quite annoying to call a simple function by saying (((foldl f) h) lst)
That's true, but it seems awfully arbitrary.
How often do you find that you need to put function arguments in an
uncomfortable order so that the automatic currying works out right?
-- Bruce
Bruce Hoult <·····@hoult.org> writes:
> In article <·················@his.com>, Feuer <·····@his.com> wrote:
> > The advantage of a language with significant syntax is that it allows
> > the programmer to quickly and easily write certain kinds of code. For
> > example, ML and Haskell syntax make it easy to write curried functions
> > and function applications, as well as infix operators. It would be
> > quite annoying to call a simple function by saying (((foldl f) h) lst)
>
> How often do you find that you need to put function arguments in an
> uncomfortable order so that the automatic currying works out right?
Well comparing my experiences from 5 years ago programming constraint
solvers and scheduling systems in SML to the present where I'm data
mining in Scheme, I'd say I encounter about equal hassle in both
systems w/rt curried functions and partial applications. I use a lot
more HO functions in Scheme, at least partly to simulate SML
functors, and I get mildly annoyed at the number of explicit lambdas I
need to include. OTOH, I spent a fair amount of time in SML fretting
over the most `natural' partial application order (not to mention the
whole tuple vs curried API issue).
On the whole I prefer Scheme, but I might find that I also like SML
better (not that I ever *dis*liked it) now that my fluency in the
functional paradigm has grown.
Just $0.02.
david rush
--
From the start...the flute has been associated with pure (some might
say impure) energy. Its sound releases something naturally untamed, as
if a squirrel were let loose in a church." --Seamus Heaney
In article <·················@his.com>, Feuer wrote:
>Bruce Hoult wrote:
>
>> In article <·················@quiotix.com>, Jeffrey Siegal
>> <···@quiotix.com> wrote:
>
>>
>> > I consider Lisp syntax (or something similarly elegant) to be
>> > essential. I suspect that many proponents of Dylan-like languages would
>> > consider it unacceptable. I strongly suspect there is no middle ground.
>>
>> I can happily use either. Or paren-less prefix (Logo, ML). Or postfix
>> (PostScript, Forth). But even after much use of the others I find that
>> I do prefer "conventional" syntax.
>
>The advantage of a language with significant syntax is that it allows the
>programmer to quickly and easily write certain kinds of code. For example, ML
>and Haskell syntax make it easy to write curried functions and function
>applications, as well as infix operators. It would be quite annoying to call
>a simple function by saying
>(((foldl f) h) lst)
In Lisp, rather than Scheme, that would be:
(funcall (funcall (foldl f) h) lst)
A ``curried'' function in the first position of a list is not
automatically called.
Now the *disadvantage* of significant syntax is that it allows the programmer
to quickly and easily write the kinds of code that the language designer
thought the programmer ought to be able to write quickly and easily.
That approach assumes that the language designer can forsee how the language
will be used, which could turn into a self-fulfilling prophecy.
If you don't like chaining the funcalls using nested expressions, you
can invent some syntax which folds up the nesting, like
(chained-funcall #'foldfl f h lst)
Another way might be to do it as a mapper:
(mapchain #'start l-1 l-2 ... l-n)
where start has to be a function that takes as many arguments
as there are lists. The first element from every list is taken,
and turned into an argument list for start, which returns
another function that takes as many arguments, and is used
for the second elements of the list and so on.
Now, I have no idea how important it is to make this kind of chaining
more convenient, or in what way. So if I were designing a language, I
would view it as a grave mistake to introduce a special purpose syntax
for it, given that people can just experiment with their own, and settle
on solutions that are right for them. Then if a pattern of useful
primitives emerges from the community, which many people find useful,
their functions and macros can be incorporated into the language.
You also mentioned infix. You can find implementations of infix evaluators
for Common Lisp, so if you really want infix, it's there.
The point is that special syntax is a really form of premature
optimization. Worse, it's a form of optimization based entirely on
guessing what is going to be needed. The resulting language might attract
users who are looking for exactly that, so that the optimization later
appears to have been correct.
On 24 Dec 2001 23:16:18 +0100, Andreas Bogk <·······@andreas.org>
wrote:
>israel r t <········@antispam.optushome.com.au> writes:
>
>> Lisp needs to reinvent itself.
>
>I suggest to take a look at Dylan. It's a pretty recent Lisp-like
>language, and it's got a few things right (but on the other hand
>omitted some features some people consider essential). I've also got
>a list of things to do better on the next iteration.
>
>You can learn a lot from Dylan when designing a new Lisp.
>
>Andreas
What I saw of Dylan looked good, but it is a dead language. Stillborn.
······@interaccess.com (Thaddeus L Olczyk) writes:
> What I saw of Dylan looked good, but it is a dead language. Stillborn.
There are two Dylan compilers being actively maintained, one
commercial, one free. That's not exactly dead.
Andreas
--
"In my eyes it is never a crime to steal knowledge. It is a good
theft. The pirate of knowledge is a good pirate."
(Michel Serres)
* israel r t
> Lisp needs to reinvent itself.
* Andreas Bogk
| I suggest to take a look at Dylan.
Since the whole thread is a spoof of an article that caused the Scheme
community to explode in rage and the resident Dylan fans completely fail
to understand that this is a stupid attempt to inflame the Lisp community
likewise, but rather once again take part in it with their unsolicited
Dylan marketing campaign -- which is no surprise, like Scheme fans, they
also erroneously think their language is a Lisp and annoy comp.lang.lisp
with marketing for their Lisp-wannabe languages every once in a while --
the conlusion is clear: Dylan is worth a look if and only if Lisp needs
to reinvent itself, which it does not need any more than Scheme does.
Both Dylan and Scheme have distanced themselves from the Lisp community
in a number of important ways, but when they lose ground, they return to
their Lisp heritage, and when they gain ground, they point out how Lisp
is not longer worth anyone's time. This closely parallels the behavior
of immature children who want to distance themselves from their parents
as long as they risk nothing by doing so. If Dylan and Scheme were for
real, they would make a clean cut with Lisp and attempt to make it on
their own without constant references to their heritage, good or bad.
"Members of the Lisp family" try to point out much better they are than
their parent, whatever "Lisp" as a parent means. Even Paul Graham, the
inventor of the silly new toy language "arc", needs to point out how
Common Lisp is superior to his new toy by knocking Common Lisp before he
has anything to show for himself.
Attacking Common Lisp is primarily a way to say "I don't understand
feature X, therefore it is must be bad and should be removed". If they
spent as much time trying to understand what was going on as they do
trying to fight against Common Lisp, they would not need to fight, either.
///
--
The past is not more important than the future, despite what your culture
has taught you. Your future observations, conclusions, and beliefs are
more important to you than those in your past ever will be. The world is
changing so fast the balance between the past and the future has shifted.
[...]
> Even Paul Graham, the
> inventor of the silly new toy language "arc", needs to point out how
> Common Lisp is superior to his new toy by knocking Common Lisp before he
> has anything to show for himself.
How can you judge the sillyness of arc when it has not even been specified
yet? (The articles he wrote about arc are very clever in my opinion.)
Mr Graham's criticisim of CL is sincere and he genuinely loves Lisp. I
remember whe we talked about free implementations of CL you were very angry
and said something like it could not expected of anybody to give away his
work for free, etc. Maybe Mr Graham will do this and then many of us will
support him by buying his (O'Reilly)-book on arc (that hopefully will become
Archlisp). Maybe he will give Lisp the bright future it deserves.
J.B.
-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
Check out our new Unlimited Server. No Download or Time Limits!
-----== Over 80,000 Newsgroups - 19 Different Servers! ==-----
"Janos Blazi" <······@hotmail.com> writes:
> [...]
>
> > Even Paul Graham, the
> > inventor of the silly new toy language "arc", needs to point out how
> > Common Lisp is superior to his new toy by knocking Common Lisp before he
> > has anything to show for himself.
>
> How can you judge the sillyness of arc when it has not even been specified
> yet? (The articles he wrote about arc are very clever in my opinion.)
One way is to read his webpage about it, cited at the beginning of
this thread. I did, and it seemed to me that his ideas were
wrong-headed.
--
Tom Breton at panix.com, username tehom. http://www.panix.com/~tehom
> One way is to read his webpage about it, cited at the beginning of
> this thread. I did, and it seemed to me that his ideas were
> wrong-headed.
(1)
The webpage contains ideas only and no final product. So im my opinion you
can judge his intentions and his opinions but you cannot judge "arc",
whatever tha may become. It is Eric's general attitude to get angry at the
slightest inacuracy and what is source for the goose is source for the
gander.
(2)
At first reading I thought that Mr Graham had some points but it would be
much better (even in his sence) to create a new CL implementation and
augment it with a nice standard library and a GUI toolkit. Then I read the
text a second time and now I think I understand better what he is after.
Being a pessimistic man I just wonder as to what extent he will succeed and
whether there will be a new Lisp at all. But I hope he will succeed as his
success would make life more interesting.
J.B.
-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
Check out our new Unlimited Server. No Download or Time Limits!
-----== Over 80,000 Newsgroups - 19 Different Servers! ==-----
----- Original Message -----
From: "Janos Blazi" <······@hotmail.com>
Newsgroups: comp.lang.lisp
[I deleted comp.lang.functional and comp.lang.scheme from the header]
> [...]
> > Even Paul Graham, the
> > inventor of the silly new toy language "arc", needs to point out how
> > Common Lisp is superior to his new toy by knocking Common Lisp before
he
> > has anything to show for himself.
>
> How can you judge the sillyness of arc when it has not even been specified
> yet? (The articles he wrote about arc are very clever in my opinion.)
I think it is not dead wrong to criticize Paul G.'s plan to make the Common
Lisp community (unsolicited) happy. I am not a computer scientist, but I am
currently studying Lisp (after: P.H.Winston, Berthold K. Horn, "LISP, 3rd
Edition").
I also have red Graham's proposal concerning Arc. But honestly speaking:
nobody is interested in such a new dialect. The world doesn't need a new
Lisp.We are polluted with a many hundred of computer languages.
I think it is highly questionable from Mr. Graham to believe he is entitled
to make a new Lisp (yes, yes, he didn't clearly state it).
It is also dangerous to split the Lisp community again. Actually Lisp takes
a stand on Java, C, C++,... A new Lisp dialect will only contribute to
weaken Common Lisp its position.
> Mr Graham's criticisim of CL is sincere and he genuinely loves Lisp.
My mother also is loving me. When I was a young boy, she actually urged me,
that I should contemplate about to become a priest...
> Maybe he will give Lisp the bright future it deserves.
I hardly ever believe this will happen; Mixing postfix and prefix notation
as with Arc is utterly insane.
S. Gonzi
> I think it is not dead wrong to criticize Paul G.'s plan to make the
Common
> Lisp community (unsolicited) happy.
I agree with you but he is not criticising the plan, he is criticising the
langauge that does not exist yet.
> I am not a computer scientist, but I am
> currently studying Lisp (after: P.H.Winston, Berthold K. Horn, "LISP, 3rd
> Edition").
>
> I also have red Graham's proposal concerning Arc. But honestly speaking:
> nobody is interested in such a new dialect.
How can you tell? *You* are not interested, others may well be. Just wait
and see.
> The world doesn't need a new
> Lisp.We are polluted with a many hundred of computer languages.
I do not understand in which possible ways computer languages can constitute
a pollution.
> I think it is highly questionable from Mr. Graham to believe he is
entitled
> to make a new Lisp (yes, yes, he didn't clearly state it).
Everybody is entitled to make a new lisp, even you or I. Are you afraid of
Mr Graham's influence?
> It is also dangerous to split the Lisp community again. Actually Lisp
takes
> a stand on Java, C, C++,... A new Lisp dialect will only contribute to
> weaken Common Lisp its position.
Again you cannot predict this at this state of play. It is possible that you
are right but it is as well possible the other way.
> > Mr Graham's criticisim of CL is sincere and he genuinely loves Lisp.
> My mother also is loving me. When I was a young boy, she actually urged
me,
> that I should contemplate about to become a priest...
And you have actually become one... Or not? What is wrong with becoming a
priest?
> > Maybe he will give Lisp the bright future it deserves.
> I hardly ever believe this will happen; Mixing postfix and prefix notation
> as with Arc is utterly insane.
Just wait and see.
I posted some of his arguments here a few years ago but of course I could
not put them so cleverly, smoothely and convincingly.
J.B.
-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
Check out our new Unlimited Server. No Download or Time Limits!
-----== Over 80,000 Newsgroups - 19 Different Servers! ==-----
> I also have red Graham's proposal concerning Arc. But honestly speaking:
> nobody is interested in such a new dialect. The world doesn't need a new
> Lisp.We are polluted with a many hundred of computer languages.
Although it's always easy to make this argument, I don't think it
should stop people from trying to make new better things.
You could equally well argue that there are millions of books and most
of them aren't very good, so why should authors persist in writing new
ones? New good languages do come along. For example I find perl5 quite
useful, which would have surprised me greatly if you described the
language to me 10 years ago. Amazingly, there is still a lot of
unexplored territory in the field of language design, especially in
the direction of making a good all-purpose language. Most new
languages have been aimed at proving that some particular theoretical
operation is sufficient to write all programs in. I suspect this is
largely responsible for the disrepute into which language design has
fallen.
Evidently the currently available Lisps are not perfect, since many
good programmers have tried them but chosen other vehicles. People on
this newsgroup would do well to entertain the possibility that Lisp
may have faults, rather than that all non-Lisp users are boneheads.
A new clean Lisp without such horrors as loop, values, let/let*, the
menagerie of array types and a thousand other historical botches, but
not as stripped down as Scheme, would be most welcome.
On Sun, Jan 20, 2002 at 10:20:37AM -0800, Trevor Blackwell wrote:
> > I also have red Graham's proposal concerning Arc. But honestly speaking:
>
> > nobody is interested in such a new dialect. The world doesn't need a new
>
> > Lisp.We are polluted with a many hundred of computer languages.
>
>
> Although it's always easy to make this argument, I don't think it
> should stop people from trying to make new better things.
>
> You could equally well argue that there are millions of books and most
> of them aren't very good, so why should authors persist in writing new
> ones? New good languages do come along. For example I find perl5 quite
> useful, which would have surprised me greatly if you described the
> language to me 10 years ago. Amazingly, there is still a lot of
> unexplored territory in the field of language design, especially in
> the direction of making a good all-purpose language. Most new
> languages have been aimed at proving that some particular theoretical
> operation is sufficient to write all programs in. I suspect this is
> largely responsible for the disrepute into which language design has
> fallen.
>
> Evidently the currently available Lisps are not perfect, since many
> good programmers have tried them but chosen other vehicles. People on
> this newsgroup would do well to entertain the possibility that Lisp
> may have faults, rather than that all non-Lisp users are boneheads.
I think that many people on this newsgroup are quite aware of the fact.
I think you will find a greater degree of C programmers (maybe Perl more
so now) who are convinced that their language is the "one true way" than
CLers. At least that was my experience. But that could also be due
to the greater numbers of them.
>
> A new clean Lisp without such horrors as loop, values, let/let*, the
> menagerie of array types and a thousand other historical botches, but
> not as stripped down as Scheme, would be most welcome.
Maybe you think they are horrors. I think they are useful.
LOOP is, whatever your opinions may be on it, one of the more powerful
iteration constructs I've seen in any language. VALUES is the standard
way of returning multiple values--I agree that the name MULTIPLE-VALUE-BIND
is a bit long but that can be macroed--would you prefer the usage of lists,
which do not make obvious your intent? As for LET/LET* is it the distinction
that bothers you, the fact of lexical scoping, or is it a problem with
LAMBDA in general? If it's just too many parenthesis then try out:
(defmacro with (var val &body body)
`(let ((,var ,val))
,@body))
I stopped using this type of macro myself though; I decided it didn't really
make things any clearer.
What is the menagerie of array types? Are you referring to multiple-
dimension arrays that can be specialized to a given type? Would you prefer
arrays for which that was not true, eliminating lots of helpful optimization
opportunities?
I agree with you that CL is not perfect, but I don't understand why you've
picked out those particular operators as "horrors".
--
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; Matthew Danish email: ·······@andrew.cmu.edu ;;
;; OpenPGP public key available from: 'finger ···@db.debian.org' ;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
Trevor Blackwell wrote:
> A new clean Lisp without such horrors as loop, values, let/let*, the
loop we could lose, but how can you not love VALUES?!
In C it happens all the time: I want two things back from a function so
one param is a pointer passed in for the sole purpose of passing
something back out. yechh.
And sometimes I want LET, sometimes LET*. Which should be dumped? Then
what do I do?
kenny
clinisys
Kenny Tilton <·······@nyc.rr.com> writes:
> Trevor Blackwell wrote:
> > A new clean Lisp without such horrors as loop, values, let/let*, the
>
> loop we could lose, but how can you not love VALUES?!
>
> In C it happens all the time: I want two things back from a function so
> one param is a pointer passed in for the sole purpose of passing
> something back out. yechh.
>
> And sometimes I want LET, sometimes LET*. Which should be dumped? Then
> what do I do?
I'm guessing both. I mean we have lambda, right? So who needs let? :P
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
···@conquest.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
> Kenny Tilton <·······@nyc.rr.com> writes:
>
> > Trevor Blackwell wrote:
> > > A new clean Lisp without such horrors as loop, values, let/let*, the
> >
> > loop we could lose, but how can you not love VALUES?!
> >
> > In C it happens all the time: I want two things back from a function so
> > one param is a pointer passed in for the sole purpose of passing
> > something back out. yechh.
> >
> > And sometimes I want LET, sometimes LET*. Which should be dumped? Then
> > what do I do?
>
> I'm guessing both. I mean we have lambda, right? So who needs let? :P
[...]
I think if you really drop let/let* in favour of some other
facilities, the first thing most Lisp programmers will do, is to build
let and let* macros. :)
Values are another quite useful thing. It is perhaps a pain to
implement it, but sometimes exactly this feature is needed. And if you
do not use values, nobody will force you.
Regards,
Julian St.
* Julian St wrote:
> I think if you really drop let/let* in favour of some other
> facilities, the first thing most Lisp programmers will do, is to build
> let and let* macros. :)
I think, in fact, that this is just exactly what they *did* do!
> Values are another quite useful thing. It is perhaps a pain to
> implement it, but sometimes exactly this feature is needed. And if you
> do not use values, nobody will force you.
yes.
--tim
* Trevor Blackwell wrote:
> A new clean Lisp without such horrors as loop, values, let/let*, the
> menagerie of array types and a thousand other historical botches, but
> not as stripped down as Scheme, would be most welcome.
Other than the unspecified historical botches, which I obviously can't
comment on, I use all of these things every day. But I guess I'm just
one of those boring people trying to solve real-world problems with
CL, so I don't really count. And after all a `new clean lisp' is so
much more interesting than, say, standardizing something dull like
sockets, isn't it?
--tim
Tim Bradshaw wrote:
> And after all a `new clean lisp' is so
> much more interesting than, say, standardizing something dull like
> sockets, isn't it?
Here is what I have heard lately as various stuff worth standardizing:
- MOP
- FFI
- Sockets
- GUI (CLIM? Other?)
Other?
kenny
clinisys
Kenny Tilton <·······@nyc.rr.com> writes:
> Tim Bradshaw wrote:
> > And after all a `new clean lisp' is so
> > much more interesting than, say, standardizing something dull like
> > sockets, isn't it?
>
> Here is what I have heard lately as various stuff worth standardizing:
>
> - MOP
> - FFI
> - Sockets
> - GUI (CLIM? Other?)
>
> Other?
CORBA (there _is_ a language mapping, btw).
--
(concatenate 'string "cbbrowne" ·@canada.com")
http://www.ntlug.org/~cbbrowne/
"I doubt this language difference would confuse anybody unless you
were providing instructions on the insertion of a caffeine enema."
-- On alt.coffee
In article <·················@nyc.rr.com>, Kenny Tilton wrote:
>
>
>Tim Bradshaw wrote:
>> And after all a `new clean lisp' is so
>> much more interesting than, say, standardizing something dull like
>> sockets, isn't it?
>
>Here is what I have heard lately as various stuff worth standardizing:
>
> - MOP
> - FFI
> - Sockets
> - GUI (CLIM? Other?)
>
>Other?
- POSIX bindings for CL, at least for functions that are true platform
bindings rather than C programming gadgets. You'd almost certainly
want this in a separate standard, not in ANSI CL.
- Threads that can map to POSIX threads, with proper integration of thread
exit cleanup handling with Lisp's unwinding, and thread cancelation
mapped to the condition system. There could be some basic threads in
CL, with compatible extensions in the CL bindings for POSIX.
···@accton.shaw.ca (Kaz Kylheku) writes:
> In article <·················@nyc.rr.com>, Kenny Tilton wrote:
[...]
> >Here is what I have heard lately as various stuff worth standardizing:
> >
> > - MOP
> > - FFI
> > - Sockets
> > - GUI (CLIM? Other?)
> >
> >Other?
>
> - POSIX bindings for CL, at least for functions that are true platform
> bindings rather than C programming gadgets. You'd almost certainly
> want this in a separate standard, not in ANSI CL.
>
> - Threads that can map to POSIX threads, with proper integration of thread
> exit cleanup handling with Lisp's unwinding, and thread cancelation
> mapped to the condition system. There could be some basic threads in
> CL, with compatible extensions in the CL bindings for POSIX.
Is there any CL implementation that has implemented the second item?
Otherwise I'd file this under "this would be nice to have", and not
"people are doing this already, but don't agree on the details, so
let's standardize it"...
Regs, Pierre.
--
Pierre R. Mai <····@acm.org> http://www.pmsf.de/pmai/
The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We cause accidents. -- Nathaniel Borenstein
From: Tim Bradshaw
Subject: Re: New Lisp Standards? (was Re: New Lisp ?)
Date:
Message-ID: <ey38zasa903.fsf@cley.com>
* Kenny Tilton wrote:
> - MOP
> - FFI
> - Sockets
and things like URIs perhaps - some kind of general more-network-aware
CL really.
> - GUI (CLIM? Other?)
Not CLIM, or not CLIM without a very convincing case that it can
produce good native-look-and-feel GUIs, but yes, I guess.
> Other?
threads in a non-toxic-to-OS-threads way.
And probably a million things with fashionable names - what are they
this week? XML (or is that pass� yet?) CORBA (*must* be old-hat by
now, there even seems to be a standard CL binding).
As well as that there are some nice CL-level things that could be done
without enormous pain or incompatibility I think - hierarchical
packages for one would seem useful and fairly simple (is ACL's
implementation reasonable?). Conduit packages like my conduits system
but obviously more thought out. Package locks. Streams - simple
streams, maybe Gray or something derived from one or the other.
--tim
On 20 Jan 2002 23:38:20 +0000, Tim Bradshaw <···@cley.com> wrote:
COM
DNA
.NET
------------------------------------------------------------
Add this to your .sig. Highly effective at reducing spam !
Please direct all spam to:
·········@whitehouse.gov ··············@whitehouse.gov
·····@cia.gov ·····@fbi.gov ·······@spamcop.net ,
······@liberal.org.au ,···@chq.liberal.org.au,
·······@onenation.com.au
And probably a million things with fashionable names - what are they
this week? XML (or is that passé yet?)
COM
DNA
.NET
OPEN GL
------------------------------------------------------------
Add this to your .sig. Highly effective at reducing spam !
Please direct all spam to:
·········@whitehouse.gov ··············@whitehouse.gov
·····@cia.gov ·····@fbi.gov ·······@spamcop.net ,
······@liberal.org.au ,···@chq.liberal.org.au,
·······@onenation.com.au
Tim Bradshaw schrieb:
> > - GUI (CLIM? Other?)
>
> Not CLIM, or not CLIM without a very convincing case that it can
> produce good native-look-and-feel GUIs, but yes, I guess.
I've been working with CLIM for 6 years now, and I think it
has its pros and cons.
Here's what I'd like to see as a GUI toolkit:
- CLIM's presentation system (easy creation of context menus
or drag-and-drop interactions) but without command tables.
- A set of standard GUI gadgets (cross-platform!) including
e.g. nested menu bars, tables, combo boxes and tooltips.
- User extensibility of the gadget set (by means of a clean,
well-documented CLOS object model for gadgets).
- A predictible, usable layout engine (CLIM's define-application-frame
comes close to the goal).
Aspects of CLIM I'd drop from the toolkit:
- Explicit accepts: this is old-fashioned question-and-answer style.
- Accept-values: in my opinion a misguided attempt to make GUI dialogs
look like old-fashioned question-and-answer interactions to the
programmer - who needs that?
- Command tables: the need to organize commands into command tables
has never helped me, only caused problems.
- CLIM Views: burdened with too many different notions:
(1) distinguishing textual dialogs from gadget-based ones:
no longer useful because customers demand GUIs today
(2) basis for future interaction styles:
I'd bet, a really new interaction style won't fit into the
CLIM framework
(3) defining the gadget properties for an accept-values element:
why should I describe the gadget by means of a view object
instead of supplying the gadget directly?
So, what I'd like to see for LISP is something like Java's Swing,
but with a cleaner API and object model, and extended by CLIM's
presentation system.
> > Other?
>
> threads in a non-toxic-to-OS-threads way.
>
> And probably a million things with fashionable names - what are they
> this week? XML (or is that pass� yet?) CORBA (*must* be old-hat by
> now, there even seems to be a standard CL binding).
Both threads and CORBA are crucial and I'd like to see them portable
(well, the CL CORBA binding is called "official", so I hope it's
portable,
but threads aren't...).
XML can be done at the application level, so a pure-CL library can do
the
job (best basis for portability).
--- Ralf
israel r t <········@antispam.optushome.com.au> wrote, quoting:
>What a language is has changed since then. In 1985, a programming
>language was just a spec. Now, thanks to Perl, it means not just (and
>maybe not even) a spec, but also a good free implementation, huge
>libraries, and constant updates." [...]
Of course, neither Common Lisp not Scheme follow this short-sighted belief,
so one would be justified in thinking that you are trolling by cross-posting
this message to groups which discuss them.
Some other Lisps (eg XLisp) have followed this path of providing a standard
free implementation, but I'm not sure that it's helped them.
Jeffrey Siegal wrote:
> C was the exception of the 80s. C++ was heavily promoted by Microsoft
> (and the other Windows compiler vendors, when there were any). Perl was
> perhaps the exception of the 90s (I consider Perl marginal and Python to
> be clearly niche).
i'm curious what you think python's niche is. the python community
doesn't
seem to feel it's got one just yet.
--
Garry Hodgson Let my inspiration flow
Senior Hacker in token rhyme suggesting rhythm
Software Innovation Services that will not forsake me
AT&T Labs 'til my tale is told and done.
·····@sage.att.com
Garry Hodgson wrote:
> Jeffrey Siegal wrote:
>
>
>>C was the exception of the 80s. C++ was heavily promoted by Microsoft
>>(and the other Windows compiler vendors, when there were any). Perl was
>>perhaps the exception of the 90s (I consider Perl marginal and Python to
>>be clearly niche).
>>
>
> i'm curious what you think python's niche is. the python community
> doesn't
> seem to feel it's got one just yet.
Heh, I'm not going to step into that one. Whatever I say, you, or some
(other?) Python advocate is sure to counter with, "But what about Xxxxx?"
I'll just say that Python is not mainstream in the same way that C, C++,
Java, VB, etc. and possibly Perl, are. Perhaps it could be some day,
but it isn't today.
On Wed, 2 Jan 2002, Jeffrey Siegal wrote:
> Garry Hodgson wrote:
[snip]
> > i'm curious what you think python's niche is. the python community
> > doesn't
> > seem to feel it's got one just yet.
[snip]
> I'll just say that Python is not mainstream in the same way that C, C++,
> Java, VB, etc. and possibly Perl, are. Perhaps it could be some day,
> but it isn't today.
Hmm. I think of VB as definitely a Niche langauge. A Large Niche, perhaps,
but definitely a Niche (maybe two, I'm not sure).
It seems that there are a bunch of qualities that are being conflated,
nicheness, popularity (ELisp is a very popular niche langauge, as is
Javascript), purposeness (general vs. various sorts of specificity),
"mainstreamness", etc.
These certainly interplay and overlap, but I don't think they're all
identical. I think Python is generally considered an unexceptional choice
for most sorts of development, albeit with strengths, weaknesses, and
caveats. While surely there are some places where it would cause raised
eyebrows, overall trends seem toward consensus as a standard, reasonable
langauge.
It's probably not yet quite as widespread as Perl, but it's not far
off. It has sufficient infrastructure (e.g., books) to be seen by the
clueless as "real".
I'm not sure how much more mainstream you can get :) Or rather, there's
merely jockeying for position, rather than mainstream status *per se*,
left for Python.
Cheers,
Bijan Parsia.
Bijan Parsia wrote:
> Hmm. I think of VB as definitely a Niche langauge. A Large Niche, perhaps,
> but definitely a Niche (maybe two, I'm not sure).
Perhaps. I'm not going to argue that.
> It seems that there are a bunch of qualities that are being conflated,
> nicheness, popularity (ELisp is a very popular niche langauge, as is
> Javascript), purposeness (general vs. various sorts of specificity),
> "mainstreamness", etc.
Popularity is essential for something to be mainstream. Consider the
word itself.
If something isn't popular, it isn't mainstream, although it may be
difficult to define the niche except in terms of the thing itself ("the
niche of Python users").
On Wed, 2 Jan 2002, Jeffrey Siegal wrote:
> Bijan Parsia wrote:
> > Hmm. I think of VB as definitely a Niche langauge. A Large Niche, perhaps,
> > but definitely a Niche (maybe two, I'm not sure).
>
> Perhaps. I'm not going to argue that.
It is relevant to the subsequent point...
> > It seems that there are a bunch of qualities that are being conflated,
> > nicheness, popularity (ELisp is a very popular niche langauge, as is
> > Javascript), purposeness (general vs. various sorts of specificity),
> > "mainstreamness", etc.
>
> Popularity is essential for something to be mainstream. Consider the
> word itself.
If if so, it doesn't mean that popularity is the same thing as mainstream.
> If something isn't popular, it isn't mainstream,
Which doens't mean that if it's popular, it *is* mainstream. Python is
*quite* popular, but whether it's mainstream depends, IMHO, on some other
features (e.g., in part, it being *seen* as a "normal", mainstream choice
by various classes of people).
But, fwiw, I don't agree with your claim about the connection between
popularity and mainstreamness.
> although it may be
> difficult to define the niche except in terms of the thing itself ("the
> niche of Python users").
Given that most Python programming is directed to other tasks, this
definition, in this context, seems rather vacuous.
I think you're seriously conflating *unpopularity* and "niche". A language
can be perfectly general purpose, and used by it's user base in an
uniformly general purpose way, and still be unpopular.
So, at this point, I'm completely puzzled at what distinctions you're
trying to draw and the value of them. Ok, python is a general purpose,
fairly popular, "niche" (in your sense) language....I guess. It doesn't
seem to explain very much.
If it helps, I think of VisualBasic as a niche language because my
understanding of it is that the primary driving force of its use is making
database frontend screens for corporate (Windows based) apps.
I may be wrong about that, and it may be used for other things (I'm *sure*
it is), but the connection between it's use, evolution, popularity,
status, etc. still seem fairly tightly tied to that niche. A large niche,
to be sure, but nevertheless.
Cheers,
Bijan Parsia.
Bijan Parsia wrote:
> > although it may be
> > difficult to define the niche except in terms of the thing itself ("the
> > niche of Python users").
>
> Given that most Python programming is directed to other tasks, this
> definition, in this context, seems rather vacuous.
You seem to want to classify languages in terms of the tasks they are
used for. I don't. I never saw any reason why Lisp should have been
considered an "A.I language", despite it's greatest popularity being in
A.I. circles.
I'm more interested in the dynamics of the subculture that surround a
language, and one of the most important, if not the most important
defining factors of that subculture is size.
Back in this thread somewhere, I already said I considered Lisp (and
Scheme) and Dylan to be niche languages. They're not mainstream by any
stretch of the imagination, yet they can be, and are, certainly used for
all manner of tasks, just like Python. That makes them all general
purpose languages, but not mainstream ones.
[ replying to comp.lang.lisp only
http://world.std.com/~pitman/pfaq/cross-posting.html ]
Jeffrey Siegal <···@quiotix.com> writes:
> Bijan Parsia wrote:
> > > although it may be
> > > difficult to define the niche except in terms of the thing itself ("the
> > > niche of Python users").
> >
> > Given that most Python programming is directed to other tasks, this
> > definition, in this context, seems rather vacuous.
>
> You seem to want to classify languages in terms of the tasks they are
> used for. I don't. I never saw any reason why Lisp should have been
> considered an "A.I language", despite it's greatest popularity being in
> A.I. circles.
Well, I'd characterize the situation in a way that is midway between these
two positions. I think a language is influenced by its upbringing, since
its development has been sensitive to its constituency. An AI background
therefore creates a certain way of thinking. But AI is not all Lisp has been
influenced by.
I'd make the analogy to a resume. Some people look at a resume and see AI
on it and say "oh, I don't want an AI guy" and throw it in the trash. Others
look at it and see "AI" and say "just the person". And a third camp of people
say "oh, that's an interesting area to have studied. what else have they done."
in order to form an overall view of what the person (or language, in this case)
has done.
It's important to understand though that even a resume that contains only one
area of work (not the case here, but just a general lesson in resume reading)
does not imply that other work is impossible. If it did, then after one's
first job, by induction, their entire career would be fixed in stone, since
only the same kind of people could ever hire them. One's past builds strengths
toward one's futures, but should not be seen to limit one's futures.
Lisp has been strengthened by the AI community, which has enriched its
ability to self-represent, to adapt, to accomodate multiple models, to
reason symbolically, to do type discovery, do delay decision-making,
and so on. The relationship to and effect of AI is not to be
understated. But Lisp has also been used by mathemeticians and they
have pushed on its numerics. And it has been used by OS builders, who
have field tested and enhanced its control structures. And it has
been usd for writing portable applications, causing it to be more
robust than many languages on a wide range of porting targets. The
Lisp resume is quite varied. But even for as much as it's done, perhaps
because it's a dynamic language, it remains open to "continuing education"
and new fields of endeavor.
> I'm more interested in the dynamics of the subculture that surround a
> language, and one of the most important, if not the most important
> defining factors of that subculture is size.
Size of subculture is important to the correctness/usefulness of it?
This doesn't sound right. It would suggest that baseball (which has a large
subculture) is more important than nuclear physics (which has a comparatively
small subculture). I think only "having critical mass" to sustain a
continuing basis is essential; beyond that, clearly additional numbers and
resources have some benefit (though occasionally also drawbacks), but it
certainly isn't a smooth, unvarying curve. It's a pretty complicated function.
> Back in this thread somewhere, I already said I considered Lisp (and
> Scheme) and Dylan to be niche languages. They're not mainstream by any
> stretch of the imagination, yet they can be, and are, certainly used for
> all manner of tasks, just like Python. That makes them all general
> purpose languages, but not mainstream ones.
People are using terms casually here and it can lead to misunderstanding.
Both Lisp and PostScript are turing powerful, yet most people would
say that PostScript's _intent_ (at least in the market) is not general
purpose. Likewise Emacs lisp is turing powerful, but the marketing of
it leaves it relegated to a more special-purpose status. I don't mean
that as a slight of either language, but if one is going to talk
"differences" while at the same time retaining the politically correct
notion that "everyone is every thing" (the old "animals are people
too" mantra you see on some bumper stickers here in the US ... sigh), then
you weaken the terminology to the point of useless and might as well declare
the "heat death" (due to entropy) of conversation.
Lisp is plainly general purpose. I don't follow Python but my sense
is that it seeks to be as well. That is, these languages are not
heavy in domain-dependent operators like PostScript (with its
asymmetrically heavy support for fonts, shapes, etc.) or Emacs Lisp
(with its asymmetrically heavy support for text editing). One could,
and I will, argue that Visual Basic, JavaScript, and HyperTalk are all
niche languages also, not because there is anything ungeneral about their
basic control structures but mostly because they come with lots of very
specific stuff for certain kinds of interfaces.
Maybe "niche languages" and "languages not initially predisposed to be
especially helpful at any particular task" form an exhaustive
partition of languages. Heh... ;-) At least then we could all debate
whether it was better to look down on a language for being specially
useful for something specific or for not being especially useful for
something specific... Only half-serious here. But then, only half-joking.
Jeffrey Siegal wrote:
>
> Garry Hodgson wrote:
> > i'm curious what you think python's niche is. the python community
> > doesn't seem to feel it's got one just yet.
>
> Heh, I'm not going to step into that one. Whatever I say, you, or some
> (other?) Python advocate is sure to counter with, "But what about Xxxxx?"
you do me a disservice. i intended no trap.
just an honest question.
> I'll just say that Python is not mainstream in the same way that C, C++,
> Java, VB, etc. and possibly Perl, are. Perhaps it could be some day,
> but it isn't today.
no argument here.
--
Garry Hodgson Let my inspiration flow
Senior Hacker in token rhyme suggesting rhythm
Software Innovation Services that will not forsake me
AT&T Labs 'til my tale is told and done.
·····@sage.att.com