If Lisp is so powerful as believed by many lisp lovers and advocates,
why there are not enough lisp libraires around to compete with Java? If
Lisp is effieient to develop solid programs, it should take less time
and effort to do so. Perhaps Lisp is good at writing some kind of
programs while lacking sgnificant features to support developing styles
such as that of Java? Simply it can't be explained just using "worse is
better". if it is truly better, it should be easier to come up with
reliable libraries with less time. If it is easier to maintain and
extend, it should be easy to accommodate to new software development
styles. Obviously Lisp didn't stand up to the challenge. What is wrong?
A simple example, current Lisp IDE is not as satisfactory as other
powerful IDEs, and I doubt that these Lisp editors are developed by
Lisp. SourceInsight is a powerful code reading tool. And why we can't
come up with such a powerful tool developed in Lisp.
lisplover wrote:
> If Lisp is so powerful as believed by many lisp lovers and advocates,
> why there are not enough lisp libraires around to compete with Java?
A great majority of existing Java libraries functionality are obsolete
for Lisp case. Most of the Java libraries have the only one purpose -
to
cover the flaws of the Java language: container libraries is a good
example.
> If Lisp is effieient to develop solid programs, it should take less
time
> and effort to do so. Perhaps Lisp is good at writing some kind of
> programs while lacking sgnificant features to support developing
styles
> such as that of Java? Simply it can't be explained just using "worse
is
> better". if it is truly better, it should be easier to come up with
> reliable libraries with less time.
Code reuse is a way too better in Lisp then in Java, so, Lisp don't
need
so much of the libraries very same in functionality.
If you'll show a list of Java libraries that you'd like to see in
Lisp, we
will have a lot of fun here.
> A simple example, current Lisp IDE is not as satisfactory as other
> powerful IDEs,
Mua-ha-ha. Java is good for only one thing - writing Java IDEs. And
Java IDEs
have no reasonable use at all.
For Lisp we have something much more powerfull and flexible then any
other
"IDE" - Emacs + Unix toolchain.
> and I doubt that these Lisp editors are developed by
> Lisp. SourceInsight is a powerful code reading tool. And why we can't
> come up with such a powerful tool developed in Lisp.
You know nothing. It's a shame - to know nothing and speak loud. :(
Up spake ·······@gmail.com:
> You know nothing. It's a shame - to know nothing and speak loud. :(
A greater shame than one who knows and is silent?
--
-trent
Real Programmers don't use Python. -- Skud
Real Programmers don't use *whitespace*. -- Thorfinn
Trent Buck <·········@tznvy.pbz> writes:
> Up spake ·······@gmail.com:
> > You know nothing. It's a shame - to know nothing and speak loud. :(
>
> A greater shame than one who knows and is silent?
It is better to keep your mouth closed and be thought a fool,
than to open it and remove all doubt.
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
Duane Rettig Feb 22, 9:06 am wrote:
==
It is better to keep your mouth closed and be thought a fool,
than to open it and remove all doubt.
==
I mean oh yes, there is one obvious fact: comp.lang.python and
comp.lang.lisp could become somehow intermangled kinda like:
comp.lang.lisp.python.
Why are the fellows that quick in calling someone a troll?
He asked questions - right? So lets nail it down: why there are not
more of that kind of libraries for Lisp if Lisp - allegedly -- is that
cool?
The same could be asked for Scheme. However, if one is going to ask me
as a Scheme user by heart I wouldn't have had a good answer why there
are no more libraries for Scheme.
comp.lang.lisp would be better off answering questions in a human
manner instead of fooling itself.
What is wrong with Lisp users?
Förster vom Silberwald
F�rster vom Silberwald wrote:
>
> Why are the fellows that quick in calling someone a troll?
Agreed, it would be easier to answer it in an FAQ, and point people to it,
rather than accuse those asking the question of trolling.
> He asked questions - right? So lets nail it down: why there are not
> more of that kind of libraries for Lisp if Lisp - allegedly -- is that
> cool?
This has been answered in this thread already:
10 times more efficient language / 1000 times fewer users =
1/100 of libraries
That said, you can often use C libraries from Lisp.
Förster vom Silberwald wrote:
> Why are the fellows that quick in calling someone a troll?
What's wrong with being a troll? People are very immature in fearing
them. And when you actually look at the details, it turns out the
problems "trolls cause" are actually caused by the vocal audience. Not
the troll.
Like, is the original poster is a liar, who intentionally stirs
trouble? Almost certainly not. To some extent, trolls are defined
relative to its audience. At least, I think it's useful to do so.
Are people like me condescending and arrogant in calling him/her a
troll? Quite possibly. So in that case, the troll may be better than
the 'detractors.'
Tayssir John Gabbour Feb 24, 4:17 am wrote:
==
What's wrong with being a troll? People are very immature in fearing
them. And when you actually look at the details, it turns out the
problems "trolls cause" are actually caused by the vocal audience. Not
the troll.
Like, is the original poster is a liar, who intentionally stirs
trouble? Almost certainly not. To some extent, trolls are defined
relative to its audience. At least, I think it's useful to do so.
Are people like me condescending and arrogant in calling him/her a
troll? Quite possibly. So in that case, the troll may be better than
the 'detractors.
==
You must the take following into account: someone browsing groups for
answers and dicussions.
What will you think if you - as an outsider - are searching
com.lang.lisp for discussions about libraries. What will be your
impressions when you see that questions become answered by the
troll-tag? Does that mean then that there already exist enough
libraries?
Or wouldn't it be better to answer in a clever way so as such that an
outsider gets the impression that the original poster is in error.
However, nobody can expect from me as an outsider that calling one a
troll means that I have to infer that there are enough libraries.
Why not educating the original poster by means of examples where Common
Lisp is successfully utilizied in industrial projects?
Förster vom Silberwald
Förster vom Silberwald wrote:
> You must the take following into account: someone browsing groups for
> answers and dicussions.
>
> What will you think if you - as an outsider - are searching
> com.lang.lisp for discussions about libraries. What will be your
> impressions when you see that questions become answered by the
> troll-tag?
I'd observe the responses to the backlash of thoughtful critics. ;)
Seriously, I don't care about that point. The only issue of any vague
interest is, "Did I post that in a weird mood, and act like a jerk to
someone who didn't deserve that treatment?"
But this point you mentioned is one of pragmatism, that I might be a
bad salesman and scare someone away. Well, I can do that quite simply
by telling the hypothetical reader to run to their
McBritney-Cobol-of-the-Day and suck it down, that overfed consumer. ;)
To answer lisplover's point, of course you're right -- Lisp is horribly
flawed for the programming mainstream. For purposes people have a
demand for. In the tech world, we see a demand for commodity coders who
can be outsourced and replaced. Rent a coder by the bushel. The
analogue of this is the business model of a McDonald's -- an
environment where people use tools with which users can't cut
themselves (or food). Those businesses scale by having replaceable
workers.
And if you tried introducing knives into that environment, you'd have a
lot of maimed people.
Adam Smith warned about deskilling, in his oft-misquoted tome:
"The man whose whole life is spent in performing a few simple
operations, of which the effects are perhaps always the same, or very
nearly the same, has no occasion to exert his understanding or to
exercise his invention in finding out expedients for removing
difficulties which never occur. He naturally loses, therefore, the
habit of such exertion, and generally becomes as stupid and ignorant as
it is possible to become for a human creature to become. The torpor of
his mind renders him not only incapable of relishing or bearing a part
in any rational conversation, but of conceiving any generous, noble, or
tender sentiment, and consequently of forming any just judgment
concerning many even of the ordinary duties of private life."
And the important thing is, it's disgusting and ridiculous to think
that people are subordinated to their tools. Why do people call
themselves "Java programmers" as if to fully describe themselves? We
have an insane overemphasis on tools. If Lisp doesn't have the
libraries you want, in order to make some product the short term, do
the obvious -- use something else. And remember in mind that things
evolve, so x at time-2 may be nothing like at time-1.
For those who have a deep need to cure themselves of technological
darwinism, here's an antidote:
http://www.nooranch.com/synaesmedia/wiki/wiki.cgi?DavidNoble/ForcesOfProduction
And more verbiage:
http://groups-beta.google.com/group/comp.lang.lisp/msg/b6b357d8dc3a9534
http://groups-beta.google.com/group/comp.lang.lisp/msg/bc240b571684f1c1
> He asked questions - right? So lets nail it down: why there are not
> more of that kind of libraries for Lisp if Lisp - allegedly -- is
that
> cool?
There was a responce:
1) There are lot of libraries. You don't have to reinvent the wheel.
2) There is no need in such a huge amount of libraries. Most of the
Java
libraries exists only due to the Java inflexibility.
> The same could be asked for Scheme. However, if one is going to ask
me
> as a Scheme user by heart I wouldn't have had a good answer why there
> are no more libraries for Scheme.
There are lot of them. Including ALL the existing Java libraries. ;)
> What is wrong with Lisp users?
Too many trolls around here. All are a bit paranoid now.
"F�rster vom Silberwald" <··········@hotmail.com> writes:
> Duane Rettig Feb 22, 9:06 am wrote:
>
> ==
> It is better to keep your mouth closed and be thought a fool,
> than to open it and remove all doubt.
> ==
>
> I mean oh yes, there is one obvious fact: comp.lang.python and
> comp.lang.lisp could become somehow intermangled kinda like:
> comp.lang.lisp.python.
>
> Why are the fellows that quick in calling someone a troll?
Actually, I didn't call anyone a troll. In fact, with regard to
this thread, I would consider myself a troll, except for the fact
that I have come back to the scene to answer you. But in general,
you are correct; people are quick to call others trolls, and they
shouldn't do so; if you go back in the etymology of trolling, as
it relates to fishing - trolling is dropping a line with some bait
and dragging it, usually from the back of a boat, to see what bites.
A few characteristics of a troller (in the fishing sense) are that
1. They don't expect to catch anything in any particular place,
2. they will not likely come to the same spot again, unless they
go around in circles,
3. For most fishermen (let alone trollers) the point is not to
catch any fish, but to drop the line and spend time in the boat
away from things.
Thus, it is impossible to tell a troll from someone who is just
fishing, or from some one who is actually wanting to catch fish
in order to eat...
> He asked questions - right? So lets nail it down: why there are not
> more of that kind of libraries for Lisp if Lisp - allegedly -- is that
> cool?
No. His first sentence was: "If Lisp is so powerful as believed by
many lisp lovers and advocates, why there are not enough lisp
libraires around to compete with Java?". The question comes with
the presumption that there are not enough Lisp libraries around.
It doesn't come with background for the question, as to what
attempts were made to find out or what resources were searched
which gave him that presumption.
I think that a more honest form of this question goes something like
this:
"I have been programming for many years, now, and had never
heard of lisp (except, perhaps, only in passing). Now, when I
actually try Lisp out, it is an amazing language, but that
doesn't jibe with my own view that as an experienced <x-language>
programmer, I would have heard of Lisp more. Since there is
nothing wrong with me, there must be something wrong with the
Lisp community; what is that?"
The answer, of course, is that there is nothing wrong with "you" (the
asker of that generic question) but you are wrong in your assumption
that it must also mean that there is something wrong with the Lisp
community.
Now, I seldom actually say this; it could easily be taken as a statement
that I believe that there is nothing that can be done to improve the
lot of the Lisp Community. It would be a false perception; anyone who
knows what I do for the Lisp community will know that that is not true;
I am constantly advocating for Lisp, and for CL in particular. And
due to the advocacy of some in this community, I have seen a turnaround
from the sad days in the mid-90s when Lisp was thought to be dead, to
the present day, when we seem to be seeing a revival of interest in
lisp; take a look at all of the quality Lisp implementations, both
CL and Scheme, and ask yourself how they continue to be maintained.
> The same could be asked for Scheme. However, if one is going to ask me
> as a Scheme user by heart I wouldn't have had a good answer why there
> are no more libraries for Scheme.
You should start at http://www.lisp.org and go from there (this is probably
the more helpful "pat-answer" to give to the OP than to make jokes). The
resources on Scheme are probably not as complete as for Common Lisp, since
the ALU is more oriented toward CL than Scheme (though we do try to reach
out to the Scheme community, and to accept suggestions for additional
information on Scheme).
> comp.lang.lisp would be better off answering questions in a human
> manner instead of fooling itself.
Like most Usenet groups, there tends to be a set of questions that
never go answered directly. Some of them are:
- Please answer my xyz (homework problem) for me. [We're not
as good on this one as are the people in comp.arch - they have
homework-answering down to an art, and can, with complete aplomb,
give a completely false answer that _sounds_ good, even to the point
of fooling other technical people]
- I love Lisp, but ...
- why is Lisp {dead,languishing,not popular,...}
- When did you stop beating your wife?
> What is wrong with Lisp users?
We're a little jaded by the same tired old questions about why Lisp
is <your favorite slur here>. We're a little more jaded than most,
because the questions have been coming for most of its 47 years.
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
F�rster vom Silberwald wrote:
> He asked questions - right? So lets nail it down: why there are not
> more of that kind of libraries for Lisp if Lisp - allegedly -- is that
> cool?
Because Lisp's coolness - a qualitative measure - and the number of
available libraries - a quantitative measure - are not related. They are
only related in the sense that to a certain degree, a high quality can
compensate for a lack of quantity and vice versa.
Note that this is just a nice way of saying that the question is stupid.
Libraries don't write themselves. A critical mass of people is needed to
develop a high number of libraries.
Pascal
If Lisp is so cool -- a qualitative measure -- why can't it attract a
critical mass of people? Do you think that if there really exists a
language 10 times more efficient, The majority programmers would just
sit there, content with some stupid 10 times less efficient language
whill totally ignoring that much powerful language? Or are you
expecting that the majority are so stupid that they can't master this
powerful language to make any use? Obviously not. There must be some
flaws there. I am totally not trolling. I just think there must exist
some defects and try to find it out. After all, it is such an elegant
idea from original Lisp to be described as "Maxwell's Equations of
Software!". And what a pity it is that this language is just for some
advocates' toys.
lisplover Feb 24, 4:35 am wrote:
==
If Lisp is so cool -- a qualitative measure -- why can't it attract a
critical mass of people? Do you think that if there really exists a
language 10 times more efficient, The majority programmers would just
sit there, content with some stupid 10 times less efficient language
whill totally ignoring that much powerful language? Or are you
expecting that the majority are so stupid that they can't master this
powerful language to make any use? Obviously not. There must be some
flaws there. I am totally not trolling. I just think there must exist
some defects and try to find it out. After all, it is such an elegant
idea from original Lisp to be described as "Maxwell's Equations of
Software!". And what a pity it is that this language is just for some
advocates' toys.
==
The problem what lures behind the wall: your approach isn't fruitful.
Wouldn't it be better if you state what libraries come to your mind?
Name some of the libraries you are in dire need for your projects. It
will then be easier for people to point you to some such libraries or
give you some advices on how to search for alternatives.
I think your postings are not well focused. So lets calm down and start
reformulating your questions.
By the way: yes mass is stupid. I know a lot of idiots who are using
Windows. I know a lot of idiots who think that becoming a
Hollywood-star will contribute to mankind. I know a lot of idiots who
think that beeing in a clique is some kind of prestige. I know a lot of
idots who think that owning a Bachelor in computer -science entitles
them to call themself "computer-scientists".
I know a lot of idiots who raise money for a 50 000$ car but will
commit to suicide if they had to pay 200$ more in average for a Mac.
Indeed there are a lot of idiots. The mass and trash is not really a
useful measure for gauging things.
Förster vom Silberwald
Let us put it this way, what do you think that all the software that
support your posting and browsering in this website, from your OS, your
browser, your networks, to the routers, the web servers, all the
software involved. what percentage are written in Lisp? If Lisp is
really equipped with such an extraordinary power, why can't it come up
with something similar?
lisplover Feb 24, 4:58 am wrote:
==
Let us put it this way, what do you think that all the software that
support your posting and browsering in this website, from your OS, your
browser, your networks, to the routers, the web servers, all the
software involved. what percentage are written in Lisp? If Lisp is
really equipped with such an extraordinary power, why can't it come up
with something similar?
==
I am a scientist and not a programmer. I can't even go to answer Lisp
related questions.
However, have you ever taken into account that a lot of allgedly more
successful projects, e.g. Python, rely on some heavier prior developed
C libraries?
As a lisplover as your name suggest: please can you elaborate and
disclosure some prior projects where you tried to use Common Lisp.
Which obstacles hampered your road?
Or do you need a critical mass first where you get the feeling you are
not alone? You mentioned the Maxwell equations - right? You know that
not many have ever heared of Maxwell equations either did they see such
equations. The trash and critical mass at the universities is studying
business.
So, wouldn't it be a good idea to go to the next physics departement
and asking them why the hell didn't they already abolish the Maxwell
equations.
Förster vom Silberwald
lisplover wrote:
> Let us put it this way, what do you think that all the software that
> support your posting and browsering in this website, from your OS,
your
> browser, your networks, to the routers, the web servers, all the
> software involved. what percentage are written in Lisp? If Lisp is
> really equipped with such an extraordinary power, why can't it come
up
> with something similar?
Your "arguments" are stupid, troll. Try to eat shit - so many flies
loves it!
On 24 Feb 2005 06:31:40 -0800, ········@gmail.com" <·······@gmail.com>
wrote:
>
>lisplover wrote:
>> Let us put it this way, what do you think that all the software that
>> support your posting and browsering in this website, from your OS,
>your
>> browser, your networks, to the routers, the web servers, all the
>> software involved. what percentage are written in Lisp? If Lisp is
>> really equipped with such an extraordinary power, why can't it come
>up
>> with something similar?
>
> Your "arguments" are stupid, troll. Try to eat shit - so many flies
>loves it!
Well... Typical, "professional", "deep" style of discussion most
popular on comp.lang.lisp.... If someone does not have arguments, uses
profanities....
A.L.
A.L. wrote:
> On 24 Feb 2005 06:31:40 -0800, ········@gmail.com" <·······@gmail.com>
> wrote:
>>Your "arguments" are stupid, troll. Try to eat shit - so many flies
>>loves it!
>
>
> Well... Typical, "professional", "deep" style of discussion most
> popular on comp.lang.lisp.... If someone does not have arguments, uses
> profanities....
>
> A.L.
Dzien Dobry,
Ok, first off the poster is pointing out that "appeal to the masses"
(argumentum ad populum) is a logical fallacy. We use that particular
expression here all the time.. in c.l.l it's not profane, it's
vernacular. If you came in to a jazz newsgroup and told everybody that
brittney spears was better music because it's more popular, you'd
probably get the same response.
Second, who are you to come into c.l.l and insult/troll us? this is our
home, c.l.l, and you are some interloper asshole who makes the same
arguments lisp users have been hearing for 50 years. Do you expect us to
be civil to every troll around? The fact that you have to take this to a
personal level indicates you have no real arguments.
It is not our purpose here to convert you to Lisp.. we discuss lisp
here... most of us are already lisp users. If you search google, you
will find that the exact argument you are trying to make has been played
out many times. So yeah, we'd rather tell you to eat shit then listen to
your ignorant statements and faulty logic.
I took the liberty of looking through google groups for other posts of
yours, and you don't usually come off as a troll, until lisp is
involved. I suggest you forget about lisp users, we don't care. I for
one am quite happy making my living programming in a "niche language",
and i couldn't care less what language you and your team (or millions of
code monkeys across the world) use.
You sir, are a bore!
--
Drew Crampsie
drewc at tech dot coop
"Never mind the bollocks -- here's the sexp's tools."
-- Karl A. Krueger on comp.lang.lisp
drewc wrote:
> So yeah, we'd rather tell you to eat shit then listen to
> your ignorant statements and faulty logic.
Just wanted to note that i was using a royal 'we' in that post, i do not
presume to speak for all c.l.l readers.
--
Drew Crampsie
drewc at tech dot coop
"Never mind the bollocks -- here's the sexp's tools."
-- Karl A. Krueger on comp.lang.lisp
"drewc" <·····@rift.com> wrote in message
···························@pd7tw1no...
> drewc wrote:
>
> > So yeah, we'd rather tell you to eat shit then listen to
> > your ignorant statements and faulty logic.
>
> Just wanted to note that i was using a royal 'we' in that post, i do not
> presume to speak for all c.l.l readers.
Now that's confusing. The King uses the royal "we" precisely because he DOES
speak for all of his citizens.
Gorbag wrote:
> "drewc" <·····@rift.com> wrote in message
> ···························@pd7tw1no...
>
>>drewc wrote:
>>
>>
>>>So yeah, we'd rather tell you to eat shit then listen to
>>>your ignorant statements and faulty logic.
>>
>>Just wanted to note that i was using a royal 'we' in that post, i do not
>>presume to speak for all c.l.l readers.
>
>
> Now that's confusing. The King uses the royal "we" precisely because he DOES
> speak for all of his citizens.
>
>
I speak for all _my_ citizens, why may or may not be readers of c.l.l :)
. In this case, my citizens are those who agree we with me. Not a very
strong monarchy perhaps....
--
Drew Crampsie
drewc at tech dot coop
"Never mind the bollocks -- here's the sexp's tools."
-- Karl A. Krueger on comp.lang.lisp
>>>>> "Gorbag" == Gorbag <······@invalid.acct> writes:
Gorbag> "drewc" <·····@rift.com> wrote in message
>> drewc wrote:
>>
>> > So yeah, we'd rather tell you to eat shit then listen to
>> > your ignorant statements and faulty logic.
>>
>> Just wanted to note that i was using a royal 'we' in that post,
>> i do not presume to speak for all c.l.l readers.
Gorbag> Now that's confusing. The King uses the royal "we"
Gorbag> precisely because he DOES speak for all of his citizens.
But he doesn't necessarily have to be a royal to use that form. In my
understanding the 'royal we' is reserved for either actual
royals/aristocracy or for people with tapeworms...
Holger
+ Holger Duerer <········@gmx.net>:
| In my understanding the 'royal we' is reserved for either actual
| royals/aristocracy or for people with tapeworms...
Heh. It is commonly used by journalists. Not to mention by
mathematicians: "Hence, by Zorn's lemma, we conclude that..."
--
* Harald Hanche-Olsen <URL:http://www.math.ntnu.no/~hanche/>
- Debating gives most of us much more psychological satisfaction
than thinking does: but it deprives us of whatever chance there is
of getting closer to the truth. -- C.P. Snow
From: Peter Seibel
Subject: Re: OT: Royal we [was Re: why not enough lisp libraries?]
Date:
Message-ID: <m3fyzj6t6a.fsf@gigamonkeys.com>
Harald Hanche-Olsen <······@math.ntnu.no> writes:
> + Holger Duerer <········@gmx.net>:
>
> | In my understanding the 'royal we' is reserved for either actual
> | royals/aristocracy or for people with tapeworms...
>
> Heh. It is commonly used by journalists.
Yes. But then we call it the "editorial we".
-Peter
--
Peter Seibel ·····@gigamonkeys.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
+ Peter Seibel <·····@gigamonkeys.com>:
| > Heh. It is commonly used by journalists.
|
| Yes. But then we call it the "editorial we".
Hmm. Maybe I should introduce the term "academic we".
--
* Harald Hanche-Olsen <URL:http://www.math.ntnu.no/~hanche/>
- Debating gives most of us much more psychological satisfaction
than thinking does: but it deprives us of whatever chance there is
of getting closer to the truth. -- C.P. Snow
Harald Hanche-Olsen wrote:
> + Peter Seibel <·····@gigamonkeys.com>:
>
> | > Heh. It is commonly used by journalists.
> |
> | Yes. But then we call it the "editorial we".
>
> Hmm. Maybe I should introduce the term "academic we".
>
Well, i'm a Leo, we consider ourselves royalty. Perhaps a "Narcissisitic
We" is more accurate in this case. :)
--
Drew Crampsie
drewc at tech dot coop
"Never mind the bollocks -- here's the sexp's tools."
-- Karl A. Krueger on comp.lang.lisp
From: Marco Baringer
Subject: Re: why not enough lisp libraries?
Date:
Message-ID: <m2y8det82h.fsf@soma.local>
"lisplover" <·········@hotmail.com> writes:
> Let us put it this way, what do you think that all the software that
> support your posting and browsering in this website, from your OS, your
> browser, your networks, to the routers, the web servers, all the
> software involved. what percentage are written in Lisp? If Lisp is
> really equipped with such an extraordinary power, why can't it come up
> with something similar?
why should it? what would be the point? the code already exists, why
does it need to be rewritten?
--
-Marco
Ring the bells that still can ring.
Forget the perfect offering.
There is a crack in everything.
That's how the light gets in.
-Leonard Cohen
"lisplover" <·········@hotmail.com> writes:
> Let us put it this way, what do you think that all the software that
> support your posting and browsering in this website, from your OS, your
> browser, your networks, to the routers, the web servers, all the
> software involved. what percentage are written in Lisp?
According to a study of some version of Red Hat, Lisp came in at
fourth place in number of source code lines. 86% were C or C++, shell
scripts were 2.6%, and various Lisp dialects 2.4%. The rest,
including lanuages with many libraries such as Java, Perl, and Python,
were below 2% each.
Now, does that prove anything of relevance? I think not.
> If Lisp is really equipped with such an extraordinary power, why
> can't it come up with something similar?
It can, and in many cases it has.
"lisplover" <·········@hotmail.com> writes:
> Let us put it this way, what do you think that all the software that
> support your posting and browsering in this website, from your OS, your
> browser, your networks, to the routers, the web servers, all the
> software involved. what percentage are written in Lisp? If Lisp is
> really equipped with such an extraordinary power, why can't it come up
> with something similar?
It might help if you learned to read with a least a modicum of
retention. As has been pointed out, the answer to your question is
"it already did". And before the existence of what you are talking
about. But the "masses" you are fond of citing, just didn't care.
So, they reinvented it, well some of it anyway.
/Jon
--
'j' - a n t h o n y at romeo/charley/november com
Ask instead the following question: what percentage of all these things
was *originally* (in the mists of time) written in Lisp?
C-x C-c
--
Marco
lisplover wrote:
> Let us put it this way, what do you think that all the software that
> support your posting and browsering in this website, from your OS, your
> browser, your networks, to the routers, the web servers, all the
> software involved. what percentage are written in Lisp? If Lisp is
> really equipped with such an extraordinary power, why can't it come up
> with something similar?
>
> By the way: yes mass is stupid. I know a lot of idiots who are using
> Windows.
I know a lot of idiots that think that by using obsolete black terminals
from the 70's on top of bloated monolithic kernels will make them look
smarter.
lisplover wrote:
> If Lisp is so cool -- a qualitative measure -- why can't it attract a
> critical mass of people?
Because people are not attracted by coolness. Never. They're attracted
by
popularity (artificially created by market specialists - which involves
the
tons of money investments). Average people don't know how to assess the
programming language coolness.
> Do you think that if there really exists a
> language 10 times more efficient, The majority programmers would just
> sit there, content with some stupid 10 times less efficient language
> whill totally ignoring that much powerful language?
Yes, we KNOW it. The majority always choosing a shit.
Thousands of flyes can't be wrong, yes? Shit is very tasty!
> Or are you
> expecting that the majority are so stupid that they can't master this
> powerful language to make any use?
Majority aren't stupid. They're just don't care. They don't want to
assess
the tools they're using - they relies on popularity, not on the
objective
properties of the tools. Not only in programming.
lisplover wrote:
> If Lisp is so cool -- a qualitative measure -- why can't it attract a
> critical mass of people? Do you think that if there really exists a
> language 10 times more efficient, The majority programmers would just
> sit there, content with some stupid 10 times less efficient language
> whill totally ignoring that much powerful language? Or are you
> expecting that the majority are so stupid that they can't master this
> powerful language to make any use? Obviously not. There must be some
> flaws there. I am totally not trolling. I just think there must exist
> some defects and try to find it out. After all, it is such an elegant
> idea from original Lisp to be described as "Maxwell's Equations of
> Software!". And what a pity it is that this language is just for some
> advocates' toys.
>
The world is full of defects. Is that a problem???
Well you acentuate one of the reasons. Handwringing and the
you-go-first syndrome. How have your statements so far done anything
productive? As another poster has asked, "what libraries
specifically do you need?". Also with all your comments so far
I have to ask "well are you going to use Lisp or are you not?".
That is all that is important, quit dancing at the water's edge
and dive in, the water's fine.
Wade
From: Marco Baringer
Subject: Re: why not enough lisp libraries?
Date:
Message-ID: <m2acpuunv9.fsf@soma.local>
"lisplover" <·········@hotmail.com> writes:
> If Lisp is so cool -- a qualitative measure -- why can't it attract a
> critical mass of people? Do you think that if there really exists a
> language 10 times more efficient, The majority programmers would just
> sit there, content with some stupid 10 times less efficient language
> whill totally ignoring that much powerful language?
yes, that's exactly what they'll do. but not for techincal reasons.
> Or are you
> expecting that the majority are so stupid that they can't master this
> powerful language to make any use?
they're not stupid, but they don't see the gain (which comes later)
only the initial cost of learning a new language.
> Obviously not. There must be some
> flaws there. I am totally not trolling. I just think there must exist
> some defects and try to find it out. After all, it is such an elegant
> idea from original Lisp to be described as "Maxwell's Equations of
> Software!". And what a pity it is that this language is just for some
> advocates' toys.
your analysis forgets that using a technology (lisp in this case) is
far more a social choice than a technical one. people generally use
what they know, if they're feeling adventerous they'll use what their
friends say is cool or what they read about on the internet. only a
small percentage will go out a pick a random language and start using
it. only a small percentage of that small percentage will stick with
the new language long enough to work through their own personal mental
baggage and start actually learning the language (instead of staring
at the syntax). even then there are other factors involved: existing
code bases written in other languages, other people on the team
withstronger personalities (or better ties to "management"), etc.
technical merit alone means little or nothing in the real world, just
look at what happened to lisp :)
--
-Marco
Ring the bells that still can ring.
Forget the perfect offering.
There is a crack in everything.
That's how the light gets in.
-Leonard Cohen
On 24 Feb 2005 04:35:44 -0800, lisplover <·········@hotmail.com> wrote:
> If Lisp is so cool -- a qualitative measure -- why can't it attract a
> critical mass of people? Do you think that if there really exists a
> language 10 times more efficient, The majority programmers would just
> sit there, content with some stupid 10 times less efficient language
> whill totally ignoring that much powerful language? Or are you
> expecting that the majority are so stupid that they can't master this
> powerful language to make any use? Obviously not. There must be some
> flaws there. I am totally not trolling. I just think there must exist
> some defects and try to find it out. After all, it is such an elegant
> idea from original Lisp to be described as "Maxwell's Equations of
> Software!". And what a pity it is that this language is just for some
> advocates' toys.
>
Last I checked Lisp was used professionally by some 30 000 users.
This is much less than the million or so C++ users but it's
hardly a toy language for advocates.
Why don't you check your facts.
Commercial products like Allegro Lisp and LispWorks Lisp have
pretty decent libraries. Lisp has a strong tradition in
CAD/CAM. It is not much used in home or business products
,more in industry, so you don't notice it as much.
--
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
"lisplover" <·········@hotmail.com> writes:
> If Lisp is so cool -- a qualitative measure -- why can't it attract a
> critical mass of people? Do you think that if there really exists a
> language 10 times more efficient, The majority programmers would just
> sit there, content with some stupid 10 times less efficient language
> whill totally ignoring that much powerful language?
Your numbers are wrong. Lisp probably is not 10 times more efficient
than, say, Java or Python, for any reasonable definition of
(programmers') "efficiency". It's executables are in general not 10
times faster or smaller than, say, those of C or C++ or Fortran.
Still people like using it. If you don't, then go and use something
else. Otherwise, you won't learn much and are not helping anyone.
"lisplover" <·········@hotmail.com> writes:
> If Lisp is so cool -- a qualitative measure -- why can't it attract a
> critical mass of people?
You can't be serious, can you??
> Do you think that if there really exists a language 10 times more
> efficient, The majority programmers would just sit there, content
> with some stupid 10 times less efficient language whill totally
> ignoring that much powerful language?
Absolutely. If you don't understand this, I'd say that's 90% of your
problem in understanding anything being written here.
/Jon
--
'j' - a n t h o n y at romeo/charley/november com
lisplover wrote:
> If Lisp is so cool -- a qualitative measure -- why can't it attract a
> critical mass of people?
I think it can.
> Do you think that if there really exists a
> language 10 times more efficient, The majority programmers would just
> sit there, content with some stupid 10 times less efficient language
> whill totally ignoring that much powerful language?
Yes.
> Or are you
> expecting that the majority are so stupid that they can't master this
> powerful language to make any use? Obviously not.
No. But I know that Lisp takes much more time to learn before you can
write some useful program while other languages manage it better to give
you some kind of feeling of success earlier on. That's I think why more
people stick with the latter languages than with Lisp (or other more
"complex" languages).
The big advantage of Lisp to me is that it makes complex things easier
to tackle, and it achieves this by making some of the easier things
harder to tackle as a side effect.
> There must be some flaws there.
Call them trade offs, and you're much closer to the truth. I don't care
about the lack of libraries for Lisp that you seem to have in mind. I
even don't know about the lack of some libraries because the respective
problem domains are of no interest to me. The stuff that I _am_
interested in is exceptionally well covered in Lisp, much better than in
any other language I know of.
If your trade offs are different you may either choose to improve the
situation for Lisp or switch to a different language where things are
much better off for you.
As other people have already asked you, what is your actual problem?
Pascal
Pascal Costanza <··@p-cos.net> writes:
> No. But I know that Lisp takes much more time to learn before you can
> write some useful program while other languages manage it better to
> give you some kind of feeling of success earlier on. That's I think
> why more people stick with the latter languages than with Lisp (or
> other more "complex" languages).
>
> The big advantage of Lisp to me is that it makes complex things easier
> to tackle, and it achieves this by making some of the easier things
> harder to tackle as a side effect.
I'm not sure that I agree with you that Lisp takes more time to learn
before you can write useful programs. I suppose it hinges on the
definition of useful though. I just remember finding C a challenge
when I first tackled it. And at that time, I was using commercial
tools that were designed to get you going quickly.
I think Perl was the easiest for me, but I never attempted to do any
GUI programming with it. Not unless you count HTML and I don't.
I do agree that there is a lot to Lisp. I suspect I will be picking
up new tricks for as long as I stick with it.
--
An ideal world is left as an excercise to the reader.
--- Paul Graham, On Lisp 8.1
I have tons and tons of examples where the "majority" of people is "just
wrong". Shall we go into politics? :)
Bottom line: if there is no library, write one! But be careful. It's
better be a very good one and pass the "global test" of TRT-ness :)
Cheers
--
Marco
lisplover wrote:
> If Lisp is so cool -- a qualitative measure -- why can't it attract a
> critical mass of people? Do you think that if there really exists a
> language 10 times more efficient, The majority programmers would just
> sit there, content with some stupid 10 times less efficient language
> whill totally ignoring that much powerful language? Or are you
> expecting that the majority are so stupid that they can't master this
> powerful language to make any use? Obviously not. There must be some
> flaws there. I am totally not trolling. I just think there must exist
> some defects and try to find it out. After all, it is such an elegant
> idea from original Lisp to be described as "Maxwell's Equations of
> Software!". And what a pity it is that this language is just for some
> advocates' toys.
>
Marco Antoniotti Feb 24, 1:02 pm wrote:
==
I have tons and tons of examples where the "majority" of people is
"just
wrong". Shall we go into politics? :)
Bottom line: if there is no library, write one! But be careful. It's
better be a very good one and pass the "global test" of TRT-ness :)
==
But first people need some incentives. I am working on a PhD in physics
and my colleagues are using Matlab or IDL.
However, in the past Dubois has pushed Python quite a lot in the
journal "Computing in Science and Engineering". His articles gave me
the motivation to explore seomething different.
Though, I hate Python and will tell everybody that it is a piece of
crap, but I had a motivator in person of Dubois to use something
different when steering code.
In the meantime I mostly use Bigloo. I even made a small contribution
to it: a very good binding to the high quality plotting library DISLIN.
First I started out with a small C binding to some plotting options
which I could use for my daily work. After that I realized it would be
a good idea to make a whole binding. That undertaking took me 2 years;
I was a lazy binding-worker.
Förster vom Silberwald
PS: The binding is downloadable from the official Bigloo homepage.
F�rster vom Silberwald wrote:
> Marco Antoniotti Feb 24, 1:02 pm wrote:
> ==
> I have tons and tons of examples where the "majority" of people is
> "just
> wrong". Shall we go into politics? :)
>
> Bottom line: if there is no library, write one! But be careful. It's
> better be a very good one and pass the "global test" of TRT-ness :)
> ==
>
> But first people need some incentives. I am working on a PhD in physics
> and my colleagues are using Matlab or IDL.
Of course people need incentives.
> However, in the past Dubois has pushed Python quite a lot in the
> journal "Computing in Science and Engineering". His articles gave me
> the motivation to explore seomething different.
Pardon my ignorance: who is Dubois?
>
> Though, I hate Python and will tell everybody that it is a piece of
> crap, but I had a motivator in person of Dubois to use something
> different when steering code.
>
> In the meantime I mostly use Bigloo. I even made a small contribution
> to it: a very good binding to the high quality plotting library DISLIN.
>
> First I started out with a small C binding to some plotting options
> which I could use for my daily work. After that I realized it would be
> a good idea to make a whole binding. That undertaking took me 2 years;
> I was a lazy binding-worker.
Almost good. You are not passing the global TRT-ness test :) To do so
you have to port your library to UFFI and put the binding on
common-lisp.net.
Cheers
--
Marco
Marco Antoniotti wrote:
> Pardon my ignorance: who is Dubois?
Paul F. Dubois is a mathematican at the Lawrence Livermore National
Laboratory. He is also an editor of the journal "Computing in Science
and Engineering".
Dubois is also involved into Python Numerics.
I think Dubois wrote also some books (e.g. using Eiffel in scientific
programming).
Regards,
Förster vom Silberwald
"lisplover" <·········@hotmail.com> writes:
> If Lisp is so cool -- a qualitative measure -- why can't it attract a
> critical mass of people?
I think most people don't get into Lisp because they don't have a lot
of friends already hacking in Lisp. Perhaps a more pragmatic reason
would be that they are making money hacking in some other language and
just don't see a need to learn anything else. Or perhaps they are
looking for a language to hack in and want to hack in what everyone
else is hacking.
What does it say about me that I am hacking in a language with less
than 1% market penetration on a platform with less than 5% market
penetration? It sure doesn't seem to scream practical. But I enjoy
doing it and that is a strictly personal issue.
--
An ideal world is left as an excercise to the reader.
--- Paul Graham, On Lisp 8.1
"lisplover" <·········@hotmail.com> wrote on 24 Feb 2005 04:3:
> Do you think that if there really exists a language 10 times more
> efficient, The majority programmers would just sit there, content with some
> stupid 10 times less efficient language whill totally ignoring that much
> powerful language?
Yes, and Lisp is a real-world example of this.
You clearly don't understand that there are lots of issues that go into
choosing what computer language to use, aside from how efficient, or cool,
or productive the language is.
You might want to look into concepts like "total cost of ownership", to begin
to get an idea how decisions are really made in the real world.
> I am totally not trolling. I just think there must exist some defects and
> try to find it out.
You are ignorant, yet making strong assumptions. You can't believe that there
might be reasons OTHER than "defects" in design, why a computer language
hasn't taken over the world in popularity.
Open your eyes a bit. Other issues matter too. Without commenting on whether
Lisp has defects or not, it's obvious that Lisp could be perfect in design yet
still less popular than many alternatives.
People assume you are trolling, because it's hard to believe that you're really
this ignorant. Especially when everybody on this thread keeps pointing out
how flawed your assumptions are, but you just ignore this education and
continue to repeat your silly claims.
If you're not a troll, then try to read and learn a little bit, before
continuing your biased crusade.
-- Don
_______________________________________________________________________________
Don Geddis http://don.geddis.org/ ···@geddis.org
Incompetence: When you earnestly believe you can compensate for a lack of
skill by doubling your efforts, there's no end to what you can't do.
-- Despair.com
"F�rster vom Silberwald" <··········@hotmail.com> wrote on 24 Feb 2005 03:0:
> why there are not more of that kind of libraries for Lisp if Lisp -
> allegedly -- is that cool?
What makes you think that coolness (of language design) has much of anything
to do with the quantity of libraries?
You obviously don't understand anything about the social process by which
libraries get made.
Here's a suggestion: rather than looking at second-order effect (like how
many libraries there are), if you wonder about Lisp's "coolness", why don't
you just evaluate that directly? Why don't you actually learn something about
Lisp, and see how cool the design is yourself?
> comp.lang.lisp would be better off answering questions in a human
> manner instead of fooling itself.
> What is wrong with Lisp users?
You're getting the reaction you see, not because the question is sensitive,
but instead because you're an ignorant person making insulting claims in
the middle of asking the question.
The reactions you get are just returning the favor to what you started.
If you want a real answer, try not making so many assumptions, and realize
how ignorant you are to start with. Then ask people to help educate you.
You may learn a lot.
-- Don
_______________________________________________________________________________
Don Geddis http://don.geddis.org/ ···@geddis.org
If a kid asks where rain comes from, I think a cute thing to tell him is "God
is crying." And if he asks why God is crying, another cute thing to tell him
is "Probably because of something you did." -- Deep Thoughts, by Jack Handey
"F�rster vom Silberwald" <··········@hotmail.com> writes:
> He asked questions - right? So lets nail it down: why there are not
> more of that kind of libraries for Lisp if Lisp - allegedly -- is that
> cool?
Because there are.
BTW, have you stopped beating your wife?
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
·······@gmail.com wrote:
> If you'll show a list of Java libraries that you'd like to see in
> Lisp, we will have a lot of fun here.
Well, since you're offering, I'd love a good library for LDAP. Do you
know of one?
S-
·····@salkin.org wrote:
> ·······@gmail.com wrote:
> > If you'll show a list of Java libraries that you'd like to see in
> > Lisp, we will have a lot of fun here.
>
> Well, since you're offering, I'd love a good library for LDAP. Do you
> know of one?
The dumbest way: use Lisp with Java FFI (ABCL, for example).
Another way: use ELisp implementations (there are some). It's quite
easy
to convert elisp to CL or to embed it without direct code conversion.
·····@salkin.org writes:
> Well, since you're offering, I'd love a good library for LDAP. Do you
> know of one?
I've been doing work with LDAP lately. My approach consisted of an LDIF
parser and wrappers to "ldapsearch" etc. Not necessarily the most
efficient, but it works well enough and there are no FFI issues involved
(invoking of OS-level subprocesses is required, of course). For my
needs a dependency on OpenLDAP isn't too heinous.
You can see what I have at svn://piro.quadium.net/ldif/ and
svn://piro.quadium.net/ldap/. Right now only querying works and there's
some stuff I want to clean up, but everything should be there come next
week or so. CMUCL is required currently as well (for #'EXT:RUN-PROGRAM).
--
vsync
http://quadium.net/
Out came what has to be the filthiest thing from my head. Two and a
half inches long, dark green/brown and stained with a little blood on
the end, it was close to the consistency of a pencil eraser in parts,
moving to the consistency of jello at one end.
-- http://linux.slashdot.org/comments.pl?sid=137001&cid=11448177
As promised, I've put together a tarball and some documentation for
my LDIF parsing and LDAP connectivity libraries.
NET.QUADIUM.LDIF is an LDIF reading and writing library. It provides
support for reading and writing data records, and minimal support
for reading and writing change records (this support will be enhanced in
future).
NET.QUADIUM.LDAP is a library for searching and modifying LDAP
directories. It utilizes the OpenLDAP client-side utilities for the
connectivity (meaning it will work on any platform where these utilities
are available, at the cost of some efficiency), and NET.QUADIUM.LDIF for
reading and writing the records. It also provides a convertor of search
filters from a sexp form to the string form expected by OpenLDAP.
Functionality isn't fully guaranteed at this point... I've tested
informally at this point (on CMUCL against a slapd server) but I haven't
had the chance to put together either a set of examples or the
accompanying unit tests. I intend to have this complete before I tag it
1.0.
A tarball of version 0.9 of both these libraries, along with the current
version of my NET.QUADIUM.TOYS miscellaneous utility library is
available at:
* http://quadium.net/code/ldap-0.9.tar.gz
* http://quadium.net/code/ldap-0.9.tar.gz.asc
PDF documentation for both libraries is included in the tarball.
The libraries are licensed under the GNU Lesser General Public License.
Contributions of suggestions, bug reports, and patches are of course
welcome. If you have any questions or difficulties please let me know
and I'll ensure that more details make it into the documentation.
--
vsync
http://quadium.net/
Out came what has to be the filthiest thing from my head. Two and a
half inches long, dark green/brown and stained with a little blood on
the end, it was close to the consistency of a pencil eraser in parts,
moving to the consistency of jello at one end.
-- http://linux.slashdot.org/comments.pl?sid=137001&cid=11448177
The OP isn't wholly wrong, so we need to clarify the topic. Lisp has
tons of libraries. However, they're scattered around. You have to go
to sourceforge, or commonlisp.net, or the AI repository, or the wiki.
You have to know reputation and gossip--which popular c.l.l figure
writes good code, which libraries are hot, which are immature. It's
like academia, where you often need a human expert to point you to the
right places in the literature.
Also, you learn more by doing, so rolling your own library is more fun.
Especially in Lisp, where we look for ways to say things that are
beautiful as well as correct.
···············@yahoo.com writes:
> Also, you learn more by doing, so rolling your own library is more fun.
> Especially in Lisp, where we look for ways to say things that are
> beautiful as well as correct.
I agree with you, but people could argue that it is faster to use a
good pre-existing library than to roll your own. And they would have
a point. Perl's CPAN is a big deal for example. Perl is a language
made for gluing components together. For a verbose and inflexible
language like Java, comprehensive class libraries are a major win. I
mean how else are you going to get anything done in Java in a human
lifetime?
As far as Lisp goes, I don't think the principle is any different.
Having a decent library of code gives you a leg up. Building good
infrastructure from scratch is hard.
That said, I think I'm learning something about Lisp by trying to
develop infrastructure for my own project.
--
An ideal world is left as an excercise to the reader.
--- Paul Graham, On Lisp 8.1
David Steuber wrote:
> I agree with you, but people could argue that it is faster to use a
> good pre-existing library than to roll your own. And they would have
> a point. Perl's CPAN is a big deal for example. Perl is a language
> made for gluing components together.
Perl's CPAN is a pretty good example: 90% of it is crap. If you're
going to depend on a library from CPAN, you generally need to read the
code yourself first and try it out, or go by the reputation of the
author, or ask around for recommendations on mailing lists. Some parts
of CPAN are great, other parts are pants (and I'm not just talking
about the Acme namespace). Just because you can download all of it
from the same FTP site doesn't mean it's all finished, all of a
consistent quality, or all works well together.
The situation is really not so different for CL, except that there's
the additional indirection layer on cliki, and the overall volume is
smaller.
-dan
On 2005-02-23, ···@telent.net <···@telent.net> wrote:
>
> David Steuber wrote:
>> I agree with you, but people could argue that it is faster to use a
>> good pre-existing library than to roll your own. And they would have
>> a point. Perl's CPAN is a big deal for example. Perl is a language
>> made for gluing components together.
>
> Perl's CPAN is a pretty good example: 90% of it is crap. If you're
> going to depend on a library from CPAN, you generally need to read the
> code yourself first and try it out, or go by the reputation of the
> author, or ask around for recommendations on mailing lists. Some parts
> of CPAN are great, other parts are pants (and I'm not just talking
> about the Acme namespace). Just because you can download all of it
> from the same FTP site doesn't mean it's all finished, all of a
> consistent quality, or all works well together.
>
> The situation is really not so different for CL, except that there's
> the additional indirection layer on cliki, and the overall volume is
> smaller.
Another problem I have had with CPAN, is that some software I want to
install depends on a particular module in CPAN. If this module later have
been changed, it may be incopatible with the program I want to install, yet
this program only requires 'module', and not 'module in version x', or
'module in versions between x and y'. I don't know whether this is
possible to specify this in CPAN, but the package systems of most Linux
distributions can do this (more or less), so it is solvable. It is definitly
a problem if you have two programs requiring different versions of this
module.
A CL package system should try to solve these issues. The first
I know how should be fixed, but the second I'm not sure about. It's
certain that two packages with the same name can't run in the same lisp
image. Then either the version must be in the package name (ugly), or
the package search path must be updated dynamicly when a module of a
particular version is required.
--
Gisle S�lensminde, Phd student, Scientific programmer
Computational biology unit, University of Bergen, Norway
Email: ·····@cbu.uib.no | Complicated is easy, simple is hard.
On 23 Feb 2005 14:27:04 GMT, Gisle Sælensminde <·····@kaktus.ii.uib.no>
wrote:
> A CL package system should try to solve these issues. The first
> I know how should be fixed, but the second I'm not sure about. It's
> certain that two packages with the same name can't run in the same lisp
> image. Then either the version must be in the package name (ugly), or
> the package search path must be updated dynamicly when a module of a
> particular version is required.
>
This problem seems to rear it's ugly head from time to time.
COM has a design which tries to remedy this problem.
Instead of each program using DLL's com objects pointers are stored
in the registry. When a new version comes out it inherits from the old one
overloading and extending it. The software that depended on the old version
still works and new software can make use of the new features.
COM is a open standard and if you were to make a system to write
extensible libraries I would take a sideway glance to get a few ideas.
--
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Up spake David Steuber:
> As far as Lisp goes, I don't think the principle is any different.
> Having a decent library of code gives you a leg up. Building good
> infrastructure from scratch is hard.
You could learn about lisp by writing a CCLAN download-compile-install library :-)
> That said, I think I'm learning something about Lisp by trying to
> develop infrastructure for my own project.
--
-trent
I'm not afraid of flying.
I'm afraid of being 35,000 feet up and suddenly *not* flying.
Trent Buck <·········@tznvy.pbz> writes:
> Up spake David Steuber:
> > As far as Lisp goes, I don't think the principle is any different.
> > Having a decent library of code gives you a leg up. Building good
> > infrastructure from scratch is hard.
>
> You could learn about lisp by writing a CCLAN download-compile-install library :-)
yasdf-install?
David Steuber <·····@david-steuber.com> writes:
> For a verbose and inflexible language like Java, comprehensive class
> libraries are a major win.
Just an idea: Is it possible that the inflexibility of Java even makes
it easier to agree to develop a large amount of co-existing libraries?
I'm not programming in Java, but I think I'd have a quite precise
expectation on how a Java library should look like (essentially
object-based, method names look such-and-such, errors handled by
exceptions that look such-and-such, etc.).
With CL I'm not so sure. There are so many possibilities: Shall I use
a functional style? OOP? Define a domain specific language? What are
the naming conventions? From the CL standard at least I can't deduce
many general rules (on this superficial level).
Matthias wrote:
> Just an idea: Is it possible that the inflexibility of Java even
makes
> it easier to agree to develop a large amount of co-existing
libraries?
> I'm not programming in Java, but I think I'd have a quite precise
> expectation on how a Java library should look like (essentially
> object-based, method names look such-and-such, errors handled by
> exceptions that look such-and-such, etc.).
You're idealizing Java. It is not so fixed that you have only one True
Way
to implement a given functionality. It is flexible enough to make a
mess of
things, and inflexible enough to not allow you to avoid a mess.
So, we have what we have - tons of almost identical and
not-so-reusable Java
libraries, which does well the job which is completely unnecessary in
the
more flexible languages.
Up spake ·······@gmail.com:
> So, we have what we have - tons of almost identical and
> not-so-reusable Java libraries, which does well the job which is
> completely unnecessary in the more flexible languages.
Examples?
Not that I'm disagreeing with you, but like to see arguments backed by
hard facts.
--
-trent
Never trust a computer you can lift.
Trent Buck wrote:
> Up spake ·······@gmail.com:
> > So, we have what we have - tons of almost identical and
> > not-so-reusable Java libraries, which does well the job which is
> > completely unnecessary in the more flexible languages.
>
> Examples?
J2EE. With no exceptions.
All XML-related stuff (we have S-expressions).
All containers implementations.
All bloated stuff ("code generators") that could be easily replaced
with
true macros.
Matthias <··@spam.pls> writes:
> Just an idea: Is it possible that the inflexibility of Java even makes
> it easier to agree to develop a large amount of co-existing libraries?
> I'm not programming in Java, but I think I'd have a quite precise
> expectation on how a Java library should look like (essentially
> object-based, method names look such-and-such, errors handled by
> exceptions that look such-and-such, etc.).
I don't think it's "inflexibility" or even micro idioms such as
naming, etc. I think the main issue is standardization. With Java, you
have a very *known commodity.* It may not be the best, but Sun has
developed and collected a large number of libraries over time, and
then blessed them, giving them *official status.* Because of this,
programmers can use them as basic building blocks to develop even more
libraries, etc. In each case, the standard libraries may not be the
best, but they serve as a common API for everything built above
them. In some cases, they have built things with a standardized API
only, with implementation providers that can then plug in and
implement things (crypto and XML parsing come to mind). In other
cases, you have fewer choices choice and the reference implementation
is the only implementation (the collection classes have some
"pluggability" but not as much as other heavyweight APIs).
> With CL I'm not so sure. There are so many possibilities: Shall I use
> a functional style? OOP? Define a domain specific language? What are
> the naming conventions? From the CL standard at least I can't deduce
> many general rules (on this superficial level).
I actually don't think that's the problem so much as standardizing on
something (anything). If you look at the CLHS, you'll find various
APIs in various styles. The sequence APIs are all functional; the
streams APIs all OOP. This really isn't an issue. The main thing is
that both of those APIs have a standard definition that everybody can
count on, and therefore build on. [In the case of streams, however,
there are issues with multiple APIs rolling around. You have CLHS
streams (which are limited in terms of users defining new stream
types), Gray streams (which nearly made it into the standard and which
everybody pretty much supports), and finally simple streams, which may
or may not have support in any given implementation.]
I'm hopeful that the CLRFI process might bring some amount of
"blessing" to various non-ANSI APIs that have been rattling around in
the ether.
--
Dave Roberts
dave -remove- AT findinglisp DoT com
http://www.findinglisp.com/
Matthias <··@spam.pls> writes:
> Just an idea: Is it possible that the inflexibility of Java even makes
> it easier to agree to develop a large amount of co-existing libraries?
They can co-exist, but often you get libraries that do the same thing in
different ways used by other libraries that you need to use. The various
options all have their flaws because a complete solution for all angles
of usage and all levels of usage isn't possible. You just can't hide
away the details in macros.
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
···············@yahoo.com wrote:
> Also, you learn more by doing, so rolling your own library is more
fun.
> Especially in Lisp, where we look for ways to say things that are
> beautiful as well as correct.
If you said that to me in a job interview, you just failed the
interview *irrespective* of what programming language I am looking for
and how qualified you are.
Rolling a useful, trustworthy library requires thinking about
reusability, access idioms, packaging, and test code. Not to mention
debugging the library and then being responsible for fixing it when the
inevitable bug reports come in.
It is a *large* amount of annoying work. It is normally difficult to
get right and is beset by subtle bugs when you get it wrong. For
example, (length a) could be either O(1) or O(n) if a is a list.
However, that affects whether inserting or joining pieces of lists is
O(n) or O(1). Functionally, though, there is no difference.
I have written and debugged a red-black tree, a doubly-linked list, a
double-ended queue, a heap, etc. far too many times in far too many
languages.
Is it too much to ask that a language have a well-tested,
community-accepted library that at least implements the basic
structures in Cormen, Leiserson, and Rivest? C++, Perl, Python, Java,
and C# don't seem to think so. In fact, many of them even implement
structures far more *advanced* than what is presented in CLR.
And don't get me started about the lack of a community vetted test
suite.
-a
"Andrew P. Lentvorski, Jr." <·····@allcaps.org> writes:
> ···············@yahoo.com wrote:
>> Also, you learn more by doing, so rolling your own library is more
> fun.
>> Especially in Lisp, where we look for ways to say things that are
>> beautiful as well as correct.
>
> If you said that to me in a job interview, you just failed the
> interview *irrespective* of what programming language I am looking for
> and how qualified you are.
Which part, the part where the candidate admits that he (shudders) _likes_
to program, or the part where the candidate tells you he has a sense
of esthetics?
Tell you what, he can come and work for _me_ anytime...
Andrew P. Lentvorski, Jr. wrote:
> ···············@yahoo.com wrote:
>
>>Also, you learn more by doing, so rolling your own library is more
>
> fun.
>
>> Especially in Lisp, where we look for ways to say things that are
>>beautiful as well as correct.
>
>
> If you said that to me in a job interview, you just failed the
> interview *irrespective* of what programming language I am looking for
> and how qualified you are.
>
> Rolling a useful, trustworthy library requires thinking about
> reusability, access idioms, packaging, and test code. Not to mention
> debugging the library and then being responsible for fixing it when the
> inevitable bug reports come in.
>
> It is a *large* amount of annoying work. It is normally difficult to
> get right and is beset by subtle bugs when you get it wrong. For
> example, (length a) could be either O(1) or O(n) if a is a list.
> However, that affects whether inserting or joining pieces of lists is
> O(n) or O(1). Functionally, though, there is no difference.
Well. Define "list" :)
>
> I have written and debugged a red-black tree, a doubly-linked list, a
> double-ended queue, a heap, etc. far too many times in far too many
> languages.
>
> Is it too much to ask that a language have a well-tested,
> community-accepted library that at least implements the basic
> structures in Cormen, Leiserson, and Rivest? C++, Perl, Python, Java,
> and C# don't seem to think so. In fact, many of them even implement
> structures far more *advanced* than what is presented in CLR.
Shameless plug. :) I have the gall to think that red-black trees, heaps
and queues have been around for quite some time. They heve been in the
AI.Repository for some time now :) I wrote them straight out of CLR
more than ten years ago. :) Union-find is in the CLOCC.
I welcome sharp criticism on them. I have a lot of it on my own and
now, if I had the time, I would probably change both implementation and
interfaces.
But I have very little time now and I do little things here and there.
And I agree with your comments above. Rolling out something useful is
very difficult and tedious. Check out cl-unififcation on
common-lisp.net. It is a relatively small thing, but it took a long
time during weekends and nights to write, document, and test. Yet I
feel it is still "80%-assed" :)
Cheers
--
Marco
···············@yahoo.com writes:
> Lisp has tons of libraries. However, they're scattered around. You
> have to go to sourceforge, or commonlisp.net, or the AI repository, or
> the wiki. You have to know reputation and gossip--which popular c.l.l
> figure writes good code, which libraries are hot, which are immature.
> It's like academia, where you often need a human expert to point you
> to the right places in the literature.
Or like... say... C... or Java... or Python... or Perl...
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
Hi, Rahul. This thread started because the OP claimed Java had more
libraries than Lisp. So even if your comment is correct, it belongs as
an immediate descendant of the root node.
"lisplover" <·········@hotmail.com> wrote on 22 Feb 2005 02:2:
> If Lisp is so powerful as believed by many lisp lovers and advocates,
> why there are not enough lisp libraires around to compete with Java?
If you have 1000x as many programmers, but work in 10x worse language,
you'll still write 100x as much code.
> Simply it can't be explained just using "worse is better".
You might want to go back and read that original essay you're referring to.
And perhaps the followups.
It may be right or wrong, but it certainly attempts to explain exact the
issue that concerns you. You can't just dismiss that explanation without
putting in a lot more thought than you clearly have here.
-- Don
_______________________________________________________________________________
Don Geddis http://don.geddis.org/ ···@geddis.org
These are my new shoes. They're good shoes. They won't make you rich like me,
they won't make you rebound like me, they definitely won't make you handsome
like me. They'll only make you have shoes like me. That's it.
-- Charles Barkley
Don Geddis <···@geddis.org> writes:
> "lisplover" <·········@hotmail.com> wrote on 22 Feb 2005 02:2:
>
> > Simply it can't be explained just using "worse is better".
>
> You might want to go back and read that original essay you're referring to.
> And perhaps the followups.
I just had a thought on this. Compare Lisp to C/C++ and you get
Worse:
* Lisp is slow.
* Lisp uses a lot of memory.
Technology advances and along comes Java so you get
Better:
* Lisp is fast (compared to Java, Perl, Python, etc) and is
actually quite competitive with C/C++ depending on the compiler
used.
* Lisp doesn't use as much memory. Java is a huge memory hog.
Heck, look at newer web browsers written in C/C++ and observe
just how big a memory foot print they have. On my system,
Safari is almost always the largest user of system memory.
Best:
* Lisp may not be able to turn a sow's ear into a world class
programmer, but it will let a good programmer do a lot more than
he could do in Java for the same reasons Python will. The
language is at a higher level and offers better abstractions.
--
An ideal world is left as an excercise to the reader.
--- Paul Graham, On Lisp 8.1
>> "lisplover" <·········@hotmail.com> wrote on 22 Feb 2005 02:2:
>> > Simply it can't be explained just using "worse is better".
> Don Geddis <···@geddis.org> writes:
>> You might want to go back and read that original essay you're referring to.
David Steuber <·····@david-steuber.com> wrote on 23 Feb 2005 02:3:
> I just had a thought on this. Compare Lisp to C/C++ and you get
> Worse:
> * Lisp is slow.
> * Lisp uses a lot of memory.
> Technology advances and along comes Java so you get
> Better:
[...]
> Best:
[...]
I can't quite tell, but it seems to me you might be talking about something
orthogonal to the meaning of "worse is better". Just in case you didn't know,
you can read more about the history of the topic here:
http://www.dreamsongs.com/WorseIsBetter.html
The phrase came about in Gabriel's essay on Lisp:
http://www.naggum.no/worse-is-better.html
in particular, this section:
http://www.jwz.org/doc/worse-is-better.html
It is an attempt to explain the rise popularity of Unix and C, over what
might be called objectively superior existing designs like Lisp. The
explanation (in part) is roughly that implementation simplicity (of the OS or
programming language) allows its rapid spread, and once it is ubiquitous, it
wins, regardless of the "objective quality" of the design.
"Worse is better" isn't about Lisp being slow or using a lot of memory.
-- Don
_______________________________________________________________________________
Don Geddis http://don.geddis.org/ ···@geddis.org
On Wed, 23 Feb 2005 18:59:56 -0800, <···@geddis.org> wrote:
>
> It is an attempt to explain the rise popularity of Unix and C, over what
> might be called objectively superior existing designs like Lisp. The
> explanation (in part) is roughly that implementation simplicity (of the OS or
> programming language) allows its rapid spread, and once it is ubiquitous, it
> wins, regardless of the "objective quality" of the design.
I would think that cost is a major factor here. The existance of
alternative low cost code sources for Unix tools had to contribute to
its spread. The clear example I would cite is later in time, the rise
of linux, but the FSF had made available many tools to someone with a
unix machine. The Lisp vendors sold both "parts", the hardware and
software and they seem to have been the only source.
What was the list price of a Lisp Machine versus an early sparc (such
as the currently named 'classic') ? Was there a comparable Lisp
organization to FSF and the ftp.gnu.org repository? How internet
capable were those early Lisp Machines anyway?
Unix clearly offered the oportunity to do such things as I did in
1987, add emacs to our HP720 workstation so that editing NEC files
became simple. It took a short period of my time and had no
additional cost over the monthly infrastructure costs. Was there a
comparable ability on a Lisp Machine of that era?
How it happened can probably be discussed over and over, but certainly
you are right about 'once it is ubiquitous'.
--
Everyman has three hearts;
one to show the world, one to show friends, and one only he knows.
From: Christopher C. Stacy
Subject: Re: why not enough lisp libraries?
Date:
Message-ID: <uu0o2l5cw.fsf@news.dtpq.com>
There's no point in trying to correlate popularity with quality;
you're barking up the wrong tree. Most people prefer to wallow in crap.
It's comfortable and familiar, and it already smells like they do.
The main reason why C became more popular than Lisp is that most
schools would teach you to program in C, but none taught Lisp.
There were very few Lisp programmers in the world, all in very
elite ivory towers. By the time "workstations" were invented,
the battle was already over. Most people are not willing to
throw away most of what they learned and move to a new technology,
and most people did not need anything approaching the capability
of a Lisp Machine. It was too far ahead of its time.
Your questions about Lisp Machines are way off base in terms of both
timelines and capabilities. Comparing the SPARC to the Lisp Machine,
you are off by over a decade. Comparing the network capabilities,
there really was no comparison. The Lisp Machine's networking
features were much better than what is available on systems today.
Even if the Lisp Machine had cost far less, most people would not
have bought them. Lisp Machines could have been a continuing niche
player if the companies (eg. Symbolics) had played their cards better.
But Lisp was subsequently killed off due to its association with the
"failure" of the AI bubble (cf. "AI Winter").
Since then, Lisp has been in stealth mode. The few companies
smart enough to use it don't want to tell. At first, because
it was unpopular. Later, because it gave them a secret advantage.
Today, enough time and shit has passed that some people are taking
another look. (There are no fabulous Lisp Machine operating systems,
of course, but there are development environments and libraries.)
Note that you don't hear much on this newsgrup about the extensive
libraries available in the commercial versions of Lisp; that's not
because they don't exist. Just that most of the traffic here is
about free software libraries that people are developing.
On Thu, 24 Feb 2005 08:38:55 GMT, <······@news.dtpq.com> wrote:
> There's no point in trying to correlate popularity with quality;
> you're barking up the wrong tree. Most people prefer to wallow in crap.
> It's comfortable and familiar, and it already smells like they do.
Gee, that should go a long way to dispelling the myth about elitist
Lisp programmers.
> The main reason why C became more popular than Lisp is that most
> schools would teach you to program in C, but none taught Lisp.
Schools teach what students demand.
> Your questions about Lisp Machines are way off base in terms of both
> timelines and capabilities. Comparing the SPARC to the Lisp Machine,
> you are off by over a decade. Comparing the network capabilities,
> there really was no comparison. The Lisp Machine's networking
> features were much better than what is available on systems today.
Let's see Metcalf invented ethernet in 1973, the first Lisp Machines
appeared in 1980 and the Sparc came out in 1989. Well, I guess it was
too hard to compare to whatever was kicking butt on the Lisp Machine,
something was around, maybe that huge PDP-9 I played Spacewar on in
1980 when the beamline was down. Even in the 80s, I remember most
internetworking as dialups at 110 to 300 baud, while getting a 9600
baud line for a local connection was godly. If that's what you mean
by better networking, then it's hard not to agree, but in the ethernet
world there is very little new under the sun.
> Even if the Lisp Machine had cost far less, most people would not
> have bought them. Lisp Machines could have been a continuing niche
> player if the companies (eg. Symbolics) had played their cards better.
> But Lisp was subsequently killed off due to its association with the
> "failure" of the AI bubble (cf. "AI Winter").
Nope, that might have stopped sales after that point, but an installed
base would not have abandoned expensive hardware without excellent
justification. Glad you back up my point about cost tho. If the rise
and fall of AI occurred over 6 months, this might be a reason, since
momentum didn't have time to build. Again, either the Lisp Machines
were simply too expensive compared to alternatives (wouldn't be a
surprise, since the ivory tower hasn't ever run a business anywhere
but down) or they were badly marketed. Maybe the creators thought
that people would simply fall over themselves to rush to buy this
wonderous machine...but people need to be told why something is
wonderous, they are usually too busy doing something else to work that
out on their own.
> Note that you don't hear much on this newsgrup about the extensive
> libraries available in the commercial versions of Lisp; that's not
> because they don't exist. Just that most of the traffic here is
> about free software libraries that people are developing.
I've visited the commercial websites and read their blurbs, but I've
also visited CPAN or freshmeat or sourceforge, they represent what I
consider to be "extensive".
The OP seems right, I see that every time I look up some project on
Cliki only to find that once again there are dead links or source was
never released. CL certainly has potential, I expect it to solve my
problems rather well, but it appears that potential remains largely
unrealized in readily accessible form. Hopefully, the rise of Cliki,
weblogs, and the websites will allow momentum to be built up
permanently in the second coming.
--
Everyman has three hearts;
one to show the world, one to show friends, and one only he knows.
From: Christopher C. Stacy
Subject: Re: why not enough lisp libraries?
Date:
Message-ID: <upsyqkwvx.fsf@news.dtpq.com>
GP lisper <········@CloudDancer.com> writes:
> Let's see Metcalf invented ethernet in 1973, the first Lisp Machines
> appeared in 1980 and the Sparc came out in 1989.
Wrong.
GP lisper <········@CloudDancer.com> writes:
> Schools teach what students demand.
Luckily not where I live, or I would quit.
--
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.
---------------------------------------------------------------------
From: Christopher C. Stacy
Subject: Re: why not enough lisp libraries?
Date:
Message-ID: <ud5upr3yi.fsf@news.dtpq.com>
Robert Strandh <·······@labri.fr> writes:
> GP lisper <········@CloudDancer.com> writes:
>
> > Schools teach what students demand.
>
> Luckily not where I live, or I would quit.
It depends on the kind of school and the purpose of the particular
courses. In most cases, in undergraduate studies for the computer field,
that's exactly what they do. They teach a language that is popular in
the market, such as C++ or Java. In 1971 when I first started learning
about computers, they taught COBOL. They could have taught Algol or PL/I
or Lisp or Simula or SNOBOL or dozens of things. The goal is generally
to crank out what have been called "code monkeys", in some quarters.
The situation with Lisp in schools is now, just recently, somewhat
better than it was in the previous decades. Previously, there was
nobody to teach it, as actualy understanding and using Lisp was
largely restricted to a few ivory towers. That poor situation
created the environment that Lisp Machines were released into,
so it's no wonder that they were not familiar and popular.
The fact that they were expensive was a factor, but if they had been
cheap, I bet they still would not have been accepted. For example,
I watched lots of people (who had free access to them) reject them
because they were unfamiliar. These were experienced programmers,
PhD students, and other sophisticated people. They explained very
clearly that they had already invested all the time in their life
that they were willing to expend on learning new ways of doing things.
I think most people people fall into that category.
It's not strictly speaking the "level" of education that
determines this attitude, although it is correlated with
the amount of further learning that somenoe wants to do.
Plenty of people loved Lisp Machines. Just not enough to make
them generally familiar to and popular with the vast majority.
Combine that with a "dot-com crash" mentality that scapegoats
the technology for not delivering HAL-9000 AI's to the boardroom,
and you've got yourself a bad situation. Fail to recognize early
enough what to do about that big problem, and you've got Symbolics.
Marketing and focus were badly screwed up, as well as totally random
business problems (eg. real estate investments). But price of the
equipment was a potentially mitigating factor - it was largely a
derivative of the overall situation.
Lisp Machines were extraordinarly successful where applied.
On 2005-02-24, Christopher C. Stacy <······@news.dtpq.com> wrote:
>
> Since then, Lisp has been in stealth mode. The few companies
> smart enough to use it don't want to tell. At first, because
> it was unpopular. Later, because it gave them a secret advantage.
> Today, enough time and shit has passed that some people are taking
> another look. (There are no fabulous Lisp Machine operating systems,
> of course, but there are development environments and libraries.)
This is not the main point, but....
The theory of 'Lisp as a secret weapon', regularly comes up on cll.
My impression is quite the oposite. Companies that have succeded using
some kind of exotic technology are often quite proud of it, and tells
it to the world when they can. Now it may be that these are the stupid
ones, and the real smart ones actually manages to keep it secret so well
that very few knows it. I find it hard to belive in such a theory.
Do you have any evidence (knows of) any company that have this 'secret weapon'
strategy, or even unconfirmed rumours about such a company.
--
Gisle S�lensminde, Phd student, Scientific programmer
Computational biology unit, University of Bergen, Norway
Email: ·····@cbu.uib.no | Complicated is easy, simple is hard.
Here is evidence of a successful company that employed Lisp and
considered it a secret weapon. These are two paragraphs from a larger
work at http://paulgraham.com/avg.html, Paul Graham's web site.
-----
"Our secret weapon was similar. We wrote our software in a weird AI
language, with a bizarre syntax full of parentheses. For years it had
annoyed me to hear Lisp described that way. But now it worked to our
advantage. In business, there is nothing more valuable than a technical
advantage your competitors don't understand. In business, as in war,
surprise is worth as much as force.
"And so, I'm a little embarrassed to say, I never said anything
publicly about Lisp while we were working on Viaweb. We never mentioned
it to the press, and if you searched for Lisp on our Web site, all
you'd find were the titles of two books in my bio. This was no
accident. A startup should give its competitors as little information
as possible. If they didn't know what language our software was written
in, or didn't care, I wanted to keep it that way."
-----
On 2005-02-24, njivy <···@njivy.org> wrote:
> Here is evidence of a successful company that employed Lisp and
> considered it a secret weapon. These are two paragraphs from a larger
> work at http://paulgraham.com/avg.html, Paul Graham's web site.
>
> -----
> "Our secret weapon was similar. We wrote our software in a weird AI
> language, with a bizarre syntax full of parentheses. For years it had
> annoyed me to hear Lisp described that way. But now it worked to our
> advantage. In business, there is nothing more valuable than a technical
> advantage your competitors don't understand. In business, as in war,
> surprise is worth as much as force.
>
> "And so, I'm a little embarrassed to say, I never said anything
> publicly about Lisp while we were working on Viaweb. We never mentioned
> it to the press, and if you searched for Lisp on our Web site, all
> you'd find were the titles of two books in my bio. This was no
> accident. A startup should give its competitors as little information
> as possible. If they didn't know what language our software was written
> in, or didn't care, I wanted to keep it that way."
> -----
>
I'll give you a point for this, but at the same time, it seems like Paul
Graham that started the whole 'secret weapon' theory, like in his essay
'Beating the avarages', see http://www.paulgraham.com/avg.html. I don't know
how much he activly tried to keep it secret before he left viaweb, or whether
it was just lack of interest from the outside world. After he left the company
he has definitly not kept it secret.
A more important lesson of viaweb, is that it does not matter which programing
language you are using, as long as you have a significant product or service to
offer. Then you can focus on that. In the other hand, of you don't have a
significant product to offer, you can instead try to get attention telling
the world that you are using the latest fashion in programming languages and
software development methodology (as well as an average product). At least
during the dot.com boom, this was enough to convince some investors.
--
Gisle S�lensminde, Phd student, Scientific programmer
Computational biology unit, University of Bergen, Norway
Email: ·····@cbu.uib.no | Complicated is easy, simple is hard.
Gisle S�lensminde wrote:
> Companies that have succeded using
> some kind of exotic technology are often quite proud of it, and tells
> it to the world when they can.
How would you know they do this 'often', if you can't know about the
ones that don't?
Paul
On 2005-02-24, Paul F. Dietz <·····@dls.net> wrote:
> Gisle S�lensminde wrote:
>
>> Companies that have succeded using
>> some kind of exotic technology are often quite proud of it, and tells
>> it to the world when they can.
>
> How would you know they do this 'often', if you can't know about the
> ones that don't?
>
> Paul
I know of companies that use lisp, or other unusual programing languages, and is proud
of it, and by often, I mean that I know of several such companies. Of cause I can't compare
it with the number of 'secret weapon' companies, because I don't know their numbers. In fact I
don't know of even a single such company. Companies don't always manage to keep their
secrets, so if this is fairly common, I think that at least somone on this group would
have heard about such companies.
As examples of companies that don't try to hide the fact, you can see at the 'success stories'
section at the franz web pages. Not all of these companies mention Lisp in their marketing
material, but I don't think that qualifies to call it a secret weapon.
--
Gisle S�lensminde, Phd student, Scientific programmer
Computational biology unit, University of Bergen, Norway
Email: ·····@cbu.uib.no | Complicated is easy, simple is hard.
From: Christopher C. Stacy
Subject: Re: why not enough lisp libraries?
Date:
Message-ID: <uhdk1r53k.fsf@news.dtpq.com>
Gisle Sælensminde <·····@kaktus.ii.uib.no> writes:
> On 2005-02-24, Christopher C. Stacy <······@news.dtpq.com> wrote:
> >
> > Since then, Lisp has been in stealth mode. The few companies
> > smart enough to use it don't want to tell. At first, because
> > it was unpopular. Later, because it gave them a secret advantage.
> > Today, enough time and shit has passed that some people are taking
> > another look. (There are no fabulous Lisp Machine operating systems,
> > of course, but there are development environments and libraries.)
>
> This is not the main point, but....
>
> The theory of 'Lisp as a secret weapon', regularly comes up on cll.
> My impression is quite the oposite.
I am reporting on my actual experiences at such companies,
not merely imagining that it might be going on.
For example, the last company that I worked for that did this,
just a couple years ago, offered web-based services.
They went so far as to hack the error handling to make any
potentially escaping error messages appear to be coming from Java.
······@news.dtpq.com (Christopher C. Stacy) writes:
> not merely imagining that it might be going on.
>
> For example, the last company that I worked for that did this,
> just a couple years ago, offered web-based services.
> They went so far as to hack the error handling to make any
> potentially escaping error messages appear to be coming from Java.
Classic! ;-)
--
Dave Roberts
dave -remove- AT findinglisp DoT com
http://www.findinglisp.com/
>>>>> "Dave" == Dave Roberts <···········@remove-findinglisp.com> writes:
Dave> ······@news.dtpq.com (Christopher C. Stacy) writes:
>> not merely imagining that it might be going on.
>>
>> For example, the last company that I worked for that did this,
>> just a couple years ago, offered web-based services. They went
>> so far as to hack the error handling to make any potentially
>> escaping error messages appear to be coming from Java.
Dave> Classic! ;-)
Well, better than emulating ASP on IIS where you not only have to
dress up your errors to be credible but have to actually generate
failures or simulate downtimes a few times a month to appear
plausible.
Holger
On 2005-02-24, Christopher C. Stacy <······@news.dtpq.com> wrote:
> Gisle Sælensminde <·····@kaktus.ii.uib.no> writes:
>
>> The theory of 'Lisp as a secret weapon', regularly comes up on cll.
>> My impression is quite the oposite.
>
> I am reporting on my actual experiences at such companies,
> not merely imagining that it might be going on.
>
> For example, the last company that I worked for that did this,
> just a couple years ago, offered web-based services.
> They went so far as to hack the error handling to make any
> potentially escaping error messages appear to be coming from Java.
Was this because of a fear of scaring away customers or investors, for
not complying to industy standards by using Java or C#, or was it to hide
the fact that you were using Lisp in order to keep a competitive advantage?
The difference is important, since the first case only shows the prejudges
present in the industry, rather than saying anything about Lisp.
PS: After sending my doubts about whether anyone used lisp as a secret wapon.
I got some private emails from people that told me that at least they used lisp
as a compatitive advantage. One of them was claiming that this was the very thing
that kept him in business, so now I have at least some evidence.
--
Gisle S�lensminde, Phd student, Scientific programmer
Computational biology unit, University of Bergen, Norway
Email: ·····@cbu.uib.no | Complicated is easy, simple is hard.
From: Christopher C. Stacy
Subject: Re: why not enough lisp libraries?
Date:
Message-ID: <uhdjxflha.fsf@news.dtpq.com>
Gisle Sælensminde <·····@kaktus.ii.uib.no> writes:
> On 2005-02-24, Christopher C. Stacy <······@news.dtpq.com> wrote:
> > Gisle Sælensminde <·····@kaktus.ii.uib.no> writes:
> >
>
> >> The theory of 'Lisp as a secret weapon', regularly comes up on cll.
> >> My impression is quite the oposite.
> >
> > I am reporting on my actual experiences at such companies,
> > not merely imagining that it might be going on.
> >
> > For example, the last company that I worked for that did this,
> > just a couple years ago, offered web-based services.
> > They went so far as to hack the error handling to make any
> > potentially escaping error messages appear to be coming from Java.
>
> Was this because of a fear of scaring away customers or investors, for
> not complying to industy standards by using Java or C#, or was it to hide
> the fact that you were using Lisp in order to keep a competitive advantage?
> The difference is important, since the first case only shows the prejudges
> present in the industry, rather than saying anything about Lisp.
The product was a service offered over the web by a privately
held company with full funding, and the software was not for sale.
If the company were to be sold or something, I don't think any
future investors would be fooled by this ruse. Due dilligence
would involve their technical experts reviewing the system.
>
> PS: After sending my doubts about whether anyone used lisp as a secret wapon.
> I got some private emails from people that told me that at least they used lisp
> as a compatitive advantage. One of them was claiming that this was the very thing
> that kept him in business, so now I have at least some evidence.
Yes, I'm sure my story is not unique!
According to Christopher C. Stacy <······@news.dtpq.com>:
> Most people prefer to wallow in crap.
> It's comfortable and familiar, and it already smells like they do.
Ooooh.
c.l.l should have more trolls. Everyone is in fine form here and this
ringside view I have is tremendously enjoyable! ;-)
--
Ng Pheng Siong <····@netmemetic.com>
http://sandbox.rulemaker.net/ngps -+- M2Crypto, ZServerSSL for Zope, Blog
http://www.sqlcrypt.com -+- Database Engine with Transparent AES Encryption
David Steuber wrote:
> * Lisp doesn't use as much memory. Java is a huge memory hog.
> Heck, look at newer web browsers written in C/C++ and observe
> just how big a memory foot print they have. On my system,
> Safari is almost always the largest user of system memory.
Same for me and Firefox on Gentoo GNU/Linux. In fact, Firefox crashes
every now and then - when my swap fills, I think. I *do* abuse the
tabbed browsing though. Browsers may not have been designed to be long
running applications.
> --
> An ideal world is left as an excercise to the reader.
> --- Paul Graham, On Lisp 8.1
Does anyone have a solution to this exercise. It's not homework :-).
From: Edi Weitz
Subject: Re: why not enough lisp libraries?
Date:
Message-ID: <uvf8k98up.fsf@agharta.de>
On 22 Feb 2005 02:27:48 -0800, "lisplover" <·········@hotmail.com> wrote:
> If Lisp is so powerful.. <blech>
Cool, we haven't had a troll for weeks. I wonder who is already
lining up to feed him... :)
Cheers,
Edi.
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
Maybe we can think this way? Diamonds are precious, but obviously it is
not used for drinking. Water is cheap, but we need to drink it
everyday. Diamonds obviously lack some significant features to fit for
drinking. This is not to say that diamonds are not good, simply because
they are not fit for this task. Thus Lisp doesn't fit for...
"lisplover" <·········@hotmail.com> schrieb im Newsbeitrag
·····························@c13g2000cwb.googlegroups.com...
> Maybe we can think this way? Diamonds are precious, but obviously it is
> not used for drinking. Water is cheap, but we need to drink it
> everyday. Diamonds obviously lack some significant features to fit for
> drinking. This is not to say that diamonds are not good, simply because
> they are not fit for this task. Thus Lisp doesn't fit for...
>
Is Eliza speaking here (or really some human)?
Edi Weitz wrote:
> On 22 Feb 2005, "lisplover" <·········@hotmail.com> wrote:
> > If Lisp is so powerful.. <blech>
>
> Cool, we haven't had a troll for weeks. I wonder who is already
> lining up to feed him... :)
I suspect there's usually a false premise which trolls craft their
posts around.
In this case, I think the premise is that Lisp "competes with Java". It
does not. They cater to two different markets.
And in fact, "competition" only makes real sense with commercial
products. Just last week, I wrote a little Java program to make running
JSettlers of Catan to work better. And while doing so, I used Lisp to
automate some tedious parts. So in this case, the two "products" were
complementary.
And to the kindly troll: Keep in mind that "Worse is Better" is a
rhetorical piece. While well-written, it's also overly abstract. More
creative than explanatory, framing questions rather than answering
them. You're shortchanging yourself if you limit yourself to it,
because there's a world of interesting discussion out there.
And don't forget... http://planet.lisp.org/
MfG,
Tayssir
Tayssir John Gabbour wrote:
> Edi Weitz wrote:
> > On 22 Feb 2005, "lisplover" <·········@hotmail.com> wrote:
> > > If Lisp is so powerful.. <blech>
> >
> > Cool, we haven't had a troll for weeks. I wonder who is already
> > lining up to feed him... :)
>
> I suspect there's usually a false premise which trolls craft their
> posts around.
>
> In this case, I think the premise is that Lisp "competes with Java".
> It does not. They cater to two different markets.
Incidentally, if I were some corporate PR flack, the thing I'd do most
is try to turn people into rabid, warring consumers; jackasses who
froth at the mouth when a competitor's product is mentioned.
Trolls are useful because they prey on this reaction that's been
instilled in us.
Many of us personally witnessed this from Franz's lecture at last
year's ECOOP. The Franz representative delievered a stormy sermon
explaining that our livelihoods would be destroyed if we didn't adopt
B2B (and Lisp). His technique was good; he surrounded it with Dilbert
slides for an atmosphere of good humor, and heated up in the middle.
This isn't a criticism; it was surreal and disturbing like many
beautiful things are. Above all, it was fun to pass from annoyance to
astonishment at his cojones, to enjoyment and fun. If our good friends
in the Lisp world are like this, imagine what corporations outside it
are like.
MfG,
Tayssir
Edi Weitz wrote:
> On 22 Feb 2005 02:27:48 -0800, "lisplover" <·········@hotmail.com> wrote:
>
>
>>If Lisp is so powerful.. <blech>
>
>
> Cool, we haven't had a troll for weeks. I wonder who is already
> lining up to feed him... :)
Looks like you were first :)
Cheers
--
Marco
On Tue, 22 Feb 2005 11:39:42 +0100, Edi Weitz <········@agharta.de>
wrote:
>On 22 Feb 2005 02:27:48 -0800, "lisplover" <·········@hotmail.com> wrote:
>
>> If Lisp is so powerful.. <blech>
>
>Cool, we haven't had a troll for weeks. I wonder who is already
>lining up to feed him... :)
>
Well... Some time ago I asked about constraint programming library
in Lisp, similar in functionality to Java ILOG JSolver, Koalog or
JCL (Java Constraint Library). Or, say, C++ ILOG Solver, or Prolog
CLP(FD).
I asked also about Lisp interfaces to popular OR solvers,
specifically ILOG CPLEX and Dash XPRESS.
I was sent to obsolete and abandoned academic products and advised
"Do it yourself".
No, thanks, I will not do myself. I am not in the business of "doing
it myself". Instead of Lisp, I am using Prolog that maybe is not
that good and spohisticated as Lisp, but has all the libraries I
need.
I will not even mention the "component market" - components that
support COM interface and can do whatever I want to do. From GUI,
through database access to various computations. There are about 25
thousands of such components on the market. Purchasing components
instead of doing yourself saves tons of monies and a lot of time.
Of course, Lisp is not on this market. Lisp Is Better and doesn't
need components. This market is for "trolls".
Nice playing in your sandbox, guys... Have fun... And keep
pretending that you don't see that the world doesn't care...
A.L, troll
> No, thanks, I will not do myself. I am not in the business of "doing
> it myself". Instead of Lisp, I am using Prolog that maybe is not
> that good and spohisticated as Lisp, but has all the libraries I
> need.
Prolog is easily embeddable into Lisp with just a ~200 LOC macro.
Can you implement Lisp in prolog?
Again - stop thinking about Lisp as of "programming language". It is a
metalanguage which can host ANY other language. You like Prolog?
You can use Prolog within Lisp. You like Java or Smalltalk? No problems
- Lisp
can mimic them. You invented your own new language? You can implement
it in
Lisp in a few hours.
As for me - I really *HATE* Lisp coding. Lispish syntax sucks, this
typeless
semantics sucs. That's why I implement (using only defmacro) compilers
for
any other languages I like (including ML, Prolog, Haskell, Python) in
Lisp
and use them all together.
A.L. wrote:
> No, thanks, I will not do myself. I am not in the business of "doing
> it myself". Instead of Lisp, I am using Prolog that maybe is not
> that good and spohisticated as Lisp, but has all the libraries I
> need.
I don't know what to say; why do you think people should feel bad that
you've found a more appropriate tool for your purposes? You've won!
To put perspective into this issue, I don't define myself by a tool I
use. I use many. I define myself quite a bit with my nationality
though. And I'm bitterly sad that my country has 5% of the world's
population and 25% of its prisoners. A police state. And we pursue
insane foreign adventures and invasions, as we see with Iraq.
And so on that backdrop... we should feel bad that you've looked at
people's suggestions and decided on a frickin' tool?! No, you're a
winner!
You realized that neither Java nor Lisp nor C++ nor PHP was the best
tool for you. Prolog was. One brain point for you!
> Nice playing in your sandbox, guys... Have fun... And keep
> pretending that you don't see that the world doesn't care...
>
> A.L, troll
Well, ah might jest be a dumb Americun... but you seem to be
representing the world, and you seem to care. Every book on negotiation
I've read claims that whomever cares least has power.
Please understand. Lisp is a tool. The only reason that we're having
this discussion is because the programming world is full of lies. From
primadonnas who ruin computing with their pathetic internecine wars.
People who disloyally use the miracle of computing to commoditize
employees in their countries, or to spy on their people.
We are played off each other to the point where we say ridiculous shit
like "Normal screwdrivers can't be used with flat-head screws! You need
a Microsoft screwdriver!"
But that's what we get for being obnoxious nerds. ;P
On 24 Feb 2005 08:44:18 -0800, "Tayssir John Gabbour"
<···········@yahoo.com> wrote:
>A.L. wrote:
>> No, thanks, I will not do myself. I am not in the business of "doing
>> it myself". Instead of Lisp, I am using Prolog that maybe is not
>> that good and spohisticated as Lisp, but has all the libraries I
>> need.
>
>
>Well, ah might jest be a dumb Americun... but you seem to be
>representing the world, and you seem to care. Every book on negotiation
>I've read claims that whomever cares least has power.
>
I am not American...
>Please understand. Lisp is a tool. The only reason that we're having
>this discussion is because the programming world is full of lies. From
>primadonnas who ruin computing with their pathetic internecine wars.
>People who disloyally use the miracle of computing to commoditize
>employees in their countries, or to spy on their people.
>
>We are played off each other to the point where we say ridiculous shit
>like "Normal screwdrivers can't be used with flat-head screws! You need
>a Microsoft screwdriver!"
>
Yes, Lisp is a tool. Pretty good tool. It is as, say, Bosh or Black
and Decker electric drill. With electric drill you can only drill
holes. Fortunately, both Bosh and B&D have discovered long ago that it
is possible to develop "attachments" to drills that can do 1000 and
one other things, making electric drill a really universal tool.
Lisp has many nice features that make it very good language. I would
prefer to do lists in Lisp then in Prolog. But there are no
"attachments" to Lisp, what makes it good only to play in the sandbox.
Language is not that much the issue. In industrial environment,
developer's hour costs 150-200 bucks (including benefits, overhead,
taxes, etc.). If I have to pay 10,000 bucks to buy library from ILOG
or to spend a year developing my own, then the economics tells me what
is the best choice. Not mentioning the fact that ILOG has invested
already 15 man years in his products, and mine would be not as good as
theirs. If working at all...
That the language is "better"? Who cares?
A.L.
A.L. wrote:
> On 24 Feb 2005 08:44:18 -0800, "Tayssir John Gabbour"
> <···········@yahoo.com> wrote:
> >Well, ah might jest be a dumb Americun... but you seem to be
> >representing the world, and you seem to care. Every book on
> >negotiation I've read claims that whomever cares least has
> >power.
>
> I am not American...
Um, I was using an accent to say, "I might just be a dumb American..."
Intentional misspellings for self-deprecating, ironic effect, I guess.
Of course it doesn't translate well...
> By the way, we are getting rid of Smalltalk, too....
There are a number of strategies for subverting politics and getting
things done. Marc Battyani and Peter van Eynde have given talks on this
topic; mod_lisp under Apache in fact is geared towards Marc's tactics.
> a) in organization like where I am working for (about $100 million
> revenue), there are about 30 people who must know the language. This
> is R&D, maintenance, implementation, QA. Switching to "non
mainstream"
> language cost a lot of monies and time, both direct and indirect. The
> decision to go with Prolog was done in desperation and under time
> pressure. We are now in the process of eliminating Prolog, possibly
> completely. As quickly as possible,
Good (but unconventional) tools often conflict with a large
organization's desire to benefit from certain economies of scale. This
is a well-known feature of teams like yours. And I actually find that a
good thing; otherwise who could compete with a large organization?
So, the Yahoos of the world will refuse to buy Google for a couple
million dollars, and rewrite Paul Graham's program into C++.
> In addition, I question the claim about the "increase of productivity
> in Lisp"...
Good. The alternative is being a dishonest ideologue. Unquestioning
ideology is precisely the problem. Disobedience is the antidote.
On Thu, 24 Feb 2005 12:58:55 -0600, A.L. <·············@hot_won_mail.com>
wrote:
>
> Language is not that much the issue. In industrial environment,
> developer's hour costs 150-200 bucks (including benefits, overhead,
> taxes, etc.). If I have to pay 10,000 bucks to buy library from ILOG
> or to spend a year developing my own, then the economics tells me what
> is the best choice. Not mentioning the fact that ILOG has invested
> already 15 man years in his products, and mine would be not as good as
> theirs. If working at all...
>
> That the language is "better"? Who cares?
>
> A.L.
>
The foreign function interface allows you to interface libraries.
Compare the time making a interface to the libraries (a day or two)
to the increase in productivity you get from using lisp.
It is a myth that every lisp programmer spends all his time
reinventing the wheel.
--
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
On Thu, 24 Feb 2005 20:09:50 +0100, "John Thingstad"
<··············@chello.no> wrote:
>On Thu, 24 Feb 2005 12:58:55 -0600, A.L. <·············@hot_won_mail.com>
>wrote:
>
>>
>> Language is not that much the issue. In industrial environment,
>> developer's hour costs 150-200 bucks (including benefits, overhead,
>> taxes, etc.). If I have to pay 10,000 bucks to buy library from ILOG
>> or to spend a year developing my own, then the economics tells me what
>> is the best choice. Not mentioning the fact that ILOG has invested
>> already 15 man years in his products, and mine would be not as good as
>> theirs. If working at all...
>>
>> That the language is "better"? Who cares?
>>
>> A.L.
>>
>
>The foreign function interface allows you to interface libraries.
>Compare the time making a interface to the libraries (a day or two)
>to the increase in productivity you get from using lisp.
I went throuh this exercise. It is a bit (quite a bit...) more than 2
days, in addition would require testing, documenting, etc.
However, there is other aspect of using "not mainstream languages":
a) in organization like where I am working for (about $100 million
revenue), there are about 30 people who must know the language. This
is R&D, maintenance, implementation, QA. Switching to "non mainstream"
language cost a lot of monies and time, both direct and indirect. The
decision to go with Prolog was done in desperation and under time
pressure. We are now in the process of eliminating Prolog, possibly
completely. As quickly as possible,
b) the average mental capabilities of so-called-software-engineer
makes it impossible to use anything more sophisticated than Java,
Visual Basic preferred. Not that long ago I was interviewing a
candidate for C++ job. The guy had excellent references and wanted
salary close to $100K. During the interview he exposed his philosophy:
"C++ is too complicated for single person to master all aspects of the
language, from A to Z. Therefore, the art of building software team is
to find people, each with his own slice of C++ expertise, in such a
way that the composite knnowledge of the team covers complete C++".
Try to use Lisp with such guys,
c) Market perception. Somehow, the information that piece of our
application is written in language XXX that was invented 40 years ago
is being used by our competition as a proof that our products are
"obsolete". We have experienced this, and this is not anecdotal.
Unfortunately, the market perception is important, and potential users
don't investigate the merit of such claims.
By the way, we are getting rid of Smalltalk, too....
In addition, I question the claim about the "increase of productivity
in Lisp"...
A.L.
A.L. <·············@hot_won_mail.com> writes:
> On Thu, 24 Feb 2005 20:09:50 +0100, "John Thingstad"
> <··············@chello.no> wrote:
>
> >The foreign function interface allows you to interface libraries.
> >Compare the time making a interface to the libraries (a day or two)
> >to the increase in productivity you get from using lisp.
>
> I went throuh this exercise. It is a bit (quite a bit...) more than 2
> days, in addition would require testing, documenting, etc.
Don't you realize that all this is as likely (actually given what else
you have written, I'd say rather more likely) to mean you are simply
incompetent?
Why is it that (typically incompetent) people extrapolate from their
own singular experience to claim that what holds for them _must_
(somehow) hold for everyone? I've never really understood this. Nor,
for that matter, why they are so eager to broadcast their incompetence
to the whole world. This isn't just rhetorical - does anyone have any
insight into this? Especially the latter part.
/Jon
--
'j' - a n t h o n y at romeo/charley/november com
jayessay wrote:
>
>
> Why is it that (typically incompetent) people extrapolate from their
> own singular experience to claim that what holds for them _must_
> (somehow) hold for everyone? I've never really understood this. Nor,
> for that matter, why they are so eager to broadcast their incompetence
> to the whole world. This isn't just rhetorical - does anyone have any
> insight into this? Especially the latter part.
As for the former, i suspect that ignorance of ones own failings mixed
with the arrogance that creates leads to an assumption that every body
is at the same skill level. It would be hard for one to accept, after
making a career of it, that one is not very good at their chosen field.
I would think denial plays a large role.
As for the later, either the sub-concious mind cries out for
confirmation of ones suspected ineptitiude, so it's a Freudian type
thing, or its just a case of the Greater Internet Fuckwad theory:
http://www.penny-arcade.com/view.php3?date=2004-03-19
:)
--
Drew Crampsie
drewc at tech dot coop
"Never mind the bollocks -- here's the sexp's tools."
-- Karl A. Krueger on comp.lang.lisp
In article <··············@rigel.goldenthreadtech.com>, jayessay wrote:
> A.L. <·············@hot_won_mail.com> writes:
>> On Thu, 24 Feb 2005 20:09:50 +0100, "John Thingstad"
>> <··············@chello.no> wrote:
>>
>> >The foreign function interface allows you to interface libraries.
>> >Compare the time making a interface to the libraries (a day or two)
>> >to the increase in productivity you get from using lisp.
>>
>> I went throuh this exercise. It is a bit (quite a bit...) more than 2
>> days, in addition would require testing, documenting, etc.
>
> Don't you realize that all this is as likely (actually given what else
> you have written, I'd say rather more likely) to mean you are simply
> incompetent?
>
Well, this may one of the few things in this thread with which I agree
with A.L. (though I think it is a minor detail) -- there is *no* way that
anybody could realistically budget 'a day or two' to write a FFI. Think
of what happens if there is a bug in the FFI and you are dealing with
good developers: the programmer who discovers the bug 1) writes some
code that exposed the bug; 2) spent some time recognising that there
was a bug and then locating it; 3) spent some time isolating the bug; 4)
spent some time reporting the bug; 5) (possibly) spent some time working
with the programmer who wrote the FFI fixing the problem; 6) (possibly)
spent some time idling while waiting for a fix or determining that it
would be a while and so should do something else in the mean time; 7)
(possibly) re-working (or worse re-designing) the original code. Now go
through the same for the programmer who wrote the FFI in the first place
(and be sure to include the cost of that programmer's disruption). And
don't forget about the time costs to the overall schedule. Then lets
say there is a second bug.
Add it up.
If you are dealing with inexperienced or poor developers, the same thing
eventually happens but there's a lot of random time wasting sprinkled
throughout in the most amusing and novel ways possible.
The same thing happens but worse if the FFI wasn't extensive enough in the
first place (because the delays are likely to be longer, and for sure you
are going to have documentation updates).
Furthermore, I've written FFIs (in other languages than CL) in a commercial
environment, unless the library's api is really simple you are going to have
to think about how to represent the library in the target language. In CL
this is less of a problem than in some languages (and I'm thinking of Java
here) because you have the tools to wrap the FFI pretty much anyway you like.
Rich Hickey's Foil and Jfli are very nice examples of this (and there is no
way it took two days for Rich to write either of Foil or Jfli).
This is all *completely* routine in a commercial environment, so don't
misunderstand -- it is likely that FFI is the way to go but the cost isn't
going to be '2 days or so'.
This kind of argument is not a good strategy when trying to convince
anybody in a management role in a commercial software enterprise :-)
The funny thing is that if the programmers don't try this kind of argument
every now and again you can pretty much bet the project is dead and that
nobody cares anymore. A.L., you must surely know this -- so, why don't you
take John's point rather than fixate on the details?
Cheers,
Bob
hutch <·····@hutch.local> writes:
> Well, this may one of the few things in this thread with which I agree
> with A.L. (though I think it is a minor detail) -- there is *no* way that
> anybody could realistically budget 'a day or two' to write a FFI. Think
> of what happens if there is a bug in the FFI and you are dealing with
> good developers: [...]
Replace "FFI" with "compiler", and think about the consequences. Does
this mean that you shouldn't use compilers? Ok, try "interpreter"... now
what do you use? Raw assembly? Ok, try "CPU" or more historically
relevant: "FPU".
Being paralyzed by the possibility of failure is itself failure. Ok,
maybe I shouldn't paraphrase: "The only thing we have to fear is fear
itself." If you are so afraid that you can't hire intelligent
programmers who can 1) write well-documented libraries with a
well-documented goal in order to improve code clarity and programmer
productivity by others of magnitude and 2) read said documentation and
fix bugs in said code, then you shouldn't be in the business of hiring
programmers to tackle difficult problems...
I think MS wants your phone number so they can sell you a copy of
VB.NET. It's great at limiting not only the skill of the programmers
you'll find but also the difficulty of the problems you'll consider
tackling. Sounds like a win-win proposition. :)
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
In article <··············@nyct.net>, Rahul Jain wrote:
> hutch <·····@hutch.local> writes:
>
>> Well, this may one of the few things in this thread with which I agree
>> with A.L. (though I think it is a minor detail) -- there is *no* way that
>> anybody could realistically budget 'a day or two' to write a FFI. Think
>> of what happens if there is a bug in the FFI and you are dealing with
>> good developers: [...]
>
> Replace "FFI" with "compiler", and think about the consequences. Does
> this mean that you shouldn't use compilers? Ok, try "interpreter"... now
> what do you use? Raw assembly? Ok, try "CPU" or more historically
> relevant: "FPU".
>
> Being paralyzed by the possibility of failure is itself failure. Ok,
> maybe I shouldn't paraphrase: "The only thing we have to fear is fear
> itself." If you are so afraid that you can't hire intelligent
> programmers who can 1) write well-documented libraries with a
> well-documented goal in order to improve code clarity and programmer
> productivity by others of magnitude and 2) read said documentation and
> fix bugs in said code, then you shouldn't be in the business of hiring
> programmers to tackle difficult problems...
>
> I think MS wants your phone number so they can sell you a copy of
> VB.NET. It's great at limiting not only the skill of the programmers
> you'll find but also the difficulty of the problems you'll consider
> tackling. Sounds like a win-win proposition. :)
>
What are you talking about? Did you read what I wrote?
A.L. <·············@hot_won_mail.com> writes:
> c) Market perception. Somehow, the information that piece of our
> application is written in language XXX that was invented 40 years
> ago is being used by our competition as a proof that our products
> are "obsolete".
Actually, this is another thing that I find strange. I don't doubt
plenty of brachiating low brows make this sort of argument, but it is
really very strange. Presumably the same people would make an
argument that use of the Calculus in some application would make it
completely obsolete as it was invented over three _centuries_ ago.
And, no, I don't find this a bogus comparison.
/Jon
--
'j' - a n t h o n y at romeo/charley/november com
The problem is you, not Lisp:
A.L. wrote:
>>The foreign function interface allows you to interface libraries.
>>Compare the time making a interface to the libraries (a day or two)
>>to the increase in productivity you get from using lisp.
>
>
> I went throuh this exercise. It is a bit (quite a bit...) more than 2
> days, in addition would require testing, documenting, etc.
No, it is a day or two (after the first library), if you are any good.
Is it possible you did not realize how much of the effort was going into
training you to do FFI? tsk tsk
>
> However, there is other aspect of using "not mainstream languages":
>
> a) in organization like where I am working for (about $100 million
> revenue), there are about 30 people who must know the language. This
> is R&D, maintenance, implementation, QA. Switching to "non mainstream"
> language cost a lot of monies and time,...
Switching languages is easy and rather fun if your people are any good.
I suspect they are not, since VB seems to be their upper bound.
> c) Market perception. Somehow, the information that piece of our
> application is written in language XXX that was invented 40 years ago...
...helped me win a client over. They had had a lot of bad luck with
startups like ours in the same application space and wanted to know why
they should expect us to be any better. In a sidebar as the meeting
broke up the lead guy asked what language we had used. When he heard
Common Lisp, he knew he was talking to a different kind of software
company.
> is being used by our competition as a proof that our products are
> "obsolete". We have experienced this, and this is not anecdotal.
Sounds like you do not know how to present your own case, and that might
be because...
> In addition, I question the claim about the "increase of productivity
> in Lisp"...
...you have not got what it takes to develop software, if you think it
is a claim and not a simple fact.
kt
--
Cells? Cello? Cells-Gtk?: http://www.common-lisp.net/project/cells/
Why Lisp? http://lisp.tech.coop/RtL%20Highlight%20Film
"Doctor, I wrestled with reality for forty years, and I am happy to
state that I finally won out over it." -- Elwood P. Dowd
From: Edi Weitz
Subject: Re: why not enough lisp libraries?
Date:
Message-ID: <umztty7dq.fsf@agharta.de>
On Thu, 24 Feb 2005 14:56:21 -0600, A.L. <·············@hot_won_mail.com> wrote:
> We are now in the process of eliminating Prolog, possibly
> completely. As quickly as possible,
>
> [...]
>
> By the way, we are getting rid of Smalltalk, too....
>
> In addition, I question the claim about the "increase of
> productivity in Lisp"...
Cool. And why are you still hanging around here? You seem to have so
much more important things to do. Do you also post these stories in
comp.lang.smalltalk and comp.lang.prolog so that we're not the only
ones feeling bad?
Edi.
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
On Thu, 24 Feb 2005 22:29:05 +0100, Edi Weitz <········@agharta.de>
wrote:
>On Thu, 24 Feb 2005 14:56:21 -0600, A.L. <·············@hot_won_mail.com> wrote:
>
>> We are now in the process of eliminating Prolog, possibly
>> completely. As quickly as possible,
>>
>> [...]
>>
>> By the way, we are getting rid of Smalltalk, too....
>>
>> In addition, I question the claim about the "increase of
>> productivity in Lisp"...
>
>Cool. And why are you still hanging around here? You seem to have so
>much more important things to do. Do you also post these stories in
>comp.lang.smalltalk and comp.lang.prolog so that we're not the only
>ones feeling bad?
>
Because:
a) USENET is democratic publishing forum. I can write whatever is my
opinion, as long as this what I write is in sync with description of
the group. Nowhere is told that this what I write must be politically
correct, must coincide with the opionon of the majority, and nowhere
is stated that this what I write must pass through Mr. Edi Weitz
censorship,
b) Because I like Lisp. Whether it an be used in production
environment or not. I am just not in love with Lisp and don't have
sexual intercourses with List each evening.
A.L.
>>>>> "EW" == Edi Weitz <········@agharta.de> writes:
EW> On Thu, 24 Feb 2005 14:56:21 -0600,
EW> A.L. <·············@hot_won_mail.com> wrote:
>> We are now in the process of eliminating Prolog, possibly
>> completely. As quickly as possible,
[...]
>> By the way, we are getting rid of Smalltalk, too....
>>
>> In addition, I question the claim about the "increase of
>> productivity in Lisp"...
EW> [...] Do you also post
EW> these stories in comp.lang.smalltalk and comp.lang.prolog so
EW> that we're not the only ones feeling bad?
Oh and don't forget comp.lang.lucky-language-you-will-switch-to where
people will most certainly appreciate the 'you want me to use lisp
when the best people I can get are this dumb?' kind of remarks.
cheers,
BM
> b) the average mental capabilities of so-called-software-engineer
> makes it impossible to use anything more sophisticated than Java,
> Visual Basic preferred. Not that long ago I was interviewing a
> candidate for C++ job. The guy had excellent references and wanted
> salary close to $100K. During the interview he exposed his philosophy:
> "C++ is too complicated for single person to master all aspects of the
> language, from A to Z. Therefore, the art of building software team is
> to find people, each with his own slice of C++ expertise, in such a
> way that the composite knnowledge of the team covers complete C++".
> Try to use Lisp with such guys,
This is a typicle problem and well stated.
As a retired CIO with over 25 years experience, I would further recomend
that shop standards should only permit use of the language subset well
understood by every member of the programming team.
While almost every programmer likes to explore new techniques and exorcize
the limits of his/her knowledge, the last thing any organization needs is
for a program to fail that contains code only understood by a programmer
that is not available.
Mike Sicilian
mike wrote:
>
> While almost every programmer likes to explore new techniques and exorcize
> the limits of his/her knowledge, the last thing any organization needs is
> for a program to fail that contains code only understood by a programmer
> that is not available.
>
That is not a failure of techniques, or programming language, or
from someone testing their knowledge. It is failure to work together
and to communicate and to fail to interact as human beings. The
same thing can happen if a programmer knows what they are doing
and uses known techniques. In that situation a programmer can
provide a great working solution and still no-one else understands.
That is the nature of complexity. The above problem is not
fixed by thinking that programmers that know the same language
can understand each other's code, in general it is not true.
Wade
"Wade Humeniuk" <··················@telus.net> wrote in message
·······················@clgrps12...
> mike wrote:
>
>>
>> While almost every programmer likes to explore new techniques and
>> exorcize the limits of his/her knowledge, the last thing any organization
>> needs is for a program to fail that contains code only understood by a
>> programmer that is not available.
>>
>
> That is not a failure of techniques, or programming language, or
> from someone testing their knowledge. It is failure to work together
> and to communicate and to fail to interact as human beings. The
> same thing can happen if a programmer knows what they are doing
> and uses known techniques. In that situation a programmer can
> provide a great working solution and still no-one else understands.
> That is the nature of complexity. The above problem is not
> fixed by thinking that programmers that know the same language
> can understand each other's code, in general it is not true.
>
> Wade
I did not mean to imply that use of a common language subset was the only
thing required to assure programming team effectiveness, only that it was
one important part.
Probably the most important single prerequisite is that all programmers who
are working in teams must try to write code with the goal of it being
understood by all members of the team - not just the compiler. Many
programmers do not like their code to be reviewed by the team. Some even
think obscurity = depth and they try to show off by using little known,
little understood techniques.
Mike Sicilian
mike wrote:
>
> Probably the most important single prerequisite is that all programmers who
> are working in teams must try to write code with the goal of it being
> understood by all members of the team - not just the compiler. Many
> programmers do not like their code to be reviewed by the team. Some even
> think obscurity = depth and they try to show off by using little known,
> little understood techniques.
>
Well at least the interface should be understood by
other team members. Much can be done to help others to understand the
internals, but it can be a lot of work (meaning money). In the past
I have been involved on development teams that did code reviews and
management was a little divided over it and vacilatted on whether to
support the process. I personally think code reviews are a good
thing, you really get to see how someone is working and
they cease to be a black box. It also makes teams gel better.
I tend to associate obscurity
with insecurity over the quality of their work, or
with just poor quality. Its like people always
stamping DRAFT on their documents and insisting they are
not complete, a little afraid and ashamed of the contents.
Wade
On Thu, 24 Feb 2005 23:30:33 +0000, mike wrote:
> Probably the most important single prerequisite is that all programmers who
> are working in teams must try to write code with the goal of it being
> understood by all members of the team - not just the compiler. Many
> programmers do not like their code to be reviewed by the team. Some even
> think obscurity = depth and they try to show off by using little known,
> little understood techniques.
I *love* having my code reviewed by others, and that seems to confuse some
of the people I work with. Some of them are so precious with their code
that they can't handle the slightest criticism of it, whereas I want
people to try as hard as they can to rip my code to shreds.
On the other hand, one of the biggest criticisms people seem to have of my
code is that I use things other people find hard to understand, e.g.
anonymous inner classes in Java. I do get annoyed by this reluctance to
learn the language properly.
Cheers,
Bill.
Up spake William Bland:
> On the other hand, one of the biggest criticisms people seem to have of my
> code is that I use things other people find hard to understand, e.g.
> anonymous inner classes in Java. I do get annoyed by this reluctance to
> learn the language properly.
Do you still try to educate them? Or have you given up?
--
-trent
You cannot run Windows innocently. Guilt of aiding & abetting, at the
very least, is automatic. Loading up on anti-virus and firewall software,
even decent ones, are merely well-meaning actions to be taken into
consideration by judge and jury when deciding your sentence.
-- David P. Murphy
On Fri, 25 Feb 2005 03:33:28 +0000, Trent Buck wrote:
> Up spake William Bland:
>> On the other hand, one of the biggest criticisms people seem to have of my
>> code is that I use things other people find hard to understand, e.g.
>> anonymous inner classes in Java. I do get annoyed by this reluctance to
>> learn the language properly.
>
> Do you still try to educate them? Or have you given up?
*Sigh*. It varies from day-to-day. I *never* try to educate people on a
Monday, for example ;-)
Cheers,
Bill.
On Thu, 24 Feb 2005 23:30:33 GMT, "mike" <····@mike.net> wrote:
>
>
>I did not mean to imply that use of a common language subset was the only
>thing required to assure programming team effectiveness, only that it was
>one important part.
>
Joking?...
>Probably the most important single prerequisite is that all programmers who
>are working in teams must try to write code with the goal of it being
>understood by all members of the team - not just the compiler. Many
>programmers do not like their code to be reviewed by the team. Some even
>think obscurity = depth and they try to show off by using little known,
>little understood techniques.
>
Agree, and this is the reason why many companeis have mandatory
"code reviews"
A.L.
On Thu, 24 Feb 2005 22:31:16 GMT, "mike" <····@mike.net> wrote:
>
>> b) the average mental capabilities of so-called-software-engineer
>> makes it impossible to use anything more sophisticated than Java,
>> Visual Basic preferred. Not that long ago I was interviewing a
>> candidate for C++ job. The guy had excellent references and wanted
>> salary close to $100K. During the interview he exposed his philosophy:
>> "C++ is too complicated for single person to master all aspects of the
>> language, from A to Z. Therefore, the art of building software team is
>> to find people, each with his own slice of C++ expertise, in such a
>> way that the composite knnowledge of the team covers complete C++".
>> Try to use Lisp with such guys,
>
>
>
>This is a typicle problem and well stated.
>
>As a retired CIO with over 25 years experience, I would further recomend
>that shop standards should only permit use of the language subset well
>understood by every member of the programming team.
>
Joking?... This is plain nonsense.... We will not use exceptions in
C++ only because programmers don't know what is exception?... The
solution is to fire them all on the spot and hire ones who know what
is exception.
>While almost every programmer likes to explore new techniques and exorcize
>the limits of his/her knowledge, the last thing any organization needs is
>for a program to fail that contains code only understood by a programmer
>that is not available.
This I support. Programmer should be not a necessary attchment to
his code. Code should be easy to reverse engineer by other team
members.
By the way, try this with Lisp...
A.L.
On Fri, 25 Feb 2005 07:12:09 -0600, A.L.
<·················@oddpost_tego_tez_nie.com> wrote:
>
> Joking?... This is plain nonsense.... We will not use exceptions in
> C++ only because programmers don't know what is exception?... The
> solution is to fire them all on the spot and hire ones who know what
> is exception.
>
You are forgetting about the capabilities of the compiler.
If you want to write portable C++ you will save yourself a world of
grief by avoiding templates, namespaces and exceptions.
--
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
On Fri, 25 Feb 2005 14:42:35 +0100, "John Thingstad"
<··············@chello.no> wrote:
>On Fri, 25 Feb 2005 07:12:09 -0600, A.L.
><·················@oddpost_tego_tez_nie.com> wrote:
>
>>
>> Joking?... This is plain nonsense.... We will not use exceptions in
>> C++ only because programmers don't know what is exception?... The
>> solution is to fire them all on the spot and hire ones who know what
>> is exception.
>>
>
>You are forgetting about the capabilities of the compiler.
>If you want to write portable C++ you will save yourself a world of
>grief by avoiding templates, namespaces and exceptions.
Fine. But I DON'T want to write portable code. Moreover, code across
compilers is more and more portable (with notable exception of gcc).
I am afraid that we are talking from different perspectives. The
majority on this group are from the academia or are "garage
programmers". I can assure that commercial development has a bit
different gosals and objectives than academic environment. I know
thsi pretty well, I spent 20+ years as university professor...
A.L.
A.L. <·················@oddpost_tego_tez_nie.com> writes:
> I am afraid that we are talking from different perspectives. The
> majority on this group are from the academia or are "garage
> programmers". I can assure that commercial development has a bit
Any evidence? How long are you subscribing to comp.lang.lisp?
Paolo
--
Lisp Propulsion Laboratory log - http://www.paoloamoroso.it/log
Recommended Common Lisp libraries/tools (see also http://clrfi.alu.org):
- ASDF/ASDF-INSTALL: system building/installation
- CL-PPCRE: regular expressions
- UFFI: Foreign Function Interface
"John Thingstad" <··············@chello.no> writes:
> You are forgetting about the capabilities of the compiler. If you
> want to write portable C++ you will save yourself a world of grief
> by avoiding templates, namespaces and exceptions.
To which I say, it's been 7 years since ISO/IEC 14882:1998. Get some
new compilers, or move on to a different language.
--
Steven E. Harris
"Michael N Kaplan" <················@gmail.com> writes:
> If only it were that easy. There are some people (companies, gov't,
> military, etc) that can't as easily "upgrade" to a new compiler /
> language. Yes, for new software fine. But there remains a lot of
> legacy code that can't be thrown away as the places it's being used
> would be very...put out. And since the legacy code must be supported,
> a fine set of hacks and dirty code must be written. "Native compiler
> on hp-ux 10.20 doesn't support booleans? Alright, guess we can't use
> booleans yet" etc etc. Now, this may be a somewhat unique situation
> in that the majority of people can upgrade a bit easier, but not
> everyone has that option.
>
> I'd love to move on, use booleans, stop having to worry about whether
> or not all my compilers support namespaces. (Visual Studios 7 requires
> them, no backwards compatibility with #include <iostream.h> etc, other
> compilers we target don't have them) But some places in the real world
> can't do that.
Of course. The only wall I see in front of these organizations is
that nowaday hardware has a planed obsolescence (as in:
biodegradability -- really, literally, the hardware fells appart, not
counting marketing obsolescence) so short, that most software project
will see at least a couple of hardware generations before completion.
It's all right to keep the same software tool suite 20 years when
you're building ferrite core based computers for a shuttle, that can
run 100 years, but IMO it's harder to do when the target is OTS "PC"
hardware.
If I started a software project on the Duron I bought three years ago,
can Duron processors still be bought for all the gold of the world
nowadays? (The minimum I can find on my on-line shop is Athlon XP).
--
__Pascal Bourguignon__ http://www.informatimago.com/
You're always typing.
Well, let's see you ignore my
sitting on your hands.
A.L. wrote:
>
> b) the average mental capabilities of so-called-software-engineer
> makes it impossible to use anything more sophisticated than Java,
> Visual Basic preferred. Not that long ago I was interviewing a
> candidate for C++ job. The guy had excellent references and wanted
> salary close to $100K. During the interview he exposed his philosophy:
> "C++ is too complicated for single person to master all aspects of the
> language, from A to Z. Therefore, the art of building software team is
> to find people, each with his own slice of C++ expertise, in such a
> way that the composite knnowledge of the team covers complete C++".
> Try to use Lisp with such guys,
>
To be fair, this might be a miscommunication with that programmer.
Did he mean expertise with C++ the programming language, or
C++ the programming language + utility templates +
application specific object frameworks + IDEs +
debugging tools + C++ OS interfaces + ...
If it was the latter then I can see his point, a C++ GUI
will need someone with expertise in that (also human
interface design) and maybe an expert in Object Relational DB
and Knowledge Representation (another C++ framework)
and so on and so on...
Wacde
"A.L." <·············@hot_won_mail.com> wrote
> a) in organization like where I am working for (about $100 million
> revenue), there are about 30 people who must know the language. This
> is R&D, maintenance, implementation, QA. Switching to "non mainstream"
> language cost a lot of monies and time, both direct and indirect. The
> decision to go with Prolog was done in desperation and under time
> pressure. We are now in the process of eliminating Prolog, possibly
> completely. As quickly as possible,
I don't have too much problems to sell Lisp based products to billions $
organisations.
> b) the average mental capabilities of so-called-software-engineer
> makes it impossible to use anything more sophisticated than Java,
> Visual Basic preferred.
Lisp is not for average mental capabilities...
> Not that long ago I was interviewing a
> candidate for C++ job. The guy had excellent references and wanted
> salary close to $100K. During the interview he exposed his philosophy:
> "C++ is too complicated for single person to master all aspects of the
> language, from A to Z. Therefore, the art of building software team is
> to find people, each with his own slice of C++ expertise, in such a
> way that the composite knnowledge of the team covers complete C++".
> Try to use Lisp with such guys,
Fire them all!
> c) Market perception. Somehow, the information that piece of our
> application is written in language XXX that was invented 40 years ago
> is being used by our competition as a proof that our products are
> "obsolete". We have experienced this, and this is not anecdotal.
> Unfortunately, the market perception is important, and potential users
> don't investigate the merit of such claims.
> By the way, we are getting rid of Smalltalk, too....
No problem, just inform comp.lang.smaltalk.
> In addition, I question the claim about the "increase of productivity
> in Lisp"...
Yes, for your buddies, the ones with average mental capabilities, there is
none. The only way to deal with such a team is to use them only to glue
pre-written libraries. Java/C#/VB are precisely made for that.
Now, I agree with Edi, I don't understand why you are hanging here as you
says yourself that don't have the political/marketing/economic/intellectual
human resources to use Lisp.
Jealousy maybe eh ? ;-)
And just for your info about CPLEX form ILOG:
"CPLEX Callable Library provides a C programming language interface,
allowing all features to be accessed from multiple programming languages."
Marc
> b) the average mental capabilities of so-called-software-engineer
> makes it impossible to use anything more sophisticated than Java,
> Visual Basic preferred. Not that long ago I was interviewing a
> candidate for C++ job. The guy had excellent references and wanted
> salary close to $100K. During the interview he exposed his
philosophy:
> "C++ is too complicated for single person to master all aspects of
the
> language, from A to Z. Therefore, the art of building software team
is
> to find people, each with his own slice of C++ expertise, in such a
> way that the composite knnowledge of the team covers complete C++".
And he is right. You can't master all aspects of this huge, bloated
language.
And, C++ is also a Meta-Language. Not as powerfull as Lisp, but it
can't
be treated as just a single programming language like Java.
> Try to use Lisp with such guys,
Lisp is a best choice in this situation. You have one, two or more
Lisp gurus, who can implement languages on top of Lisp, and you have
hordes
of cheaper staff, who knows only "slices" of, for example, Basic,
Prolog,
whatever - you can invent your own languages which best suites the
needs
of this hordes - it's very cheap to invent a languages.
This approach is briefly described here:
http://arxiv.org/abs/cs.PL/0409016
> c) Market perception. Somehow, the information that piece of our
> application is written in language XXX that was invented 40 years ago
> is being used by our competition as a proof that our products are
> "obsolete". We have experienced this, and this is not anecdotal.
> Unfortunately, the market perception is important, and potential
users
> don't investigate the merit of such claims.
Now consider, how the market will responce to the information that
the software is written using the punks toy language Basic. ;)
A.L. <·············@hot_won_mail.com> writes:
> In addition, I question the claim about the "increase of productivity
> in Lisp"...
Any evidence?
Paolo
--
Lisp Propulsion Laboratory log - http://www.paoloamoroso.it/log
Recommended Common Lisp libraries/tools (see also http://clrfi.alu.org):
- ASDF/ASDF-INSTALL: system building/installation
- CL-PPCRE: regular expressions
- UFFI: Foreign Function Interface
On Fri, 25 Feb 2005 17:36:46 +0100, Paolo Amoroso <·······@mclink.it>
wrote:
>A.L. <·············@hot_won_mail.com> writes:
>
>> In addition, I question the claim about the "increase of productivity
>> in Lisp"...
>
>Any evidence?
After you.
A.L.
A.L. <·············@hot_won_mail.com> writes:
> On Fri, 25 Feb 2005 17:36:46 +0100, Paolo Amoroso <·······@mclink.it>
> wrote:
>
>>A.L. <·············@hot_won_mail.com> writes:
>>
>>> In addition, I question the claim about the "increase of productivity
>>> in Lisp"...
>>
>>Any evidence?
>
> After you.
I am not a native English speaker, so I'm not sure I fully understand
your statement. Does it mean something like "I'll tell about my
evidence after you have told about yours"? If so, I have no evidence
either that Lisp increases productivity, or that it doesn't. That's
why I ask whether you do have any such evidence.
Paolo
--
Lisp Propulsion Laboratory log - http://www.paoloamoroso.it/log
Recommended Common Lisp libraries/tools (see also http://clrfi.alu.org):
- ASDF/ASDF-INSTALL: system building/installation
- CL-PPCRE: regular expressions
- UFFI: Foreign Function Interface
Paolo Amoroso <·······@mclink.it> writes:
> A.L. <·············@hot_won_mail.com> writes:
> > On Fri, 25 Feb 2005 17:36:46 +0100, Paolo Amoroso <·······@mclink.it>
> > wrote:
> >>A.L. <·············@hot_won_mail.com> writes:
> >>> In addition, I question the claim about the "increase of productivity
> >>> in Lisp"...
> >>Any evidence?
> > After you.
>
> I am not a native English speaker, so I'm not sure I fully understand
> your statement. Does it mean something like "I'll tell about my
> evidence after you have told about yours"? If so, I have no evidence
> either that Lisp increases productivity, or that it doesn't. That's
> why I ask whether you do have any such evidence.
It's more a question about how discourse works: Somebody claims "Santa
Clause does exist!". AL says: "I question your claim." Now it's
"somebody"'s job to bring up evidence for his claim. It's not AL's
job to disprove any claim "somebody" happens to bring up.
Personally speaking, I dislike it if people make claims "programming
language/ editor/ library/ development method ('methodology' if you
want to sound educated) such-and-such is X-times more productive than
alternatives" without providing any evidence. And no, personal
anecdotes do not count as evidence. Studies and experiments, properly
analyzed by statisticians, do.
As long as such evidence is not available (and it's hard to produce)
it would be much more convincing for language advocates to just write
great software that people like to use. There's no better advocacy
than a cool project people like to join in.
Matthias <··@spam.pls> writes:
> Personally speaking, I dislike it if people make claims "programming
> language/ editor/ library/ development method ('methodology' if you
> want to sound educated) such-and-such is X-times more productive
> than alternatives" without providing any evidence. And no, personal
> anecdotes do not count as evidence. Studies and experiments,
> properly analyzed by statisticians, do.
Unfortunately, anectdotal evidence is not only basically all you have,
it is (for _serious_ economic reasons) almost certainly all you will
ever have in this area. There are indeed "studies" out there that do
show much higher productivity and so forth, but they are at best
"toys"; again due to the economics of it. Toy studies, aren't going
to cut it either, even if rigorously done. The reason should be
obvious.
This isn't a great situation, but the spin you're putting on it is not
much different from someone claiming "all Turing complete languages
are basically the same". After all, where's the evidence (of the sort
you describe) that they aren't?
/Jon
--
'j' - a n t h o n y at romeo/charley/november com
Matthias <··@spam.pls> writes:
> Personally speaking, I dislike it if people make claims "programming
> language/ editor/ library/ development method ('methodology' if you
> want to sound educated) such-and-such is X-times more productive
> than alternatives" without providing any evidence. And no, personal
> anecdotes do not count as evidence.
Hmmm. Why not? Given the difficulties of setting up an experiment that
controls for the many variables that go into software productivity in
order to isolate the effect of programming language, it seems a bit
rash to reject out of hand the judgement of skilled practitioners of
an art/craft/whatever about which tools make them more productive.
If someone is expert in two programming languages, A and B, and tells
me that they find language A allows them to get more done with fewer
errors than language B that's, to me, an interesting data point. It
may not predict that I'll necessarily be more productive in A than B
but it at least makes me want to know why it's true for that
programmer. Is it something about the way they approach programming?
Is it specific to the particular kind of software they are writing? Or
maybe they've even misjudged the productivity gain--I'd like to know
by what measures they are more productive and know more about their
specific situation to make sure there isn't an easier explanation. For
instance if they wrote a program once in B and then again in A and the
second time went faster, I'd be more likely to attribute that to the
benefit of experience. But if they tried again to write it in B and it
still took longer than writing it in A, I'd start to think the
difference between A and B might have something to do with it.
> Studies and experiments, properly analyzed by statisticians, do.
>
> As long as such evidence is not available (and it's hard to produce)
> it would be much more convincing for language advocates to just write
> great software that people like to use. There's no better advocacy
> than a cool project people like to join in.
Sure.
-Peter
--
Peter Seibel ·····@gigamonkeys.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
Peter Seibel wrote:
>
> Hmmm. Why not? Given the difficulties of setting up an experiment that
> controls for the many variables that go into software productivity in
> order to isolate the effect of programming language, it seems a bit
> rash to reject out of hand the judgement of skilled practitioners of
> an art/craft/whatever about which tools make them more productive.
>
There are scientific ways of judging software productivity. You
do not need to experiment, but use epidemiology studies like
the CDC does to track down the causes of diseases. There have
been studies like that, the COCOMO model is the result of
one such statistical study of software development. Of course
the larger the project the more predictable it becomes, smaller
projects are more unpredictable. In companies where I worked
and they used COCOMO to estimate project duration they have been
very close (+/- 10%). As a side note: It is a little dismaying
that software productivity is subject to some kind of
formula.
Programmer productivity is only one factor in a project, there is
customer relations, documentation, training, testing, installation.
Sometimes programmer produtivity gets lost in the effort expended in
these other areas.
Wade
On Sun, 27 Feb 2005 16:09:43 GMT, Wade Humeniuk
<··················@telus.net> wrote:
>Peter Seibel wrote:
>
>>
>> Hmmm. Why not? Given the difficulties of setting up an experiment that
>> controls for the many variables that go into software productivity in
>> order to isolate the effect of programming language, it seems a bit
>> rash to reject out of hand the judgement of skilled practitioners of
>> an art/craft/whatever about which tools make them more productive.
>>
>
>There are scientific ways of judging software productivity. You
>do not need to experiment, but use epidemiology studies like
>the CDC does to track down the causes of diseases. There have
>been studies like that, the COCOMO model is the result of
>one such statistical study of software development. Of course
>the larger the project the more predictable it becomes, smaller
>projects are more unpredictable. In companies where I worked
>and they used COCOMO to estimate project duration they have been
>very close (+/- 10%). As a side note: It is a little dismaying
>that software productivity is subject to some kind of
>formula.
>
>Programmer productivity is only one factor in a project, there is
>customer relations, documentation, training, testing, installation.
>Sometimes programmer produtivity gets lost in the effort expended in
>these other areas.
It is not "lost". However, it is snal lfraction of ovarall
productivity. Documenting, QA, packaging and implementation takes
about 75% - 85% of the project time/resources. Most savings comes
from optimizing these parts of process. I don't see how Lisp
contribute to this.
A.L.
P.S. By the way, where I can find 50 Lisp programmers?... Today or
tomorrow?... Don't say that I can "retrain" ptrogrammers that we
alerady have. I cannot. Somoebody has to take care about the
products that we currently have. How long it would take and how much
it would cost to rewrite about 3 million lines of
C/C++/Java/Smalltalk into "better" Lisp? Is there any experience
with developing in Lisp systems with few millions lines of code and
deploying these systems? What are the costs and risks? How much it
would cost (in plain $$$ or whatever) to switch to "better"
language? How long the only vendor of commerical Lisp tools will
stay on the market? And what happens if he pulls the plug (don't
send me to Open Source).
A.L. <·················@oddpost_tego_tez_nie.com> writes:
> How long it would take and how much
> it would cost to rewrite about 3 million lines of
> C/C++/Java/Smalltalk into "better" Lisp?
I don't know why you would do this. If the system is already working
and written, then leave it as it is. I would seek to use Lisp on any
new projects that come down the line, and only then in the
circumstance that it can be done relatively independently (a specific
module or program with a well defined interface to the rest of
whatever code you have). If you have a new project come along that is
a new library for an existing working program written in C or Java,
ten you'll probably write the new bits in C or Java. There is no shame
in that, IMO.
There is shame in not considering new tools when you have the chance
to do so, however. That said, each decision to use or not use a new
tool will depend on a variety of factors, the productivity of a
Lisp-based solution being only one of them. For instance, if your
programmers are happy using C and Java and are resistant to learning
Lisp, you only have one of two possible resources: use C and Java, or
fire them and hire some people that are into Lisp and love it for what
it is. If you force Lisp on everybody, even if it's a great solution,
you'll still fail. Lisp can't make up for cranky programmers who are
sabotaging the outcome of a project because they disagree with the
foundations. I have figured this out the hard way.
> Is there any experience
> with developing in Lisp systems with few millions lines of code and
> deploying these systems?
This probably isn't quite what you're looking for, but there are tools
that people use every day that are built from Lisp: Emacs and Autocad
come to mind. These are large systems with boatloads of Lisp. I don't
know exactly how many lines of code, but very large, definitely.
> What are the costs and risks? How much it
> would cost (in plain $$$ or whatever) to switch to "better"
> language? How long the only vendor of commerical Lisp tools will
> stay on the market? And what happens if he pulls the plug (don't
> send me to Open Source).
You can obviously minimize the costs and risks by finding programmers
who are energized to go for it and picking a smaller independent
project up front on which to gain some experience. If you "go for
broke" right out of the chute, trying to convert all code and all
programmers to Lisp, you will surely fail. BTW, you would surely fail
with *any* programming language, methodology, etc. The way to
introduce any new technology into any business is to start small,
demonstrate success, and then grow things from there. As people see
teams succeeding and you start to get *personal* testimonials about
how productive and effective things are, you will attract additional
members of your team. Everybody believes the guy in the next cube more
than a random nut-case they read on Usenet or the 27 scientific papers
"proving" it, and everybody wants to be part of a winning
team. Demonstrate success and things will blossom from there. Again,
this is not a Lisp-specific piece of advice. It's the way to introduce
almost anything new to an existing team.
There are several vendors of Lisp tools and Lisp is a 45-year-old
language. I don't think you really have to worry about it going
away. Seriously, if anything has staying power, Lisp does. And, I
would even go the other way and suggest that Lisp's current vector is
up, not down. That probably wasn't the case five years ago, but my
anecdotal read of momentum is the other way.
--
Dave Roberts
dave -remove- AT findinglisp DoT com
http://www.findinglisp.com/
Dave Roberts <···········@remove-findinglisp.com> writes:
> The way to introduce any new technology into any business is to start
> small, demonstrate success, and then grow things from there. As people
> see teams succeeding and you start to get *personal* testimonials
> about how productive and effective things are, you will attract
> additional members of your team.
Not only that, you'll develop an understanding of what exactly the
strengths and weaknesses of that technology are (or at least as
practiced by your employees). This will help make better judgements as
to the use of that technology in larger projects, where there's more at
risk. Also, when you do use it in larger projects, you'll have better
experience in the technology and will be less likely to get overburdened
by having to learn a technology as well as the requirements for a new
product or even business line at the same time.
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
Are these questions from a serious businessperson? Or rather a debater
-- "drive-by questions" asked by someone who doesn't care about the
answer?
Your questions have answers. Whether you care or not depends on who you
are.
A. L. wrote:
> Documenting, QA, packaging and implementation takes
> about 75% - 85% of the project time/resources. Most savings comes
> from optimizing these parts of process. I don't see how Lisp
> contribute to this.
Because you never asked! ;)
Let's take the first thing you mentioned, documentation. Ever noticed
that you can easily use Lisp code as data? The creator of cl-pdf
clearly did, because he generates thousands of pages of documentation
automatically, even with graphs of OOP structures.
But I suspect the debating counterattack: "Oh, I meant ANOTHER kind of
documentation!" And we debate forever.
And we're ignoring the fact that you don't care about optimizing 15-25%
of it, by your own admission. If you don't care about the question, you
won't care about the answer.
> P.S. By the way, where I can find 50 Lisp programmers?... Today or
> tomorrow?... Don't say that I can "retrain" ptrogrammers that we
> alerady have. I cannot. Somoebody has to take care about the
> products that we currently have. How long it would take and how much
> it would cost to rewrite about 3 million lines of
> C/C++/Java/Smalltalk into "better" Lisp?
How much are you willing to pay? I mean really; you don't get high
value for a Java programmer from DeVry.
Another "drive-by question." If you want it answered, you'd will to
Lisp meetings and make a big post on various mailing lists. See for
yourself.
A large CAD company hired two Common Lisp programmers recently, by
having a guy drive for hours to a Lisp meeting, and other things I
don't know about. You won't do this, so your company won't get the
benefits. Easy as that.
(I hear the counterattack...)
There may be ego in this question. I hear, "Oh, I'd love to give Lisp a
chance... but I'm not sure you meet my harsh standards!"
An equally sarcastic response would be: "Oh, I guess your company's not
resourceful enough to devise and judge unconventional plans... but
there are very few business capable of true greatness!"
Excuses are easiest.
> How long the only vendor of commerical Lisp tools will
> stay on the market? And what happens if he pulls the plug (don't
> send me to Open Source).
Where was this researched? There are at least four commercial Lisp
implementors, charging from $200-20,000/seat. Some of them have
survived and grown. But uncaring research says there's only one.
And there's a good reason for bad research -- big corporations wait and
see what faster, smaller companies do. Then like monkeys, they imitate.
And they never get the imitation perfect anyway.
You have already explained your competitors won't let you use Lisp.
They have more control than you, over your own company. So I ask: Are
these false questions? Even if you wanted the answer, you couldn't do
anything with it. And we can't explore this in any depth or detail,
because I don't know if you have motivation to bring this conversation
somewhere constructive.
MfG,
Tayssir
Tayssir John Gabbour wrote:
> Are these questions from a serious businessperson? Or rather a
debater
> -- "drive-by questions" asked by someone who doesn't care about the
> answer?
Hmm, my own post sounds unpleasantly defensive and pessimistic. Time
for me to lose myself in coding or something; I've just come off a
contract, and I need to clear my head. Been acting weird recently.
MfG,
Tayssir
On 27 Feb 2005 11:58:45 -0800, "Tayssir John Gabbour"
<···········@yahoo.com> wrote:
>Are these questions from a serious businessperson? Or rather a debater
>-- "drive-by questions" asked by someone who doesn't care about the
>answer?
>
Rhetorical.
>Your questions have answers. Whether you care or not depends on who you
>are.
>
Maybe we know different kinds of industry. According to my
experience, Lisp has great future in industry. Unfortunately, this
future is past.
What concludes my contribution to this thread.
A.L.
A.L. wrote:
>
> Maybe we know different kinds of industry. According to my
> experience, Lisp has great future in industry. Unfortunately, this
> future is past.
>
> What concludes my contribution to this thread.
>
--- The following to read with your best robotic voice ---
I am programmer ....
Programming should not be fun ....
My happiness is not important, only productivity is measure ...
--
Reminds me of the song "White Collar Holler" by Stan Rogers (written by
Nigel Russell)
http://stevebriggs.superb.net/stanrogers/songs/wch-sng.html
Wade
A.L. wrote:
>
>
> It is not "lost". However, it is snal lfraction of ovarall
> productivity. Documenting, QA, packaging and implementation takes
> about 75% - 85% of the project time/resources. Most savings comes
> from optimizing these parts of process. I don't see how Lisp
> contribute to this.
>
Programmers don't just program. They need to interact
with customers, technical writers, testers. This takes time. If
they are more productive in Lisp that leaves them more time to perform
their non-programming tasks. If a programmer is spending 16 hours a day
in crunch mode (going on for months and months) they have no
time to do these other things and the whole project can suffer. (and
I have certainly experienced that). Also with greater productivity in
Lisp, the programming team can be smaller, which can have great
benefits (not just monetary). Smaller teams have a greater potential
to be cohesive teams.
I still think that 50% of large projects fail. The reasons for
this are still not obvious. I think one of the things that
would help is if "everyone" on the project becomes a "programmer"
in some way. I do not mean everyone programs, but that everyone
uses more formal expressions of what they want, mean and say.
Using the Lisp mind-set of greater expressibility may
provide a way for people to do that. In essence we need
people to adopt a more formal/rigorous mindset instead
of thinking computers should be adapted to understand
human ambiguity. (I know this sounds pretty abstract)
Also there is too much burden on programmers to translate
this human ambiguity into concrete programs (programmers
tend to not be domain experts, but programming experts.
two different things).
Wade
> A.L.
>
> P.S. By the way, where I can find 50 Lisp programmers?... Today or
> tomorrow?... Don't say that I can "retrain" ptrogrammers that we
> alerady have. I cannot. Somoebody has to take care about the
> products that we currently have. How long it would take and how much
> it would cost to rewrite about 3 million lines of
> C/C++/Java/Smalltalk into "better" Lisp? Is there any experience
> with developing in Lisp systems with few millions lines of code and
> deploying these systems? What are the costs and risks? How much it
> would cost (in plain $$$ or whatever) to switch to "better"
> language? How long the only vendor of commerical Lisp tools will
> stay on the market? And what happens if he pulls the plug (don't
> send me to Open Source).
>
Wade Humeniuk <··················@telus.net> writes:
> Using the Lisp mind-set of greater expressibility may
> provide a way for people to do that. In essence we need
> people to adopt a more formal/rigorous mindset instead
> of thinking computers should be adapted to understand
> human ambiguity. (I know this sounds pretty abstract)
> Also there is too much burden on programmers to translate
> this human ambiguity into concrete programs (programmers
> tend to not be domain experts, but programming experts.
> two different things).
AMEN!
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
A.L. <·················@oddpost_tego_tez_nie.com> writes:
> P.S. By the way, where I can find 50 Lisp programmers?... Today or
> tomorrow?...
If you don't insist on physical presence (do you want programmers or
do you want bodies?), then you can already count 1 for me.
With a job offer on c.l.l you should be able to find a good proportion
of the needed Lisp programmers.
> Don't say that I can "retrain" ptrogrammers that we
> alerady have. I cannot. Somoebody has to take care about the
> products that we currently have. How long it would take and how much
> it would cost to rewrite about 3 million lines of
> C/C++/Java/Smalltalk into "better" Lisp? Is there any experience
> with developing in Lisp systems with few millions lines of code and
> deploying these systems? What are the costs and risks? How much it
> would cost (in plain $$$ or whatever) to switch to "better"
> language? How long the only vendor of commerical Lisp tools will
> stay on the market?
I've not followed very closely commercial vendors of lisp tools, but
it seems to me there's at least three or four of them, not only one.
> And what happens if he pulls the plug (don't
> send me to Open Source).
In ANY case, commercial vendors eventually pull the plug. Even IBM
pulled the plug several times. If that's a big problem for you, the
only thing you can do is to use only freedom software.
--
__Pascal Bourguignon__ http://www.informatimago.com/
In a World without Walls and Fences,
who needs Windows and Gates?
Pascal Bourguignon <····@mouse-potato.com> writes:
> A.L. <·················@oddpost_tego_tez_nie.com> writes:
> > P.S. By the way, where I can find 50 Lisp programmers?... Today or
> > tomorrow?...
>
> If you don't insist on physical presence (do you want programmers or
> do you want bodies?), then you can already count 1 for me.
Depending on the details, I might be interested as well.
> > And what happens if he pulls the plug (don't
> > send me to Open Source).
>
> In ANY case, commercial vendors eventually pull the plug. Even IBM
> pulled the plug several times. If that's a big problem for you, the
> only thing you can do is to use only freedom software.
The last part is not true. The most typical way to handle this issue
is to contract for the vendor code to be in escrow for you.
/Jon
--
'j' - a n t h o n y at romeo/charley/november com
A.L. <·················@oddpost_tego_tez_nie.com> writes:
> C/C++/Java/Smalltalk into "better" Lisp? Is there any experience
> with developing in Lisp systems with few millions lines of code and
> deploying these systems? What are the costs and risks? How much it
Section 1 "Background" on page 1 of this paper:
New Architectural Models for Visibly Controllable Computing: The
Relevance of Dynamic Object Oriented Architectures and Plan Based
Computing Models
ftp://publications.ai.mit.edu/ai-publications/2004/AIM-2004-005.pdf
mentions an approximately 1 MLOC system, the Symbolics Genera
operating system, which is possibly among the largest ever written in
Lisp. The paper compares its size with that of contemporary operating
systems, and explains why such a comparison may make sense.
> language? How long the only vendor of commerical Lisp tools will
> stay on the market? And what happens if he pulls the plug (don't
My crystal ball is a bit foggy :)
The time at which only one Lisp vendor will stay on market does not
seem so close. Here is a list of current commercial and non
commercial vendors of Common Lisp implementations (a couple of entries
should probably be removed):
Common Lisp Implementations
http://lisp.tech.coop/implementation
Paolo
--
Lisp Propulsion Laboratory log - http://www.paoloamoroso.it/log
Recommended Common Lisp libraries/tools (see also http://clrfi.alu.org):
- ASDF/ASDF-INSTALL: system building/installation
- CL-PPCRE: regular expressions
- UFFI: Foreign Function Interface
A.L. <·················@oddpost_tego_tez_nie.com> writes:
> And what happens if he pulls the plug (don't send me to Open Source).
Eh? What do you mean "don't"? This kind of fear is exactly why RMS
started the FSF in the first place. There are other solutions, but
you're rather naive if you think that any single vendor is a reliable
source of support for any single (version of a) product.
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
"A.L." schrieb:
> P.S. By the way, where I can find 50 Lisp programmers?... Today or
> tomorrow?... Don't say that I can "retrain" ptrogrammers that we
> alerady have. I cannot. Somoebody has to take care about the
> products that we currently have. How long it would take and how much
> it would cost to rewrite about 3 million lines of
> C/C++/Java/Smalltalk into "better" Lisp? Is there any experience
> with developing in Lisp systems with few millions lines of code and
> deploying these systems? What are the costs and risks? How much it
> would cost (in plain $$$ or whatever) to switch to "better"
> language? How long the only vendor of commerical Lisp tools will
> stay on the market? And what happens if he pulls the plug (don't
> send me to Open Source).
Don't ask.
Just do it.
You will notice, everyone hasty climb on board of a winning ship.
Than _you_ can choose ...
stefan
`'''�
(o.o)
[=] -< whats going on there??
|
...
> A.L.
>
> How long it would take and how much
> it would cost to rewrite about 3 million lines of
> C/C++/Java/Smalltalk into "better" Lisp?
...
This sounds very much like the typical COBOL advocat.
Andreas
"Andreas Thiele" <······@nospam.com> writes:
> This sounds very much like the typical COBOL advocat.
I think we still have about 100 COBOL developers here... probably more
of them than we have Java.
--
Alan Shutko <···@acm.org> - I am the rocks.
"Alan Shutko" <···@acm.org> schrieb im Newsbeitrag
···················@vera.springies.com...
> "Andreas Thiele" <······@nospam.com> writes:
>
> > This sounds very much like the typical COBOL advocat.
>
> I think we still have about 100 COBOL developers here... probably more
> of them than we have Java.
>
> --
> Alan Shutko <···@acm.org> - I am the rocks.
Do you have a COBOL based product?
Andreas
"Andreas Thiele" <······@nospam.com> writes:
> Do you have a COBOL based product?
It's internal software. (I work at a pharmacy benefits company.) I
don't know where all that COBOL came from, since the company started
in 1992, but I assume it came with some company we acquired.
Regardless, the code base is still there, and new features and whatnot
are still added to the COBOL code base.
It's increasingly clear to me that almost no code will ever be
rewritten... but the flip side is that companies really do get used to
a multi-language environment. It isn't necessary to eradicate the old
languages, the key is to get Lisp a foothold in new development. (Not
that I've had success here yet, but it's possible.)
--
Alan Shutko <···@acm.org> - I am the rocks.
"Alan Shutko" <···@acm.org> schrieb im Newsbeitrag
···················@vera.springies.com...
> "Andreas Thiele" <······@nospam.com> writes:
>
> > Do you have a COBOL based product?
>
> It's internal software. (I work at a pharmacy benefits company.) I
> don't know where all that COBOL came from, since the company started
> in 1992, but I assume it came with some company we acquired.
> Regardless, the code base is still there, and new features and whatnot
> are still added to the COBOL code base.
>
> It's increasingly clear to me that almost no code will ever be
> rewritten... but the flip side is that companies really do get used to
> a multi-language environment. It isn't necessary to eradicate the old
> languages, the key is to get Lisp a foothold in new development. (Not
> that I've had success here yet, but it's possible.)
>
> --
> Alan Shutko <···@acm.org> - I am the rocks.
Alan,
if you can still make money with your COBOL code everything is fine. Of
course this is a very important aspect widely considered the most important.
I was a COBOL programmer for about two years and made some very bad
experience. May be a company with great documentation and great coding
standards is in a better situation. Our software in great parts was
unmaintainable. Gotos from section a to b to c and back to a or b made it
extremely difficult to analyze undocument code which did essential work.
Programmers were forbidden to touch certain modules and and and ...
Despite of my experiences in 2003 I still heard a manager say: "COBOL is
easy to write, easy to maintain and gives robust and fast modules!".
Let's be honest: If I had to decide what language to choose to write a new
application, I am sure it will not be COBOL. I think the presence of COBOL
hinders technological advances. This is no Lisp against COBOL comparison it
is just me arguing against COBOL.
BTW, if I had to do my old COBOL job again, a large amount of my coding work
would be done by Lisp programs :)
Andreas
Peter Seibel <·····@gigamonkeys.com> writes:
> Matthias <··@spam.pls> writes:
> > Personally speaking, I dislike it if people make claims "programming
> > language/ editor/ library/ development method ('methodology' if you
> > want to sound educated) such-and-such is X-times more productive
> > than alternatives" without providing any evidence. And no, personal
> > anecdotes do not count as evidence.
>
> Hmmm. Why not? Given the difficulties of setting up an experiment
> that controls for the many variables that go into software
> productivity in order to isolate the effect of programming language,
Well, if the effect of programming language choice on productivity
were as huge as claimed by some (I read "10 times more efficient"
somewhere here) I should be measurable even with simple studies. Such
a huge effect would peak out of the noise very clearly.
> it seems a bit rash to reject out of hand the judgement of skilled
> practitioners of an art/craft/whatever about which tools make them
> more productive.
You are right here. But remember, it's something different when a
skilled practitioner says "I like X for these reasons" than when she
claims "A is 10 times more productive than B". The first is a
personal statement, a judgment, a believe maybe. Depending on the
person and circumstances, this can be useful. The second sentence
sounds like a scientific statement, like a fact. And it is meant to
sound like that.
Using pseudo-scientific statements to push ones own agenda is among
the worst means of persuasion. On the long run, this hurts science
_and_ your agenda (since people are not that stupid). So let's stop
doing it. Even if the agenda is as noble as spreading lisp. ;-)
Matthias
From: Christopher C. Stacy
Subject: Re: why not enough lisp libraries?
Date:
Message-ID: <ud5ulfl9y.fsf@news.dtpq.com>
Matthias <··@spam.pls> writes:
> Peter Seibel <·····@gigamonkeys.com> writes:
> > Matthias <··@spam.pls> writes:
> > > Personally speaking, I dislike it if people make claims "programming
> > > language/ editor/ library/ development method ('methodology' if you
> > > want to sound educated) such-and-such is X-times more productive
> > > than alternatives" without providing any evidence. And no, personal
> > > anecdotes do not count as evidence.
> >
> > Hmmm. Why not? Given the difficulties of setting up an experiment
> > that controls for the many variables that go into software
> > productivity in order to isolate the effect of programming language,
>
> Well, if the effect of programming language choice on productivity
> were as huge as claimed by some (I read "10 times more efficient"
> somewhere here) I should be measurable even with simple studies.
> Such a huge effect would peak out of the noise very clearly.
But there are not even any simple studies available for us to analyze,
which is why the only thing that you can get from people throwing around
random numbers like this is that their anecdotal experience was positive.
Contrary to popular belief, ancedotal evidence is extremely valuable.
The trick is to get anecdotes from people who you should believe.
People could conduct some tests, but I don't think there will ever
be any statistical evidence to back up these kinds of claims in any
way that has meaning when applied to any situation (eg. the real
world) that I care about. Every situation is too different and
there are too many subjective factors and random variables.
······@news.dtpq.com (Christopher C. Stacy) writes:
> Matthias <··@spam.pls> writes:
>
> > Well, if the effect of programming language choice on productivity
> > were as huge as claimed by some (I read "10 times more efficient"
> > somewhere here) I should be measurable even with simple studies.
> > Such a huge effect would peak out of the noise very clearly.
>
> But there are not even any simple studies available for us to analyze,
> which is why the only thing that you can get from people throwing around
> random numbers like this is that their anecdotal experience was positive.
> Contrary to popular belief, ancedotal evidence is extremely valuable.
> The trick is to get anecdotes from people who you should believe.
>
> People could conduct some tests, but I don't think there will ever
> be any statistical evidence to back up these kinds of claims in any
> way that has meaning when applied to any situation (eg. the real
> world) that I care about. Every situation is too different and
> there are too many subjective factors and random variables.
What about: http://www.flownet.com/gat/papers/lisp-java.pdf
And the associated FAQ: http://www.flownet.com/gat/papers/ljfaq.html
Doesn't this count for anything?
While this is not about Lisp, there are other theories about
programmer productivity:
http://www.artima.com/intv/speed.html
http://home.pacbell.net/ouster/scripting.html
I may be off base, but it seems to me that Lisp is at least as high a
level language as Python or Tcl.
--
An ideal world is left as an excercise to the reader.
--- Paul Graham, On Lisp 8.1
David Steuber <·····@david-steuber.com> writes:
> ······@news.dtpq.com (Christopher C. Stacy) writes:
> > People could conduct some tests, but I don't think there will ever
> > be any statistical evidence to back up these kinds of claims in any
> > way that has meaning when applied to any situation (eg. the real
> > world) that I care about. Every situation is too different and
> > there are too many subjective factors and random variables.
>
> What about: http://www.flownet.com/gat/papers/lisp-java.pdf
I know that paper. And I like it: it shows how one can put numbers on
these productivity claims, in principle. Unfortunately, as clearly
stated in the paper: "Our study contains one significant
methodological flaw: all the subjects were self-selected [...]. About
the only firm conclusion we can draw is that it would be worthwhile to
conduct a follow-up study with better controls." After this
disclaimer the author draws a couple of additional conclusions... ;-)
Still, note that the median development time (medians are probably the
most robust statistics one can use in rather small samples with very
high variation) of Lisp is about half that of Java. I think a
productivity gain of factor 2 is huge. But people in this newsgroup
are claiming a factor 10 and more.
Matthias <··@spam.pls> writes:
> David Steuber <·····@david-steuber.com> writes:
> > ······@news.dtpq.com (Christopher C. Stacy) writes:
> > > People could conduct some tests, but I don't think there will ever
> > > be any statistical evidence to back up these kinds of claims in any
> > > way that has meaning when applied to any situation (eg. the real
> > > world) that I care about. Every situation is too different and
> > > there are too many subjective factors and random variables.
> >
> > What about: http://www.flownet.com/gat/papers/lisp-java.pdf
>
...
> Still, note that the median development time (medians are probably the
> most robust statistics one can use in rather small samples with very
> high variation) of Lisp is about half that of Java. I think a
> productivity gain of factor 2 is huge. But people in this newsgroup
> are claiming a factor 10 and more.
Your not considering the type of project and getting confused. The
thing to note is that at least some (I believe most) of the claims of
something like an order of magnitude involve real large scale projects
- not toys like the one in the study. As I said before, it is simply
not economically feasible to remove the "toyness" from such studies.
The best you can do is have a somewhat more significant toy than
really silly ones. After all, what is the productivity difference
between L1 and L2 for the problem "write a program that outputs 'Hello
World' the number of times provided by a user", where L1 and L2 range
over all programming languages?
/Jon
--
'j' - a n t h o n y at romeo/charley/november com
From: Christopher C. Stacy
Subject: Re: why not enough lisp libraries?
Date:
Message-ID: <uu0nx0xmu.fsf@news.dtpq.com>
David Steuber <·····@david-steuber.com> writes:
> ······@news.dtpq.com (Christopher C. Stacy) writes:
>
> > Matthias <··@spam.pls> writes:
> >
> > > Well, if the effect of programming language choice on productivity
> > > were as huge as claimed by some (I read "10 times more efficient"
> > > somewhere here) I should be measurable even with simple studies.
> > > Such a huge effect would peak out of the noise very clearly.
> >
> > But there are not even any simple studies available for us to analyze,
> > which is why the only thing that you can get from people throwing around
> > random numbers like this is that their anecdotal experience was positive.
> > Contrary to popular belief, ancedotal evidence is extremely valuable.
> > The trick is to get anecdotes from people who you should believe.
> >
> > People could conduct some tests, but I don't think there will ever
> > be any statistical evidence to back up these kinds of claims in any
> > way that has meaning when applied to any situation (eg. the real
> > world) that I care about. Every situation is too different and
> > there are too many subjective factors and random variables.
>
>
> What about: http://www.flownet.com/gat/papers/lisp-java.pdf
>
> And the associated FAQ: http://www.flownet.com/gat/papers/ljfaq.html
>
> Doesn't this count for anything?
It only speaks to one particular little example, not anything that
could be an objective scientific study with wide applicability used
to back up vast sweeping statements. I see no reason to believe
that it is a repeatable experiment. So it would not convince me.
(I consider the study to be anecdotal; perhaps you can see why I
don't think there will ever be any studies about any language
that that would satisfy me.)
Personally, I think Lisp makes me far more productive, and I can
give reasons why. It's nothing that hasn't been said before.
······@news.dtpq.com (Christopher C. Stacy) writes:
> Personally, I think Lisp makes me far more productive, and I can
> give reasons why. It's nothing that hasn't been said before.
I'm sure I'm over trimming, but I do agree with you. The claim had
been made that there were no studies. Instead, there are no
scientifically valid studies ;-)
I imagine a real study would be rather expensive and the cautions from
Richard Feynman about Cargo Cult Science would almost certainly apply.
My productivity in Lisp is certainly improving. I would say that I'm
about as productive in Lisp as I used to be in Perl. Well almost. I
offer this without proof as another anecdote. Lisp seems to be about
as high level as modern scripting languages with the ability to go
higher in terms of embedding a domain specific language and lower in
terms of bit twiddling. There is a wide range. I suspect that with
some current implementations it is possible to write efficient digital
signal processing code and high level "scripting" code that all gets
compiled into a single running image. This can also be done in C of
course. But I suspect that it is easier in Lisp.
I suppose a reasonable claim to make would be that Lisp can give you
development times comparable to Python with execution speed comparable
to C. I don't feel like I'm going too far out on a limb by saying
that with the caveat that there will be exceptions.
--
An ideal world is left as an excercise to the reader.
--- Paul Graham, On Lisp 8.1
David Steuber wrote:
>
> I suppose a reasonable claim to make would be that Lisp can give you
> development times comparable to Python with execution speed comparable
> to C. I don't feel like I'm going too far out on a limb by saying
> that with the caveat that there will be exceptions.
>
One of things about Lisp that speeds me up is that I can immediately
start coding a solution. Any part, low level, high level, I can
just _immediately_ start somewhere. With something like C it is
more difficult, I need support code to run it, I usually create
a makefile, create include files, all my tools have to line up
and then the endless edit-compile-debug cycles start. With Lisp
I can write a small something, test it, let my thoughts go on to
a different part, stash the code away. My code tends to grow
from running (however small) system to running system. There
is always something to show, some success, and most importantly
something concrete to think about.
Wade
On Tue, 01 Mar 2005 02:40:10 GMT,
Wade Humeniuk <··················@telus.net> wrote:
> One of things about Lisp that speeds me up is that I can immediately
> start coding a solution. Any part, low level, high level, I can
> just _immediately_ start somewhere.
Because of the REPL, I can start running this code almost immediately
and get a feel for what's going on. This allows for prototyping and
experimentation while approaching the final code.
It's hard to describe to people who haven't seen it in action how
empowering it is to use a REPL. APL workspaces are pretty much the
same thing, and OCaml offers a really good emacs-based REPL.
raja
Rajat Datta wrote:
>
> It's hard to describe to people who haven't seen it in action how
> empowering it is to use a REPL. APL workspaces are pretty much the
> same thing, and OCaml offers a really good emacs-based REPL.
>
I would say many people have the mistaken view that what you
get when you get CL is a compiler and some libraries. You
actually get a core image that you extend to make other running images.
The core image is a running application, part compiler, part library,
part IDE, part debugger and the REPL. Its because of the dynamic nature of
CL that you can do this. A Lisp standard is not just a language definition,
it also specifies what is available in a core image, what is needed
to allow extension of that image.
Other languages try to adopt Lisp dynamism, and parts of the REPL like incremental
compilation, but most of the time it ends up being a hodge-podge of tools.
Wade
To further flesh out my thoughts,
I would say that a Lisp image meets the definition of a life form,
viral, but no less a life form. It just needs a programmer
to make it reproduce and evolve. So the REPL is a core element of
a digital lifeform?
Wade
Wade Humeniuk wrote:
> To further flesh out my thoughts,
>
> I would say that a Lisp image meets the definition of a life form,
> viral, but no less a life form. It just needs a programmer
> to make it reproduce and evolve.
Um, nice sentiment, but my definition of a life form requires an ability to
gather resources, manufacture the materials needed for its own body, and
reproduce on its own accord. Saying "it just needs a programmer" is an
admission that it's not a life form, but a tool.
--
Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA
20% of the world is real.
80% is gobbledygook we make up inside our own heads.
"Brandon J. Van Every" <·····························@yahoo.com> writes:
> Wade Humeniuk wrote:
> > To further flesh out my thoughts,
> >
> > I would say that a Lisp image meets the definition of a life form,
> > viral, but no less a life form. It just needs a programmer
> > to make it reproduce and evolve.
>
> Um, nice sentiment, but my definition of a life form requires an ability to
> gather resources, manufacture the materials needed for its own body, and
> reproduce on its own accord. Saying "it just needs a programmer" is an
> admission that it's not a life form, but a tool.
Of course.
Parasites are not life forms, they're tools.
Since "they just need a host" is an administion that it's not a life
form, but a tool.
--
__Pascal Bourguignon__ http://www.informatimago.com/
Pascal Bourguignon wrote:
> "Brandon J. Van Every" <·····························@yahoo.com>
> writes:
>
>> Wade Humeniuk wrote:
>>> To further flesh out my thoughts,
>>>
>>> I would say that a Lisp image meets the definition of a life form,
>>> viral, but no less a life form. It just needs a programmer
>>> to make it reproduce and evolve.
>>
>> Um, nice sentiment, but my definition of a life form requires an
>> ability to gather resources, manufacture the materials needed for
>> its own body, and reproduce on its own accord. Saying "it just
>> needs a programmer" is an admission that it's not a life form, but a
>> tool.
>
> Of course.
> Parasites are not life forms, they're tools.
> Since "they just need a host" is an administion that it's not a life
> form, but a tool.
I'm recalling something a friend of mine said about programmer geeks and the
anti-sociability of pedantic arguments, but I find I have some capacity for
it, so I'll indulge. Lisp doesn't walk / grow / disperse up to you, stick a
tentacle in your brain, and start sucking the juice out. "It just needs a
programmer" referred to an active programmer, not a passive one. The one
point where the logic of my claim might break down is not parasites, but
domesticated crops that no longer have the ability to reproduce without
human management. Still, they go through the rest of the motions as long as
the humans plant the seeds. I will leave the pedantry of that debate as an
exercise to other readers.
--
Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA
20% of the world is real.
80% is gobbledygook we make up inside our own heads.
"Brandon J. Van Every" <·····························@yahoo.com> writes:
> Pascal Bourguignon wrote:
> > "Brandon J. Van Every" <·····························@yahoo.com>
> > writes:
> >
> >> Wade Humeniuk wrote:
> >>> To further flesh out my thoughts,
> >>>
> >>> I would say that a Lisp image meets the definition of a life form,
> >>> viral, but no less a life form. It just needs a programmer
> >>> to make it reproduce and evolve.
> >>
> >> Um, nice sentiment, but my definition of a life form requires an
> >> ability to gather resources, manufacture the materials needed for
> >> its own body, and reproduce on its own accord. Saying "it just
> >> needs a programmer" is an admission that it's not a life form, but a
> >> tool.
> >
> > Of course.
> > Parasites are not life forms, they're tools.
> > Since "they just need a host" is an administion that it's not a life
> > form, but a tool.
>
> I'm recalling something a friend of mine said about programmer geeks and the
> anti-sociability of pedantic arguments, but I find I have some capacity for
> it, so I'll indulge. Lisp doesn't walk / grow / disperse up to you, stick a
> tentacle in your brain, and start sucking the juice out. "It just needs a
> programmer" referred to an active programmer, not a passive one. The one
> point where the logic of my claim might break down is not parasites, but
> domesticated crops that no longer have the ability to reproduce without
> human management. Still, they go through the rest of the motions as long as
> the humans plant the seeds. I will leave the pedantry of that debate as an
> exercise to other readers.
I was mocking your restricted definition of "life form".
What Wade tried to express is that lisp is a meme. http://www.memecentral.com/
(A lot of ideas are memes).
--
__Pascal Bourguignon__ http://www.informatimago.com/
Our enemies are innovative and resourceful, and so are we. They never
stop thinking about new ways to harm our country and our people, and
neither do we. -- Georges W. Bush
Pascal Bourguignon wrote:
> "Brandon J. Van Every" <·····························@yahoo.com>
> writes:
>
>> Pascal Bourguignon wrote:
>>> "Brandon J. Van Every" <·····························@yahoo.com>
>>> writes:
>>>
>>>> Wade Humeniuk wrote:
>>>>> To further flesh out my thoughts,
>>>>>
>>>>> I would say that a Lisp image meets the definition of a life form,
>>>>> viral, but no less a life form. It just needs a programmer
>>>>> to make it reproduce and evolve.
>>>>
>>>> Um, nice sentiment, but my definition of a life form requires an
>>>> ability to gather resources, manufacture the materials needed for
>>>> its own body, and reproduce on its own accord. Saying "it just
>>>> needs a programmer" is an admission that it's not a life form, but
>>>> a tool.
>>>
>>> Of course.
>>> Parasites are not life forms, they're tools.
>>> Since "they just need a host" is an administion that it's not a life
>>> form, but a tool.
>>
>> I'm recalling something a friend of mine said about programmer geeks
>> and the anti-sociability of pedantic arguments, but I find I have
>> some capacity for it, so I'll indulge. Lisp doesn't walk / grow /
>> disperse up to you, stick a tentacle in your brain, and start
>> sucking the juice out. "It just needs a programmer" referred to an
>> active programmer, not a passive one. The one point where the logic
>> of my claim might break down is not parasites, but domesticated
>> crops that no longer have the ability to reproduce without human
>> management. Still, they go through the rest of the motions as long
>> as the humans plant the seeds. I will leave the pedantry of that
>> debate as an exercise to other readers.
>
> I was mocking your restricted definition of "life form".
Your mockery was not very good, as "programmer" vs. "host" is a big change
of semantics.
> What Wade tried to express is that lisp is a meme.
> http://www.memecentral.com/ (A lot of ideas are memes).
Whether he was trying to express that or not, I do find it plausible.
--
Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA
20% of the world is real.
80% is gobbledygook we make up inside our own heads.
Brandon J. Van Every wrote:
> Wade Humeniuk wrote:
>
>>To further flesh out my thoughts,
>>
>>I would say that a Lisp image meets the definition of a life form,
>>viral, but no less a life form. It just needs a programmer
>>to make it reproduce and evolve.
>
>
> Um, nice sentiment, but my definition of a life form requires an ability to
> gather resources, manufacture the materials needed for its own body, and
> reproduce on its own accord. Saying "it just needs a programmer" is an
> admission that it's not a life form, but a tool.
>
Well a virus just needs a self-replicating cell to reproduce. A virus
attaches to a cell by bonding to receptors on the surface of the
cell. A digital lifeform (thought) by analogy may attach to
a "receptive" programmer in much the same manner. Many
Lisp programmers will say "ever since I found Lisp, it has
wrecked me, I do no want to program in anything else." Lisp
started as an attractive self-contained idea and has
changed (evolved) over the last 50 years.
I think this is similar to the idea that we are "genes finding a way
to reproduce themselves".
Wade
Wade Humeniuk wrote:
>
> Well a virus just needs a self-replicating cell to reproduce. A virus
> attaches to a cell by bonding to receptors on the surface of the
> cell. A digital lifeform (thought) by analogy may attach to
> a "receptive" programmer in much the same manner. Many
> Lisp programmers will say "ever since I found Lisp, it has
> wrecked me, I do no want to program in anything else." Lisp
> started as an attractive self-contained idea and has
> changed (evolved) over the last 50 years.
>
> I think this is similar to the idea that we are "genes finding a way
> to reproduce themselves".
Yet, Lisp finds no way to reproduce itself amongst the vast majority of
programmers. I believe it's reproducing among programmers with "taste," and
possibly "idealism," although of course there are other forms of taste and
idealism that push programmers in other directions. comp.lang.functional
has many discussions about comparative taste and idealism, and I've sampled
most of the HLL wares. I find I don't care about purity one bit, and my
jury is still out on type safety.
I'd be interested in hearing from Lispers who took it up for "pragmatic"
reasons. I don't generally think of Lisp as a pragmatic toolbase, given
that a minority of people use it. But it is possible that Lisp can handle
some jobs well that other languages can't, and also that Lisp has some areas
of strong library support that other languages don't.
--
Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA
"Trollhunt" - (n.) A searching out for persecution
of persons accused of Trolling. (c.f. witch-hunt)
Brandon J. Van Every wrote:
> Yet, Lisp finds no way to reproduce itself amongst the vast majority of
> programmers. I believe it's reproducing among programmers with "taste," and
> possibly "idealism," although of course there are other forms of taste and
> idealism that push programmers in other directions. comp.lang.functional
> has many discussions about comparative taste and idealism, and I've sampled
> most of the HLL wares. I find I don't care about purity one bit, and my
> jury is still out on type safety.
Lisp is a parasite that shares a symbiotic relationship with its host.
Most programmers eat antibiotics every day, so Lisp doesn't stand a
chance. They might not gain anything, but I guess they feel cleaner :)
Wade Humeniuk <··················@telus.net> writes:
> David Steuber wrote:
>
> > I suppose a reasonable claim to make would be that Lisp can give you
> > development times comparable to Python with execution speed comparable
> > to C. I don't feel like I'm going too far out on a limb by saying
> > that with the caveat that there will be exceptions.
>
> One of things about Lisp that speeds me up is that I can immediately
> start coding a solution. Any part, low level, high level, I can
> just _immediately_ start somewhere.
I agree, but also think that I may not always want to do that.
One example: Maxima (a free computer algebra system) is a big piece of
software where very smart people seemed to have started immediately,
somewhere. The result is a mostly working, _very_ complex software.
Quite hard to understand on the source level (I tried to factor out
the Risch algorithm code once, but gave up). I think the developers
are now spending time to clean things up and rethink the design
decisions that seemingly were made by accident during the original
development.
The point is: The developer loves this code-immediately-type of
development, since he writes code most of the time, solves problems
most of the time, has fun most of the time. It really feels
productive. But the _impression_ of productivity can be wrong.
Along a similar line: I sometimes see people modeling stuff in C/C++
when they should be using a higher level language (say Lisp or say
mathematical languages like Matlab, Mathematica, Maple, etc.). These
guys feel very productive, code all the time, make progress, etc. The
only problem: They spend most of their time on stuff (like
visualization, linear algebra, numerical solvers) that's already
available in the mathematical languages. So, again, the _impression_
of productivity can be wrong.
Of course, this is not a Lisp thing: Recall how long it took the
Mozilla guys to clean up the code that came from Netscape. On the
other hand, Axiom (another free lisp-based computer algebra system)
seems nicely structured (disclaimer: I looked at it only very briefly).
I'll now have some fun coding... :-)
Matthias
Matthias <··@spam.pls> writes:
> I agree, but also think that I may not always want to do that.
I think what you want to do is plan on throwing one away, per Fred
Brooks in The Mythical Man-Month. Being able to play with some code is
a great way to collect your thoughts. The problem comes when you keep
that test solution around far too long.
--
Dave Roberts
dave -remove- AT findinglisp DoT com
http://www.findinglisp.com/
From: Christopher C. Stacy
Subject: Re: why not enough lisp libraries?
Date:
Message-ID: <uwtsrhc7w.fsf@news.dtpq.com>
Matthias <··@spam.pls> writes:
>
> One example: Maxima (a free computer algebra system) is a big piece of
> software where very smart people seemed to have started immediately,
> somewhere. The result is a mostly working, _very_ complex software.
> Quite hard to understand on the source level (I tried to factor out
> the Risch algorithm code once, but gave up). I think the developers
> are now spending time to clean things up and rethink the design
> decisions that seemingly were made by accident during the original
> development.
Which was already done, along with a lot of other things to it,
during the 23 years of commercial Macsyma development that is
not accounted for in the antique "Maxima" version, by the way...
Matthias wrote:
> Wade Humeniuk <··················@telus.net> writes:
>
>>David Steuber wrote:
>>
>>>I suppose a reasonable claim to make would be that Lisp can give you
>>>development times comparable to Python with execution speed comparable
>>>to C. I don't feel like I'm going too far out on a limb by saying
>>>that with the caveat that there will be exceptions.
>>
>>One of things about Lisp that speeds me up is that I can immediately
>>start coding a solution. Any part, low level, high level, I can
>>just _immediately_ start somewhere.
>
> I agree, but also think that I may not always want to do that.
>
> One example: Maxima (a free computer algebra system) is a big piece of
> software where very smart people seemed to have started immediately,
> somewhere. The result is a mostly working, _very_ complex software.
> Quite hard to understand on the source level (I tried to factor out
> the Risch algorithm code once, but gave up). I think the developers
> are now spending time to clean things up and rethink the design
> decisions that seemingly were made by accident during the original
> development.
...but this is just a problem of doing something for the first time. Of
course, it's only possible to find out the hard way what the "right"
design for a problem is that noone has ever done before. There's simply
no substitute for that. No amount of language design can keep you from
making design mistakes.
As a sidenote, the notion that doing design first on paper before
actually implementing it just shifts the problem to an earlier stage but
doesn't solve it.
Pascal
Pascal Costanza wrote:
>
> As a sidenote, the notion that doing design first on paper before
> actually implementing it just shifts the problem to an earlier stage but
> doesn't solve it.
>
I have written design documents before implementation and I tend
to agree with that statement. The design document tends to
"lie", and it has to. To distill the information and communicate
it with other people, artistic license is needed. This means it
has to presented in a appealing way to get it through any approval
process. To make it appealing, information has to be left out and
the devil is in the details. As a writer of the document, one is
painfully aware of the inaccuracies, as a reader one can get the
false impression that it is correct. (Also the design doc can
become obselete as the implementation is actually done and
the design doc is never updated).
When I did some work with CDC (Control Data Corp) I found their
process to very good. They did not do a design as such,
they did an interface specification instead. Document the protocol/
interface so that a project can be broken into parts and everyone
knows what to expect of the other parts (of course there were changes,
but you had to justify changing the interface).
Wade
Pascal Costanza <··@p-cos.net> wrote:
> As a sidenote, the notion that doing design first on paper before
> actually implementing it just shifts the problem to an earlier stage but
> doesn't solve it.
That reminds me of this essay, which just got republished:
http://www.developerdotstar.com/mag/articles/reeves_design_main.html
Jonne
·····@mit.jyu.fi wrote:
> Pascal Costanza <··@p-cos.net> wrote:
>
>
>>As a sidenote, the notion that doing design first on paper before
>>actually implementing it just shifts the problem to an earlier stage but
>>doesn't solve it.
>
>
> That reminds me of this essay, which just got republished:
> http://www.developerdotstar.com/mag/articles/reeves_design_main.html
damn. so I am not a cowboy programmer after all? I am just following
"best practice"? shucks, I had this whole macho, shoot from the hip
codeslinger self-image going.... :(
well, at least I have an answer for the PHBs who are freaking out over
the absence of documentation. Thanks for the link!
kt
--
Cells? Cello? Cells-Gtk?: http://www.common-lisp.net/project/cells/
Why Lisp? http://lisp.tech.coop/RtL%20Highlight%20Film
"Doctor, I wrestled with reality for forty years, and I am happy to
state that I finally won out over it." -- Elwood P. Dowd
On Mon, 28 Feb 2005 20:32:29 -0500, David Steuber wrote:
>
> My productivity in Lisp is certainly improving. I would say that I'm
> about as productive in Lisp as I used to be in Perl.
The big thing for me isn't the initial productivity, it's the ease of
making changes.
I am finally getting to use Lisp quite a lot at work. I find I'm a little
more productive using Lisp to get an initial solution to a problem than I
would be in Java, but the real big wins come when the specification
changes. I've found I've been able to implement *very* large changes to a
specification just be tweaking a couple of lines of Lisp code. Perhaps
this is because, in Lisp, I'm more able to take the bottom-up approach,
so even when the specification changes, the problem domain doesn't, and I
can reuse 99% of what I've written before. It still surprises me, and I
love it :-)
Cheers,
Bill.
> Yes, Lisp is a tool. Pretty good tool. It is as, say, Bosh or Black
> and Decker electric drill. With electric drill you can only drill
> holes. Fortunately, both Bosh and B&D have discovered long ago that
it
> is possible to develop "attachments" to drills that can do 1000 and
> one other things, making electric drill a really universal tool.
Wrong. Lisp is not a drill. It is a factory which can build drills,
aircrafts,
hammers and microscopes. Again - Lisp is not a language. It is a
metalanguage
and runtime platform (compare to JVM and .NET). I consider it stupid to
code
in Lisp. But it is also stupid to use languages that don't target lisp
as a
runtime platform.
> Lisp has many nice features that make it very good language. I would
> prefer to do lists in Lisp then in Prolog. But there are no
> "attachments" to Lisp, what makes it good only to play in the
sandbox.
I'd ask you the same question again: can you implement Lisp in Prolog?
You can't. I can implement an efficient Prolog *COMPILER* just on top
of
the Lisp macros - extending Lisp to all of the Prolog functionality.
I can also build a Haskell compiler in Lisp, targeting Lisp - and you
can't
do the vice versa in Haskell.
> That the language is "better"? Who cares?
Languages sucks. You have to compare languages development
environments.
On 25 Feb 2005 03:16:50 -0800, ·······@gmail.com <·······@gmail.com> wrote:
> sandbox.
>
> I'd ask you the same question again: can you implement Lisp in Prolog?
> You can't. I can implement an efficient Prolog *COMPILER* just on top
> of
> the Lisp macros - extending Lisp to all of the Prolog functionality.
> I can also build a Haskell compiler in Lisp, targeting Lisp - and you
> can't
> do the vice versa in Haskell.
>
That's not completely correct.
Any Turing complete language *can* implement any other
Turing complete language. It is more a question of the
amount of effort that goes into it.
The first thing Yahoo store did after purchasing Viaweb was to
implement it in C. That effectively meant writing a lisp
interpreter.
The things he describes actually happens all the time.
Managers think that in the name of maintainability all
code should be in one language mastered by all.
Managers seek a stratified design.
If the components are in a plethora of languages this
becomes impossible.
Language abstraction is one implementation strategy.
Object orientation is another.
Structural decomposition (top down programming) is a third.
Which method is the most serendipitous depends on the problem.
Luckily Lisp supports all of these.
In C++ you could write a library of functions,
set up a users interface and put something like Lua/Guile/..
on top of it. Then you write the binding glue in this language.
In Lisp you would write this languages on the language
as a transform into Lisp which is then compiled.
This means that the language is *compiled* where
the C++ equivalent would be *interpreted*.
Herein lies the real advantage of using Lisp.
You get a *bottom* structure that is easier to create and maintain
*and* that executes more efficiently.
--
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
> That's not completely correct.
> Any Turing complete language *can* implement any other
> Turing complete language. It is more a question of the
> amount of effort that goes into it.
I'm talking about efficient, practical implementation.
Sure, you can write a Visual Basic interpreter on QBASIC. But nobody
will ever use it. In Lisp you have all of the compiler features for
free.
That's why it is a meta-language.
> The first thing Yahoo store did after purchasing Viaweb was to
> implement it in C. That effectively meant writing a lisp
> interpreter.
They were stupid. Lot of stupid people around here...
> The things he describes actually happens all the time.
> Managers think that in the name of maintainability all
> code should be in one language mastered by all.
But they're wrong. This approach can't improve maintainability at all.
Well, you have one stupid simple language like Java. But you still have
a lot of libraries (and your own code) which logic does not fit well
into
Java, and you have to be an Einstain to understand all this crap.
> Managers seek a stratified design.
> If the components are in a plethora of languages this
> becomes impossible.
No. It is the only one possible way to the maintainability - only if
language
fits the problem domain well you will not spend lot of expensive time
to
uncover the logic behind the application. Documenting, literate
programming,
etc. will not help at all. Only good language design.
> Language abstraction is one implementation strategy.
> Object orientation is another.
> Structural decomposition (top down programming) is a third.
But OO fails to give enough level of abstraction. :(
It was so beautiful in theory. :(((
> In Lisp you would write this languages on the language
> as a transform into Lisp which is then compiled.
> This means that the language is *compiled* where
> the C++ equivalent would be *interpreted*.
> Herein lies the real advantage of using Lisp.
Thihs is what I'm talking about.
On 25 Feb 2005 04:25:23 -0800, ········@gmail.com"
<·······@gmail.com> wrote:
>
>
> But they're wrong. This approach can't improve maintainability at all.
>Well, you have one stupid simple language like Java. But you still have
>a lot of libraries (and your own code) which logic does not fit well
>into
>Java, and you have to be an Einstain to understand all this crap.
>
Acha... You should state this from very beginning: Java is too
complicated for you to learn and understand the language...
A.L.
> > But they're wrong. This approach can't improve maintainability at
all.
> >Well, you have one stupid simple language like Java. But you still
have
> >a lot of libraries (and your own code) which logic does not fit well
> >into
> >Java, and you have to be an Einstain to understand all this crap.
> >
>
> Acha... You should state this from very beginning: Java is too
> complicated for you to learn and understand the language...
Java is simple. And its simplicity leads to the enormous complexety of
the
Java application. If you know Java, this does not automatically mean
that you will understand any Java application.
That's why you're stupid. That's why your approach is so dumb.
On 25 Feb 2005 05:15:49 -0800, ········@gmail.com"
<·······@gmail.com> wrote:
>
>> > But they're wrong. This approach can't improve maintainability at
>all.
>> >Well, you have one stupid simple language like Java. But you still
>have
>> >a lot of libraries (and your own code) which logic does not fit well
>> >into
>> >Java, and you have to be an Einstain to understand all this crap.
>> >
>>
>> Acha... You should state this from very beginning: Java is too
>> complicated for you to learn and understand the language...
>
> Java is simple. And its simplicity leads to the enormous complexety of
>the
>Java application. If you know Java, this does not automatically mean
>that you will understand any Java application.
>
> That's why you're stupid. That's why your approach is so dumb.
Mr. mauhuur, thanks for strong professional arguments. However, I am
afraid that you have no clue... And that your knowledge of software
engineering is on the same level as my knowledge of Japanese theatre
Kabuki...
A.L.
> > That's why you're stupid. That's why your approach is so dumb.
>
> Mr. mauhuur, thanks for strong professional arguments. However, I am
> afraid that you have no clue... And that your knowledge of software
> engineering is on the same level as my knowledge of Japanese theatre
> Kabuki...
Just fuck off. You're not interesting, shiteating troll scum. Please,
die.
········@gmail.com" <·······@gmail.com> writes:
> > > That's why you're stupid. That's why your approach is so dumb.
> >
> > Mr. mauhuur, thanks for strong professional arguments. However, I am
> > afraid that you have no clue... And that your knowledge of software
> > engineering is on the same level as my knowledge of Japanese theatre
> > Kabuki...
>
> Just fuck off. You're not interesting, shiteating troll scum. Please,
> die.
Perhaps it is time for the news group comp.lang.lisp.advocacy to be
created.
--
An ideal world is left as an excercise to the reader.
--- Paul Graham, On Lisp 8.1
On 25 Feb 2005 13:25:06 -0500, David Steuber <·····@david-steuber.com>
wrote:
>········@gmail.com" <·······@gmail.com> writes:
>
>> > > That's why you're stupid. That's why your approach is so dumb.
>> >
>> > Mr. mauhuur, thanks for strong professional arguments. However, I am
>> > afraid that you have no clue... And that your knowledge of software
>> > engineering is on the same level as my knowledge of Japanese theatre
>> > Kabuki...
>>
>> Just fuck off. You're not interesting, shiteating troll scum. Please,
>> die.
>
>Perhaps it is time for the news group comp.lang.lisp.advocacy to be
>created.
Yes. Mr. mauhuur would be the most active contributor. With very
convincing arguments.
A.L.
A.L. wrote:
> On 25 Feb 2005 13:25:06 -0500, David Steuber <·····@david-steuber.com>
> wrote:
>
>>········@gmail.com" <·······@gmail.com> writes:
>>
>>> > > That's why you're stupid. That's why your approach is so dumb.
>>> >
>>> > Mr. mauhuur, thanks for strong professional arguments. However, I am
>>> > afraid that you have no clue... And that your knowledge of software
>>> > engineering is on the same level as my knowledge of Japanese theatre
>>> > Kabuki...
>>>
>>> Just fuck off. You're not interesting, shiteating troll scum. Please,
>>> die.
>>
>>Perhaps it is time for the news group comp.lang.lisp.advocacy to be
>>created.
>
> Yes. Mr. mauhuur would be the most active contributor. With very
> convincing arguments.
>
It would give him something to do, which can't be altogether a bad thing.
········@gmail.com" schrieb:
> > > That's why you're stupid. That's why your approach is so dumb.
> > Mr. mauhuur, thanks for strong professional arguments. However, I am
> > afraid that you have no clue... And that your knowledge of software
> > engineering is on the same level as my knowledge of Japanese theatre
> > Kabuki...
> Just fuck off. You're not interesting, shiteating troll scum. Please,
> die.
Aber ja - hm?
Some people have different minds. Some points in such minds are
unmovable, otherwise this mind is nothing. This is easier to know than
all chinese letters.
stefan
> Aber ja - hm?
>
> Some people have different minds. Some points in such minds are
> unmovable, otherwise this mind is nothing. This is easier to know
than
> all chinese letters.
It is quite easy to distinguish someone trolling for fun (here - A.L.)
and
someone with "different mind". Trolls should die - there is no need for
them.
People who thinks different should all work together to produce a
better, more
diverse and beautiful world. Trolls aren't creative, that's why they
have to die.
········@gmail.com" schrieb:
> > Aber ja - hm?
> > Some people have different minds. Some points in such minds are
> > unmovable, otherwise this mind is nothing. This is easier to know
> than
> > all chinese letters.
> It is quite easy to distinguish someone trolling for fun (here - A.L.)
> and
> someone with "different mind". Trolls should die - there is no need for
> them.
> People who thinks different should all work together to produce a
> better, more
> diverse and beautiful world. Trolls aren't creative, that's why they
> have to die.
No. Even evolution did not work this way.
stefan
> No. Even evolution did not work this way.
I know. It is not applyable at all for the humankind - consider all
that
"mentally challenged" who are not only alive, but have a right to
reproduce!
But we can help the evolution. The true free market *can* (in theory).
On Fri, 25 Feb 2005 07:06:46 -0600, A.L.
<·················@oddpost_tego_tez_nie.com> wrote:
> On 25 Feb 2005 04:25:23 -0800, ········@gmail.com"
> <·······@gmail.com> wrote:
>
>>
>>
>> But they're wrong. This approach can't improve maintainability at all.
>> Well, you have one stupid simple language like Java. But you still have
>> a lot of libraries (and your own code) which logic does not fit well
>> into
>> Java, and you have to be an Einstain to understand all this crap.
>>
>
> Acha... You should state this from very beginning: Java is too
> complicated for you to learn and understand the language...
>
> A.L.
If you read the paragraph more carefully you will see
that it is not Java that is the culprit.
The *myth* is that joining all the code under one
language makes it easier to understand and maintain
It is the code you write in Java that determines this.
If you try to *warp* code written in other languages
to work in Java you could end up with something even more
difficult to understand.
He wants to write an abstraction language on Lisp that map's
directly to the problem. Thus the solution isn't Lisp per se
but the language he writes on Lisp to describe the problem.
--
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
On Fri, 25 Feb 2005 14:23:23 +0100, "John Thingstad"
<··············@chello.no> wrote:
>
>He wants to write an abstraction language on Lisp that map's
>directly to the problem. Thus the solution isn't Lisp per se
>but the language he writes on Lisp to describe the problem.
This is the reason why industry is not using Lisp. And most likely,
will not.
A.L.
> >He wants to write an abstraction language on Lisp that map's
> >directly to the problem. Thus the solution isn't Lisp per se
> >but the language he writes on Lisp to describe the problem.
>
> This is the reason why industry is not using Lisp. And most likely,
> will not.
1) Industry IS using Lisp. Due to this reason.
2) It is true, that there are lot of undereducated halfbrained so
called "managers". They will not survive the competition - complexity
of the
software projects now approaching the limit when the usage of one
stupid
toy language like sucking Java won't be possible at all.
P.S. You're stupid troll. You did not tried to read the article I
pointed at all, you missed all arguments. I don't see the point in
arguing with you, troll.
On 25 Feb 2005 06:08:47 -0800, ········@gmail.com" <·······@gmail.com>
wrote:
>
>> >He wants to write an abstraction language on Lisp that map's
>> >directly to the problem. Thus the solution isn't Lisp per se
>> >but the language he writes on Lisp to describe the problem.
>>
>> This is the reason why industry is not using Lisp. And most likely,
>> will not.
>
>1) Industry IS using Lisp. Due to this reason.
>
>2) It is true, that there are lot of undereducated halfbrained so
>called "managers". They will not survive the competition - complexity
>of the
>software projects now approaching the limit when the usage of one
>stupid
>toy language like sucking Java won't be possible at all.
>
>P.S. You're stupid troll. You did not tried to read the article I
>pointed at all, you missed all arguments. I don't see the point in
>arguing with you, troll.
Fine Mr. mauhuur.. With all possible respect, you are landing in my
Kill File.
A.L.
········@gmail.com" <·······@gmail.com> writes:
> 2) It is true, that there are lot of undereducated halfbrained so
> called "managers". They will not survive the competition - complexity
> of the
> software projects now approaching the limit when the usage of one
> stupid
> toy language like sucking Java won't be possible at all.
I'm on the Lisp side, but this is probably over the top. ;-)
Java will survive quite well, as will others.
Never underestimate the power of brute force. While I love simplicity
and elegance, many a project has eventually succumed to a swarm of
frothing Java programmers, even if it did take 10 times as many, 10
times a long, etc., etc. Indeed, if you're coming from a C++
background (as I was when I first learned Java), Java is a breath of
fresh air and makes you seem so productive that you don't even realize
that you could be even more so with Lisp.
As Guy Steele said about Java:
http://people.csail.mit.edu/people/gregs/ll1-discuss-archive-html/msg04045.html
"And you're right: we were not out to win over the Lisp programmers;
we were after the C++ programmers. We managed to drag a lot of them
about halfway to Lisp. Aren't you happy?"
--
Dave Roberts
dave -remove- AT findinglisp DoT com
http://www.findinglisp.com/
From: Christopher C. Stacy
Subject: Re: why not enough lisp libraries?
Date:
Message-ID: <uwtswie7x.fsf@news.dtpq.com>
Dave Roberts <···········@remove-findinglisp.com> writes:
>
> Never underestimate the power of brute force. While I love simplicity
> and elegance, many a project has eventually succumed to a swarm of
> frothing Java programmers, even if it did take 10 times as many, 10
> times a long, etc., etc.
Yes, there's always a continuum, and the "elegant" aesthetic is rather
subjective. Lisp can often (more often than most people imagine)
be used to quickly cobble together a solution that is easier to
understand and maintain and meets the performance specifications.
That's one definition of elegant, perhaps recursively explained
by the elegance of the language, per se. But money is what makes
the world go round, and (as is normally the case in history)
people are what is expensive. The big cost is in finding good
Lisp programmers because Lisp is not the most popular thing.
That's a very valid business risk to consider.
Most companies hire programmers who know some popular language
(such as C++ or Java), regardless of whether they are good programmers
are not. Indeed, most programmers in general are not good.
Sometimes I think that's getting worse, because with so many
libraries available, increasingly more clueless people are able
to plug things together. This should be no surprise, since
most people in the world are only vaugely competent at what
they do; that's why there can be "exceptional" people.
When you factor some amount of "art" into the discipline of creating
good software, it becomes obvious that this must always be true.
What is important to most companies is not that programmers are very good,
but that they are easily replacable. For that, you need popular tools.
Naturally it turns out that those tools are not the most powerful ones.
The programmers and tools have evolved to be optimized for each other.
We can easily imagine how the tools could be better -- allowing
mediocre programmers to succeed even more. But the popular tools
are fundamentally flawed, and have tremendous momentum. Even most
of the toolmakers themselves are stuck using the poor tools!
Considering all that, progress in this area has come a long way.
25 years ago we thought that people would not even be programming
computers anymore, in the traditional sense. That was overly
optimistic, owing partly to underestimation and partly to social
setbacks (such as "AI Winter"), but it's also partly come true.
Considering technologies based on Lisp, progress seems slow to
the few people who recognize the potential of doing things our
non-popular way. So-called modern progress and the popularity of
today's computing technologies is bewilderingly agonizing for
the very few who have seen the future-past where it was actually
beginning to be realized. Those of us who were around back then
shouldn't be so surprised. Back in the 1970s and 180s everyone
uesd to be programming in COBOL on punched cards while we sat in
our ivory labs with Lisp Machines. Lisp Machine commercialization
sadly failed, due to social and market forces that were misunderstood,
and from the ordinary foibles of risky high-tech company screwups.
It's often said that software development is poorly understood,
and there have always been attempts to develop and codify practices
that can reduce it to a predictable low-risk endeavor. In the main,
these efforts has been designed or interpreted to mean optimizing
for mediocre programmers using already widespread technologies.
Companies don't want to hire engineering artists - they would rather
employ fungable coders. Unique talents are not easily replaced, and
therefore represent a risk. The degree to which companies can propsper
using such a worse-is-better strategy depends on the context they are
operating in, including what they are doing, and the competition.
Their position changes, and companies come and go.
This is why you see Lisp being used in places that can tolerate,
or which necessarioly demand, the risk of the unconventional.
Academia. Individual programmers and small shops that need to
leverage the power of Lisp in order to compete with larger companies.
Large companies and government agencies that can afford the risk and
expense of trying things or maintaining research and development costs.
In the late 1990s and into this century, many people are once again
in a mode of at least looking at new technologies. Hopefully Lisp
will gain some popularity from this.
Since this discussion was obstensibly about libraries, here are my
thoughts on that. Libraries are a necessary part of what programmers
need to succeed. The roll-your-own approach has long been championed
by Lisp hackers, and while it's certainly usually much easier to do this
in Lisp than in most languages, that's never been wholly satisfactory.
It is particularly unbelievable to people inexperienced with Lisp.
Fortunately, both the commercial and free vendors have improved
the range of libraries available, and are continuing to do so.
Right now there are enough libraries to do pretty much all the
usual things that people want most of the time, as far as I can tell.
There are many improvements to be made all around, but people have
been happily deploying applications that use multiprocessing,
networing and web, databases, and window GUIs.
The environment, integration, and libraries are not as nice
as what we had a couple decades ago, but it's coming along okay.
Pretty much beats the hell out of the alternatives, anyway.
Christopher C. Stacy wrote:
> Dave Roberts <···········@remove-findinglisp.com> writes:
> This is why you see Lisp being used in places that can tolerate,
> or which necessarioly demand, the risk of the unconventional.
> Academia.
I'm curious about whether the academia adoption of Lisp (specifically
excluding Scheme) is similar to industrial adoption. I personally
suspect academia has a very narrow range of acceptance. Pascal Costanza
mentioned it was very uncommon to find an openminded place like the
university at Brussels, which he recently moved to.
Scheme has something in favor of it in mainstream adoption -- it's
frequently taught with limits, like Python's "There should be only one
way to do it". So through my biased lens, I see SICP Scheme as a
somewhat deskilling tech.
MfG,
Tayssir
From: Christopher C. Stacy
Subject: Re: why not enough lisp libraries?
Date:
Message-ID: <uoee8idyd.fsf@news.dtpq.com>
······@news.dtpq.com (Christopher C. Stacy) writes:
> Back in the 1970s and 1980s everyone uesd to be programming in COBOL
> on punched cards while we sat in our ivory labs with Lisp Machines.
> Lisp Machine commercialization
Well, not everyone. But the APL people, technological forerunners
of the Lisp Machine's sort of foray into the real world, are in
exactly the same damn boat as we are.
> Java will survive quite well, as will others.
Java - definitely will survive. The language&technology diversity will
rule forever!
But stupid "managers" who thinks now, that Only Java Will Ever Rule
will
not survive.
> Never underestimate the power of brute force. While I love simplicity
> and elegance, many a project has eventually succumed to a swarm of
> frothing Java programmers, even if it did take 10 times as many, 10
> times a long, etc., etc. Indeed, if you're coming from a C++
> background (as I was when I first learned Java), Java is a breath of
> fresh air and makes you seem so productive that you don't even
realize
> that you could be even more so with Lisp.
For C++ people Java is also a prison cage - there are no even traces
of
metaprogramming features, even of the poor and stupid C++-ish kind.
Simple and stupid languages like Java definitely have to exist, there
is
a very wide area of applications for them. But - they should not
dominate.
They should never be the "only one option available".
> "And you're right: we were not out to win over the Lisp programmers;
> we were after the C++ programmers. We managed to drag a lot of them
> about halfway to Lisp. Aren't you happy?"
As for me - Java is a step away from Lisp. C++ had metaprogramming.
Java
will never feature so "dangerous" feature. GC is not so important - I
can
easily imagine a Lisp without GC - it won't lack a lot then.
········@gmail.com" <·······@gmail.com> writes:
> > Java will survive quite well, as will others.
>
> Java - definitely will survive. The language&technology diversity will
> rule forever!
>
> But stupid "managers" who thinks now, that Only Java Will Ever Rule
> will
> not survive.
I doubt you'd ever find a manager of the type you describe. Even
managers of questionable intellect are not so dumb at to suggest that
Java will be the last programming language of all time. To suggest
such is pure folly and ignores history.
> > Never underestimate the power of brute force. While I love simplicity
> > and elegance, many a project has eventually succumed to a swarm of
> > frothing Java programmers, even if it did take 10 times as many, 10
> > times a long, etc., etc. Indeed, if you're coming from a C++
> > background (as I was when I first learned Java), Java is a breath of
> > fresh air and makes you seem so productive that you don't even
> realize
> > that you could be even more so with Lisp.
>
> For C++ people Java is also a prison cage - there are no even traces
> of
> metaprogramming features, even of the poor and stupid C++-ish kind.
>
> Simple and stupid languages like Java definitely have to exist, there
> is
> a very wide area of applications for them. But - they should not
> dominate.
> They should never be the "only one option available".
And they are not the only option available. Indeed, I don't think
anybody in this thread suggested that they are or even that they
should be. Whether or not they dominate will be decided by the
marketplace and not by you or I.
> > "And you're right: we were not out to win over the Lisp programmers;
> > we were after the C++ programmers. We managed to drag a lot of them
> > about halfway to Lisp. Aren't you happy?"
>
> As for me - Java is a step away from Lisp. C++ had metaprogramming.
> Java
> will never feature so "dangerous" feature. GC is not so important - I
> can
> easily imagine a Lisp without GC - it won't lack a lot then.
Never say never. It's quite likely that Java will develop such
features over time. The generics feature was one small step in that
direction. That said, if you were to say, "I don't think Java will
ever develop a macro system to rival that of Lisp," I would probably
agree with you. Without sexp syntax, it would be very difficult to
do. I could easily see it getting something of the C++ variety,
however.
--
Dave Roberts
dave -remove- AT findinglisp DoT com
http://www.findinglisp.com/
Dave Roberts wrote:
> > But stupid "managers" who thinks now, that Only Java Will Ever
Rule
> > will
> > not survive.
>
> I doubt you'd ever find a manager of the type you describe. Even
> managers of questionable intellect are not so dumb at to suggest that
> Java will be the last programming language of all time. To suggest
> such is pure folly and ignores history.
But I know the living examples of this kind. And - look at all the
trolls
at c.l.java.advocacy - they think this way as well. Only One Very
Simple
Language that Even Dummies Can Master - this is the motto they have.
> > Simple and stupid languages like Java definitely have to exist,
there
> > is
> > a very wide area of applications for them. But - they should not
> > dominate.
> > They should never be the "only one option available".
>
> And they are not the only option available. Indeed, I don't think
> anybody in this thread suggested that they are or even that they
> should be. Whether or not they dominate will be decided by the
> marketplace and not by you or I.
Read again what A.L. suggested: to feed the hordes of the dumb
"programmers" you have to manage the project with a simpliest
technology
available. Well, I can agree with this statement - but I believe that
Lisp
(or any other meta-tool of the same power) is the simplest solution,
not
Java nor Visual Basic.
> > As for me - Java is a step away from Lisp. C++ had
metaprogramming.
> > Java
> > will never feature so "dangerous" feature. GC is not so important -
I
> > can
> > easily imagine a Lisp without GC - it won't lack a lot then.
>
> Never say never. It's quite likely that Java will develop such
> features over time.
Then it will loose its "simplicity". Java adepts won't accept this
way.
They already have Jatha - a very nice Java metaprogramming tool, they
have AspectJ - but they consider it as a marginal hacking. They will
never
accept it as a mainstream. As well as Python people - they don't want
to see
the Lambda in the language any more. Van Rossum don't want to implement
an
efficient tail recursion, because "recursion is dangerous". This is the
trend - to simplify and dumbify everithing. Not towards the expressive
power...
> The generics feature was one small step in that
> direction. That said, if you were to say, "I don't think Java will
> ever develop a macro system to rival that of Lisp," I would probably
> agree with you. Without sexp syntax, it would be very difficult to
> do.
Jatha proved that it is possible (and easy). They definitely can
develop
such a thing. But they won't accept it, never... :(
> I could easily see it getting something of the C++ variety,
> however.
Even this (C++ or R5RS) kind of macro system is too complicated for a
halfbrained ones... :(
On 1 Mar 2005 03:12:30 -0800, ·······@gmail.com <·······@gmail.com> wrote:
> As well as Python people - they don't want
> to see
> the Lambda in the language any more. Van Rossum don't want to implement
> an
> efficient tail recursion, because "recursion is dangerous". This is the
> trend - to simplify and dumbify everithing. Not towards the expressive
> power...
>
For a discussion of this see:
http://lambda-the-ultimate.org/node/view/472
--
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
"John Thingstad" <··············@chello.no> writes:
> If you read the paragraph more carefully you will see
> that it is not Java that is the culprit.
> The *myth* is that joining all the code under one
> language makes it easier to understand and maintain
> It is the code you write in Java that determines this.
> If you try to *warp* code written in other languages
> to work in Java you could end up with something even more
> difficult to understand.
Well said, John.
To state this another way, think about code generators of any
sort. It's always easier to look at the top-level input language than
to look at the output. The output is functionally equivalent but lacks
the abstractions that the input language has. When you take something
from a highly abstracted language and stuff it into a language that
has poor support for abstraction (Java or anything without a
macro/metaprogramming system), you're forced to see all the ugly
implementation details, which then consequently overwhelm you with
complexity.
Put finally a third way: it's a bit like sausage. Just eat the final
product and don't spend time thinking about how it's made. ;-)
--
Dave Roberts
dave -remove- AT findinglisp DoT com
http://www.findinglisp.com/
A.L. wrote:
> On Tue, 22 Feb 2005 11:39:42 +0100, Edi Weitz <········@agharta.de>
> wrote:
>
>
>>On 22 Feb 2005 02:27:48 -0800, "lisplover" <·········@hotmail.com> wrote:
>>
>>
>>>If Lisp is so powerful.. <blech>
>>
>>Cool, we haven't had a troll for weeks. I wonder who is already
>>lining up to feed him... :)
>>
>
>
> Well... Some time ago I asked about constraint programming library
> in Lisp, similar in functionality to Java ILOG JSolver, Koalog or
> JCL (Java Constraint Library). Or, say, C++ ILOG Solver, or Prolog
> CLP(FD).
>
> I asked also about Lisp interfaces to popular OR solvers,
> specifically ILOG CPLEX and Dash XPRESS.
Never heard of them. Maybe because I don't do much OR?
> I was sent to obsolete and abandoned academic products and advised
> "Do it yourself".
>
> No, thanks, I will not do myself. I am not in the business of "doing
> it myself". Instead of Lisp, I am using Prolog that maybe is not
> that good and spohisticated as Lisp, but has all the libraries I
> need.
That's the point. If it has the libraries you need, then it solves your
problems.
> I will not even mention the "component market" - components that
> support COM interface and can do whatever I want to do.
Do they work on the Mac? Or Linux?
From GUI,
> through database access to various computations. There are about 25
> thousands of such components on the market. Purchasing components
> instead of doing yourself saves tons of monies and a lot of time.
>
> Of course, Lisp is not on this market. Lisp Is Better and doesn't
> need components. This market is for "trolls".
What you just described is something that works well under one specific
platform. The latest version (commercial) of LW and ACL play well with
COM components, and I have used the to do quite fancy things. Alas, it
is work that is not so useful for the Mac.
> Nice playing in your sandbox, guys... Have fun... And keep
> pretending that you don't see that the world doesn't care...
Why do you care then?
Cheers
--
Marco
"lisplover" <·········@hotmail.com> writes:
> If Lisp is so powerful as believed by many lisp lovers and advocates,
> why there are not enough lisp libraires around to compete with Java? If
Is it because there are not enough lisp libraires around to compete
with java that you came to me?
M-x Doctor
--
Lisp Propulsion Laboratory log - http://www.paoloamoroso.it/log
Recommended Common Lisp libraries/tools (see also http://clrfi.alu.org):
- ASDF/ASDF-INSTALL: system building/installation
- CL-PPCRE: regular expressions
- UFFI: Foreign Function Interface
It is the power of Lisp that make me come here. I read about Lisp at
Paul Graham's website. To be honest, I was really excited about the
ideas revealed in his articls about Lisp, especially the eval function.
Then I spent some time reading every kind of material I can get
relative to that topic, including the original papers by John McCarthy.
I almost finished reading Peter's Practical Common Lisp and it is well
written! I also read throught SICP. And I read some parts of On Lisp.
Then I begin to think seriously. Lisp is powerful and flexible, but is
it really appreciated in software development? While Java is less
powerful and flexible, I am quite sure whether I am writing good code
given that spcific situation. And I always can find some useful
libraries to do some work for me. I wrote code in C++ for sometime. The
memory management is really hard and error prone. And I simply don't
like the idea of template. But other language, such as Java and C#,
while they are not as powerful as Lisp, they provide GC, and a majority
of useful libraries. I can almost start doing useful stuff. Thus it
give less initiative to use Lisp for real projects. But the point is
that, while we are saying Lisp is powerful, what we are aiming at? Lisp
is isolated in a sense. I feel comfortable processing list inside Lisp
world. But what happends if I want to communicate with the outside
world for, say, TCP/IP, Multimedia, GUI, ,OpenGL, etc? I have to use
layers, such as uffi, to call functions writtend in other languages. I
feel this kind of unsmoothness is ugly, given such a elegant idear
originated in John McCarthy's LISP.
From: M Jared Finder
Subject: Re: why not enough lisp libraries?
Date:
Message-ID: <421d5fcf@x-privat.org>
lisplover wrote:
> It is the power of Lisp that make me come here. I read about Lisp at
> Paul Graham's website. To be honest, I was really excited about the
> ideas revealed in his articls about Lisp, especially the eval function.
> Then I spent some time reading every kind of material I can get
> relative to that topic, including the original papers by John McCarthy.
> I almost finished reading Peter's Practical Common Lisp and it is well
> written! I also read throught SICP. And I read some parts of On Lisp.
> Then I begin to think seriously. Lisp is powerful and flexible, but is
> it really appreciated in software development? While Java is less
> powerful and flexible, I am quite sure whether I am writing good code
> given that spcific situation.
Please show me good Java code for the following situation:
You have a physics simulation with four different types of objects --
a sphere, a cylinder, a cube, and a cone. Accuracy is your top
priority, so you want to handle each type of collision differently.
Additionally, it is likely that more objects will get added in the
future, so you want to minimize the amount of boiler plate code you have
to write per object type.
Using CLOS, this would be extremely easy, you'd just end up with
(defgeneric collide-objects (obj1 obj2))
(defmethod collide-objects ((obj1 sphere) (obj2 sphere))
code to collide two spheres)
(defmethod collide-objects ((obj1 sphere) (obj2 cylinder))
code to collide a sphere with a cylinder)
.
.
.
14 more methods
.
.
.
In fact, you could cut this in half by allowing the objects to be
specified in either order.
I do not believe a solution to this in Java exists, because Java does
not support multiple dispatch. This means that each solution is going
to involve tons of busywork. Or do you consider repetitious code to be
"good code"?
-- MJF
Of course there is a solution to this in every language, although not
similar to that in CLOS. for example, in C# by using reflection.
class Sphere
{
public void collide_with(Object obj1)
{
if(obj1.GetType() == typeof(Cube)
{
//collide with Cube;
}
}
}
class Cube
{
public void collide_with(Object obj1)
{
if(obj1.GetType() == typeof(Cube)
{
//collide with Cube;
}
}
}
class Engine
{
collide-objects(Object obj1, Object obj2)
{
obj1.collide_with(obj2);
}
}
Done. You may argue that I have to change the method in every class
once a new object is added. But in CLOS you also have to add n new
methods too. No big advantage over that in C#.
"lisplover" <·········@hotmail.com> writes:
> Of course there is a solution to this in every language, although not
> similar to that in CLOS. for example, in C# by using reflection.
>
> class Sphere
> {
> public void collide_with(Object obj1)
> {
> if(obj1.GetType() == typeof(Cube)
> {
> //collide with Cube;
> }
> }
> }
> class Cube
> {
> public void collide_with(Object obj1)
> {
> if(obj1.GetType() == typeof(Cube)
> {
> //collide with Cube;
> }
> }
>
> }
> class Engine
> {
> collide-objects(Object obj1, Object obj2)
> {
> obj1.collide_with(obj2);
> }
> }
> Done. You may argue that I have to change the method in every class
> once a new object is added. But in CLOS you also have to add n new
> methods too. No big advantage over that in C#.
Except in Common Lisp you can do it even if some of the classes you
care about are written by someone else and not modifyable by you.
-Peter
--
Peter Seibel ·····@gigamonkeys.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
Thanks for your reply! I have almost finished reading your Practical
Common Lisp and find it really inspiring! It is one of the best books
on Lisp I can get my hands on. And I totally agree that Lisp is
powerful. But I just suspect whether it lack some features that make it
unpopular. I love its syntax thus I don't think it is the problem. But
when I try to use OpenGL, I find it is not that straightforward as in
other languages, such as C/C++/C#/Java. I find it dismay to come across
one website on this topic that contains an expamle for bringing up a
window, drawing a retangle in it. Wow, is it what I will expect from
using Lisp?
To answer your question, the following is the solution even if some of
the classes are written by someone else and not modifyable by me.
For example, Sphere and Cube are not modifyable.
Class Engine
{
public void collide_with(Sphere sphere, Cube cube)
{
//collide sphere with cube
}
public void collide_with(Sphere sphere, Sphere sphere);
{
//collide sphere with sphere
}
public void collide_with(Cube cube, Sphere sphere)
{
//collide cube with spere
}
static void Main(string[] args)
{
Sphere sphere = new Sphere();
Cube cube = new Cube();
Engine eng = new Engine();
eng.collide_with(sphere,cube);
eng.collide_with(cube,sphere);
eng.collide_with(cube,cube);
}
}
>>>>> "ll" == lisplover <·········@hotmail.com> writes:
ll> ... I love its syntax
ll> thus I don't think it is the problem. But when I try to use
ll> OpenGL, I find it is not that straightforward as in other
ll> languages, such as C/C++/C#/Java.
I disagree. If anything, Lisp makes it easier to use OGL. For example,
why would you prefer:
gl_push_some_context(FOO|BAR); /* matrices, lights whatever */
gl_monkey_with_some_context(quux);
gl_begin(SOMETHING);
gl_bla(x,y,z);
...
gl_end(); /*matches begin something*/
gl_pop_context(); /*matches push something */
when you can just write some simple macros and do this:
(with-some-context-pushed (+foo+ +bar+)
(gl-monkey-with-some-context quux)
(doing +something+
(gl-bla x y z)
... ))
ll> I find it dismay to come
ll> across one website on this topic that contains an expamle for
ll> bringing up a window, drawing a retangle in it. Wow, is it
ll> what I will expect from using Lisp? [...]
http://cvs.sourceforge.net/viewcvs.py/cl-sdl/cl-sdl-timot/examples/
cheers,
BM
"lisplover" <·········@hotmail.com> writes:
> To answer your question, the following is the solution even if some of
> the classes are written by someone else and not modifyable by me.
> For example, Sphere and Cube are not modifyable.
>
> Class Engine
> {
> public void collide_with(Sphere sphere, Cube cube)
> {
> //collide sphere with cube
> }
> public void collide_with(Sphere sphere, Sphere sphere);
> {
> //collide sphere with sphere
> }
> public void collide_with(Cube cube, Sphere sphere)
> {
> //collide cube with spere
> }
> static void Main(string[] args)
> {
> Sphere sphere = new Sphere();
> Cube cube = new Cube();
> Engine eng = new Engine();
> eng.collide_with(sphere,cube);
> eng.collide_with(cube,sphere);
> eng.collide_with(cube,cube);
> }
> }
Overloading isn't a replacement for generic functions with multiple
dispatch methods. Your solution will not work in the presence of
subclasses and polimorphic variables. Imagine a subclass of Sphere
(let's call it Ellipsoid) and the corresponding method in your Engine
class:
public void collide_with(Ellipsoid ellipsoid, Cube cube) {
//collide ellipsoid with cube
}
Now, a variable of type Sphere can contain either instances of Sphere
or of subclasses of Sphere (such as Ellipsoid) so we can write:
Sphere sphere = new Sphere();
Sphere ellipsoid = new Ellipsoid(); //note the type of the variable
Cube cube = new Cube();
Engine eng = new Engine();
eng.collide_with(sphere, cube); //Ok
eng.collide_with(ellipsoid, cube); //will use the wrong method
Ant�nio Leit�o.
"lisplover" <·········@hotmail.com> writes:
> when I try to use OpenGL, I find it is not that straightforward as in
> other languages, such as C/C++/C#/Java.
I didn't find it all that straightforward in C++ with a window system
thrown in. It gets easier with some Lisp macrology and such thrown
in.
> To answer your question, the following is the solution even if some of
> the classes are written by someone else and not modifyable by me.
> For example, Sphere and Cube are not modifyable.
>
> Class Engine
> {
> public void collide_with(Sphere sphere, Cube cube)
> {
> //collide sphere with cube
> }
> public void collide_with(Sphere sphere, Sphere sphere);
> {
> //collide sphere with sphere
> }
> public void collide_with(Cube cube, Sphere sphere)
> {
> //collide cube with spere
> }
> static void Main(string[] args)
> {
> Sphere sphere = new Sphere();
> Cube cube = new Cube();
> Engine eng = new Engine();
> eng.collide_with(sphere,cube);
> eng.collide_with(cube,sphere);
> eng.collide_with(cube,cube);
> }
> }
I think you fell into a trap here. Once you add Blob, Jar, Bottle,
Glom, Froob, Torus, Widget, and Fish, Engine is going to get huge.
What you really want is to be able to ask an object if some point is
enclosed by it. Writing MxN methods could get painful.
CLOS is pretty powerful though. EQL method specialization has saved
me from having to write a butt load of fragile code for event handling
in a GUI. If I want to handle a new event, I just write a new
method. I don't have to touch any of the existing methods.
--
An ideal world is left as an excercise to the reader.
--- Paul Graham, On Lisp 8.1
From: M Jared Finder
Subject: Re: why not enough lisp libraries?
Date:
Message-ID: <421f5430@x-privat.org>
lisplover wrote:
> Thanks for your reply! I have almost finished reading your Practical
> Common Lisp and find it really inspiring! It is one of the best books
> on Lisp I can get my hands on. And I totally agree that Lisp is
> powerful. But I just suspect whether it lack some features that make it
> unpopular. I love its syntax thus I don't think it is the problem. But
> when I try to use OpenGL, I find it is not that straightforward as in
> other languages, such as C/C++/C#/Java. I find it dismay to come across
> one website on this topic that contains an expamle for bringing up a
> window, drawing a retangle in it. Wow, is it what I will expect from
> using Lisp?
>
> To answer your question, the following is the solution even if some of
> the classes are written by someone else and not modifyable by me.
> For example, Sphere and Cube are not modifyable.
>
> Class Engine
> {
> public void collide_with(Sphere sphere, Cube cube)
> {
> //collide sphere with cube
> }
> public void collide_with(Sphere sphere, Sphere sphere);
> {
> //collide sphere with sphere
> }
> public void collide_with(Cube cube, Sphere sphere)
> {
> //collide cube with spere
> }
> static void Main(string[] args)
> {
> Sphere sphere = new Sphere();
> Cube cube = new Cube();
> Engine eng = new Engine();
> eng.collide_with(sphere,cube);
> eng.collide_with(cube,sphere);
> eng.collide_with(cube,cube);
> }
> }
But this won't work if you are dealing with just ICollidable's (of which
Sphere and Cube both implement). You'll need to add type discovery code:
public static void collide_with( ICollidable obj1, ICollidable obj2 ) {
Class type1 == obj1.getClass();
Class type2 == obj2.getClass();
if( type1 == Sphere.TYPE && type2 == Sphere.TYPE ) {
collide_with( (Sphere)obj1, (Sphere)obj2 );
} else if( type1 == Sphere.TYPE && type2 == Cube.TYPE ) {
collide_with( (Sphere)obj1, (Cube)obj2 );
} else if( type1 == Cube.TYPE && type2 == Sphere.TYPE ) {
collide_with( (Cube)obj1, (Sphere)obj2 );
} else if( type1 == Cube.TYPE && type2 == Cube.TYPE ) {
collide_with( (Cube)obj1, (Cube)obj1 );
}
else {
throw new RuntimeException( "invalid types" );
}
}
Now try adding a few more types that can be collided, like Tetrahedron
and Teapot. Adding types to collide_with will quickly get extremely
tedious. And there's the assumption of a single level hierarchy here;
if there were subclasses of these types, the order of the checks would
become important.
-- MJF
M Jared Finder wrote:
> lisplover wrote:
>
>> Thanks for your reply! I have almost finished reading your Practical
>> Common Lisp and find it really inspiring! It is one of the best books
>> on Lisp I can get my hands on. And I totally agree that Lisp is
>> powerful. But I just suspect whether it lack some features that make it
>> unpopular. I love its syntax thus I don't think it is the problem. But
>> when I try to use OpenGL, I find it is not that straightforward as in
>> other languages, such as C/C++/C#/Java. I find it dismay to come across
>> one website on this topic that contains an expamle for bringing up a
>> window, drawing a retangle in it. Wow, is it what I will expect from
>> using Lisp?
>>
>> To answer your question, the following is the solution even if some of
>> the classes are written by someone else and not modifyable by me.
>> For example, Sphere and Cube are not modifyable.
>>
>> Class Engine
>> {
>> public void collide_with(Sphere sphere, Cube cube)
>> {
>> //collide sphere with cube
>> }
>> public void collide_with(Sphere sphere, Sphere sphere);
>> {
>> //collide sphere with sphere
>> }
>> public void collide_with(Cube cube, Sphere sphere)
>> {
>> //collide cube with spere
>> }
>> static void Main(string[] args)
>> {
>> Sphere sphere = new Sphere();
>> Cube cube = new Cube();
>> Engine eng = new Engine();
>> eng.collide_with(sphere,cube);
>> eng.collide_with(cube,sphere);
>> eng.collide_with(cube,cube);
>> }
>> }
>
>
> But this won't work if you are dealing with just ICollidable's (of which
> Sphere and Cube both implement). You'll need to add type discovery code:
>
> public static void collide_with( ICollidable obj1, ICollidable obj2 ) {
> Class type1 == obj1.getClass();
> Class type2 == obj2.getClass();
>
> if( type1 == Sphere.TYPE && type2 == Sphere.TYPE ) {
> collide_with( (Sphere)obj1, (Sphere)obj2 );
> } else if( type1 == Sphere.TYPE && type2 == Cube.TYPE ) {
> collide_with( (Sphere)obj1, (Cube)obj2 );
>
> } else if( type1 == Cube.TYPE && type2 == Sphere.TYPE ) {
> collide_with( (Cube)obj1, (Sphere)obj2 );
> } else if( type1 == Cube.TYPE && type2 == Cube.TYPE ) {
> collide_with( (Cube)obj1, (Cube)obj1 );
> }
>
> else {
> throw new RuntimeException( "invalid types" );
> }
> }
>
> Now try adding a few more types that can be collided, like Tetrahedron
> and Teapot. Adding types to collide_with will quickly get extremely
> tedious. And there's the assumption of a single level hierarchy here;
> if there were subclasses of these types, the order of the checks would
> become important.
>
> -- MJF
(defmethod collide-2 ((o1 sphere) (o2 sphere)) ...)
(defmethod collide-2 ((o1 sphere) (o2 cube)) ...)
(defmethod collide-2 ((o1 cube) (o2 sphere)) ...)
(defmethod collide-2 ((o1 cube) (o2 cube)) ...)
(defmethod collide-2 ((o1 cube) (o2 tetrahedron)) ...)
(defmethod collide-3 ((o1 sphere) (o2 sphere) (o3 sphere)) ...)
(defmethod collide-3 ((o1 sphere) (o2 cube) (o3 sphere)) ...)
(defmethod collide-3 ((o1 sphere) (o2 cube) (o3 cube)) ...)
(defmethod collide-3 ((o1 sphere) (o2 cube) (o3 tetrahedron)) ...)
Writing COLLIDE-4 is left as an exercise to the reader.
As for generating all of these automatically, we can go the obvious way
(defmacro defmethod-c (name args &body forms)
`(progn ,@(loop ap in (permute-args args)
collect (list* 'defmethod name ap forms))))
where DEFMETHOD-C is a limited form of DEFMETHOD that just expannd in
the permutation of the arguments.
Other ways of doing this effect are also left as an exercise to the reader.
Achieving this in any of the other INTERCAL-family languages is marked
as a "term project". Yes. You can use Python in the process.
Cheers
--
Marco
Peter Seibel <·····@gigamonkeys.com> writes:
> Except in Common Lisp you can do it even if some of the classes you
> care about are written by someone else and not modifyable by you.
This is one of the neatest aspects (if you'll pardon the slight pun)
of CLOS. At first, generic functions seemed quite strange to me,
coming from a OOP == message passing sort of background. Now, I find
myself wondering how I could have lived without them.
--
Dave Roberts
dave -remove- AT findinglisp DoT com
http://www.findinglisp.com/
Quick: do it with three objects now of four types.
Cheers
--
Marco
lisplover wrote:
> Of course there is a solution to this in every language, although not
> similar to that in CLOS. for example, in C# by using reflection.
>
> class Sphere
> {
> public void collide_with(Object obj1)
> {
> if(obj1.GetType() == typeof(Cube)
> {
> //collide with Cube;
> }
> }
> }
> class Cube
> {
> public void collide_with(Object obj1)
> {
> if(obj1.GetType() == typeof(Cube)
> {
> //collide with Cube;
> }
> }
>
> }
> class Engine
> {
> collide-objects(Object obj1, Object obj2)
> {
> obj1.collide_with(obj2);
> }
> }
> Done. You may argue that I have to change the method in every class
> once a new object is added. But in CLOS you also have to add n new
> methods too. No big advantage over that in C#.
>
>>>>> "Marco" == Marco Antoniotti <·······@cs.nyu.edu> writes:
Marco> Quick: do it with three objects now of four types.
Marco> Cheers
Easy. Just write a small Python script (or Lisp, or Perl, ...) that
generates the code; put that into your build process and you are done.
A scripting language and Ant are often a substitute for a macro system.
:-)
Holger
Marco> lisplover wrote:
[... longish listing truncated ...]
Holger Duerer wrote:
>>>>>>"Marco" == Marco Antoniotti <·······@cs.nyu.edu> writes:
>
>
> Marco> Quick: do it with three objects now of four types.
> Marco> Cheers
>
> Easy. Just write a small Python script (or Lisp, or Perl, ...) that
> generates the code; put that into your build process and you are done.
> A scripting language and Ant are often a substitute for a macro system.
>
> :-)
>
Your solution does not involve any INTERCAL, hence it is wrong.
Why don't you try a CL solution just for fun? :)
Cheers
--
marco
lisplover wrote:
> like the idea of template. But other language, such as Java and C#,
> while they are not as powerful as Lisp, they provide GC, and a majority
> of useful libraries. I can almost start doing useful stuff.
But isn't it often tedious to write lots of code by hand? Anyway, that
and the lack of powerful control structures is why I don't like C dialects.
> world. But what happends if I want to communicate with the outside
> world for, say, TCP/IP, Multimedia, GUI, ,OpenGL, etc? I have to use
> layers, such as uffi, to call functions writtend in other languages. I
> feel this kind of unsmoothness is ugly, given such a elegant idear
> originated in John McCarthy's LISP.
Right, you use a library, be it a C library that's wrapped up in Lisp.
In the end, it's the same as using a library in Java. Some of those
(the java.lang and java.awt ones definitely) are even implemented in C
in the VM.
I'm new to CL, so I don't know just how bad foreign function bindings
are, but it would certainly be possible to hide a hideous C API behind a
nice Lisp interface.
lisplover wrote:
> It is the power of Lisp that make me come here. I read about Lisp at
> Paul Graham's website. To be honest, I was really excited about the
> ideas revealed in his articls about Lisp, especially the eval
function.
> Then I spent some time reading every kind of material I can get
> relative to that topic, including the original papers by John
McCarthy.
> I almost finished reading Peter's Practical Common Lisp and it is
well
> written! I also read throught SICP. And I read some parts of On Lisp.
You'd better spend the same time really coding in Lisp. Doing your
average job with Lisp.
> Then I begin to think seriously. Lisp is powerful and flexible, but
is
> it really appreciated in software development? While Java is less
> powerful and flexible, I am quite sure whether I am writing good code
> given that spcific situation. And I always can find some useful
> libraries to do some work for me.
No, you can not. As for me, I can't find a Java libraries for even the
simplest tasks. Tons of useless code only!
> I wrote code in C++ for sometime. The
> memory management is really hard and error prone. And I simply don't
> like the idea of template.
Idea is not so bad. C++ implementation of this idea just sucks.
> But other language, such as Java and C#,
> while they are not as powerful as Lisp, they provide GC, and a
majority
> of useful libraries. I can almost start doing useful stuff. Thus it
> give less initiative to use Lisp for real projects. But the point is
> that, while we are saying Lisp is powerful, what we are aiming at?
Lisp
> is isolated in a sense. I feel comfortable processing list inside
Lisp
> world. But what happends if I want to communicate with the outside
> world for, say, TCP/IP, Multimedia, GUI, ,OpenGL, etc? I have to use
> layers, such as uffi, to call functions writtend in other languages.
I
> feel this kind of unsmoothness is ugly, given such a elegant idear
> originated in John McCarthy's LISP.
Why do you want to use one single language for everything? There is no
silver bullet. You need dozens of different languages to code
efficiently -
for any simple task - special language. Lisp can mimic another
languages -
that's why it's a bit more powerfull then other average "generic"
languages.
But even Lisp is not generic enough.
GENERIC languages does not exist at all!!!!
On 24 Feb 2005 06:47:46 -0800, ········@gmail.com" <·······@gmail.com>
wrote:
>
> No, you can not. As for me, I can't find a Java libraries for even the
>simplest tasks. Tons of useless code only!
What "tasks" you have in mind? Do you know easy way to access from
Lisp CPLEX linear programming solver from ILOG?... They DO provide
Java interface.
A.L.
A.L. wrote:
> What "tasks" you have in mind? Do you know easy way to access from
> Lisp CPLEX linear programming solver from ILOG?... They DO provide
> Java interface.
>
Sure, use ABCL, and you can use every Java library you feel like.
HTH, HAND.
I do not wish to take part in the general discussion, but I can point
you to CPLEX-glue, an interface to the ILOG CPLEX Callable Library;
see
http://www.math.uni-magdeburg.de/~mkoeppe/primaldual/index.html
It supports Guile Scheme and Allegro Common Lisp (using SWIG). The
Allegro CL bindings are not complete, however; we are extending it
whenever necessary for our work.
--
Matthias Koeppe -- http://www.math.uni-magdeburg.de/~mkoeppe
On Fri, 25 Feb 2005 11:20:07 +0100, Matthias Koeppe
<·······@mail.math.uni-magdeburg.de> wrote:
>I do not wish to take part in the general discussion, but I can point
>you to CPLEX-glue, an interface to the ILOG CPLEX Callable Library;
>see
> http://www.math.uni-magdeburg.de/~mkoeppe/primaldual/index.html
>
>It supports Guile Scheme and Allegro Common Lisp (using SWIG). The
>Allegro CL bindings are not complete, however; we are extending it
>whenever necessary for our work.
Great! Thanks for the pointer!
A.L.
"lisplover" <·········@hotmail.com> writes:
> But what happends if I want to communicate with the outside world
> for, say, TCP/IP, Multimedia, GUI, ,OpenGL, etc? I have to use
> layers, such as uffi, to call functions writtend in other
> languages. I feel this kind of unsmoothness is ugly, given such a
> elegant idear originated in John McCarthy's LISP.
What do the Perl, Python, Tcl, etc programmers do? I suspect they
have to link to code written in other languages. Ok, Perl has TCP/IP
built in. But that is built directly on C code.
I'm sure things have improved, but the last time I saw Java doing 3D
graphics, it was slooooooooow. Using FFI to access OpenGL does work,
can be abstracted to look smooth, and can be fast.
As for GUI, I am not too displeased with the code I have to access
Carbon's API. It certainly isn't as ugly as C++ code would be.
--
An ideal world is left as an excercise to the reader.
--- Paul Graham, On Lisp 8.1
On 22 Feb 2005 02:27:48 -0800, "lisplover" <·········@hotmail.com>
wrote:
>If Lisp is so powerful as believed by many lisp lovers and advocates,
>why there are not enough lisp libraires around to compete with Java?
Not so many. Just few. Count the guys posting to this group. This is
about so called "Lisp community".
Lisp Is Better and doesn't need any libraries.
A.L.
"A.L." schrieb:
> On 22 Feb 2005 02:27:48 -0800, "lisplover" <·········@hotmail.com>
> wrote:
> >If Lisp is so powerful as believed by many lisp lovers and advocates,
> >why there are not enough lisp libraires around to compete with Java?
> Not so many. Just few. Count the guys posting to this group. This is
> about so called "Lisp community".
> Lisp Is Better and doesn't need any libraries.
... and Lisp is different. I typed: DIFFERENT. (yes different).
stefan
> If Lisp is so powerful as believed by many lisp lovers and advocates,
> why there are not enough lisp libraires around to compete with Java?
Lisp has few libraries because it is powerful. A library bound to a
language is a sign that the language is weak in some respect, and makes
certain things too difficult for a programmer. In lisp, everything is
easy if your objective is working software.
David
·············@gmail.com" <············@gmail.com> writes:
> > If Lisp is so powerful as believed by many lisp lovers and advocates,
> > why there are not enough lisp libraires around to compete with Java?
>
> Lisp has few libraries because it is powerful. A library bound to a
> language is a sign that the language is weak in some respect, and makes
> certain things too difficult for a programmer. In lisp, everything is
> easy if your objective is working software.
I'm on the Lisp side of this debate, but this sounds like a hand-wave
to me.
Frankly, the core of the CLHS that defines the key structure and
behavior of Lisp is actually pretty small (things like the reader,
EVAL/APPLY, etc.). Most of CLHS *is* library, though we probably don't
think about it that way.
So I think this falls flat on the face of it.
--
Dave Roberts
dave -remove- AT findinglisp DoT com
http://www.findinglisp.com/
> Frankly, the core of the CLHS that defines the key structure and
> behavior of Lisp is actually pretty small (things like the reader,
> EVAL/APPLY, etc.). Most of CLHS *is* library, though we probably
don't
> think about it that way.
And CLHS is a tiny library, compared to the standard Java classes. It
is because you don't have to spend enormous efforts on coding
everything around once foreover. It is easy to code again, when the
need arises, with variations appropriate for each particular case.
David
Dave Roberts wrote:
> ·············@gmail.com" <············@gmail.com> writes:
>
>> > If Lisp is so powerful as believed by many lisp lovers and advocates,
>> > why there are not enough lisp libraires around to compete with Java?
>>
>> Lisp has few libraries because it is powerful. A library bound to a
>> language is a sign that the language is weak in some respect, and makes
>> certain things too difficult for a programmer. In lisp, everything is
>> easy if your objective is working software.
>
> I'm on the Lisp side of this debate, but this sounds like a hand-wave
> to me.
>
> Frankly, the core of the CLHS that defines the key structure and
> behavior of Lisp is actually pretty small (things like the reader,
> EVAL/APPLY, etc.). Most of CLHS *is* library, though we probably don't
> think about it that way.
>
> So I think this falls flat on the face of it.
>
One might even say he got it backwards.
To me, the power of a language isn't measured by how the size of the
libraries - it's measured by how many ways of programming can be worked
into a library without changing the language itself.
For example, CLOS is (or was, anyway; I suspect most modern systems have
compiler support for optimization) a library, and many other fatures that
(in other languages) would be part of the core are as well, which is
largely a testament to the power of macros.
It's a simple equation; language users can write libraries, they can't
change the language itself. Language designers aren't omniscient, so the
more of a language than can be written as a library, the better its
future-proofing.
Svein Ove Aas schrieb:
> Dave Roberts wrote:
[snip important text]
When there is only one way to climb up the mountain, than ok, you can
write a library for stituation one (sunshine weather), for situation two
(ice-wind storms), for situation three (slippery rocks) for ... So
different skilled climbers will make different use of that.
When there are two ways to climb up the mountain, then ok, you can write
duple as much libraries. Just fine to keep you busy and maybe one needs
it to reach the top.
When there are three ways to climb up a mountain, well, you can find out
a very common library for common use on three ways. Maybe you still keep
yourself bussy. Maybe you think about the climbing itself?
When you can climb up the mountain from every side you want, what in the
wourld should a library include? Say where the top is? Or describe how
to use a rope?
The more libraries there are, the more the language is dead. At last you
have more libs than apps. This is a bit like more developers in the
second row than in the first place.
So what is it good for? Do anyone think a library developer can overcome
a language designer? Or is development of a language done inside a
library? Maybe libs are good for finding some ideas for people who
dont't know what they want? (ie: lets see what we have to say what we
can get)
There is an importand detail, seem to be necessary to repeat: Lisp is
different from all the rest of languages. Please note that. This way one
can't compare Lisp with any other programming language. Saying
x-language has that or other parts is generally a bad thing. (best cases
may end in a copyshop for strategies, see gc-talks)
Else, when one wants to write a library (seems there are some), that one
may choose a language which needs that kind of support, otherwise write
a tool (ohweia).
stefan
ps.:
isn't it boring to always have the same table then a neighbor has?
> If Lisp is so powerful as believed by many lisp lovers and advocates,
> why there are not enough lisp libraires around to compete with Java?
Lisp has few libraries because it is powerful. A library bound to a
language is a sign that the language is weak in some respect, and makes
certain things too difficult for a programmer. In lisp, everything is
easy if your objective is working software.
David