Lisp for enterprise computing? - lisp
This is a discussion on Lisp for enterprise computing? - lisp ; Stefan Arentz <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 ...
-
Re: Lisp for enterprise computing?
Stefan Arentz <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
-
Re: Lisp for enterprise computing?
Zach Beane <xach@xach.com> writes:
> Stefan Arentz <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.
-
Re: Lisp for enterprise computing?
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
-
Re: Lisp for enterprise computing?
Zach Beane wrote:
> Stefan Arentz <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
-
Re: Lisp for enterprise computing?
On Mar 20, 3:30 am, Pertti Kellomäki <pertti.kellom...@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.
-
Re: Lisp for enterprise computing?
On 2008-03-20 13:09:13 -0400, Sohail Somani <sohail@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.
-
Re: Lisp for enterprise computing?
On Thu, 20 Mar 2008 16:39:11 -0400, Raffael Cavallaro wrote:
> On 2008-03-20 13:09:13 -0400, Sohail Somani <sohail@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
-
Re: Lisp for enterprise computing?
Raffael Cavallaro wrote:
> On 2008-03-20 03:30:10 -0400, Pertti Kellomäki <pertti.kellomaki@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/
-
Re: Lisp for enterprise computing?
On Thu, 20 Mar 2008 10:21:00 -0700, Mikael Jansson wrote:
> On Mar 20, 6:09Â pm, Sohail Somani <soh...@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
-
Re: Lisp for enterprise computing?
On 2008-03-20 16:49:18 -0400, Sohail Somani <sohail@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"