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?
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
On Mar 17, 9:52 am, Harry <···········@gmail.com> wrote:
> 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.
> 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?
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
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
Ken Tilton wrote:
>
>
> 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
>
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
Slark wrote:
> Ken Tilton wrote:
>
>>
>>
>> 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
>>
>
> 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...
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
hth, kenny
--
http://smuglispweeny.blogspot.com/
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
On Mar 17, 5:52 am, Harry <···········@gmail.com> wrote:
> 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/
Harry <···········@gmail.com> writes:
> 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__
On Mar 17, 7:41 am, ····@informatimago.com (Pascal J. Bourguignon)
wrote:
> Harry <···········@gmail.com> writes:
> > 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__
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?
On Mar 17, 6:52 am, Harry <···········@gmail.com> wrote:
> 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
> 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?
>
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.
On Mar 18, 9:11 am, ·······@eurogaran.com wrote:
> 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"))
> 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
Note how you carefully omit the
1st European Lisp Symposium
Bordeaux, France, May 22-23, 2008
LaBRI, Université Bordeaux
On Mar 18, 4:08 pm, ·······@eurogaran.com wrote:
> > 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
>
> Note how you carefully omit the
> 1st European Lisp Symposium
>
> Bordeaux, France, May 22-23, 2008
> LaBRI, Université Bordeaux
Yes, a bit careless of me but I wrote spontaneously. Good that you
mention it.
Ernst
·······@eurogaran.com writes:
> > 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?
> >
>
> 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.
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
> 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...
P� Tue, 18 Mar 2008 13:54:02 +0100, skrev <·······@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?
--------------
John Thingstad
On Mar 18, 2:51 pm, "John Thingstad" <·······@online.no> wrote:
> På Tue, 18 Mar 2008 13:54:02 +0100, skrev <·······@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?
> > 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.
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.
·······@eurogaran.com writes:
> > > 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...
/Jon
--
'j' - a n t h o n y at romeo/charley/november com
·······@eurogaran.com wrote:
>>> 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/
On Mar 18, 9:51 am, "John Thingstad" <·······@online.no> wrote:
> På Tue, 18 Mar 2008 13:54:02 +0100, skrev <·······@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.
·······@eurogaran.com wrote:
>>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?
>>
>
>
> 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.
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...
hth, kenny
--
http://smuglispweeny.blogspot.com/
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
From: Edi Weitz
Subject: Re: Lisp for enterprise computing?
Date:
Message-ID: <ulk4ggu18.fsf@agharta.de>
On Tue, 18 Mar 2008 01:11:45 -0700 (PDT), ·······@eurogaran.com wrote:
> 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
http://weitz.de/eclm2008/
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
On Tue, 18 Mar 2008 01:11:45 -0700, kodifik wrote:
>
> 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/
> 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.
>
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.
On Tue, 18 Mar 2008 08:23:56 -0700, kodifik wrote:
>
>> 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.
--
Lars Rune Nøstdal
http://nostdal.org/
On Tue, 18 Mar 2008 01:11:45 -0700, kodifik wrote:
> 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
On Mar 19, 2:49 am, tim <····@internet.com> wrote:
> On Tue, 18 Mar 2008 01:11:45 -0700, kodifik wrote:
> > 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
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
On Tue, 18 Mar 2008 19:17:49 -0700, Harry wrote:
>> 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
tim wrote:
> (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/
On Mar 18, 4:11 am, ·······@eurogaran.com wrote:
> > 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?
>
> 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.
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.
On Mar 17, 6:52 pm, Harry <···········@gmail.com> wrote:
> 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
You're really asking the wrong questions.
On Mar 17, 9:52 am, Harry <···········@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.
On 19 mar, 07:24, Campo <··········@yahoo.com> wrote:
> You're really asking the wrong questions.
>
> On Mar 17, 9:52 am, Harry <···········@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.
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
Christophe <····················@birdtechnology.net> writes:
> On 19 mar, 07:24, Campo <··········@yahoo.com> wrote:
>> You're really asking the wrong questions.
>>
>> On Mar 17, 9:52 am, Harry <···········@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.
>
> Hi all,
>
> 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?
> 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.
On 19 mar, 15:11, Stefan Arentz <·············@gmail.com> wrote:
> Christophe <····················@birdtechnology.net> writes:
> > On 19 mar, 07:24, Campo <··········@yahoo.com> wrote:
> >> You're really asking the wrong questions.
>
> >> On Mar 17, 9:52 am, Harry <···········@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.
>
> > Hi all,
>
> > 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.
>
> > 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 <····················@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.
>> > 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.
On 19 mar, 21:13, Stefan Arentz <·············@gmail.com> wrote:
> Christophe <····················@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 :)
Christophe <····················@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.
On 20 mar, 14:41, Stefan Arentz <·············@gmail.com> wrote:
> Christophe <····················@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.
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
__ Christophe <····················@birdtechnology.net> _____
| 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.
On Mar 20, 7:03 am, Christophe
<····················@birdtechnology.net> wrote:
> On 20 mar, 14:41, Stefan Arentz <·············@gmail.com> wrote:
>
> > Christophe <····················@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.
>
> 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
Is that really true? 70% of java project FAIL? link?
gavino <·········@gmail.com> writes:
> On Mar 20, 7:03 am, Christophe
> <····················@birdtechnology.net> wrote:
>> On 20 mar, 14:41, Stefan Arentz <·············@gmail.com> wrote:
>>
>> > Christophe <····················@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.
>>
>> 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
>
> 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 :-)
Joel Spolsky has a good article about it I think. Not sure where he
got the numbers though.
S.
Stefan Arentz <·············@gmail.com> writes:
> gavino <·········@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.
On Mar 21, 1:59 am, Pascal Bourguignon <····@informatimago.com> wrote:
> Stefan Arentz <·············@gmail.com> writes:
> > gavino <·········@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.
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
Pascal Bourguignon <···@informatimago.com> writes:
> Stefan Arentz <·············@gmail.com> writes:
>
>> gavino <·········@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.
From: Edi Weitz
Subject: Re: Lisp for enterprise computing?
Date:
Message-ID: <uod93bso2.fsf@agharta.de>
On Mon, 24 Mar 2008 20:10:04 +0100, Stefan Arentz <·············@gmail.com> wrote:
>> That's why in CL the percentage of successful software projects is
>> higher.
>
> Unfortunately they can stil be counted on one hand :-)
The ones you've heard of, maybe. Or you have very big hands.
--
European Common Lisp Meeting, Amsterdam, April 19/20, 2008
http://weitz.de/eclm2008/
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
Edi Weitz <········@agharta.de> writes:
> On Mon, 24 Mar 2008 20:10:04 +0100, Stefan Arentz <·············@gmail.com> wrote:
>
>>> That's why in CL the percentage of successful software projects is
>>> higher.
>>
>> Unfortunately they can stil be counted on one hand :-)
>
> The ones you've heard of, maybe. Or you have very big hands.
Big hands, but still 5 fingers!
S.
On Mar 25, 9:55 am, Stefan Arentz <·············@gmail.com> wrote:
> Edi Weitz <········@agharta.de> writes:
> > On Mon, 24 Mar 2008 20:10:04 +0100, Stefan Arentz <·············@gmail.com> wrote:
>
> >>> That's why in CL the percentage of successful software projects is
> >>> higher.
>
> >> Unfortunately they can stil be counted on one hand :-)
>
> > The ones you've heard of, maybe. Or you have very big hands.
>
> Big hands, but still 5 fingers!
>
> S.
He means you have a worst case of polydactylism ever seen.
Christophe <····················@birdtechnology.net> writes:
> On 20 mar, 14:41, Stefan Arentz <·············@gmail.com> wrote:
>> Christophe <····················@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.
On 19 mar, 15:11, Stefan Arentz <·············@gmail.com> wrote:
> Christophe <····················@birdtechnology.net> writes:
> > On 19 mar, 07:24, Campo <··········@yahoo.com> wrote:
> >> You're really asking the wrong questions.
>
> >> On Mar 17, 9:52 am, Harry <···········@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.
>
> > Hi all,
>
> > 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?
>
> > 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.- Masquer le texte des messages précédents -
>
> - Afficher le texte des messages précédents -
From: Pertti Kellomäki
Subject: Re: Lisp for enterprise computing?
Date:
Message-ID: <frt3dm$fq$1@news.cc.tut.fi>
Campo wrote:
> 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
On Mar 20, 3:30 am, Pertti Kellomäki <················@tut.fi> wrote:
> Campo wrote:
> > 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.
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.
Campo wrote:
> 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
On 2008-03-20 03:30:10 -0400, Pertti Kellom�ki <················@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, 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
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?
--
Sohail Somani
http://uint32t.blogspot.com
On Mar 20, 6:09 pm, Sohail Somani <······@taggedtype.net> wrote:
> 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?
>
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.
Now, I can't say I've /know/ Common Lisp, but I'm trying to learn.
-- Mikael
On Thu, 20 Mar 2008 10:21:00 -0700, Mikael Jansson wrote:
> On Mar 20, 6:09 pm, Sohail Somani <······@taggedtype.net> wrote:
>> 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?
>>
> 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.
>
> Now, I can't say I've /know/ Common Lisp, but I'm trying to learn.
>
> -- Mikael
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 :-)
--
Sohail Somani
http://uint32t.blogspot.com
On 20 Mar, 22:13, Sohail Somani <······@taggedtype.net> wrote:
> 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.
>
> 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.
>
Obviously. But, the point I was trying to make was that because your
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
On 2008-03-20 13:09:13 -0400, Sohail Somani <······@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:
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.
On Thu, 20 Mar 2008 16:39:11 -0400, Raffael Cavallaro wrote:
> On 2008-03-20 13:09:13 -0400, Sohail Somani <······@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.
--
Sohail Somani
http://uint32t.blogspot.com
On 2008-03-20 16:49:18 -0400, Sohail Somani <······@taggedtype.net> said:
> 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"
On Thu, 20 Mar 2008 18:39:22 -0400, Raffael Cavallaro wrote:
> On 2008-03-20 16:49:18 -0400, Sohail Somani <······@taggedtype.net>
> said:
>
>> 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"
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. ;-)
--
Sohail Somani
http://uint32t.blogspot.com
Sohail Somani <······@taggedtype.net> writes:
> 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/
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.
--
Sohail Somani
http://uint32t.blogspot.com
On 2008-03-20 23:36:28 -0400, Sohail Somani <······@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?
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.
This is a multi-part message in MIME format.
--------------080604020802060506050204
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Raffael Cavallaro wrote:
> On 2008-03-20 23:36:28 -0400, Sohail Somani <······@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?
Perhaps his thinking was right? Memorization is precisely what you're
doing when you use the 'technical' (computing specific) term memoization
isn't it. It is if you're thinking at an abstract conceptual level...
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
---
aghillo.blogspot.com <http://aghillo.blogspot.com/>
--------------080604020802060506050204
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Raffael Cavallaro wrote:
<blockquote
··············································@pasdespamsilvousplaitmaccom"
type="cite">On 2008-03-20 23:36:28 -0400, Sohail Somani
<a class="moz-txt-link-rfc2396E" ···················@taggedtype.net">&·········@taggedtype.net></a> said:
<br>
<br>
<blockquote type="cite">On Fri, 21 Mar 2008 00:34:02 +0100, Joost
Diepenmaat wrote:
<br>
<br>
<blockquote type="cite">If you
<br>
already know closures, OO, exceptions or other features that are
<br>
available in other languages too, and you also already know where they
<br>
work well or not, CL isn't a big step; most of those features seem to
<br>
work as well if not better in CL as anywhere else, and you get macros
<br>
and decent compilers into the bargain.
<br>
</blockquote>
<br>
I think that must be it. Anyway, that speaks to experience, not some
<br>
vague measurement of intelligence.
<br>
</blockquote>
<br>
not so
<br>
<br>
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?
<br>
</blockquote>
Perhaps his thinking was right? Memorization is precisely what you're
doing when you use the 'technical' (computing specific) term
memoization isn't it. It is if you're thinking at an abstract
conceptual level...<br>
<br>
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!)<br>
<br>
Graham<br>
<br>
<div class="moz-signature">---<br>
<a href="http://aghillo.blogspot.com/">aghillo.blogspot.com</a>
</div>
</body>
</html>
--------------080604020802060506050204--
On Fri, 21 Mar 2008 07:48:35 +0000, Slark wrote:
> 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
On 21 Mar, 06:00, Raffael Cavallaro <················@pas-d'espam-s'il-
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
http://mikael.jansson.be
On 2008-03-21 14:14:58 -0400, Mikael Jansson <··············@gmail.com> said:
> 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.
On 22 Mar, 18:23, Raffael Cavallaro <················@pas-d'espam-s'il-
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.
--
Mikael Jansson
http://mikael.jansson.be
On Sat, 22 Mar 2008 11:45:32 -0700 (PDT), Mikael Jansson wrote:
>On 22 Mar, 18:23, Raffael Cavallaro 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.
>
> 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.
That's probably not true. Humans can be passionate about what they do
in other types of endeavors too. Is it really `less important' to be a
guitar player and be passionate about it? I hope not :)
On Fri, 21 Mar 2008 01:00:48 -0400, Raffael Cavallaro wrote:
> On 2008-03-20 23:36:28 -0400, Sohail Somani <······@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
http://uint32t.blogspot.com
On 21 Mar, 18:55, Sohail Somani <······@taggedtype.net> wrote:
> On Fri, 21 Mar 2008 01:00:48 -0400, Raffael Cavallaro wrote:
> > On 2008-03-20 23:36:28 -0400, Sohail Somani <······@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++!
>
I'm curious about that: do you believe the 80/20 rule <http://
www.codinghorror.com/blog/archives/001002.html> to hold?
--
Mikael Jansson
http://mikael.jansson.be
On Mar 21, 6:55 pm, Sohail Somani <······@taggedtype.net> wrote:
> ** 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? :(
--
Mikael Jansson
http://mikael.jansson.be
On Mon, 24 Mar 2008 07:40:48 -0700, Mikael Jansson wrote:
> On Mar 21, 6:55 pm, Sohail Somani <······@taggedtype.net> wrote:
>
>> ** 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?
Like I said, not a good guage!
--
Sohail Somani
http://uint32t.blogspot.com
On 2008-03-21 21:15:10 -0400, Damien Kick <·····@earthlink.net> said:
> 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.
Sohail Somani <······@taggedtype.net> writes:
> 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.
Definitely.
--
Joost Diepenmaat | blog: http://joost.zeekat.nl/ | work: http://zeekat.nl/
Sohail Somani <······@taggedtype.net> writes:
> 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.
Stefan Arentz <·············@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 haven't used the following, but they seem promising:
- bordeaux-threads for threads
- iolib for networking
- cl-mime for MIME processing
Zach
Zach Beane wrote:
> Stefan Arentz <·············@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 haven't used the following, but they seem promising:
>
> - bordeaux-threads for threads
>
> - iolib for networking
>
> - cl-mime for MIME processing
>
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
Zach Beane <····@xach.com> writes:
> Stefan Arentz <·············@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.
On Thu, 20 Mar 2008 18:29:23 +0100, Stefan Arentz wrote:
> 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.
--
Sohail Somani
http://uint32t.blogspot.com
Raffael Cavallaro wrote:
> On 2008-03-20 03:30:10 -0400, Pertti Kellom�ki <················@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/
On 2008-03-20 16:54:42 -0400, Pascal Costanza <··@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.
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
Raffael Cavallaro wrote:
> On 2008-03-20 16:54:42 -0400, Pascal Costanza <··@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
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/
Pascal Costanza wrote:
> Raffael Cavallaro wrote:
>> On 2008-03-20 16:54:42 -0400, Pascal Costanza <··@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.
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/
On Mar 21, 3:29 am, Pascal Costanza <····@p-cos.net> wrote:
> Pascal Costanza wrote:
> > Raffael Cavallaro wrote:
> >> On 2008-03-20 16:54:42 -0400, Pascal Costanza <····@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?p...
> >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-in...
>
> 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
>
> --
> 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/
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.
On Mar 21, 11:29 am, Pascal Costanza <····@p-cos.net> wrote:
> Pascal Costanza wrote:
> > Raffael Cavallaro wrote:
> >> On 2008-03-20 16:54:42 -0400, Pascal Costanza <····@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
On 2008-03-21 04:28:26 -0400, Pascal Costanza <··@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://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.
On Mar 21, 9:08 am, Raffael Cavallaro <················@pas-d'espam-
s'il-vous-plait-mac.com> wrote:
> On 2008-03-21 04:28:26 -0400, Pascal Costanza <····@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://www.javaworld.com/javaworld/jw-12-1998/jw-12-techniques.html?p...
> >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.
P� Thu, 20 Mar 2008 23:52:05 +0100, skrev Raffael Cavallaro
<················@pas-d'espam-s'il-vous-plait-mac.com>:
> On 2008-03-20 16:54:42 -0400, Pascal Costanza <··@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.
>
> 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
>
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
On Mar 21, 1:56 am, "John Thingstad" <·······@online.no> wrote:
> På Thu, 20 Mar 2008 23:52:05 +0100, skrev Raffael Cavallaro
> <················@pas-d'espam-s'il-vous-plait-mac.com>:
>
>
>
>
>
> > On 2008-03-20 16:54:42 -0400, Pascal Costanza <····@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.
>
> > 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
>
> 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- Hide quoted text -
>
> - Show quoted text -
Maybe we should start marketing as lisp a language that even idiots
could learn
On Fri, 21 Mar 2008 09:56:04 +0100, John Thingstad wrote:
> 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.
--
Sohail Somani
http://uint32t.blogspot.com
On Mar 20, 1:54 pm, Pascal Costanza <····@p-cos.net> wrote:
> Raffael Cavallaro wrote:
> > On 2008-03-20 03:30:10 -0400, Pertti Kellomäki <················@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/
go get em pascal!
On Mar 20, 9:49 am, Raffael Cavallaro <················@pas-d'espam-
s'il-vous-plait-mac.com> wrote:
> On 2008-03-20 03:30:10 -0400, Pertti Kellomäki <················@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,
Lispers must write code, Javans could do with gluing code.
slobodan
http://tourdelisp.blogspot.com/
Slobodan Blazeski <·················@gmail.com> writes:
> On Mar 20, 9:49�am, Raffael Cavallaro <················@pas-d'espam-
> s'il-vous-plait-mac.com> wrote:
>> On 2008-03-20 03:30:10 -0400, Pertti Kellom�ki <················@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,
> Lispers must write code, Javans could do with gluing code.
I think you mean 'reinvent the wheel' here for the Lispers.
S.
P� Tue, 25 Mar 2008 08:59:27 +0100, skrev Stefan Arentz
<·············@gmail.com>:
> Slobodan Blazeski <·················@gmail.com> writes:
>
>> On Mar 20, 9:49�am, Raffael Cavallaro <················@pas-d'espam-
>> s'il-vous-plait-mac.com> wrote:
>>> On 2008-03-20 03:30:10 -0400, Pertti Kellom�ki
>>> <················@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,
>> Lispers must write code, Javans could do with gluing code.
>
> I think you mean 'reinvent the wheel' here for the Lispers.
>
> S.
No just write the code do do what you want (in ten minutes) instead of
loading a library doing 100 things including one doing what you want
(after spending an hour finding it).
--------------
John Thingstad
On Mar 25, 9:59 am, Stefan Arentz <·············@gmail.com> wrote:
> Slobodan Blazeski <·················@gmail.com> writes:
> > On Mar 20, 9:49 am, Raffael Cavallaro <················@pas-d'espam-
> > s'il-vous-plait-mac.com> wrote:
> >> On 2008-03-20 03:30:10 -0400, Pertti Kellomäki <················@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,
> > Lispers must write code, Javans could do with gluing code.
>
> I think you mean 'reinvent the wheel' here for the Lispers.
No, reinventing the wheel means that generally accepted technique or
solution is ignored in favor of a locally invented solution. So If i'm
making from scratch regex library instead of using cl-ppcre I need to
have a really good reason(*) else I'm reinventing the wheel. In lisp
a lot of libraries just doesn't exist, or if they do they need to be
worked on or even built from scratch so you MUST learn to WRITE code.
In java there is usually libraries that sun or ibm paid to be built
so javan code just GLUE them togather and be done. Of course, unless
he wants to do something that library writers didn't forseen than
javan is forced in jumping through some very nasty hoops in order to
fix some unflexible piece of shit. I don't use java but I'll give you
some example with c#, I could beat lisp and it's web framework
weblcoks all the time as long as my problem fits into what asp.net
writers expected. But as soon I have to customize things and problems
gets harder and harder weblocks wins easily. So having strong library
support helps have a faster start against a lisping starting from
scratch but very soon lip will get you and return with vengance,
because it's higher level functionality and metaprogramming will allow
lisp to skip writing boilerplate code in java c# you have to do it
yourself. For good.
Harry <···········@gmail.com> writes:
> 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