Time for a Fresh Scheme Standard: Say Goodbye to the RnRS Relic
New Scheme
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.
Erik Naggum
| 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.
New Scheme
> 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 <ku...@bellsouth.net> wrote in message news:<okfg064...@bellsouth.net>...
> <posted-and-mailed why="cross-postings to cll and clf">
> <flame mode="on">
> news...@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)
IsraelRT
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.
Erik Naggum
| 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.
Hirotaka Yamamoto
> 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
IsraelRT
> 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....
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.
New Scheme
> On 22 Dec 2001 01:02:35 -0800, news...@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?
Erik Naggum
> Look, Tengwar is more widely used than Scheme these days.
* IsraelRT <isra...@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.
IsraelRT
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.
IsraelRT
>* IsraelRT <isra...@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.
Erik Naggum
| 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 <isra...@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.
Courageous
> 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//
Hirotaka Yamamoto
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
Kent M Pitman
http://world.std.com/~pitman/pfaq/cross-posting.html ]
Erik Naggum <er...@naggum.net> writes:
> * news...@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.
MJ Ray
>> 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.
MJ Ray
> 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.
israel r t
.
.
{ 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.
New Scheme
> 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 <ku...@bellsouth.net> wrote in message news:<okfg064...@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
Erik Naggum
| 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!
Terry Reedy
Please delete comp.lang.python from this thread. (and maybe
c.l.perl).
Terry J. Reedy
MJ Ray
>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.
MJ Ray
> 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.
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.
Hirotaka Yamamoto
> So you lack the courage to deal with all forms of counter-information.
So you do too against my post.
israel r t
(MJ Ray) wrote:
>Erik Naggum <er...@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...
Erik Naggum
| 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.
Erik Naggum
| 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?
Sander Vesik
> 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 +++
Anton van Straaten
>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
Sander Vesik
> 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
israel r t
<ym...@yc5.so-net.ne.jp> wrote:
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.
israel r t
>* Hirotaka Yamamoto <ym...@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.
israel r t
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
> 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....
Frank A. Adrian
> 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
Erik Naggum
| 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?
Erik Naggum
| The last standard was released in 1994, ie nearly a decade ago.
How old are you?
Bruce Lewis
> 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.
--
<brlewis@[(if (brl-related? message) ; Bruce R. Lewis
"users.sourceforge.net" ; http://brl.sourceforge.net/
"alum.mit.edu")]>
David Rush
> In comp.lang.scheme Anton van Straaten <an...@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
israel r t
>Erik Naggum <er...@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 !
israel r t
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
Andreas Bogk
> 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)
Jeffrey Siegal
> 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.)
Andreas Bogk
> 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.
Jeffrey Siegal
> > 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?
Thaddeus L Olczyk
wrote:
>israel r t <isra...@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.
Andreas Bogk
> > 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.
Jeffrey Siegal
> > 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.
Bijan Parsia
> 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.
Andreas Bogk
> 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)
Andreas Bogk
> 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 Bogk
> 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
Bijan Parsia
> Bijan Parsia <bpa...@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.
Kaz Kylheku
<Pine.A41.4.21L1.01122...@login6.isis.unc.edu>, Bijan
Parsia wrote:
>On 25 Dec 2001, Andreas Bogk wrote:
>
>> Bijan Parsia <bpa...@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.
Julian St.
[...]
> 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. ;)
Bruce Hoult
<j...@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
<j...@quiotix.com> wrote:
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
<Pine.A41.4.21L1.01122...@login9.isis.unc.edu>, Bijan
Parsia <bpa...@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
<j...@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
jeff
Successful language design is all these things.
israel r t
<jn...@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.
Andreas Bogk
> 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.
Jeffrey Siegal
>>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.
Jeffrey Siegal
>>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.
Bruce Hoult
<j...@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
Jeffrey Siegal
> 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.
Bijan Parsia
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.
Kaz Kylheku
>On Tue, 25 Dec 2001 23:12:51 -0800, jeff
><jn...@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.
Barry Margolin
Kaz Kylheku <k...@ashi.footprints.net> wrote:
>In article <jd1j2uggcr52j22jt...@4ax.com>, israel r t wrote:
>>On Tue, 25 Dec 2001 23:12:51 -0800, jeff
>><jn...@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, bar...@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.
Francois-Rene Rideau
> 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).
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
Kaz Kylheku
>In article <bapW7.51884$cv4.1...@news1.calgary.shaw.ca>,
>Kaz Kylheku <k...@ashi.footprints.net> wrote:
>>In article <jd1j2uggcr52j22jt...@4ax.com>, israel r t wrote:
>>>On Tue, 25 Dec 2001 23:12:51 -0800, jeff
>>><jn...@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.
Jeffrey Siegal
>>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.
Andrew Cady
> 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
israel r t
<bpa...@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.
Feuer
> In article <3C27C7BC...@quiotix.com>, Jeffrey Siegal
> <j...@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.
Bruce Hoult
<j...@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
Kent M Pitman
> 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.
Bruce Hoult
> 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
Kaz Kylheku
>Jeffrey Siegal <j...@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.
Coby Beck
"Bruce Hoult" <br...@hoult.org> wrote in message
news:bruce-9D1859....@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")
Thomas F. Burdick
> "Bruce Hoult" <br...@hoult.org> wrote in message
> news:bruce-9D1859....@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! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
David Rush
> Jeffrey Siegal <j...@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
> In article <3C2A856C...@his.com>, Feuer <fe...@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)
>
> 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
Jeffrey Siegal
> 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.
Bruce Hoult
> "Coby Beck" <cb...@mercury.bc.ca> writes:
>
> > "Bruce Hoult" <br...@hoult.org> wrote in message
> > news:bruce-9D1859....@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
<j...@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
Jeffrey Siegal
> 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).
Andreas Bogk
> > 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
> 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.
Jeffrey Siegal
> 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
> 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.
Bruce Hoult
<j...@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
israel r t
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 )
Andreas Bogk
> 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
Andreas Bogk
> 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.
Bruce Hoult
<j...@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
Erik Naggum
> 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.
Frank A. Adrian
> 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
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