I believe every computer enthusiast recognizes himself in these words. I
have certainly met so many real enthusiasts all over the world that I do
not think those who did not share these feelings worked with computers in
the 1970's, 1980's or even early 1990's. Today, we have a lot of people
who only work with computers because it pays for their expensive homes,
cars, spouses, and kids, but I do not care much about those people, and
they have no impact on the industry, either, as they are the people who
get laid off and simply go into another business they do not care much
about either if they cannot continue to work with computers. The rest of
the computer people are just as competent, intelligent, and caring as
they used to be, and they drive innovation, development, excitement in
new stuff of all kinds. They also keep the little fire within burning
with a passion for the older things they have loved all their lives.
For every hardware or software product, there are enthusiasts: wild,
untamed, uncontrollable people who overflow with excitement that "normal"
people have no way to understand. It is that _excitement_ that sets us
apart from the crowd. It is that _excitement_ that causes people to join
free software and open source projects to give away their work to others
of the same kind. This is why free software and open source are mostly
developer-to-developer, because only developers share their joy. Users
do not understand, they do not care, and they do not understand why we
care. The currency in the developer community is _enthusiasm_. Not just
your own for your own work, but for the competence, intelligence, and
caring that just about anybody else excudes, too. As a developer, you
are not judged solely by your work, but by how great you think it is,
what went into making it great, and for your capacity to understand how
great somebody else's work is.
All of the software tools on the Internet have a following behind them:
People who _care_ and who are willing to help others who care. All
languages have groups of dedicated people behind them that profess their
love for their language, in direct words, in direct action, in every way
they can. All languages with vendors behind them have developer forums
where people come with a general attitude that the tools are great and
that the vendor does a great job providing for them, unless, of course,
there are bugs, in which case the "angry side" of developers show up and
they feel personally betrayed by incompetent, unintelligent, or careless
people. But give them half a chance to prove otherwise, and developers
will love them again, forgiving and forgetting, because they share the
overall enthusiasm that drives us all. In fact, developer to developer,
we do not only expect enthusiasm, we demand it. There is something very
_wrong_ with a developer who just slops something together and leaves a
stinking heap of dysfunctional crap, and such people _anger_ developers.
The demand for enthusiasm is a profound recognition of the competence,
intelligence and caring that _must_ go into computer software. It is
among the hardest mental tasks known to man to create bug-free software.
We manage to do it because we demand competence, intelligence and caring
from _all_ the people who take part in its creation. If there are
somebody among us who fail to deliver on these counts, the are not only
doing a bad job, they are destroying part of the very fragile fabric that
know keeps everything together. Because, let us just face it right away:
Creating software is so immensely hard that we cannot afford to create it
in a world where incompetent, unintelligent, careless people must be safe
from harm. This is different from every other engineering discipline --
all of them are about ensuring that the blundering moron does not get
himself killed. Software can crash on the incompetent, bridges cannot.
We "solve" this problem by requiring of the people that set the standards
for our industry that they be enthusiasts, highly competent, highly
intelligent, very caring enhtusiasts who are devoted and dedicated to a
level of quality that would be unimaginable in any other discipline. We
do not always get what we want, but that is the requirement we have.
The optimism that the information technology industry managed to excude
to the general public a few years ago led to the hyperinflation in IT
stocks. The wild, untamed, uncontrollable excitement that computer
people feel towards their own work spilled over into the general public
for the first time, and the public was completely unprepared for it, so
they thought it was more than the _feeling_ shared among developers. It
went really bad. Billions of dollars have moved from the hands of those
who believed to unscrupulous, big spenders who were not developers, but
managers and other suits who got a whiff of our enthusiasm and could not
handle it. Such is the immense power of the enthusiasm that developers
and computer people feel that it has probably produced a global recession
when it affected people who did not know that it was a feeling _reserved_
for competent, intelligent, caring people who knew where it came from and
when it should be used. However sad the losses and difficult our times
because of it, the enthusiasm remains untamed among developers. They may
be more cautious in their spending and they may regret that they spent
all that free money too soon, but their core belief in competence,
intelligence, and caring has not changed. Developers everywhere are
still devoting their time and their lives to the extremely high quality
of their work. The enthusiasm that defines computer people has not been
killed by being laid off, by losing money, by failing products, even by
betrayal from managers, investors, what have you. Computers are great,
our languages are great, we are great, we just had a bit of bad luck. I
include this part of negativism because I want to show that the greatness
that keeps us together and in the business survived such a huge blow.
I think Common Lisp is a really _great_ language. I absolutely loved Guy
Steele's "Common Lisp the Language" in both editions -- he excudes more
competence, intelligence, and caring than any other programming language
book author I have read. His profound and rich sense of humor is no
accident. I think ANSI Common Lisp is the best standard there is, and
the language it defines is most certainly the top of the crop. I feel a
deep personal satisfaction in being able to program in this greatest of
languages.
Now, when I approach a Common Lisp vendor, I fully _expect_ him to share
my enthusiasm for the technology I want to purchase from him and probably
to exceed mine because he created something great for a great language
and since I have discovered both the great language, the great product,
and the great vendor, we should be able to share a _lot_ of enthusiasm.
If the vendor does not share my enthusiasm, there is something _wrong_
with him. If the vendor insults what I think is great, he is insane --
no two ways about that. My enthusiasm for Common Lisp is not affected by
a negative idiot who thinks it sucks. For every language and product,
there are people who are _not_ members of their respective communities
who hate them with a passion very close in magnitude to the passionate
love felt by its adherents, so this is not something I care about at all.
Outsiders to any community have always been behaving like idiots.
However, there is something _very_ seriously wrong with the Common Lisp
community. People _in_ the community feel that it is perfectly OK to
debase, denigrate, ridicule, denounce, disrespect, insult, defame, and
smear Common Lisp. Instead of telling people how great a language we
have, some certifiable nutcases spend their time propagandizing and
agitating against the language, creating stupid deviant versions and
breaking with the language as defined, doing something other than what
was agreed upon, and introducing "features" that cause the knowledge base
for the language to be polluted and the skill of knowing Common Lisp to
be nigh worthless when faced with individual Common Lisp systems. [The
worst perpetrators also argue that since you have to know so much extra
in addition to Common Lisp, it does not matter that you cannot use your
skill set from having learned Common Lisp.)
Instead of being able to trust an implementation to follow the standard,
to let the standard be the baseline of expectations, Common Lisp users
are taught by expect things to be broken. If an insane vendor goes out
of his way to decry the incompetence of the standards committee because
he did not get his will on, say, lower-case symbol names, and he shows
the whole world that he writes code that does not work correctly if you
want standard behavior, that does something to the ability of developers
to trust the implementation. Instead of taking conformance for granted,
we have to check for it, read the release notes files very carefully to
see that, oops, floating point contagion works differently here, the
standard pathnames are broken by design so not supported, and it was just
plain wrong to specify how CLOS objects should be updated when the class
is updated, so we omitted that. These are not bugs. These are not best
efforts that fall short for lack of resources and that will be fixed
given the resources. These are _intentional_ violations. I call them
"political bugs".
The desire to maintain a greatness is so powerful in other communities
that they split whenever they need an incompatible feature. A new name
is often chosen for the new language. Anything to keep people looking
upwards and onwards. The new feature is great to those who follow it,
and the old feature is great to those who stay. Never mind the people
who are not members of our community. In the Common Lisp community,
however, it is perfectly OK for people to continue to call their deviant
languages "Common Lisp" even though they purposefully break with it, and
people who hate all sorts of features _stay_. They do _not_ leave when
they are disgruntled and have better ideas. It is somebody else's fault
when their better ideas are defeated. The inevitable conclusion is that
Common Lisp is _not_ great to Common Lisp people. As a community, we are
_unable_ to chase away the negative morons and their destructive forces.
Instead, some people even defend the "right" of the destructive nutcases
to continue to hammer on the greatness of their language. A feeble lack
of enthusiasm follows, where "it is just a tool" and "it has good sides
and bad". So, why should anyone choose Common Lisp over any other tool?
For some time, lots of Lisp people have asked why (Common) Lisp is dying.
There are some objections every now and then, like when a dying parent
keeps his ungrateful offspring from stealing his fortune by refusing to
stop breathing. There are some people who still show signs of enthusiasm
in the Common Lisp community, who still express love for their language,
who still want the language to be fully implemented. The rabid nutcases
refer to these as "religiuos zealots". In any _other_ community, those
who love the language would be celebrated and the nay-sayers would be run
out of town, asked to go create their own community. Instead, we let
these corpses stay with us and spread death and gloom and pestilence, and
anyone who arrives in our community will take one whiff of the death and
decide to go elsewhere, anywhere, because just about anywhere else, you
find _vibrant_ enthusiasm among the community members.
We need to throw out and bury the corpses. Those who think Common Lisp
sucks are _not_ members of the Common Lisp community. Those who want to
work with Common Lisp should feel free to express their _love_ for the
language, should not be ashamed to be _excited_ about their language,
should feel comfortable _sharing_ with others in the community, and
should experience a strong sense of commmon competence, intelligence and
care from joyful, happy people who have seen a great languge survive all
sorts of problems and changes and still remain a truly great language.
This is not possible when people who hate parts of the language, some of
the people who created it, or some of the process that created it, who
hold personal grudges they cannot let go of, or who think the best way to
"improve" the language is to stay in the community and spread negativity
and tear down everybody else's enthusiasm, do just that. No improvement
at all will take place when such negativity rules because everybody is
afraid that if they open up for any change at all, the destructive forces
will win and the language they love will be destroyed by the hatemongers
and destroyers who seek only their own personal revenge over feature wars
lost. And that is precisely the case with Common Lisp. Strong negative
forces want to reverse several decisions and threaten to destabilize the
language, so in order to maintain the necessary peace that will allow
developers to use this language at all, _nothing_ happens. By mounting a
constant attack on the standards process, the nutcases who are never
going to be happy with the language, anyway, ensure that their negative
attitude keeps everyone else from being happy and becoming happier, too.
The enthusiasm that really helps improve a language is a love for it the
way it is and has evolved so far, with an understanding and appreciation
of its "momentum of evolution" so that any changes that are proposed seek
to retain the users and the investments in it and does not splinter off
into a different language and break with the past. People who love their
language develop it further and share their ideas of its evolution so
that the community takes part in deciding where to go, but they never
seek to "improve through destruction". People who love their language
want to go from "great" to "greater", not from "great" via "sucks" to
"different".
Can we do this? Can people who are still enthusiastic about Common Lisp
the language, even after reading a 20K long news article, please raise a
hand and express their feelings? Can you stand up and say "I _love_
Common Lisp!" in a crowd and feel proud of yourself? Do you want to
fight for Common Lisp at work, at school, at home? Do you want to tell
people how great Common Lisp is? Do you want to share of your time to
help make Common Lisp a continued success and to go from survivor to
winner? Do you want to pay hard earned cash to make sure that Common
Lisp vendors succeeds because you know that that helps you succeed? Do
you want to help make _all_ the vendors and Common Lisp system builders
stop their negative spins on the language and the standard and just do
the right thing and implement the standard faithfully _first_, and then
do whatever else they think is also great _afterwards_, _without_ making
any insults towards the standard or the rest of the community?
It will take hard work to get the negative attitudes out of the system.
It will require significant effort to convince the vendors who still have
rabid nutcases on staff to want to change their public image to a more
up-beat, enthusiastic one. E.g., convincing the CLISP maintainers to get
rid of the negative attitude problem in stuff like this
-ansi
ANSI CL compliant: Comply with the ANSI CL specification even on
those issues where ANSI CL is broken. This option is provided for
maximum portability of Lisp programs, and is not useful for actual
everyday work. It sets the symbol macro *ansi* to t. See "Maximum
ANSI CL compliance", for details.
would be a good start. It should be possible to argue for a better way
without _having_ to debase what one does not like. If one argues for
something different based on something that others think is great being
bad, nobody who likes the existing stuff will want to listen, and instead
they get all defensive and want to keep the lunatics at bay.
I actually believe thare are enough Common Lisp enthusiasts out there to
make a difference if we can get the corpses that stink up the place out
and that there is nothing wrong with Common Lisp's following or fans if
they can be allowed to express their enthusiasms instead of being hurt by
rabid nutcases who insist on insulting both language and its happy users.
///
Perhaps you will call me "rabid nutcase" or maybe just and "outsider" to the
world of LISP or even computers and programming, but I still would like to
write several sentences of my comments.
First of all I must say that while still being a very new follower of LISP,
I do love and respect the language. I am also quite enthusiastic about telling
other people about LISP and how great a language it is. The key word to all
that, however, is "language". In your article you made an impression that
LISP is a religion or at least a philosophy and that unbelievers (so-called
"destructive/rabid nutcases" or "negative morons") are sent by the satan.
The problem here (IMHO, of course) is that LISP is _not_ a religion and it
_not_ even a philosophy, instead it _is_ a tool and it _has_ good and bad
sides. Moreover, people who choose to be blind when it comes to the bad sides
and to the fact that standards change and new needs arrive, _can_ be called
"religious zealots".
Here's a simple parallel: suppose you have a hammer with standard rubber
handle which has little bumps all over it for better grip, yet they irritate
your hand. Will you go to the store and buy a new hammer or a new handle or
will you take a knife and illiminate the bumps and use your existing hammer?
Of course there's a possibility that you have many hammers in your toolshed,
in which case you will just go and take a different one without such bumps
(or with fewer bumps), but let's forget about that this time.
So, unless you really hate knives or you really like to drive to the store
and spend money on new stuff, you will probably choose to eliminate the small
inconviniece yourslef. Now when the inconvenience grows bigger and many people
choose to eliminate them themselves, the store that sells our hammers will
probably want to change the design of their hammer so customers will be happy.
This does not mean that every store everywhere will do the same, perhaps
because they think it's too small to change their standard or just because
they choose not to. So now we have stores that have eliminated the inconvenience
and stores that did not, so which will succeed more? I cannot say that the
stores that did not eliminate the bumps will go out of bussiness completely
or loose all their customers, there might be people who work in gloves and
the bumps really do help them have a better grip, so they stay with the
standard.
Unless the standard hammers have other inconveniences and a whole lot of
influencial people decide to change the standard, the standard stays the same
and we have standard hammers that many people find obsolete and we have new
non-standard hammers that many people find better and new. So should the
non-standard hammers now be renamed so the standard hammers can be standard
or do they stay with the name "hammer"?
Ok, looks like my "sever sentences" have grown to a page, but I hope I did
make my point clear. I will not comment on any of the specific cases of
implementations being non-ANSI compliant, I'm just stating my general opinion
about standards and changes in standards.
Regards,
rk
Perhaps you will call me "rabid nut-case" or maybe just and "outsider" to the
world of LISP or even computers and programming, but I still would like to
write several sentences of my comments.
First of all I must say that while still being a very new follower of LISP,
I do love and respect the language. I am also quite enthusiastic about telling
other people about LISP and how great a language it is. The key word to all
that, however, is "language". In your article you made an impression that
LISP is a religion or at least a philosophy and that un-believers (so-called
"destructive/rabid nut-cases" or "negative morons") are sent by the satan.
The problem here (IMHO, of course) is that LISP is _not_ a religion and it
_not_ even a philosophy, instead it _is_ a tool and it _has_ good and bad
sides. Moreover, people who choose to be blind when it comes to the bad sides
and to the fact that standards change and new needs arrive, _can_ be called
"religious zealots".
Here's a simple parallel: suppose you have a hammer with standard rubber
handle which has little bumps all over it for better grip, yet they irritate
your hand. Will you go to the store and buy a new hammer or a new handle or
will you take a knife and eliminate the bumps and use your existing hammer?
Of course there's a possibility that you have many hammers in your tool-shed,
in which case you will just go and take a different one without such bumps
(or with fewer bumps), but let's forget about that this time.
So, unless you really hate knives or you really like to drive to the store
and spend money on new stuff, you will probably choose to eliminate the small
inconvenience yourself. Now when the inconvenience grows bigger and many people
choose to eliminate them themselves, the store that sells our hammers will
probably want to change the design of their hammer so customers will be happy.
This does not mean that every store everywhere will do the same, perhaps
because they think it's too small to change their standard or just because
they choose not to. So now we have stores that have eliminated the inconvenience
and stores that did not, so which will succeed more? I cannot say that the
stores that did not eliminate the bumps will go out of bossiness completely
or loose all their customers, there might be people who work in gloves and
the bumps really do help them have a better grip, so they stay with the
standard.
Unless the standard hammers have other inconveniences and a whole lot of
influential people decide to change the standard, the standard stays the same
> Can we do this? Can people who are still enthusiastic about Common Lisp
> the language, even after reading a 20K long news article, please raise a
> hand and express their feelings?
I love Common Lisp! I quit my previous job just because the boss
didn't even try to understand me and my enthusiasm about it.
[Quitting a well-paid job without even having another place ready to
go to is quite a crazy thing to do here. I even don't know any other
Common Lisp programmer (except the one who is learning it -- the guy
from my previous working place) in my country.]
I love Common Lisp as it is and would be really happy to see it become
even better.
I'll be there when we're taking the fortress :)
--
Janis Dzerins
If million people say a stupid thing it's still a stupid thing.
Huh!? If you get that impression, if it is because you think in those
terms. I most certainly do not. Enthusiasm and religion do have some
emotions in common, but I think you must be out of your mind if you see
evidence of your impression in what I wrote.
> Moreover, people who choose to be blind when it comes to the bad sides
> and to the fact that standards change and new needs arrive, _can_ be
> called "religious zealots".
Nobody chooses to be blind to them (where do you get these insane ideas?),
they simply do not denigrate the whole language because of things they do
not use or, better, work to improve through the standardization channels
they trust to correct mistakes because they still love the language.
Obviously, you did not get the message at all. Let me just hope somebody
else does.
///
>
> Obviously, you did not get the message at all. Let me just hope somebody
> else does.
Your message has been very interesting, but Erik: You are a naive guy.
Do you really believe there is a collaboration between dealers and the
user-community?
On one side you are promoting (in other posts) that only
commercial-dealers are capable of producing a good Lisp product and now
you are whining. Erik, there will never be the situation when dealers
will ask you what you want. This is not because you are Erik Naggum, its
because they run a business and nothing else.
I am also a naive guy and often promote a programming language in the
hope the developers want also hear my opinion; but often I get the
impression they do not listen.
I am not against commercial-products (even when they are pricy; we also
in the astophysics-community use expensive tools, e.g. IDL costs USD
2500.-), but open or free software can in some cases be more flexible.
S. Gonzi
People who run a business generally listen to their customers if
they want to stay in business.
--
Ola Rinta-Koski o...@cyberell.com
Cyberell Oy +358 41 467 2502
Rauhankatu 8 C, FIN-00170 Helsinki, FINLAND www.cyberell.com
>
> On one side you are promoting (in other posts) that only
> commercial-dealers are capable of producing a good Lisp product and now
> you are whining. Erik, there will never be the situation when dealers
> will ask you what you want. This is not because you are Erik Naggum, its
> because they run a business and nothing else.
>
Well, *I* sure hope vendors ask their customers what they want every
once in a while!
--tim
> On Fri, 31 Aug 2001 05:57:38 GMT, Erik Naggum wrote:
> >
> > [... 9 pages of interesting thoughts and statements ...]
Yes, I raise my newbie hand :)
> Here's a simple parallel: suppose you have a hammer [...]
This is IMHO a bad analogy. When you end your work
you take the hammer with you. The code is a
product, not a tool.
Now lets think about something standard that stays
with the final product when you leave.
Nuts & bolts, thats it. Now you're working happily
and some-big-bolt-making-company *replaces* all
his products with non-standard enhanded nuts and
bolts. We have a problem here.
The good thing (tm) is IMHO to sell standard
products *and* special non-standard work-specific
products. Doing it otherwise you're screwing :)
your customers.
--
Eduardo Muñoz
Really? Naïve. Nobody has ever said that before. I think you are
reading a _lot_ of stuff into what I said that simply is not there, and
the rest of your message is so far out I think this conclusion is
warranted.
> Do you really believe there is a collaboration between dealers and the
> user-community?
Um, actually, yes (provided that you meant "vendor", as in producer of
products). If you do not believe there is, you are simply ignorant and
cynical.
> On one side you are promoting (in other posts) that only
> commercial-dealers are capable of producing a good Lisp product and now
> you are whining.
I am whining? About what? Are you sure you have read what I wrote?
> Erik, there will never be the situation when dealers will ask you what
> you want.
And this has what to do with what I said? Do you perhaps not see the
difference between stating what I want from a vendor and wanting them to
ask me what I want? Why should the vendor ask _me_ for anything but my
money? The real question is how smart they are in trying to pry them
loose from my hard and fast grip when I tell them that I want a fully
conforming implementation of Common Lisp and some enthusiasm, please. If
they are just a wee bit smarter than completely asinine bozos, they will
understand that denouncing the very things I came to them to purchase is
not the way to do it. Unless, of course, they have been taught by their
users that it _is_ OK to denounce the standard they try to implement.
> This is not because you are Erik Naggum, its because they run a business
> and nothing else.
And this has what to do with what I said? What do you think running a
business entails? If they say "we hate the standard, but buy the best
implementation of that shit from us", do you think they run a business or
a freak show? If they ran a business, they would say "we love this
stuff, and if you buy the best implementation of this wonderful stuff
from us, we'll love you, too". That is what marketing is all about.
> I am also a naive guy and often promote a programming language in the
> hope the developers want also hear my opinion; but often I get the
> impression they do not listen.
And this has what to do with what I said?
> I am not against commercial-products (even when they are pricy; we also
> in the astophysics-community use expensive tools, e.g. IDL costs USD
> 2500.-), but open or free software can in some cases be more flexible.
And this has what to do with what I said?
Is the concept of enthusiasm _really_ this foreign to people?
Perhaps this was a naïve thing to do. I mean, post an optimistic,
upbeat, enthusiastic message about how languages thrive only when people
love them, to a crowd of fucking retards who want their language to
wither and die. What was I _thinking_? Well, I put my neck out. If the
Common Lisp community rejects enthusiasm and optimism and they really
find it much more fascinating to post gloom and doom and listen to the
death knell of their past loved ones than to get a grip on themselves and
start thinking positively, well, then _I_ have better things to do with
my life than to congregate with such pathetic losers. Perhaps this will
be a test. Perhaps we will see a show of hands from the negative morons
and the positive people who want Common Lisp to live are way outnumbered.
Then I have no reason to expect anything from this community at all and
the vendors are indeed right to denounce their own livelihood and try to
grab as much cash from the poor sods who still use Common Lisp as they
can, because they see that they are going downhill and do not even want
to _try_ any way to get back on track. Perhaps it was really stupid to
ask publicly if people were positive or negative, to ask people to say
they love or hate their language, because perhaps everybody just loathes
Common Lisp and I am the only "religious zealot" left who likes it?
Perhaps the John Foderaros among you are right. But I still hope not.
///
> Then I have no reason to expect anything from this community at all and
> the vendors are indeed right to denounce their own livelihood and try to
> grab as much cash from the poor sods who still use Common Lisp as they
> can, because they see that they are going downhill and do not even want
> to _try_ any way to get back on track.
There seems to be a problem with your stance:
a) Why do expect anything from the community; or better: why should the
community care on Naggum?
b) You are only a Lisp programmer, but you are not the inventor of Lisp
nor you are in any Lisp-standard-commitee (prove me wrong)
c) Do you really think that promoting a language or a product in a
newsgroup will really change the behaviour of the community?
d) Naggum! You will have to learn that you are not alone on this planet.
And when there is the situation that most part of the community is not
on your side, so you should accept it. Nobody impedes you, and you can
make your own Common-Lisp-Naggum standard.
e) Write a book about good Lisp style ( you may not have to search for a
publisher; there is a WWW, you can put it as LaTex/DVI or whatever you
prefer for downloading on your homepage)
f) Erik, you are a buck more naive as thought.
So, this was my last conversation with you, because the coming soon
situation will be: Whining Naggum will write:
Fucking: "I think you are reading a _lot_ of stuff into what I said
that simply is not there, and the rest of your
message is so far out I think this conclusion is...".
Naggum, this is not my problem when you believe other people are not
capable of reading your posts. Then you must not write posts.
S. Gonzi
[By the way. I do not think that Franz Inc. is that devil. I cannot
imagine that a company is greedy when they also give defacto free Lisp
versions for Linux.]
> Moreover, people who choose to be blind when it comes to the bad
> sides and to the fact that standards change and new needs arrive,
> _can_ be called "religious zealots".
Love is not being "blind when it comes to the bad sides". People love
not "because of", they love "despite". I *love* my kid, but I can
tell quite a few things I don't *like* about him. Now, that's the
whole idea of raising a kid, you can't take out neither love, nor a
critical thinking from the equation - and anything else is an
implementation detail (pedagogy).
Being blind to bad sides of your kid is a good start to raise a
homicidal maniac. Look what happened to C++ or perl ;).
SY, Uwe
--
u...@ptc.spbu.ru | Zu Grunde kommen
http://www.ptc.spbu.ru/~uwe/ | Ist zu Grunde gehen
> Can we do this? Can people who are still enthusiastic about Common Lisp
> the language, even after reading a 20K long news article, please raise a
> hand and express their feelings?
I can. I'm not sure I agree with you on everything, but CL is
far-and-away the best programming language I've ever written in.
--tim
>
> b) You are only a Lisp programmer, but you are not the inventor of Lisp
> nor you are in any Lisp-standard-commitee (prove me wrong)
So who *was* that person who sat next to me at the last J13 meeting, I
wonder?
Do you actually have any evidence that most of the CL community
is against Erik, or are you just guessing?
> Nobody impedes you, and you can
> make your own Common-Lisp-Naggum standard.
I strongly suspect this mythical CL/N would be quite
close to the existing CL standard. All Erik seems to
be asking for is that vendors' CLs should be similarly
close, and that customers should come to require
conformance from their vendors. Is this /so/ unreasonable?
(Have you actually /read/ the article? Your responses
would make sense if you were reacting purely to the
subject line.)
> Erik Naggum wrote:
>
> > Then I have no reason to expect anything from this community at all and
> > the vendors are indeed right to denounce their own livelihood and try to
> > grab as much cash from the poor sods who still use Common Lisp as they
> > can, because they see that they are going downhill and do not even want
> > to _try_ any way to get back on track.
>
> There seems to be a problem with your stance:
>
> a) Why do expect anything from the community; or better: why should the
> community care on Naggum?
Because Naggum is a valuable resource to the Lisp community,
perhaps?
> b) You are only a Lisp programmer, but you are not the inventor of Lisp
> nor you are in any Lisp-standard-commitee (prove me wrong)
He is an active member of the Lisp community. There is *no*
active Lisp standardisation committee at the moment.
> c) Do you really think that promoting a language or a product in a
> newsgroup will really change the behaviour of the community?
>
> d) Naggum! You will have to learn that you are not alone on this planet.
> And when there is the situation that most part of the community is not
> on your side, so you should accept it. Nobody impedes you, and you can
> make your own Common-Lisp-Naggum standard.
Start paying attention. Erik has been talking about companies
and groups of people whose Common Lisp implementations contain
gratuitous incompatibilities.
> e) Write a book about good Lisp style ( you may not have to search for a
> publisher; there is a WWW, you can put it as LaTex/DVI or whatever you
> prefer for downloading on your homepage)
>
> f) Erik, you are a buck more naive as thought.
>
>
> So, this was my last conversation with you, because the coming soon
> situation will be: Whining Naggum will write:
>
> Fucking: "I think you are reading a _lot_ of stuff into what I said
> that simply is not there, and the rest of your
> message is so far out I think this conclusion is...".
>
> Naggum, this is not my problem when you believe other people are not
> capable of reading your posts. Then you must not write posts.
>
>
> S. Gonzi
> [By the way. I do not think that Franz Inc. is that devil. I cannot
> imagine that a company is greedy when they also give defacto free Lisp
> versions for Linux.]
Whoooo.
--
Raymond Wiker
Raymon...@fast.no
First of all, thank you. Thank you for articulating so clearly
why I love computers and programming. What you say, at least in
the first half of your message, is absolutely correct, and is why
I'm _so_ darn glad to go to work in the morning.
As for:
> Can we do this? Can people who are still enthusiastic about Common Lisp
> the language, even after reading a 20K long news article, please raise a
> hand and express their feelings? Can you stand up and say "I _love_
> Common Lisp!" in a crowd and feel proud of yourself?
Well, I've finally wangled to get a job where I use Lisp, and if our
company doesn't make it, I really don't know what I'll do. Try to
learn Python, maybe, but no WAY I'm going back to C++/Java.
so: "I _love_ Common Lisp!"
But, now, Erik, do you _really_ think you are helping your own cause
by calling people "moron" and "corpses"? Don't tell me whether or not
they _are_, I don't care about that. I mean, calling people that
_publicly_, do you really think that helps? Maybe it does. Shock
therapy, who knows. But I'm not very convinced.
I just don't know that the situation is as grim as you paint. Of course,
I haven't been in this community very long, so I may be in the honeymoon
period, all is rosy, etc. But I'm _happy_ with my vendor. Yes, their
implementation is often buggy, they they happily take my reports and fix
the problems. As for the open source lisps -- well -- they're open source,
aren't they? Of course you're at the mercy of the head implementor, who
may _be_ a total nutcase for all I know (I'm NOT saying he is!). But if
the community wish really IS for an ansi compliant lisp, wouldn't a fork
of the sources, to bring them into conformance, be a more positive step?
What about the work that Dan Barlow is doing, the cClan guys, the CLiki?
They seem to be LOADED with enthusiasm! It seems to me there is certainly
a community of lisp programmers who love their language, who love their
tool, and who love what they can do with it.
Anyway, I'm just rambling, but I guess I'm just hoping to cheer you up.
Good night Erik.
--Alain Picard
--
It would be difficult to construe Larry Wall, in article
this as a feature. <1995May29....@netlabs.com>
Why do you feel under attack because I want enthusiasm and optimism and
love of the language? Why do you have to stage an all-out war against me
just because I want people to love what they do? What is wrong with you?
What are you _really_ trying to defend with your amazing lunacy? Do you
feel that you would be squeezed out of the Common Lisp community because
you are a sourpuss who wants to destroy the language and its usability?
///
> [...]
>
> Naggum, this is not my problem when you believe other people are not
> capable of reading your posts. Then you must not write posts.
I'd marked your article as one to respond to, as I didn't want your
ridiculous opinions to go unchallenged.
However, you seem to have been adequately squelched. Please think
about your post next time.
Christophe
Common Lisp is a great Language and I'm trying my
best to convince the people I know why I think this
to be true.
I'm not sure if this language bashing attitudes come
automatically in communities of languages that are so far
above the crap that is used by the marketing baited sheeps
of our industry, but our community often discusses lengthly
on topics that _probably_ are made not the optimal way, but
they are _certainly_ made better than in most other languages.
I don't think that there is anything so critical in
the ANSI Common Lisp Standard that it would pay to let
the community concentrate on that instead of the topics
that are _really_ needed.
Instead of having endless debates on how broken ANSI-CL might be
(which IMHO is not the case...) we should take what we have
(which is better than all I've found anywhere else) and begin
including that huge amount of missing infrastructure that "minor"
languages now have for years.
To the topic of non-conformant implementations:
It is somewhat of a shame that things like multithreading or GUI
toolkits are still considered as not really available in CL because
there are implementations that do not provide it - but it is a catastrophe
that things like "user-definable streams" or the MOP or even things like
CHANGE-CLASS are still considered as being not really standard because of
this fact.
I begin more and more to realize that trying not to use such features makes
this situation even worse. Therefore I urge all people - Use this features
wherever they are useful, only this ensures to raise the pressure to force
those who still think that this features are not needed to implement them.
To the vendors "enthusiasm":
Our vendors are so quiet most of the time (some even more quiet than others)
that most people think that there is not much momentum going on from their
side. I find it *critical* for a vendor to at least regularily (on at least
a monthly base) announce some news and even if this news are not really so
important, astonishing or new at all - what counts is the fact that the
people know they are still alive and working hard on their stuff.
Another topic is that vendors should try more to gain from their user-base.
A vendor should motivate it's users to offer some work to a central
"contributions" base. Vendors should even begin to ask themselves what
things to _not_ opensource and not what things to opensource. Imagine the
opportunities CLIM would offer if it would be opensource...
There are many people that sit down a weekend and hack some extension to a
opensource project together - but if all source is closed you can only hope
that the vendor still develops it further.
ciao,
Jochen Schmidt
Shock therapy it is. But also an attempt to show those who denounce the
language and the great stuff that I love and want to use what it feels
like to be denounced. Believe you me, they recognize this and they do
feel it.
However, you are probably right. There are probably people who like John
Foderaro despite his antisocial attitude and self-destructiveness and who
want him to stay. They would be put off by my very strong desire to have
him ostracized. If there were a way to make them take care of him and
make him realize that he could change his ways, something I personally
doubt is possible at this stage, it would have been better to encourage
that. Suffice to say that I think there is as little hope for those who
hate the standard as they think there is hope for Common Lisp becoming
what they want it to be. Now, they have been extremely vocal against the
standard in extremely unproductive ways (take it up in the committee if
you want changes, dammit!), but the standard _is_ what the community has
agreed on and what these guys pretend to be selling an implementation of.
> As for the open source lisps -- well -- they're open source, aren't they?
> Of course you're at the mercy of the head implementor, who may _be_ a
> total nutcase for all I know (I'm NOT saying he is!). But if the
> community wish really IS for an ansi compliant lisp, wouldn't a fork of
> the sources, to bring them into conformance, be a more positive step?
This would work iff the enthusiasm could be rekindled. Whoever wants to
put in any work on such a thing if they are constantly facing a barrage
of hostility from those who hate the standard?
> What about the work that Dan Barlow is doing, the cClan guys, the CLiki?
> They seem to be LOADED with enthusiasm! It seems to me there is
> certainly a community of lisp programmers who love their language, who
> love their tool, and who love what they can do with it.
You are absolutely right! These are the people that should be regarded
as the Common Lisp community.
> Anyway, I'm just rambling, but I guess I'm just hoping to cheer you up.
> Good night Erik.
Thanks for the nice words and feedback.
///
> Richard Krush <rich...@gmx.net> wrote:
>
>> Moreover, people who choose to be blind when it comes to the bad
>> sides and to the fact that standards change and new needs arrive,
>> _can_ be called "religious zealots".
>
> Love is not being "blind when it comes to the bad sides". People love
> not "because of", they love "despite". I *love* my kid, but I can
> tell quite a few things I don't *like* about him. Now, that's the
> whole idea of raising a kid, you can't take out neither love, nor a
> critical thinking from the equation - and anything else is an
> implementation detail (pedagogy).
>
> Being blind to bad sides of your kid is a good start to raise a
> homicidal maniac. Look what happened to C++ or perl ;).
This is by far the best analogy I've read so far!
Imagine how you _would_ feel if your father is telling the people that
you suck because you have to use a pair of glasses or most other kids
can run faster on the football field...
ciao,
Jochen
Some specific comments below...
"Siegfried Gonzi" <siegfri...@kfunigraz.ac.at> wrote in message
news:3B8F8BCA...@kfunigraz.ac.at...
> Erik Naggum wrote:
>
> > Then I have no reason to expect anything from this community at all
and
> > the vendors are indeed right to denounce their own livelihood and try
to
> > grab as much cash from the poor sods who still use Common Lisp as they
> > can, because they see that they are going downhill and do not even
want
> > to _try_ any way to get back on track.
>
> There seems to be a problem with your stance:
>
> a) Why do expect anything from the community; or better: why should the
> community care on Naggum?
>
His entire post was about wanting people to care about Common Lisp and
vendors to care about the standard and the Lisp community. I have no idea
why you interprete this as any kind of appeal for personal aproval. Really,
I don't. If you expect nothing from a community it is only because you
either don't know what the word means or you do not believe in giving
anything so why should you get anything. That is your right, but I think it
is a sad thing to reject out of hand the concept of people sharing some kind
of common ground. If you feel you are part of the "community" in more than
just the fact of your presence, the only useful thing you can do in this
thread is say what you would like that common ground to be, if not then keep
your very negative world view to yourself.
> b) You are only a Lisp programmer, but you are not the inventor of Lisp
> nor you are in any Lisp-standard-commitee (prove me wrong)
>
Completely non-sequitor. An obvious truth, but who said any different?
> c) Do you really think that promoting a language or a product in a
> newsgroup will really change the behaviour of the community?
>
Why in the world not?
> d) Naggum! You will have to learn that you are not alone on this planet.
> And when there is the situation that most part of the community is not
> on your side, so you should accept it. Nobody impedes you, and you can
> make your own Common-Lisp-Naggum standard.
>
Very strange statements. You can only be misunderstanding on purpose.
This world view, where everything is "sides", and usually this implies only
two, is not an accurate reflection of reality. Instead of refferring to
this nebulous "side" of Erik's that most of us are not on, the only useful
thing you can do is explain your own opinion (the topic would be what your
hopes for lisp the language and lisp the community are, not your opinion of
Erik or his motives)
> e) Write a book about good Lisp style ( you may not have to search for a
> publisher; there is a WWW, you can put it as LaTex/DVI or whatever you
> prefer for downloading on your homepage)
>
> f) Erik, you are a buck more naive as thought.
>
>
> So, this was my last conversation with you, because the coming soon
> situation will be: Whining Naggum will write:
>
> Fucking: "I think you are reading a _lot_ of stuff into what I said
> that simply is not there, and the rest of your
> message is so far out I think this conclusion is...".
>
This is self serving for sure. Provoke him and then predict he will lash
back.
> Naggum, this is not my problem when you believe other people are not
> capable of reading your posts. Then you must not write posts.
>
You must know I dislike a great deal of what he posts, but this one it is
obvious you did not try to understand.
Coby
--
(remove #\space "coby . beck @ opentechgroup . com")
How about a Common Lisp test suite for conformance? While there are many
things to deride in Perl, the interpreter self test and the very
organized way in which well written modules test themselves during
installation is a thing of beauty. I'm sure that the major Lisp vendors
have regression test suites - perhaps one would be willing to open
source their suite to jump start such an effort.
As a relatively new user, I think that the lack of community standards
for real world issues like network io and multi-threading are silly,
given how close the implementations really are (look at CLOCC). These
issues are critical parts of almost any real application written today -
but the community seems to be unable to build any new standards after
exhausting itself on defining Common Lisp. A language can't remain
static forever, new uses will ultimately drive new requirements which
should result in new standards.
Are there any Common Lisp test harness setups, like Perl's Test.pm, that
might be used as a basis for package level self test?
joe
That was hastily written and really should only apply to the inventor
part...
Siegfried> S. Gonzi
Siegfried> [By the way. I do not think that Franz Inc. is that devil. I cannot
Siegfried> imagine that a company is greedy when they also give defacto free Lisp
Siegfried> versions for Linux.]
What does "defacto free" mean?
And I don't consider it free. It used to be free, but nowadays it's
really an evaluation copy. Use it, evaluate it, and then either buy
it or throw it away after some fixed period. Unlike Lispworks, where
you can use it "forever" (I think).
Ray
P.S. I'm not bashing Franz for this change. They have to make money
after all and if they collapsed because they gave away Lisp for Linux,
I wouldn't be happy, even though I don't have any Franz product.
There seems to be disease-of-the-day:
To critizize and question every suggestion, decision, institution and
motive. My wife works at a big accounting firm and she had a conversation
with one of the older managers there. He commented on how people are now
hired for a certain skill set, to do a certain job, refuse to take any
directions (to be told what to do), and question everything to the point
where nothing gets done. He said in his day that when the boss told him to
do something (and something he had not done before, or was hired to do) he
said "Yes Sir" and just went and did it. Everybody is a know-it-all these
days. Humility is part of the road to understanding.
When I was younger learning to program was like that, I took what I was
given, I did not question if was the right way or the best way. I just did
it, I had the underlying assumption that what I was using was created by
some people who knew what they were doing. If it does not, what does it
matter? If CL is not the final word, or the best word, what does it matter?
I use it now because it is a labour of love. I still strive to have that
beginner's mind, because its the only time that I can learn.
Wade
Be a Great Student. The rest will follow.
> [barbarically wrenched from surrounding context,] Erik Naggum wrote:
>
> > Then I have no reason to expect anything from this community at all and
> > the vendors are indeed right to denounce their own livelihood and try to
[...]
> a) Why do expect anything from the community; or better: why should the
> community care on Naggum?
There are three reasons I can think of for your having asked that question
One is that you don't understand what a community is. A community is
not just a random collection of people, it's a group of people who
have a common purpose or a common interest. Given a common cause and
a collection of normal socially adjusted people, it's _inevitable_
that they will care about each other.
The second is that you don't believe Erik is part of the CL community.
There are two things I'd like to say here: (1) of course he bloody
well is! (2) supposing that there were any doubt, would you rather be
part of an open and welcoming community, or would you rather make
newcomers sit a written entrance test and swear allegiance to the flag
before you let them in? David Miller tells a story about the first
email exchange he had with Linus Torvalds, where he describes the
"dumb question" he asked, and the considered response he got
encouraging him to go on and hack on it and "assuming I knew what I
was doing". "This is cool. Why would I not want to work on a project
run by guys like that?". Davem later went on to port Linux to the
SPARC architecture, and has also hacked on SGI, networking and the VM
system.
The third is that you're questioning whether a community even exists
at all. In my darker moments I have doubts. I think there's the
basis of one. I don't think it's particularly cohesive. I _think_
(this is just gut feeling, I have no evidence) that it's picked up
somewhat over the last couple of years. I do know that an atmosphere
where people look like they're unhappy with their tools and like they
mistrust and don't respect each other is not conducive to its growth.
I'm spending less and less time reading c.l.l lately because it's just
too damn depressing.
-dan
--
http://ww.telent.net/cliki/ - Link farm for free CL-on-Unix resources
according to the Christophe Rhodes' tests, the current development CLISP
is more compliant than CMUCL 18c wrt pathnames.
> These are not best efforts that fall short for lack of resources
> and that will be fixed given the resources. These are _intentional_
> violations. I call them "political bugs".
All differences between "clisp -ansi" and ANSI CL are due to lack of
resources.
We will gladly accept patches and constructive discussion towards full
ANSI compliance. Please subscribe to <clisp-list> and write there.
This has been stated so many times that I fail to see the reason for
your rudeness.
PS. I do love ANSI CL, and I don't think I need to be taught how to love.
--
Sam Steingold (http://www.podval.org/~sds)
MS: Brain off-line, please wait.
> installation is a thing of beauty. I'm sure that the major Lisp vendors
> have regression test suites - perhaps one would be willing to open
> source their suite to jump start such an effort.
There's some portion of a CL conformance test in CLOCC already. There
are also Christophe's Rhodes (work in progress) pathname tests which
were discussed here recently that could be integrated into that
framework; also there's the beginnings of a test suite for SBCL in
the SBCL source archive. Some of that will be SBCL specific, but I
think it includes at least some ansi conformance tests too.
So, sure it would be nice if one of the vendors were to contribute
towards this effort, but it's a project where users can work on an
equal footing too.
> Are there any Common Lisp test harness setups, like Perl's Test.pm, that
> might be used as a basis for package level self test?
There's XPTEST from Onshore (see CLiki) and there's RT in the CMU AI
Repo (which I would love someone to package for cCLan because then I
could remove the copy hidden inside db-sockets). I've also heard of
something called which may be called "CL Unit", but I can't find that
right now.
> All differences between "clisp -ansi" and ANSI CL are due to lack of
> resources. We will gladly accept patches and constructive
> discussion towards full .ANSI compliance.
This is certainly nice to hear said.
Btw, in discussing the issue of conformance, and the related issue of
whether :ANSI-CL should be on the *FEATURES* list, that's why we
created the notion of "purporting to conform". Without this, every
time you discovered a bug, you'd have to remove the :ANSI-CL feature
until you fixed it. To me, at least, this underscores that compliance
is to some extent just an issue of "intent" as much as anything else.
I've often said informally that what it means for an implementation
to conform is to happily accept bug reports.
Btw, I don't know to what extent clisp is merely "missing functionality"
and to what extent it's repairing a prior set of deviations from standard
functionality, but if it's mostly the former, then claiming to conform to
a subset is perhaps the appropriate interim terminology. (I'm quite
curious how far it is from being totally conforming, actually, though I
suppose I should go check out the web site. I think I tried to do that
the other day, but the site wasn't responding...)
>
>
> However, there is something _very_ seriously wrong with the Common Lisp
> community. People _in_ the community feel that it is perfectly OK to
> debase, denigrate, ridicule, denounce, disrespect, insult, defame, and
> smear Common Lisp. Instead of telling people how great a language we
> have, some certifiable nutcases spend their time propagandizing and
> agitating against the language, creating stupid deviant versions and
> breaking with the language as defined, doing something other than what
> was agreed upon, and introducing "features" that cause the knowledge
base
> for the language to be polluted and the skill of knowing Common Lisp to
> be nigh worthless when faced with individual Common Lisp systems.
While I hope this is an exageration of the reality I agree there is this
tendency and it is a negative one though it need not be. I think it stems
from two things, one a good thing one not.
The bad: people are letting the pressure of mainstream opinion beat them
down. Even if they like lisp, they get so much flack from others who know
nothing about it, they feel they have to put it down themselves. A "herd
mentality"takes over, even though they want to be different, they are afraid
of what it really requires.
The good: lisp people tend to be the kind of people who question things and
think hard about elegance and the Right Thing (certainly compared to most of
the other large programming communities) People who question find fault.
But I agree with Erik that this can be done in a constructive and positive
way without "throwing out the baby with the bathwater"
> Can we do this? Can people who are still enthusiastic about Common Lisp
> the language, even after reading a 20K long news article, please raise a
> hand and express their feelings? Can you stand up and say "I _love_
> Common Lisp!" in a crowd and feel proud of yourself?
I _Love_ Common Lisp!
(I am also blessed to have worked with it in my last two jobs as well as my
current position!)
> I actually believe thare are enough Common Lisp enthusiasts out there to
> make a difference
I believe so... time will tell.
This is a
> We will gladly accept patches and constructive discussion towards full
> ANSI compliance. Please subscribe to <clisp-list> and write there.
> This has been stated so many times that I fail to see the reason for
> your rudeness.
I installed the latest available version of CLISP for GNU/Debian unstable
because I was going bananas over the incompetence of a web designer who
was supposed to help us get a secure news server with a web interface for
user registration up and running in two weeks and I needed something to
help save the day. I am quite happy to say that CLISP saved the project
and let me produce web pages efficiently and correctly, and I had no clue
to how this should be done using available tools when I started, which is
why I _had_ to use Common Lisp so I at least had some firm ground under
my feet. However, what I quoted from the man page is precisely among the
things that have put me off CLISP for many years. Remove the denigratory
remarks about how ANSI CL is broken and how standard behavior "is not
useful for actual everyday work". If I want somebody's snotty opinions
on the standard, I shall ask for it. I do not want them in a man page
for a purportedly conforming implementation that I want to use because I
am excited about the language. This has to do with the _professionalism_
in the community, not with conformance or how right anyone are about
their comments. Professionals set aside their personal opinions when
they do their work and focus on the work at hand.
///
> And I don't consider it free. It used to be free, but nowadays it's
> really an evaluation copy. Use it, evaluate it, and then either buy
> it or throw it away after some fixed period. Unlike Lispworks, where
> you can use it "forever" (I think).
Actually, we recently revised http://www.franz.com/downloads/ to
remove the 6 month limit. Also, the 30-day renewal period has been
changed to 60 days (automatically renewed via a program).
Kevin
the former.
please see http://clisp.cons.org/impnotes.html#intro for the list of
symbols missing from CLISP (actually, the pretty-printer has been almost
implemented in the CVS, so the list will go down with the next release).
see http://clisp.cons.org/impnotes.html#ansi for the explanation of what
the -ansi option is about.
the page is accessible to me right now.
sorry about the outage (even though it was not my fault :-)
--
Sam Steingold (http://www.podval.org/~sds)
Support Israel's right to defend herself! <http://www.i-charity.com/go/israel>
Read what the Arab leaders say to their people on <http://www.memri.org/>
Marriage is the sole cause of divorce.
> On Fri, 31 Aug 2001 05:57:38 GMT, Erik Naggum wrote:
> >
> > [... 9 pages of interesting thoughts and statements ...]
> >
[snip]
> other people about LISP and how great a language it is. The key word to all
> that, however, is "language". In your article you made an impression
Hmm. You need to get the actors right: "While reading your article I
formed the impression..."
> that
> LISP is a religion or at least a philosophy
Even if you got this "impression", it's clearly not what he
wrote. Furthermore, it's clearly possible for Erik to have written what he
wrote WITHOUT him thinking that (since, after all, he doesn't think
that, AFICT, and he wrote that article; *ad esse, ad posse est*).
(Furthermore, I think he went out of his way to convey his lack of that
belief.)
> and that un-believers (so-called
> "destructive/rabid nut-cases" or "negative morons") are sent by the satan.
No, if they were *just* sent from Satan, and had the wide array of talents
being in Satan's employ required *and used them to promote Lisp and its
community*, or merely refrained from harming it, I think Erik would
embrace them. Gingerly perhaps, depending on the number of infectious
lesions on their skin or psyches, but embraced them nevertheless.
> The problem here (IMHO, of course) is that LISP is _not_ a religion and it
> _not_ even a philosophy, instead it _is_ a tool and it _has_ good and bad
> sides.
Even if Erik had argued the contrary, what you say is rather
tendentious. Read Kent Pitman's aritcle on languages as political
parties. Even if you *don't agree*, I don't see that you get to *blindly*
and *without evidence* assert the contrary.
In any case, Erik wasn't talking about Common Lisp, the language
*alone*. He was discussing the community of developers, designers, users,
enthusiaists, venders, writers, etc. that have have the langauge more or
less as a focal point, or, at least, a principle shared concern.
That community isn't a tool. Indeed, for everyone in, of, or around that
community to treat it as a tool, and a tool they don't care to treat
properly, would be rather damaging.
> Moreover, people who choose to be blind when it comes to the bad sides
Unlike Erik...
> and to the fact that standards change and new needs arrive,
Unlike Erik...
> _can_ be called
> "religious zealots".
Unlike Erik...
...but even so, why call them religious zealots? On most issues it's not
at all clear cut (i.e., that the feature is bad, that it's so bad we must
thrash it and anyone who's thought about using it immediately, and that
there's a superior alternative so much so that everyone should...nay
*MUST* adopt it...NOW).
(If you *really have* such a superior alternative, most of the time it
should stand on it's own. I.e., if it's so great just *show* it, maybe
talk it up. I don't see that it actually helps, except in limited cases,
to trash what it purports to replace. Indeed, Erik said this only about
10,000 times :))
And why call them religious zealots? Interestingly, Common Lisp *is* born
of a philosophy...one that Kent (and others) have explained over and
over. Roughly, "a common, standard base that we all can agree to live
with". I think it reflects well on the community that embraced this
philosophy that the result is *also* engaging, interesting, practical, and
worth studying and use and getting enthusiastic about.
Alas, the ANSI Smalltalk standard hasn't similarly succeeded (although,
it's sorta young in that cycle). Partly, it defined so much less, and
*didn't* standardize a lot of the stuff that Smalltalkers get enthused
about (graphics, guis, the ide, etc.) So we tend to have different
rallying points (Camp Smalltalk, mostly; roughly, a party, often
associated with a conference, where a bunch of Smalltalkers get together
and work on cross-dialect/implementation projects; a report from the
latest: http://www.smalltalkconsulting.com/html/CSEssen2001_1.html; the
CSt wiki: http://wiki.cs.uiuc.edu/CampSmalltalk).
[snip hammer stuff]
FWIW, if you thought you were being simple, sensible, and consilitory, and
even if what you wrote up to this point *was* so, I would find the hammer
stuff irritating were I in Erik's place. I mean, really.
Cheers,
Bijan Parsia.
* Erik Naggum
> This is a
... very nice thing to hear.
Don't know why that was so hard to say. :)
///
> > * Honorable Erik Naggum <er...@naggum.net> writes:
> >
> > standard pathnames are broken by design so not supported
>
> according to the Christophe Rhodes' tests, the current development CLISP
> is more compliant than CMUCL 18c wrt pathnames.
... and I hope I haven't made any mistakes.
Christophe
[ Please, read the code (and comments); patches and/or rewrites welcome]
But why sbould they have to be shown what it feels like to be
denounced? They didn't denounce *you*, they denounced (a tiny part
of) a programming language.
Your behavior reminds me of a child on a schoolyard playground.
Someone makes a disparaging comment about your favorite toy, and you
respond by hitting them and throwing a tantrum. You've been throwing
these tantrums for years now. Have they helped?
Let me try to short-circuit some of this conversation by anticipating
your answer. You are going to say something along the lines of: "Yes,
they've helped, because they drive away fucking morons like you, Erann
Gat, who clutter up this newsgroup with mindless drivel about
politeness and false accusations of neo-naziism."
Fine. (You're right, by the way. You actually did drive me away.)
But while you mold this newsgroup into your perfect little cadre of
Erik Naggum sycophants the language you claim to love so much is
withering and dieing, and you don't even notice. You talk about "the
Lisp vendors." Well, I've got news for you, Erik Naggum: there is
only one Lisp vendor left. All the others are out of business.
> languages thrive only when people love them
You are wrong, Erik Naggum. Do you really think C++ and Java thrive
because people love them? Ridiculous. Languages thrive because
people *use* them, not because people love them. So Erik, please stop
trying to convince people to love Common Lisp. Your brand of love is
poison.
Erann Gat
g...@flownet.com
...what?
> I installed the latest available version of CLISP for GNU/Debian
> unstable [...] to help save the day. I am quite happy to say that
> CLISP saved the project and let me produce web pages efficiently and
> correctly,...
I am quite happy to hear this.
> Professionals set aside their personal opinions when
> they do their work and focus on the work at hand.
exactly.
so when you have "work at hand", you use CLISP (or ACL, or whatever tool
you want) and act as a professional, and when writing to c.l.l, you
badmouth the people who brought it to you. makes sense: you are not at
work and you do not have to act as a professional. :-)
BTW, why don't you direct at least some of your venom to GCL?
It does not even purport to comply!
As to the passages on the CLISP pages which disturb you so much - well,
CLISP is a large project, and I am not done with it yet. :-)
Please send patches, to the pages and to the CLISP sources.
--
Sam Steingold (http://www.podval.org/~sds)
Support Israel's right to defend herself! <http://www.i-charity.com/go/israel>
Read what the Arab leaders say to their people on <http://www.memri.org/>
Two wrongs don't make a right, but three rights make a left.
No, Erann, that is where you are wrong.
> Your behavior reminds me of a child on a schoolyard playground.
I am quite sure it does. Children in schoolyard playgrounds also appeal
to a sense of justice, they have an elaborate sense of fairness, and they
believe in such trivial things as standardization processes. What things
remind you of says something very fundamental about yourself. If I were
you, I would have chosen to tell people I was reminded of something else.
> Someone makes a disparaging comment about your favorite toy, and you
> respond by hitting them and throwing a tantrum. You've been throwing
> these tantrums for years now. Have they helped?
This is the level at which you would operate. I am so glad I am not like
that.
> Let me try to short-circuit some of this conversation by anticipating
> your answer. You are going to say something along the lines of: "Yes,
> they've helped, because they drive away fucking morons like you, Erann
> Gat, who clutter up this newsgroup with mindless drivel about politeness
> and false accusations of neo-naziism."
Amazing. What kind of immature behavior does _this_ remind you of?
> Fine. (You're right, by the way. You actually did drive me away.)
> But while you mold this newsgroup into your perfect little cadre of
> Erik Naggum sycophants the language you claim to love so much is
> withering and dieing, and you don't even notice. You talk about "the
> Lisp vendors." Well, I've got news for you, Erik Naggum: there is
> only one Lisp vendor left. All the others are out of business.
I am so delighted that you actually managed to get the ideas I tried to
communicate and were not stuck in your old rut and just dug up some old
dirt you could throw at me. That would have been so -- childish.
> You are wrong, Erik Naggum. Do you really think C++ and Java thrive
> because people love them? Ridiculous. Languages thrive because people
> *use* them, not because people love them. So Erik, please stop trying to
> convince people to love Common Lisp. Your brand of love is poison.
I love you, too, Erann Gat. Now, is your recess over, yet?
///
> BTW, why don't you direct at least some of your venom to GCL?
> It does not even purport to comply!
If it doesn't purport to comply, it's not bound by the standard.
Now, if only it would drop the "CL" bit, too...
Christophe
Are you incapable of understanding that _you_ have done something that
you could very easily correct to avoid all criticism? Is that you want
to _insist_ on badmouthing the standard that you fail to understand that
you _deserve_ this criticism?
> BTW, why don't you direct at least some of your venom to GCL?
Because they do not gratuitously defame that which they purport to
conform to.
> It does not even purport to comply!
Bingo! Please get the idea.
> As to the passages on the CLISP pages which disturb you so much - well,
> CLISP is a large project, and I am not done with it yet. :-) Please send
> patches, to the pages and to the CLISP sources.
You know what fix.
///
Kevin> Raymond Toy <t...@rtp.ericsson.se> writes:
>> And I don't consider it free. It used to be free, but nowadays it's
>> really an evaluation copy. Use it, evaluate it, and then either buy
>> it or throw it away after some fixed period. Unlike Lispworks, where
>> you can use it "forever" (I think).
Kevin> Actually, we recently revised http://www.franz.com/downloads/ to
Kevin> remove the 6 month limit. Also, the 30-day renewal period has been
Kevin> changed to 60 days (automatically renewed via a program).
Cool! I don't get to use Linux and lisp too often, so I don't keep
up.
Ray
Christophe> Sam Steingold <s...@gnu.org> writes:
>> BTW, why don't you direct at least some of your venom to GCL?
>> It does not even purport to comply!
Christophe> If it doesn't purport to comply, it's not bound by the standard.
Christophe> Now, if only it would drop the "CL" bit, too...
But I think it does claim to be a CLtL1 compatible and I think it is
reasonably close to that.
Sad to say, but Bill Schelter, the prime mover behind GCL and maxima,
has recently passed away.
Ray
criticism, yes. I welcome criticism, especially on <clisp-list> which
is more accessible to me that c.l.l.
insults - no. I think your choice of words is pretty insulting.
> > It does not even purport to comply!
> Bingo! Please get the idea.
but it is _called_ "Common Lisp"! :-)
> > As to the passages on the CLISP pages which disturb you so much - well,
> > CLISP is a large project, and I am not done with it yet. :-) Please send
> > patches, to the pages and to the CLISP sources.
>
> You know what fix.
maybe, but how am I supposed to know what changes would satisfy you?! :-)
--
Sam Steingold (http://www.podval.org/~sds)
Support Israel's right to defend herself! <http://www.i-charity.com/go/israel>
Read what the Arab leaders say to their people on <http://www.memri.org/>
If your VCR is still blinking 12:00, you don't want Linux.
SS> maybe, but how am I supposed to know what changes would
SS> satisfy you?! :-)
I'll hazard a guess:
(From the clisp man page dated 31 May 2001, on Debian sid, v2.27)
...
-ansi ANSI CL compliant: Comply with the ANSI CL specifi
cation even on those issues where ANSI CL is bro
ken. This option is provided for maximum portabil
ity of Lisp programs, and is not useful for actual
everyday work. It sets the symbol macro *ansi* to
t. See impnotes.html, section "Maximum ANSI CL
compliance", for details.
...
the fix could be
-ansi ANSI CL compliant. See impnotes.html, section
"Maximum ANSI CL compliance", for details.
cheers,
B<I am blind to emoticons>M
Fine, consider the fact that I am insulted by your manual page.
> maybe, but how am I supposed to know what changes would satisfy you?! :-)
Wipe that grin off your face, think, and you will know.
///
> Are there any Common Lisp test harness setups, like Perl's Test.pm, that
> might be used as a basis for package level self test?
Check the ANSI test suite which comes with CLOCC. I'm not familiar with it,
so I don't know how complete it is.
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://web.mclink.it/amoroso/ency/README
[http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/]
In that case I heartily apologize, I will reread your article and try to
understand what you really meant.
Regards,
rk
By the way, if the commetn about "not useful for actual everyday work"
is really serious, I'd like to hear an explanation of that.
There are a few typos in the standard that tell you weird things like that
unless should work identically to when or something equally dumb. Everyone
disregards them, and even ANSI's definition of what may be fixed by editorial
change (without the need for a technical vote) is I think broad enough to
include stuff like this that is so blatantly wrong that everyone just knows
it and fixes it when they see it. I hope ANSI mode does not force compliance
with typos.
Beyond typos, though, I am unaware of any ANSI CL requirement which assures
that you won't be able to get work done, unless the implementor has made a
poor design choice. I could just be deficient in my understanding of the
implications of what we decided, but I would certainly like to hear that
elaborated.
(I'm assuming also that this is not a religious argument like that it's not
possible to write a fast XML implementation if you don't preserve case or
force it to lower, or something like that. But if it's that, I guess we
should all know it.)
> Well, I've got news for you, Erik Naggum: there is only one Lisp
> vendor left. All the others are out of business.
Which one? Franz? Call me crazy, but I can think of several:
Xanalys, Digitool, Corman. There's also that rumored commercial fork
of CMUCL.
> You are wrong, Erik Naggum. Do you really think C++ and Java thrive
> because people love them? Ridiculous. Languages thrive because
> people *use* them, not because people love them.
That's why C++ thrives. I think Java thrives for a variety of
reasons. But who wants Lisp to thrive like those? Not me. I'd love
it if it thrives like Perl or Python. Those languages thrive because
of how much their users love them.
This is the mentality of people who defend a fortress that is being
besieged. But in this case the problem is that people do not even care to
take a closer look at that fortress, let alone besieging it.
Now I do not love computer languages, I simply use them to solve problems
and probably most programmers think like me. This attitude does not make me
to an evil person.
Statements like 'Lisp is dying' cannot be made precise and making statements
about 'why it is dying' is absolutely useless as such statements could never
be falsified by experiment. So I do not understand, why you do not disregard
such statements.
Additionally, 'membership in the Lisp community' is not well defined either
so I do not see how such a 'membership' could end.
Your old friend,
Janos Blazi
-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
Check out our new Unlimited Server. No Download or Time Limits!
-----== Over 80,000 Newsgroups - 19 Different Servers! ==-----
Nobody is even hinting at saying or meaning anything that stupid.
> Now I do not love computer languages, I simply use them to solve problems
> and probably most programmers think like me. This attitude does not make
> me to an evil person.
No, but it makes you an irrelevant person.
///
this (unfortunate and now removed) comment is _very_ old
(from long before my days).
the only place where ANSI CL standard is (IMHO) deficient is readable
pathname printing: #p"" is ambiguous (#p".foo" can be #s(pathname :type
"foo") and #s(pathname :name ".foo")). the #s(pathname ...) (and
#s(logical-pathname)!) notation, while used in a couple of CLHS pages,
has not been standardised. any chance it ever will be?
--
Sam Steingold (http://www.podval.org/~sds)
Support Israel's right to defend herself! <http://www.i-charity.com/go/israel>
Read what the Arab leaders say to their people on <http://www.memri.org/>
Let us remember that ours is a nation of lawyers and order.
> Can we do this? Can people who are still enthusiastic about Common Lisp
> the language, even after reading a 20K long news article, please raise a
> hand and express their feelings? Can you stand up and say "I _love_
> Common Lisp!" in a crowd and feel proud of yourself?
I love Common Lisp!
16 years ago I changed career directions in order to become
a part of this exciting, new version of one of the oldest
programming languages. I have never regretted a moment of it.
I am the current primary implementor/maintainer of the core
of Allegro CL. As such, it is my responsibility, under the
guidance of my manager Kevin Layer, to ensure that as much
as possible, we track the ANSI standard. When it is pointed
out to us that the standard is violated, we log a bug report
against that violation and prioritize it to fix it as soon as
possible. We also have a fairly extensive test suite, which we
are continually updating and enhancing; it ensures that those
bugs we fix to bring us ever closer to the standard remain
fixed.
Also as primary implementor/maintainer of the Allegro CL core,
I am committed to providing users with choices. I take this
mandate from my manager and from my Company, which as an
organization promotes the success of our customers by providing
choices to our customers. Where the Common Lisp spec fails to
specify such needed features as multiprocessing, foreign functions
interfaces, extensible streams implementations, locale and
internationalization support, etc, I am involved in the efforts
to bring those features to our customers, without sacrificing any
ansi compliance.
Of course, using such extensions make a user's code non-portable
to Common Lisp implementations from other vendors, but the
availability of these extensions is what gives the choice to
customers as to whether and how much portability to sacrifice
in order to get work done. Many of our customers choose to use
several versions of CL and to wrap non-portable extensions from
each vendor in macro packages they provide. However, whatever
the extension is, we always provide the choice to stay with pure
ANSI CL, with no usage of extensions or modifications, and to
thus remain perfectly portable between conforming ANSI CL
implementations.
I am passionate about Common Lisp. And I am grateful to my
employer, who allows me to be passionate about it, and to
have strong opinions about it without fear of retaliation.
I am also grateful to my colleagues at Franz, Inc., who are
very competent at what they do, and who are also very passionate
about Common Lisp. I am also amazed that such a large group
of developers as we have with such strong (and sometimes
opposing) opinions can work together, but we do it; we work
together every day. I think that we succeed because we have a
common goal, and what results is a vibrant product which meets
the needs of many more people than a more lackluster product
would meet.
--
Duane Rettig Franz Inc. http://www.franz.com/ (www)
1995 University Ave Suite 275 Berkeley, CA 94704
Phone: (510) 548-3600; FAX: (510) 548-8253 du...@Franz.COM (internet)
No human being is irrelevant. To say that somebody is irrelevant is callous.
But should you mean 'irrelevant to the Lisp community' so we are returning
to our starting point.
J. B.
> Perhaps this was a naïve thing to do.
Of course it was a naive[*] thing to do. It's amazingly naive to
think that such a post will make any difference at all. But who said
naivete' is all bad? Computer science, and software engineering[**]
to the extent that it's not production-line, is powered by naivete'.
Trying to solve difficult problems that you may not even really
understand, and when "solve" probably doesn't mean "create a
solution", that's naive. Just so long as we're able to keep a
skeptical part of our brains going at the same time, that naivete' is
a wonderful thing.
[*] Why does it have to be so difficult to type Latin-1 characters in
the US? I have a great setup at home, but the second I get to a
computer lab, I can only write nave.. In California, for godsakes. I
wonder when MS will get the clue that this is not an English-language
country, it's an English-Spanish-Chinese language country. Maybe it's
because of the lilly-white suburb they work in. That's one of my
favorite things about Sun workstations: the <compose> key. And Sun's
in the South Bay here in Cali, hmmm...
[**] I don't like the term "software engineering", but I think that's
mainly because of ideas that others have attached to it. Programmers
generally act as scientists or engineers. I don't know what else to
call a programmer-as-engineer.
> We need to throw out and bury the corpses. Those who think Common Lisp
> sucks are _not_ members of the Common Lisp community. Those who want to
> work with Common Lisp should feel free to express their _love_ for the
> language, should not be ashamed to be _excited_ about their language,
> should feel comfortable _sharing_ with others in the community, and
> should experience a strong sense of commmon competence, intelligence and
> care from joyful, happy people who have seen a great languge survive all
> sorts of problems and changes and still remain a truly great language.
> This is not possible when people who hate parts of the language, some of
> the people who created it, or some of the process that created it, who
> hold personal grudges they cannot let go of, or who think the best way to
> "improve" the language is to stay in the community and spread negativity
> and tear down everybody else's enthusiasm, do just that.
I agree with this sentiment. Common Lisp is in desperate need of a
good split or two. Paul Graham, for example, loves Lisp. He's got an
amazing enthusiasm for Lisp that is obvious from reading about
anything of his. But he hates Common Lisp. That's bad for CL and bad
for him. His vision of a perfect Lisp is *very* different from CL.
And I wish he'd go and try to build it. Probably he doesn't have the
time, which is too bad. I'm sure it would make people very happy and
help to create a new, enthusiastic Lisp community, and possibly leave
the CL community free to become more enthusiastic.
> I felt like I was born a Lisper, that this was the language that matched
> how I thought, as opposed to Fortran, Cobol, Pascal or any of the other
> Algol derivatives, which I had of course learned and played with. (The
> only other language that had said "me" was the assembly language of the
> PDP-10, MACRO-10.)
I'm curious, what other languages do people feel at home it? For me,
the only other language that gave me the giddy thrill I got from Lisp
was PostScript.
| [*] Why does it have to be so difficult to type Latin-1 characters in
| the US? I have a great setup at home, but the second I get to a
| computer lab, I can only write nave.. In California, for godsakes. I
Since you sent that article with Gnus/Emacs, you should be able to
type Latin-1 characters in Emacs using latin-1-prefix input method
which you can turn on with C-u C-\ latin-1-prefix RET. For a
description on how to use it, see C-h I RET after turning it on.
--
Hannu
Thank you.
> the only place where ANSI CL standard is (IMHO) deficient is readable
> pathname printing: #p"" is ambiguous (#p".foo" can be #s(pathname :type
> "foo") and #s(pathname :name ".foo")).
The implementation has to make some design choices when it comes to
mapping pathname namestrings to and from the underlying operating system
and its inevitable differences from the pathname concept. For instance,
Unix makes no distinction between "/tmp/foo/" and "/tmp/foo", but these
mean different things entirely in pathnames if the former has :directory
(:absolute "tmp" "foo") and the latter has :name "foo". Likewise, since
"dot files" are possible in Unix and get somewhat strained when
shoehorned into the pathname concept, you have to make a design choice
and stick by it. When things are ambiguous, the only thing you need to
do is document your choice, but if you are really nice, you can make it a
user-configurable option.
> the #s(pathname ...) (and #s(logical-pathname)!) notation, while used in
> a couple of CLHS pages, has not been standardised. any chance it ever
> will be?
Not unless we define a particular Unix bindings or pathname concepts.
///
> To say that all those who do not exactly share your opinion should be thrown
> out of the community is an extremely dangerous thing and I hope there are
> not many NGs where you can get way with this mentality.
Well I thought Eriks point is that there are people who do not like
common lisp but they do not go away and they continue to say bad
things about the language and this hurts the user community.
>
> This is the mentality of people who defend a fortress that is being
> besieged. But in this case the problem is that people do not even care to
> take a closer look at that fortress, let alone besieging it.
I do not think that was what was said in Erik's post. I got that
there is a "social contract" in the lisp community that some people do
not follow. The people inquestion should be ostracizedfrom the
community by the community, if you cannot play by our rules do not
play here is fair.
>
> Now I do not love computer languages, I simply use them to solve problems
> and probably most programmers think like me. This attitude does not make me
> to an evil person.
>
But it does not make you one of the passionate people Erik was talking
about, the heart & soul of the commmunity. A hacker in the old sence
of the word.
> Statements like 'Lisp is dying' cannot be made precise and making statements
> about 'why it is dying' is absolutely useless as such statements could never
> be falsified by experiment. So I do not understand, why you do not disregard
> such statements.
>
Now a knoledgable member of the community can not have an opinion
based on his experence with out a double blind studdy on the death of CL?
> Additionally, 'membership in the Lisp community' is not well defined either
> so I do not see how such a 'membership' could end.
>
Just because something is not well defined does not mean that it does
not exist. Perhaps the best way to look at it is that when other
members of the community acknoledge your membership you are a member
and if they decide otherwise then you loose membership.
marc
Actually, that's a feature of leim, which doesn't come with emacs by
default, and wasn't compiled into the emacs 20.7 here (it is in the
20.2, but then I can't use VM...sigh). So, lacking special
application support, I'm stuck with what this NT box gives me, which
is not much.
> I'm curious, what other languages do people feel at home it? For
> me, the only other language that gave me the giddy thrill I got from
> Lisp was PostScript.
For me it's Common Lisp, Dylan and Smalltalk.
Chris.
--
http://www.double.co.nz/cl
Try typing C-x 8 " i. This is a standard Emacs feature.
///
Ah, well, thanks for clearing that up.
Let me know when you muster the gumption to deal with the substance of
my remarks, will you? In the meantime, farewell. I'm going back from
whence I came. Adieu, Common Lisp! I hope it helps that I still love
you despite the fact that I don't use you any more.
E.
What substance? Not even your pathetic attempts at insults had substance.
///
Would someone please explain the difference between "Lisp" and "Common
Lisp"? I thought that the whole standardization process was to pull
together all the Lisps. What is Paul Graham's vision (besides what he wrote
in the article "To Be Popular")? Would not this new Lisp be expressable in
CL? His long-builtin-name complaint is easily fixed by creating shortened
macro names for the builtins. His idea of a Python like external syntax, a
new syntax with a read/load/write system. He also said Libraries (just a
matter of effort), hackability (symbols in packages can be seen, changed).
Does not CL have attributes from all the Lisps that went before?
I am not even sure I can envsion a better Lisp.
Wade
> Would someone please explain the difference between "Lisp" and "Common
> Lisp"?
Lisp is a language family. Common Lisp is a specific syntax/semantics.
> I thought that the whole standardization process was to pull
> together all the Lisps.
The whole purpose of Pat Buchanan leaving the US Republican Party was to
allow all right-thinking folk to follow. Does that mean those remaining
behind were not right-thinking?
We did pull together a lot of lisps. But not all of them. I would say
that AutoLisp, Gnu Emacs Lisp, ISLISP, and COmmon Lisp are all legitimate
members of the Lisp family. Some would also say Scheme is, but it's not
necesary to believe that in order to believe that Lisp is a broader collection
than Common Lisp.
Digitool's Lisp (which BTW and IMO is the greatest single software
product ever) runs only on a niche platform that is itself rapidly
losing market share. The company, as far as I can tell, is hanging on
by its fingernails. They don't even have a street address any more,
just a PO box. I am frankly astonished that version 4.3.1 actually
happened. Alice must be putting in a truly heroic effort. (Good for
you Alice, wherever you are.) Corman is a one-man operation. There's
no street address, no phone number, not even a .com Web address. I've
not used Corman Lisp, so I can't judge its quality; it may be the
greatest thing since sliced bread. But if you go to a manager and
point to Corman Lisp as an example of a Lisp *vendor* you'll be
laughed out of the office. The "rumored" commercialization of CMU
speaks for itself. As for Xanalys, allow me to quote from Franz's Web
site:
"Although Xanalys is maintaining the Harlequin products, Franz remains
the sole commercial Lisp vendor focused on enhancing and improving
Lisp."
So maybe there isn't only one Lisp vendor, maybe there are 1.84, maybe
even 2. Whatever the number is, it's perilously close to zero, and
that's the real issue. And we won't solve that problem by quibbling
over exacly how many Lisp vendors there are or aren't, or whether Loop
is the greatest thing since sliced bread or should be avoided like the
plague, or by hurling epithets like "pestulent corpses" around.
> > You are wrong, Erik Naggum. Do you really think C++ and Java thrive
> > because people love them? Ridiculous. Languages thrive because
> > people *use* them, not because people love them.
>
> That's why C++ thrives. I think Java thrives for a variety of
> reasons. But who wants Lisp to thrive like those? Not me. I'd love
> it if it thrives like Perl or Python. Those languages thrive because
> of how much their users love them.
I certainly agree it's best to have both. But if I have to choose I'd
much rather people use Lisp and not love it than love it and not use
it. Eric Raymond writes:
"LISP is worth learning for the profound enlightenment experience you
will have when you finally get it; that experience will make you a
better programmer for the rest of your days, even if you never
actually use LISP itself a lot."
I think Eric R. has it right, and Erik N. has it exactly backwards.
Lisp's problem is not that people don't love it enough. Quite the
contrary: Lisp's problem is that people love it too much, but don't
use it nearly enough.
E.
> As for Xanalys, allow me to quote from Franz's Web
> site:
>
> "Although Xanalys is maintaining the Harlequin products, Franz remains
> the sole commercial Lisp vendor focused on enhancing and improving
> Lisp."
Well this is heavy stuff. You cite a competitor and take thos words
for granted. Well I do not know how other feels but I do tink that is
a damn stupid idea.
Well we had to learn what Franz understands under improvements.
>
> So maybe there isn't only one Lisp vendor, maybe there are 1.84, maybe
> even 2.
What interesting implications. How many vendors are there for Perl?
Python? Ruby? Smalltalk? OCaml? Haskell?
> Whatever the number is, it's perilously close to zero, and
> that's the real issue.
Where's the issue? If we measure langauges just by how many vendors
there are we have to drop immedieatly 3 quarters or more of our tools.
Friedrich
> "Although Xanalys is maintaining the Harlequin products, Franz remains
> the sole commercial Lisp vendor focused on enhancing and improving
> Lisp."
Uh, Erann, I certainly put stock in at least some of your recent
observations, but this one seems to be reaching just a little. Last I
checked Xanalys hadn't hired Franz as their spokesmen. One might
imagine there's at least the possibility of bias in this statement.
> So maybe there isn't only one Lisp vendor, maybe there are 1.84, maybe
> even 2. Whatever the number is, it's perilously close to zero, and
> that's the real issue. And we won't solve that problem by quibbling
> over exacly how many Lisp vendors there are or aren't, or whether Loop
> is the greatest thing since sliced bread or should be avoided like the
> plague, or by hurling epithets like "pestulent corpses" around.
I doubt we'll solve any problem by worrying how many vendors there
are, even if that number is approaching zero. I bet there are several
times in Lisp's past when there have been no commercial vendors. Yet
that didn't kill Lisp. Vendor count doesn't matter; adequate supply
does. And there ARE ample Lisps to program in.
Counting vendors and pointing to the zero mark seems alarmist. (Btw,
I use the term "vendor" often, and I mean to include those who make
free versions as vendors. I think the making of money is irrelevant
except to the maker; the sustaining of support is relevant, and presumably
those who make free implementations are feeding themselves somehow.)
I'm frankly surprised Franz would point to there being only one
vendor--it must panic those who like second-sourcing availability.
I thought lack of "backup" was one of the common reasons for freaking
out about use of Lisp. And making it seem like there's no other source
also seems to provoke such concern unnecessarily, since in spite of
the lack of vendors-for-fee, it's pretty easy to second-source a Lisp.
IMO, a fair analysis would say that uniformly, people seem not to make
money, probably because it's hard to price a Lisp in a way that
recovers development prices, because other commercially available
programming languages are mostly low-margin products and low margin
products only work in high volume, which Lisp does not have...
There seem to be four basic strategies being pursued by Lisp makers:
* Volunteer time, don't account for it. There seems to be ample passion,
so this is not at risk. CLISP, CMU CL, and GCL seem to be in this camp.
* Sell Lisp and try to survive on the profit. This seems to be barely
paying people enough to eat, not because the products are bad but because
the market is small. Digging out of this is non-trivial. Digitool,
Corman, and maybe Eclipse and Symbolics seem to be doing this.
* Make Lisp but sell Lisp consulting. Franz seems to be doing this.
* Make Lisp but sell Lisp layered products. Xanalys seems to be
doing this. I think Franz often confuses Xanalys' lack of "presence"
in the Lisp sales community as lack of caring; that has yet to be
demonstrated--Xanalys does have products built on Lisp that it markets
aggressively. Given that it is effectively a recent "restart" company
which needs to prove to its funders that it can show healthy profits,
one can hardly fault them their chosen path. I've found their support
to be quite adequate to my own needs in spite of their low-key marketing.
Their product is in good order and I don't crave a new release.
It seems to me that although each of these four categories yields different
levels of profit, all are pretty much in steady state for the last couple
of years. Sure, Digitool is on the edge, but I thought it would be dead
years ago and it's not. The absence of Symbolics saddens me a little, but
putting aside my personal feelings, the loss of it from the arena might help
to unify the community around the MOP, since I'm not sure what other
implementations lack MOP support. Maybe Corman seems a garage operation, but
that just means "low overhead" and "robust against a fluctuating economy" to
me, so I don't fear that.
It would be nice to see one of them rocket up, but perhaps it's first up to
us as customers to build some success stories. We do have working tools
that should be up to that.
And, as has been said, it's a poor craftsman that blames his tools.
I have not insulted anyone, you hyper-sensitive twit.
if you have nothing better to do than to accuse people of things they go
out of their way not to say, I suggest not doing it here.
E.
> [...] Lisp's problem is that people love it too much, but don't use
> it nearly enough.
From where I stand, the latter half is painfully and obviously
true.
But here's a simpler, more obvious and more fundamental truth (at
least from my Australian perspective): Lisp's problem is that not
enough people KNOW it.
Why not? Partly because it's not widely used (huh!) in commercial
software. Partly because it's not being taught at universities. And
partly because it's not seen as one of the two or three best choices
for young hackers to build their clever toys.
It's a damn shame because (IMO) it's potentially the BEST language for
ALL of these uses, and they're largely interdependent. And of all of
these problems, I think the easiest one to solve is by far the most
important.
For want of a nail, the shoe was lost
For want of the shoe, the horse was lost
For want of the horse, the rider was lost
For want of the rider, the battle was lost
For want of the battle, the kingdom was lost.
I know it's common around here to argue something like "Lisp is not
optimised for mundane tasks; it's optimised for solving the most
difficult problems."
True as it may be, I think promoting Lisp this way is doing it a
terrible disservice. By the time today's youngsters get around to
solving extremely difficult problems (if ever), they've already
acquired half a dozen languages. They've already learned how to push
their current tools past their limits, and they're more than likely
constrained by their existing code base, availability of skilled
employees, and prejudices acquired through years of thinking in their
current languages. They're too far gone.
I think it is absolutely essential that Lisp be promoted as an
excellent language for solving simple tasks as well as the very
difficult ones. Otherwise it will not get a foot in the door.
When I was at university a few years back, we were taught Eiffel in
the first semester. In the second semester, one of the courses
required us to write some simple simulations. The instructor didn't
care which language we chose as long as the programs met their
specs. At least a dozen of the students were delighted with this
freedom of choice, and postponed this course in order to learn another
language first. Of all languages to choose, they chose C. They didn't
have a clue (and didn't seem to care) that the lists, hash tables,
stacks, queues and trees and Eiffel provided would have to be
hand-rolled in C. C had credibility, both as a "hacker's language" and
as an "industrial strength" language, so they thought it must have
something going for it that Eiffel didn't have.
At the time, Python wasn't widely known. Today I'd guess that at least
3/4 of them (all the females, and half of the males) would undoubtedly
have chosen Python instead of C. Because it is nice and simple, does
the job, AND has credibility as a "hacker's language". But nobody
considered Lisp. Nobody KNEW about Lisp.
I think free software will play a crucial role in the future of Lisp,
and I think it's role is seriously underestimated in this
newsgroup. With Linux becoming more and more usable by beginners,
there's no reason why Clisp and/or CMUCL can't become a standard part
of every distribution, they way Perl and Python have become in recent
years. Lisp code can be easily shared and worked upon by hackers
without the need for expensive tools or distribution of huge images.
IMO, the crucial missing pieces are the SMALL pieces.
A hacker who wants to build a toy very often finds him/herself wanting
at least one thing (besides a good language) that is dead simple in
Python, but not so simple in Lisp: Easy interaction with the operating
system. Along with that comes the GUI, the networking facilities and
ability to easily script the whole works. IMHO, the availability of
these simple things would do more to promote Lisp to the next
generation of hackers (thence "IT Professionals" and "Project
Manageres") than any more elaborate solutions. Once exposed to the
language, and once able to solve the trivial problems in this
language, who'd use anything else for complex tasks if they had the
choice?
> Digitool's Lisp (which BTW and IMO is the greatest single software
> product ever) runs only on a niche platform that is itself rapidly
> losing market share. The company, as far as I can tell, is hanging on
> by its fingernails. They don't even have a street address any more,
> just a PO box. I am frankly astonished that version 4.3.1 actually
> happened.
I am not at all surprised by the arrival of 4.3.1. If it is astonishment
for you, I think you haven't followed MCL/Digitool recently and should
revise your perception on the current shape of Digitool. They're working
on the MCL port for OSX right now.
> Alice must be putting in a truly heroic effort. (Good for you Alice,
> wherever you are.)
Declaring [falsely] that Digitool is out of business won't help her a
bit.
abe
--
<keke at mac com>
>
> It's a damn shame because (IMO) it's potentially the BEST language for
> ALL of these uses, and they're largely interdependent. And of all of
> these problems, I think the easiest one to solve is by far the most
> important.
I suggest you visit comp.lang.eiffel, comp.lang.sather even
comp.lang.smalltalk. You'll see the same arguments there.
Well I get from one "niche" language to the other, and at the moment
I very much on Common Lisp. It's an eye opener if you come e.g from
Eiffel as I did. Well and has cost me more money to find that than is
good for me. Did I Common Lisp 3 years ago. I would have good software
today written in it. Now I'm just starting to do "real" work in
it. And I have to say it did not care a dime if it's potentially best
language for anyone, it's good for me and just that counts.
And it seems to be possible to find projects where just one things
matter. Does it work? And they do not care too much what is used to
make it work. Well I suggest if you think Common Lisp is the best
since slice bread and that it beats everyting. Than go out try to get
your project and use Common Lisp.
Why does you care what other think. Why did you even care that Common
Lisp is unpopular. Does it work? Does it work for you? Will it work
for you? Will you bet on it? Than use it.
>
> I think it is absolutely essential that Lisp be promoted as an
> excellent language for solving simple tasks as well as the very
> difficult ones. Otherwise it will not get a foot in the door.
Well solve a simple problem and show it. What simple task have you
solve today?
>
> A hacker who wants to build a toy very often finds him/herself wanting
> at least one thing (besides a good language) that is dead simple in
> Python, but not so simple in Lisp: Easy interaction with the operating
> system. Along with that comes the GUI, the networking facilities and
> ability to easily script the whole works.
Well who prevents you from writing the necessary pieces? If you think
there is a niche why don't you fill it? I really hate this sort of
argumentation. Yeah, if just that and that would be there all would
use it.
Well if *you* think so. Why the hell don't you work for it. Well bills
to pay? Not overly confident that people are really interested? Well
than do not spend your time and work on it.
> IMHO, the availability of
> these simple things would do more to promote Lisp to the next
> generation of hackers (thence "IT Professionals" and "Project
> Manageres") than any more elaborate solutions.
Well provide what you think is lacking. Than you can gain from the to
be expected populatity from Common Lisp. You do not want? Well than
ask someone else to do the job and "pay for it".
Friedrich
> > * In message <sfwn14f...@world.std.com>
> > * On the subject of "Re: What I want from my Common Lisp vendor and the Common Lisp community"
> > * Sent on Fri, 31 Aug 2001 21:26:09 GMT
> > * Honorable Kent M Pitman <pit...@world.std.com> writes:
> >
> > > -ansi ANSI CL compliant: Comply with the ANSI CL specifi
> > > cation even on those issues where ANSI CL is bro
> > > ken. This option is provided for maximum portabil
> > > ity of Lisp programs, and is not useful for actual
> > > everyday work.
> >
> > By the way, if the commetn about "not useful for actual everyday work"
> > is really serious, I'd like to hear an explanation of that.
>
> this (unfortunate and now removed) comment
Hooray!
> the only place where ANSI CL standard is (IMHO) deficient is readable
> pathname printing: #p"" is ambiguous (#p".foo" can be #s(pathname :type
> "foo") and #s(pathname :name ".foo")). the #s(pathname ...) (and
> #s(logical-pathname)!) notation, while used in a couple of CLHS pages,
> has not been standardised. any chance it ever will be?
Oh, it's not just that; I'm afraid there are many other issues (as I'm
sure you know).
I've been thinking about this, and I actually think that the best way
forward is to rip out pathnames entirely and start again[1], with
carefully defined semantics of how strings should be treated; I've
been playing a little with this, and I think that the way I want to
sell it is by replacing pathnames with URIs.
Somewhat along the lines of gray streams, there will then be hooks
into things such as open, compile-uri, and so on, with the behaviour
of those on file uris being the only thing that's initially
specified. Of course, this does have the disadvantage that the name of
the compile-file-pathname analogue is the stunningly ugly
compile-uri-uri.
Those who follow the cCLan/common-lisp-controller discussions will be
pleased to hear that that functionality is trivially replicatable in
this framework. The major change from pathnames that I envisage is
that there is no easy way of specifying a relative pathname; while
#p"foo/bar.lisp" gives you a pathname with directory (:relative
"foo"), #u"foo/bar.lisp" would give you something merged with the
current value of *default-uri-defaults*; I think that this would solve
quite a few problems that are felt with pathnames.
Christophe
[1] Or for now, layering URI support on top and shadowing a few
symbols from CL.
> Sam Steingold <s...@gnu.org> writes:
>
> > > * Honorable Kent M Pitman <pit...@world.std.com> writes:
> > >
> > > > -ansi ANSI CL compliant: Comply with the ANSI CL specifi
> > > > cation even on those issues where ANSI CL is bro
> > > > ken. This option is provided for maximum portabil
> > > > ity of Lisp programs, and is not useful for actual
> > > > everyday work.
> > >
> > > By the way, if the commetn about "not useful for actual everyday work"
> > > is really serious, I'd like to hear an explanation of that.
> >
> > this (unfortunate and now removed) comment
>
> Hooray!
[ I apologize for following up to myself; this isn't relevant to my
post about pathnames ]
And the icing on the cake would be for clisp to start up in ANSI mode
by default. I realize that this would be an incompatible change, and
so might need a large bump in version number, but it would make me a
lot happier.
Please?
Cheers,
Christophe
Riiight!
///
From your other _mature_ behavior, it seems likely that your sole point
is to reduce my credibility out of personal reasons, which I think people
will see when they read your articles, but this is even more disingenuous
than your regular batch of insincerity.
The point I tried to raise, and which people who do not hate me seem to
have been able to grasp quite easily, is that the _reason_ Common Lisp is
not used is that people in the Common Lisp community produce a continuous
stream of negative remarks about the language and the standard and about
its viability. You do that, too, Erann Gat. People do not start to use
something they hear everybody else express doubts, fear, hatred towards.
People who love parts of Common Lisp and not the whole language, will not
use it, either. "I love Common Lisp, _but_ <reams upon reams of reasons
not to use it>" do not really love Common Lisp, it is simply an insincere
way of expressing one's dislike for something. It is just as hollow as
"Oh, I love California, but I would not want to live there". That you do
not understand the hollowness and the insincerity is no surprise, though.
It also seems that you completely missed the point that people who hate
their work cannot be trusted to do quality work. Gee, I wonder why.
///
> [...]
The other day I was walking in the bush and a strange creature
appeared from the underbrush. It was an old and slow-moving wombat,
half blinded with cataracts. To my great surprise and amusement, it
came burrowing out of the bush and STRAIGHT AT ME!
Not sure why your response reminded me of this incident, but I think
I'd better leave it at that...
Patrick <xu...@yahoo.com.au> writes:
> Partly because it's not being taught at universities. And
> partly because it's not seen as one of the two or three best choices
> for young hackers to build their clever toys.
While I can't fix the fact that Lisp is not taught at most
universities, I did fix the fact that it used to not be taught at the
U of Bordeaux. The course is for the 4th year students, and there are
about 120 or so students taking the course every year for the past
few years, although it is only since last year that the course was
entirely based on Common Lisp. Check out:
http://dept-info.labri.u-bordeaux.fr/~strandh/Teaching/MTP/2000-2001/Dir.html
My estimation is that at least 20 of the 120 really understand the
advantages of Lisp, and that perhaps 5 or so become real passionate.
While that may seem insignificant, I don't think it is. Several
companies that have hired these students or that were created by these
students now either use Lisp or consider using it.
We are also mostly the ones in charge of the McCLIM project for
creating a free version of CLIM, which gives students excellent
opportunities to hack Common Lisp and see how it can be used.
--
Robert Strandh
---------------------------------------------------------------------
Greenspun's Tenth Rule of Programming: any sufficiently complicated C
or Fortran program contains an ad hoc informally-specified bug-ridden
slow implementation of half of Common Lisp.
---------------------------------------------------------------------
> years ago and it's not. The absence of Symbolics saddens me a little, but
> putting aside my personal feelings, the loss of it from the arena might help
> to unify the community around the MOP, since I'm not sure what other
> implementations lack MOP support. Maybe Corman seems a garage operation, but
CLISP lacks native support for the MOP, but PCL may be used.
Could you please elaborate on your statement about Symbolics? I don't
understand whether its Common Lisp implementation lacks the MOP.
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://web.mclink.it/amoroso/ency/README
[http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/]
> [...]
> http://dept-info.labri.u-bordeaux.fr/~strandh/Teaching/MTP/2000-2001/Dir.html
> My estimation is that at least 20 of the 120 really understand the
> advantages of Lisp, and that perhaps 5 or so become real passionate.
>
> While that may seem insignificant, I don't think it is.
I don't either. Not at all. If 20/120 see potential in Lisp and 5
become passionate about it, I would regard that as a good result.
Presumably you have taught other languages as well as Lisp. If so,
have you noticed any remarkable differences between the way students
respond to Lisp, compared with other languages? ie. is the ratio of
those who become passionate about Lisp noticeably different from the
ratio of those who become passionate about other languages?
Or, have you noticed a difference in the _type_ of people who respond
well to Lisp, in comparison with other languages?
> Several companies that have hired these students or that were
> created by these students now either use Lisp or consider using it.
That's good news. Teaching _alone_ doesn't guarantee that university
knowledge is brought forward into the workplace. (Few companies use
Eiffel in Australia, though lots of students are made to learn it).
> We are also mostly the ones in charge of the McCLIM project for
> creating a free version of CLIM, which gives students excellent
> opportunities to hack Common Lisp and see how it can be used.
That's great. I believe that encouraging experimental hacking is THE
best way to keep the flame alive. It provides the missing link between
learning a language, and learning to think in a language. (That is why
it distresses me to see Lisp promoted only - or even mainly - as a
power tool for solving the biggest and the hardest problems).
> you Alice, wherever you are.) Corman is a one-man operation. There's
> no street address, no phone number, not even a .com Web address. I've
> not used Corman Lisp, so I can't judge its quality; it may be the
> greatest thing since sliced bread. But if you go to a manager and
www.corman.net , another business owns corman.com
Street address is on http://www.corman.net/license.html
200$ buys you a solid product with excellent support that can build
stand alone win32 executables. I just built a simple gui program, copied
it to a _floppy_ and ran it on another machine that had never been
touched by Lisp before. As for the support issue, it has been excellent.
Source for the compiler and runtime are included, mitigating concerns
about it being a one man operation. We recently got to watch Agillion
sell over a hundred Herman Miller chairs in their dot-bomb auction. The
importance of size and glitz are over-rated, even pointy-haired-bosses
can be made happy with source code and low risk.
On a philosophical note. You are creating the problem, not describing
it. Some people will search google and see your ignorant, denigrating
comments about Digitool and Corman and not buy well supported, good
products.
Joe Nall
> hand and express their feelings? Can you stand up and say "I _love_
> Common Lisp!" in a crowd and feel proud of yourself? Do you want to
Here is my 5000 word essay on why I love Common Lisp. But of course I
don't want to actually write those 5000 words myself, if I can get
Common Lisp to write them for me. And of course I don't want to write
them in English, partly because English is not really the language of
love, and partly because I have not yet learned Common Lisp well
enough to make it write a good essay in English. And of course it's
better to post the program that writes the essay than the raw text of
the essay, especially if it saves bandwidth. So here it is:
(defun oneletter()
(aref "etaoinshrdlucmfpbygwkvzxjq"
(- 25 (ceiling (sqrt (random 625))))))
(defun oneword()
(let ((len (+ (random 5) 1 (ceiling (sqrt (random 5))))))
(coerce (loop as i below len collect (oneletter)) 'string)))
(defun printwords (words)
(loop with hor = 0 as word in words do
(if (zerop hor) (fresh-line) (princ " "))
(princ word)
(incf hor (length word))
(if (> hor 50) (setf hor 0))))
(defun strayano (n)
(printwords (loop as i below n collect (oneword))))
(strayano 5000)
> The point I tried to raise, and which people who do not hate me seem to
> have been able to grasp quite easily, is that the _reason_ Common Lisp is
> not used is that people in the Common Lisp community produce a continuous
> stream of negative remarks about the language and the standard and about
> its viability.
Yes, I understand that. I say you're wrong. Please try to pry your
brain open just wide enough to grasp the possibility that not everyone
who disagrees with you does so because they haven't understood what
you're trying to say.
> You do that, too, Erann Gat.
Oh? How so?
> People do not start to use
> something they hear everybody else express doubts, fear, hatred towards.
Hogwash, as is easily demonstrated: Listen up, everyone! Java sucks
big fat weenies! No go and see if anyone is abandoning Java as a
result of my overwhelming negativism.
> People who love parts of Common Lisp and not the whole language, will not
> use it, either.
Again, hogwash. I used Common Lisp for twenty years pretty much to
the eclusion of all other languages. I loved most of it, hated some
of it, felt neutral about some of it, and some of it I simply never
understood. I used the parts I loved, ignored the parts I hated to
the extent possible (the package system was hard to avoid), and
struggled with the parts I didn't understand. Mostly I revelled in
the fact that I could change the language to suit my tastes and get
ten times as much done than my colleagues.
> "I love Common Lisp, _but_ <reams upon reams of reasons
> not to use it>" do not really love Common Lisp, it is simply an insincere
> way of expressing one's dislike for something. It is just as hollow as
> "Oh, I love California, but I would not want to live there". That you do
> not understand the hollowness and the insincerity is no surprise, though.
Well, I do live in California. I love parts of it, hate other parts,
and parts of it I still don't understand even after thirteen years.
On balance, I don't know any place I'd rather live (not even New York,
which I had a wonderful time visiting, but I don't think I'd want to
live there).
The world is full of hollowness and insincerity. So what? Some of
what you call hollowness and insincerity I call civility, and I think
it's a feature. Some of what you call H&I is simply ambiguity. Love
and hate are two extremes on a continuum, not a binary choice. I'm
sure that some of my fellow Californians love it here more than they
hate it, other hate it more than they love it, and other simply feel
ambiguous about it. But we all mostly get along and manage to make
what is to most of us on balance a pretty nice place to live.
BTW, the hollowest and insincerest people I know are the faith
healers, whose rhetoric sounds a lot like yours, but with "Jesus"
substituted for "Lisp": "There are those who claim to love Jesus, but
who continue to live lives of sin. These people do not truly love the
Lord Jesus."
> It also seems that you completely missed the point that people who hate
> their work cannot be trusted to do quality work.
No, I didn't miss it. I just think it's irrelevant. There's a lot of
crap that gets written in C++ and Java. (There is also, I have
learned somewhat to my asontishment, some exceptionally good software
written in those languages as well.) Having some poor quality
software written in Lisp is a price I think is worth paying to have it
enjoy a similar level of success.
E.
That is _precisely_ the danger of the alarmists, negativists, and other
naysayers! It really irks me when I go search for Common Lisp on the Net
and mostly find negative things said about it, especially by people of
good reputation. When professional people I suggest Common Lisp do this,
they start to wonder. I work with a large Norwegian law firm right now,
and they were flabbergasted that I had used Common Lisp. Not at first,
because against tremendous odds, we made into production in record time
for hardware supplier, ISP, web design, SSL certificates, secure servers,
you name it -- two weeks from first phone call to operational is *fast*.
But then, _excited_ about this unknown Common Lisp that got them there in
time, one of their senior staff looked for Common Lisp on the Net. You
can do this yourself and be sufficiently alarmed, but think carefully
about what it does to a senior lawyer. Suffice to say that the first bug
he found caused a major crisis of trust instead of a simple bug report,
and of course it was a user error to begin with.
///
| Here is my 5000 word essay on why I love Common Lisp.
nice. it crashed on cmucl tho :)
--
Rolf Lindgren http://www.roffe.com/
ro...@tag.uio.no
EN> ... It really irks me when I go
EN> search for Common Lisp on the Net and mostly find negative
EN> things said about it, especially by people of good reputation.
The first page for google web search seemed innocous, as did the deja
both sorted by relevance and date. A search with "common lisp problem"
seems to be equally harmless.
EN> When professional people I suggest Common Lisp do this, they
EN> start to wonder. I work with a large Norwegian law firm right
EN> now, and they were flabbergasted that I had used Common Lisp.
I can imagine. Though it is unclear why lawyers of all people would
assume that they'd know enough to have an informed opinion on something
outside their domain.
EN> [...] But
EN> then, _excited_ about this unknown Common Lisp that got them
EN> there in time,
This is their first mistake, they should have been excited about Naggum
Inc. not Common Lisp.
EN> one of their senior staff looked for Common
EN> Lisp on the Net.
This is their second mistake, informing yourself through searching the
web has a chance of working only if you have the "right" background.
EN> You can do this yourself and be sufficiently
EN> alarmed, but think carefully about what it does to a senior
EN> lawyer. [...]
Could you get us the search results, so we can see?
cheers,
BM
> [Software Scavenger]
>
> | Here is my 5000 word essay on why I love Common Lisp.
>
> nice. it crashed on cmucl tho :)
real nice, but CLISP displayed a nice and hefty chunk of text ;-))
cor
--
An operatingsystem is just a name you give to the rest of bloating
idiosyncratic machine-based-features you left out of your editor
Alzik kon spelluh dee ik ut de eerste keer wel goedt
OK, I was just trying to save some space.
Xanalys is the resurrection a bankrupt Harlequin, which was acquired
not for its Lisp technolgy, but for its electronic publishing
technology. The Lisp product just sort of came along for the ride,
and many of the key Lisp people (you included) aren't working there
any more. That would give me pause in betting on Xanalys as a stable
long-term provider even *before* reading what Franz has to say about
them.
> > So maybe there isn't only one Lisp vendor, maybe there are 1.84, maybe
> > even 2. Whatever the number is, it's perilously close to zero, and
> > that's the real issue. And we won't solve that problem by quibbling
> > over exacly how many Lisp vendors there are or aren't, or whether Loop
> > is the greatest thing since sliced bread or should be avoided like the
> > plague, or by hurling epithets like "pestulent corpses" around.
>
> I doubt we'll solve any problem by worrying how many vendors there
> are, even if that number is approaching zero. I bet there are several
> times in Lisp's past when there have been no commercial vendors. Yet
> that didn't kill Lisp. Vendor count doesn't matter; adequate supply
> does. And there ARE ample Lisps to program in.
Businesses care about more than just adequate supply now. They care
about adequate supply in the *future*. They care about being able to
get support. They care about being able to count on their suppliers
being stable and not going bankrupt. They care about not being locked
in to sole-source providers. What they emphatically do not care about
is whether or not the product is loved by its users.
> Counting vendors and pointing to the zero mark seems alarmist. (Btw,
> I use the term "vendor" often, and I mean to include those who make
> free versions as vendors. I think the making of money is irrelevant
> except to the maker; the sustaining of support is relevant, and presumably
> those who make free implementations are feeding themselves somehow.)
It may be. Perhaps my experience is different from everyone else's.
In my career using Lisp has been a constant managerial struggle
because the people I've worked for see significant risk in its use.
And you know what? They're not completely wrong. So I've had to
argue that the benefits outweight the risks, but that's a very hard
case to make because in the end it's a subjective judgement.
Sometimes I've succeeded, sometimes not. But I'm just sick and tired
of having to make the argument all the time. I'm sick of being a
pariah. I want three or four Lisp vendors out there making piles of
money so that I can simply dispense with the risk argument and get
some work done for a change.
> I'm frankly surprised Franz would point to there being only one
> vendor--it must panic those who like second-sourcing availability.
> I thought lack of "backup" was one of the common reasons for freaking
> out about use of Lisp. And making it seem like there's no other source
> also seems to provoke such concern unnecessarily, since in spite of
> the lack of vendors-for-fee, it's pretty easy to second-source a Lisp.
Yes. Exactly. So why would they say it if it weren't true?
> IMO, a fair analysis would say that uniformly, people seem not to make
> money, probably because it's hard to price a Lisp in a way that
> recovers development prices, because other commercially available
> programming languages are mostly low-margin products and low margin
> products only work in high volume, which Lisp does not have...
No, I don't believe this is true. You could charge ten times what
Franz charges for Lisp and still make money *if* you could show that
the net savings in programmer costs is more than the cost of the Lisp.
The absolute cost is irrelevant. All that matters is the
cost-benefit ratio. Actually, that's not true. What matters it the
*customer's perception* of the cost+risk/benefit ratio.
[snip]
> It seems to me that although each of these four categories yields different
> levels of profit, all are pretty much in steady state for the last couple
> of years. Sure, Digitool is on the edge, but I thought it would be dead
> years ago and it's not.
Yes. Astonishing, isn't it? If you were a manager, would you bet the
success of your product (and your career) on the continued existence
of Digitool?
> Maybe Corman seems a garage operation, but
> that just means "low overhead" and "robust against a fluctuating economy" to
> me, so I don't fear that.
It also means it could vanish in an instant if Roger Corman gets hit
by a bus, God forbid, or simply decides he wants to do something else
with his life.
> It would be nice to see one of them rocket up, but perhaps it's first up to
> us as customers to build some success stories. We do have working tools
> that should be up to that.
Precisely! I don't care if you love Lisp or hate it. I don't care if
you badmouth the loop macro (I happen to love loop myself) or diss the
standard. What I care about is that you *do* something with Lisp that
I can point to as a success story so I can stop the endless bickering
with my managers and get some work done for a change!
E.
> g...@flownet.com (Erann Gat) writes:
>
> > [...] Lisp's problem is that people love it too much, but don't use
> > it nearly enough.
>
>
> From where I stand, the latter half is painfully and obviously
> true.
I disagree. People who love CL will use it.
I use it at work for all sort of sysadminny things that some other
people would use Perl for.
> I think it is absolutely essential that Lisp be promoted as an
> excellent language for solving simple tasks as well as the very
> difficult ones. Otherwise it will not get a foot in the door.
But CL is already fine for simple problems. I do a lot of simple
things for people in the listener. It's a nice problem
exploration/data exploration tool. You get someone to export their
data in something vaguely lisp friendly, read it in and you can start
working with their stuff in ways Excel etc. don't allow.
--
Lieven Marchand <m...@wyrd.be>
She says, "Honey, you're a Bastard of great proportion."
He says, "Darling, I plead guilty to that sin."
Cowboy Junkies -- A few simple words
Correction: I have insulted no one.
Thanks for supplying me with more data on your need to keep posting
more and more of your usual drivel, and thank you especially for not
going to any length at all to falsify my conclucions about your needs.
#:E.
I want three or four Lisp vendors out there making piles of
> money so that I can simply dispense with the risk argument and get
> some work done for a change.
[...]
> Yes. Astonishing, isn't it? If you were a manager, would you bet the
> success of your product (and your career) on the continued existence
> of Digitool?
If you are genuinely worried about the long term viability of a
software supplier, what is keeping you from entering into a source
code escrow agreement for the products your business depends on?
Yes, they see risk in your using CL, you see risk in using any vendor's
product (except maybe ACL). Everyone is depending on everyone else to
accomplish anything. Since you are pariah, if you use Lisp, and you leave
(or die), who will continue on in your manager's eye? Maybe the solution is
for you to get a development group around you who all use CL and provide the
necessary security that your management needs for continutity. Or maybe
make CL _part_ of the groups efforts.
Maybe they consider you a risk. This insecurity may be compounded by you
expressing disatisfaction with using other tools or languages. Though they
have observed your competence and your commitment they might construe that
you will leave when you find a better place where you will be happier. You
have strong feelings towards what you do and are attached to a certain way.
One of the secrets of life is that everyone else knows what other people
really think, there really is no way to hide how you really feel.
Perhaps you should consider strengthing your manager's trust in you
personally. Someone has to be strong and provide the base of security that
everyone needs (including managers). If I was a manager I would not put my
blind trust in strangers, but I would put my trust into those I know, those
I can count on and those who are committed. Maybe you could put CL to one
side for a while and make this a personal journey.
Wade
Let us look at the "substance" in this claim. There is my argument that
there is a love-hate axis on which Common Lisp is not sufficiently loved,
and by that it is clearly _understood_ that it is not sufficiently used.
In fact, the whole point with the love-hate axis was to explain the lack
of use. But this axis is ridiculous, according to master mind Erann Gat.
Instead, there is the love-use axis, where the more languages are loved,
the less they are used and vice versa, take loathsome language C++ and
loathsome language Java as additional examples to support the loved, but
not used Common Lisp. In fact, if people express their love for Common
Lisp, they would poison something (langauge, themselves, both?) and die
or at least not use it. In order to increase the usage of a language, it
is precisely the people who defame the language, denigrate the standard
and the process that created it, and generally speak ill of any and all
features in the language, that truly help. The less people love Common
Lisp, the more they will use it, according to master mind Erann Gat,
because to him, loathsome language C++ and loathsome language Java set
the standard by which Common Lisp should measure its success. In order
to be used, you must not be loved. That sounds to me like a recipe for a
really, really bad relationship, but despite everything I know about C++
and Java, even its users do not think that way. After all, it is not
master mind Erann Gat's lack of love for C++ or Java that drives anybody
else to use it. Or maybe those _are_ the languages they choose when they
have been driven away by false alarms about Common Lisp companies being
out of business and other random and assorted evil perpetrated against
Common Lisp and its user community by master mind Erann Gat.
Of f*ing _course_ C++ and Java thrive because people love them, you twit!
(Politeness master Erann Gat has approved "you twit" as non-insulting.)
It requires an evil mind of biblical proprotions to believe that those
who sat down to create C++ and Java failed to understand that they had to
draw on the _excitement_ of its user community, and instead thought they
could start off with people _using_ their stuff. Bjarne Stroustrup's own
accounts of how this started and got rolling is a virtual roller coaster
of excitement and user satisfaction. How do people start using something?
How do people continue to use something? Even if somebody orders them
them around, they have to be _ordered_ by someone. Unless you are master
mind Erann Gat, I must presume, you do not choose things you hate. You
do not even choose things towards which you are indifferent. You choose
things according to a value scale, and preferably the topmost value if
you can get it -- and if not, something else has higher value that makes
the topmost thing lose value, such as being an out-of-budget experience.
What I am doing here is revoking people's "license to hate Common Lisp",
or at least trying to. John Foderaro set up this whole stupid election
thing and wanted to see the community split into those who supported him
and those who supprted me. I do not want _personal_ support, however. I
want people to support Common Lisp and cease and desist in negative and
destructive marketing practices. Like Erann Gat thinks it is important
to warn the world against me because _he_ picked a fantastically stupid
fight and lost, some of the people who have a deep desire to warn the
world against Common Lisp have staged fights or even wars and lost, and
cannot get over it. Such people have no business trying to destroy any
other person's appreciation for what they dislike, but that is what such
vengeful, negative people do. This community is not big enough to be
able to drown such individuals in an ocean of enthusiasm and positive
feedback, and thus they make things worse out of proportion.
The love-use axis is _obviously_ wrong. It has absolutely no predictive
power and just assumes that "use begets use" at best, "use begets hatred"
at worst. People who think this is smart or even good should have their
head examined by a professional.
///
Have you considered trying a different approach and see if you get
different results? If not, you confirm only that your own behavior
causes such responses as you get. Thank you for confirming that you do
not understand this. It has unfortunately been evident for a long time.
///
> [Software Scavenger]
>
> | Here is my 5000 word essay on why I love Common Lisp.
>
> nice. it crashed on cmucl tho :)
I can't reproduce any crash on CMU CL, neither interpreted, nor
compiled, whether at the prompt or loaded from file. I also think
that the source code posted is conforming, and shouldn't cause any
problems in a conforming implementation. Could you give a more
elaborate bug report?
Regs, Pierre.
--
Pierre R. Mai <pm...@acm.org> http://www.pmsf.de/pmai/
The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We cause accidents. -- Nathaniel Borenstein
> Robert STRANDH <str...@labri.u-bordeaux.fr> writes:
>
> Presumably you have taught other languages as well as Lisp. If so,
> have you noticed any remarkable differences between the way students
> respond to Lisp, compared with other languages? ie. is the ratio of
> those who become passionate about Lisp noticeably different from the
> ratio of those who become passionate about other languages?
Hard to say. But I do know that when I switched from Scheme to Common
Lisp, things worked much better. The students are very sensitive to
credibility. Scheme is just not credible in the eyes of the
students. I got into eternal discussions about speed of
implementations, the necessity of adding your own object system, lack
of required numeric types, etc. When I listened to my own arguments,
they did not sound convincing.
I have also taught C quite a lot, but it is hard to compare the two.
> Or, have you noticed a difference in the _type_ of people who respond
> well to Lisp, in comparison with other languages?
Yes, I think so. The ones that "get" Lisp, and especially the ones
that become passionate, are the very best students. People who become
passionate about C or C++ are more the ones that have a need to be
members of a club at the exclusions of others, with no real technical
reason why.
This is all based on informal observation. And it is average behavior,
of course.
--
Robert Strandh
---------------------------------------------------------------------
Greenspun's Tenth Rule of Programming: any sufficiently complicated C
or Fortran program contains an ad hoc informally-specified bug-ridden
slow implementation of half of Common Lisp.
---------------------------------------------------------------------
I find it rather curious that you think this approach will work.
> Hogwash, as is easily demonstrated: Listen up, everyone! Java sucks
> big fat weenies! No go and see if anyone is abandoning Java as a
> result of my overwhelming negativism.
This is particularly mature to be you, but still does nothing to falsify
my conclusions about your general immaturity and lack of intelligence.
Are you a strong and vocal member of the Java community, Erann Gat? Do
you post this immature filth in Java newsgroups? If you are not, what
was that again about "pry open your brain"? Do you think anyone will
_listen_ to such immature crap? Any random idiot can flame at that level
without consequence. It is substantial criticism based on a different
agenda than that which was underlying the design of the language that is
the problem. Some people hate Common Lisp for not being Scheme, but they
cloak their "criticism" in such a way as to make people believe that
Common Lisp is inherently flawed. One needs to be unusually intelligent
to be able to figure out what these nutballs really have a problem with.
If Guy Steele or James Gosling or Bill Joy went on record to say they
think "Java sucks big fat weenies" (or preferably something intelligent)
to the Java community, do you think that would make it slightly more
interesting than that a fairly immature little runt like you does it
here? If you do not understand this point, you really _have_ not
understood anything.
> Again, hogwash. I used Common Lisp for twenty years pretty much to
> the eclusion of all other languages. I loved most of it, hated some
> of it, felt neutral about some of it, and some of it I simply never
> understood. I used the parts I loved, ignored the parts I hated to
> the extent possible (the package system was hard to avoid), and
> struggled with the parts I didn't understand.
And you still do not understand that the fact that you ignore the parts
you hate is just what makes you a little different from the people who
post long and painfully disturbed messages about what they hate about the
language, and keep arguing against the language and the standard and the
standardization process because they were once "spurned" by it?
> The world is full of hollowness and insincerity. So what?
Just the kind of commentary I expect from you.
> Some of what you call hollowness and insincerity I call civility, and I
> think it's a feature.
I have long suspected that that would be the operating definition of your
civility, but thank you for making it clear to us all.
> Love and hate are two extremes on a continuum, not a binary choice.
Really? Thank you for sharing such a profoundly important insight!
> BTW, the hollowest and insincerest people I know are the faith healers,
> whose rhetoric sounds a lot like yours, but with "Jesus" substituted for
> "Lisp": "There are those who claim to love Jesus, but who continue to
> live lives of sin. These people do not truly love the Lord Jesus."
Again, this is a very powerful reflection your life and life experiences.
I am so glad I have nothing of your life experiences to drag me down. It
would be awful.
Pull yourself together and engage your brain, Erann Gat. The stupidity
you posted so far only indicates that you are going nuts very quickly.
///
But why would anyone do that if you keep posting your hatred for Lisp and
denigrate the language, its suppliers, its users, those who do love the
language, and almost everything else related to Common Lisp?
I actually believe you may be just so dense that you do not understand
the connection, probably because of your dismal life experiences and your
interaction with your managers in particular. There sure seems to be
same core problem with you as with other negativists: They fail to get
over their negative experiences, but keep them in the forefront of their
mind. You sure have a hangup bordering on a mental illness when it comes
to your reactions to anything I say. _Normal_ people get over things.
Nutcases do not. It is one of the important point of distinction.
///
Why, that would clearly make it impossible to continue to rant and rave
about all the problems of using Common Lisp.
He is not genuinely worried at all. Like so many others who feel they
have been mistreated and betrayed, they really, really want to destroy
what they think mistreated and betrayed them. Normal people get over
such experiences and just move on to what they _really_ want. Those who
had what they really wanted thwarted by mistreatment or betrayal seem to
have a problem finding something else to really want. This is a personal
tragedy and should not have any bearing on programming languages or their
communities, but for Common Lisp, such things do seem to affect us.
///
This is extraordinarily interesting! I expect serious professionals to
see through the Scheme propaganda, but if students do it, it is great!
There is perhaps enough material for a conformance paper on this, and if
so, I would love to hear you speak about it.
> The ones that "get" Lisp, and especially the ones that become passionate,
> are the very best students. People who become passionate about C or C++
> are more the ones that have a need to be members of a club at the
> exclusions of others, with no real technical reason why.
This matches my own experience to a t. I thought I was alone, however.
> This is all based on informal observation. And it is average behavior,
> of course.
Sometimes, that is all we have, but it is nonetheless interesting to hear.
///
> www.corman.net , another business owns corman.com Street address is
> on http://www.corman.net/license.html 200$ buys you a solid product
> with excellent support that can build stand alone win32
> executables. I just built a simple gui program, copied it to a
> _floppy_ and ran it on another machine that had never been touched
> by Lisp before. As for the support issue, it has been excellent.
> Source for the compiler and runtime are included, mitigating
> concerns about it being a one man operation. We recently got to
> watch Agillion sell over a hundred Herman Miller chairs in their
> dot-bomb auction. The importance of size and glitz are over-rated,
> even pointy-haired-bosses can be made happy with source code and low
> risk.
> On a philosophical note. You are creating the problem, not
> describing it. Some people will search google and see your ignorant,
> denigrating comments about Digitool and Corman and not buy well
> supported, good products.
The simple fact that there are multiple vendors spreads the risks more
ways, and diminishes the costs of coping with the risks.
Even taking the most negative view, of Corman being a one man shop,
the fact that it's selling a standardized language, with multiple
implementations available, means that code can be taken elsewhere if
Corman's support flags.
It doesn't mean that such a process would be cheap or trivially easy,
just that if your code is built to be not _too_ heavily dependant on
Corman-specific features, a port should be doable. (Substitute
"Digitool" or "Franz" or "Xanalys" as needed...)
Contrast this with, let's say:
- Coding in ML, and depending on Harlequin's support, which _did_
flag, with no answer available;
- Depending on Apple's support for Dylan;
- Depending on the developers of Clean to forever make support
available;
- Coding an application that you hope to use in 2010 using this
year's version of Visual BASIC, when it's more than likely that
it won't be deployable anymore by 2005...
Coding in C or C++ involves cutting risks in similar ways, since there
are multiple makers of C/C++ compilers...
--
(reverse (concatenate 'string "moc.enworbbc@" "enworbbc"))
http://www.cbbrowne.com/info/finances.html
An engineer is someone who does list processing in FORTRAN.
And, if I may:
- Coding in a version of Common Lisp that deviates from the standard for
political reasons and whose deviations vary according to which
developer team was last responsible for maintaining the sources.
However, more important to me than code portability is knowledge
portability. You can always figure out how to survive a version change
if you have the right people already. It is harder to find people who
are willing to dispense with their years of training and experience with
a conforming implementation and have them come and look at some weird
shit that uses weird macros and overly verbose iteration constructs just
because someone, somewhere has irrational feelings about the standard.
///
> Xanalys is the resurrection a bankrupt Harlequin, which was acquired
> not for its Lisp technolgy, but for its electronic publishing
> technology.
Not quite right, actually.
Xanalys does NOT due the electronic publishing thing. Harlequin still
exists and does. Xanalys is the spin-off that does SPECIFICALLY the
Lisp-based and layered Information technologies. See their web site.
The original purchase by Global Graphics may have been as you say, but
Xanalys is itself a financially distinct concern with its own concern
that directly and indirectly addresses the Lisp products.
> The Lisp product just sort of came along for the ride,
> and many of the key Lisp people (you included) aren't working there
> any more.
The people you know. Their real key people have never had their names
bandied about and several are still there.
I myself used Lisp a lot but was never directly a Lisp maintainer.
The loss of me had no effect on the Lisp product per se.
I prefer to be a user / critic rather than a producer. I was working on
the standard itself for a long time, and then on WebMaker (a FrameMaker to
HTML translation tool) while I was there.
> That would give me pause in betting on Xanalys as a stable
> long-term provider even *before* reading what Franz has to say about
> them.
Hopefully what I said will give you reason to reconsider both your posture
and the importance of letting a company speak for itself. I'm not a Xanalys
employee and probably even my point of view is not quite right, but I think
it's closer than what you said.
On what basis should I revise my perception? comp.lang.lisp.mcl has
virtually no traffic. Their street address has been replaced with a
PO Box. The "people" page on their site has disappeared. They
haven't advertised a job opening in years. These are not the signs of
a vigorous, healthy company.
> > Alice must be putting in a truly heroic effort. (Good for you Alice,
> > wherever you are.)
>
> Declaring [falsely] that Digitool is out of business won't help her a
> bit.
Of course. That's why I made no such declaration. But declaring that
Digitool is thriving when it clearly isn't won't help anyone either.
E.
Maybe the problem is that perception creates reality? Just the way your
perception of me creates the reality you respond to me in out of thin
air, maybe it _would_ help if you just shut up about all the negative
stuff that seems to be dripping out of your mouth half involuntarily?
My point in this thread has been that the impression people like you
_love_ to create about Common Lisp is part of the reason it is having a
hard time, and consequently, why you have a hard time with your manager.
Just like another poster here, I think this is more personal than
anything else -- you create your own reality as far as perceptions go,
and the reality you create is one where Common Lisp has serious problems.
That is not necessarily true. If you tried to look at it differently,
just as you could look at me differently, you would find something else.
But somehow, I suspect that that is not in your personality, and we will
just have to live with a insane rants about me and Common Lisp from you.
Please consider it a service to the community and to yourself to just
shut up, Erann Gat.
///
> The simple fact that there are multiple vendors spreads the risks more
> ways, and diminishes the costs of coping with the risks.
That's true, but having the source code yourself spreads the risks even
more.
> Even taking the most negative view, of Corman being a one man shop,
> the fact that it's selling a standardized language, with multiple
> implementations available, means that code can be taken elsewhere if
> Corman's support flags.
True.
> It doesn't mean that such a process would be cheap or trivially easy,
> just that if your code is built to be not _too_ heavily dependant on
> Corman-specific features, a port should be doable. (Substitute
> "Digitool" or "Franz" or "Xanalys" as needed...)
>
> Contrast this with, let's say:
>
> - Coding in ML, and depending on Harlequin's support, which _did_
> flag, with no answer available;
There are multiple ML implementations. OCaml is probably the best
implemented (yes, I know it's not identical to ML), and is well
supported and you get the source code. So you can fix problems yourself
even if there is no support.
> - Depending on Apple's support for Dylan;
Fortunately there are two other implementations. Harlequin's, which has
much the same problem as Harlequin's other stuff, but is at least in the
hands of people who care about it. It appears to be kind of moribund at
the moment, but I doubt that they'll allow it to die completely. And
then there's the free "Gwydion" Dylan, from the same stable as CMUCL.
It's less mature, but improving steadily and you can fix problems
yourself even if there is no support. Right now it is entirely suitable
for doing command-line/batch/CGI work and it will have good GUI support
shortly (once Harlequin's DUIM is fully ported).
> - Depending on the developers of Clean to forever make support
> available;
They're in the process of going open source, so you can fix problems
yourself.
> - Coding an application that you hope to use in 2010 using this
> year's version of Visual BASIC, when it's more than likely that
> it won't be deployable anymore by 2005...
You're correct about this one.
> Coding in C or C++ involves cutting risks in similar ways, since there
> are multiple makers of C/C++ compilers...
Fewer and fewer as time goes on. It's nearly compulsory to use VC++ on
Windows, CodeWarrior on the Mac, and gcc elsewhere.
-- Bruce
> ke...@ma.ccom (Takehiko Abe) wrote in message news:<keke-01090...@solg4.keke.org>...
> > In article <1f4c5c5c.01083...@posting.google.com>,
> > Erann Gat wrote:
> >
> > > Digitool's Lisp (which BTW and IMO is the greatest single software
> > > product ever) runs only on a niche platform that is itself rapidly
> > > losing market share. The company, as far as I can tell, is hanging on
> > > by its fingernails. They don't even have a street address any more,
> > > just a PO box. I am frankly astonished that version 4.3.1 actually
> > > happened.
> >
> > I am not at all surprised by the arrival of 4.3.1. If it is astonishment
> > for you, I think you haven't followed MCL/Digitool recently and should
> > revise your perception on the current shape of Digitool. They're working
> > on the MCL port for OSX right now.
>
> On what basis should I revise my perception? comp.lang.lisp.mcl has
> virtually no traffic.
Because MCL users are using a mailing list. Don't you know that?
> Their street address has been replaced with a
> PO Box. The "people" page on their site has disappeared. They
> haven't advertised a job opening in years. These are not the signs of
> a vigorous, healthy company.
>
> > > Alice must be putting in a truly heroic effort. (Good for you Alice,
> > > wherever you are.)
> >
> > Declaring [falsely] that Digitool is out of business won't help her a
> > bit.
>
> Of course. That's why I made no such declaration. But declaring that
> Digitool is thriving when it clearly isn't won't help anyone either.
>
> E.
Erann, Digitool was never a very active company. But especially in
the last few months there was a lot of positive action:
- OpenMCL has been published. With Gary Byers (one of the original
MCL developers) hacking OpenMCL!
- MCL 4.3.1 appeared. MCL 4.3.1 can run as a classic application under MacOS X.
- MCL 4.4 is in the works. MCL 4.4 will be a "carbonized" version of MCL.
This is actually very cool. I like it. Quite a few MCL users
are waiting for it to be published.
Compared to the fear I had that MCL will never make it to the PowerPC
when Apple years ago no longer was interested in MCL, I'm now very
confident that we will see future versions of MCL and that MCL will
make the transition to MacOS X. So, I actually have less fears for MCL
than in recent years.
When it comes to the PO box address, I can tell you that I talked
to real people (http://www.digitool.com/staff.html)
the last time I saw some of them - hi Steve! They are very
friendly Lisp hackers and I admire their technical skills a lot.
Be nice to them, they deserve it.
Hey, for students the entry license of Macintosh Common Lisp is just $85!
For non-Mac users, Xanalys will show the upcoming LispWorks 4.2 at
LinuxWorld in Frankfurt/Germany.
Xanalys Ltd, Hall 6.0, booth E24 http://www.linuxworldexpo.de/
Rainer Joswig
Thanks for posting this. However, I have a small gripe: This stuff was
published only because someone said something stupid and negative about
the company. It is very nice to see such rotten behavior countered with
real and positive information and good news, but maybe it should have
been better known to begin with?
///
> this framework. The major change from pathnames that I envisage is
> that there is no easy way of specifying a relative pathname; while
I think you mean "will be no easy way of specifying a relative URI"
> #p"foo/bar.lisp" gives you a pathname with directory (:relative
> "foo"), #u"foo/bar.lisp" would give you something merged with the
> current value of *default-uri-defaults*; I think that this would solve
> quite a few problems that are felt with pathnames.
Addendum for anyone who wasn't following the debate the last time we
did relative pathnames on comp.lang.lisp: the reason #p"foo/bar.lisp"
is surprising (at least, it surprised me) is that it defaults the :host
component from the :host component of *default-pathname-defaults*.
So, you can specify relative pathnames with ease, but they're never
_entirely_ relative ...
-dan
--
http://ww.telent.net/cliki/ - Link farm for free CL-on-Unix resources
This is a classic problem; it is entirely common for the "good news"
not to get publicized until it _needs_ to be because someone claimed
otherwise.
--
(concatenate 'string "cbbrowne" "@ntlug.org")
http://www.ntlug.org/~cbbrowne/languages.html
All ITS machines now have hardware for a new machine instruction --
STMLMD Skip To My Lou, My Darlin'.
Please update your programs.
Well, I actually did let Xanalys speak for itself. I went to their
Web site and clicked on "products". Four products came up. Lisp was
the fourth one. I clicked on it and nothing happened. This left me
with the impression that Franz was telling the truth and Xanalys
really was letting Lisp languish. It turns out that the page is
Javascript-dependent, and I had JS switched off. (Attention Xanalys
folks: you really need a <noscript> tag on that page.)
So I stand happily corrected: there are apparently two real Lisp
vendors out there.
I stand by my broader point though. I disagree with Erik's claim that
what Lisp needs is for people to express their unconditional love for
it. I say what Lisp needs is for people to use it to build cool stuff
and beat the pants off their competition. Whether they are motivated
by love or something else is immaterial. I'll take a Paul Graham over
an Erik Naggum any day. Whatever damage Paul does to Common Lisp by
saying it sucks is more than offset by his publicizing the fact that
he got rich using it. If we had ten Paul Grahams we wouldn't even be
having this discussion. Lisp would be thriving. If we had ten Erik
Naggums... nah, too scary to contemplate. (But if we had two Erik
Naggums, now that would be interesting ;-)
E.
Sigh. The point with the love-your-language part was that people do not
use the language for anything at all when they are mostly depressed about
its lack of use and prominent people in the community beat it up all the
time for personal reasons. You have yet to explain how people start to
use something they do not use. I do not think you understand how people
_decide_ to use something. My offer of an explanation is that people who
love their language and get an up-beat, optimistic attitude about it,
also use it. Obviously, this does not apply to you, who continue to
prefer to be depressive and down-beat and just whine that people should
use it. Do you have any clue at all what could _propel_ people to use
Common Lisp to build cool stuff and beat the pants off their competition?
It does not look like you do, since you keep repeating that incredibly
obvious and vacuous line only because you want to beat me over the head
for personal reasons.
> Whether they are motivated by love or something else is immaterial.
> I'll take a Paul Graham over an Erik Naggum any day.
I can beat that. I would take John Foderaro over Erann Gat any day. :)
> Whatever damage Paul does to Common Lisp by saying it sucks is more than
> offset by his publicizing the fact that he got rich using it.
Really? That is the part that I highly doubt. It is precisely that Paul
Graham debunks Common Lisp _after_ he succeeded with it that is so
depressing to other Common Lisp users. It makes it an _accident_ that he
got rich using Common Lisp. He would have gotten rich using just about
anything else, or so it seems.
> If we had ten Paul Grahams we wouldn't even be having this discussion.
> Lisp would be thriving. If we had ten Erik Naggums... nah, too scary to
> contemplate. (But if we had two Erik Naggums, now that would be
> interesting ;-)
You are such an idiot, Erann Gat. This is all so _personal_ to you. Get
some professional help to _get over_ your personal problems. USENET is
not a good place to engage in therapy sessions the way you keep doing. I
mean that seriously. Bring print-outs of your articles to a shrink and
he will tell you that you have a problem you _can_ get help to get out of.
///
> [...] It makes it an _accident_ that he got rich using Common
> Lisp. He would have gotten rich using just about anything else,
> or so it seems.
I don't know much about Paul Graham but, at a glance, that does not
seem to be a fair assessment of his position. In "Beating the
Averages" he attributes a lot of his success to the help Lisp gave
him.
http://www.paulgraham.com/lib/paulgraham/sec.txt
Has he written an anti-CL article subsequent to this?
> What a poor answer. Yes it's obviously better for you to pick out you
> handerchief and cry a bit more.
I've never thought much of bullfighting as a sport. I like bulls too
much. I like their earnest stupidity. I like their thick-headed
bravery. I like their artlessness.
I also like the way you blunder blindly around this arena from time to
time, charging at any red rag you can find. I know your triggers,
Frido. The words "free software" and "popularity" are enough to set
you running full tilt, and almost always at the wrong target. But to
be perfectly honest with you, I don't feel anywhere near enough malice
to want it any other way. Just keep doing what you do best, and best
of luck to you.
(BTW, if you've got a spare handkerchief I can cry into, toro, I'd be
much obliged. Red's my favourite colour).
Lisp yes, Common Lisp no.
> http://www.paulgraham.com/lib/paulgraham/sec.txt
>
> Has he written an anti-CL article subsequent to this?
Yes.
///
Any pointers, anyone?
Deepak <URL:http://www.glue.umd.edu/~deego>
--
You know you've spent too much time on the emacs when you spill
milk and the first thing you think is "C-_"
I do. I subscribe to that list. I also know that the digitool site
says:
Usenet News related to MCL
news: comp.lang.lisp.mcl
The MCL newsgroup is relayed bidirectionally to the Info-MCL mailing
list.
So it would not be unreasonable to suppose that the newsgroup would
contain any messges sent to the list.
> Erann, Digitool was never a very active company. But especially in
> the last few months there was a lot of positive action:
>
> - OpenMCL has been published. With Gary Byers (one of the original
> MCL developers) hacking OpenMCL!
>
> - MCL 4.3.1 appeared. MCL 4.3.1 can run as a classic application under MacOS X.
>
> - MCL 4.4 is in the works. MCL 4.4 will be a "carbonized" version of MCL.
> This is actually very cool. I like it. Quite a few MCL users
> are waiting for it to be published.
Gary Byers no longer works for Digitool. "In the works," is a
euphamism for vaporware. The appearance of 4.3.1 is a positive sign,
the only real positive sign among many negative ones. That's why it
surprised me.
E.
> universities, I did fix the fact that it used to not be taught at the
> U of Bordeaux. The course is for the 4th year students, and there are
[...]
> http://dept-info.labri.u-bordeaux.fr/~strandh/Teaching/MTP/2000-2001/Dir.html
>
> My estimation is that at least 20 of the 120 really understand the
> advantages of Lisp, and that perhaps 5 or so become real passionate.
[...]
> We are also mostly the ones in charge of the McCLIM project for
> creating a free version of CLIM, which gives students excellent
> opportunities to hack Common Lisp and see how it can be used.
The work on Free CLIM/McCLIM is an important "side effect" of Robert's Lisp
course. He and his students are doing a good job, and it's really nice to
see a steady flow of commit logs :)
Another project by some of Robert's students is the Eclipse/CLWM window
manager:
http://www.emi.u-bordeaux.fr/~boninfan/TER
http://www.emi.u-bordeaux.fr/~hatchond/Eclipse
I profit by the occasion for thanking all of you.
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://web.mclink.it/amoroso/ency/README
[http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/]
`I think that Lisp is an outdated, obscure language only used by
nostalgic academics'
can be adequately refuted in this forum by simply saying,
`What commentary credits do you have? None, I think.'
One can obtain commentary credits by doing something that has
benefitted the Lisp community. For example, I think I've earned
commentary credits by 1) Presenting a paper on a system using Lisp at
the 1999 LUGM; 2) Helping keep Garnet alive, and 3) Fixing a subtle
bug in CLX. If I wanted to, then, I might be entitled to make a
negative comment about Lisp, such as, for example, ``it was foolish to
put the loop macro in the standard,'' though I doubt I'd want to say
such a thing at my present level of expertise.
Commentary credits must be claimed but must also in some sense be
`approved' by the community. For example, if I used my fixing the bug
in CLX as a commentary credit in a piece that claimed to find major
drawbacks with CLOS and the MOP, members of the Lisp community might
rightly reply that my commentary credit was disallowed.
Commentary credits are only semi-permanent. They can be
garbage-collected, and thus disappear, if they seem to have become
irrelevant. If one is overused, it can be declared `overloaded' and
disallowed on the basis of invalid polymorphism (somewhat like the CLX
example above).
A valid commentary credit empowers one to express an opinion on Common
Lisp without having one's right to do so challenged. At that point,
only discussions of the actual technical merit of the opinion would be
acceptable. A critique of the right to offer the opinion, such as
`Only a cretinous moron would think that'
could be adequately refuted by saying
`I believe I provided a commentary credit for my opinion.'
This proposal would have many advantages.
1) It would filter out the trash. Anyone who hasn't done anything in
Lisp would be semi-automatically ignored with minimum fuss.
2) Anyone can play. You just have to do something to benefit the Lisp
community.
3) It would minimize the wear-and-tear on the heavy artillery
(i.e. Erik Naggum). He could be saved for the egregious
offenders.
4) It might tend to distract people from arguing about
non-Lisp-related things to arguing about the technical merit of
some commentary credit.
5) It would remind people, especially newcomers, about things that
have been done in Lisp.
6) It would remind the commentators themselves of what they have
accomplished in Lisp, perhaps causing them to be more reflective in
their comments.
There would be a `grandfather' clause for people who have provided
major contributions. Anyone who had a book about Lisp published, for
example, would be considered grandfathered forever. Thus if Paul
Graham were to post his comments about not liking Common Lisp in this
forum, he would be automatically deferred to --- that it, all debate
on his comments would be confined to their technical merits, not to
his right to hold the opinions he holds.
People like Kent Pitman, who has a basically unbounded supply of
commentary credits, would also be grandfathered in.
In the present case, Erin Gatt has commentary credits. He has done
several things that have benefitted the Lisp community, including
being involved in some fairly spectacular accomplishments. So I think
he has sufficient commentary credits to cover his commentary to this
point.
--
Fred Gilham gil...@csl.sri.com
I was storing data in every conceivable way, including keeping a chain
of sound waves running between the speaker and the microphone. There
was no more memory left to be had....
http://www.paulgraham.com/popular.html
A large number of strongly negative comments about Common Lisp that I can
see absolutely no reason for. He has obviously made up his mind not to
like Common Lisp regardless of what can be done with it to accomodate his
needs. Like most language re-designers, he needs a new language instead
of working within an existing one. This is a pretty silly mistake, and
not a credit to his thinking.
///
> > > On what basis should I revise my perception? comp.lang.lisp.mcl has
> > > virtually no traffic.
> >
> > Because MCL users are using a mailing list. Don't you know that?
>
> I do. I subscribe to that list. I also know that the digitool site
> says:
>
> Usenet News related to MCL
> news: comp.lang.lisp.mcl
> The MCL newsgroup is relayed bidirectionally to the Info-MCL mailing
> list.
That part of the site is followed by:
NOTE: The relay is unreliable at times. For best coverage of
MCL-related conversation, we suggest that you subscribe to the
Info-MCL mailing list.
in italics.
>
> So it would not be unreasonable to suppose that the newsgroup would
> contain any messges sent to the list.
It would not be unreasonalble unless you subscribe to the list.
Since you do, you must know that news<->info-mcl link has been
broken/stopped for some time now.
But what are you trying to communicate here? You've been getting
messages from info-mcl but saw no traffic at comp.lang.lisp.mcl and...
and you concluded that you haven't got any message from the list
after all?
Anyway, you should also have known:
1. that 4.3.1 was coming. It was mentioned in info-mcl at least
back in April.
2. that 4.4 is in beta.
[I'm not the beta tester. Rainer may be].
3. that Digitool is alive and they keep writing, writing, writing
> Gary Byers no longer works for Digitool. "In the works," is a
> euphamism for vaporware. The appearance of 4.3.1 is a positive sign,
> the only real positive sign among many negative ones. That's why it
> surprised me.
Couldn't you stop drawing a grim picture??
When I saw Rainer's post, I thought it put this topic re: Digitool to
the good rest. And here you go again. WHY? The more you do that, the
more you sound disingenuous. Are you trying to prove the Erik's point?
abe
--
<keke at mac com>
> * Erann Gat
> > I stand by my broader point though. I disagree with Erik's claim that
> > what Lisp needs is for people to express their unconditional love for it.
> > I say what Lisp needs is for people to use it to build cool stuff and
> > beat the pants off their competition.
>
> Sigh. The point with the love-your-language part was that people do not
> use the language for anything at all when they are mostly depressed about
> its lack of use and prominent people in the community beat it up all the
> time for personal reasons. You have yet to explain how people start to
> use something they do not use.
Yes. A defeatist posture does not win you confidence from those
around you. My experience is that projecting confidence in your own
opinion, providing good argumentation for it, and not continuing to
focus on the antagonistic part of your relationship with the people
making decisions goes along way. Melodramatic, oblivious, and
condescending behavior is not really good for getting things done, tho
I appreciate their cathartic aspects.
Erann, what you are asking for very considerable changes in reality,
changes which depend upon a great deal of risky work from other people
in a market where capital is somewhat scarce. It's not likely that
those changes can be made. I would reccomend you take a different
approach to this, focus on:
* An ANSI standard and multiple implementations supporting it.
* The strengths of these implentations, becoming
familiar with several of them so you can argue for their
abilities.
* The flexibility in initial and continuing investment into
the tools, a range from public domain and user support to
exceptional customer support on commercial systems.
* The standard and Kent's Common Lisp Hyperspec provide
excellent documentation at a level equal or superior to any
language I have seen. Combined with a library containing
the classics: CLtL2, ANSI Common Lisp and "On Lisp (Graham),
"OO Programming in Common Lisp" (Keene), and PAIP (Norvig)
the documentations for CL is marvelous.
* The CL spec is public and not controlled by a single
commercial entity, nor it is defined by the one
implementation.
* The strengths of the community and the breadth of work CL has done:
* Community was capable of putting together an ANSI spec,
something Perl and Python haven't done. A considerable base
for the language has been commodotized, which puts users in
a strong relation to their vendors, much stronger than many
other languages, including C/C++.
* A very strong, and technically succesful heritage. The
ideas and tools of the community have been succesful for
several decades at accomplishing very difficult technical
tasks.
* A sizeable Free software effort that is making great strides
in getting the Free implementations packaged for various
OSs, and also providing portable Free implementations of
needed functioanlity including SQL/persistence, web
development, testing, debugging, distribution,
modularization, and SGML/XML.
* Very experienced users in the community, many of whom are
available for consultation. These are people who have been
working with lisp for decades, perhaps implemented it
several times, built custom hardware for it, etc...
*
* The technical advantages as they relate to business concerns:
* Studies indicate that several of the CL implementations are
very competitive in terms of performance and memory usage,
particular when compared to Java and C++. Very competitive
meaning that the CLs ran faster and smaller. This means
that performance concerns for clients are comparable to
those of mainstream languages, if not better.
* Studies also show that in developer time, CL is in a world
by itself. My own experiences confirm this. With a staff
of 5 programmers we were able to develop an application
orders of magnitude more complex than an effort we did with
ObjC and WebObjects, that had 4 programmers. Faster and
more enjoyable. (Check www.lisp.org for citings) For
business this means less money to develop, quicker time to
market, and a big advantage over competitors.
* The dynamic runtime of CL means big developer time savings.
Smalltalk is perhaps theonly language that can compete on
this front. The whole process changes in a way that makes
initial devleopment, debugging, and testing easier for
developers. All the tools for doing these are available for
Free as well. With CL, businesses can maintain a very
high-level of customer support and responsiveness. My shop
routinely turns around bugs in less than 15 minutes. That
means when a customer calls, sometime they get a fix before
hanging up. Customer like that.
* Lisp excels at solving sophisticated problems, offering real
language support for those problem domains that require
considerable work from otherlanguages to even begin your
approach. The CLOS MOP is supported by several
implenentations, providing a level of sophistication to the
programmers interface to the runtime object system. Lisp
macros are incredibly powerful for development layered
domain-specific languages which allow you to approach the
problem with stronger and stronger tools so that when you're
done, the systems is very flexible.
This may require that you educate youserlf about CL at a higher level
than you currently are, and to either forumalate a relation to those
decision makers that allows you to approach this topic in a
non-defeatist manner or find another job. However, those things are
more likely to happenthana massiveinflux of capital and enthusiastic
labor than what is required to fix the things you lament, or prescribe
to the community.
--
Craig Brozefsky <cr...@red-bean.com>
http://www.red-bean.com/~craig
The outer space which me wears it has sexual intercourse. - opus
Odd that you don't like this approach.
Why do you think that you are _not_ part of the problem? How come
your abuse is perfectly OK and that posting articles with intensely
inflammatory vocabulary like "rabid nutcases" is not indicative of a
person who has arrived at the amazingly self-destructive notion that
he has no effect on the world at all so he can do anything he wants
without incurring the slighest judgment of hypocrisy or ridicule?
#:E.
I find that the paper makes a good points here and there, but overall
it is irrational, sometimes to the point of being ridiculous.
What sort of intellect is supposed to be swayed by an argument concerned
with how many characters it takes to type ``first'' and ``rest'' compared
to ``car'' and ``cdr''.
It seems that parts of this paper are trying to appeal to schoolchildren.
FG> I propose that anyone posting opinions derogatory of Lisp be
FG> requred to produce `commentary credits'. The idea is that people
FG> who don't have these credits are treated as `clueless' and can be
FG> simply ignored rather than creating flame wars.
I think this would make the newsgroup more homogenous (more
sycophants) which would make Lisp seem even more freaky to outsider
decision makers and developers.
I think a policy of `commentary credits' makes sense for a mailing
list in which a specific task is being worked on, or a moderated group
with a well-defined topic. It seems to me a general public Lisp news
group (or even a public Common Lisp news group, as certain individuals
advocate) benefits from being exposed to beliefs and attitudes of
outsiders.
A significant part of the work in moving an idea forward is the
relentless politics and advocacy that results from interaction with
`clueless' people. Sure, these people can sometimes present
themselves in a grating, confrontational way; nonetheless, there may
exist more ways to deal with this than to attempt to crush them like
bugs, or to silence them by policy...
> Any pointers, anyone?
It's on his site:
http://www.paulgraham.com/popular.html
It is a relatively succinct article on why he believes "early Lisps" were
good and Common Lisp less good than those. I also think it's a bit of a
rehash of many of the critiques that rpg has done on the language, but told
from a user viewpoint rather than an implementor's viewpoint.
I think that any person who has used Common Lisp for a long time knows that
there are places where it could be improved. We are often frustrated that
the standardization effort was halted before those involved were able to
deal with some of todays hot issues (Given that this was 15+ years ago,
it's actually quite amazing that they were in a position to consider these
issues at all!). However, Erik is correct in stating that our drive for
perfection and internal feature sniping often gives outsiders more
ammunition with which to shoot Lisp down. For better or worse (and i do
believe it is better), Common Lisp *IS* the only viable Lisp platform out
there today (No flames about Scheme, please. We acknowledge you, but
respectfully disagree). The Lisp community must come together to support
Common Lisp, warts and all (most of which were put there for good reason).
Without that, the language will continue its status as a curiosity rather
than a viable commercial option.
The good news is that Lisp is enjoying a Renaissance of sorts. More people
are interested in (and using) Lisp than have in many years. In addition,
people are waking up to the fact that (to paraphrase Nikolaus Wirth) Lisp
is an improvement on most of its successors. That being said, there is
serious damage control that needs to be done (mainly from self inficted
wounds):
(1) A new standardization effort needs to be started to advance the
language in those areas seen as vital for modern languages, but were unable
to be decided fifteen years ago. Candidates for areas include GUI,
multi-threading, FFI's, database binding, subsetting, and application
deployment.
(2) Lisp implementors and vendors need to stop thinking so much about
their "Lisp market share" and start thinking about growing their portion of
the "language market share". If they think about the former, killing each
other by trying to take away each other's shrinking market share, they
will surely all die. If they try to succeed by growing the market for
Lisp, they all prosper. It's a classic Prisoner's Dilemma problem but, in
this case, we don't have the luxury for iteration to find that an optimum
is found in cooperation. Vendors need to commit to working together for
the good of the community. Period.
(3) Implementors need to commit to the standard. It may be (in your view)
flawed, but it's the only one we have. Kill it and you kill the language.
This helps neither users or implementors.
(4) Users need to hold vendors feet to the fire to encourage cooperation.
keep reporting defects where the language differs from the standard. Vote
with your feet to insure that vendors stick to the standard. Support
efforts where wrappers are witten to layer over incompatibilities in
non-standardized areas so that vendors have an incentive to standardize
these areas.
(5) Users and vendors must strive to increase Lisp's share of use in the
programming language world. Stop sniping at Lisp's (few) flaws and start
promoting its (many) strengths.
I believe that Lisp and Common Lisp, in particular, has a bright future,
made brighter by the fact that we are all in the same boat. But if we sink
this boat, we will all be swimming for shore. It's time to patch the boat
from the holes we've been drilling and start to use that energy to make the
language better so that we all can sail on.
faa
> www.corman.net , another business owns corman.com
cormanlisp.com is available.
> Street address is on http://www.corman.net/license.html
Yes. Here it is:
Roger Corman
3445 Baldwin Way
Santa Rosa, CA 95403
USA
> On a philosophical note. You are creating the problem, not describing
> it.
I wish that were true because if it were I would have some truly
awesome persuasive power.
> Some people will search google and see your ignorant, denigrating
> comments about Digitool and Corman and not buy well supported, good
> products.
Actually, my ignorant comments were about Xanalys. My comments about
Digitool are quite well informed. The jury is still out on Corman.
But be that as it may, let's follow your advice and search Google to
see what comes up. Let's look for "Erann Gat lisp". The first result
is a paper I published that shows that Lisp is objectively superior to
C++ and Java according to certain quantifiable metrics. A dilligent
searcher might also find the list of success stories that I posted in
response to a recent inquiry in another thread
(http://groups.google.com/groups?hl=en&safe=off&selm=1f4c5c5c.0108252226.330d6cac%40posting.google.com).
Now let's look for "Joe Nall corman lisp". Nothing on the Web, but
Google groups yields one result: your response to me. So merely by
the fact that my postings wrung that story out of you I think I've had
a net positive effect.
E.
A couple of years ago, when there was another bout of
mutual psychoanalysis going on on c.l.l., a friend
noted: A Lisp is any language that lets its user
easily write an Eliza program. Common Lisp is a Lisp
that goes one better by directly reprogramming its user
into an Eliza.
--d
Because, unlike you, I do not obsess about my role and person. Get help,
Erann Gat. Get over the fact that you lost the fight you picked with me.
///
It may probably be a good joke if there would be more
than simple abversion against a language that relates
the statement to Common Lisp...
What in Common Lisp should lead to some kind of "reprogramming
it's user"? Sorry but I do not understand the joke but it seems
that a certain "pure" language will then be counted as better then...
ciao,
Jochen
> * The technical advantages as they relate to business concerns:
>
>
> * Studies indicate that several of the CL implementations are
> very competitive in terms of performance and memory usage,
> particular when compared to Java and C++. Very competitive
> meaning that the CLs ran faster and smaller. This means
> that performance concerns for clients are comparable to
> those of mainstream languages, if not better.
>
> * Studies also show that in developer time, CL is in a world
> by itself. My own experiences confirm this. With a staff
> of 5 programmers we were able to develop an application
> orders of magnitude more complex than an effort we did with
> ObjC and WebObjects, that had 4 programmers. Faster and
> more enjoyable. (Check www.lisp.org for citings) For
> business this means less money to develop, quicker time to
> market, and a big advantage over competitors.
So why doesn't someone demonstrate these points by going and cleaning up
in, say, the ICFP programming contest?
The only functional language which right now appears to be able to lay
claim to being both fast to run and fast to develop in, based on ICFP
results, is OCaml.
There *were* five Common Lisp entries in this year's contest, but three
of them were eliminated for bugs and the other two achieved only very
poor scores.
I know contests aren't real life, but this one is pretty close because
of the duration and the complexity of the tasks.
-- Bruce
I subscribed a relatively short time ago just to see if there was more
activity there than on the newsgroup. Since I subscribed there has
been no traffic on the mailing list.
But which is it? Is it "unreliable at times" or "broken/stopped for
some time now"? Either way it doesn't sound too good.
> Couldn't you stop drawing a grim picture??
Of course I could, but let's think about this for a minute. Suppose
my grim picture is wrong and everything is just hunky-dory is Lisp
land. Your request for me to stop drawing a grim picture is based on
the premise that I have the power to destroy what is in fact at the
moment a robust and vibrant industry simply by saying that it isn't
robust and vibrant. God, if that were only true. Then I could get
rid of Java and C++ simply by painting a grim picture of them. (And
believe me, I've tried. It doesn't work.)
On the other hand, if I'm right, then my grim picture just might
motivate some people to take some constructive action to help fix the
situation (like publish more Lisp success stories).
Either way I don't see how Lisp gains from my silence.
E.
Perhaps you are not privy to knowing that Eliza was a
prototype of a self-proclaiming prophet AI program that
inspired belief in its subjects.
Psychobabbling,
Stephen
This point is well taken. However, let's remember how this whole
thing started: it began when John Foderaro expressed his dislike of
the Loop macro in some pretty uncertain terms. Now, perhaps he
shouldn't have done that. But if Erik had taken the energy he put
into taking John to task for this and put it instead into writing up a
Lisp success story (surely he has many) no one would have even noticed
or cared that John dissed the loop macro. And if everyone had taken
the energy they've put into this argument and used it instead to write
up a success story and put in on the Web, we'd all be better off.
> My experience is that projecting confidence in your own
> opinion, providing good argumentation for it, and not continuing to
> focus on the antagonistic part of your relationship with the people
> making decisions goes along way. Melodramatic, oblivious, and
> condescending behavior is not really good for getting things done, tho
> I appreciate their cathartic aspects.
Are you talking to me or Erik?
> Erann, what you are asking for very considerable changes in reality,
You must be confusing me with someone else. All I'm asking for is for
people to stop bashing everyone who says something negative about Lisp
over the head, and instead put that energy into publicizing how Lisp
helped them win. Is that asking for considerable changes in reality?
> I would reccomend you take a different approach to this, focus on:
[ Much stuff deleted]
I preached the gospel of Lisp for many years on pretty much those
terms. The wall I always ran up against was the question: "Who uses
it?" The answer to that question for C++, Java and Perl is: everyone.
What's the answer for Lisp? A recent query to this newsgroup asking
people what they used Lisp for garnered only a *single* response.
Why? It's certainly not for lack of participation in the newsgroup as
a whole.
E.
Yes, this is Erann Gat: Commit some evil, wait for others to rectify it.
Lie, misrepresent, smear, then make it somebody else's responsibility to
make sure that something else, which may or may not be the truth, is also
posted. Anyone reading it are left to speculate who might be right, you,
who still might have more credibility in some circles, despite valiant
efforts to destroy it through this self-destructive campaign, or somebody
who gets pissed off by your continuous stream of falsehood and negativity.
Sure, I know you are trying to prove me wrong. Your "game" now is to
make those who think that negative articles and commentary on the Net are
bad, think again: by posting easily debunked bullshit and negative crap
about vendors, products, _whatever_, your "hope" is to enlist even more
positive reactions than I got, because your game is to beat _me_, not
help anyone and certainly not Common Lisp, and if you hurt a company or
two in the process, if some people get another uphill battle to fight,
who cares? Another part of the "game" is obviously to show people how
irrelevant negative commentary on the Net is, but all you will achieve
is that people regard Erann Gat as a certifiable nutcase who has only
destroyed himself. But have fun with your stupid little game, Erann!
///
Still, I think Parts 1 ("The Mechanics of Popularity") and 2
("External Factors") are interesting, and relevant to the current
thread. On the one hand, I find his arguments lousy. He could have
formulated the essay as a set of style suggestions and a proposal for
some more MOP-like functionality, that he feels is necessary for a
Lisp to be popular. Instead he just badmouthed Common Lisp. On the
other hand, if this is the build-up to a split, followed by his
actually implementing his dream lisp, it could be good. He's
obviously uncomfortable inside CL, which probably means he shouldn't
be using it. But he's a Lisper, so what should he use?
> I know it's common around here to argue something like "Lisp is not
> optimised for mundane tasks; it's optimised for solving the most
> difficult problems."
>
> True as it may be, I think promoting Lisp this way is doing it a
> terrible disservice. By the time today's youngsters get around to
> solving extremely difficult problems (if ever), they've already
> acquired half a dozen languages. They've already learned how to push
> their current tools past their limits, and they're more than likely
> constrained by their existing code base, availability of skilled
> employees, and prejudices acquired through years of thinking in their
> current languages. They're too far gone.
>
> I think it is absolutely essential that Lisp be promoted as an
> excellent language for solving simple tasks as well as the very
> difficult ones. Otherwise it will not get a foot in the door.
I think both are good ways to get one's foot in the door. Especially
emphasizing the fact that CL *is* optimized for big, complex,
difficult problems. And that, nonetheless, CLISP is *still* better
for scripting for unix admins than is Perl. The tack I've taken in
advocating from this point of view is: it's just as good for one-off
hacks, and routine admin stuff; probably about 1 in every 10 or 20
cute admin scripts grow into something more significant; probably
about 1 in every 10 or 20 of those turn into something too complex for
Perl to handle comfortably; we can't tell what these scripts are going
to be ahead of time -- if we could, we'd have written them in a real
language in the first place. That argument has seemed to convince a
majority of the people I've made it to of its validity, but a minority
to actually change their behavior. (Unfortunately, about half of
those who changed their behavior started doing day-to-day stuff in
Java ... sigh ... an improvement, but not exactly what I was hoping
for. Of course, at this point, we're talking about 5 people each for
Java and CL).
Perhaps a Free Software project called CommonLispScript, or something,
packaging up CLISP, and a bunch of utility libraries might help. It's
easy enough to install all the needed parts right now, but they're not
all together, piched as a unix scripting language. Maybe if I have a
free saturday with nothing better to do sometime...
> * Rainer Joswig <jos...@corporate-world.lisp.de>
> > Digitool was never a very active company. But especially in the last few
> > months there was a lot of positive action:
>
> Thanks for posting this. However, I have a small gripe: This stuff was
> published only because someone said something stupid and negative about
> the company. It is very nice to see such rotten behavior countered with
> real and positive information and good news, but maybe it should have
> been better known to begin with?
Hmm, I knew everything he mentioned there, which probably means that
anyone who was paying attention knew about it. Of course, if I
weren't hoping for a Mac in my near future, I probably wouldn't have
been paying attention. I think 4.3.1 was announced to this ng.
When will it dawn on you sluggards that it is not the macros that are the
issue? John Foderaro expresses a very strong hatred for the standard as
such, and the standardization process in particular. This undermines the
whole _legitimacy_ of Common Lisp qua language, and he's doing this as a
representative of a vendor who claims to produce a conforming Common Lisp
implementation. I am _amazed_ that the people who regard his behavior as
excusable have to excuse some silly little trivialty. There is a marked
difference between being personally opposed to abortion and working to
overturn Roe vs Wade. If you are working for an abortion clinic and you
post "private" arguments that could _really_ help those who want to
overturn Roe vs Wade, do you expect anyone to consider any _lesser_
issues than the biggest possible and most damaging issue? Well, only if
you expect people to be really stupid or you are manipulating the issues
so it looks like a harmless non-issue to people you do not want to care.
Nobody, and I mean _nobody_, cares what John Foderaro's personal opinion
on the loop macro is, or the if/when/unless nonsense he only hurts
himself by ranting so abjectly and manifestly _irrationally_ about, but
when he is arguing that people have to do so much stuff outside the
standard, anyway, that it does not matter whether they use non-standard
stuff, and he argues very strongly that it is _bad_ that the committee is
guilty of a bunch of _compromises_, he is arguing against the community
concensus-shaping process, and promises that he will _not_ lay issues to
rest, but continue to fight for his way forever, which only destabilizes
the community and never lets us move on, to, say, standardize more stuff.
Since you suffer from the exact same "can't get over this"-syndrome,
Erann Gat, you probably do not see this is the mark of a lunatic, but
that is what it is, and that lunatic is a central figure at a Common Lisp
vendor. That is the damage he is doing. That damage cannot be undone by
"success stories" or any trivialties. Undermining the legitimacy of a
standard is not met with "but I did good with it". That is no more a
valid argument than quipping "but it felt good" about a drug that the FDA
revokes from the market.
> You must be confusing me with someone else. All I'm asking for is for
> people to stop bashing everyone who says something negative about Lisp
> over the head, and instead put that energy into publicizing how Lisp
> helped them win. Is that asking for considerable changes in reality?
As usual, you argue as if you have _zero_ clue what is at stake. Why?
Is it because you so adamantly refuse to show that you understand an
issue _I_ raise? I have my doubts that you do not _actually_ fail to
understand the issues involved here. You are far too sinister for that.
> The wall I always ran up against was the question: "Who uses it?" The
> answer to that question for C++, Java and Perl is: everyone.
As long as you think in those terms, you have set yourself up to lose.
Nobody can help you when the reality you live in is not sufficient for
you to form your opinions. "Everyone"!? What is _wrong_ with you?
> What's the answer for Lisp?
You clearly imply that success stories do not work, and that one more
would not help. The critical mass that you are obviously looking for
does not exist, cannot exist. We simply do not have the infrastructure
to support it in the Common Lisp community. Cities that expand have to
cope with water, electricity, sewage, roads, telecoms, law enforcement,
health care, etc, before they can let people move in, and politicians and
civil engineers know how complicated and costly this is. Even the most
rabid liberatarians understand that this infrastructure has to be in
place and that everybody who live in that society has to help pay for it.
To make this kind of infrastructure-building work, you need both a large
tax base and the ability to borrow _vast_ amounts of money. The same is
true of a user community that grows to be very large -- it has to devote
a good chunk of its profits to building and maintaing its infrastructure.
Microsoft has figured this out, and they build the infrastructure _first_
these days. Sun figured it out with Java, too, and the spent a godawful
lot of money on building the infrastructure before anyone even saw Java.
The XML crowd has done the same thing with more politics and manipulation
than most people are willing to think about. The Common Lisp community
does not make enough profit to grow enough to fund its own infrastructure
and it has insufficient volunteer effort to help build it. Therefore,
Common Lisp must of necessity confine itself to a growth pattern that is
completely incompatible with your fake desire to see it used sufficiently
for "people use it" to be a self-propelling and self-fulfilling argument.
We are at a point in the Common Lisp community where only those who think
Common Lisp is truly great both for personal and professional reasons are
_likely_ to use it. Just pointing to others will _necessarily_ have to
answer the question _why_ they used Common Lisp. That cannot be a silly
deferred answer like "oh, somebody else also used Common Lisp" because we
simply do not have the automatic credibility of critical mass. This is
why it hurts Common Lisp to have people tell stories about why they do
_not_ use Common Lisp, why they hate or dislike Common Lisp, but more
importantly, why they do not think a standard is a even good idea.
Again, just to reiterate this point: There is a huge difference between
saying that the standard is solving only part of the whole problem (of
building an application) and saying that the standard is _not_ solving a
part of the problem (of being a complete programming language). If you
argue that the standard set of conditionals are _bogus_ and should not be
used, you are undermining the _usability_ of the standard qua standard.
If you argue that some construct in the standard should be avoided "like
the plauge", that is not a statement about the macro, it is a statement
about the trust in the stamp of approval that a standard is supposed to
have: the process that created that standard managed to include something
that is "like the plague". How can you possibly trust the _rest_ of it
when it has let something like that in? And let us not forget the case
issue. The standard is more than _wrong_, according to the same voice,
for using upper-case symbol names. The whole point with a standard is
that it be the basis for our ability to cooperate on _other_ things. It
is not unlike accepting the outcome of an election instead of bringing
legal action against the election process -- if you communicate to the
electorate that you do not trust the process after you lost, you do not
challenge just the specific outcome, you challenge the concept of holding
an election to determine a whole class of outcomes. If you really wanted
to improve the election process, you would _not_ have sued to alter the
outcome, but would have respected the outcome whatever it was under the
current set of rules and practices, and fought for changes independently.
What I want the Common Lisp community to tell every newcomer and every
vendor of a (purportedly) conforming product to tell every customer is
that Common Lisp the Standard is not only good enough, it _does_ work as
the basis for cooperation on other things we want to accomplish. It is
massively unproductive to argue against the standard unless you are doing
so in the context of the standards process -- because just by doing so,
you are saying that the standard is both _unfinished_ and _unsuitable_ to
base further work on. Those who cannot put their lost fights behind them
and move on, are keeping _everyone_ back. The inability of some people
to move on has been marring the Common Lisp community forever, and from
my long and considerable experience with standardization processes (ISO,
IETF, ANSI, national), I have to say that the willingness of some members
of the standards committee for Common Lisp to respect the process and the
reults of its votes is far lower than in any other process I have been
part of or whose work I have tracked. This is reflected in the lagging
implementation of conforming Common Lisp systems, too.
From what I have seen of the existing implementations, conformance is
basically a non-issue compared to the rest of the work that it necessary
to make a system work, provided that you start off with a working system,
and GCL, CMUCL, CLISP, and a few others have a working system. Moreover,
it is _not_ conformance that should set the vendors apart. They should
_all_ conform. This leads to a pretty interesting situation in that we
all know that a lot of the standard functionality in Common Lisp can be
expressed with other standard functionality. It _should_ therefore be
possible to implement what some call a "core" Common Lisp and then use a
free implementation of the rest of the language on top of that core to
get a first approximation to a conforming Common Lisp system. Then, as
you need better _performance_, not _conformance_, you implement more
"native" support for things that turn out to be slow. This should make
the difference in cost of implementation of a non-conforming and a
conforming implementation close to zero, and free systems that today lack
full conformance are prime candidates for working _together_ on this to
save considerable time.
In order for people to want to base their investments, time or money, in
Common Lisp, they need to _know_ that the standard will be supported.
The reason people clamor for other features to be standardized before
they are willing to do any work in Common Lisp is precisely the same: The
very lack of standardization introduces a higher risk of failure: What if
your chosen platform is not suitable by your users? This is the same
issue as building and releasing a Linux version of a Common Lisp system
when you are uncertain what signal management your users will be using,
or worse, suppose you want to make it available for the very popular IA32
(80x86), and you think Windows must be it, but _all_ your users hate
Microsoft, yet cannot agree on which OS to use instead. This is the kind
of risk Common Lisp users are facing today, and they are not only facing
it with non-standard extensions, they are facing it with _standard_
features and facilities. This is the really intolerable part.
And while Paul Graham whines unproductively about the lack of a tight OS
interface in Common Lisp compared to Perl (is he clueless? it is a
language _defined_ independently of operating systems -- Perl was married
to its operating systems (Unix) from the start, and only managed to make
a more abstract interface late in its development, such that it can be
used under Windows), the obvious solution is to figure out what Perl did
right in this department and provide similar operating system interfaces.
Common Lisp does not need to be changed for this -- we just add at least
one package with solid, native Unix support. However, this is just the
kind of infrastructure work I alluded to above. Like, can we use foreign
function interface definition _builders_ that produce FFI glue for each
of the existing implementations such that we can feed it ANSI C header
files and get back implementation-dependent FFI declarations, instead of
having to agree on the FFI code itself? That would come a long way to
obviate the need for humans to write FFI glue. Can we afford to do this?
When I read Erann Gat's rather vacuous "but people do not use it" whine
and implicitly invite lots of people to the great new Common Lisp City,
he does so without recognizing the need for water, electricity, sewage,
roads, telecoms, law enforcement, health care, etc, to be in place. I
believe we can get people to help build that stuff if and only if they
believe enough in the place they are going to move to, and that belief is
based in a strong desire to see some of your values realized. I call it
love for your language. If Erann Gat wants to bicker over "love" versus
"some other motivation", let him bicker. It is all he does these days,
anyway, regardless of _past_ merits.
> A recent query to this newsgroup asking people what they used Lisp for
> garnered only a *single* response. Why? It's certainly not for lack of
> participation in the newsgroup as a whole.
Was it you who asked?
///
> I think both are good ways to get one's foot in the door. Especially
> emphasizing the fact that CL *is* optimized for big, complex,
> difficult problems. And that, nonetheless, CLISP is *still* better
> for scripting for unix admins than is Perl.
Yes. Lisp is a language that people (and programs) can "grow into"
like no other.
Back in my university days I would have been thrilled to learn a
language that is excellent for experimenting with core CS concepts
(data structures, algorithms, etc), easy and fun to use for personal
hobby projects (games, communications utils, etc), has a rich history
and literature, an excellent and well-implemented standard, and -
above all - a language that becomes even MORE useful as size and
complexity increases.
I think Lisp currently covers the high ground very well, but it seems
to have deserted the playing field elsewhere, leaving the spoils to
Perl and Python. It doesn't need to be that way.
> Perhaps a Free Software project called CommonLispScript, or something,
> packaging up CLISP, and a bunch of utility libraries might help. It's
> easy enough to install all the needed parts right now, but they're not
> all together, piched as a unix scripting language. Maybe if I have a
> free saturday with nothing better to do sometime...
When the next version of GTK+ becomes stable, I'd be very happy to
help to bundle some CL bindings with Clisp and CMUCL and put
together some demos.
John Foderaro expresses a very strong hatred for the standard as
such, and the standardization process in particular.
Instead go to http://groups.google.com and find the exact message I sent and post the
exact text I wrote along with a link to the article so everyone else can see the
context. You can start with the message from which you derived the above statement.
Any sufficiently complex object has flaws. Every car has flaws, every plane has flaws
and every computer language has flaws.
If you ask someone what the flaws are in a complex object are and they can't name a
few then they are either
1. a novice and really don't know much about the object
2. stupid and can't figure them out
3. a liar and just won't admit to them.
Your insistence that people knowledgeable about Common Lisp pretend that the langauge
has no flaws means you want us to appear to be stupid or liars. This will NOT
enhance the credibility of the language. If we Common Lispers don't admit to the
problems in the language people will as Java or C++ fans and they they'll hear a set
of damaging and likely untrue problems that will make Common Lisp seem worse than it
really is.
I look forward to seeing replies from you that are adult and thus don't contain
personal attacks against me or anyone else. I also look forward to seeing those
references on each statement you attribute to me.
-john foderaro
franz inc.
EN> ... it is a language _defined_ independently of
EN> operating systems -- Perl was married to its operating systems
EN> (Unix) from the start, and only managed to make a more
EN> abstract interface late in its development, such that it can
EN> be used under Windows), the obvious solution is to figure out
EN> what Perl did right in this department and provide similar
EN> operating system interfaces.
Whatever they did right wrt. Unix syscalls probably did not carry over
to Windows, so they needed things like perlfork and friends so the
code could have a chance of porting. I am no perl hacker but I do
know from experience that if you know what the Unix syscall does, you
can help a perl guy as the perl layer over it is thin. Is this the
level this community wants to operate in? I vaguely remember several
respectable members explicitly NOT wanting to deal with the low level
raw OS calls but higher level abstractions.
EN> ... Like, can we use
EN> foreign function interface definition _builders_ that produce
EN> FFI glue for each of the existing implementations such that we
EN> can feed it ANSI C header files and get back
EN> implementation-dependent FFI declarations, instead of having
EN> to agree on the FFI code itself? That would come a long way
EN> to obviate the need for humans to write FFI glue. Can we
EN> afford to do this? ...
I'd love to see a discussion of this by people who have used and
implemented such things. My experience is limited to punting to C for
efficiency in some critical functions in Allegro years ago and minor
syscall toys in CMUCL. I don't know, though, if this is a big problem
for CL. If you need FFI for a good reason, you will use FFI no matter
what. Most implementations do not make it hard to do so in general.
There might be some problems with using higher level built in stuff
(re MP/select/poll thread) and the underlying raw system at the same
time but adequate warnings in documentation would cure any problems
with that.
cheers,
BM
> > Yes. A defeatist posture does not win you confidence from those
> > around you.
>
> This point is well taken. However, let's remember how this whole
> thing started:
No, I'm not interested in that part of the thread.
> > My experience is that projecting confidence in your own opinion,
> > providing good argumentation for it, and not continuing to focus
> > on the antagonistic part of your relationship with the people
> > making decisions goes along way. Melodramatic, oblivious, and
> > condescending behavior is not really good for getting things done,
> > tho I appreciate their cathartic aspects.
>
> Are you talking to me or Erik?
No one in particular. I'm not interested in that confrontation
either.
The only thing I'm interested in is discussion about how to better
promote CL. I understand that topic might have no relation to the
previous topic of this thread, but I saw an opening for introducing my
topic, so I changed the Subject.
> > Erann, what you are asking for very considerable changes in reality,
>
> You must be confusing me with someone else. All I'm asking for is for
> people to stop bashing everyone who says something negative about Lisp
> over the head, and instead put that energy into publicizing how Lisp
> helped them win. Is that asking for considerable changes in reality?
Yes, this is a change in other people which I think you will not
likely accomplish. The explosion of this thread is an indicator of
the difficulty in acheiving such a task. This is why I suggested
changing your tact when promoting CL to avoid the previous roadblocks
you hit. We should keep hope tho, because the amount of time spent on
usenet is not always an indicator of where people's energy goes.
> I preached the gospel of Lisp for many years on pretty much those
> terms. The wall I always ran up against was the question: "Who uses
> it?" The answer to that question for C++, Java and Perl is:
> everyone. What's the answer for Lisp? A recent query to this
> newsgroup asking people what they used Lisp for garnered only a
> *single* response. Why? It's certainly not for lack of
> participation in the newsgroup as a whole.
The answer for C++, Perl and Java is not "everyone." That is a
reactionary answer, and there is no non-political reason you should
accept that answer from anyone. However, if you are not able to
challenge that assumption amongst your audience, you need to deal with
it in another manner.
Paul Graham provided one answer to the "common non-sensical" answer of
"everyone uses X" question, and that is since most businesses fail,
doing what everyone else does increases your chance of failure. If
someone is pursuing this line of argumentation with you, I've find
that is not easy to win their confidence with a success story, as they
will continue to differentate your situation from the success story to
defend their position. My solution is to follow that same line of
thinking for them, to differentiate the task from others, to make the
question of what "everyone" uses irrelevant. This may take time,
since you need to overcome a fear of differentiating themselves to the
point where they can be a magnet for blame, but playing to their ego
in such situations can be effective.
cbbr...@acm.org wrote:
> Erik Naggum <er...@naggum.net> writes:
>> * Rainer Joswig <jos...@corporate-world.lisp.de>
>> > Digitool was never a very active company. But especially in the
>> > last few months there was a lot of positive action:
>
>> Thanks for posting this. However, I have a small gripe: This stuff
>> was published only because someone said something stupid and
>> negative about the company. It is very nice to see such rotten
>> behavior countered with real and positive information and good news,
>> but maybe it should have been better known to begin with?
>
> This is a classic problem; it is entirely common for the "good news"
> not to get publicized until it _needs_ to be because someone claimed
> otherwise.
> On the other hand, if I'm right, then my grim picture just might
> motivate some people to take some constructive action to help fix the
> situation (like publish more Lisp success stories).
My intuition is that it is more likely that you will simply piss
people off.
I have no really good evidence of this (unless you count the responses
you've had so far, but usenet is a strange beast where 90% of the
readers never post anything anyway, so we can probably justify not
regarding them too seriously) but in the few short years I have lived
on this earth, I have found that it doesn't work for me; only very
rarely have people wanted to do things that would please me when I
laid into them with this kind of confrontational attitude.
Your mileage may, of course, vary.
-dan
--
http://ww.telent.net/cliki/ - Link farm for free CL-on-Unix resources
>
> I also like the way you blunder blindly around this arena from time to
> time, charging at any red rag you can find. I know your triggers,
> Frido. The words "free software" and "popularity" are enough to set
> you running full tilt, and almost always at the wrong target.
Really. Well I would like to know why I should have anything against
free software and why I'm against populrity. What drives me nuts is
the saying. If that and that were there all would be fine. I aske you
to provide what you thinki is missing and you start such a p... poor
flame story
> But to
> be perfectly honest with you, I don't feel anywhere near enough malice
> to want it any other way. Just keep doing what you do best, and best
> of luck to you.
Well I can't say the same about you. And if you come back from you
prejudices and crying we probably can talk about Common Lisp again
Have a nice day
Friedrich
> g...@flownet.com (Erann Gat) writes:
>
> > Well, I've got news for you, Erik Naggum: there is only one Lisp
> > vendor left. All the others are out of business.
>
> Which one? Franz? Call me crazy, but I can think of several:
> Xanalys, Digitool, Corman.
Actually, if you use the update frequency of the home pages of Franz,
Digitool and Xanalys as an indicator, you might think there's a
"new spring of lisp" right now. Digitool has managed to get out their
version 4.3.1 and has announced that they're testing their Mac OS X
version, Xanalys has put "lisp" predominately on their front page
again(!), and the Franz page is as frequently maintained as always.
--
(espen)
> I preached the gospel of Lisp for many years on pretty much those
> terms. The wall I always ran up against was the question: "Who uses
> it?" The answer to that question for C++, Java and Perl is: everyone.
> What's the answer for Lisp? A recent query to this newsgroup asking
> people what they used Lisp for garnered only a *single* response.
> Why? It's certainly not for lack of participation in the newsgroup as
> a whole.
Maybe we're too busy writing Lisp programs to take silly polls?
I use Common Lisp to do my income taxes. This year I had work under way
to automatically fill out the IRS pdf forms, but then I saw how much I
owed and lost interest.
Tim
So it would seem.
I'd just like to point out one thing before I go. For about the last
five or so articles in this thread I didn't write the text you
attribute to me. I copied it from old postings of yours. It's been
amusing watching you argue with yourself.
For what it's worth, I love Common Lisp.
Erann
g...@flownet.com
> But CL is already fine for simple problems. I do a lot of simple
> things for people in the listener. It's a nice problem
> exploration/data exploration tool. You get someone to export their
> data in something vaguely lisp friendly, read it in and you can start
> working with their stuff in ways Excel etc. don't allow.
Sure. I tried to be polite and start using Excel 5 years ago, but after
noticing that Windows and Excel would arbitrarily crash after putting
them to _real_ test, I went back to doing this kind of stuff in lisp
again.
BUT I still think the "simple interaction with the OS" argument is valid.
It's still less painful to use perl for a lot of these tasks, and that's
a real shame.
--
(espen)
> > Couldn't you stop drawing a grim picture??
>
> Of course I could, but let's think about this for a minute. Suppose
> my grim picture is wrong and everything is just hunky-dory is Lisp
> land. Your request for me to stop drawing a grim picture is based on
> the premise that I have the power to destroy what is in fact at the
> moment a robust and vibrant industry simply by saying that it isn't
> robust and vibrant. God, if that were only true. Then I could get
> rid of Java and C++ simply by painting a grim picture of them. (And
> believe me, I've tried. It doesn't work.)
You are arguing for the argument sake. I think it fruitless to
point out what is wrong in your reasoning while knowing that you
are well aware the flaw in your reasoning.
>
> On the other hand, if I'm right, then my grim picture just might
> motivate some people to take some constructive action to help fix the
> situation (like publish more Lisp success stories).
There were some discussion a while back at info-mcl mailing list about
Digitool needing more marketing and they and/or users should do this or
that. I say they were mostly constructive. If you propose that Digitool
should reestablish info-mcl<-->usenet relay, I might agree. Maybe someone
should post a monthly-reminder or something to comp.lang.lisp.mcl. If you
still care about MCL and its future, please come back to info-mcl and
make a constructive suggestions or two instead of giving false impression
that Digitool is out of business or will be anytime soon. I don't think
Digitool/MCL is in "hunky-dory" state, so, I think the negative comment
from someone like you could actually be harmful. If you don't care about
MCL anymore, just leave this precious gem alone for the good.
>
> Either way I don't see how Lisp gains from my silence.
>
You can write CL code or write more "success stories" silently
instead of engaging in a devastating flame war.
abe
--
<keke at mac com>
> ke...@ma.ccom (Takehiko Abe) wrote in message news:<keke-03090...@solg4.keke.org>...
[...]
> > > So it would not be unreasonable to suppose that the newsgroup would
> > > contain any messges sent to the list.
> >
> > It would not be unreasonalble unless you subscribe to the list.
> > Since you do, you must know that news<->info-mcl link has been
> > broken/stopped for some time now.
>
> I subscribed a relatively short time ago just to see if there was more
> activity there than on the newsgroup. Since I subscribed there has
> been no traffic on the mailing list.
[...]
Strange, I have a number of recent messages in my mailbox from that
mailing list. Your lurking period must have been very short indeed.
Digitool employees frequently answer users questions on the list, and
have done so recently. I've always gotten good support there.
-George
> I'm curious, what other languages do people feel at home it?
I used to feel even more at home with prolog, but I got tired of how
awkward it was to do the trivial parts of my programs with it. I used
to feel at home with perl, but I got tired of how ugly larger programs
tend to be, and even more tired when the language started to become a
moving target with each 0.001 version increment.
--
(espen)
Huh? I argued against myself because you copied my words? Geez. Just
how stupid are you? Just who _do_ you think you are fooling with this?
But this is just the kind deception and evil we have come to expect from
you. You only surprise in its magnitude, not at all in its character.
You are such an idiot, Erann Gat. Get some professional help to get over
your personal problems. And please take the prescribed medication before
you post again, whether you cut and paste from newspapers or whatever
else you need to copy from to pretend that you are not really speaking,
yourself. I feel so much pity for you and your problems that I cannot
even be angry at such a pathetic excuse for a person.
///
Really?
> Your insistence that people knowledgeable about Common Lisp pretend that
> the langauge has no flaws means you want us to appear to be stupid or
> liars.
And this is even remotely connected to what I actually say?
Pot. Kettle. Black. Idiot.
Do you have respect for the standard, John Foderaro?
Do you have respect for the standardization process, John Foderaro?
What do you call the people who argue for adhering to it?
What do you call the people who want upper-case symbol names?
Let us hear your very own words!
///
> >>>>> "EN" == Erik Naggum <er...@naggum.net> writes:
> [...]
>
> EN> ... it is a language _defined_ independently of
> EN> operating systems -- Perl was married to its operating systems
> EN> (Unix) from the start, and only managed to make a more
> EN> abstract interface late in its development, such that it can
> EN> be used under Windows), the obvious solution is to figure out
> EN> what Perl did right in this department and provide similar
> EN> operating system interfaces.
>
> Whatever they did right wrt. Unix syscalls probably did not carry over
> to Windows, so they needed things like perlfork and friends so the
> code could have a chance of porting. I am no perl hacker but I do
> know from experience that if you know what the Unix syscall does, you
> can help a perl guy as the perl layer over it is thin. Is this the
> level this community wants to operate in? I vaguely remember several
> respectable members explicitly NOT wanting to deal with the low level
> raw OS calls but higher level abstractions.
Sometimes, I suspect that dealing with the lower-level OS calls
becomes necessary, no matter how good the abstractions. However, by
their nature, it would seem silly to standardize on an interface given
that to at least some extent there's a moving target.
However, what would make me feel good is to see (public) debate on
what a current interface would be like, just so that I (and others)
can see what has been considered and rejected, and so that where there
are good ideas others can use them.
I would like to see both low- and high-level interfaces to OS
features; preferably without subtle bugs. As a case in point, I'll
talk a little about RUN-UNIX-PROGRAM, a hypothetical function that
runs a unix program.
There are several approaches that can be taken here. One is as a
wrapper to exec() and friends, so that its signature would look
something like:
run-unix-program (path arguments &optional environment)
Another approach could be to use system() (or /bin/sh -c); then
run-unix-program would be like:
run-unix-program (string)
So far, so non-controversial. However, there's a certain amount of
pain and suffering involved if you are porting between
implementations; in particular, if you've used the first form and are
trying to implement it in an implementation with only the second.
The problem arises, of course, because these two things are very
different; one invokes another interpreter, with another layer of
magic; so spaces have to be quoted, metacharacters escaped, and all
sorts of hairy nonsense. A first cut might be
(defun wrapper (path arguments &optional environment)
(run-unix-program "/bin/sh -c \"~a ~{~a~^~} ~:{~a=~a~}\""
path
arguments
environment))
but I'm sure you can see all the pitfalls.
The point I'm trying to make is that a certain amount of public
discussion on these non-standard features (not just OS interaction)
might be beneficial, both for implementors and users, even if it's
only to the level of making some suggestions for differences to expect
between :unix and :windows on the *features* list.
Christophe
> But while you mold this newsgroup into your perfect little cadre of
> Erik Naggum sycophants the language you claim to love so much is
> withering and dieing, and you don't even notice. You talk about "the
> Lisp vendors." Well, I've got news for you, Erik Naggum: there is
> only one Lisp vendor left. All the others are out of business.
>
This is false.
>
> Xanalys is the resurrection a bankrupt Harlequin, which was acquired
> not for its Lisp technolgy, but for its electronic publishing
> technology. The Lisp product just sort of came along for the ride,
> and many of the key Lisp people (you included) aren't working there
> any more. That would give me pause in betting on Xanalys as a stable
> long-term provider even *before* reading what Franz has to say about
> them.
Kent has already pointed out the factual errors in this. I'd like to
just give an anecdote.
I have a copy of lispworks. The other month I found a *really*
obscure and low-level bug: I forget the details but I think it was
something to do with the stack getting smashed if you tried to do
something strange in the condition system. It was not a bug that I'd
expect would get exercised in real life (the code that produced it was
deliberately strange). I mailed Xanalys support because I though they
might be interested, with a note saying I didn't really need a fix. I
got a fix within two days. So, I don't know who is at Xanalys, but
I'm pretty sure that they understand their Lisp system rather well.
I've had similar experiences with ACL, of course.
--tim
>
> I do. I subscribe to that list. I also know that the digitool site
> says:
>
> Usenet News related to MCL
> news: comp.lang.lisp.mcl
> The MCL newsgroup is relayed bidirectionally to the Info-MCL mailing
> list.
>
> So it would not be unreasonable to suppose that the newsgroup would
> contain any messges sent to the list.
>
Um. Just a minute, You subscribe to the mailing list, so you know it
gets trafic. You also know that c.l.l.m does *not* get traffic. So
you *know* that the gateway is broken. And yet you post an article
stating that your perception of digitool as not a healthy company is
supported by the lack of traffic on the newsgroup. This is very
strange indeed.
--tim
Being a vendor in this market is not an easy business as the demand for Lisp
IDEs is not even close to more "common" languages as everyone here knows for
sure.
Kent is right if he points out that Xanalys is much more focused than
Harlequin.
Our core business is software development for the intelligence market and we
write most of this in LispWorks. This is why LispWorks is not the *public*
product we put the most - please stop laughing, I know it is slightly below
zero right now - marketing money into.
That does not mean that we are not working on it. Those dealing with us know
this - regardless if some web browser handles JavaScripts or not ;-)
We do see a rising interest in LispWorks over the last 12 month so we will
definitely come up with new releases and show more presence in the market.
Besides the love for the language all activities of any vendor must backed up
by economical reasons and return of investment. Sad but true if you want to
stay in business.
Rolf Mach
Kent M Pitman wrote:
> g...@flownet.com (Erann Gat) writes:
>
> > Xanalys is the resurrection a bankrupt Harlequin, which was acquired
> > not for its Lisp technolgy, but for its electronic publishing
> > technology.
>
> Not quite right, actually.
>
> Xanalys does NOT due the electronic publishing thing. Harlequin still
> exists and does. Xanalys is the spin-off that does SPECIFICALLY the
> Lisp-based and layered Information technologies. See their web site.
> The original purchase by Global Graphics may have been as you say, but
> Xanalys is itself a financially distinct concern with its own concern
> that directly and indirectly addresses the Lisp products.
>
> > The Lisp product just sort of came along for the ride,
> > and many of the key Lisp people (you included) aren't working there
> > any more.
>
> The people you know. Their real key people have never had their names
> bandied about and several are still there.
>
> I myself used Lisp a lot but was never directly a Lisp maintainer.
> The loss of me had no effect on the Lisp product per se.
>
> I prefer to be a user / critic rather than a producer. I was working on
> the standard itself for a long time, and then on WebMaker (a FrameMaker to
> HTML translation tool) while I was there.
>
> > That would give me pause in betting on Xanalys as a stable
> > long-term provider even *before* reading what Franz has to say about
> > them.
>
> Hopefully what I said will give you reason to reconsider both your posture
> and the importance of letting a company speak for itself. I'm not a Xanalys
> employee and probably even my point of view is not quite right, but I think
> it's closer than what you said.
--
__________________________________________________________________________________________
XANALYS - www.xanalys.com
Data Analysis and Lisp Development Tools
Software zur Datenanalyse und Lisp Entwicklungsumgebungen
__________________________________________________________________________________________
Rolf Mach
Business Development & Sales Manager, Europe
An der Schaafhansenwiese 6
D-65428 Ruesselsheim, Germany
Phone ++49 +6142 938197
Fax ++49 +6142 938199
rm...@xanalys.com
__________________________________________________________________________________________
NEW: LispWorks 4.2 at LinuxWorld Expo, Frankfurt, 30-Oct/1-Nov 2001, Hall 6.0
Booth E24
__________________________________________________________________________________________
Watson - PowerCase - Quenza - LispWorks
> A recent query to this newsgroup asking
> people what they used Lisp for garnered only a *single* response.
> Why? It's certainly not for lack of participation in the newsgroup as
> a whole.
I've already posted some real life industrial use of Common Lisp in c.l.l.
I think we should have a place to put such description. So I added a page to
CLiki for this.
Here it is:
http://ww.telent.net/cliki/success%20stories
I hope it will be filled soon.
I will put links to my industrial products as soon as I have added the
relevant pages in my web site (before the end of the month...)
Marc
Erik has claimed repeatedly that I've been on a compaign to destroy the Common Lisp
standard. The implication of this was that I've written numerous postings to this
newsgroup on that topic or that I've written a highly referenced article on that
subject. He further admitted the my simply writing a web page in which I expressed
dislike for loop,if,when and unless was irrelevant.
So I asked Eric to post references to all those anti-standard postings I've made or to
any articles I've published on the subject.
He couldn't find a single one. That's because there isn't a single one.
For most people on this newsgroup, even those I disagree with, I at least believe them
when they state facts. Eric has repeatedly shown that he will make up things and
misrepresent people if it serves his ultimate purpose.
Thus I ask that Eric from now on always include references to any fact he states. If
you see him state a fact that you don't know on your own is true, assume it's a lie.
An no more paraphrasing of what someone said! Include their actual words from some
posting or publication or don't speak for them at all.
-john foderaro
Excuse the second followup to the same annoyingly untrue bullshit, but do
you seriously think you communicate "flaws" in the _language_ when you do
nothing more intelligent than call the three conditionals "bogus" and
unconditionally call on people to avoid complex loop? Do you think
anyone knowledgeable about Common Lisp will consider you the least bit
intelligent or constructive when you claim that _that_ constitutes the
"flaws" of the language? Come on! Pretending that your idiotic rant
about if/when/unless/loop is somehow a useful contribution about the
language on par with an intelligent, thoughtful analysis of problems is
so self-serving as to make you look even more stupid than you did in the
first place. That you _keep_ that idiotic document available on the Net
is definitely _not_ to your credit.
> If we Common Lispers don't admit to the problems in the language people
> will as Java or C++ fans and they they'll hear a set of damaging and
> likely untrue problems that will make Common Lisp seem worse than it
> really is.
And what, precisely, _are_ "the problems in the language" with respect to
if/when/unless and loop? There is nothing more than _aesthetic_ whining
in your rant. Loop has lots of _real_ problems, none of which you touch
upon. The document you have posted on "lisp coding standards" is an
insult to any thinking person and especially those who like Common Lisp,
despite any wants and flaws.
If I understand you correctly, you think that by preempting the Java/C++
crowd in denouncing Common Lisp as "flawed" for some fantastically stupid
aesthetic reasons, you will make it look better that it would have been
if the Java/C++ people were allowed to do it? Geez. How stupid is this?
Who do you think will _fall_ for this fantastically irrational line of
argument?
> I look forward to seeing replies from you that are adult and thus don't
> contain personal attacks against me or anyone else.
Your passive-aggressive style of confrontation pisses me off more than
anything else you do, John Foderaro. In fact, it makes you appear so far
from sincere as you can possibly get. Your sincerity has been questioned
by more people than myself, too. I no longer trust you in any capacity,
neither your code nor your statements -- when push comes to shove and you
really have to defend yourself or something you say, you are the most
_dishonest_ person I have ever had the displeasure of dealing with, even
topping Erann Gat.
///
I am not a very experienced programmer but coming from a philosophy
background things like elegance are important to me, and I have never
run into a language that pretty much forces you into good development
habits, instead of getting lost in layers and layers of implementation
details. The ability to wade through source code with confidence
after only two weeks of learning the language (so having a very
incomplete knowledge) make changes to reflect my computer's
environment and have the whole thing work is amazing to me.
I have been coming from a web application development background, and
have been using scripting languages a lot, appreciating their
useability, but frustrated with their limitations and speed costs, so
Lisp has been like a dream come true having more power than anything
out there, making exponential leaps in development times, and a
runtime speed comparable than compiled languages.
We have entered into a new era of development one where memory and
hardware are cheap but code development and maintenance is very
expensive, and here is a community sitting on the answer to the
complaints out there, Lisp is ready to take over the programming
world. One of the fastest growing languages out there Python is
unashamedly based on many of the principles of Lisp, so Lisp should be
becoming more popular than ever before. For someone who has been
looking at the possibilities out there for rapid development, and ease
of code maintenance, adding functionality and all the main challenges
facing developers today I have made the discovery of both Python and
Lisp. Lisp does everything that Python does plus macros and is much
faster. Personally I prefer the Lisp syntax now that I am used to it,
which took a surprisingly short time.
HOWEVER.. I have also been looking at the communities and I have to
say that the one thing Lisp does not offer is the enthusiasm that is
found in Python, and there seems to have been a massive loss of sense
of humour. All the literature I have been reading on Lisp the authors
have had this enthusiasm and humour, and I find this in abundance in
the Python newsgroups, but what has happened in the Lisp community?
There is everything in Lisp to celebrate, especially now that lisp
holds the recipe to solve a lot of the problems facing large scale
developement today, and yet all I see is identity crisis, slagging of
the standards that I don't see elsewhere. I have discovered Corman
Lisp that seems to have that enthusiasm still, there are people
ganging together to get the CL implementation covered and CLOS,
apologising for not having these things covered rather than saying too
bad for you and a community is developing to make these things happen.
I applaud the effort being made by Corman and those in the community
as they are producing a professional grade lisp implementation without
the mind-numbing price demands I have run into elsewhere, and more
than anything there is the enthusiasm, spirit of excitement within
their mailing list, with users and developers helping each other out
and getting things that are not up to standard up to standard as
quickly as possible.
As an outsider looking in I see an amazing tool and language that is
not supported by much of its users which to me makes no sense. If you
don't like it why do you use it? And I hope the sparks that are there
do start to grow and become a fire. Personally when I know enough
about the language enough I am going to be doing all I can to improve
the libraries out there where I can, I have never been so caught by a
language and I would consider it a major tragedy that it disappeared
due to lack of support.
Failure to do your bidding does not constitute admitting to whatever you
want to invent about people.
Disrespect for people smart enough to see through your charades runs deep
in your personality, does it not? You think are so much smarter than
those you are trying to fool that you actually think you can get away
with this crap, right? Such arrogance simply amazes me.
> Eric has repeatedly shown that he will make up things and misrepresent
> people if it serves his ultimate purpose.
I thought you would appreciate that, considering your own track record.
Why is it wrong for me, but not wrong for you? Several people here have
arrested you for misrepresenting me. None other than you sorry self have
accused me of mispresenting you. Maybe you should grow a clue from this?
> Thus I ask that Eric from now on always include references to any fact he
> states. If you see him state a fact that you don't know on your own is
> true, assume it's a lie. An no more paraphrasing of what someone said!
> Include their actual words from some posting or publication or don't
> speak for them at all.
I am not sure what would constitute sufficiency in doing your bidding.
Would you please explain how you arrived at "He couldn't find a single
one" so I can see what kind of proof you require? I would also like to
see you find the actual references for the following statement:
> Your insistence that people knowledgeable about Common Lisp pretend that
> the langauge has no flaws means you want us to appear to be stupid or
> liars.
I think I need to understand what your rather peculiar requirements are,
because it sure looks like you demand from others what you cannot and
have not been willing to do yourself. Why is this ethical of you? Why
does this ridiculous hypocritical stance of yours make you a person that
somebody should believe in any respect at all? Have you not demonstrated
that _you_ are a liar much more than you have demonstrated that I am?
According to your _own_ standards, we should assume that everything you
have said about me is a lie. I think that is frighteningly accurate of
you, but still it amazes me that you fail to understand the criticism you
must have read here about _your_ misrepresenting me. Oh, you probably
need references to be able to deal with facts. Dream on, hypocrite.
///
Sure. here's what I wrote in the message you replied to:
From now on please don't tell people what you *think* I said:
John Foderaro expresses a very strong hatred for the standard as
such, and the standardization process in particular.
Instead go to http://groups.google.com and find the exact message I sent and post the
exact text I wrote along with a link to the article so everyone else can see the
context. You can start with the message from which you derived the above statement.
So I'm asking that you produce postings or writings by me that would backup your
statement that I've been out trying to get people to disregard the standard.
> I would also like to
> see you find the actual references for the following statement:
>
> > Your insistence that people knowledgeable about Common Lisp pretend that
> > the langauge has no flaws means you want us to appear to be stupid or
> > liars.
>
That's fair. In this case there's lots of quotes to choose from but for simplicity
let's go to your original message that started this thread. You classify people as
sane or insane based simply on whether they agree with you on what you like in the
language:
erik:
Now, when I approach a Common Lisp vendor, I fully _expect_ him to share
my enthusiasm for the technology I want to purchase from him and probably
to exceed mine because he created something great for a great language
and since I have discovered both the great language, the great product,
and the great vendor, we should be able to share a _lot_ of enthusiasm.
If the vendor does not share my enthusiasm, there is something _wrong_
with him. If the vendor insults what I think is great, he is insane --
no two ways about that.
In other words you want vendors to mindlessly echo back your enthusiasm. You don't
want to hear what the vendor may have learned through years of experience about what
could potentially be a problem for you using the language in your project. You don't
want the truth. You can't handle the truth.
> In article <32084412...@naggum.net>, Erik Naggum wrote:
> >* Deepak Goel <de...@glue.umd.edu>
> >> Any pointers, anyone?
> >
> > http://www.paulgraham.com/popular.html
> >
> > A large number of strongly negative comments about Common Lisp that I can
> > see absolutely no reason for.
>
> I find that the paper makes a good points here and there, but overall
> it is irrational, sometimes to the point of being ridiculous.
If you follow his arguments, APL should have taken the world by storm.
--
Lieven Marchand <m...@wyrd.be>
She says, "Honey, you're a Bastard of great proportion."
He says, "Darling, I plead guilty to that sin."
Cowboy Junkies -- A few simple words
Hey,
I was wondering: how would you go about filling a PDF from Lisp?
Would you use a library like the one used by gv or xpdf or is there
a simpler way?
Thanks,
--
Jordan Katz <ka...@underlevel.net> | Mind the gap
Why do you keep telling people how much you dislike me? Do you think that there is
anyone reading this newsgroup who really cares about that? Don't you realize that it
reduces your credibility to near zero when you then make some statement about me
because people now see that the motivation for your post may not be to provide
information to the readers of this group but instead is just a lie to get back at me
for whatever it is that I did to you (which is still a mystery to me).
I agree with this. The the frequency with which this happens depends on
whether the abstraction was appropriate for the problem you are trying
to solve. Maybe one way to measure it is to think if the OS interface
abstractions will get in the way, _other_ stuff will also, causing one
to write very specialized code (eg: real time stuff).
CR> However, by their nature, it would seem silly to
CR> standardize on an interface given that to at least some extent
CR> there's a moving target.
I don't know why I didn't think to say this last night, but there is
POSIX at least which even NT+ Windows purport to support AFAIR.
CR> However, what would make me feel good is to see (public)
CR> debate on what a current interface would be like, just so that
CR> I (and others) can see what has been considered and rejected,
CR> and so that where there are good ideas others can use them.
I would like that also. Two things have come up relatively recently
in this NG that I remember: timer/timeout stuff, and event-driven
IO as opposed to multiple blocking threads. Maybe we could come up
with some small set of programs that expose those bits of OS-assisted
functionality to be rewritten in multiple implementations as a starting
point.
Also note that my feeble attempt to change the course of this thread
to something technical has failed, so maybe we should top post a new
thread and hope for interest there.
[...]
CR> There are several approaches that can be taken here. One is as
CR> a wrapper to exec() and friends, so that its signature would
CR> look something like:
CR> run-unix-program (path arguments &optional environment)
CR> Another approach could be to use system() (or /bin/sh -c);
CR> then run-unix-program would be like:
CR> run-unix-program (string)
CR> So far, so non-controversial.
Even then, I worry about details. At the lower level this is
traditionally done by fork+exec. Unless a variant of fork (vfork afair)
is used, you might actually be forking a huge process which
w/o overcommit might exhaust your vm. This is not necessarily a made-up
example, think of a long running AI-ish program that grows to 1gig and
then 'system's out a sendmail to let you know about progress...
CR> However, there's a certain
CR> amount of pain and suffering involved if you are porting
CR> between implementations; in particular, if you've used the
CR> first form and are trying to implement it in an implementation
CR> with only the second.
Yes, maybe in this case the thing to think about is whether or not
the Unix people were drunk when they came up with the 4(?) variants
of exec. Maybe that was the best compromise? I often find that bits
of odd looking functionality in syscalls/libc is actually necessary.
They may not be pure and elegant, but given what you are dealing with
(unix), they are not gratuitious monstrosities. Now, CL folks usually
have a pragmatic approach to elegance and minimalism as evidenced by
other useless threads here I won't name. Maybe that approach should
carry over?
[good stuff deleted]
CR> The point I'm trying to make is that a certain amount of
CR> public discussion on these non-standard features (not just OS
CR> interaction) might be beneficial, both for implementors and
CR> users, even if it's only to the level of making some
CR> suggestions for differences to expect between :unix and
CR> :windows on the *features* list.
I agree 100%.
cheers,
BM
The only one of these people pay for, and probably the only one acceptable
for developing more than cgi-like applications or doing glue-work in a
reasonable number of organizations, is Smalltalk. At my last count there
were six commercial vendors, plus Squeak - a product available for free but
built by a large team of full time professionals, and relatively easy to
port and maintain. Ocaml is about equivalent to Squeak (and there are
non-Ocaml commercial ML's). Perl, Python and Ruby have adequate,
well-supported, portable, constantly maintained implementations that make up
for the lack of a commercial system. (Plus for several of them you can call
on ActiveState etc for support, if your tastes run that way.) Even Haskell
has university funded teams updating and fixing compilers. As good is it is
as a language, Lisp is way behind on these issues, which do figure in a lot
of organisations decision making.
-Jonathan Coupe
> As an outsider looking in I see an amazing tool and language that is
> not supported by much of its users which to me makes no sense. If you
> don't like it why do you use it? And I hope the sparks that are there
> do start to grow and become a fire. Personally when I know enough
> about the language enough I am going to be doing all I can to improve
> the libraries out there where I can, I have never been so caught by a
> language and I would consider it a major tragedy that it disappeared
> due to lack of support.
Maybe they are bunch of old foggies who forgot how to laugh!
What you say is definitely true and I am glad you are one the people who has
made a sincere effort to learn Lisp. The main fret in this thread is about
getting other people to support Lisp's use in (money-making) circumstances.
I did some work awhile ago for one of those dot-coms. Just five people, two
programmers (one guy doing dynamic web-page generation in PHP, the other
using Java to build tools to populate the database), the owner, a
documentator and me (part-time project manager/filler-in). There was a
part do be done that had automatic newsletter generation from a database and
eventually into PDF/Postscript files. The guy doing that part spent 6 weeks
using PHP and in that time had nothing to show for it. The endeavour was
next to failing, so I thought, hey, I will try to do that part in Lisp
(originally ACL/FreeBSD then CMUCL/FreeBSD). One week later (40 hours in
total) I had the first version running, complete with a web interface to see
the generated newsletters. I showed the work to the others in the group and
the other programmer looked at it and said, "Thats good, if you had to do it
over in Java it wouldn't take much time at all". Now why would he say that?
He's been a programmer for a long time. He has seen Lisp (he loves Emacs!).
The primary reason I believe is that he was trying to get more money out of
the owner by using things that
1) Are preceived as awesome technology, like Java, so they will pay more for
a precieved race-horse.
2) Which stretch out the job, so you have more chargable hours
Guess what? The company did not deliver then folded. Wasted time, wasted
effort, I just pity the owner who shelled out for it from his own pocket.
Lisp is really awesome. But there is story I have to relate..
I worked as a construction coodinator earlier in my life. We subcontracted
out the welding of a new pipeline system for delivering natural gas. This
company hired this old experienced welder who on his first morning welded 13
pipe joints. That afternoon the other welders approached him and pointed
out the average (and acceptable) number of welds to do in the morning was 2.
The next day he was gone.
The beef is not really with Lisp, its with people.
Wade
Tim Moore wrote:
> On 2 Sep 2001, Erann Gat wrote:
>
> Maybe we're too busy writing Lisp programs to take silly polls?
>
> I use Common Lisp to do my income taxes. This year I had work under way
> to automatically fill out the IRS pdf forms, but then I saw how much I
> owed and lost interest.
>
> Tim
Tim:
This looks like an interesting thing to do. Would you mind sharing
how you did it? Even better, can we get handle on the code
(or parts fo it) if it is not part of any proprietary product
you are developing.
Thanks
srini
I think Erik was looking for mindful agreement and enthusiasm. Every
vendor I have worked with will always try to put there products in the
best possable light and this is the 'sane' thing to do. If you do not
do this then it is not sane or insane. I am doing this from what I
rember of what he wrote and the above quote in this thread and any
mistakes are mine.
I just took a look at opensource.franz.com/postoffice project and when
looking at the source(imap.cl and smtp.cl) and saw the 'if*' macro in
the code for both files, with no pointer to an auxilary file where it
is defined. Now I go to the hyperspec and look for 'if*' and its not
there and I am using cmu for example and it blows up. Here is the only
pointer to how to try to figure out where is this odd 'if*' thing:
imap.cl:;;
imap.cl:;;- This code in this file obeys the Lisp Coding Standard
found in
imap.cl:;;- http://www.franz.com/~jkf/coding_standards.html
imap.cl:;;-
so I finaly go and read the coding standard in hopes of finding a url
or pointer to fix my problems. Mow the first sentence of the first
rule, on a document on franz's website starts like this:
Use if* instead of the bogus-three-conditionals: if, when and unless
This is an odd way for franz to show that they support common lisp and
would at the very least make me look for someone else to give my money
to or just pick another language for the project. That you put it up
is one thing, that your management lets it stay up in its current form
is realy amazing to me. This document bites the standard that feeds
franz and you. Now 2 lines down you insult my inteligence with the
following:
Glancing at the form (if aaaaaaaa bbbbbbbb cccccccc) you tend to see
that three values are being evaluated in order: aaaaaaaa then
bbbbbbbb and then cccccccc
What I think a incomptent or better lisp programmer would have figured
out that (if a b c) is a special form and that only b or c is
evaluated based on the truth value of a, this is exactly how it worked
in basic in highschool and pascal, cs101, in college. Currently I am
an incomptent lisp programmer, I am trying to fix that though. I will
skip commenting on rule 2 because I do not know enough to have an
oppinion yet. On to rule 3 here is one sentence from it:
At the same time, don't obscure the important comments by surrounding
them with trivial comments.
and here are some comments from imap.cl:
imap.cl:136: ((mailbox-name ; currently selected mailbox
imap.cl:141: ;; string that separates mailbox names in the
hierarchy
imap.cl:145: ;;; these slots hold information about the currently
selected mailbox:
imap.cl:147: (message-count ; how many in the mailbox
imap.cl:151: (recent-messages ; how many messages since we last
checked
imap.cl:155: (uidvalidity ; used to denote messages uniquely
imap.cl:160: :accessor mailbox-uidnext ;; predicted next uid
imap.cl:163: (flags ; list of flags that can be stored in a
message
imap.cl:167: (permanent-flags ; list of flags that be stored
permanently
imap.cl:171: (first-unseen ; number of the first unseen message
imap.cl:210: name ;; often the person's full name
imap.cl:212: mailbox ;; the login name
imap.cl:213: host ;; the name of the machine
Some of these seem trival in the extreme, line 213 for example. If
your standard is so good why is it not followed by source files that
have it listed in there comments for reference. One last thing when
you have code that is diffacult to read you should fix the code not
explain it. I have many english teachers tell me not to explain your
paper but to write it clearly in the first place. Using excessive
comments is telling me about your code.
I would like to thank franz for writting smtp.cl and imap.cl I have a
project that I would use it on after I get all the if* stuff out of
it.
And I think that everyone has the right to use whatever macros they
want. But with that said from looking at it I think cond is much
better to look at then your stuff. I always thought a case,
switch. cond statement was MUCH clearer then a long series of nested
if statements to read.
One last thing in the source code please put a reference to where to
get the macro source, just for clarity sake.
marc
There is a difference between showing people that they can define
their own little convenience macros, and publically calling upon
people to use a particular macro as a replacement to standardized core
language constructs, claiming along the way that those constructs are
bogus, with little to no objective evidence.
There is a reason that nearly every language in existence standardizes
a certain amount of basic control-flow operators, even if it could get
away with far less due to the existence of syntax-extension
mechanisms.
There are reasons for including such constructs as IF, WHEN, UNLESS,
CASE, TYPECASE, etc. in the core language standard, even if all of
them can just as easily be defined by each user with macros based on
COND. And that reason is _WIDE READABILITY_! IF, WHEN and UNLESS
aren't readable based on their own merits, or not. They are readable
by the whole community because they are part of the shared
understanding, because they are part of the standardized language. If
a reader sees an IF, WHEN or UNLESS, they don't have to worry about
the exact semantics those constructs might currently have, because
the exact semantics have been prescribed, once and for all, in the
ANSI CL standard, and are not subject to changes.
If we follow down the John Foderaro route of everyone inventing their
own basic control-flow operators, we will soon have 10s of IF*, BIF,
IFF, etc. operators, each one with their own little syntactic sugar,
and their own little semantic idiosynchrasies, understandable only
upon studying yet another specification (if there is one, besides the
implementation code).
And since basic control-flow operators are central parts of any
language, what this will basically mean is that we will have 100
twisty little Common Lisp dialects, all different. We've been
there before, when we had 10 industrial-strength Lisp dialects, all
differing in little details even on the constructs they shared. This
is something that Common Lisp was created to avoid happening again.
Even with C's pre-processor macros it is possible to do
#define BEGIN {
#define END }
or even
#define IF(x,y,z) ((x)?(y):(z))
But no serious C user will ever contemplate doing such a fundamentally
stupid thing, let alone any expert C user. Try posting such
suggestions on comp.lang.c, and you will get a serious lecture as to
why this would be fundamentally stupid, and don't you want to go over
there to comp.lang.pascal, or wherever you came from?
Yet somehow over here in Common Lisp land, we are supposed to hail
people who publically advance such dubious proposals, outside any
relevant standardization effort, as saviours of Common Lisp, and
demonstrators of its power?
And for what gain are we deliberately risking the splintering of
Common Lisp into mutually incompatible sub-dialects? If this was some
fundamental advancement, like e.g. a fully reflective Lisp system, I
could maybe see the sense of this. But for an improvement that (if it
was there to begin with), can only be described as a small,
incremental improvement, I just cannot see how it would be wise to
incompatibly change the status quo (and incompatible change is needed,
since the supposed readability of IF* can only be realized if it
supplants IF/WHEN/UNLESS in time). And the improvement (again I
really doubt there is a general improvement) can only be described as
light, since it seems that many, many programmers have been able to
read code using IF/WHEN/UNLESS without undue problems, it seems,
otherwise we'd probably have regular criticism of IF/WHEN/UNLESS on
c.l.l all the time.
I'm afraid it seems to me that certain members of the CL community
seem to have not a clear enough understanding of the fundamental
values of a standard, and a community-wide consensous, prefering
instead to go off on a wild chase of their own personal ideal Lisp.
This seems quite unlike most other language communities I've
encountered.
Regs, Pierre.
--
Pierre R. Mai <pm...@acm.org> http://www.pmsf.de/pmai/
The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We cause accidents. -- Nathaniel Borenstein
Can I just mention I do love Common Lisp and that I'm trying to get
more students and other people to at least _try_ it.
Paolo Amoroso <amo...@mclink.it> writes:
> Another project by some of Robert's students is the Eclipse/CLWM window
> manager:
>
> http://www.emi.u-bordeaux.fr/~boninfan/TER
> http://www.emi.u-bordeaux.fr/~hatchond/Eclipse
Can I just mention that the Eclipse guy found a bug in CLX that
probably has been in there since the dawn of time. Nobody ever tried
to write a window manager with CLX it seems :-(.
Anyway, the fix is in the new-CLX CVS tree on sourceforge in the
cclocc project. I've been trying to rejuvenate CLX by porting it to
the cclan/port interface, so far it works on cmucl and should on
ACL, LW and clisp. It features XAUTHORITY support and using PF_UNIX
sockets.
Patches are welcome.
> I profit by the occasion for thanking all of you.
McCLIM is maybe the most exiting thing happening in the Common Lisp
work for the last few years...
(with-mode (:dark)
Can I just mention that it is strange how much people complain that
nothing is happening and yet I always see only the same brave souls
on cliki, cclan, cclocc, McCLIM, etc. Why this indifference? Why
this complaining without taking the situation in hand? I think the
agol languages has succeeded. At least in pulling away most of the
people with some energy left...)
Groetjes, Peter
--
It's logic Jim, but not as we know it. | pvan...@debian.org
"God, root, what is difference?" - Pitr|
"God is more forgiving." - Dave Aronson| http://cvs2.cons.org/~pvaneynd/
> BUT I still think the "simple interaction with the OS" argument is valid.
> It's still less painful to use perl for a lot of these tasks, and that's
> a real shame.
Because "interaction with the OS" isn't the "simple" problem some
people here think it is. I'll use Unix for my example since I don't
know enough about Windows but I assume the problems are similar or
worse.
Writing a low level wrapper around most of the POSIX interface isn't
difficult when you know the FFI of your implementation a bit. It's a
big job and it's tedious. But all that buys you is the ability to
write C with parentheses. Consider the simple problem of listening to
a port on a service. Given your POSIX wrapper you can write this in a
sequence of calls to getservbyname/socket/accept/bind/listen and I'm
probably forgetting some. All with weird encodings of error situations
etc. What you really want is something like LispWorks
COMM:START-UP-SERVER. Designing these chunks of functionality with
usable interfaces and decent error handling is a lot of work.
In article <slrn9p7f72...@oscar.eng.cv.net>, ma...@oscar.eng.cv.net says...
> This is an odd way for franz to show that they support common lisp and
> would at the very least make me look for someone else to give my money
> to or just pick another language for the project.
You've read the web page describing the coding standards but apparently missed this
sentence at the beginning:
The opinions in this document are those of its author (john foderaro)
and may or may not reflect those of anyone else at Franz Inc.
These are my opinions. All mine. They would be my opinions if I worked for any
company or university. I would not work for a company that didn't allow me to have my
own opinions on things and neither should you.
My opinions are based on 23 years of programming experience in Lisp. That doesn't
mean that you have to agree with them but at least it should cause you to pause and
think for a bit. I don't think that you gave what I wrote much thought at all.
I've contributed a lot of Lisp code to the community even before the term opensource
existed. What have you contributed? Suppose I was looking for a module to do X and
found that you had an opensource version. You sent it to me and I found that it was
using a private interation or condition macro of your own design. I sent you a letter
asking for a copy of that macro and you emailed it to me. What should I then do?
Post something in comp.lang.lisp saying how you're denegrating the Common Lisp
standard by inventing your own control macro? That's not what I'd do. I'd send you a
letter thanking you very much for the code. Then I'd congratulate you for being a
Lisp programmer and realizing that Lisp is a language designed to be extended.
If you look at one of the programs I've contributed (AllegroServe) you'll find a
number of ACL only macros. A quick grep reveals: excl::atomically, excl::fast,
excl::with-dynamic-extent-usb8-array. Why don't you now get on my case for including
uses of these macros and not giving you the source code for the macros? Could you
stand to use AllegroServe because it included these macros or would you have to remove
them before using it? The alternative I'd suggest is rather than get
confrontational you should send a friendly letter to the author of the program and say
"I'm trying to run your program X on Lisp Y and it doesn't include macro Z could you
tell me what that macros does or better yet give me the source?" That's a much
better solution than telling someone who is doing you a favor by releasing his code
for free to change his code to suit your personal coding standards.
How dare you insinuate that I'm not enthusiastic about Common Lisp? The programmers
working in companies producing commercial Common Lisp systems are the most
enthusiastic people about Common Lisp you will ever find. These people know that they
are the last thing standing in the way of the Lisp language returning to its position
of an academic oddity. It takes a tremendous amount of work to maintain Lisp while
the computing world changes rapidly. Here it is a holiday in this country and while
this is a day off at Franz and it's a beautiful sunny day ouside there has been a
steady stream of email all day between developers about lisp-related issues.
-john foderaro
franz inc.
How do you think that we got to where were are now with the current set of control
form macros? Were they spontaneously created by the standards committee? No.
For the most part all those forms existed in pre Common Lisp lisps. They were
invented by people in those lisps to solve a need.
Not all needs are met by the standard common lisp macros. For example there's a
dolist but there's no dovector to map over items in a vector.
> If we follow down the John Foderaro route of everyone inventing their
> own basic control-flow operators, we will soon have 10s of IF*, BIF,
> IFF, etc. operators, each one with their own little syntactic sugar,
I'm never swayed by this scare tactic argument. If you can prove this statement I'd
like to see it. As I said in an earlier message I've programmed in Lisp for 23 years
but have only found it necessary to create one control macro (If in Franz Lisp, if* in
Common Lisp). I suspect that most people will create no control macros but some
people will create some great control macros that will make us think "how could we
have lived without this for so long?". At that point the Common Lisp community will
make an evolutionary step forward (and this would not in any way affect the standard
since the ability to define macros is part of the standard).
We can't live in fear of what may happen and let that control us to the extend that it
inhibits growth.
> Tim Moore <mo...@herschel.bricoworks.com> writes:
> >
> > I use Common Lisp to do my income taxes. This year I had work under way
> > to automatically fill out the IRS pdf forms, but then I saw how much I
> > owed and lost interest.
>
> Hey,
>
> I was wondering: how would you go about filling a PDF from Lisp?
> Would you use a library like the one used by gv or xpdf or is there
> a simpler way?
The approach I was taking was to generate FDF for a given PDF form. FDF
is a very simplified version of PDF that enumerates form field names and
values. You can (on Unix, at least) use the Adobe Acrobat reader to print
a PDF with form field values supplied by an FDF document.
From a Lisp point of view, generating the FDF is pretty trival; it's plain
text with a regular syntax. FORMAT is your friend.
Figuring out the field names and meanings is very tricky; I mostly did
that by writing a Perl script to extract the field names, then by hand
generating a simple FDF for each field, then seeing how the resulting PDF
printed. This was a huge pain; a PDF parsing library might have made this
easier, but you still have to figure out what each field "means"...
Tim
I do not care about a PC disclaimer, my point was and is franz is
giving your claim's weight because it is on there web site. This is
where I would expect to see stuff about how CL is wonderful and ACL is
even beter then that. Instead I see your poorly thought out and
fundmentaly flawed rant about CL. If you must do less then optimal
things you should not do them at work and franz's web space is part of
your work enviorment.
>
> These are my opinions. All mine. They would be my opinions if I worked for any
> company or university. I would not work for a company that didn't allow me to have my
> own opinions on things and neither should you.
>
Part of being a good employee is to not harm your employer. What you
have done is harm your employer with this stupid and insulting coding
standard and wierd if* macro( yes it is wierd and looks ugly) is to
make me think if this is who they show the world who do they keep
hidden?
> My opinions are based on 23 years of programming experience in Lisp. That doesn't
> mean that you have to agree with them but at least it should cause you to pause and
> think for a bit. I don't think that you gave what I wrote much thought at all.
>
If you want to start a civil discussion then start it in a civil
manner, your coding standard is rude, condisending and insultiong. Why
do think that being a asshole in writting for all the world to see and
biting the hand that feeds you should make me think you are worth
listening to? I tend to judge people by the quality of there writting
on usenet, its all I have, and by that yard stick you are IMO not
worth the effort to take seriously. You do not have the saving grace
of being correct in your thoughts. I went to your home page and there
were no links just "jkd styff" and nothing else, www.franz.com/~jkf .
> I've contributed a lot of Lisp code to the community even before the term opensource
> existed. What have you contributed? Suppose I was looking for a module to do X and
at the present time nothing. But with that said it does not change the
fact that it was a stupid page that does a disservice to the CL
community and to your employer.
> found that you had an opensource version. You sent it to me and I found that it was
> using a private interation or condition macro of your own design. I sent you a letter
if I put up a package I would hope to do a complete job of it, ie to
get this to work you need this file also in the comments at the top of
the file or a tar file with everything in it that you need including
any custom stuff that is neded to support the other stuff.
> asking for a copy of that macro and you emailed it to me. What should I then do?
> Post something in comp.lang.lisp saying how you're denegrating the Common Lisp
> standard by inventing your own control macro? That's not what I'd do. I'd send you a
> letter thanking you very much for the code. Then I'd congratulate you for being a
> Lisp programmer and realizing that Lisp is a language designed to be extended.
>
extended not mutated/fragmented, your if* in code put up as something
that franz is giving to the CL community says among other things that
your convienence is more important then franz's adhearence to the CL
standard and this is bad in s company that's product is suposed to
fathfuly reproduce the standard and not gratuitisly ignore parts of it
whenever they feel/you feel like it.
> If you look at one of the programs I've contributed (AllegroServe) you'll find a
I looked at it and if I remember correctly it is copy right franz
inc. If this is true then did you donate it to franz or was it part
of your job?
> number of ACL only macros. A quick grep reveals: excl::atomically, excl::fast,
> excl::with-dynamic-extent-usb8-array. Why don't you now get on my case for including
> uses of these macros and not giving you the source code for the macros? Could you
well IFF you insist I can, but I realy have better things to do. Also
are you planning on responding to KMP's reply to why the if* macro is
a bad idea, he had a much better argument including been ther don that
it stank and CL was suposed to fix it. Since his message was posted
before mine I would expect you to have a repled by now or are you
being selective in who you respond to? After all I am unknown and
Erik has a bunch of people who do not like him that you can tap into
for support.
> stand to use AllegroServe because it included these macros or would you have to remove
> them before using it? The alternative I'd suggest is rather than get
> confrontational you should send a friendly letter to the author of the program and say
> "I'm trying to run your program X on Lisp Y and it doesn't include macro Z could you
> tell me what that macros does or better yet give me the source?" That's a much
> better solution than telling someone who is doing you a favor by releasing his code
> for free to change his code to suit your personal coding standards.
>
again is it a favor or part of your paid work for franz? If it is the
latter then you should only deviate from the standard when you must,
networking come to mind, not where you want, if* cones to mind.
>
> How dare you insinuate that I'm not enthusiastic about Common Lisp? The programmers
> working in companies producing commercial Common Lisp systems are the most
> enthusiastic people about Common Lisp you will ever find. These people know that they
well you do hide the fact that your the saviors of the modern world
quite well, does anybody recognize you with your glasses on?
> are the last thing standing in the way of the Lisp language returning to its position
> of an academic oddity. It takes a tremendous amount of work to maintain Lisp while
> the computing world changes rapidly. Here it is a holiday in this country and while
I am sure it does, so why add more gratuitus ans unneeded changes on
top of it?
> this is a day off at Franz and it's a beautiful sunny day ouside there has been a
> steady stream of email all day between developers about lisp-related issues.
>
And I am in the offfice also and have been working on a project all
weekend that I was told about on thursday that goes live on tuesday
and your point is?
> -john foderaro
> franz inc.
>
Since there is no disclamer on this message I have a question for
someone that you work for, is this an offical posting from franz?
marc
So quoting me is too much for your need for references? *snicker*
> I'm not the one who made the big deal of that document on if*, you are.
Oh, right. Sorry. John Foderaro should be allowed to criticize
anything, but criticize John Foderaro, and you are his enemy. Remember
that line about "enemy list"? Could you cough up a reference to that
list, please? I regret that I have temporarily taken my machine off the
web for security reasons, but I can assure you that no such list exists,
either published or unpublished, but still John Foderaro accuses me of
having one and being on it. So, I should say that you are the one that
made such a big deal of being my enemy. Does this help anyone understand
how you have reacted from day one? It explained a lot to me, at least.
> You took it as an attack on the Common Lisp standard.
It is not? Geez.
> In fact it is just the opposite.
Oh, I see. I have not been attacking you, either, John Foderaro, in
fact, just the opposite. You see that now, too, I hope.
> It shows that Common Lisp gives you the flexibility to define forms that
> make your code easier for you to read.
Why did you have to knock the standard conditionals just to say that? I
have asked you repeatedly, yet you never answer, so I guess you cannot
answer (in the spirit of your own style of argument, I am allowed to
assume something from a lack of answer, right?), whether you could have
expressed your new, f*king brilliant IF* shit in positive terms that did
not reflect your stupid personal hangup with aestetics in the standard.
> Java doesn't allow that. C and C++ give you a very weak macro extension
> language.
Who cares? Are you using Java a lot? Last I heard, you rant even more
irrationally about Java than about the "braindamage" in Common Lisp.
I happen to like Java, too. That is probably because I have figured out
that it sometimes makes sense to appreciate things on their own terms, as
opposed to some completely different terms that makes everything look bad.
I have certainly not stopped liking C. On its own terms, it is a good
language. There are a lot of things in C that I would like to see in a
Common Lisp system. Access to machine words and the machine operations
on them is the only way to achieve high efficiency in some algorithms.
Writing sufficiently complex code that it needs macros in C is a mistake
-- if you need that, write in Common Lisp and generate the code you want;
C is not that hard to generate human-readable code from.
///
Wrong. _Everybody_ else understood something else by what I said.
> You don't want to hear what the vendor may have learned through years of
> experience about what could potentially be a problem for you using the
> language in your project. You don't want the truth. You can't handle
> the truth.
If you believe this idiotic crap was uttered by anyone but yourself, you
are quite simply insane, John Foderaro, and nothing can be done about you.
///
During this on-going discussion about if* I have had the oppurtunity to "try
it on for size". The thenret control statement I found unatural and took
some getting used to. But all in all I have found it a fine macro. Of
course its "just" an if/then/else/elseif construct.
I totally agree with the living in fear bit. I would not have learned CL if
I had lived in fear of learning yet another programming language.
Wade
How much thought do you expect anyone to give a paper that calls itself
"lisp coding standards" and which contains two grave insults and a silly
comment on comments that is completely useless? And this is the result
of 23 years of programming in Lisp? Sheesh!
> I've contributed a lot of Lisp code to the community even before the term
> opensource existed. What have you contributed?
Is this intimidation tactic a way of saying that you are _entitled_ to
destroy and denigrate Common Lisp, but those who criticize you for it are
not entitled to criticize because of their lack of contributions? Where
do you _get_ all this arrogance? What are you trying to defend?
> Post something in comp.lang.lisp saying how you're denegrating the Common
> Lisp standard by inventing your own control macro?
Why are you constantly _not_ getting that it is your very unintelligent
insults that cause the majority of the hostility and not your very silly
macros?
> Why don't you now get on my case for including uses of these macros and
> not giving you the source code for the macros?
Because it is your gratuitous insults that get people on your case, not
your macros. How _can_ you fail to understand this? You act like a
person who _knows_ he is guilty as sin and tries very, very hard to
pretend he has done nothing wrong by trying to deflect all criticism.
So many people have pointed out to you that this is about your attitude
that it _must_ be a matter of will that you do not get it. Otherwise, 23
years of experience with that level of inability to understand things is
not really worth a lot.
> That's a much better solution than telling someone who is doing you a
> favor by releasing his code for free to change his code to suit your
> personal coding standards.
I remember three distinct occasions when I mailed real bug-fixes to your
code and received _very_ hostile comments back that you could not use it
because it used loop and if and when and unless. I believe at least one
of those incidents prompted your writing your digusting Lisp Coding
Standards document. Suffice to say that from then on, I viewed your
ability to think straight to be permanently impaired. The bugs were
still unfixed for at least one release, by the way, and there are still
bugs in that code: The symbol printer and reader in Allegro CL does not
conform to the standard and violate print-read consistency expectations.
After having tried to explain to you how you could have avoided those
bugs, you simply failed to implement them because I use a much richer set
of conditionals in Common Lisp than you do. I do not string a whole
bunch of if* together in an unreadable mass of spaghetti code, I choose
the most readable form with care. Therefore, I manage to find and fix
such bugs only after converting the if* mess to something readable, while
your code has been buggy for over a decade, but you do not wany my fixes.
In other words, I have solid evidence that your personal coding standards
are much more important to you than working, conforming Common Lisp.
> How dare you insinuate that I'm not enthusiastic about Common Lisp?
Try reading your own language. Try remembering how you react when people
say that upper-case names symbols are required the standard. Try
actually _answering_ some of the many questions you have been asked, to
which positive answers would really have helped, while double negatives
really do not help at all. Instead of attacking people with the above
negative, try writing something _positive_ for a change.
> The programmers working in companies producing commercial Common Lisp
> systems are the most enthusiastic people about Common Lisp you will ever
> find.
I would have expected some humility in such a statement, such as at least
including a "probably" or "in my experience". Making it sound like a
universal truth means it can be shot down as false or dishonest with a
single counter-example. Such a universal statement is also an insult to
the many people who clearly exceed you in terms of enthusiasm and a
strong reason not to work with you. This is probably what you want.
The reason I have not applied for a job at Franz Inc. and probably never
will is that your statement is manifestly untrue. A few people at Franz
Inc. have really gone out of their way to destroy the credibility of the
standard, imply very strongly that you are in a market position where you
can dictate the standard and lock people in. Most of them fortunately
quit and others have assured me that they really had no effect on policy,
but they got _hired_. I would have loved to work full time with most of
your staff, but you, in particular, and a few others, have really managed
to rub me the wrong way, and you, in particular, have done everything you
can to make my insistence on conformance be unwelcome and result in no
action when I point out conformance problems. Your insane ranting here
is not doing anything to help this, and your idiotic "religious zealot"
stamp because I do not approve of your if* stunt and particularly do not
approve of your constant need to denigrate the standard and the people
behind it. I have very high respect for some of the people you have
spent _hours_ insulting to my face. I have _none_ for you, anymore. You
have done more to destroy that respect in this thread than anything else
you have done, however, including your pathetic passive-aggressvieness,
your dishonesty, and your personal need to misrepresent me and _pretend_
that you do not have a clue what I am talking about.
I would have thought the most enthusiastic people about Common Lisp I
would ever find would be a lot smarter about expressing it positively,
and _definitely_ not so pathetically self-defensive about his own
destructiveness as you are.
> My opinions are based on 23 years of programming experience in Lisp.
I _really_ hope I have had more to contribute by the time that I have as
much experience than some silly rewrite of cond and personal distaste for
a powerful iteration macro. Most of the other people who have had in
excess of two decades of Lisp experience have been fantastically helpful
to me and have imparted so much wisdom about the language that I feel
that my 6-8 years of Common Lisp and Emacs Lisp have been much more,
although I met my first Lisp in 1978 or 1980. That is part of the reason
I feel disappointed, and more than that, almost betrayed, when someone
with so much more experience chooses to sully the language and present
his experience as insulting comments about standard features. (Again,
never mind the infinitely silly if* macro -- it is of minimal material
consequence compared to the insulting attitude -- it makes you look
really ignorant and _far_ from really experienced.)
///
> It pained me to read your message. You're progamming in Lisp but
> you are still thinking like a C programmer. A C programmer can't
> extend the syntax of the C language. Neither can a Java
> programmer. [A C++ programmer can extend operators but this
> often makes the code just more unreadable and undebuggable].
So if I read your argument correctly, anyone who thinks it is a bad
idea to replace perfectly good standard constructs in CL with
different, unstandardized personal macros is still thinking like a C
programmer? Oh my god!
Just because one can do certain things in a language doesn't mean it
is a good thing to do in all cases. It somehow seems to me that this
is a concept totally alien to you.
> How do you think that we got to where were are now with the current
> set of control form macros? Were they spontaneously created by
> the standards committee? No. For the most part all those forms
> existed in pre Common Lisp lisps. They were invented by people in
> those lisps to solve a need.
Of course they weren't spontaneously created by the standards
committee (neither the ANSI working group, nor the orginal ad-hoc
standardization group that led to ClTl1 and later morphed into
X3.J13), and it would indeed be to their discredit if they had done
this in large amounts. That's not what standards are for, as you well
know. Standards are for exterminating minor differences where broad
consensous can be reached on infrastructure, not for inventing the
best control-flow operator in the world.
And yes, lots of slightly differing control-flow operators where
invented, and re-invented in many dialects. And that was fine, when
the new operator solved a real need that was otherwise unfulfilled,
and it was sad when people solved similar needs slightly differently
in different dialects, making knowledge (much more so than code) less
portable than it could have been.
And that's why Common Lisp was such a huge step in the right
direction, by canocalizing lots of those operators into one form.
> Not all needs are met by the standard common lisp macros. For
> example there's a dolist but there's no dovector to map over items
> in a vector.
And no-one would be giving you any kind of resistance if you had
implemented dovector. I can't believe you don't see a difference
between creating a new control-flow operator for some functionality
that is not covered by the standard, and replacing standard operators
with your own personal definitions which are functionally identical,
only offering a slight syntactical variation, especially if you then
go on to call on people to replace uses of if/when/unless with if*
unconditionally.
Exactly because CL gives you the power to extend the language, and
create new languages embedded within/replacing the standard language,
it is even more important to use that power wisely.
Even C has enough power to replace certain syntactic constructs of the
language with your own "improved" versions, as I mentioned in my
posting. And even this limited power can be thus abused, in the name
of personal persuasions of what constitutes readability. But in that
community I have yet to encounter anyone with any kind of experience
seriously suggesting that such a thing is something desirable.
> > If we follow down the John Foderaro route of everyone inventing their
> > own basic control-flow operators, we will soon have 10s of IF*, BIF,
> > IFF, etc. operators, each one with their own little syntactic sugar,
>
> I'm never swayed by this scare tactic argument. If you can prove
> this statement I'd like to see it. As I said in an earlier message
> I've programmed in Lisp for 23 years but have only found it necessary
> to create one control macro (If in Franz Lisp, if* in Common Lisp).
What kind of proof do you need? We already now have IF* and if. The
reason we don't have 10 IF*'s lies in the fact that most CL users are
more prudent in the use of their powers than you seem to be. If
everyone followed your example, we _would_ have more syntactic sugar
macros, because it is unreasonable to assume that you are the only
person who is dissatisfied with some construct in the language (or in
your words considers some part of the standard "bogus").
We have seen the consequences of this in stuff that hasn't become part
of the standard: Just take a look at all the ITERATE macros that were
(mostly) created as a reaction to complex LOOP. To the best of my
knowledge there are at least 4 slightly different ITERATE constructs
in current use out there, and I haven't looked at all widely for others.
I contend (and of course I cannot prove this in any rigorous sense of
the word, but who are you to call for proofs, when the best of
evidence you seem to feel necessary to underscore your dismissal of
IF/WHEN/UNLESS are completely subjective comments) that the fact that
we haven't seen similar things happen for constructs that are part of
the standard is that most CL users do in fact understand the values of
a commonly shared _basic vocabulary_, and have refrained from creating
their own variant macros.
> I suspect that most people will create no control macros but some
> people will create some great control macros that will make us think
> "how could we have lived without this for so long?". At that point
> the Common Lisp community will make an evolutionary step forward (and
> this would not in any way affect the standard since the ability to
> define macros is part of the standard).
You still seem not to grasp the difference between inventing a new
control-flow operator like e.g. WITH-STATE-MACHINE, or PATTERN-CASE
(to name just two that I personally "invented" -- along with scores of
others, I'm sure -- for certain libraries[1]), that can stand besides the
standard-provided basic operators, and replacing one of the most
fundamental (by your own reasoning in coding-standards.html[2])
control-flow operators in the language standard with your own personal
version?
Can you imagine that there is a difference between inventing a new
word for a new concept for which no word already exists in a natural
language, and insisting on replacing 'if' by 'fi' in all your natural
language sentences? And this isn't less of a problem in CL just
because you can automatically map the semantics of fi onto if via
macros, because macro-expansions are _not_ part of the readability of
code, unless as a last resort, if all else fails, on par with
reverse-engineering.
> We can't live in fear of what may happen and let that control us to
> the extend that it inhibits growth.
We can't let blind belief in the obvious superiority of our own ideas
blind us from the likely consequences of our deeds.
But somehow I'm slowly coming to the conclusion that you don't want to
understand the criticism aimed at your stance, but would rather prefer
to dismiss it out of hand, calling everyone who doesn't agree that the
introduction and promotion of IF* as a replacement for IF/WHEN/UNLESS
is a completely grand idea, as religious zealots, thinking like C
programmers, scare mongers, or whatever, and debating straw-man
arguments that bear little to no resemblence to the arguments that
people really are levelling against your stance.
Regs, Pierre.
Footnotes:
[1] See also my response to a recent request for meta-programming and
language creation examples in CL for another example.
[2] http://www.franz.com/~jkf/coding_standards.html
Because you have made your dislike for me the core your responses to me.
Remember, _you_ invited people to take part in a popularity contest with
the clear aim of defeating me through misrepresentation of what I said.
Such behavior pisses me off tremendously. I merely followed up on that
because it would be a _disaster_ if you won.
> Do you think that there is anyone reading this newsgroup who really cares
> about that?
Yes. You, for one. Those who want to vote with their wallet to remove a
cancer from the Common Lisp community.
> Don't you realize that it reduces your credibility to near zero when you
> then make some statement about me because people now see that the
> motivation for your post may not be to provide information to the readers
> of this group but instead is just a lie to get back at me for whatever it
> is that I did to you (which is still a mystery to me).
Er, _what_ was it that I should realize in that garbled sentence?
If something still remains a mystery to you, talk to your colleagues.
Several of them got the point quite early, while you keep _not_ getting
it on purpose, or so it seems.
///
Remember, due to your bias against me (how many ways have you told me you hate me in
the last week?) and your many misrepresentations of things I've said, we agreed that
you would not speak for me any more and would instead just quote me and give the
context for that quote.
Please now provide the quotes which show me insulting people.
> I remember three distinct occasions when I mailed real bug-fixes to your
> code and received _very_ hostile comments back that you could not use it
> because it used loop and if and when and unless.
Again we will have to assume that this is yet another lie unless you provide the
proof. If you can give the time of the supposed response from me and the subject of
the message I can attempt to locate it in our support archive and post it for all here
to see and judge if it's "_very_ hostile".
> Therefore, I manage to find and fix
> such bugs only after converting the if* mess to something readable, while
> your code has been buggy for over a decade, but you do not wany my fixes.
please post the letter from me refusing your fixes.
Now do you understand? Make no statements about me unless you can substantiate them.
Otherwise the good people who read this newsgroup will think that you are wasting
their precious time persuing your own personal vendetta
> It pained me to read your message. You're progamming in Lisp but you are
> still
> thinking like a C programmer. A C programmer can't extend the syntax of
> the C
> language. Neither can a Java programmer. [A C++ programmer can extend
> operators but this often makes the code just more unreadable and
> undebuggable].
That is true - but one of the reasons _I_ do not like IF* is that it leads
to code that looks astonishingly like C...
(Look at AllegroServe for what I mean)
This does not have to be a bad thing at all - but it is simply not the
style I want to write Lisp. IF* encourages _big_ control-statements, since
it makes small ones bigger that using IF/WHEN/UNLESS.
If we take a look at this code-snipped from AllegroServe (taken from
GET-REQUEST-BODY)
(let ((ch (read-char-no-hang (request-socket req)
nil nil)))
(if* (eq ch #\return)
then ; now look for linefeed
(setq ch (read-char-no-hang
(request-socket req) nil nil))
(if* (eq ch #\linefeed)
thenret
else (unread-char
ch (request-socket req)))
elseif ch
then (unread-char ch (request-socket req))))
Then I see no outstanding benefit by using IF* compared to e. g.
this:
(flet ((accept-char (char stream)
(let ((c (read-char-no-hang stream nil nil)))
(cond ((eql c char))
(t (unread-char c stream))))))
(declare (inline accept-char))
(let ((stream (request-socket req)))
(and (accept-char #\return stream)
(accept-char #\linefeed stream))))
In what way is the IF* solution more readable and maintainable then the
second solution?
ciao,
Jochen
Where does one find this macro? Is it public?
thanks,
BM
No, you didn't read my argument correctly.
A C programmer knows he can't extend the language he merely writes in it.
A Lisp programmer knows he can extend the language. That doesn't mean that he has to
in all cases, but if it leads to sufficiently better code then he should.
Let me as you this: are when and unless good or bad?
I'll be you say "good" since they are part of the ANSI spec.
Now what if they weren't part of the ANSI spec. What if now I introduced them to
you. Would they be good or bad? Now you would say "bad" since they don't give you
anything that if, not and progn can't give you.
I consider that a strange way of looking at things but sadly very common here. To me
something is either good or bad. I don't need the approval of the ANSI committee to
tell me that it's good.
> Exactly because CL gives you the power to extend the language, and
> create new languages embedded within/replacing the standard language,
> t is even more important to use that power wisely.
Would you consider writing one control flow macro in 23 years of programming to be
using that power wisely? Or for you is 'zero' the only wise number of new control
flow macros that should be written.
> Even C has enough power to replace certain syntactic constructs of the
> language with your own "improved" versions, as I mentioned in my
> posting. And even this limited power can be thus abused, in the name
> of personal persuasions of what constitutes readability. But in that
> community I have yet to encounter anyone with any kind of experience
> seriously suggesting that such a thing is something desirable.
If you ever looked at the source code for the 1978 version of Unix for the Vax that
came out of Bell Labs you may have read the source for the adb debugger program. The
author of this program (who was famous but whose name I don't remember) was a bigger
fan of Algol than C. Thus he wrote a complete set of C macros that allowed him to
write that debugger in an Algol like language that got macro expanded into C.
So yes, it has been done in the C community. The C macro facility is very weak as
I've said so the reason it's not been done more has, I believe, more to do with the
lack of power of the macroexapander than the lack of desire to extend the control
forms of C.
> What kind of proof do you need? We already now have IF* and if. The
> reason we don't have 10 IF*'s lies in the fact that most CL users are
> more prudent in the use of their powers than you seem to be.
wait a minute. You're proving my point not yours. my point is that most users know
that have the power to write control flow macros but choose not to do it. That says
that there won't ever be 10 if*'s. You have nothing to worry about.
> But somehow I'm slowly coming to the conclusion that you don't want to
> understand the criticism aimed at your stance, but would rather prefer
> to dismiss it out of hand, calling everyone who doesn't agree that the
> introduction and promotion of IF* as a replacement for IF/WHEN/UNLESS
> is a completely grand idea, as religious zealots,
you're completely wrong. I'm not asking you to embrace if* and give up if, when and
unless. I'm telling you that I've done that and I'm shocked that people are angry at
me for making a personal choice like that. A zealot insists that only he is right
and everyone must believe the same. How many people have told me on this very
forum that I can't give away for free lisp source code that includes a macro that they
don't like? It is absolultely unbelievable.
again, post a direct quote from me that says that I dislike you.
You've altered the readability of the code by factoring part of
it out (enhancing readabilty at a cost in speed if the function isn't compiled inline)
In doing so you've introduced a bug (if read-char-no-hang returns nil you'll call
unread-char passing it nil as the first argument (and the first argument should be a
character)).
If you really want to compare apples/vrs/apples you should take the if* code exactly
and put in if/when and unless and see what it looks like.
It may just be my newsreader but the indenting on both examples is messed up on my
screen so in particular for those who haven't seen if* and who run a lousy newsreader
don't be put off by the less than readability of the if* example.
> The only thing I'm interested in is discussion about how to better
> promote CL. I understand that topic might have no relation to the
> previous topic of this thread, but I saw an opening for introducing my
> topic, so I changed the Subject.
Ah. OK.
> > I preached the gospel of Lisp for many years on pretty much those
> > terms. The wall I always ran up against was the question: "Who uses
> > it?" The answer to that question for C++, Java and Perl is:
> > everyone. What's the answer for Lisp? A recent query to this
> > newsgroup asking people what they used Lisp for garnered only a
> > *single* response. Why? It's certainly not for lack of
> > participation in the newsgroup as a whole.
>
> The answer for C++, Perl and Java is not "everyone."
Yes, I know. Give me a break. Pretty darn near everyone.
> That is a
> reactionary answer, and there is no non-political reason you should
> accept that answer from anyone.
This is all politics. That's the problem.
> Paul Graham provided one answer to the "common non-sensical" answer of
> "everyone uses X" question, and that is since most businesses fail,
> doing what everyone else does increases your chance of failure.
I tried that. I was working before Paul came out of the closet ;-) so
my argument went something like this: imaging you're the CEO of a
company and you've discovered this language that gives you a
significant edge over the competition. Now a reporter calls you up to
do a story on what companies are using to do software development. Do
you tell the truth, knowing that your competitors will see the
reporter's story? Of course not. You tell the reporter that you are
doing what everyone else is doing, namely C++ or whatever. So having
everyone say they're using C++ is exactly what you'd expect to see if
a few people were using Lisp and winning big as a result.
It didn't work.
> My solution is to follow that same line of
> thinking for them, to differentiate the task from others, to make the
> question of what "everyone" uses irrelevant. This may take time,
> since you need to overcome a fear of differentiating themselves to the
> point where they can be a magnet for blame, but playing to their ego
> in such situations can be effective.
I tried that too. I got things written into the requirements that
only Lisp could solve (like being able to make changes to the software
while it is running, which is actually a very reasonable requirement
for spacecraft). That didn't work either. They still used C++
saying, "We'll figure out how to meet that requirement later." Later
when of course they couldn't do it they descoped the requirement.
E.
> [2] http://www.franz.com/~jkf/coding_standards.html
Interesting.
>A second problem with if occurs if you want to do two things in one of
>the branches of the if. In this case you have to put in a progn
>form. This makes the whole form even bigger and separates the
>bbbbbbbb and cccccccc parts from the if, thus making it even harder
>to understand the structure of the code.
This much I agree with. C/C++/Java/Perl and Pascal all make much the
same mistake. Ada and Modula-2 and Dylan get it right.
>The lack of an implicit progn in if gave rise to the two derivatives
>of if -- when and unless. No other language includes an inverse
>conditional
That's just plain not true!
BCPL had one.
Dylan has one (implemented as a macro in the standard library)
Perl has one.
>If* is better than cond since in cond the consequent is only
>indented on column making it hard to distinguish from the
>predicate.
That strikes me as a *very* weak reason for a new construct.
-- Bruce
So this is what you finally sink to. I am frankly quite disappointed.
You started this personal vendetta, John Foderaro. Doing that with me is
pretty darn stupid. Now that you recognize that you are losing, you are
turning into an Erann Gat. Your new line of _threatening_ is also pretty
amazing. Who do you think you are? The IRS? And how much money do you
think you have caused Franz Inc. to lose because of your behavior by now?
If you had been able to back down and listen to people, this could have
been an interesting technical discussion that could have resulted in some
of your retarded views not looking quite so retarded. _Arguing_ for your
views seems to be one of your least developed skills, however. Now that
you recognize this, all you can do is bicker over references. I am
frankly amazed that you think you can win anything that way, but hey,
that is precisely why I have beat you into the ground and not vice versa.
Just shut up, John Foderaro. There is no other way to control the damage
you do to yourself and to your employer.
Where are your requirements of substantiation when you speak about me?
As long a you keep posting obvious misrepresentations of what I say, your
demands are so hypocritical as to be _moronic_. Why you want to appear
that way to people is, however, beyond me. But now that you have done
more damage to yourself than I ever could do to you, perhaps it is time
to let you crawl back to your miserable cave and lick your wounds.
///
but yours does not lead to better code, it leadt to code that is
harder to read then normal(in the standard) code. I can buy a book or
books on the standard and/or check the hyperspec for answers. I can
not do that with your nonstandard macros.
>
>
> Let me as you this: are when and unless good or bad?
> I'll be you say "good" since they are part of the ANSI spec.
>
How about "not bad" because it is documented and I can expect certian
behavior that is in the standard and I can use all the resources I
listed above and c.l.l to help mew with my problems. And if I like
them or find them useful then they are good.
> Now what if they weren't part of the ANSI spec. What if now I introduced them to
> you. Would they be good or bad? Now you would say "bad" since they don't give you
> anything that if, not and progn can't give you.
>
> I consider that a strange way of looking at things but sadly very common here. To me
> something is either good or bad. I don't need the approval of the ANSI committee to
> tell me that it's good.
>
one reason for doing things using the defined in the standard language
is that other people can help, because they speak CL also if you start
mutating the language then the number of people who can help you
shrinks and the number of people who want to help you shrinks even
faster. There are lots of other reasons out there also.
>
>
>> Exactly because CL gives you the power to extend the language, and
>> create new languages embedded within/replacing the standard language,
>> t is even more important to use that power wisely.
>
> Would you consider writing one control flow macro in 23 years of programming to be
> using that power wisely? Or for you is 'zero' the only wise number of new control
> flow macros that should be written.
>
Well from how this discussion has gone, I would have to say no, in
your specific case.
>
>> Even C has enough power to replace certain syntactic constructs of the
>> language with your own "improved" versions, as I mentioned in my
>> posting. And even this limited power can be thus abused, in the name
>> of personal persuasions of what constitutes readability. But in that
>> community I have yet to encounter anyone with any kind of experience
>> seriously suggesting that such a thing is something desirable.
>
> If you ever looked at the source code for the 1978 version of Unix for the Vax that
> came out of Bell Labs you may have read the source for the adb debugger program. The
> author of this program (who was famous but whose name I don't remember) was a bigger
> fan of Algol than C. Thus he wrote a complete set of C macros that allowed him to
> write that debugger in an Algol like language that got macro expanded into C.
> So yes, it has been done in the C community. The C macro facility is very weak as
> I've said so the reason it's not been done more has, I believe, more to do with the
> lack of power of the macroexapander than the lack of desire to extend the control
> forms of C.
>
The point is that " isa it a good idea to do this needlessly" not if
it is physicaly possable.
>
>
>> What kind of proof do you need? We already now have IF* and if. The
>> reason we don't have 10 IF*'s lies in the fact that most CL users are
>> more prudent in the use of their powers than you seem to be.
>
> wait a minute. You're proving my point not yours. my point is that most users know
> that have the power to write control flow macros but choose not to do it. That says
> that there won't ever be 10 if*'s. You have nothing to worry about.
>
>
>> But somehow I'm slowly coming to the conclusion that you don't want to
>> understand the criticism aimed at your stance, but would rather prefer
>> to dismiss it out of hand, calling everyone who doesn't agree that the
>> introduction and promotion of IF* as a replacement for IF/WHEN/UNLESS
>> is a completely grand idea, as religious zealots,
>
> you're completely wrong. I'm not asking you to embrace if* and give up if, when and
> unless. I'm telling you that I've done that and I'm shocked that people are angry at
> me for making a personal choice like that. A zealot insists that only he is right
> and everyone must believe the same. How many people have told me on this very
> forum that I can't give away for free lisp source code that includes a macro that they
> don't like? It is absolultely unbelievable.
Oh the dramma of it all. Considdering what a job of creative editing
you did to the KMP post where he said that the road you are trying to
walk was travled before and was found to suck and so CL was born to
address the problems that you are trying to reintroduce. And you
"edited" it into something it was not but that you could deal with as
just an emotional I don't like it post devoid of all the facts he
posted and not attributed to him as the author so people could check
the orignal. that was defined by symbolics, in there user docs if I
remember correctly, as lieing and I agree it is dishonest and
reprehensable behavior that reflects poorly on you and franz. You are
a GREAT argument for lispworks instead of ACL. And dare I say a borring
whining pathetic dishonest fucking moron. One of the differences
between you and me is that if I think someone is an asshole I will say
"you are an asshole" to there, in this case your face. You seem to
lack the integerity and balls to do that. You have to play these
games that most 8yr old children are better at you putz.
marc
> Let me as you this: are when and unless good or bad? I'll be you
> say "good" since they are part of the ANSI spec.
>
> Now what if they weren't part of the ANSI spec. What if now I
> introduced them to you. Would they be good or bad? Now you would
> say "bad" since they don't give you anything that if, not and progn
> can't give you.
>
> I consider that a strange way of looking at things but sadly very
> common here. To me something is either good or bad. I don't need
> the approval of the ANSI committee to tell me that it's good.
This it seems to me is exactly where we differ. Things as well as
deeds aren't good or bad in isolation. They can only be judged when
put into a context. It is not a matter of "approval" by some
comittee. If WHEN and UNLESS weren't part of the current ANSI Common
Lisp standard, I would indeed carefully consider whether it was wise
to introduce those personal extensions into the public discourse at
the current point in time. Not because they don't give me anything
that IF, NOT and COND can't give me, but because they give me little
enough improvement over them that I would have to weigh their benefits
against the costs of introducing them into the basic vocabulary of the
language (i.e. those parts of the language that anyone has to learn in
order to read normal code). We are currently in a position where I
would have to consider whether it would be wise spending resources on
small aesthetic infrastructure stuff like this, when I can easily
point out X other areas where CL could benefit much more from those
resources.
Or to put it into stronger words: If ANSI Common Lisp fails its
audience in realizing their projects and goals, it will not be for
want of IF* (or UNLESS and WHEN for that matter). Now you might
differ in your assessment of the severity of the situation (I'm pretty
sure you do). But if that is the case, it is up to you to argue that
assertion, i.e. that IF/WHEN/UNLESS really are as unreadable as you
claim. But it will take more than the wild claims and assertions on
your "coding-standards"[1] page.
Anyway, introducing WHEN and UNLESS as _additions_ to the basic
control-flow constructs is a far cry from introducing IF* as a
_COMPLETE REPLACEMENT_ for IF/WHEN/UNLESS (and probably COND as
well). And it especially is a far cry from bashing those constructs
along the way as being "bogus", etc.
> Would you consider writing one control flow macro in 23 years of
> programming to be using that power wisely? Or for you is 'zero' the
> only wise number of new control flow macros that should be written.
How can one answer such a question without regard for the macros in
question? Introducing 200 control flow macros in 23 years of
programming can be evidence of using that power wisely. As can be
zero, or one. It is not the quantity that counts, and you should be
intelligent enough to know that. Why come up with such straw-men?
> If you ever looked at the source code for the 1978 version of Unix
> for the Vax that came out of Bell Labs you may have read the source
> for the adb debugger program. The author of this program (who was
> famous but whose name I don't remember) was a bigger fan of Algol
> than C. Thus he wrote a complete set of C macros that allowed him
> to write that debugger in an Algol like language that got macro
> expanded into C. So yes, it has been done in the C community. The
> C macro facility is very weak as I've said so the reason it's not
> been done more has, I believe, more to do with the lack of power of
> the macroexapander than the lack of desire to extend the control
> forms of C.
This is a completely different thing, and again you could have known
that. As long as said author didn't claim he was still writing in C,
instead of his personal rendering of Algol (which one?), this is not
an equivalent situation.
C with classes was implemented via a simple preprocessor to C, later
on Cfront compiled C++ to C. Had Bjarne Stroustrup claimed that C
with classes or C++ was just C with a couple of his own personal
macros, this would have been silly. Creating a new language is not a
problem if that's what you are trying to do. (Claiming to be) working
in one language, but disregarding basic idioms and vocabulary _is_ a
problem.
Again and again you draw parallels to things that aren't parallels at
all. Why?
> > What kind of proof do you need? We already now have IF* and if. The
> > reason we don't have 10 IF*'s lies in the fact that most CL users are
> > more prudent in the use of their powers than you seem to be.
>
> wait a minute. You're proving my point not yours. my point is that
> most users know that have the power to write control flow macros but
> choose not to do it. That says that there won't ever be 10 if*'s.
> You have nothing to worry about.
It is not 10 IF*'s that I worry about, it is 2 IF's, 3 LOOP's, 5
DEFUN's, etc.
But even then your argument is very strange indeed: "See, most people
don't behave as I want to be free to behave, because they restrain
themselves. So my kind of behaviour isn't a problem." Whatever
happened to Kant's categorical imperative?
> you're completely wrong. I'm not asking you to embrace if* and give
> up if, when and unless. I'm telling you that I've done that and I'm
> shocked that people are angry at me for making a personal choice
> like that. A zealot insists that only he is right and everyone must
If that is not what you are doing, then I don't see what your
coding-standards document is intended to do. "I consider
IF/WHEN/UNLESS bogus, extended LOOP should be avoided like the plague,
and either are signs of bad coding practice, and any code that uses
those is unreadable. But please, go on and continue using those!"
This seems like a very strange statement to make. And going through
the trouble of creating a complete "coding-standard", publishing it on
the web, and putting links to it into most source files one publishes,
seems like an interesting approach to making personal choices, and not
wanting to convert people.
Maybe your definition and mine differ, but when I make a personal
choice, I don't go through all that effort to publicize to the world
that this is was my personal choice, and tell them "BTW the
alternatives are bogus".
I'm sorry, but when one publically promotes ones personal choice, one
opens oneself to criticism. By your argumentation, when someone
publically announces "My personal choice for president is Al Gore,
because the foreign policy of George Bush is clearly bogus", then
anyone who starts to counter those claims in public is a religious
zealot, because he doesn't leave you the freedom to hold your own
"personal" opinions.
And if after all this whole episode you are still shocked and
surprised as to why people are angry at you for making a "personal
choice like that", then I don't know what to say anymore, and hence
will give up after this message. Especially since you make no sign of
even rewriting any of the inflammatory content of your
"coding-standards" page.
> believe the same. How many people have told me on this very forum
> that I can't give away for free lisp source code that includes a
> macro that they don't like? It is absolultely unbelievable.
I don't care what many people on this very forum may or may not have
told you. I argue for myself, and myself only. Whatever others do is
between you and them. My criticism has never been leveled at the mere
fact of your using IF* or including it in free lisp source code you
personally[2] are giving away. It is levelled directly at your repeated
public promotion of said macro, to the detriment of IF/WHEN/UNLESS,
and especially the form that promotion and argumentation has taken.
This is made all the more problematic by your attachment to one of the
major CL vendors, which clearly lends your words more exposure and
credence, and hence influence, than if this really were some small
personal preference. This is something you had to know, and had to
take into account in your behaviour.
Regs, Pierre.
Footnotes:
[1] http://www.franz.com/~jkf/coding_standards.html
[2] Things are of course different when the code is given away and
promoted by Franz, Inc., since this is then no longer a personal
matter.
That's certainly my impression of Prolog. (I'm learning it my spare time at
the moment for fun.) Have you looked at any of the multi-paradigm languages
that include logic programming, like Oz? If they can offer what Prolog's
advantages without its restrictions, they may be spectacularly useful. I've
also met people who make strong claims for Mercury as a better Prolog.
I suspect a lot of Lispers may also use Ocaml; whether they're more likely
to be current or ex-Lispers I'm not sure.
- Jonathan Coupe
As someone learning Lisp and having invested 5 digits into purchasing
ACL, I've been very disappointed by this whole discussion. After
owning and operating an ISP for 5 years, I learned a great deal about
customer service. Part of that involves empathizing with your customer
and being able to embrace their concerns. I found it helpful with
"difficult" customers to avoid self-defensiveness. Everytime I tried
that technique it failed me in tense situations.
Though Erik hasn't been known for exuberant levels of tact, it was his
positive postings regarding ACL that was the deciding factor for me to
purchase ACL vs. spending several times less money for Lispworks.
>you're completely wrong. I'm not asking you to embrace if* and give
> up if, when and unless. I'm telling you that I've done that and I'm
> shocked that people are angry at me for making a personal choice like
> that. A zealot insists that only he is right and everyone must
> believe the same. How many people have told me on this very forum
> that I can't give away for free lisp source code that includes a macro
> that they don't like? It is absolultely unbelievable.
Reading through the source code of ACL, like another poster, I
encountered this macro and fruitlessly went to the hyperspec to look
it up. Since this macro is an integral part of the source code for
ACL, I don't consider it merely a "personal choice". Further, I
didn't just get this "free lisp code", I paid quite a bit of dollars
for it.
Those are minor quibbles. I really don't care about if*, though I must
say that I well like when and unless.
My main point is that, as a investor in Common Lisp and in ACL, I am
disappointed in several ways by this discussion. I will say
publically, though, John, you impressed me quite well in tracking down
a subtle bug with my ODBC manager.
Best wishes to all posters and to the health of Common Lisp.
Cheers!
--
Kevin Rosenberg, M.D.
ke...@rosenberg.net
> It may just be my newsreader but the indenting on both examples is
> messed up on my screen so in particular for those who haven't seen
> if* and who run a lousy newsreader don't be put off by the less than
> readability of the if* example.
My lousy newsreader's frame geometry is set to a criminally-insane
lunatic value: 80 characters. Your posts are messed up on my screen,
but I'm trying not to be put off by the less than readability of them.
--
John Paul Wallington
Is this going to involve RAW human ecstasy?
My personal form of this macro isn't currently public, though I can
see if I can isolate it and publish it. But I'm quite certain that
various variants of such a macro do float around, and some of them
might be publically available. It's not as if I invented that
particular macro, or the idea for it. It is easy to write, too, since
this is mostly syntactic sugar and bookkeeping stuff that translates
into a tagbody...
IIRC there are also several variants which take a more open form,
i.e. DEFINE-STATE-MACHINE, DEFINE-STATE, etc.
Regs, Pierre.
> This is an apples and oranges comparison
Is it?
> You've altered the readability of the code by factoring part of
> it out (enhancing readabilty at a cost in speed if the function isn't
> compiled inline)
So raw speed and micro-efficiency is more important than readability and
abstraction? Then I begin to wonder why _you_ always called REQUEST-SOCKET
instead of introducing a LET binding if you count micro-efficiency so much!
Btw.: LW produces rather nice code and inlines the local function quite
nicely - I think I can assume that ACL does this too doesn't it?
chop-2 compiled to less code and fewer funcalls than your code so I fear
that it's "micro-efficiency" is better...
> In doing so you've introduced a bug (if read-char-no-hang returns nil
> you'll call unread-char passing it nil as the first argument (and the
> first argument should be a character)).
That is true, but easily fixed by replacing the T clause of the cond trough
c. An edit-difference of exactly _one_ character...
(defun chop-2 (req)
(flet ((accept-char (char stream)
(let ((c (read-char-no-hang stream nil nil)))
(cond ((eql c char))
(c (unread-char c stream)))))) ; clause fixed
(declare (inline accept-char))
(let ((stream (request-socket req)))
(and (accept-char #\return stream)
(accept-char #\linefeed stream)))))
The general concept remains the same and the question remains too:
I simply do not understand why you think IF* leads to more readable and
maintainable code - but you mentioned this as a fact in many posts so far.
> If you really want to compare apples/vrs/apples you should take the if*
> code exactly and put in if/when and unless and see what it looks like.
I don't think so - the fact is that you always say using IF* is so much more
readable and maintainable and I _really_ began to wonder why you think so -
I don't see how I have earned to be insulted in the way you have done it in
your posting! I'm no customer of Franz Inc. but your writing to me - full
of insults - does in no way encourage me to get in contact with Franz Inc.
in future...
In my experience IF* is neither readable nor maintainable there were
several bugs introduced simply because of the bad design of IF* and the
general code-layout this leads to. But since rewriting something from
scratch easily introduces new bugs we have chosen to be careful when doing
changes in Portable AllegroServe. But fact is that the big chunky C
like IF* code is far less maintainable and doing changes to such code
introdcuces bugs too.
> It may just be my newsreader but the indenting on both examples is messed
> up on my screen so in particular for those who haven't seen if* and who
> run a lousy newsreader don't be put off by the less than readability of
> the if* example.
If your newsreader shows the examples not indented the right way you could
paste it into an Emacs buffer.
I hope you did not mean that I may have tried to introduce wrong facts by
intentfully indenting your code the wrong way - as you imply with your
statement.
I wonder why it is so difficult to understand for you that the reason why
you get attacked here is simply that you *insult* people rather heavily -
not only with your still unchanged "Lisp Coding Standards" but also in your
posts. You always insist on your 23 years of Lisp experience as if this
would make all other posters inferior to your brilliant mind.
Jochen Schmidt
--
http://www.dataheaven.de
> I do not care about a PC disclaimer, my point was and is franz is
> giving your claim's weight because it is on there web site. This is
> where I would expect to see stuff about how CL is wonderful and ACL is
> even beter then that. Instead I see your poorly thought out and
> fundmentaly flawed rant about CL. If you must do less then optimal
> things you should not do them at work and franz's web space is part of
> your work enviorment.
While I don't want to comment on the coding `standards' paper, I do
want to say that I don't think it's unreasonable that a company should
allow its employees to express their opinions, covered by a disclaimer
and suitably distinguished from the corporate content, on its web
site. Of course, it's *uncommon* now for a company to do that, when
websites have become advertising mediums (media?), but it was common
not so long ago, and I don't think there's anything particularly wrong
with it.
--tim
> It may just be my newsreader [ ... ]
I think it probably is.
Please set your column width to somewhat less than 80 characters'
worth.
> [ ... ] but the indenting on both examples is messed up on my screen
> so in particular for those who haven't seen if* and who run a lousy
> newsreader don't be put off by the less than readability of the if*
> example.
Mmm. Even were it not just your newsreader, I think that people in
this august forum are wiser than that. After all, I haven't seen any
/ad hominem/ attacks towards you regarding your illegible posts on
80-character displays...
Christophe
> Writing a low level wrapper around most of the POSIX interface isn't
> difficult when you know the FFI of your implementation a bit. It's a
> big job and it's tedious. But all that buys you is the ability to
> write C with parentheses.
Yes, but every now and then this is just what you want. Every now and
then I just want to be able to do e.g. a 'stat' from lisp without having
to write the ffi code myself.
But of course some of the really nice things in perl are rather high-
level, like the really painless way you can use diffent kinds of DBM
files as if they were ordinary hash tables.
(MCL, btw, has very good integration with all the low- and higher level
Mac OS stuff)
--
(espen)
> In article <32085159...@naggum.net>, er...@naggum.net says...
> >
>
erik>> John Foderaro expresses a very strong hatred for the standard as
erik>> such, and the standardization process in particular.
>
>
> So I'm asking that you produce postings or writings by me that would
> backup your statement that I've been out trying to get people to
> disregard the standard.
Ancient chinese proverb: Be careful what you ask. You may get it.
In article <MPG.146f3aacb...@news.dnai.com>,
John Foderaro <j...@unspamx.franz.com> wrote:
jf> If the decision hadn't been made to make Common Lisp case insensitive
jf> upper (and I tried my best to stop it), then there wouldn't
jf> be *print-case* or readtable-case in the language. They
jf> are just kludges to fix a botch in the language.
Perhaps the words "kludges", "botch" and "tried my best to stop it"
are what Erik has been referring to.
At this point, I suspect most of the readership is way past caring anyhow...
--
It would be difficult to construe Larry Wall, in article
this as a feature. <1995May29....@netlabs.com>
Rolf Mach
Fernando wrote:
> On Sun, 02 Sep 2001 00:42:56 +0200, Rainer Joswig
> <jos...@corporate-world.lisp.de> wrote:
>
> >For non-Mac users, Xanalys will show the upcoming LispWorks 4.2 at
> >LinuxWorld in Frankfurt/Germany.
> > Xanalys Ltd, Hall 6.0, booth E24 http://www.linuxworldexpo.de/
>
> Any idea about what's new in 4.2? O:-)
--
__________________________________________________________________________________________
XANALYS - www.xanalys.com
Data Analysis and Lisp Development Tools
Software zur Datenanalyse und Lisp Entwicklungsumgebungen
__________________________________________________________________________________________
Rolf Mach
Business Development & Sales Manager, Europe
An der Schaafhansenwiese 6
D-65428 Ruesselsheim, Germany
Phone ++49 +6142 938197
Fax ++49 +6142 938199
rm...@xanalys.com
__________________________________________________________________________________________
NEW: LispWorks 4.2 at LinuxWorld Expo, Frankfurt, 30-Oct/1-Nov 2001,
Hall 6.0 Booth E24
__________________________________________________________________________________________
Watson - PowerCase - Quenza - LispWorks
ok, but I'm still waiting for it. I've told you that any person who
has a lot of experience with a complex object will find the faults
in it. This message indicates a flaw I've found.
Does the posting of this one message show that I'm trying
to start a revolution and overthrow the standard? Did I say anywhere
that my plan is to force a change in the standard so that today's
conforming programs no longer work?
> What's the answer for Lisp? A recent query to this newsgroup asking
> people what they used Lisp for garnered only a *single* response.
> Why? It's certainly not for lack of participation in the newsgroup as
> a whole.
I think that Usenet responses to such queries, or similar success stories,
are the exception rather than the rule due to a number of reasons,
including the following:
- Many of those who work in a certain field or use a certain tool do not
feel comfortable with Usenet or other online public discussion forums.
- Among the users who do feel comfortable, those who actually post are
around an order of magnitude less than the lurkers.
- Lack of time to respond. I failed several times to provide valuable
information even when I had it. Time is often a scarce resource.
- Lack of time to respond to further queries (it often happens that you are
asked about source code, screen shots, more information, etc.)
- Some users can't take the liberty of discussing their work because of
company policies on sensitive information.
- Lack of English proficiency.
Incidentally, those interested in Lisp success stories should contact Franz
and purchase the proceedings of recent Lisp conferences. At least 3 such
publications should be available for a few tens of bucks (hey! this allows
me to claim that I am a Franz customer, and I even got "support" :)
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://web.mclink.it/amoroso/ency/README
[http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/]
Please show me a post where I've insulted you.
> I hope you did not mean that I may have tried to introduce wrong facts by
> intentfully indenting your code the wrong way - as you imply with your
> statement.
I didn't mean to imply that at all. Newsreaders try to display text
rather than code and some play fast and loose with tabs and spaces.
I wanted everyone to be aware of the indentation problems I saw
in my newsreader so they would be check for that in theirs as well.
> John Foderaro wrote:
>
> > It may just be my newsreader but the indenting on both examples is
> > messed up on my screen so in particular for those who haven't seen
> > if* and who run a lousy newsreader don't be put off by the less than
> > readability of the if* example.
>
> My lousy newsreader's frame geometry is set to a criminally-insane
> lunatic value: 80 characters. Your posts are messed up on my screen,
> but I'm trying not to be put off by the less than readability of them.
I read mail over a 48x80 telnet window and find John's posts nearly
unreadable also. I don't mind the occasional wraparond line (often
unavoidable in code) and surely generate them myself. But having every
line wrap at colum 90 or whatever he's using certainly does cause me to
mostly delete the messages without reading them for reasons outside the
scope of why he probably imagines I'm not reading them... If it were
only content, I would not be skipping them by.
> While I don't want to comment on the coding `standards' paper, I do
> want to say that I don't think it's unreasonable that a company should
> allow its employees to express their opinions, covered by a disclaimer
> and suitably distinguished from the corporate content, on its web
> site. Of course, it's *uncommon* now for a company to do that, when
> websites have become advertising mediums (media?), but it was common
> not so long ago, and I don't think there's anything particularly wrong
> with it.
Funny, but I find the failure of the company (not just the individual)
to have a disclaimer here to be the weird part. To me, it suggests
either that the company is unaware that the individual has done so or
that the company is not really in disagreement.
This is because when I read Fodarero's remarks, I find myself assuming that
he speaks not realy just for himself, but for some subset of Franz,
especially if his macro can so pervade Franz code. As such, I find
myself wondering things like whether JKF's remarks are just an attempt
to achieve deniability while probing the customer base for support.
It's a technique that I see get a lot of use in the US political
parties. I notice it most in the Republican party but I don't doubt
it's used elsewhere. One member says something like "I think xxx"
where "xxx" is offensive to most Democrats and the rest of the
Republican party shrugs and says "well, he's entitled to his personal
opinion". Then a Democrat says "yyy" where "yyy" is offensive to most
Republicans and the Republicans begin asserting that all Democrats
must agree with "yyy" because they are failing to condemn it. It's at
points like this that you get some weak sense of satisfaction out of
the fact of a Party Platform, which at least outlines the beliefs of the
party and helps one know whether the beliefs of the individual are
divergent or not.
Franz having no public policy on the matters cited by Fodarero, and Franz
code appearing to agree, those remarks speak more loudly than they
might otherwise. And soft disclaimers that it's a pesonal opinion look
more like "formal cover", which several people in this discussion have
flagged.
Kent> I read mail over a 48x80 telnet window and find John's posts
Kent> nearly unreadable also. I don't mind the occasional wraparond
Kent> line (often unavoidable in code) and surely generate them
Kent> myself. But having every line wrap at colum 90 or whatever
Kent> he's using certainly does cause me to mostly delete the
Kent> messages without reading them for reasons outside the scope of
Kent> why he probably imagines I'm not reading them... If it were
Kent> only content, I would not be skipping them by.
Why not set gnus to automatically wrap lines at column 72 (or whatever
you prefer) for you? It's not good for code, but for most news
articles it works well.
--
cryptographic Ortega PLO Treasury Waco, Texas terrorist World Trade
Center Mossad ammunition domestic disruption assassination class
struggle NORAD Legion of Doom SEAL Team 6
There's no conspiracy going on here. You are correct in saying that
I speak for myself and for Franz. When I wrote in the document
that the opinions expressed in the document were mine alone
I was saying as myself that they were my opinions. I was also speaking for
Franz in saying that they were John Foderaro's opinions.
They are not the policy here at Franz nor will they ever be the policy
here at Franz. Franz has never told its developers how they must
write their code, instead the developers have over time come to an
unwritten consensus on how to write code that's mutually readable
by people with different styles.
I'm glad you brought up this point of confusion because others may have
been equally curious about it. Now I hope we've straightened it out.
I've added a "success stories" page to CLiki. Anybody is free to add a few
ones to it.
It's quite empty at this time...
Marc
John,
It just so happens I used lisp for a year or so never seeing UNLESS or WHEN
or being aware of them, never using them, never missing them either. As you
say, they don't provide anything IF, NOT and PROGN can't handle. When I
discovered them, I liked them and I happily use them as part of a rich set
of choices (though I admit UNLESS I use very infrequently, it still needs a
double take for me to read it). So your prediction of attitudes based on
inclusion in ANSI does not hold for all of the people who have objected to
your "Coding Standards" document. I seriously doubt it holds for any. You
continue to argue against positions I have seen no one take and apparently
you do this quite intentionally. Can you provide a quote where someone is
taking this position?
The main point is that like and dislike of one construct over the other is a
matter of personal taste. Can't you at least acknowledge this?
> I consider that a strange way of looking at things but sadly very common
here. To me
> something is either good or bad.
I consider *this* a strange way of looking at things. I do not divide the
world of programming syntax into good and bad at all. Good and bad are
categories I use, but almost always only within a specific context. In
general, things have their own ways of being useful, it is very rare I would
apply any "Don't do this" rule blindly. (In fact about the only "Don't do
this" rule I can think of for programming that is universal is "Don't be a b
lithering idiot" ;-) Everything else in moderation.)
> I don't need the approval of the ANSI committee to
> tell me that it's good.
>
Again this is non-sequitor to any of the arguments raised in objection to
either if* itself or more importantly your "Coding Standards" document.
> > Exactly because CL gives you the power to extend the language, and
> > create new languages embedded within/replacing the standard language,
> > t is even more important to use that power wisely.
>
> Would you consider writing one control flow macro in 23 years of
programming to be
> using that power wisely? Or for you is 'zero' the only wise number of new
control
> flow macros that should be written.
Write and use as many as you want, just don't tell me that I have poor style
if I don't use them. It really is that simple. Can you at least
acknowledge that I don't *have* to use your macro in order to write proper
lisp code?
> > But somehow I'm slowly coming to the conclusion that you don't want to
> > understand the criticism aimed at your stance, but would rather prefer
> > to dismiss it out of hand, calling everyone who doesn't agree that the
> > introduction and promotion of IF* as a replacement for IF/WHEN/UNLESS
> > is a completely grand idea, as religious zealots,
>
> you're completely wrong. I'm not asking you to embrace if* and give up
if, when and
> unless. I'm telling you that I've done that and I'm shocked that people
are angry at
> me for making a personal choice like that.
I think you misunderstand on purpose. To quote your web page:
"Use if* instead of the bogus-three-conditionals: if, when and unless. One
can go on and on about how bad the if special form is..."
"It should be obvious now why loop is a bad idea"
There is no room in those statements for respectful disagreement. If I
can't see something obvious, what does that imply? I agree, or i am an
idiot. You wrote those words, you leave them there and you defend them in
ways that only work if we had never read them.
Can you at least acknowledge that some one who likes loop and finds
IF/WHEN/UNLESS intuitive might take that as a put-down of their opinion if
not their person?
> A zealot insists that only he is right
> and everyone must believe the same.
Doesn't your document do just that? It is titled "Lisp Coding Standards"
not "An Alternative to Traditional Control Flow in Common Lisp" One of us
is really missing something here and since communication only works through
a common consensus of what words mean, I don't mind pointing out that you
are a minority of one in defending the title of that document.
> How many people have told me on this very
> forum that I can't give away for free lisp source code that includes a
macro that they
> don't like?
I don't recall anyone saying that in any terms close to these. Do you have
a quote?
You really should respond to the substance of these protests, if possible,
or not at all. You are digging a very deep hole for yourself by your
current approach. There are alot of people who have made respectful and
straightforward objections that you have ignored.
Coby
--
(remove #\space "coby . beck @ opentechgroup . com")
You have very strongly indicated that you want today's common knowledge
of how to write code in the language to become invalid. This means that
people who want to write Common Lisp code will find that they have to
make up their mind whether they agree with your silly if* stunt _and_
avoid if/when/unless or want to write standard Common Lisp and be able to
discuss their code with others who write standard Common Lisp. This is
undermining the standing of the standard, so yes, you have shown that you
are trying to start a revolution and overthrow the standard, starting not
with programs that no longer work, but with programmers that no longer
use the standard, and that revolution has apparently already started at
Franz Inc. from what you are "clarifying" about your disclaimer. This is
the wider ramifications to which I have been objecting all along, and you
are probably the only person in this thread who have failed to understand
that this is _not_ about your macro or your flaws, but about the much
wider ramifications of both your insulting language and your actions.
///
Certainly. Here's the quote from Message-ID: <87r8tow...@orion.bln.pmsf.de>
From: "Pierre R. Mai" <pm...@acm.org>
There are reasons for including such constructs as IF, WHEN, UNLESS,
CASE, TYPECASE, etc. in the core language standard, even if all of
them can just as easily be defined by each user with macros based on
COND. And that reason is _WIDE READABILITY_! IF, WHEN and UNLESS
aren't readable based on their own merits, or not. They are readable
by the whole community because they are part of the shared
understanding, because they are part of the standardized language. If
a reader sees an IF, WHEN or UNLESS, they don't have to worry about
the exact semantics those constructs might currently have, because
the exact semantics have been prescribed, once and for all, in the
ANSI CL standard, and are not subject to changes.
He's saying that something is "good" because it's part of a published
standard. You can then conclude that not being part of a published
standard means that it may not be "good". In my statement I wasn't
saying that I knew that Pierre felt that way, I was instead asking
him if he felt that way and letting him tell me.
> The main point is that like and dislike of one construct over the other is a
> matter of personal taste. Can't you at least acknowledge this?
>
I have repeatedly said that.
Can you acknowledge that I have a right to publish my own opinion despite
who I work for and how long I've been working in Lisp?
> There is no room in those statements for respectful disagreement. If I
> can't see something obvious, what does that imply? I agree, or i am an
> idiot.
It's my opinion. I stated at the top of the page
that it was my opinion. When someone
uses the word opinion it means that they know that they aren't telling you
universally held beliefs. They are telling you what they feel.
Based on the word opinion alone you should have realized that I would
not consider anyone an idiot who disagreed with my OPINION, and in
fact I would expect there to be people who disagreed.
>> How many people have told me on this very
>> forum that I can't give away for free lisp source code that
>> includes a macro that they
>> don't like?
> I don't recall anyone saying that in any terms close to these. Do you have
> a quote?
Certainly.
From: Erik Naggum <er...@naggum.net> in Message-ID: <32080033...@naggum.net>
This is why I urge Franz Inc to remove IF* from their published code. If
you are in the business of selling Common Lisp products, just follow the
standard. If you are the business of selling IF*, proceed as you have.
If John Foderaro makes it as abundently clear as I get the impression he
does that he would never write cond and progn, much less if, when, and
unless in production code, have somebody else (preferably some software)
convert his _personal_ style into _professional_ style for publication.
> You really should respond to the substance of these protests, if possible,
> or not at all.
I have now responded.
Of course they don't, at least unconditionally, because that would be
disastrous e.g. for code.
No, he is saying that the knoledge of how this works is portable
across all CL conforming implamentatuions and that is good.
>
>
>
>
>> The main point is that like and dislike of one construct over the other is a
>> matter of personal taste. Can't you at least acknowledge this?
>>
>
> I have repeatedly said that.
> Can you acknowledge that I have a right to publish my own opinion despite
> who I work for and how long I've been working in Lisp?
You seem to be a case of I have my rights but do not acknoledge the
responsabilities that go with them. And I have the right to point out
that your oppinions ar realy the stuff that fertlizer is made of. You
also have a responsability not to do your vendor harm, he has a right
to expect that, because he pay your rent/morgage and such? Franz and
more importantly franz's customers have a right to quality code that
is well documented, did frannz ever doocument the if* officialy in the
code they shiped there customers? If the answere is no then franz and
you did the customers a grave disservice.
I have a question for you, does franzhave a coding standard for there
product, a real one? I would be in seeing it and seeing the comments
that it would generate by those more knoledgeable then my self.
What I think Erik is saying is that they should pull this non standard
stuff from there production code that they ship to customers. That
has ABSOLUTLY NOTHING to do with givving away code, you are paid to do
this, remember?? This get back to the "I donated allegroserv" line I
asked you were you paid to do this work and have received no answere
so I guess that is a yes. If that is true by claiming to have donated
it you are stealing the credit that franz is entitled to for funding
the development of the system.
>
>
>
>> You really should respond to the substance of these protests, if possible,
>> or not at all.
>
> I have now responded.
>
I call upon the lisp community to vote on this statement, well if he
can do it....
What do you think john need to know.
marc
Another poster just pointed out it was documented so I was wrong there.
On Tue, 4 Sep 2001, Coby Beck wrote:
>
> "John Foderaro" <j...@unspamx.franz.com> wrote in message
> news:MPG.15fdcc0dd...@news.dnai.com...
> > In article <871ylnx...@orion.bln.pmsf.de>, pm...@pmsf.de says...
> > Let me as you this: are when and unless good or bad?
> > I'll be you say "good" since they are part of the ANSI spec.
>
> John,
>
> It just so happens I used lisp for a year or so never seeing UNLESS or WHEN
> or being aware of them, never using them, never missing them either. As you
> say, they don't provide anything IF, NOT and PROGN can't handle. When I
> discovered them, I liked them and I happily use them as part of a rich set
> of choices (though I admit UNLESS I use very infrequently, it still needs a
> double take for me to read it). So your prediction of attitudes based on
While flaming is often its own reward, I find it a bit more satisfying to
state constructively why I like the alternative conditionals WHEN and
UNLESS. Maybe after I've exhausted that avenue I'll comment on Foderaro's
motives or the sexuality of his mother or something.
Martin Fowler's book "Refactoring" has had a lot of influence on my recent
coding style in multiple languages. Some books are great because they
open your mind to completely new vistas; others are great because they
codify what you already know to be true, but perhaps don't realize it.
"Refactoring" is in the latter category. It has a lot of good advice
and recipes for writing clear code. Among other things, it recommends an
"early out" style of error checking and value returning in methods.
Rather than deeply nest conditionals, return directly when an error is
encountered or values are ready to be returned. This leads to a style
where conditionals often have only one branch.
Here's an example. I'm not attempting to prove that "early out" has a
huge advantage with these toy fragments, but merely to illustrate what I'm
talking about:
;; Traditional "functional" Lisp style
(defun do-something (input1 input2)
(if (and (is-valid input1)
(is-valid input2))
(let ((foo (set-stuff-up input1 input2)))
(if (simple-situation input1 input2)
foo
(do-some-more-stuff input1 input2 foo)))
(error 'invalid-inputs input1 input2)))
;; Early out style
(defun do-something (input1 input2)
(if (not (and (is-valid input1)
(is-valid input2)))
(error 'invalid-inputs input1 input2))
(let ((foo (set-stuff-up input1 input2)))
(if (simple-situation input1 input2)
(return-from do-something foo))
(do-some-more-stuff input1 input2 foo)))
If you're going to write in the latter style, WHEN and UNLESS make for
very readable alternative syntax:
(defun do-something (input1 input2)
(unless (and (is-valid input1)
(is-valid input2))
(error 'invalid-inputs input1 input2))
(let ((foo (set-stuff-up input1 input2)))
(when (simple-situation input1 input2)
(return-from do-something foo))
(do-some-more-stuff input1 input2 foo)))
So that's why I like them. In particular UNLESS, which on its face is
completely redundant, reads very naturally as a validating "guard."
I don't like IF* very much because I find it adds verbiage to no useful
end, but I certainly respect JKF's right to use it in the considerable
amount of code that he's released. Some think that it's hard to find the
source to the macro, others don't; whatever. I would think that using it in
code fragments that were answers to Usenet questions would be rather
pompous and affected, like gratuitously throwing in French or Latin
phrases, but that's just me.
Tim
P.S. I like LOOP too.
> In article <Df6l7.32821$aZ.86...@typhoon.tampabay.rr.com>, cb...@mercury.bc.ca
> > There is no room in those statements for respectful disagreement. If I
> > can't see something obvious, what does that imply? I agree, or i am an
> > idiot.
>
> It's my opinion. I stated at the top of the page that it was my
> opinion. When someone uses the word opinion it means that they know
> that they aren't telling you universally held beliefs. They are
> telling you what they feel. Based on the word opinion alone you
> should have realized that I would not consider anyone an idiot who
> disagreed with my OPINION, and in fact I would expect there to be
> people who disagreed.
[ Adding deleted context:
"Coby Beck" <cb...@mercury.bc.ca> writes:
I think you misunderstand on purpose. To quote your web page:
"Use if* instead of the bogus-three-conditionals: if, when and unless. One
can go on and on about how bad the if special form is..."
"It should be obvious now why loop is a bad idea" ]
No, it is NOT just an opinion. "When talking about biology, use the
Punctuated Equilibrium model of evolution instead of the bogus
religious explanations ... it should be obvious now why Creationism is
a bad idea." The above is indeed my opinion, but some opinions
generalize to others. OF COURSE I think anyone who disagrees in an
idiot; I'm also willing to admit it. Just wrapping a general
statement with "It is my opinion that ..." doesn't necessarily make it
less general.
That said, reader case issues have had a long history of being
low-priority at Franz. Just to be sure of the following, I went and
checked the heap of Allegro manuals in my office.
As of Allegro 4.2 (my copy is dated January, 1994), readtable-case was
still listed as unimplemented in the ANSI conformance section. It
finally showed up in Allegro 4.3 (dated March, 1996 - it may have
appeared first in a 4.2.x release, I don't have those documents to
hand).
ANSI voted readtable-case into the language in June, 1989; the whole
standard passed in December 1994. Franz had plenty of warning that this
needed to be done, but apparently chose to put it off as long as
possible - Allegro was tracking other ANSI conformance issues closely at
the time (the char-bit functions were deprecated in at least 4.1 - March
1992), but not this one. I'd love to hear there was a reason for this
other than developer dislike for that part of the standard.
I remembered this, because around that time I needed a case-sensitive
reader for compatibility with a vile little lex/YACC-based S-expression
reader in use by other implementors in my team. I had extolled Lisp's
virtues to the rest of them, and it was embarrassing for me to have to
say that I couldn't do a case-sensitive read in Allegro (actually I
could, if I was willing to set a global flag, break all my existing
code, and abandon CLX).
--
Remove obvious stuff to e-mail me.
Bob Bane
if* is a macro. We ship our code compiled and during the
compilation process macros are expanded and are not
referenced in the compiled code. Is this what you want?
Our open source modules (AllegroServe, imap, smtp, etc) are shipped
in a compiled form and for some of them the source is also shipped
(or pointers are give to web pages where the source can be found).
Does this come under 'production code' in your mind? Or is this
different. If it's under production code does that mean that
Erik is saying that all if*'s should be removed from all those
open source modules?
> This get back to the "I donated allegroserv" line I
> asked you were you paid to do this work and have received no answere
> so I guess that is a yes.
It's definitely the case that Franz paid for my time (and the time
of others) to develop the open source modules that we distribute.
I'm happy you've given me an opportunity to give Franz credit for
spending money on something and donating it to the community.
I'll just show you how I would write that function
but before I do I better at the disclaimer that the
views expressed are my opinion and mine alone and
I won't think any less of anyone who disagrees.
you ended up with this being the best form:
(defun do-something (input1 input2)
(unless (and (is-valid input1)
(is-valid input2))
(error 'invalid-inputs input1 input2))
(let ((foo (set-stuff-up input1 input2)))
(when (simple-situation input1 input2)
(return-from do-something foo))
(do-some-more-stuff input1 input2 foo)))
I personally would have left it in the
non-early-out form and written it:
(defun do-something (input1 input2)
(if* (and (is-valid input1)
(is-valid input2))
then
(let ((foo (set-stuff-up input1 input2)))
(if* (simple-situation input1 input2)
then foo
else (do-some-more-stuff input1 input2 foo)))
else
(error 'invalid-inputs input1 input2)))
I prefer my form because just looking at you see immediately
that there are two branches in this function controlled by
the 'and' expression. Then inside the 'then' form you see that
there are two branches inside it controlled by the simple-situation
form. So without reading the code you see the structure of the
function.
It's my personal belief that this is simpler to read than
your version.
<newbie>
Personally I'd prefer:
(defun do-something (input1 input2)
(unless (and (is-valid input1)
(is-valid input2))
(error 'invalid-inputs input1 input2))
(let ((foo (set-stuff-up input1 input2)))
(if (simple-situation input1 input2)
foo
(do-some-more-stuff input1 input2 foo))))
or at least
(defun do-something (input1 input2)
(unless (and (is-valid input1)
(is-valid input2))
(error 'invalid-inputs input1 input2))
(let ((foo (set-stuff-up input1 input2)))
;
; *** Look at me! ***
; *** Exit Point! ***
;
(when (simple-situation input1 input2)
(return-from do-something foo))
;
(do-some-more-stuff input1 input2 foo)))
The pre-condition sits up front and, to me, is immediately
obvious. The RETURN-FROM is in the "main body" and may not be.
It's really a minor point, I could easily argue either way
and your choice wouldn't bother me unless the exit was
deeply buried. Judging from what you have written, it
wouldn't be. I'm more worried about missing it on a quick
skim over a function and forming a wrong opinion about
what the function does than what I'd get from even a
slightly more intelligent approach (like reading it).
As for the thread, if a C/C++ compiler manufacturer started
shipping example code that contained:
#define begin {
#define end }
#define repeat do{
#define until(x) }while(!(x));
int func(int x,int y)
begin
int prod = 1;
repeat
prod = prod * x;
y = y - 1;
until(y==0);
end
I'd question how committed they were to the C/C++ language
standards. The IF* macro doesn't seem to add anything to Lisp
it just replaces standard practice with something that has
a decided Pascal look-and-feel to it.
Besides, everyone knows that `then' should come at the end:
\ for the visiting forthers
\ n1 - current elevator floor
\ n2 - new elevator floor
\ f - false = going down
\ true = going up
: move-elevator ( n1 f -- n2 ) 1 swap if + else - then ;
> P.S. I like LOOP too.
me too :-)
Geoff
</newbie>
> Here's an example. I'm not attempting to prove that "early out" has a
> huge advantage with these toy fragments, but merely to illustrate what I'm
> talking about:
>
> ;; Traditional "functional" Lisp style
> (defun do-something (input1 input2)
> (if (and (is-valid input1)
> (is-valid input2))
> (let ((foo (set-stuff-up input1 input2)))
> (if (simple-situation input1 input2)
> foo
> (do-some-more-stuff input1 input2 foo)))
> (error 'invalid-inputs input1 input2)))
>
> ;; Early out style
> (defun do-something (input1 input2)
> (if (not (and (is-valid input1)
> (is-valid input2)))
> (error 'invalid-inputs input1 input2))
> (let ((foo (set-stuff-up input1 input2)))
> (if (simple-situation input1 input2)
> (return-from do-something foo))
> (do-some-more-stuff input1 input2 foo)))
>
The above threw me for a second: "why would you use RETURN-FROM and
put DO-SOME-MORE-STUFF outside the IF?" Because DO-SOME-MORE-STUFF
isn't a function call, but some more code in the body of the function,
or so I assume. If that's the case, then the rewriting below is more
usefull.
JF> (defun do-something (input1 input2)
JF> (if* (and (is-valid input1)
JF> (is-valid input2))
JF> then
JF> (let ((foo (set-stuff-up input1 input2)))
JF> (if* (simple-situation input1 input2)
JF> then foo
JF> else (do-some-more-stuff input1 input2 foo)))
JF> else
JF> (error 'invalid-inputs input1 input2)))
How about
(defun do-something (input1 input2)
(if (and (is-valid input1)
(is-valid input2))
; then
(let ((foo (set-stuff-up input1 input2)))
(if (simple-situation input1 input2)
foo
(do-some-more-stuff input1 input2 foo)))
; else
(error 'invalid-inputs input1 input2)))
I don't use these comments unless I am really confused, but maybe
%10 of the time or if I am trying to be too clever for my own good
I end up needing to stick "; else bla" or "; implicit else" if I abuse
when with return etc. I don't see a big difference here, but I also
think my server missed the beginning of the thread.
cheers,
BM
> If you ever looked at the source code for the 1978 version of Unix for the Vax that
> came out of Bell Labs you may have read the source for the adb debugger program. The
> author of this program (who was famous but whose name I don't remember) was a bigger
> fan of Algol than C. Thus he wrote a complete set of C macros that allowed him to
> write that debugger in an Algol like language that got macro expanded into C.
> So yes, it has been done in the C community. The C macro facility is very weak as
> I've said so the reason it's not been done more has, I believe, more to do with the
> lack of power of the macroexapander than the lack of desire to extend the control
> forms of C.
>
The author was Bourne and he also wrote the standard shell in it. I
don't think it supports your position though since "Bourgol" was
cursed for the next 20 years by everyone who had to maintain the
code. If you take into account the number of Unix ports in that
period, this prank may have costs millions of dollars in wasted time.
--
Lieven Marchand <m...@wyrd.be>
She says, "Honey, you're a Bastard of great proportion."
He says, "Darling, I plead guilty to that sin."
Cowboy Junkies -- A few simple words
Yeah. I'm trying to keep the examples short; imagine more after
do-some-more-stuff, including other possible return points.
Tim
In article <MPG.15febe21...@news.dnai.com>, John Foderaro wrote:
> In article <slrn9pa3p...@oscar.eng.cv.net>, ma...@oscar.eng.cv.net says...
>> What I think Erik is saying is that they should pull this non standard
>> stuff from there production code that they ship to customers.
>
> if* is a macro. We ship our code compiled and during the
> compilation process macros are expanded and are not
> referenced in the compiled code. Is this what you want?
>
Well there is no lisp shiped in compiled code it is all machien code
by then, the nature of compiling remember. What I would like to see,
if I become a franz customer, is the removal of gratuitus and
deliberate inconpatabilities with the standard. Franz states they are
a CL vendor and they seem to be atacking CORE ANSI CL CINSTRUCTS
because of the aproved use of an inferior construct to replace it in
code that franz clames is production that franz as a CL vendor shows
the world both opensource and commerical. What I would like is to see
the if* macro DIE and dissapear from the world, it is illconcievd,
lacking in technical merrit and an assult on core ANSI defined CL
functionality. I would be happy if all the if* krud was removed from
all files that franz has the copyright for.
> Our open source modules (AllegroServe, imap, smtp, etc) are shipped
not MY but our, did you get talked to reciently by
management/coworkers?
> in a compiled form and for some of them the source is also shipped
all open source products ship or make avalable source not some of
them.
> (or pointers are give to web pages where the source can be found).
> Does this come under 'production code' in your mind? Or is this
> different. If it's under production code does that mean that
> Erik is saying that all if*'s should be removed from all those
> open source modules?
first why are you bringing Erik in to this you are replying to my
comments not his. let me say what I think shoud happen re if*:
IFF it is copyrighted by franz if* should be banned/removed from the
file and standard branching constructs used to replace them.
>
>
>> This get back to the "I donated allegroserv" line I
>> asked you were you paid to do this work and have received no answere
>> so I guess that is a yes.
>
> It's definitely the case that Franz paid for my time (and the time
> of others) to develop the open source modules that we distribute.
> I'm happy you've given me an opportunity to give Franz credit for
> spending money on something and donating it to the community.
>
>
Ah so no only did you not donate your time you also took credit for
work you did not even preform so you stole from your employer and your
coworkers the credit they were due. That is just a fucked up and very
very very VERY STUPID thing to do in a fourm that some of the people
at franz read. "Do not shit where you eat" is GOOD advice try
following it sometime.
one last thing, getting caught in a lie is not an opportunity it is a
demonstration of sloppy work on the liers part that is all.
And now a quick C question for John:
why is there so much use of the:
if {}
else if{}
...
else{}
in C when it has a switch statement? there is a technical reason,
what is it? And how does this prove that it is not needed in common
lisp?
no help from the audence please
marc
Ok I'm confused. I explicitly say that something is my opinion and
you say that it's not an opinion.
You then give this example:
"When talking about biology, use the
Punctuated Equilibrium model of evolution instead of the bogus
religious explanations ... it should be obvious now why Creationism is
a bad idea."
supposedly intended to mirror my text and you say it is "indeed my opinion"
even though no where do you say "In my opinion..".
I'd say that my statement and your statement are both opinions, I was
just more explicit about mine being an opinion. The statement I
just made about them both being opinions was an opinion but I believe
one that most people share but obviously you do not.
"The 49ers will win the Super Bowl this year."
Is that an opinion or have I just insulted everyone who is a fan
of another team?
Dude, you are seriously confused about how open source works and also
about who John Foderaro is in relation to Franz. Maybe you should chill
out a bit and investigate how the major contributors to your favorite open
source project get funded and how they refer to their contributions in
casual conversation.
Tim
Looks like the THEN following an IF* is totally noise,
unless John is allowing the test position to contain
more than one expression. Doesn't Lisp abhor vacuous
keywords? One could remove THEN from the macro
and in IF* uses, either keep that area blank or use
your commented THEN when an urge is felt to highlight
the start of a then-branch.
--d
> In article <xcvvgiy...@conquest.OCF.Berkeley.EDU>,
> t...@conquest.OCF.Berkeley.EDU says...
> > No, it is NOT just an opinion. "When talking about biology, use the
^^^^^^^^^^^^^^^
^^^^
> > Punctuated Equilibrium model of evolution instead of the bogus
> > religious explanations ... it should be obvious now why Creationism is
> > a bad idea." The above is indeed my opinion, but some opinions
> > generalize to others.
>
> Ok I'm confused. I explicitly say that something is my opinion and
> you say that it's not an opinion.
>
> You then give this example:
> "When talking about biology, use the
> Punctuated Equilibrium model of evolution instead of the bogus
> religious explanations ... it should be obvious now why Creationism is
> a bad idea."
>
> supposedly intended to mirror my text and you say it is "indeed my opinion"
> even though no where do you say "In my opinion..".
>
> I'd say that my statement and your statement are both opinions, I was
> just more explicit about mine being an opinion. The statement I
> just made about them both being opinions was an opinion but I believe
> one that most people share but obviously you do not.
Sure, an opinion. But not "just" an opinion.
> "The 49ers will win the Super Bowl this year."
This is qualitatively different.
I mentioned it only to refute this point:
----
From: "Pierre R. Mai" <pm...@acm.org>
in Message-ID: <87r8tow...@orion.bln.pmsf.de>
Even with C's pre-processor macros it is possible to do
#define BEGIN {
#define END }
or even
#define IF(x,y,z) ((x)?(y):(z))
But no serious C user will ever contemplate doing such a fundamentally
stupid thing, let alone any expert C user.
----
I agree that Bourne (thanks for the reminder) went way overboard
and I would never condone writing a whole new language
inside Lisp (which is why i'm no fan of the loop macro by the
way).
not really since the 'then' can be 'thenret' to allow you
to specify the cond behavior where it returns
the value of the predicate
(cond ((testit))
...
)
But more importantly when you have big predicates the
'then' is a visual cue to allow you to find the
then clause. As I've said, I don't mind typing a
few more characters if it makes the code easier
for me to read later on.
Perhaps you could then make the THEN optional, so that
then some of the snappier IF*s, where the THEN is just
clutter and not an aid to readability, can be
then written and read easily.
--d
Why? He did lie about what his contributions were to the project in 2
key instances:
1: my turned to our for allegroserv
2: donated turned into franz paid/ordered me to do it, he is an
employee after all.
In any projects one of the forms of compensation for work well done is
bragging rights. He stole from his coworkers who did the work by
claiming he did it and he stole from franz by claiming he bore the
monatery hardship of funding this project with his time when franz
paid him to do the work. Theft is theft and durring the course of
this discussion the only time I can remember him even attempting to be
civil is tuesday morning his time, after he probably got to work or
work calle him and had a little chat about what the fuck he was doing
this weekend, He did make some emotional appeals after editing posts
for content to try to gain support but I do not considder that civil
but self serving nothing more or less.
marc
Janos Blazi
-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
Check out our new Unlimited Server. No Download or Time Limits!
-----== Over 80,000 Newsgroups - 19 Different Servers! ==-----
what is wrong with cond that a long string of if* then elseif ... else
fixes and you can do the exact same logic with a standard ansi if:
(if a b (if c d (if e f g )))
so again why do I need yours?
marc
ps I am just learning lisp so there may be a stupid syntax error in
the above.
marc
> In article <9n3cnc$c98$0...@216.39.145.192>, Tim Moore wrote:
> > On Tue, 4 Sep 2001, Marc Spitzer wrote:
> > Dude, you are seriously confused about how open source works and also
> > about who John Foderaro is in relation to Franz. Maybe you should chill
> > out a bit and investigate how the major contributors to your favorite open
> > source project get funded and how they refer to their contributions in
> > casual conversation.
> >
> > Tim
> >
>
> Why? He did lie about what his contributions were to the project in 2
> key instances:
> 1: my turned to our for allegroserv
It is my understanding that Foderaro is the primary author of
Allegroserve. I suspect that "our" is him being generous.
> 2: donated turned
into franz paid/ordered me to do
it, he is an
> employee after all.
>
> In any projects one of the forms of compensation for work well done is
> bragging rights. He stole from his coworkers who did the work by
> claiming he did it and he stole from franz by claiming he bore the
> monatery hardship of funding this project with his time when franz
> paid him to do the work. Theft is theft and durring the course of
Maybe on your planet. You are demanding a standard of attribution that I
have never seen applied in the open source "movement." To use a personal
example, I feel perfectly comfortable referring to "my" port of gcc to HP
PA-RISC, even though Hitachi funded the work. After all, we are among
programmers here, not sponsors and lawyers. Going beyond my small
contribution of years ago, you don't see RMS and Torvalds thanking their
sponsors and employers every time they mention some part of GNU/Linux.
Torvalds works for TransMeta; duh. Foderaro works for Franz; I can't
imagine any reasonable person thinking that someone else paid him to write
AllegroServe, that he did it in his free time, or that he ought to
properly attribute credit to them every time it comes up in conversation.
That being said...
> this discussion the only time I can remember him even
attempting to
be > civil is tuesday morning his time, after he probably got to work or
> work calle him and had a little chat about what the fuck he was doing
> this weekend, He did make some emotional appeals after editing posts
> for content to try to gain support but I do not considder that civil
> but self serving nothing more or less.
Foderaro is one of the founders of Franz. Franz is not a public company
so the details of ownership are none of our business, but I imagine that
he is entitled to use "Franz" and "my" somewhat interchangably. That
right does assign a responsibility that he seems somewhat reluctant to own
up to, but claims of him ripping off co-workers and stealing credit from
Franz are just plain silly.
Tim
A bigger problem with adding comments is that they're not actually
part of the syntax, and when they get out of step with the code they
will serve more to confuse than to elucidate. Why would I want to
fake syntax with comments when I could write real syntax?
ObPersonalPreference: I'd still rather be using COND anyway. AIF (and
a smattering of other anaphoric macros) is about my only normal use of
"syntax" macros.
-dan
--
http://ww.telent.net/cliki/ - Link farm for free CL-on-Unix resources
> You cut off all the fingers on one hand? Talk about serious
> commitment. :)
No, there are three digits to the finger (or toe). Still eerily reminiscent
of a Roald Dahl story.
Philip
--
Real programs don't eat cache (Malay)
-----------------------------------------------------------------------------
Philip Lijnzaad, lijn...@ebi.ac.uk \ European Bioinformatics Institute,rm A2-08
+44 (0)1223 49 4639 / Wellcome Trust Genome Campus, Hinxton
+44 (0)1223 49 4468 (fax) \ Cambridgeshire CB10 1SD, GREAT BRITAIN
Neither do they claim that they _donated_ their work to anyone. In fact,
funding being what it is, they refer to it as their work, but both RMS
and Linus have always been careful not to speak about "donating" it.
_I_ would consider saying that I donated something only if I had funded
it myself, and since I have in fact funded and donated a lot of stuff
over the years, to university computer clubs, to the SGML community, etc,
but I did not use "donate" when in fact somebody else donated money to
fund my work. I expect the same standard of honesty from others when
referring to what one gives away. If it is not yours to donate, it is a
bad idea to say that you did. This applies to the funding, not the work.
///
If I remember correctly allegrostor was announced as a working
finished, version 1.0, product that only ran on ACL at the time. And
that franz had no intention of porting it to anything else. It was
treated like any other product and just happened to cost nothing. I
would not call this an opensource movement type of operation. It was
pure commerical development so I do not see how any of the opensource
stuff applys.
>
> That being said...
>
> > this discussion the only time I can remember him even
> attempting to
> be > civil is tuesday morning his time, after he probably got to work or
>> work calle him and had a little chat about what the fuck he was doing
>> this weekend, He did make some emotional appeals after editing posts
>> for content to try to gain support but I do not considder that civil
>> but self serving nothing more or less.
>
> Foderaro is one of the founders of Franz. Franz is not a public company
> so the details of ownership are none of our business, but I imagine that
> he is entitled to use "Franz" and "my" somewhat interchangably. That
> right does assign a responsibility that he seems somewhat reluctant to own
> up to, but claims of him ripping off co-workers and stealing credit from
> Franz are just plain silly.
>
> Tim
>
>
I did not claim I commented on what he wrote, he went from my to our
and donated to I was paid for it. both of the claims poved false by
his own admission. Add to this the other questionable tactics he has
used in this discussion, why should I give him the benafit of the
doubt when I have seen no evadence that he merrits such
considderation? I do not know him personaly and I could be completely
wrong but I do not think I am.
marc
This is a good question. The reasons that I feel it shouldn't
be optional are
1. The 'then' is there to separate the predicate from the consequent.
I believe that readability is enhanced if you highlight those
places in your code where control flow is unusual. Since
control may flow from the predicate right over the consequent
this is one of those places. And no, if* doesn't highlight
all the cases where that can occur, but it's a start.
2. by nearly always having a 'then' there, you don't have to read
the word to see what it says (what if it says 'them' rather than
'then'. Thus in practice while there are more 'keywords' in
the code due to the 'if*' form you don't really have to read them
to see the structure of the code, the indenting itself predicts
what the keywords are.
I thought we were still talking about if/when/unless, but it also applies
to case sensitivity. Teaching people to abhor upper-case and tell them
to use lower-case also destroys the common knowledge. Making standard
functions return non-standard values is _really_ bogus.
If they worry so much about upper-case versus lower-case, there are two
easy steps: set *print-case* to :downcase and make the keyword argument
:case-insensitive to apropos default to t. They do neither, but seem to
want people use their very incompatible version instead. I have been
working on a solution that does not destroy conformance at all -- and it
turns out to be really easy to support in the framework that Franz Inc.
has already built to support their special set-case-mode. This is about
the willingness to remain conforming while making serious changes, or
lack thereof, to be more precise.
But as long as we talk about this issue, it is in fact possible to let
(common-lisp:symbol-name 'foo) return "FOO" and have something like a
(common-lisp-lower:symbol-name 'foo) return "foo". This is the kind of
thing the package system should have been able to deal with, shadowing
some of the important functions. The reader needs to be able to deal
with a parameterization of which functions to call, however, and the
specification for this will have to be extra-standard. This means that
it should probably go in the readtable. Since the readtable already
supports everything we need for a lower-case Common Lisp to work, all we
would really need is the ability to retain the standard functionality in
addition to the lower-case versions. This should be doable without
having to break anything, if only you are willin to look for it. That
would make it possible to intermix standard and lower-case code, too,
which is currently impossible with the separated schemes used today.
> Intelligent people can disagree with majority opinion and/or hold silly
> opinions of their own without being pilloried as the enemy of the state.
> If not, it's the state and its defenders that I'd question, not the
> individual.
Grandiose speech. Competely irrelevant to this case, however.
///
> On Tue, 4 Sep 2001, Marc Spitzer wrote:
>
> > In article <9n3cnc$c98$0...@216.39.145.192>, Tim Moore wrote:
> >
> > > Dude, you are seriously confused about how open source works and
> > > also about who John Foderaro is in relation to Franz. Maybe you
> > > should chill out a bit and investigate how the major
> > > contributors to your favorite open source project get funded and
> > > how they refer to their contributions in casual conversation.
I concur completely with Tim here.
> If I remember correctly allegrostor was announced as a working
> finished, version 1.0, product that only ran on ACL at the time. And
> that franz had no intention of porting it to anything else. It was
> treated like any other product and just happened to cost nothing. I
> would not call this an opensource movement type of operation. It was
> pure commerical development so I do not see how any of the opensource
> stuff applys.
[You mean allegroserve, not allegrostore I think]
I think making the source available under an open-source license which
allows, for instance, people to port it (as they have done) to other
implementations freely is rather different than `just happening to
cost nothing' and more than adequate to classify it as open source.
I don't want to take any sides in this whole battle, but it's kind of
annoying that some people seem to be so entranced by the jkf-bashing
that they're making all sorts of misleading statements like the one I
quote above. I guess I should expect this on usenet by now though...
--tim
The more I looked into the two languages, I started asking friends who
are developers with more experience than me who are using Delphi
(pascal - which I have used before) and VB (because of where they are
working now), about Python and Lisp. They admitted to knowing little
about Python except that it was a scripting language which seemed to
imply saying it all (something about limited access to interfaces
which was greek to me). Lisp on the other hand was considered a
really cool language but useless for anything except manipulating
strings. I have to admit that this threw me off, and I was determined
to learn lisp if for no other reasons than for the way it was
improving my approach to development, and then move onto Python for
practical purposes.
I am glad that I have stuck it out as I have been finding that
although so far I haven't managed to start digging into the system
part of the implementations I have been looking at, the way in which
it allows me to code robust algorithms, and build in steps means that
I am going to be moving hell and high water to keep it as the core of
my applications, and the power is amazing...
Finally my point: That offhand comment I took seriously because of
its source, this was an experienced developer, and if I had not been
of a sufficiently impractical bent to have spent a lot of money and
years pursuing the study of philosophy, I would have dropped looking
farther into Lisp. It is an amazing language and facility but suffers
from some seriously bad press as an impractical language that all
these eggheads are using to try and create artificial intelligence
with, and take over the world or get us all killed in the
process(;-)). Who would have thought it was a powerful and practical
language that could do things other languages only dream about. Even
now I have been secretly studying it on my own time, and when I run
across a cool way of doing or thinking about a problem I have a huge
translation problem to recreate the solution at work in the languages
I have to use there.
Lisp needs a good press core:-)
At the moment as I found out there are people who have gone in
different directions who studied Lisp at uni but never really used it
being the bottom-line on Lisp's practicality, and this is not right.
At the moment I have not managed to be good enough to create anything
practical with it, and am working hard at doing this and then I will
be busy debunking the myths I run into with cold hard code, and
hopefully moving to a job where I can use it all the time.
So I am a recent convert and I hope there are more of me out there and
as I am opinionated I will have no problem telling employers that I
will be able to get that project for them in something they have heard
of, or in 1/3 the time using Lisp.......
God I do go on..
> The good: lisp people tend to be the kind of people who question things and
> think hard about elegance and the Right Thing (certainly compared to most of
> the other large programming communities) People who question find fault.
> But I agree with Erik that this can be done in a constructive and positive
> way without "throwing out the baby with the bathwater"
>
>
> > Can we do this? Can people who are still enthusiastic about Common Lisp
> > the language, even after reading a 20K long news article, please raise a
> > hand and express their feelings? Can you stand up and say "I _love_
> > Common Lisp!" in a crowd and feel proud of yourself?
>
> I _Love_ Common Lisp!
>
ME TOOOO!!!!
> (I am also blessed to have worked with it in my last two jobs as well as my
> current position!)
>
I am hoping to share your good fortune.:(
>
> > I actually believe thare are enough Common Lisp enthusiasts out there to
> > make a difference
>
> I believe so... time will tell.
>
> Coby
> Here's an example. I'm not attempting to prove that "early out" has a
> huge advantage with these toy fragments, but merely to illustrate what I'm
> talking about:
That is exactly what I was trying to say in an earlier article, but
didn't put so clearly. I have plenty of code which has big hairy
functions which have to find and validate a lot of state information
before doing some operation where there are many possible was to
fail. They end up looking like this:
(defun do-one-conversion (....)
;; Returns successp, new state, optional comment.
;; signals CONVERSION-ERROR if something really bad happens (state
;; may be bad)
(flet ((succeed (new-state &optional comment)
(return-from do-one-conversion t new-state comment))
(fail (&optional comment)
(return-from do-one-conversion nil nil comment))
(bad (...)
(error 'conversion-error ...)))
....
(unless thing-is-ok-p
(fail "Thing is not OK..."))
....
(when donep
(succeed 'fishy "OK, new state slightly smelly"))))
Of course some would argue that I shouldn't write such hairy functions
that I need this kind of internal protocol, but for the system
concerned it was rather hard to see how to do it otherwise (you'd need
to see the code to see why).
--tim
> How about
>
> (defun do-something (input1 input2)
> (if (and (is-valid input1)
> (is-valid input2))
> ; then
> (let ((foo (set-stuff-up input1 input2)))
> (if (simple-situation input1 input2)
> foo
> (do-some-more-stuff input1 input2 foo)))
> ; else
> (error 'invalid-inputs input1 input2)))
>
>
> I don't use these comments unless I am really confused, but maybe
> %10 of the time or if I am trying to be too clever for my own good
> I end up needing to stick "; else bla" or "; implicit else" if I abuse
> when with return etc. I don't see a big difference here, but I also
> think my server missed the beginning of the thread.
One difference is that if* gives you implicit PROGN's.
> Being blind to bad sides of your kid is a good start to raise a
> homicidal maniac. Look what happened to C++ or perl ;).
Nobody advocates turning a blind eye to bad sides of CL. The point is
that incompatible improvements should be an *option*, and/or should be
made to work alongside the standard way of doing things, until the
standard is updated to include said improvements. An update of a
standard is done through an orderly process, not through SNIPING and
COUP D'ETAT. That way you can have a diverse community without the
members stabbing each others backs.
--
Håkon Alstadheim, Montreal, Quebec, Canada
(defmacro then (&body body)
`(progn ,@body))
(defmacro else (&body body)
`(progn ,@body))
///
A curious thing is that Foderaro could have easily
_extended_ IF to his IF* in a backward-compatible
way if he'd wanted.
0. Have IF* do everything that it's currently
spec'ed to do, with the following mods:
1. Make THEN always optional -- which, among other
things, makes (IF* a b) equivalent to (IF a b).
2. If there are no THENs or ELSEs among the IF*-form's
subforms, assume an ELSE after the second subform.
Thus, (IF* a b c) is equivalent to (IF a b c).
Also, (IF* a b c d ...) is eqv to (IF a b (PROGN
c d ...)), as in Emacs.
3. Since IF* is now completely backward-compatible with
syntactically correct uses of IF (see 1 and 2
above), simply call the new construct IF.
4. People who use the new IF as the old IF won't have a
complaint. They can only run into problems if their
use of the IF would have been an error in the old IF.
(Minor caveat: THEN and ELSE must be known to be
macro keywords.)
5. Add several minutes to your life from having avoided
flamage for introducing a new conditional, while
retaining all the features you want to keep you in
a happy condition (!).
6. Re-lose those minutes when users run your code in a
CL that doesn't have the new IF.
--d
Yes.
>
> I think making the source available under an open-source license which
> allows, for instance, people to port it (as they have done) to other
> implementations freely is rather different than `just happening to
> cost nothing' and more than adequate to classify it as open source.
correct, I was realy tring to comment on the development model which
was not a opensource until ver 1 when it was announced and
opensourced. That the development model used commerical before that
was the point I was trying to make.
>
> I don't want to take any sides in this whole battle, but it's kind of
> annoying that some people seem to be so entranced by the jkf-bashing
> that they're making all sorts of misleading statements like the one I
> quote above. I guess I should expect this on usenet by now though...
>
> --tim
>
>
I do not know jkf and am not interested in 'bashing' him. But he set
the tone for the discussion when I looked at his coding standard and
he said in it essentialy that if you do not do it my way you are a
stupid person and I did not agree with him. Now that is insulting to
me. And through out the disscussion that we engaged in he did nothing
to improve the tone. Now perhaps I was a bit too adverserial but I do
not think I was.
marc
> > Being blind to bad sides of your kid is a good start to raise a
> > homicidal maniac. Look what happened to C++ or perl ;).
>
> Nobody advocates turning a blind eye to bad sides of CL.
Neither do I, but you trim that part of the quote.
You seem to miss the context in which my reply was written. My
message was among the very first replies, but I guess most of the
thread contents is now "above" my message in the thread.
SY, Uwe
--
u...@ptc.spbu.ru | Zu Grunde kommen
http://www.ptc.spbu.ru/~uwe/ | Ist zu Grunde gehen
Try to replace the definition of a special form in your favorite lisp.
If I had exported code which required people to redefine a special
form in their Lisp to run it, I would have been criticized and
correctly.
As it is I just used a macro which can be added to any Common Lisp
and thus makes my code a valid Common Lisp program.
> (defmacro then (&body body)
> `(progn ,@body))
> (defmacro else (&body body)
> `(progn ,@body))
I've recently had to deal with some code which did exactly this. So
it had a very nice syntax (well, if you like that kind of thing)
(if x
(then ...)
(else ...))
The problem was that the macros were defined just exactly as you have
them above, so there was no enforcement of the syntax at all. So
things got completely mixed up, and you'd find things like:
(if x
y
(else ...))
and even worse, there was no mechanism to prevent THEN and ELSE just
finding their way into code outside an IF, which they did on occasion
due to editing errors.
All this was apparently because the people who wrote this framework
either didn't understand or didn't want to use the package
system. They wanted you to *have* to write THEN and ELSE (they had a
kind of sub-CL dialect in which you were meant to write), but rather
than defining a SUB-CL package in which they would have their own IF
which would check for the syntax they wanted, they'd just defined
macros like this.
Well, I don't work on that system any more, and this is one of the
things I don't miss. There were other horrors.
--tim
I don't think it's compatible.
(let ((then 3))
(if t then 4))
--tim
Geez, somebody _did_ that? For real? That is just sickening.
I guess I should have "commented" the code and explained why I thought it
would be an obvious "bad joke", on par with #define BEGIN { in C, but
which would illustrate that having implicit progns is not such a big deal.
This might also be a good time to state that I really want to use progn
in multi-form consequents and alternatives, to increase the readability
of complex if forms. That is, we already have all the mechanisms we need
to identify more complex forms. And wrapping a single form in a progn is
real easy with a real editor. Just like loop forms are hard to navigate,
so are keyword-based "separators". But I guess some people want progn to
go away so hard they just have to reinvent it badly.
///
I would reommend an appointment with a shrink and extended homeopathic
treatment. Erik, you should read you own (non-technical) posts
sometimes to see how irrelevant _they_ are. You may sure be a smart
guy with Lisp, but otherwise you fail to understand people or what
they seem to be saying or the context _completely_ and _utterly_.
S
What _are_ you talking about?
> If I had exported code which required people to redefine a special form
> in their Lisp to run it, I would have been criticized and correctly.
Why? What is this "replace" and "redefine" about?
> As it is I just used a macro which can be added to any Common Lisp and
> thus makes my code a valid Common Lisp program.
And shadow-importing the symbol if from a different package than the
common-lisp package into your application package, with a new macro
definition would _not_ have made it a valid Common Lisp program?
I have often gotten the impression that you are still programming in some
ancient pre-Common Lisp langauge and do not really know what is in Common
Lisp these days, or at least do not use it, but I wonder if you have ever
studied the standard to see what is there. Sometimes, "experience" can
get a little stale.
///
> Before I launch into this, I want to say that I have a lot of respect
> for Franz, Inc. Allegro CL is first-rate, and no tool vendor I've ever
> dealt with does customer support better, period.
Thanks for the kind words.
> That said, reader case issues have had a long history of being
> low-priority at Franz. Just to be sure of the following, I went and
> checked the heap of Allegro manuals in my office.
> As of Allegro 4.2 (my copy is dated January, 1994), readtable-case was
> still listed as unimplemented in the ANSI conformance section. It
> finally showed up in Allegro 4.3 (dated March, 1996 - it may have
> appeared first in a 4.2.x release, I don't have those documents to
> hand).
A little history on this:
Franz Inc's tradition regarding case mode came from the very popular
verion of lisp on unix called Franz Lisp. When CLtL (first edition)
was written, long before the Ansi Common Lisp spec was even conceived,
for the sake of continuity and an upgrade path, we provided our
customers with a choice, to either decide on the case-sensitive style
that they were used to, or to go with the CLtL style of a
case-insensitive reader. Many customers chose one mode or the other,
and there tended not to be too much mixing of the modes.
You may recall being one of those customers. Our first encounter with
you regarding case-sensitivity was in October of 1989, in spr506. In
that spr you complained about *print-case* not doing nice things
with defstruct accessors. We took the bug, and noted that a workaround
was to use the :case-sensitive-lower mode that was available. It
turned out that you had also come up with a suitable workaround (some
advice around defstruct), and had presented both options as viable.
Now it is possible that you were unhappy with the outcome of that spr,
but there was no indication of that. It is also possible that you
were unhappy with case sensitivity issues, but we did not hear from
you again about case until 1996, when you requested readtable-case
in spr14689 (by that time, 4.3 was out and we informed you of that).
Meanwhile, we got two inquiries into readtable-case before the Ansi
standard was ratified in 1994, and in each situation there was no
objection to the workaround we offered, nor to waiting for the
implementation of readtable-case until we could get to it. At the
time, we were also trying to track other ANSI compliance issues.
We always gave highest priority to the compliance issues which had
no workaround, or to the issues which had been requested most from
customers. Unfortunately, one or two inquiries for readtable-case
was far outnumbered by the many inquiries into other conformance
issues like logical-pathnames, which we had also not implemented
until 4.2.
In March of 1994, we started getting more requests to implement
readtable case. These were among the first to ask specifically
for the implementation as a part of the standard, and these
queries were more urgent in nature. So, sometime that same year,
the implementation was started, bounded in time by the first CVS
recordings of the implementation in September orf 1994. It was
first made avaialable in May of 1995 in 4.3.alpha, and then it
was finally made available officially in version 4.3 in May of 1996.
If this seems like quite a long time to implement a feature, I agree.
However, at that time, _all_ features took a long time for us to
implement, and it took us a long time to get from release to release;
in fact, it took one year to get each of 4.2.beta and 4.3.beta to
their final stages. Some of the reasons for this were:
- Our development team was split into two groups; the one not working
on our standard unix product was working on the Procyon-based
Windows product, which was to be a stopgap solution while we ported
our unix version to x86 and then to windows. And since the Procyon
lisp was essentially a CLTL lisp with CLOS, it took a lot of
resources to even get it close to the level of ANSI compatibility
that we had achieved so far on the unix product.
- It was arguably the dead of the AI winter, and customers were
scrambling to reassure themselves that they were making the right
decision by chosing (and continuing to use) Lisp. Lisp was still
thought by some to be big, and slow, and dead. A good portion of
our time in those years was spent optimizing our code, helping
customers optimize their code, and optimizing our code (some more).
This also caused a drain on resources to do other important things.
- We had a huge influx of feature requests, for connectivity, for a
better foreign-functions interface, for ports to other architectures,
and so on. We placed a high priority on conforming to the standard,
but we had to also respond to customer requests and to ensure that
they were able to succeed with their own programming needs and products.
There were so many of these at that time that we had to pick and
choose which pieces we would do then, and which we would later.
> ANSI voted readtable-case into the language in June, 1989; the whole
> standard passed in December 1994. Franz had plenty of warning that this
> needed to be done, but apparently chose to put it off as long as
> possible - Allegro was tracking other ANSI conformance issues closely at
> the time (the char-bit functions were deprecated in at least 4.1 - March
> 1992), but not this one. I'd love to hear there was a reason for this
> other than developer dislike for that part of the standard.
The reason is not easy to state succinctly - call it priority; call
it triage; call it resource allocation and management, but it is
definitely not due to dislike of the standard in any way. I hope
that my lengthy timeline above has given you a sense of what really
went on at that time, and hopefully it has reassured you that our
motivations have been good, even as our execution may not have been
perfect.
> I remembered this, because around that time I needed a case-sensitive
> reader for compatibility with a vile little lex/YACC-based S-expression
> reader in use by other implementors in my team. I had extolled Lisp's
> virtues to the rest of them, and it was embarrassing for me to have to
> say that I couldn't do a case-sensitive read in Allegro (actually I
> could, if I was willing to set a global flag, break all my existing
> code, and abandon CLX).
If you had legacy code which you didn't want to change to make
compatible between both modes, I can understand that (although at such
time, it would have helped us to have told us this, so that we
might have been set the priorities differently).
However, almost from the beginning of its lifetime, CLX has been
compatible with the case-sensitive mode, and so you would not have
had to abandon that.
--
Duane Rettig Franz Inc. http://www.franz.com/ (www)
1995 University Ave Suite 275 Berkeley, CA 94704
Phone: (510) 548-3600; FAX: (510) 548-8253 du...@Franz.COM (internet)
How did you see into my mind and discover what I did not _understand_
just because I point out that it is completely irrelevant? Does this
somehow trigger your defense mechanisms such that you need to post your
personal comments about someone else, which is certainly completely and
utterly irrelevant here?
Please accept a hint: Understanding and agreement are orthogonal.
///
> ObPersonalPreference: I'd still rather be using COND anyway. AIF (and
> a smattering of other anaphoric macros) is about my only normal use of
> "syntax" macros.
Do you use the variation that unconditionally binds the result of the
predicate to THIS (or something similar)? That drives me nuts,
personally, so I use IF-LET:
(if-let (damn-thang (find-the-damn-thang))
(do-the-damn-thang damn-thang)
(do-something-else))
which I like much better. The problem I have is how to extend this to COND:
(binding-cond thang
((find-the-damn-thang) (do-the-damn-thang thang))
((find-some-other-thang) (do-some-thang thang))
(t (do-something-else)))
just doesn't seem as nice. That's what I use, but I'm kind of
uncomfortable with it...
I'll risk grevious personal injury and mention that Scheme has a bit
syntax for this. If the first element after the condition is the
symbol '=>', then the second element after the condition is applied to
the result of the condition. Here's an example:
(cond ((assq 'key table) => #'cdr)
((assq 'default table) =>
#'(lambda (x) (format t "Using ~d" x) x))
(t 42))
Yeah, I know about that, but I find it less satisfying than my
BINDING-COND, because that whole => thing is, well, weird. It's using
magical symbols for something that seems like it should be do-able in
a lispy way
> (cond ((assq 'key table) => #'cdr)
> ((assq 'default table) =>
> #'(lambda (x) (format t "Using ~d" x) x))
> (t 42))
Aside from that, the first clause seems okay. The second, though,
yuck. I don't like using anonymous functions/closures like that,
unless I have to; I use with-FOO instead of call-with-FOO.
Other than the following explanantions and quibbles, I'm satisfied. And
impressed with the depth of your spr database. :-)
Duane Rettig wrote:
>
> Bob Bane <ba...@removeme.gst.com> writes:
>
> You may recall being one of those customers. Our first encounter with
> you regarding case-sensitivity was in October of 1989, in spr506. In
> that spr you complained about *print-case* not doing nice things
> with defstruct accessors. We took the bug, and noted that a workaround
> was to use the :case-sensitive-lower mode that was available. It
> turned out that you had also come up with a suitable workaround (some
> advice around defstruct), and had presented both options as viable.
> Now it is possible that you were unhappy with the outcome of that spr,
> but there was no indication of that. It is also possible that you
> were unhappy with case sensitivity issues, but we did not hear from
> you again about case until 1996, when you requested readtable-case
> in spr14689 (by that time, 4.3 was out and we informed you of that).
>
I was working on a project using Allegro in 1989-1990, as the last gasp
of Xerox AI Systems/en-vos. I didn't have a chance to use Allegro
on-the-job again until 1996, for a different employer (my personal AI
Winter), so for me seeing that readtable-case was still unimplemented in
4.2 was a bit of a timewarp - I didn't know the history.
> > I remembered this, because around that time I needed a case-sensitive
> > reader for compatibility with a vile little lex/YACC-based S-expression
> > reader in use by other implementors in my team. I had extolled Lisp's
> > virtues to the rest of them, and it was embarrassing for me to have to
> > say that I couldn't do a case-sensitive read in Allegro (actually I
> > could, if I was willing to set a global flag, break all my existing
> > code, and abandon CLX).
>
> If you had legacy code which you didn't want to change to make
> compatible between both modes, I can understand that (although at such
> time, it would have helped us to have told us this, so that we
> might have been set the priorities differently).
>
> However, almost from the beginning of its lifetime, CLX has been
> compatible with the case-sensitive mode, and so you would not have
> had to abandon that.
>
Sort of. The 4.{1,2,3} manuals all say in bold print that
excl:set-case-mode may not be called after loading CLX, so using it in
the pre-built Composer image was right out. I suppose I could have
tried building a case-sensitive image, loading CLX and Composer into it,
making my sources (including other people's open-source code)
case-sensitive and loading them, but that sounded like more effort and
uncertainty than changing the non-Lisp S-expression reading code to be
case insensitive.
--
Remove obvious stuff to e-mail me.
Bob Bane
Didn't I sufficiently caution (as "minor caveat")
against such uses of THEN and ELSE? If I did not, I
hereby do.
--d
While binding and testing at the same time is useful, I find that I
either want it to be bound first and tested independently
(let ((damn-thang (find-the-damn-thang)))
(if damn-thang
(do-the-damn-thang damn-thang)
(do-something-else)))
or assigned to in the test
(let ((damn-thang))
(if (setq damn-thang (find-the-damn-thang))
(do-the-damn-thang damn-thang)
(do-something-else)))
or using more advanced control-flow mechanisms, more suitable when there
is no else branch and much more going on, such as an already established
block surrounding the forms at the appropriate level
(block nil
(do-the-damn-thang (or (find-the-damn-thang) (return))))
///
>* g...@google.com (Erann Gat)
>> I'd just like to point out one thing before I go. For about the last
>> five or so articles in this thread I didn't write the text you attribute
>> to me. I copied it from old postings of yours. It's been amusing
>> watching you argue with yourself.
>
> Huh? I argued against myself because you copied my words? Geez. Just
> how stupid are you? Just who _do_ you think you are fooling with this?
>
> But this is just the kind deception and evil we have come to expect from
> you. You only surprise in its magnitude, not at all in its character.
> You are such an idiot, Erann Gat. Get some professional help to get over
> your personal problems. And please take the prescribed medication before
> you post again, whether you cut and paste from newspapers or whatever
> else you need to copy from to pretend that you are not really speaking,
> yourself. I feel so much pity for you and your problems that I cannot
> even be angry at such a pathetic excuse for a person.
>
>///
I thought civilized people would not put up with the kind of invective that
has become common on this newsgroup lately. I tend to filter to the trash
any message threads being sent between Erik and anybody else, because I don't
need the negative stimulus. We all know Erik posts useful messages at times
(often, even) but the level of discourse he inspires probably drives many people
away.
I am trying to open my mind up to new things, and to try to see things
in a fresh light. Perhaps we should bask in the colorful language and insults.
I have discovered recently that the messages on this newsgroup are a
veritable treasure trove of colorful phrases, and ways of attacking the very
essence of another person. In this spirit, I am collecting them and making
a customized Eliza program. This program dares you to talk to it, and when
you do it responds using some of the language typically coming from this
type of discussion on c.l.l. This way, I can enjoy the experience of Erik's
flame wars without actually having a usenet connection. It becomes
positively apoplectic if you even mention certain names, like Erann Gat,
or John Foderaro. I am still looking for more colorful phrases and insults, and
I know you guys won't disappoint me.
By the way, I am serious about this--I will make the program available when
done.
But even more seriously...
I just want to say that some of the smartest people, and best programmers, in
the world are regulars in this group. This includes Erann, John, Kent, Duane,
Erik and all the rest of you who regularly contribute. I am proud to know all of
you. Yes, I love Common Lisp (oh god, I was trying to avoid saying it, but I
can't help myself) but I also love the community of intellects that form around
it. I believe that the lisp compilers I create are used by some of the most
imaginative, brilliant programmers around. This is what keeps me going.
This newsgroup is not the whole lisp community--far from it. But it does
include many long time lisp experts, and creative, passionate programmers. I
feel so lucky to be able to be a part of this. We all know we are different from
the programming masses. Maybe more akin to artists (or at least aspire to that).
When I see people in this group calling each other such nasty things, I can
barely believe it. There aren't that many of us--and we all will play an
important role in lisp's future.
Please, let's act like grown-ups. I don't believe technical expertise absolves
one from polite discourse, particularly in a public form like this. We all have
something in common, and that is our feeling that lisp offers some things that
more often-used languages do not and cannot offer. I believe that lisp is
poised to solve many of the programming problems that are coming down
the road. Such as truly intelligent web agents (where you don't know
if that poster, or that e-mail respondant, is a person or not). I just can't
imagine another language could do this better than lisp. The explosion of
server-side programming opportunities is great for lisp--it just shines.
And I say lisp, because I believe that Common Lisp is not the only language
definition nor the final one. I like it fine as it is, but I admit to the
possibility that others, perhaps more original thinkers then me, could come
up with improvements that would make lisp that much more exciting and powerful.
John Foderaro, AllegroServe is great. Thanks for all of your work you have done
with Franz.
Erann, thanks for helping to get lisp sent to Mars.
Erik, I know you have done some tremendous things with Lisp, and helped many to
better understand it's intricacies.
Roger Corman
I guess. However I suspect that this case is enough that this new IF
really is not compatible with the standard CL one, and will cause
significant and obscure lossage, since the case I gave partly reverses
the sense of the conditional - (if never-false then
(explode-the-world)). So I definitely do not think that IF could be
safely extended to IF* in a backward-compatible way - the caveats are
not minor!
--tim
> [...] This program dares you to talk to it, and when you do
> it responds using some of the language typically coming from this
> type of discussion on c.l.l. This way, I can enjoy the experience of
> Erik's flame wars without actually having a usenet connection.
[...]
> By the way, I am serious about this--I will make the program
> available when done.
Why not just ask Erik for his version?
--
John Paul Wallington
It's OKAY --- I'm an INTELLECTUAL, too.
I thought civilized people would be above your behavior, too.
> I tend to filter to the trash any message threads being sent between Erik
> and anybody else, because I don't need the negative stimulus.
Somehow, you think it is acceptable to post this. Why?
> We all know Erik posts useful messages at times (often, even) but the
> level of discourse he inspires probably drives many people away.
Yeah, of course it is my fault! That attitude is the core problem here.
It is somehow appropriate for this forum to discuss me and blame me for
it at the same time, as if you are all mindless morons who cannot help
themselves and I am the person responsible for everybody else's actions.
You do the exact same thing, Roger Corman, and you, too, think it is
somehow appropriate to discuss this as if it were a matter of fact.
If people, you included, could stop discussing _me_, there would be
nothing for me to be angry about, because the core problem I see is that
people have this bizarre personal need to attack _me_ every damn time I
say something about someone's _behavior_, and they certainly do not
confine themselves to _my_ behavior. _Are_ people so defensive and do
they really have so low self-esteem and self-confidence that they cannot
distinguish between their behavior and their person? That is, why do
they behave as if their behavior is always correct and should remain
unchallenged and preferably be lauded no matter how counter-productive it
is? There are people here who have an obvious and serious personality
disorder that they cannot back down from their position if it has been
criticized, and who start to attack the _person_ of those who criticizes
them. Why are such people posting to a newsgroup? They are clearly not
able to deal with normal human discourse and certainly not able to deal
with people who _will_ shoot down stupid suggestions or arguments.
In the case of Erann Gat, please do make the effort to see how he has
behaved towards me from the start in this thread. His behavior is not at
all my fault. That he cannot keep his personal needs away from the Net
is not my problem. That he attacks me so insanely as he does, does make
it my business to stop him. I have no other gripes about Erann Gat, but
a lot of people have personal gripes about me as a person far beyond
anything I have ever actually done to anyone. This puzzles me. I find
it very odd that semi-intelligent people need to be so obsessive about a
person that they cannot discuss whatever they (say they) want to discuss
but have to blame someone else for their very own despicable behavior.
> I am trying to open my mind up to new things, and to try to see things in
> a fresh light. Perhaps we should bask in the colorful language and
> insults.
Perhaps you should realize that by discussing me, you contribut to the
problem.
> I am still looking for more colorful phrases and insults, and I know you
> guys won't disappoint me.
I find your behavior more delibarate and thus much more dispicable than
those who post in obvios anger. Have you no self-respect?
> By the way, I am serious about this--I will make the program available
> when done.
Reconsider.
> When I see people in this group calling each other such nasty things, I can
> barely believe it.
I cannot believe how you found the personal need to post what you have.
> Please, let's act like grown-ups.
Do grown-ups discuss others as if they were things and casually place the
blame for many other people's behavior on a single person? Real grown-ups
are a tad more mature than that.
> I don't believe technical expertise absolves one from polite discourse,
> particularly in a public form like this.
So it is OK to be gravely insulting and grossly unfair if you are "polite"?
> And I say lisp, because I believe that Common Lisp is not the only
> language definition nor the final one. I like it fine as it is, but I
> admit to the possibility that others, perhaps more original thinkers then
> me, could come up with improvements that would make lisp that much more
> exciting and powerful.
Until we have it, it makes very little sense to discuss Common Lisp in
terms of what could have been or could be. No other language community I
know, have a higher regularity of people who argue just this way, and it
simply means that people will wait for the next great thing instead of
using this great thing while they can. It is if people refuse to use the
greatest language in the world simply because something better could be
made. To me, this simply says that people have too little need to use
these powerful tools, but around masturbating to it, instead, like people
do with Scheme or other "academic" languages.
///
A silent error would be deadly I agree. I was
taking as understood that THEN and ELSE would no longer
be available for use as variables. Of course to put
teeth into this proscription you would have to enforce
it -- OTTOMH, I can think of defining THEN and ELSE as
macros and/or symbol-macros that will cause them to
error loudly. Perhaps you can think of something else.
I am less persuaded that removing these symbols from
the pool of available variables is by itself
unacceptable. All macros (and even global function
definitions to a lesser extent) bring with them the
price that some variables become henceforth unavailable
for unencumbered use. The best we can hope for is that
unintended use of these symbols as variables will make
itself known as program error instead of creating
mischief in a running program.
--d
-john foderaro
Rest assured that you are not attacked unless you attack someone first.
Since you do that, the likelihood of you receiving criticism for it rises
dramatically. Quit it, and you will find that everybody responds
maturely. It is your own fault that you get the responses you get. Your
first response to my _technical_ issues with your IF* stunt was personal.
You set the tone, and have stayed by it since. That you now gripe about
losing the game you want to play and pretend that you are better than you
are is simply pathetic.
There is no need to talk about behaving better. Just behave better. If
you talk about it and fail, it makes you look so much _more_ juvenile,
but also hypocritical and pretentious. Guess again if you think this
makes you look better in anyone else's eyes.
///
sigh..
Please show me (and the rest of the readers) where I did that, or
if you can't please cease making misstatements about what I've said.
To make it easy for you here's the whole loop macro thread:
http://groups.google.com/groups?hl=en&safe=off&threadm=87ae09r4jk.fsf%
40asaka.latnet.lv&rnum=1&prev=/groups%3Fq%3Dgroup:comp.lang.lisp%
2Binsubject:the%2Binsubject:loop%2Binsubject:macro%26hl%3Den%26safe%3Doff%
26rnum%3D1%26selm%3D87ae09r4jk.fsf%2540asaka.latnet.lv
and here's the whole "What I want from my lisp vendor" thread
http://groups.google.com/groups?hl=en&safe=off&threadm=3B9682D0.187843DF%
40removeme.gst.com&rnum=1&prev=/groups%3Fq%3Dgroup:comp.lang.lisp%
2Binsubject:lisp%2Binsubject:vendor%26hl%3Den%26safe%3Doff%26rnum%3D1%26selm%
3D3B9682D0.187843DF%2540removeme.gst.com
* John Foderaro
> sigh..
>
> Please show me (and the rest of the readers) where I did that,
In your first response to my article in the loop thread about your
disgusting, demeaning, denigratory, and insulting "lisp coding standards"
document, your response reads as follows:
* John Foderaro in <MPG.15f588c27...@news.dnai.com>
| The sad thing is that the religious zealots seem to have taken over this
| newsgroup (or at least they are the loudest). I laugh at them and I hope
| you do too. I hope that I can get a message through to the scientists
| out there who understand that CL is just a language with good points and
| bad points and that we must figure out how to make CL better and
| continually relevant to the current computing world.
You really do not need "misrepresentation" to look like a hypocritical
idiot. In fact, misrepresentation could only _improve_ your image the
way you have been going on about it here. You have only yourself to
thank.
Here is a hint for you, John Foderaro: If you want to climb that high
ethical horse of yours, the way to avoid looking like a hypocritical
idiot is to _do_, not _tell_. But since you choose to present yourself
as someone who likes to talk about how mature you are and how juvenlie
others are when they behave smarter than you do, please accept this
advice: just answer the technical stuff and refrain from answering
whatever you want to respond to with your stupid personal crap. That
would _be_ mature. Talking about how mature you are is really juvenile.
///
> It is your own fault that you get the responses you get. Your
> first response to my _technical_ issues with your IF* stunt was personal.
> You set the tone, and have stayed by it since.
The response you quoted was not a response to you but to Coby Beck.
If we go up the tree to find the first ancestor message from you
we get to:
Message-ID: <32080033...@naggum.net>
http://groups.google.com/groups?as_ugroup=comp.lang.lisp&as_umsgid=%
3C3208003...@naggum.net%3E
Is this what you consider to be a message that simply
discusses the _technical_ issues of the if* macro without
getting into any personal attacks? [If that's the case I'd
sure not want to see what you consider a personal attack message].
Everyone can read the whole message from the link but here are
a few quotes so you can get the 'tone'
Do you want to deal with a person who goes out of his
way to insult something _great_ and who thinks marring it is necessary?
But it gets worse, much worse. The exact same kind of religious fervor
and irrationality applies to several other areas.
I could deal with the
IF* abomination and the exaggerated hatred for LOOP for a long time,
that you are willing to share the arrogance of a person who is
pretending that Common Lisp is not a defined standard,
.. John Foderaro's _professional_ conduct and
it makes him look like a crackpot unaware that he is a crackpot in his
profession, as well.
So I echo what Roger Corman said. Let's keep things friendly here
and we'll get real information across and look a lot more professional
to people just checking in to see what Lisp is all about.
Riiiight!
> So I echo what Roger Corman said.
Of course you. You are just the kind of person to _support_ that kind of
disrespectful behavior.
> Let's keep things friendly here and we'll get real information across and
> look a lot more professional to people just checking in to see what Lisp
> is all about.
Just start, John! Just start. Do not pretend that you have to wait for
anyone. Just _show_ us what it is like when you behave reasonably mature
and stick to technical issues. No more insulting, arrogant bullshit
about others, OK? Why do you keep doing it when you lambast me for doing
it? I find that part of your behavior _really_ disgusting, and yes, it
says something about your _person_ when you choose to pretend that you
above your own criticism. If you cannot start here, start by cleaning up
your insulting language in the "lisp coding standards" page. Show us
that this is not a religious nutcase at work and clean up your code, too,
to show that you have actually _listened_ to those who have expressed
similar views to mine. This all requires you to _back_down_, and I have
a hunch that your refusal to do what people tell you to do and instead
prefer to tell people what to do over just doing what you (say you) want
yourself is that you _cannot_ back down: You would not be you if you
could back down. That is why you keep telling people to be friendly when
very clearly, you are actually criticizing people and trying to leave
them defenseless. You have done that so many times that your sincerity
is in serious jeopardy because of it. So just _do_, no more _talk_, OK?
///
> I am less persuaded that removing these symbols from
> the pool of available variables is by itself
> unacceptable. All macros (and even global function
> definitions to a lesser extent) bring with them the
> price that some variables become henceforth unavailable
> for unencumbered use. The best we can hope for is that
> unintended use of these symbols as variables will make
> itself known as program error instead of creating
> mischief in a running program.
But you pitched it as a way of combining IF and IF*, which it is not.
It's just a "better" IF*. Personally, I occasionally use THEN and
ELSE as variable names, because they communicate that I'm computing
what is going to be an then or else clause. Any of my code that does
this would be a pain in the butt to port to your IF -- the advantage
of not reusing a normal name from CL is that it's obvious that there
may be problems porting code to IF* (or AIF or ...).
Anyone who indulges in a flame be banned for 5 days, 10 days for next
offense and 20 days.. and so on..
I love lisp, and am so terribly disappointed at what has become of
comp.lang.lisp, and how unfriendly it is.. and am all the more
disappointed at how many users it turns off lisp. And it is all of us
lispers who lose, because the smaller the userbase, the lesser the
development of language and friendly packages therein.
Wish we all took a clue from how good emacs and elisp is doing.
Deepak <URL:http://www.glue.umd.edu/~deego>
--
You know you've spent too much time on emacs when you spill
milk and the first thing you think is "C-_"
> so I finaly go and read the coding standard in hopes of finding a url
> or pointer to fix my problems. Mow the first sentence of the first
> rule, on a document on franz's website starts like this:
>
> Use if* instead of the bogus-three-conditionals: if, when and unless
>
> This is an odd way for franz to show that they support common lisp and
> would at the very least make me look for someone else to give my money
It is indeed sad...
> I would like to thank franz for writting smtp.cl and imap.cl I have a
> project that I would use it on after I get all the if* stuff out of
> it.
I too gladly used Franz to implement these (as we were too busy to do
them ourselves). But please note: to be fair realize that we _paid_
Franz to write these. This is also true of the original XML parser
from which they learned enough to create the much better current
version. As well as enhancements to ORBlink. Please note further
that I believe this was well spent money and have always thought that
Franz has tried to do a great job.
> And I think that everyone has the right to use whatever macros they
> want. But with that said from looking at it I think cond is much
> better to look at then your stuff. I always thought a case,
> switch. cond statement was MUCH clearer then a long series of nested
> if statements to read.
Absolutely. Frankly it's the IF* macro that is completely bogus - but
I'm not going to go apoplectic over JF's use of the damn thing to get
the job done.
/Jon
--
Jon Anthony
Synquiry Technologies, Ltd. Belmont, MA 02478, 617.484.3383
"Nightmares - Ha! The way my life's been going lately,
Who'd notice?" -- Londo Mollari
Exactly. And more: busy promoting and selling great ones that exist.
And just how do you propose to enforce this? Who will be the accusers,
the judge and the jury? People who are unconcerned about such issues,
prove that revengefulness and hatred is a poor basis for suggestions
about other people's behavior.
Just improve your own behavior. It is the only behavior you control.
Trying to control anyone else's is just plain evil.
However, it would be tremendously helpful if you could try grow a clue
_why_ these things develop. Let me give you a hint: First, people who
are unable to accept criticism and who will never back down from any of
their positions regardless of any criticism, but attack the person who
criticizes them directly if they are at least decent people, indirectly
in the sort of polite ways that you strongly favor when they are not.
Second, people who keep doing this have to defend their actions somehow,
and the more they can blame somebody else, the worse they get, because
they are freed of personal responsibility for their actions. Now, I
tolerate neither of these and want people to be responsible for their
very own actions and blaming nobody. Several people are unable to cope
with such a requirement and go ballistic when they cannot blame someone
else for their own behavior, and that someone is me, because it has
become acceptable in this forum to blame me for the behavior of nutcases.
If you help make sure people accept responsibility for their own actions
and cannot blame me or anyone else, there will be no more flaming. If
you are so interested in less flaming, you _will_ help in this regard.
Thank you for your cooperation.
///
But, this is utterly and completely wrong. First, compiling inline
should be available.
Second, worrying about the importance of presumed micro efficiency gains
is the domain
of C programming. Third, by your statement here it _appears_ that it is
precisely
_because_ of if* that you _missed_ the more readable variation
(thinking,
perhaps, it was "good enough" and afterall avoids a possible call).
I made this statement.
> You've altered the readability of the code by factoring part of
> > it out (enhancing readabilty at a cost in speed if the function isn't compiled inline)
>
you said:
> But, this is utterly and completely wrong.
which part is utterly and completely wrong:
1. You've altered the readability of the code by factoring part of it out
2. enhancing readabilty at a cost in speed if the function isn't compiled inline
is 1 or 2 or both?
Or in fact is neither statement wrong and your point in fact was
that Common Lisp compilers should inline functions and that
along with comparing what's more readable, if* or if, you
should consider looking for common subexpressions and factoring
them out to improve readabilty?
>
> Please help me understand the point you're making.
>
> I made this statement.
>
>> You've altered the readability of the code by factoring part of
>> > it out (enhancing readabilty at a cost in speed if the function isn't
>> > compiled inline)
>>
>
> you said:
>
>> But, this is utterly and completely wrong.
>
> which part is utterly and completely wrong:
>
> 1. You've altered the readability of the code by factoring part of it out
>
> 2. enhancing readabilty at a cost in speed if the function isn't compiled
> inline
>
> is 1 or 2 or both?
I would say both - but I would _not_ call it "utterly and completely wrong".
To 1:
Point one is - taken out of context true - it is _what_ I've done.
But in your original post you write "This is an apples and oranges
comparison" and this is IMHO not true. My point was that using IF* leads to
code that is not really more readable - and the example showed that IMHO
rather well. If "factoring a part out" would have been the only thing
(leaving IF* in) It still would be IMHO less readable than the other
approach (see below).
To 2:
This point _is_ wrong regardless of what is argued. By fact I did not know
that ACL does not inline user-defined functions because I mainly use LW and
CMUCL and both systems inline rather well - so this is a feature I
regularily use. So you could argue that my code would be at least on ACL
slower (which could probably be wrong too since you have 3 REQUEST-SOCKET
calls and I have only one). But this can be easily fixed without changing
the concept by using MACROLET instead of FLET
(macrolet ((accept-char (char stream)
`(let ((c (read-char-no-hang ,stream nil nil)))
(cond ((eql c ,char))
(c (unread-char c ,stream))))))
(let ((stream (request-socket req)))
(and (accept-char #\return stream)
(accept-char #\linefeed stream))))
And I see absolutely _no_ reason why
(let ((ch (read-char-no-hang (request-socket req)
nil nil)))
(if* (eq ch #\return)
then ; now look for linefeed
(setq ch (read-char-no-hang
(request-socket req) nil nil))
(if* (eq ch #\linefeed)
thenret
else (unread-char
ch (request-socket req)))
elseif ch
then (unread-char ch (request-socket req))))
could be in any way faster then...
I think you _definitely_ need more time to grasp what happens in the IF*
variant then in the alternative variant.
> Or in fact is neither statement wrong and your point in fact was
> that Common Lisp compilers should inline functions and that
> along with comparing what's more readable, if* or if, you
> should consider looking for common subexpressions and factoring
> them out to improve readabilty?
Not really - as I already said I like the diversity CL offers (IF, WHEN,
UNLESS, COND, AND, OR, EVERY, SOME...) and my example should show that it
_pays_ to think _what_ construct to choose best and that a over-general IF*
that is said as the only thing that should be used leads to less readable
code in most situations.
I think even the non factored out version using AND and COND instead of IF*
is more readable.
(let ((stream (request-socket req)))
(and (let ((c (read-char-no-hang stream nil nil)))
(cond ((eql c #\return))
(c (unread-char c stream))))
(let ((c (read-char-no-hang stream nil nil)))
(cond ((eql c #\linefeed))
(c (unread-char c stream))))))
So your restriction on C-Style control-flow IMHO _leads_ to less readable
code.
ciao,
Jochen
Btw.: I'm glad to see that you removed the inflaming parts of your
style-guide - This is a step in the right direction.
> Erann, thanks for helping to get lisp sent to Mars.
Hmmm... wasn't it asteroid Braille (1992KD) rather than Mars?
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://web.mclink.it/amoroso/ency/README
[http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/]
I think things are not that bad.... much improved over the 2+ years I've
subscribed, and the unfriendliness, though extreme at times, is isolated and
directed. I think random newbies get friendly advice and tolerance and
spirited technical disscussions happen all the time with out degenerating.
We all control the tone here, so just be an example of what you would like
to see, that's all.
So if you're worried, just post friendly messages! : )
Coby
--
(remove #\space "coby . beck @ opentechgroup . com")
> Anyone who indulges in a flame be banned for 5 days, 10 days for next
> offense and 20 days.. and so on..
Please ban me from your newsgroup.
Thanks.
-dan
--
http://ww.telent.net/cliki/ - Link farm for free CL-on-Unix resources
> Deepak Goel <de...@glue.umd.edu> writes:
>
> > Anyone who indulges in a flame be banned for 5 days, 10 days for next
> > offense and 20 days.. and so on..
>
> Please ban me from your newsgroup.
You have it backwards. If you flame any other usenet group, you will
automatically be subscribed to comp.lang.lisp for 20 days. In
addition, a post that appears to originate from you will be issued.
This post will contain questions taken almost verbatim from the FAQ.
It will select a comp.lang newsgroup at random and rant about how much
better that language is than lisp. The post will conclude with
personal attacks against the more vociferous members as well as
insults against the lisp community in general.
The only way to get off the newsgroup is to send 20 messages with any
but the correct spelling of the word `unsubscribe'.
> I have no other gripes about Erann Gat,
Ah, maybe there is hope.
> His behavior is not at all my fault.
No, you're wrong about that. The reason I attacked you (and I freely
admit that's exactly what I did) is because you advocate it. You
wrote:
> Shock therapy it is. But also an attempt to show those who denounce the
> language and the great stuff that I love and want to use what it feels
> like to be denounced. Believe you me, they recognize this and they do
> feel it.
and you have repeatedly advocated applying pain to people whose
behavior you find unacceptable. I found your attack on John Foderaro
unacceptable so I dealt with it in the manner you prescribe, by
denouncing you.
Now you might say that it is not my business to defend John, and
perhaps you are right. But I'm not defending John, I'm defending
John's right to free speech, and again here I am simply following your
example. Your initial attacks on John were motivated not by attacks
on you, but by (perceived) attacks on "the language and the great
stuff that [you] love". Well, I love the principle of free speech.
By attacking John and accusing him of hating Common Lisp (when it is
quite clear that he does not), by applying "shock therapy" in the name
of suppressing dissent, you attacked a principle that I dearly love.
So I followed your example and dealt with it by attacking you.
Look where it's gotten us.
E.
> (macrolet ((accept-char (char stream)
> `(let ((c (read-char-no-hang ,stream nil nil)))
> (cond ((eql c ,char))
> (c (unread-char c ,stream))))))
> (let ((stream (request-socket req)))
> (and (accept-char #\return stream)
> (accept-char #\linefeed stream))))
A style question: I would have written this
(macrolet ((accept-char (char stream)
(let ((gstream (gensym))
(c (gensym)))
`(let* ((,gstream ,stream)
(,c (read-char-no-hang ,gstream nil nil)))
(cond ((eql ,c ,char))
(,c (unread-char ,c ,gstream)))))))
(let ((stream (request-socket req)))
(and (accept-char #\return stream)
(accept-char #\linefeed stream))))
While I don't see anything wrong with the original code, isn't it
generally considered dangerous not to write macros safe in the first
place even when they don't have to the way they are called in the
first version of the code? (Just asking; no offense; not another
flame war, please :-) I would possibly even shadow the `char'
argument, just to make changes to `accept-char' less dangerous.
The original version is easier to read, though; opinions, anyone?
Regards,
--
Nils Goesche
"Don't ask for whom the <CTRL-G> tolls."
PGP key ID 0x42B32FC9
I actually liked the really original version with the inlined function.
I dislike the use of macros in cases like this for efficiency -- it seems
that the flet was a perfectly lucid way of expressing what we were after.
If a macro will be used to get efficiency out of non-inlining
implementations maybe that macro should be something called
inline-flet that hides the macro-let and lets you write the code
like you would with flet -- only inlined. (No I don't have the code, but
might give it a shot later.)
cheers,
BM
That's right. The way I like to put it is that Lisp beat both Java
and C++ out of Earth's gravity well. Lisp hasn't been to Mars -- yet
:-)
By the way, as long as we're on the subject, credit for sending Lisp
into space also goes to the developers of CLisp, which was the first
Lisp we ported to run on the flight computer to prove that it could be
done (and which we might have actually flown but for the fact that we
needed multithreading), and the people at Harlequin, who ported
Lispworks to run on the flight computer, and Franz and Digitool, whose
Lisps we used to actually develop most of our code. It's a credit to
the vendors that we were able to port code almost seamlessly between
*four* different Lisp implementations running on three different
operating systems, with a total of seven different Lisp/OS
combinations. Lisp is the real write-once-run-anywhere language. And
while we're at it, credit also goes to everyone who *used* those
systems so that they could be there and available when we needed them.
E.
Now let us see what happens if I advocate that you go shoot yourself.
Will you do that, too?
> I found your attack on John Foderaro unacceptable so I dealt with it in
> the manner you prescribe, by denouncing you.
No, you did not. You simply do _not_ copy me. You may copy my words and
actually _believe_ that you mean what I would mean, but you do not. Your
evil deeds are not mine, they your very own responsibility. Accept it.
> But I'm not defending John, I'm defending John's right to free speech,
> and again here I am simply following your example.
Free speech is not under attack, you imbecile. And you are not following
any examples. You originate your own behavior. There is nobody you can
blame for what you do. There is nobody else who can get tainted by your
behavior, however much you want to make somebody else look bad because
_you_ are an evil piece of shit our solely to destroy other people. We
have seen you in action on this newsgroup before. It is evident that you
have no constructive objectives in mind at all in these exchanges. That
is the part you cannot copy, because of our personality differences.
> So I followed your example and dealt with it by attacking you.
No, you fail to follow any example at all. You are originating your own
behavior and copy nobody. Take responsibility for what you do yourself,
and just quit the moronic games you play. People take notice not of what
examples you think you copy, but what _you_ actually do. Trying to shift
the blame like that is what the criminally insane do.
> Look where it's gotten us.
Look where it has gotten _you_. If you want to be remembered as a
psychopath, keep going the way you do. Your first step to change this
impression is that you take responsibility for your own actions always,
blame nobody and attempt to smear nobody because you are piece of shit.
I actually think you _are_ evil and insane, Erann Gat. Insane people
have very slim chances of affecting other people. Destructive people
like yourself have very little chance of doing anything constructive.
And, _please_ get over the fact that you lose the games you play when you
want to make anybody else look bad. You succeed _only_ with yourself.
///
When you have complete control over all symbols used, I think doing the
full gensym thing is a distractor. However, inline declarations of local
function should at least have worked. There is no danger of redefinition
outside of the function that would affect the compiler's ability to know
exactly what it is doing.
///
Now if we could only somehow get everybody to actually practice what
they all preach...
Larry
You're right that the macro-version was not perfect in this regard.
There was two reasons I've chosen to do it like it was done.
1) Make it as similar to the FLET version as it is possible.
2) Makt it as simple as possible to express the idea
Your suggestions do not change the generated codes functionality, but would
lead to a more robust behaviour in regard to changes. It is definitely a
good idea to put the stream and char argument of the macro in a LET binding,
so that probably given forms do not get evaluated multiple times.
You would not necessarily need GENSYMs if you have no &body forms or
macros that use the used symbols as free variables (though the last problem
is more a problem with _that_ macros and not the one here).
It is definitely a good idea if you think more carefully on macros that get
reused - for a local macro like the above it is probably not per se
necessary.
As others said I only used MACROLET to circumvent possible inabilities of
inlining local function-calls - so I do not use it in my own code that way.
_If_ you really have to use a Lisp that does not inline local functions I
would define a INLINE-FLET macro like Bulent suggested.
ciao,
Jochen
Does that mean that ACL would be able to inline local function-calls like
used in my first example?
The ability to inline at least local function-calls is rather important for
me, since I often use FLET or LABELS to abstract complicated control-flow
situations.
ciao,
Jochen Schmidt
No. "Should have worked" is different from "should work". The former
means it does not.
> The ability to inline at least local function-calls is rather important
> for me, since I often use FLET or LABELS to abstract complicated
> control-flow situations.
How Scheme. :)
///
> Nils Goesche wrote:
>
> > A style question: I would have written this
[snip]
> There was two reasons I've chosen to do it like it was done.
>
> 1) Make it as similar to the FLET version as it is possible.
> 2) Makt it as simple as possible to express the idea
I assumed that. I just wanted to know whether people had clear
opinions on that.
> It is definitely a good idea if you think more carefully on macros that get
> reused - for a local macro like the above it is probably not per se
> necessary.
Probably not. The gensym stuff makes it look weird, but in fact I
already got bitten for not using them (bottom-up programming, I guess
:-).
> As others said I only used MACROLET to circumvent possible inabilities of
> inlining local function-calls - so I do not use it in my own code that way.
> _If_ you really have to use a Lisp that does not inline local functions I
> would define a INLINE-FLET macro like Bulent suggested.
Definitely.
You're right there along-side him, Erik, open your eyes.
These exchanges between you two lost their charm a long time ago...
Wrong. I am not one who makes a game out of trying to taint other
people's image by doing something I think is wrong. Also, I am not one
who claims to follow somebody else's example when that would have meant
contradicting myself so badly I would look like a moron. Open your eyes
to the crucial differences despite any similarities you see.
///
> Let me as you this: are when and unless good or bad?
> I'll be you say "good" since they are part of the ANSI spec.
>
> Now what if they weren't part of the ANSI spec. What if now I introduced them to
> you. Would they be good or bad? Now you would say "bad" since they don't give you
> anything that if, not and progn can't give you.
Forms such as WHEN and UNLESS may not be technically perfect. But the
"goodness" of their being part of a standard is the result of a technical
and political tradeoff accepted by all parties who took part to the
standardization effort, both implementors and users. If you are not willing
to accept such a tradeoff, just don't bother with standardization.
[...]
> He is an active member of the Lisp community. There is *no*
> active Lisp standardisation committee at the moment.
>
OT, but what about the ISO-standardized Lisp? Did the ISLISP project
fail or something?
[...]
--
BPT <b...@tunes.org> /"\ ASCII Ribbon Campaign
backronym for Linux: \ / No HTML or RTF in mail
Linux Is Not Unix X No MS-Word in mail
Meme plague ;) ---------> / \ Respect Open Standards
[...]
> Here is my 5000 word essay on why I love Common Lisp. But of course I
> don't want to actually write those 5000 words myself, if I can get
> Common Lisp to write them for me. And of course I don't want to write
> them in English, partly because English is not really the language of
> love, and partly because I have not yet learned Common Lisp well
> enough to make it write a good essay in English.
Bug report: it doesn't write an essay at *all*. For me, it printed out
the script for Hamlet, which is a *play*. Still, I have never seen
such a useful AI program that is so concise. BTW: after this occured a
couple of times, I noticed that `ps' reported a huge number of
`monkey' and `typewriter' processes. Another CMUCL-specific problem???
[...]
Oh, my vote: Lisp is the best programming language I have ever used,
and I will learn to write good programs in it if it takes me years
(now I'm reading _CLtL_ and _LISPcraft_น, not extrapolating from the
Elisp manual and _Simply Scheme_, so it should be easier). I used to
think that CL was a crufty, klugy hack, probably from the
aforementioned CL-haters (and Scheme zealots), but I have happily been
proven wrong.
I think Emacs is extremely helpful, also, for getting people
interested in Lisp. Emacs has lots of tutorials, great manuals (like
*some* CL manuals), and the people on comp.emacs actually have a sense
of humor (gasp!). You also have an incentive to learn Lisp because
then you can do amazing things with your editor, like editing
expression-based Lisp code without being stuck in an editor that is
completely line-based, and reading Usenet news and mail with it (as I
am doing now, with Gnus). I wrote my first Lisp code in Emacs (first,
setqueueing things in my ~/.emacs, then writing a major mode for Lout
files). After I had become comfortable with Lisp, I took a close look
at CL, ignoring the criticisms from the CL-haters and the
Scheme-zealots. I suppose there is no reason that people could not
start out in the CL community, it is just that the Emacs community is
more newbie-friendly (as opposed to user-friendly, which with today's
crufty ``desktop-OSes'' like MS-Windows often implies inferiority). I
think this could change if there were more enthusiasm about CL, like
Eric said.
Lisp just has a profound sense of Right Thinginess, like something
which flows seamlessly into the realm of _GEB_, Zen, and recursion...
an indescribable series of enlightnments (although I like Sawfish and
GWM better :)), ... OK, I'll shut up before I try to find funding for
the Holy Coalition of Lispers <grin>.
Footnotes:
น I also found a copy of the _LISP 1.5 Primer_ at the North Carolina
State University Library. I found it very interesting that the
language has managed to retain the core concepts which make it so
flexible despite having been invented way back in 1956. But then,
other great works such at Homer's _The Odyssey_ and Plato's _The
Republic_, plus Gilgamesh and assorted other epics, have also
survived over the centuries...
> Raymond Wiker <Raymon...@fast.no> writes:
>
> [...]
> > He is an active member of the Lisp community. There is *no*
> > active Lisp standardisation committee at the moment.
> >
> OT, but what about the ISO-standardized Lisp? Did the ISLISP project
> fail or something?
No, it succeeded. :-)
It's just a different dialect. And far less used. If you read the spec,
you'd quickly understand. Nothing wrong with the language really, but
it's pretty tiny and almost no one implements it.
`What commentary credits do you have? None, I think.'
the best coin is offered most discreetly.
thi