Lisp for enterprise computing?
Harry
I have heard some say on the Net that Lisp-based development is fast
as well as intellectually very elegant and fulfilling. That Lisp is
"the programmable programming language"... All this is certainly very
encouraging; I tend to even believe all this, esp after reading Paul
Graham's success story and a few articles here and there. However,
since it may be a while before I know Lisp enough to be able to find
my own answers, (just got my copies of Ansi Common Lisp and Practical
Common Lisp) could some of you fine Lispers share your insights on the
following in the meantime?
1. How could Lisp be exploited in building enterprise applications
(versus going the J2EE or .NET route)? In Web tier and in Biz Logic
tier?
2. While I (am not afraid to and in fact) love writing code from
scratch if needed (and if permitted), what community support (in the
form of free/opensource libraries/packages similar to Perl CPAN and
various Java/C/C++ sites) is available for Lisp?
3. Could folks who have tried both J2EE and Lisp for enterprise
computing share their experiences and insights?
4. How much of a pure functional style of programming (with no setf's)
could be used in building a non-trivial enterprise application? I'm
coming from primarily an imperative programming background (Java/C/C+
+) and am wondering how could one possibly write a nontrivial/large
application without side-effects!
5. What arguments could I give to my mgt (of primarily a J2EE shop) to
give Lisp a small and cautious try?
Many thanks in advance,
/HS
Pascal J. Bourguignon
> Hello,
>
> I have heard some say on the Net that Lisp-based development is fast
> as well as intellectually very elegant and fulfilling. That Lisp is
> "the programmable programming language"... All this is certainly very
> encouraging; I tend to even believe all this, esp after reading Paul
> Graham's success story and a few articles here and there. However,
> since it may be a while before I know Lisp enough to be able to find
> my own answers, (just got my copies of Ansi Common Lisp and Practical
> Common Lisp) could some of you fine Lispers share your insights on the
> following in the meantime?
>
> 1. How could Lisp be exploited in building enterprise applications
> (versus going the J2EE or .NET route)? In Web tier and in Biz Logic
> tier?
Yes.
> 2. While I (am not afraid to and in fact) love writing code from
> scratch if needed (and if permitted), what community support (in the
> form of free/opensource libraries/packages similar to Perl CPAN and
> various Java/C/C++ sites) is available for Lisp?
See:
http://cliki.net/
http://common-lisp.net/
http://www.cl-user.net/asp/root-dir
> 3. Could folks who have tried both J2EE and Lisp for enterprise
> computing share their experiences and insights?
I've not tried J2EE.
> 4. How much of a pure functional style of programming (with no setf's)
> could be used in building a non-trivial enterprise application? I'm
> coming from primarily an imperative programming background (Java/C/C+
> +) and am wondering how could one possibly write a nontrivial/large
> application without side-effects!
A very big lot. Of course, it would be silly to try to implement 100%
of your code in a purely functional way, but a lot of internal and
library code can be written this way, with big profits in debugging
time and integration time.
> 5. What arguments could I give to my mgt (of primarily a J2EE shop) to
> give Lisp a small and cautious try?
This is hard to say.
To switch over, you'd basically have to fire all the java monkeys^W
coders and hire one tenth or one fiftieth of CL programmers. Paying
the CL coders three or four times a java m^coder, you'd divide the
salary mass by anything between 3 and 12. If you'd rewrite all the
code base you'd reduce it to one hundredth at least (that means, you'd
divide the number of bugs by at least one hundred).
But doing just one small a cautious step, it'd be less obvious.
--
__Pascal Bourguignon__
Ken Tilton
Harry wrote:
> Hello,
>
> I have heard some say on the Net that Lisp-based development is fast
> as well as intellectually very elegant and fulfilling. That Lisp is
> "the programmable programming language"... All this is certainly very
> encouraging; I tend to even believe all this, esp after reading Paul
> Graham's success story and a few articles here and there. However,
> since it may be a while before I know Lisp enough to be able to find
> my own answers, (just got my copies of Ansi Common Lisp and Practical
> Common Lisp) could some of you fine Lispers share your insights on the
> following in the meantime?
>
> 1. How could Lisp be exploited in building enterprise applications
> (versus going the J2EE or .NET route)? In Web tier and in Biz Logic
> tier?
http://smuglispweeny.blogspot.com/2008/03/my-biggest-lisp-project.html
I do not know anything about tiers or j2ee, I was lucky enough to miss
all that.
>
> 2. While I (am not afraid to and in fact) love writing code from
> scratch if needed (and if permitted), what community support (in the
> form of free/opensource libraries/packages similar to Perl CPAN and
> various Java/C/C++ sites) is available for Lisp?
Anything in C, and if you are all enterprise-y and everything and use
Franz I hear they have a Java FFI.
>
> 3. Could folks who have tried both J2EE and Lisp for enterprise
> computing share their experiences and insights?
>
> 4. How much of a pure functional style of programming (with no setf's)
> could be used in building a non-trivial enterprise application? I'm
> coming from primarily an imperative programming background (Java/C/C+
> +) and am wondering how could one possibly write a nontrivial/large
> application without side-effects!
CL is a multi-paradigm language. The pure FP nutjobs will try to sell
you on monads. No, that is not a joke.
>
> 5. What arguments could I give to my mgt (of primarily a J2EE shop) to
> give Lisp a small and cautious try?
Point out to them that it will be small and cautious. This will confuse
them long enough for you to finish the experiment.
What I did was not tell the boss until the experiment was succeeded.
Most bosses appreciate not having to decide these things.
hth, kenny
--
http://smuglispweeny.blogspot.com/
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
Slark
I agree - if you have the flexibility to do that, or are motivated
enough to do it at home, then that's the best way. Asking to do an
experiment may simply confuse and raise abstract objections - showing a
result misses all that bit out...
Graham
Ken Tilton
And if the OP *really* wants to get early buy-in from management they
can point out the trend implicit in Perl/Python/Ruby towards agile
dynamic languages actually points at CL which has the advantage of being
mature, compiled, and standardized.
Then have a beerfest where everyone takes turns reading aloud from:
http://wiki.alu.org/RtL_Highlight_Film
Brian Adkins
> 5. What arguments could I give to my mgt (of primarily a J2EE shop) to
> give Lisp a small and cautious try?
If your 'management' is sold on J2EE, then convincing them to use Lisp
is the least of your troubles.
attila....@gmail.com
> (versus going the J2EE or .NET route)? In Web tier and in Biz Logic
> tier?
you can probably follow most of this without much lisp knowledge:
http://common-lisp.net/project/cl-perec/shop.html
this is what hibernate does for java, but as a co-author i'm not in
the position of sharing my opinion on how they compare to each
other... :)
> 3. Could folks who have tried both J2EE and Lisp for enterprise
> computing share their experiences and insights?
j2ee is a goddamn bullshit. take a static language without syntactic
abstractions, write a lot of code that is supposed to glue together
easily to form actual applications, realized that it doesn't, and then
bring in XML to the rescue... should i continue? i've spent 3-4 years
fighting that shit before i quit to work as a full-time lisp
freelancer.
> 4. How much of a pure functional style of programming (with no setf's)
> could be used in building a non-trivial enterprise application? I'm
> coming from primarily an imperative programming background (Java/C/C+
> +) and am wondering how could one possibly write a nontrivial/large
> application without side-effects!
the point is to minimize sideeffects, not to live without them. where
you have no sideeffects you can have lazy evaluation (not with stock
CL, though) and testing functional code is much simpler.
> 5. What arguments could I give to my mgt (of primarily a J2EE shop) to
> give Lisp a small and cautious try?
been there, done that. the most you can get out of it is that you'll
be the black sheep of the company. or, if memory serves well, you
"start your own f*ing company!"... :D
- attila
Vagif Verdi
> 5. What arguments could I give to my mgt (of primarily a J2EE shop) to
> give Lisp a small and cautious try?
I'm using lisp (sbcl) myself after years of J2EE and MS (COM, ASP,
dotnet) development.
So if you can use common lisp.
If you can't for some reason (management is against) then you can use
Clojure http://clojure.sourceforge.net/
It is a lisp like (not CL and not scheme) language on JVM, that comes
in a normal java jar, and can be dropped into your J2EE application.
They even have a servlet to run in tomcat, Jetty or any other
compliant J2EE application server: http://code.google.com/p/webjure/
Scott Burson
> 4. How much of a pure functional style of programming (with no setf's)
> could be used in building a non-trivial enterprise application? I'm
> coming from primarily an imperative programming background (Java/C/C+
> +) and am wondering how could one possibly write a nontrivial/large
> application without side-effects!
I think I work harder than the vast majority of Lisp programmers at
using a functional style whenever it makes sense, but I've never tried
to write an entire application without side effects, nor would I
recommend such an undertaking to someone in your situation. (As a
research exercise it might be interesting, but you need to write code
that your colleagues could have some hope of maintaining.)
I will, however, take the opportunity to recommend FSet, my functional
collections package for Common Lisp:
http://common-lisp.net/project/fset/
Well, I'm not saying you should try to use FSet from the beginning.
First you need to learn to use lists in a functional way. But as you
write Lisp applications, sooner or later you will come to a point
where some part of your code is using lists that are getting too long
to be efficient (since, for instance, finding something in a list
requires a linear search). At that point you might consider
substituting an FSet type for the long list. (Lisp also offers
vectors and hash tables, but these are imperative types.)
Of course, this would be easier if I had gotten around to writing any
tutorial material for FSet, which I have not :(
-- Scott
kod...@eurogaran.com
> scratch if needed (and if permitted), what community support (in the
> form of free/opensource libraries/packages similar to Perl CPAN and
> various Java/C/C++ sites) is available for Lisp?
>
Any programming language is a human language, therefore shaped by its
community.
When you choose a language, you choose a community.
Lisp is very good technically but has a very bad community spirit. Be
warned. Bad vibrations float all around since it was born, with
Greenblatt and the people from LMI hating Knight and Symbolics,
Raymond hating Gabriel, and everyone hating and being hated by
Stallman. The examples could go on and on...
This translates most notably in the lack of a CLAN site comparable to
CPAN.
We are building now a renewed community which tries to overcome such
bad habits. Be welcome to join efforts.
Edi Weitz
> We are building now a renewed community which tries to overcome such
> bad habits.
Really? Ugh, seems I didn't get the memo again.
Edi.
--
European Common Lisp Meeting, Amsterdam, April 19/20, 2008
Real email: (replace (subseq "spam...@agharta.de" 5) "edi")
jayessay
Well, with that attitude, it looks like you're off to a fairly poor
start and you have a long way to go...
/Jon
--
'j' - a n t h o n y at romeo/charley/november com
kod...@eurogaran.com
> start and you have a long way to go...
it looks like WE're off to a fairly poor
start and WE have a long way to go...
Ken Tilton
I had you all lined for the killfile when I realized there is no way I
can miss out on stuff this funny.
You might keep an eye out for the hounds, tho, they need exercise...
John Thingstad
Who's WE?
--------------
John Thingstad
Thomas F. Burdick
> På Tue, 18 Mar 2008 13:54:02 +0100, skrev <kodi...@eurogaran.com>:
>
> >> Well, with that attitude, it looks like you're off to a fairly poor
> >> start and you have a long way to go...
>
> > it looks like WE're off to a fairly poor
> > start and WE have a long way to go...
>
> Who's WE?
Maybe it's another poor attempt to nominate Dr WEITZ Edi as Open
Source Slave^[^HDictator?
kod...@eurogaran.com
> > start and WE have a long way to go...
>
> Who's WE?
time...;)
Now seriously. My points are:
1- Technical considerations are less important than sociological
factors
in choosing a programming language.
2- A history of past confrontations has determined for Lisp a gloom
present.
3- Lisp renaissance is due more to gradual replacement of its
community members than it is due to a true revival in interest (which
does also exist).
4- I wanted to cause anger and dispute, because it is not possible to
correct a defect you cannot see.
wvan....@gmail.com
> We are building now a renewed community which tries to overcome
> such bad habits. Be welcome to join efforts.
Are you? Like Edi, I missed that one as well.
Lispers do come together and in good spirits. Visit European Common
Lisp Meetings organized by Edi and Arthur Lemmens, or visit
International Lisp Conferences organized by the Association of Lisp
Users (ALU).
Ernst van Waning,
ALU
(concatenate 'string (reverse "@wve") (reverse "ln.scirtemofni"))
Lars Rune Nøstdal
>
> Any programming language is a human language, therefore shaped by its
> community.
> When you choose a language, you choose a community. Lisp is very good
> technically but has a very bad community spirit.
..hum..
I like #lisp, Planet Lisp and comp.lang.lisp.
For technical communities I prefer those that say things exactly like
they are instead of complicating things by "being nice".
If I want people that are "nice to me" I'll talk to salespeople instead
of tech-people. Then I'll start "hating" and being miserable when I come
home - instead of "hating" (or caring?) up-front, when I had the ability
to do something about the situation and my future.
In 2001 I gave up everything related to computers and programming, but
then I rediscovered my initial interest through GNU/Linux and Lisp and
their communities. All four of them are good and I don't want them to
change, and they won't.
--
Lars Rune Nøstdal
http://nostdal.org/
kod...@eurogaran.com
> Lisp Meetings organized by Edi and Arthur Lemmens, or visit
> International Lisp Conferences organized by the Association of Lisp
> Users (ALU
Note how you carefully omit the
1st European Lisp Symposium
Bordeaux, France, May 22-23, 2008
LaBRI, Université Bordeaux
kod...@eurogaran.com
> they are instead of complicating things by "being nice".
>
> If I want people that are "nice to me" I'll talk to salespeople instead
> of tech-people. Then I'll start "hating" and being miserable when I come
> home - instead of "hating" (or caring?) up-front, when I had the ability
> to do something about the situation and my future.
>
I understand and fully share your view. My criticism was for the Lisp
community not "being collaborative", rather than not "being nice".
> In 2001 I gave up everything related to computers and programming, but
> then I rediscovered my initial interest through GNU/Linux and Lisp and
> their communities. All four of them are good and I don't want them to
> change, and they won't.
>
They will.
It is interesting to compare both communities (Linux and Lisp). Unix
people have gathered now around Linux and seem to be much more
collaborative (which doesn't mean less rude). My impression is that
there, too, a generational replacement has happened.
Pascal Costanza
>>> it looks like WE're off to a fairly poor
>>> start and WE have a long way to go...
>> Who's WE?
> The big question humanity has been asking itself from the beginning of
> time...;)
>
> Now seriously. My points are:
> 1- Technical considerations are less important than sociological
> factors in choosing a programming language.
There are already enough languages out there where the sociological
considerations are more important than the technical ones. It's good
that there are also a few languages where this is the other way around,
for people who are actually looking for technically driven design decisions.
> 2- A history of past confrontations has determined for Lisp a gloom
> present.
That's also part of the reason why discussions in the Lisp community are
sometimes so heated: People are interested in getting things "right",
and there are different and sometimes conflicting ideas what is "right"
and what is "wrong." These ideas need to be discussed.
Pascal
--
1st European Lisp Symposium (ELS'08)
http://prog.vub.ac.be/~pcostanza/els08/
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
jayessay
> > > it looks like WE're off to a fairly poor
> > > start and WE have a long way to go...
> >
> > Who's WE?
> The big question humanity has been asking itself from the beginning of
> time...;)
>
> 4- I wanted to cause anger and dispute, because it is not possible to
> correct a defect you cannot see.
So, in your mind inciting anger and dispute within a community is a
productive and effective means of bringing said community together?
That's certainly different, but I'm not sure how much success you will
have...
wvan....@gmail.com
Yes, a bit careless of me but I wrote spontaneously. Good that you
mention it.
Ernst
gavino
wrote:
holy crap! the gains would be that staggering? WOA! I smell startup
company. WOW one more BIG question: would you liek Mr Graham throw
out the use of a relational db?
tim
> We are building now a renewed community which tries to overcome such
> bad habits. Be welcome to join efforts.
One reason for the lack of libraries in Lisp is that they are not needed
so much. For example, I wrote a replacement for FLex in about 1,500 lines
of code. There are a couple of features of FLex that are missing but on the
other hand it has some features that FLex lacks (like easy extension to
support Unicode).
If I had to do that in C, it would be about 15,000 lines of code.
There are several other cases in my project where a few hundred lines of
code was all that was needed to replace a package that was thousands or
even tens of thousands of lines of code.
I am still a relative beginner with Lisp and I think there are a lot of
untapped opportunities to write software more efficiently.
Tim
Harry
Tim, I'm very surprised to learn that! Would you consider sharing the
source code with me/the community? It will be equally fine if you
could at least describe, for newbies like myself, as to what exactly
allowed you to achieve a factor of 10 compared to C... heavily macro-
based code, or just 'regular' Lisp constructs??
/HS
tim
>> I am still a relative beginner with Lisp and I think there are a lot of
>> untapped opportunities to write software more efficiently.
>>
>> Tim
>
> Tim, I'm very surprised to learn that! Would you consider sharing the
> source code with me/the community? It will be equally fine if you
> could at least describe, for newbies like myself, as to what exactly
> allowed you to achieve a factor of 10 compared to C... heavily macro-
> based code, or just 'regular' Lisp constructs??
>
> /HS
The project is at http://cobolforgcc.sourceforge.net. Ignore the web page
blurbs which refer to the original C version, and go browse the source
code using the CVS browse facility. This is about a month out of date as I
have been working on a big set of changes which would be done in a week or
so.
Caveat: as I said I am a beginner and a lot of the early code in
particular is not that flash and I would not necessarily recommend the
code as a good example.
At an appropriate time I will be soliciting comments from lisp people
about the code, but at the moment I have not documented the code and
cleaned it up so a lot of complaints would be redundant.
The main factors that seem to allow fewer lines of code in Lisp are
1. Use of macros to avoid repeated use of verbose boilerplate code. A
simple example: following nested structures that may contain nil/null
pointers. I defined an anaphoric macro FOLL which follows the links but
stops when it hits a nil value. This turns
(if item
(let ((x (field item)))
(if x (let ((y (field2 x)))
(if y (let ((z (field3 y))))
(actually-do-useful-stuff z)))))
into
(foll ((item (field it) (field2 it) (field3 it) (useful-stuff it))))).
2. Code as data allows you to easily process code as data! For example, in
the C version I used a package that allowed you to define a list of
attributes and then use those attributes as input to various skeletons. I
used this in for tokens which were then inserted into the grammar, various
token tables etc. In lisp this is so easy to do because you just define
the attributes as a list and output various processed forms of the list.
There is no need to to lexical analysis or parsing which saves a lot of
code. In the CVS version I do this using code generation but I have now
converted this mostly to macros. I should be uploading this in the next
week or so. Because I wrote this myself it does exactly what I want it to
do.
I decided to use the bison parser generator and tack on a lisp skeleton.
Ultimately I found that this took almost as much code as writing it
myself from scratch would have done. Partly this is due to having to work
within the bison framework - for example the skeletons are written using
M4. If anything could turn you off macros it would be M4, which is the
worst programming language ever. There are several other ways I had to
work around bison issues.
3. Ability to use functions as data. This makes it easy to do things like
write a function to scan the syntax tree and attach whatever function you
would like to it. This avoids a lot of duplicate code.
4. Garbage collection removes a lot of code formerly dedicated to
bookkeeping of memory access.
5. Not having to specify type everywhere saves a lot of code. Also, you
can write more flexible code by supporting multiple types of arguments,
which you handle differently.
6. Huge library of built-in functions that are easy to use.
I am also targetting GCL as one of my lisp compilers, and it is mainly
CLTL V1 only, though there is an ANSI Lisp well on the way. So, there are
quite a few things I can't use eg hash tables with EQUALP comparisons and
conditions.
Tim
Harry
> Hello,
> Many thanks in advance,
Can't thank you folks enough (each* one of you!) for taking the time
to write. Assimilating all the info and links you shared, looks like,
will be VERY helpful to me and will keep me busy for a while. Going
into hibernation now, with my books and all this wonderful info...
Best regards,
/HS
*
> (apply #'thank-you! (all-those-who-responded))
T
danb
> (if item
> (let ((x (field item)))
> (if x (let ((y (field2 x)))
> (if y (let ((z (field3 y))))
> (actually-do-useful-stuff z)))))
Just as a side note, you should replace IF with AND if
you plan to return a value from this expression, and
use WHEN if you don't.
> (foll ((item (field it) (field2 it) (field3 it) (useful-stuff it)))))
Of course, this example is so regular, it can be compressed even more.
It's similar to binding (>>=) in the Maybe monad in Haskell.
(maybe>>= item field field2 field3 useful-stuff)
:)
--Dan
------------------------------------------------
Dan Bensen
http://www.prairienet.org/~dsb/
Campo
Good lord. Talk about self-reference. If "bad spirits" were enough to
sink a language Scott McNeely's lingering stench would have driven
every Java programmer to Groovy several years before it was
introduced.
CL's big problem is that it is not a good first language. It is a
language for people who have suffered, but the industry is staffed
with people about to suffer for the first time. As soon as someone has
suffered they are either made a manager, or fired.
Campo
> På Tue, 18 Mar 2008 13:54:02 +0100, skrev <kodi...@eurogaran.com>:
>
> >> Well, with that attitude, it looks like you're off to a fairly poor
> >> start and you have a long way to go...
>
> > it looks like WE're off to a fairly poor
> > start and WE have a long way to go...
>
> Who's WE?
He has a mouse in his pocket.
Campo
On Mar 17, 9:52 am, Harry <simonsha...@gmail.com> wrote:
> Hello,
>
> I have heard some say on the Net that Lisp-based development is fast
> as well as intellectually very elegant and fulfilling. That Lisp is
> "the programmable programming language"... All this is certainly very
> encouraging; I tend to even believe all this, esp after reading Paul
> Graham's success story and a few articles here and there. However,
> since it may be a while before I know Lisp enough to be able to find
> my own answers, (just got my copies of Ansi Common Lisp and Practical
> Common Lisp) could some of you fine Lispers share your insights on the
> following in the meantime?
Lisp isn't magic. Every once in a while I have a dream where I start
jumping higher and higher and pretty soon I am flying. I think some
people expect that they will magically float above the considerations
of the world once they learn lisp. Then they find CL initially
uncomfortable rather than transcendant. This accounts for 90% of lisp-
hate, I think.
Anyway, all that programmability comes with a certain cognitive
overhead. If you are dead set on stringing statements one after
another CL is not a good choice for you. Unfortunately, most
programmers are dead set on doing exactly that.
> 1. How could Lisp be exploited in building enterprise applications
> (versus going the J2EE or .NET route)? In Web tier and in Biz Logic
> tier?
A small team of really good CL programmers could build you better
software than your current large team of idiot Java programmers. They
might have to build their own dotlisp tier to do so though, and that
might be expensive.
> 2. While I (am not afraid to and in fact) love writing code from
> scratch if needed (and if permitted), what community support (in the
> form of free/opensource libraries/packages similar to Perl CPAN and
> various Java/C/C++ sites) is available for Lisp?
CL has a lot of libraries. It has less than Java, because Sun doesn't
put millions into CL. You might have to roll your own for some
important stuff. But you'd be surprised at how many libs there are for
CL.
> 3. Could folks who have tried both J2EE and Lisp for enterprise
> computing share their experiences and insights?
J2EE is completely brain-dead, but well supported. Your HR department
will be able to hire many incompetents just by looking at their
resumes. CL can't compete with that.
> 4. How much of a pure functional style of programming (with no setf's)
> could be used in building a non-trivial enterprise application? I'm
> coming from primarily an imperative programming background (Java/C/C+
> +) and am wondering how could one possibly write a nontrivial/large
> application without side-effects!
Who cares? If you want a pure functional language you should look
elsewhere, IMHO. But, all of the calculation in your apps can be done
functionally, in CL, if you are that dedicated to nipple clamps.
That's basic theory.
> 5. What arguments could I give to my mgt (of primarily a J2EE shop) to
> give Lisp a small and cautious try?
>
It's unlikely that you can argue your management into mainlining CL
over, say, Java. But you can get an implementation and use it to do
something useful. Give them value. If they are not able to appreciate
value, get a new job.
Alan Crowe
> 4. How much of a pure functional style of programming (with no setf's)
> could be used in building a non-trivial enterprise application? I'm
> coming from primarily an imperative programming background (Java/C/C+
> +) and am wondering how could one possibly write a nontrivial/large
> application without side-effects!
Any large program involve christmas trees of pointers to
structures of pointers to structures of .....
In C this alternation is explicit. Lisp standardises on
pointers and in Common Lisp you use optional type
declarations to help the compile eliminate any overhead.
How do you avoid structure sharing bugs? One idea is to be
omniscient. Reality deals harshly with such hubris.
Another idea is "defensive deep copying" which is expensive
in both time and memory, and in actually writing the code.
One is tempted to trim, which introduces obscure bugs.
A better idea is "functional programming". Look at what a
functional program is actually doing when you change a data
structure. Usually it amounts to doing "just enough"
copying. Functional programming is a discipline for
designing out structure sharing bugs.
In Common Lisp the semantics of the built-in lists (done
with cons, car, cdr, endp) are biased towards functional
programming, but the semantics of arrays (including vectors)
and CLOS support imperative programming without reservation.
So Lisp style involves both designing out structure sharing
bugs by using functional techniques and using imperative
techniques for inplace algorithms and the like.
In the Lisp world functional programming is not a hair
shirt, it is protective clothing.
Alan Crowe
Edinburgh
Scotland
Christophe
Hi all,
To take an example : JDK 1.6 arrives with a database (Derby). A slow,
really not bug free, database !
Allegro CL is selling with AllegroCache.
For industry, I prefer, a lot, to use Allegro CL.
Compared to Java : Allegro is more reliable, more quick, use less
memory, use a notably better Database, have more libraries ! all in
standard.
SUN invest, perhaps, millions in Java, but all of this money go to
smoke !
And, with the open source policy, there are actually Zero innovation
in the language.
Best Regards,
Christophe
Stefan Arentz
Really? In my experience Derby is amazingly fast and reliable. I've
used it in numerous projects with success.
> Allegro CL is selling with AllegroCache.
Oh. Selling. No open source alternative?
> For industry, I prefer, a lot, to use Allegro CL.
> Compared to Java : Allegro is more reliable, more quick, use less
> memory, use a notably better Database, have more libraries ! all in
> standard.
You are comparing a key/value store to a full SQL database. Don't you
think that is rather silly? And really, before you make such claims,
show some numbers.
> SUN invest, perhaps, millions in Java, but all of this money go to
> smoke !
> And, with the open source policy, there are actually Zero innovation
> in the language.
Really? The open sourcing of Java 7 has actually led to many
improvements already. Including one significant one at the language
level, the introduction of a simple form of closures.
http://wiki.java.net/bin/view/JDK/ClosuresSyntaxInJava7
Personally I think it is a good thing that not much innovation is
happening in the language. Adding new stuff to a static language like
Java is really hard. Specially when you have to design these changes
with long durability in mind.
S.
Lars Rune Nøstdal
>
>> In 2001 I gave up everything related to computers and programming, but
>> then I rediscovered my initial interest through GNU/Linux and Lisp and
>> their communities. All four of them are good and I don't want them to
>> change, and they won't.
>>
> They will.
I think it is the world that is changing or adapting - not the other way
around.
Christophe
Franz doesn't a dumping Compagny, and don't work only Sunday :) ...
It's not a community, but an industry to produce very good products.
You buy your car, I think. You con understand it's logical to buy a
software.
The only difference between car and soft, it's the duplication cost.
But in all cases, you have a design and development cost.
>
> > For industry, I prefer, a lot, to use Allegro CL.
> > Compared to Java : Allegro is more reliable, more quick, use less
> > memory, use a notably better Database, have more libraries ! all in
> > standard.
>
> You are comparing a key/value store to a full SQL database. Don't you
> think that is rather silly? And really, before you make such claims,
> show some numbers.
>
You have never used AllegroCache. But, it's right they are no
comparison between Derby and AllegroCache. Really no !
> > SUN invest, perhaps, millions in Java, but all of this money go to
> > smoke !
> > And, with the open source policy, there are actually Zero innovation
> > in the language.
>
> Really? The open sourcing of Java 7 has actually led to many
> improvements already. Including one significant one at the language
> level, the introduction of a simple form of closures.
>
It's a joke, but a good example of forgotten in computer sciences in
general.
> http://wiki.java.net/bin/view/JDK/ClosuresSyntaxInJava7
>
Perhaps, SUN will give up JScheme to manage Corba :) Seriously, in
1980 Smalltalk offer a better way for closure, where is the
innovation ?
Or it's another joke.
> Personally I think it is a good thing that not much innovation is
> happening in the language. Adding new stuff to a static language like
> Java is really hard. Specially when you have to design these changes
> with long durability in mind.
>
Yes, perhaps, but what the utility of an old fashion language, subtain
c/c++ developers in there jobs ?
> S.- Masquer le texte des messages précédents -
>
> - Afficher le texte des messages précédents -
Christophe
Stefan Arentz
...
>> > To take an example : JDK 1.6 arrives with a database (Derby). A slow,
>> > really not bug free, database !
>>
>> Really? In my experience Derby is amazingly fast and reliable. I've
>> used it in numerous projects with success.
>>
>> > Allegro CL is selling with AllegroCache.
>>
>> Oh. Selling. No open source alternative?
>
> Franz doesn't a dumping Compagny, and don't work only Sunday :) ...
> It's not a community, but an industry to produce very good products.
>
> You buy your car, I think. You con understand it's logical to buy a
> software.
>
> The only difference between car and soft, it's the duplication cost.
> But in all cases, you have a design and development cost.
That is not an answer to my question.
>> > For industry, I prefer, a lot, to use Allegro CL.
>> > Compared to Java : Allegro is more reliable, more quick, use less
>> > memory, use a notably better Database, have more libraries ! all in
>> > standard.
>>
>> You are comparing a key/value store to a full SQL database. Don't you
>> think that is rather silly? And really, before you make such claims,
>> show some numbers.
>>
>
> You have never used AllegroCache. But, it's right they are no
> comparison between Derby and AllegroCache. Really no !
I have actually used AllegroCache for several experiments and I was
quite happy with it. It would be better to compare it to for example
Berkeley DB though, which is available for both Java and C.
[ cut away the parts that were jibberish]
>> Personally I think it is a good thing that not much innovation is
>> happening in the language. Adding new stuff to a static language like
>> Java is really hard. Specially when you have to design these changes
>> with long durability in mind.
>>
>
> Yes, perhaps, but what the utility of an old fashion language, subtain
> c/c++ developers in there jobs ?
The Java ecosystem is quite alive actually. Commercially, open source
and community wise.
S.
Pertti Kellomäki
> A small team of really good CL programmers could build you better
> software than your current large team of idiot Java programmers.
But do note that this is also true:
A small team of really good programmers could build you better
software than your current large team of idiot programmers.
And I would bet that this would also be true:
A small team of really good Java programmers could build you better
software than your current large team of idiot CL programmers.
No language is going to help you if the team consists of idiots.
--
Pertti
Christophe
> Christophe <christophe.allegr...@birdtechnology.net> writes:
>
> ...
>
>
>
>
>
> >> > To take an example : JDK 1.6 arrives with a database (Derby). A slow,
> >> > really not bug free, database !
>
> >> Really? In my experience Derby is amazingly fast and reliable. I've
> >> used it in numerous projects with success.
>
> >> > Allegro CL is selling with AllegroCache.
>
> >> Oh. Selling. No open source alternative?
>
> > Franz doesn't a dumping Compagny, and don't work only Sunday :) ...
> > It's not a community, but an industry to produce very good products.
>
> > You buy your car, I think. You con understand it's logical to buy a
> > software.
>
> > The only difference between car and soft, it's the duplication cost.
> > But in all cases, you have a design and development cost.
>
> That is not an answer to my question.
Concerning Open Source alternative ... I don't know Open Source :)
I live in Earth, not in Utopia Shuttleworth.
>
> >> > For industry, I prefer, a lot, to use Allegro CL.
> >> > Compared to Java : Allegro is more reliable, more quick, use less
> >> > memory, use a notably better Database, have more libraries ! all in
> >> > standard.
>
> >> You are comparing a key/value store to a full SQL database. Don't you
> >> think that is rather silly? And really, before you make such claims,
> >> show some numbers.
>
> > You have never used AllegroCache. But, it's right they are no
> > comparison between Derby and AllegroCache. Really no !
>
> I have actually used AllegroCache for several experiments and I was
> quite happy with it. It would be better to compare it to for example
> Berkeley DB though, which is available for both Java and C.
>
I have a doubt...
>
> >> Personally I think it is a good thing that not much innovation is
> >> happening in the language. Adding new stuff to a static language like
> >> Java is really hard. Specially when you have to design these changes
> >> with long durability in mind.
>
> > Yes, perhaps, but what the utility of an old fashion language, subtain
> > c/c++ developers in there jobs ?
>
> The Java ecosystem is quite alive actually. Commercially, open source
> and community wise.
>
Commercially : IBM, SUN
Open Source : ... Existing really ???
Community : yes IBM, SUN employees :)
Ecosystem : return to Jurassic Parc :)
Stefan Arentz
...
> Commercially : IBM, SUN
> Open Source : ... Existing really ???
> Community : yes IBM, SUN employees :)
>
> Ecosystem : return to Jurassic Parc :)
Your response is one of ignorance and not knowing the facts.
S.
Christophe
Java : 70% of project fails. A fact.
Exclude some little libraries, Java subtain by employees of IBM and
SUN, not by some community.
You take the example of closure : it's a pure example of regression.
It's enough to see Smalltalk in 1980 standard, to understand the
regression.
We are in a Lisp Forum, speak about closure without have in mind the
lambda theory, I think it's a regression. And also a regression for
customer : Java : 70% of project fails. A fact !
Christophe
Raffael Cavallaro
> A small team of really good Java programmers could build you better
> software than your current large team of idiot CL programmers.
except that common lisp is a more difficult language than java to
learn, so learning enough common lisp to be considered a common lisp
programmer more or less guarantees that one is not an idiot, and a team
of common lisp programmers is more or less guaranteed not to be a team
of idiots
because java is designed to control the damage that average programmers
can do, it is mostly used by the average and below average, so large
teams of java programmers are quite likely to contain a fair number of
dolts
Stefan Arentz
> On 20 mar, 14:41, Stefan Arentz <stefan.are...@gmail.com> wrote:
>> Christophe <christophe.allegr...@birdtechnology.net> writes:
>>
>> ...
>>
>> > Commercially : IBM, SUN
>> > Open Source : ... Existing really ???
>> > Community : yes IBM, SUN employees :)
>>
>> > Ecosystem : return to Jurassic Parc :)
>>
>> Your response is one of ignorance and not knowing the facts.
>>
>> S.
>
> Java : 70% of project fails. A fact.
> Exclude some little libraries, Java subtain by employees of IBM and
> SUN, not by some community.
I wish you good luck in your universe :-)
S.
Sohail Somani
> except that common lisp is a more difficult language than java to learn,
Could you explain why you think so?
--
Sohail Somani
http://uint32t.blogspot.com
Mikael Jansson
> On Thu, 20 Mar 2008 12:49:37 -0400, Raffael Cavallaro wrote:
> > except that common lisp is a more difficult language than java to learn,
>
> Could you explain why you think so?
>
to know what constructs to use for looping (do, do*, dolist, loop,
Y, ...), what paradigm to use (mostly-functional or mostly-
imperative), when to use special variables in place of global
variables and/or simple let-bindings.
Now, I can't say I've /know/ Common Lisp, but I'm trying to learn.
-- Mikael
Stefan Arentz
> On Thu, 20 Mar 2008 12:49:37 -0400, Raffael Cavallaro wrote:
>
>> except that common lisp is a more difficult language than java to learn,
>
> Could you explain why you think so?
Personally I had no trouble learning enough Common Lisp and CLOS to be
productive. I don't think CL is very complicated.
For me the real problem is finding usable libraries. Common Lisp comes
with a lot of stuff but something simple as a network socket has not
been standardized. Or even regular expressions. Or basic crypto stuff,
or threads, or MIME parsing or xml parsing, etc. etc.
Maybe it is time for a 'Boost for Common Lisp' - a supplementary
standard library.
S.
Zach Beane
> For me the real problem is finding usable libraries. Common Lisp comes
> with a lot of stuff but something simple as a network socket has not
> been standardized. Or even regular expressions. Or basic crypto stuff,
> or threads, or MIME parsing or xml parsing, etc. etc.
I agree that it would be nice if there were more libraries, but I
think your list is somewhat flawed. For example, for some of the above
I would strongly recommend:
- cl-ppcre for regular expressions
- ironclad for basic crypto stuff
- cxml for xml parsing
I haven't used the following, but they seem promising:
- bordeaux-threads for threads
- iolib for networking
- cl-mime for MIME processing
Zach
Stefan Arentz
> Stefan Arentz <stefan...@gmail.com> writes:
>
>> For me the real problem is finding usable libraries. Common Lisp comes
>> with a lot of stuff but something simple as a network socket has not
>> been standardized. Or even regular expressions. Or basic crypto stuff,
>> or threads, or MIME parsing or xml parsing, etc. etc.
>
> I agree that it would be nice if there were more libraries, but I
> think your list is somewhat flawed. For example, for some of the above
> I would strongly recommend:
>
> - cl-ppcre for regular expressions
>
> - ironclad for basic crypto stuff
>
> - cxml for xml parsing
I've used all of these and they are indeed excellent.
> I haven't used the following, but they seem promising:
>
> - bordeaux-threads for threads
>
> - iolib for networking
I gave up on it. It's undocumented and has no sample code. The author
prefers to improve the library instead of documenting even the most
basic example. Whatever.
>
> - cl-mime for MIME processing
Good tip. Looks promising too.
I'm certainly not saying there are no libraries. I just wish there
were more *standard* libraries included.
S.
Sohail Somani
> Maybe it is time for a 'Boost for Common Lisp' - a supplementary
> standard library.
I understand this feeling. I have often thought along similar lines.
Personally, I think the main benefit of an organization like Boost is
that they have certain documentation/testing/*licensing* standards which
as you mention elsewhere (sans licensing), is a problem with certain CL
libraries. Getting things into the standard is only secondary. Who has 5
years to wait for tr1::tuple available on every compiler?
I am not 100% sure about this, but I think Boost had people making some
actual $$$ from its further development via consulting or whatever.
Without such financial backing, I fear the situation won't change. I know
there are cases of a few people on this group doing that but that is by
and large the exception, not the rule (flame retardant suit is on and
functioning.) I'm sure without this, Edi-ware wouldn't even exist.
That being said, I would love to see a plan to have an umbrella
organization with standardized documentation/testing/licensing that can
afford to support further development for Common Lisp libraries.
Ken Tilton
Let's not forget all the C/C++ libraries we have.
kenny
--
http://smuglispweeny.blogspot.com/
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
Campo
Sure. I would take a smart Java programmer over a stupid Lisp
programmer any day. Interestingly, that distinction doesn't come up
much.
At one point in the past I spent most of my day interviewing
programmers for an unnamed large company. I hated doing that. I had a
template for my interviews. At the end I would ask "so, how would you
do that in scheme?" I didn't reject candidates if they failed to
answer that, but... maybe I should have. The people who gave
reasonable answers to that were uniformly good hires.
It's not politically correct to say this but I will say it: CL is for
smart people. Most programmers are too stupid to program in Lisp. If
your IQ is not several deviations above the norm you should stick to
Java or Python.
So yeah:
> A small team of really good Java programmers could build you better
> software than your current large team of idiot CL programmers.
if that team existed. But it doesn't. If they were bright they would
not be Java programmers.
Raffael Cavallaro
> On Thu, 20 Mar 2008 12:49:37 -0400, Raffael Cavallaro wrote:
>
>> except that common lisp is a more difficult language than java to learn,
>
> Could you explain why you think so?
Because common lisp contains so much more than java, so in order to
understand other people's common lisp code you must understand a very
large language, even if you don't use these features yourself:
multiple inheritance v. single inheritance
generic funtions and multiple dispatch v. methods belonging to classes
and single dispatch
mop v no mop
macros v no macros
closures v no closures (yet)
distinctions among read-time, compile-time, load-time and run-time in
common lisp, etc.
Sohail Somani
> On 2008-03-20 13:09:13 -0400, Sohail Somani <soh...@taggedtype.net>
> said:
>
>> On Thu, 20 Mar 2008 12:49:37 -0400, Raffael Cavallaro wrote:
>>
>>> except that common lisp is a more difficult language than java to
>>> learn,
>>
>> Could you explain why you think so?
>
> Because common lisp contains so much more than java, so in order to
> understand other people's common lisp code you must understand a very
> large language, even if you don't use these features yourself:
Ok so it sounds like you mean it might be a difficult language in which
to maintain other people's code.
To be honest, I think overuse of MOP and unintuitive reader macros might
be the biggest problems. Usage of the other features are not big deals,
IMHO.
Pascal Costanza
> On 2008-03-20 03:30:10 -0400, Pertti Kellomäki <pertti.k...@tut.fi>
> said:
>
>> A small team of really good Java programmers could build you better
>> software than your current large team of idiot CL programmers.
>
> except that common lisp is a more difficult language than java to learn,
I disagree: http://java.sun.com/j2se/1.5/pdf/generics-tutorial.pdf
Pascal
--
1st European Lisp Symposium (ELS'08)
http://prog.vub.ac.be/~pcostanza/els08/
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
Sohail Somani
I think it all comes down to knowing when to use which tool. Its like
knowing when to use run-time polymorphism vs when to use compile-time
polymorphism in C++. The choice of which looping construct to use is
similar. Though I have recently developed a healthy appreciation of LOOP,
I must say.
Anyway, if your programmers are using the wrong tool for the job, you
need different programmers :-)
C.R. Kirkwood-Watts
| Java : 70% of project fails. A fact.
I having trouble understanding what this line means. Is it: seven out
of ten projects fail? Or: 70% of each project fails somehow? Or, is
there another interpretation I'm not considering?
Chris.
Raffael Cavallaro
> Ok so it sounds like you mean it might be a difficult language in which
> to maintain other people's code.
or to *use* other people's code. Using libraries often entails
understanding how they work, and that often entails reading and
understanding the library code.
common lisp is a much larger language than java in terms of the
language features it supports (as opposed to the volume of library
code) so learning common lisp properly is a task that only better
programmers are up to
in case it's not clear, i'm basically agreeing with campo's post down
thread where he says that "CL is for smart people"
gavino
Is that really true? 70% of java project FAIL? link?
Raffael Cavallaro
> I disagree: http://java.sun.com/j2se/1.5/pdf/generics-tutorial.pdf
if your point is that java's newer features are clumsily integrated
with the base language because they were bolted on afterwards, you'll
get no argument from me.
but I don't think that tutorial you pointed to is more difficult for
most programmers to understand than AMOP, and these are just *single*
language features, and common lisp supports many more language features
than java does out of the box, and even more by extension because
common lisp is much more extensible
where is the java tutorial for the java mop? (there is none of course)
where is the java tutorial for java macros?
where is the java tutorial for multiple inheritance and multiple dispatch?
etc., etc.
common lisp is just a bigger language with more, and more complex
language features than java which makes it harder to learn
Sohail Somani
Ok but do I really need all the whiz-bang features of CL to implement
something like the Hunchentoot library? Or cl-glut? Or metabang-bind? I
think its quite rare that you actually require a few deviations above
average IQ to understand some CL code. Really.
I've often heard that the most difficult thing to do is to keep something
simple. That is where you need a few deviations above average IQ. In my
opinion, the authors of the above mentioned libraries have done that very
well. Of course there are more but those are just some off the top of my
head.
The "CL is for smart people" thing bugs me. Perhaps I am not that smart.
But I don't really care because reading library code has never prevented
me from doing what I wanted to do with the code. Two disclaimers: 1) I
haven't wanted to do much outside what the libraries are meant for, 2) I
have not touched Cells. ;-)
Joost Diepenmaat
> Ok but do I really need all the whiz-bang features of CL to implement
> something like the Hunchentoot library? Or cl-glut? Or metabang-bind? I
> think its quite rare that you actually require a few deviations above
> average IQ to understand some CL code. Really.
I'm not really sure but I'm inclined to agree. I think Lisps mostly just
*look* foreign to many programmers.
> The "CL is for smart people" thing bugs me. Perhaps I am not that smart.
> But I don't really care because reading library code has never prevented
> me from doing what I wanted to do with the code. Two disclaimers: 1) I
> haven't wanted to do much outside what the libraries are meant for, 2) I
> have not touched Cells. ;-)
My impression as a fairly new CL programmer is that it's not that hard
to "get", but you need to be a fairly experienced programmer and/or
willing to experiment to see what many of the great features are good
for. If you already know closures, OO, exceptions or other features that
are available in other languages too, and you also already know where
they work well or not, CL isn't a big step; most of those features seem
to work as well if not better in CL as anywhere else, and you get macros
and decent compilers into the bargain.
What I'm getting at is that CL seem to *me* to be a language that's
ideal for experienced programmers who've worked in a couple of different
languages and seen what's available and now want as much of those
features as you can get but in a single language.
And I'm not mentioning Cells in this group again until I've built
something useful in it. :-)
--
Joost Diepenmaat | blog: http://joost.zeekat.nl/ | work: http://zeekat.nl/
Sohail Somani
> If you
> already know closures, OO, exceptions or other features that are
> available in other languages too, and you also already know where they
> work well or not, CL isn't a big step; most of those features seem to
> work as well if not better in CL as anywhere else, and you get macros
> and decent compilers into the bargain.
I think that must be it. Anyway, that speaks to experience, not some
vague measurement of intelligence.
Raffael Cavallaro
not so
how many average java programmers even know what closures are? or what
memoization is? (I had one tell my I had made a typo - he thought I was
trying to write "memorization") or a general condition system (not just
execeptions)? or a metaobject protocol?
years of experience won't necessarily teach you what these things are -
you need to learn certain abstract concepts and the propensity and
ability to learn such abstract concepts are marks of intelligence.
Stefan Arentz
I think it is more like 70% of ALL software projects beyond a specific
size fail. Including those in Common Lisp :-)
Joel Spolsky has a good article about it I think. Not sure where he
got the numbers though.
S.
Slark
On 2008-03-20 23:36:28 -0400, Sohail Somani <soh...@taggedtype.net> said:
On Fri, 21 Mar 2008 00:34:02 +0100, Joost Diepenmaat wrote:
If you
already know closures, OO, exceptions or other features that are
available in other languages too, and you also already know where they
work well or not, CL isn't a big step; most of those features seem to
work as well if not better in CL as anywhere else, and you get macros
and decent compilers into the bargain.
I think that must be it. Anyway, that speaks to experience, not some
vague measurement of intelligence.
not so
how many average java programmers even know what closures are? or what memoization is? (I had one tell my I had made a typo - he thought I was trying to write "memorization") or a general condition system (not just execeptions)? or a metaobject protocol?
Actually, don't most programmers know about memoization? You see it in lots of code (including java...) - of course the autohors may not know the technique has a name, but that's largely irrelevant (until you come to try communicate with others!)
Graham
Joost Diepenmaat
Pascal Costanza
> On 2008-03-20 16:54:42 -0400, Pascal Costanza <p...@p-cos.net> said:
>
>> I disagree: http://java.sun.com/j2se/1.5/pdf/generics-tutorial.pdf
>
> if your point is that java's newer features are clumsily integrated with
> the base language because they were bolted on afterwards, you'll get no
> argument from me.
No, that's not my only point.
> but I don't think that tutorial you pointed to is more difficult for
> most programmers to understand than AMOP, and these are just *single*
> language features, and common lisp supports many more language features
> than java does out of the box, and even more by extension because common
> lisp is much more extensible
>
> where is the java tutorial for the java mop? (there is none of course)
Yes, there is: http://www.manning.com/forman/
> where is the java tutorial for java macros?
http://java.sun.com/j2se/1.5.0/docs/guide/apt/GettingStarted.html
> where is the java tutorial for multiple inheritance and multiple dispatch?
http://www.javaworld.com/javaworld/jw-12-1998/jw-12-techniques.html?page=1
http://java.sun.com/j2se/1.5.0/docs/guide/collections/designfaq.html#1
> etc., etc.
>
> common lisp is just a bigger language with more, and more complex
> language features than java which makes it harder to learn
I disagree. I think Common Lisp is easier to learn by now. Java was a
simple language in the beginning, but isn't anymore.
Java has a lot of complexity, but with very little rewards. In some
cases, I would say that Java is even more complicated than Common Lisp.
For example, see
http://www.eclipse.org/aspectj/doc/released/adk15notebook/generics-inAspectJ5.html
John Thingstad
<raffaelcavallaro@pas-d'espam-s'il-vous-plait-mac.com>:
Depends on what you mean by 'learn the language'.
There is a reason J2EE engineers with 10 years experience get major bucks
for their work.
GOOD Java programmers are few and far between. And to master Java you must
also know the libraries which are numerous and tricky. Tomcat, JNI,
Servlets, JSP to mention a few. Compare Lisp with Huchencentoot to this
and I would argue learning Lisp web programming is in fact simpler as well
as far less tedious.
--------------
John Thingstad
Pascal Bourguignon
> gavino <gavc...@gmail.com> writes:
>
> [...]
>> Is that really true? 70% of java project FAIL? link?
>
> I think it is more like 70% of ALL software projects beyond a specific
> size fail. Including those in Common Lisp :-)
Indeed. But since Common Lisp code is at least 10 times more compact
than other languages, there are very few CL programs that go beyond
that specific size. That's why in CL the percentage of successful
software projects is higher.
> Joel Spolsky has a good article about it I think. Not sure where he
> got the numbers though.
>
> S.
--
__Pascal Bourguignon__ http://www.informatimago.com/
You're always typing.
Well, let's see you ignore my
sitting on your hands.
Pascal Costanza
> Raffael Cavallaro wrote:
>> On 2008-03-20 16:54:42 -0400, Pascal Costanza <p...@p-cos.net> said:
>>
>>> I disagree: http://java.sun.com/j2se/1.5/pdf/generics-tutorial.pdf
>>
>> if your point is that java's newer features are clumsily integrated
>> with the base language because they were bolted on afterwards, you'll
>> get no argument from me.
>
> No, that's not my only point.
>
>> but I don't think that tutorial you pointed to is more difficult for
>> most programmers to understand than AMOP, and these are just *single*
>> language features, and common lisp supports many more language
>> features than java does out of the box, and even more by extension
>> because common lisp is much more extensible
>>
>> where is the java tutorial for the java mop? (there is none of course)
>
> Yes, there is: http://www.manning.com/forman/
>
>> where is the java tutorial for java macros?
>
> http://java.sun.com/j2se/1.5.0/docs/guide/apt/GettingStarted.html
>
>> where is the java tutorial for multiple inheritance and multiple
>> dispatch?
>
> http://www.javaworld.com/javaworld/jw-12-1998/jw-12-techniques.html?page=1
> http://java.sun.com/j2se/1.5.0/docs/guide/collections/designfaq.html#1
I forgot a reference about multiple dispatch. But this is typically done
using the visitor pattern, which adds a lot of complexity as well.
>> etc., etc.
>>
>> common lisp is just a bigger language with more, and more complex
>> language features than java which makes it harder to learn
>
> I disagree. I think Common Lisp is easier to learn by now. Java was a
> simple language in the beginning, but isn't anymore.
>
> Java has a lot of complexity, but with very little rewards. In some
> cases, I would say that Java is even more complicated than Common Lisp.
>
> For example, see
> http://www.eclipse.org/aspectj/doc/released/adk15notebook/generics-inAspectJ5.html
To add to that, a good approach for getting a Common Lisp to work is to
do the following:
- Give them a copy of Practical Common Lisp.
- Give them a link to a tutorial how to use asdf and asdf-install (the
weakest part atm).
- Show them common-lisp.net, cliki.net and cl-user.net.
- Be available for any questions that may come up every now and then.
If you follow that recipe, newbies will be productive in 2-3 months.
I don't have hard empirical data for that, but it worked pretty well in
a few cases I have observed, and what I hear is that this is the same
experience for other people (for example, ITA).
My conclusion is that Common Lisp is pretty simple to learn, at least
the stuff you need in 80% of the cases, or so.
I don't know how Java currently fares in that regard.
Slobodan Blazeski
s'il-vous-plait-mac.com> wrote:
> On 2008-03-20 03:30:10 -0400, Pertti Kellomäki <pertti.kellom...@tut.fi> said:
>
> > A small team of really good Java programmers could build you better
> > software than your current large team of idiot CL programmers.
>
> learn,
slobodan
http://tourdelisp.blogspot.com/
Slobodan Blazeski
>
> - Show quoted text -
Maybe we should start marketing as lisp a language that even idiots
could learn
Raffael Cavallaro
>> but I don't think that tutorial you pointed to is more difficult for
>> most programmers to understand than AMOP, and these are just *single*
>> language features, and common lisp supports many more language features
>> than java does out of the box, and even more by extension because
>> common lisp is much more extensible
>>
>> where is the java tutorial for the java mop? (there is none of course)
>
> Yes, there is: http://www.manning.com/forman/
>
>> where is the java tutorial for java macros?
>
> http://java.sun.com/j2se/1.5.0/docs/guide/apt/GettingStarted.html
>
>> where is the java tutorial for multiple inheritance and multiple dispatch?
>
> http://www.javaworld.com/javaworld/jw-12-1998/jw-12-techniques.html?page=1
> http://java.sun.com/j2se/1.5.0/docs/guide/collections/designfaq.html#1
>
>> etc., etc.
>>
>> common lisp is just a bigger language with more, and more complex
>> language features than java which makes it harder to learn
These are broken imitations for the most part and so not widely known
or used by your average java programmer. The same is not true for their
lisp parallels. For example, apt is not the equivalent of common lisp
macros but a command line preprocessor, which is not used by most java
programmers. Contrast this with lisp macros which are part of the base
language and widely used - as you undoubtedly know, parts of the base
language of common lisp are defined to be macros.
Your average java programmer does not understand or use apt; your
average lisp programmer *must* understand lisp macros. This means that
your average lisp programmer has to understand more to learn his
language.
gavino
s'il-vous-plait-mac.com> wrote:
> On 2008-03-21 04:28:26 -0400, Pascal Costanza <p...@p-cos.net> said:
>
>
>
> >> but I don't think that tutorial you pointed to is more difficult for
> >> most programmers to understand than AMOP, and these are just *single*
> >> language features, and common lisp supports many more language features
> >> than java does out of the box, and even more by extension because
> >> common lisp is much more extensible
>
> >> where is the java tutorial for the java mop? (there is none of course)
>
> > Yes, there is:http://www.manning.com/forman/
>
> >> where is the java tutorial for java macros?
>
> >http://java.sun.com/j2se/1.5.0/docs/guide/apt/GettingStarted.html
>
> >> where is the java tutorial for multiple inheritance and multiple dispatch?
>
> >http://java.sun.com/j2se/1.5.0/docs/guide/collections/designfaq.html#1
>
> >> etc., etc.
>
> >> common lisp is just a bigger language with more, and more complex
> >> language features than java which makes it harder to learn
>
> These are broken imitations for the most part and so not widely known
> or used by your average java programmer. The same is not true for their
> lisp parallels. For example, apt is not the equivalent of common lisp
> macros but a command line preprocessor, which is not used by most java
> programmers. Contrast this with lisp macros which are part of the base
> language and widely used - as you undoubtedly know, parts of the base
> language of common lisp are defined to be macros.
>
> Your average java programmer does not understand or use apt; your
> average lisp programmer *must* understand lisp macros. This means that
> your average lisp programmer has to understand more to learn his
> language.
java sucks and is nothing more than a confuseopoly to get managers to
spend $
If you don't know what a confuseopoly is read some scott adams.
gavino
> Pascal Costanza wrote:
> > Raffael Cavallaro wrote:
> >> On 2008-03-20 16:54:42 -0400, Pascal Costanza <p...@p-cos.net> said:
>
> >>> I disagree:http://java.sun.com/j2se/1.5/pdf/generics-tutorial.pdf
>
> >> if your point is that java's newer features are clumsily integrated
> >> with the base language because they were bolted on afterwards, you'll
> >> get no argument from me.
>
> > No, that's not my only point.
>
> >> but I don't think that tutorial you pointed to is more difficult for
> >> most programmers to understand than AMOP, and these are just *single*
> >> language features, and common lisp supports many more language
> >> features than java does out of the box, and even more by extension
> >> because common lisp is much more extensible
>
> >> where is the java tutorial for the java mop? (there is none of course)
>
> > Yes, there is:http://www.manning.com/forman/
>
> >> where is the java tutorial for java macros?
>
> >http://java.sun.com/j2se/1.5.0/docs/guide/apt/GettingStarted.html
>
> >> where is the java tutorial for multiple inheritance and multiple
> >> dispatch?
>
> >http://java.sun.com/j2se/1.5.0/docs/guide/collections/designfaq.html#1
>
> I forgot a reference about multiple dispatch. But this is typically done
> using the visitor pattern, which adds a lot of complexity as well.
>
> >> etc., etc.
>
> >> common lisp is just a bigger language with more, and more complex
> >> language features than java which makes it harder to learn
>
> > I disagree. I think Common Lisp is easier to learn by now. Java was a
> > simple language in the beginning, but isn't anymore.
>
> > Java has a lot of complexity, but with very little rewards. In some
> > cases, I would say that Java is even more complicated than Common Lisp.
>
> > For example, see
>
> To add to that, a good approach for getting a Common Lisp to work is to
> do the following:
>
> - Give them a copy of Practical Common Lisp.
> - Give them a link to a tutorial how to use asdf and asdf-install (the
> weakest part atm).
> - Show them common-lisp.net, cliki.net and cl-user.net.
> - Be available for any questions that may come up every now and then.
>
> If you follow that recipe, newbies will be productive in 2-3 months.
>
> I don't have hard empirical data for that, but it worked pretty well in
> a few cases I have observed, and what I hear is that this is the same
> experience for other people (for example, ITA).
>
> My conclusion is that Common Lisp is pretty simple to learn, at least
> the stuff you need in 80% of the cases, or so.
>
> I don't know how Java currently fares in that regard.
>
> Pascal
>
> --
>
> My website:http://p-cos.net
> Common Lisp Document Repository:http://cdr.eurolisp.org
> Closer to MOP & ContextL:http://common-lisp.net/project/closer/
I would change that to LISP Winston & Horn 3rd edition, practical
common lisp might be better for experienced programmers, adn even then
I think ANSI common lisp by Graham and onlisp probably are better than
pcl.
gavino
> Stefan Arentz <stefan.are...@gmail.com> writes:
I would love to see stats about how 70% of java projects fail. About
how much $$$ is dumped downt eh java oracle db2 sun hole
gavino
> > said:
>
> >> A small team of really good Java programmers could build you better
> >> software than your current large team of idiot CL programmers.
>
> > except that common lisp is a more difficult language than java to learn,
>
> I disagree:http://java.sun.com/j2se/1.5/pdf/generics-tutorial.pdf
>
> Pascal
>
> --
>
> My website:http://p-cos.net
> Common Lisp Document Repository:http://cdr.eurolisp.org
> Closer to MOP & ContextL:http://common-lisp.net/project/closer/
go get em pascal!
Sohail Somani
> On 2008-03-20 23:36:28 -0400, Sohail Somani <soh...@taggedtype.net>
> said:
>
>> On Fri, 21 Mar 2008 00:34:02 +0100, Joost Diepenmaat wrote:
>>
>>> If you
>>> already know closures, OO, exceptions or other features that are
>>> available in other languages too, and you also already know where they
>>> work well or not, CL isn't a big step; most of those features seem to
>>> work as well if not better in CL as anywhere else, and you get macros
>>> and decent compilers into the bargain.
>>
>> I think that must be it. Anyway, that speaks to experience, not some
>> vague measurement of intelligence.
>
> not so
>
> how many average java programmers even know what closures are? or what
> memoization is? (I had one tell my I had made a typo - he thought I was
> trying to write "memorization") or a general condition system (not just
> execeptions)? or a metaobject protocol?
Here, you are mixing knowledge with intelligence. Surely knowledge
affects the measurement known as IQ but is not the only component by far.
I think this is one of the reasons that IQ tests are so subjective**.
Anyway, it isn't fair to rattle off random terms and they say people are
stupid when they have never *heard* of them. However, if you explain it
to them and they give you a blank stare, you have my blessing. By far,
I've found that most programmers can integrate new knowledge into their
existing understandings. Even if it isn't a deep and profound
understanding.
> years of experience won't necessarily teach you what these things are -
> you need to learn certain abstract concepts and the propensity and
> ability to learn such abstract concepts are marks of intelligence.
Here, I agree. But I live in this ideal world where programmers strive to
be better than they are. Indeed, it has surprised me sometimes when this
is not true but I like to think that I have always managed to help those
people love their profession and want to improve. I even got someone to
enjoy using Boost and C++!
<tangent>
It makes me sad to realize that a lot of useful-to-someone programs are
so damn boring and require no special programming skill at all. I've been
fortunate enough to stay away from those, but I know they exist!
</tangent>
** By the way, before anyone thinks I am not for IQ because I got a low
score, this is not true. On two different WAIS tests some time apart I
got more than 130. But being me, I know this is obviously not a good
gauge! I'm sure you will agree ;-)
Sohail Somani
> Depends on what you mean by 'learn the language'. There is a reason J2EE
> engineers with 10 years experience get major bucks for their work.
I once saw a job posting for J2EE experts with 15 years experience.
Mikael Jansson
> On Thu, 20 Mar 2008 10:21:00 -0700, Mikael Jansson wrote:
>
> > For me, I found I was given too much freedom, which made it difficult to
> > know what constructs to use for looping (do, do*, dolist, loop, Y, ...),
> > what paradigm to use (mostly-functional or mostly- imperative), when to
> > use special variables in place of global variables and/or simple
> > let-bindings.
>
> knowing when to use run-time polymorphism vs when to use compile-time
> polymorphism in C++. The choice of which looping construct to use is
> similar. Though I have recently developed a healthy appreciation of LOOP,
> I must say.
>
syntactical toolbox is so much larger in Lisp, it's not immediately
obvious what flavor of a certain construct to use, compared to the (in
the case of looping) one-for-or-while-to-rule-them-all in C-ish
languages. Moreover, if you don't like the existing constructs, hey,
roll you own.
It's like having this feeling of being everywhere in the programming
continuum at the same time, without knowing where to fix your
position.
> Anyway, if your programmers are using the wrong tool for the job, you
> need different programmers :-)
*insert rant about most languages being Turing-complete, and by
extension...*
--
Mikael Jansson
http://mikael.jansson.be
Mikael Jansson
vous-plait-mac.com> wrote:
>
> how many average java programmers even know what closures are? or what
> memoization is? (I had one tell my I had made a typo - he thought I was
> trying to write "memorization") or a general condition system (not just
> execeptions)? or a metaobject protocol?
>
> years of experience won't necessarily teach you what these things are -
> you need to learn certain abstract concepts and the propensity and
> ability to learn such abstract concepts are marks of intelligence.
... you could say that about programmers in any language that /aren't
passionate/ about what they're doing. C++ and bash gets my bills
paid; does that mean I have a lower level of intelligence?
Mikael Jansson
> On Fri, 21 Mar 2008 01:00:48 -0400, Raffael Cavallaro wrote:
> > On 2008-03-20 23:36:28 -0400, Sohail Somani <soh...@taggedtype.net>
> > said:
>
> > years of experience won't necessarily teach you what these things are -
> > you need to learn certain abstract concepts and the propensity and
> > ability to learn such abstract concepts are marks of intelligence.
>
> Here, I agree. But I live in this ideal world where programmers strive to
> be better than they are. Indeed, it has surprised me sometimes when this
> is not true but I like to think that I have always managed to help those
> people love their profession and want to improve. I even got someone to
> enjoy using Boost and C++!
>
www.codinghorror.com/blog/archives/001002.html> to hold?
Sohail Somani
Since you asked: I think that there are definitely people who are
vocational and there are people who are passionate about their work. But
I like to think that the people who are merely vocational started out
with some sort of passion like "ooh, that is cool!" rather than "ooh, I
need a job!"
In my short time, I would say the vast majority are those that were
initially drawn to programming due to the "ooh, that is cool!" factor. I
think these people just need a trigger (or me) to bring back that passion
(or beat it into them!) I would say that over time, acceptance of others'
dominion over their work is what drains the passion and they become
merely vocational.
But anyway, an industry full of passionate programmers is a recipe for
the extinction of development managers. Hmmm...
Mikael Jansson
> On Fri, 21 Mar 2008 11:24:12 -0700, Mikael Jansson wrote:
>
> Since you asked: I think that there are definitely people who are
> vocational and there are people who are passionate about their work. But
> I like to think that the people who are merely vocational started out
> with some sort of passion like "ooh, that is cool!" rather than "ooh, I
> need a job!"
>
around at school (M.Sc in CS&E) what people wanted to do when they
grew up, surprisingly many did /not/ want to become programmers!
Hence the part about "most 20% programmers fail to realize that
they're in the 20% group".
(Also, many don't care one bit about programming and related in their
spare time -- whether that's actually a good thing, I don't know -- I
choose to think it's bad.)
Anyway, enough with the patting-self-on-back :)
> But anyway, an industry full of passionate programmers is a recipe for
> the extinction of development managers. Hmmm...
>
I'd say that depends on the manager. Where I work, managers do the
boring stuff so you as a developer don't have to. Are you referring
to the type of boss that does micro management on his staff?
Sohail Somani
> On 21 Mar, 19:38, Sohail Somani <soh...@taggedtype.net> wrote:
>> On Fri, 21 Mar 2008 11:24:12 -0700, Mikael Jansson wrote:
>>
>> Since you asked: I think that there are definitely people who are
>> vocational and there are people who are passionate about their work.
>> But I like to think that the people who are merely vocational started
>> out with some sort of passion like "ooh, that is cool!" rather than
>> "ooh, I need a job!"
>>
> Then you're in for a harsh wake-up, the same as mine: when asking around
> at school (M.Sc in CS&E) what people wanted to do when they grew up,
> surprisingly many did /not/ want to become programmers! Hence the part
> about "most 20% programmers fail to realize that they're in the 20%
> group".
But I was talking about people who *are* programmers not people who
didn't want to be programmers... Anyway, FWIW, I found the same thing in
my CS program.
> (Also, many don't care one bit about programming and related in their
> spare time -- whether that's actually a good thing, I don't know -- I
> choose to think it's bad.)
>
> Anyway, enough with the patting-self-on-back :)
LOL
>> But anyway, an industry full of passionate programmers is a recipe for
>> the extinction of development managers. Hmmm...
>>
> I'd say that depends on the manager. Where I work, managers do the
> boring stuff so you as a developer don't have to. Are you referring to
> the type of boss that does micro management on his staff?
I am generally against the idea that programmers need to be herded and
contained. A lot of managers have this idea so I was mostly referring to
those. I have had good managers before who trust their developers but
having no manager is better :-)
It is good that you are isolated from the boring stuff, but in all
honesty, unless things are very badly managed with lots of committees and
meetings, there isn't all that much boring stuff.
Mikael Jansson
> On Fri, 21 Mar 2008 12:19:28 -0700, Mikael Jansson wrote:
> > On 21 Mar, 19:38, Sohail Somani <soh...@taggedtype.net> wrote:
> >> On Fri, 21 Mar 2008 11:24:12 -0700, Mikael Jansson wrote:
>
> >> Since you asked: I think that there are definitely people who are
> >> vocational and there are people who are passionate about their work.
> >> But I like to think that the people who are merely vocational started
> >> out with some sort of passion like "ooh, that is cool!" rather than
> >> "ooh, I need a job!"
>
> > Then you're in for a harsh wake-up, the same as mine: when asking around
> > at school (M.Sc in CS&E) what people wanted to do when they grew up,
> > surprisingly many did /not/ want to become programmers! Hence the part
> > about "most 20% programmers fail to realize that they're in the 20%
> > group".
>
> But I was talking about people who *are* programmers not people who
> didn't want to be programmers... Anyway, FWIW, I found the same thing in
> my CS program.
>
want to be programmers as much as simply finding a profession where
you start with a good salary and, if you're lucky, can upgrade to the
position of manager (doing fluffy stuff) after a while (typically,
that career path would be in the kind of company that don't attract
good hackers in the first place).
>
> >> But anyway, an industry full of passionate programmers is a recipe for
> >> the extinction of development managers. Hmmm...
>
> > I'd say that depends on the manager. Where I work, managers do the
> > boring stuff so you as a developer don't have to. Are you referring to
> > the type of boss that does micro management on his staff?
>
> I am generally against the idea that programmers need to be herded and
> contained. A lot of managers have this idea so I was mostly referring to
> those. I have had good managers before who trust their developers but
> having no manager is better :-)
>
> It is good that you are isolated from the boring stuff, but in all
> honesty, unless things are very badly managed with lots of committees and
> meetings, there isn't all that much boring stuff.
>
Unless you work at Google or Jane St. Capital, you're occasionally
interacting with entities called "customers" and "sales people".
Reducing time spent with them is often a good thing, in my experience
-- I want to produce *code*, not Statement of Work-documents...
Hence the "do the boring work". Delegating tasks to others isn't
always a bad thing: you do it all the time when you use someone else's
library.
Sohail Somani
>> It is good that you are isolated from the boring stuff, but in all
>> honesty, unless things are very badly managed with lots of committees
>> and meetings, there isn't all that much boring stuff.
>>
> Unless you work at Google or Jane St. Capital, you're occasionally
> interacting with entities called "customers" and "sales people".
> Reducing time spent with them is often a good thing, in my experience --
> I want to produce *code*, not Statement of Work-documents...
>
> Hence the "do the boring work". Delegating tasks to others isn't always
> a bad thing: you do it all the time when you use someone else's library.
Alrighty. I am not strongly opinionated on the amount of boring work that
exists to continue :-)
Damien Kick
> how many average java programmers even know what closures are? or what
> memoization is? (I had one tell my I had made a typo - he thought I was
> trying to write "memorization") or a general condition system (not just
> execeptions)? or a metaobject protocol?
Well, I'm going to cheat a little bit and broaden the choices of the
languages to use in the comparison. Perl has lexical closures and
dynamic scoping, similar to Lisp's special variables. I could be wrong,
but I think that Java's anonymous inner classes gives something of the
flavor of closures, albeit with far less taste to it. Java has some
sense of reflection to it, though not something as far reaching as the
MOP. Of course, I haven't used Java in a little over five years, so
they may have added something. One can even find discussions of
multiple dispatch, and some kind of attempt at implementing it, in more
than one popular C++ book. And Lisp isn't even the only homoiconic
(every time I see that word it makes me think it should be referring to
someone who is a legend in the gay community) language. Of course,
Prolog is probably a poor choice to use as a comparison if one is trying
to make a sales pitch for Lisp being a good blue collar language.
And one definitely doesn't have to learn everything all at once. One
can use CLOS without even knowing about the MOP or know about the MOP
without ever using it. One can use the pretty printer without knowing
anything about writing one's own dispatch functions for it. I was
personally using ERROR and HANDLER-CASE in much the same way that the
"average" Java or C++ programmer would use try/catch before I copped
onto restarts and the more general power of Lisp conditions. I think
that many people are unnecessarily scared off of Lisp because it has
this reputation for being so exotic. It *is* different but it's not
*that* different. Personally, I really like the approach of something
like _Practical Common Lisp_ in that it just starts introducing language
features in a context of using them to solve problems.
> years of experience won't necessarily teach you what these things are -
> you need to learn certain abstract concepts and the propensity and
> ability to learn such abstract concepts are marks of intelligence.
Well, I don't think that any one language can lay claim to any of these
traits. In fact, there are probably quite a few people running around
using abstract concepts who've never written a program in any language.
Raffael Cavallaro
> C++ and bash gets my bills
> paid; does that mean I have a lower level of intelligence?
All along we've been talking about *average* java programmers, not
programming wizards who happen to be working a java gig to pay the
bills. Clearly there are able programmers - presumably like yourself,
since you read c.l.l and are clearly interested in things beyond what
pays your check - who know other languages but need to work in more
mainstream languages because that's where the most lucrative job
opportunities are.
However, whatever language is hiring the most programmers will of
numerical necessity draw a larger proportion of mere warm bodies -
people who are less able, less curious, less intelligent, and just
there for the paycheck. This numbers game also drives the lower
requirements of the language used - when management decides they want a
large number of easily replaceable, mediocre programmers rather than a
small number of hard to find excellent ones, management must select a
language that is easier for easily replaceable, mediocre programmers to
learn effectively.
Raffael Cavallaro
> Well, I don't think that any one language can lay claim to any of these
> traits. In fact, there are probably quite a few people running around
> using abstract concepts who've never written a program in any language.
No doubt, but we were talking about programmers, not the general population.
The point is very simple - java may have little used, recent bolt-ons
to provide some of the things built in to common lisp, but the average
java programmer doesn't use them or know much about them. The same is
not true of their lisp equivalents - you have to know the lisp
equivalents or you can't really be said to be a lisp programmer:
you cannot be said to be a lisp programmer if you don't understand
macros; you can be said to be a java programmer if you don't understand
macros; you cannot be said to be a lisp programmer if you don't
understand closures; you can be said to be a java programmer is you
don't understand closures; etc.
Mikael Jansson
vous-plait-mac.com> wrote:
>
> [...]
>
> However, whatever language is hiring the most programmers will of
> numerical necessity draw a larger proportion of mere warm bodies -
> people who are less able, less curious, less intelligent, and just
> there for the paycheck. This numbers game also drives the lower
> requirements of the language used - when management decides they want a
> large number of easily replaceable, mediocre programmers rather than a
> small number of hard to find excellent ones, management must select a
> language that is easier for easily replaceable, mediocre programmers to
> learn effectively.
(Just so you know, I was playing the devil's advocate just to see what
you'd answer. You did, excellent explanation -- I'll borrow it in the
future! :))
It's a sad state where people don't care about what they do. Or is it?
Perhaps, it is only programmers (and a few other professions) that
are--or can be--passionate about their work. I've never had a second
thought about what to work with (or hobby, for that matter...), so
it's hard for me to imagine.
Andrew Reilly
> Actually, don't most programmers know about memoization? You see it in
> lots of code (including java...) - of course the autohors may not know
> the technique has a name, but that's largely irrelevant (until you come
> to try communicate with others!)
Indeed. Most of computing uses the term "caching" in this context.
Admittedly not quite the same animal, but in the same genus.
Cheers,
--
Andrew
Daniel Barlow
> It's not politically correct to say this but I will say it: CL is for
> smart people. Most programmers are too stupid to program in Lisp. If
> your IQ is not several deviations above the norm you should stick to
> Java or Python.
Really? That's me told, then.
-dan
e...@infometrics.nl
> Pascal Costanza wrote:
> > Raffael Cavallaro wrote:
> >> On 2008-03-20 16:54:42 -0400, Pascal Costanza <p...@p-cos.net> said:
[...]
> If you follow that recipe, newbies will be productive in 2-3 months.
>
> I don't have hard empirical data for that, but it worked pretty well in
> a few cases I have observed, and what I hear is that this is the same
> experience for other people (for example, ITA).
>
> My conclusion is that Common Lisp is pretty simple to learn, at least
> the stuff you need in 80% of the cases, or so.
Having worked for a very large Lisp-project, the overall experience
was that newbies were productive in a few weeks. OK, their code was
perhaps not what an experienced Lisper would write, but it was
accepted for production use, where it ran for years.
> I don't know how Java currently fares in that regard.
Or any other language, for that matter.
Ernst
Mikael Jansson
> ** By the way, before anyone thinks I am not for IQ because I got a low
> score, this is not true. On two different WAIS tests some time apart I
> got more than 130. But being me, I know this is obviously not a good
> gauge! I'm sure you will agree ;-)
>
I took a test in a pop sci magazine and only got 127. Aww, does this
mean I can't argue with you anymore? :(
Sohail Somani
Like I said, not a good guage!
Stefan Arentz
> Stefan Arentz <stefan...@gmail.com> writes:
>
>> gavino <gavc...@gmail.com> writes:
>>
>> [...]
>>> Is that really true? 70% of java project FAIL? link?
>>
>> I think it is more like 70% of ALL software projects beyond a specific
>> size fail. Including those in Common Lisp :-)
>
> Indeed. But since Common Lisp code is at least 10 times more compact
> than other languages, there are very few CL programs that go beyond
> that specific size. That's why in CL the percentage of successful
> software projects is higher.
Unfortunately they can stil be counted on one hand :-)
S.