User: marcoxa

Re:Thoughts from a toe-dipper

On: Kent M. Pitman Answers On Lisp And Much More

In some sense you are right.
There is no "standardized" set of "libraries" for
Common Lisp, as there are for "one-implementation"
languages like Perl and (to some lesser extent)
Python. This is a problem due to the fact
that CL standardization was done essentially in
pre-Internet-boom times, and that there are several
implementations. I'd say that the numerous complete CL implementations have been a (IMHO welcome) delaying factor in the appearance of standardized libraries.

Pretty much all the CL implementations do offer
socket libraries, what you lack is a standardized
one.

However, the CL community is well well aware of
this state of affairs and you can find more or less
centralized, embryonical CPAN-like sets of libraries.
Just check http://sourceforge.net/projects/clocc and http://sourceforge.net/projects/cclan.
Another very useful pointer (besides the always useful http://www.alu.org) is
http://ww.telent.net/cliki.

You can find all you need in these places and start using CL in the same way you would other languages.

Cheers

Re:syntax nothing to be proud of

On: Kent M. Pitman Answers On Lisp And Much More

Assuming the presence in C/C++ (or similar
languages) of the approriate functions, your example would look

C/C++ 1

strcmp(first_name(name1), first_name(name2))

C/C++ 2

strcmp(name1.first_name, name2.first_name)

C/C++ 3

strcmp(name1->first_name, name2->first_name)

They all are similar in "typing complexity" to
the proper Lisp form

(string

It is really just the "position" of the parenthesis that is different.

Cheers

Re:I agree!

On: Kent M. Pitman Answers On Lisp And Much More

I have looked at {OCa|S}ML language in the past
but have stuck with CL.

Type inference is surely nice and the only thing
you can say about CL as a language is that it does
not mandate it.

I use CMUCL most of the time, so I do not find this such a loss (CMUCL *does* quite a bit of type inference).

Pattern matching is implementatble in CL directly
and it has been in the past. Multiple dispatch
does help you in this respect also. E.g.

(defmethod factorial ((x (eql 0))) 1)
(defmethod factorial ((x integer))
(* x (factorial (1- x))))

is a perfectly good way to write the factorial
function in CL. Add a little macrology and you
can reduce the verbiage as well. (Something
you cannot do simply in ML languages - although
I have not seen OCaMLM4 at work yet).

I find the {OCa|S}ML syntax irritating. Especially in SMLNJ, I spent an inordinate amount
of time putting in parenthesis just to placate
the type inference engine.

I strongly believe that datatypes in ML languages
are overrated. Whenever I design a data structure
I know pretty well how it is going to look like
as far as the basic types are concerned. Datatypes
in ML languages are only as good as the type inference engine working underneath. Given that
you can have a similar thing in CL (admittedly
without the mathematical soundeness of ML languages), I do not find this to be a point
that would discriminate my choice of language.
The same applies to functors and modules.
They are nice, but they are not so much nice to offset
all the other things you miss when moving
away from CL.

Cheers