Learning curve for common lisp
Rainer Joswig
> Some friends and I are thinking about a project, and we were wondering
> about using CL (including CLOS). Given backgrounds with C++,
> etc. (fairly substantial) and Scheme and ML (less substantial) what sort
> of learning experience should we be expecting?
With substantial programming experience and a fair bit of reading
existing CL code, one should be able to write *good* code
after a year. "Good" depends for example on the scale
of your project. If you want to implement a really complicated
program in CL, then you might have to deal with, say, 100k lines
of dense code. Don't forget that you also might have
to learn how to use some new libraries, which might
be very different from what you are used to (say, a
logic formalism or CLIM).
The most important thing is to have a model for the Lisp
computation in your mind (lambda calculus, objects, ...).
> Given the size of CL, we are a little worried that we'd begin by writing
> pretty lousy code, and have to go back at some point and rewrite some
> stuff. Is this a serious problem?
Depends. Your initial design of your application is the critical
part. If you have a good conventional design you should
be able to move your code around - better than in
a static language. Either code changes have small effects
(changing a class often can be done in a running program)
or you may be able to write tools to introduce large
changes.
You will make really fast progress once you learn not to implement
your application in Common Lisp, but in a language suited to
solve your problem. This language should be implemented in
Common Lisp (Common Lisp is a programmable programming language).
Let macros generate your code.
Write tools to manage and to visualize your application.
Learn to work with CL environments - not against them.
Everything is dynamic - there is a reason for that.
> What sort of time scale should we be
> aware of? When will we hit that point?
For a more specific answer we would need to know something about
your project.
Erik Naggum
| Some friends and I are thinking about a project, and we were wondering
| (fairly substantial) and Scheme and ML (less substantial) what sort of
| learning experience should we be expecting?
there'll be an effort to unlearn the expectation to let the compiler tell
you what you have missed. this can be a source of very annoying errors
for quite a while. you'll (eventually) notice that the kinds of errors
you don't make more than make up for the annoying errors, but it doesn't
feel like it very early on. C++ compilers make it easy to get simple
things right, but extraordinarily hard to get complex things right. I
don't think people would fail to get simple things right unless they had
a tool that effectively invited them not to care about them, and too much
static type checking and the like does just that.
| Given the size of CL, we are a little worried that we'd begin by writing
| pretty lousy code, and have to go back at some point and rewrite some
| stuff. Is this a serious problem?
well, you'll find that you write verbose code, but not lousy code. if
you're used to Scheme, you might write Schemish code, which I think is
lousy in Common Lisp mainly because run-time type dispatch is so strongly
discouraged by the language specification and by the excessive focus on
separately-named operators on only one type at a time. with ML under
your belt, you might be more inclined to get CLOS right in that you can
think of the various methods as invoked for statically selected objects,
although they are not actually statically selected.
| What sort of time scale should we be aware of?
it appears to take longer to really grasp a new language the more code
people write per unit of time. that is, if your primary focus is to get
something done, you'll bring all your experience to the task and press
onward, and you won't notice the subtle warning and stop signs. the more
you are free to observe and reflect, the shorter time it takes to learn
most anything. in the end, you get more done if you don't go too fast,
which is like outrunning your mental abilities on the keyboard. of
course, you want to go as fast as you can, but that's usually a lot
slower in the beginning than you feel comfortable with if you have a lot
of experience getting things done in another language.
I think the best solution is to have somebody who knows Common Lisp way
better than you look at your code and ask you what you _really_ want to
accomplish with it, as that can be fairly well covered in syntax and the
kinds of obscure machinery that C++ is virtually made of.
| When will we hit that point?
it depends on how much you value introspection, and how much "there MUST
be a better way than this"-signals from your aestheticlesน will interfere
with your coding. since you have "fairly substantial" exposure to C++,
they can't be all that well developed (sorry), but I have seen people go
from dabblers in Common Lisp to _enjoying_ the HyperSpec in three months.
#:Erik
-------
น the little-known source of aesthetic reactions. if your whole body feels
like going into a fetal position or otherwise double over from the pain
of experiencing something exceptionally ugly and inelegant, such as C++,
it's because your aestheticles got creamed.
Kenneth P. Turvey
Soren Dayton <csdayto...@cs.uchicago.edu> wrote:
>
>Some friends and I are thinking about a project, and we were wondering
>about using CL (including CLOS). Given backgrounds with C++,
>
>pretty lousy code, and have to go back at some point and rewrite some
>aware of? When will we hit that point?
>
>Thanks a lot,
>Soren
I have been using Common Lisp for a little over a year and I still feel
like a novice. It is a big language. If you come from a scheme
background it should be a bit easier to get started, but becoming an
accomplished LISP programmer takes longer than any of the languages you
mentioned. In some places it is more complicated (the object system,
packages), in everything it is simply bigger.
I am an excellent C programmer, but only a mediocre LISP programmer.
The question you should ask first is whether LISP is the language to use
for your application. Can you give us some more details about the
project you are considering?
--
Kenneth P. Turvey <ktu...@SprocketShop.com>
Practice random senselessness and act kind of beautiful.
-- James Craig Burley
Craig Brozefsky
> it depends on how much you value introspection, and how much "there MUST
> be a better way than this"-signals from your aestheticles¹ will interfere
> with your coding. since you have "fairly substantial" exposure to C++,
> they can't be all that well developed (sorry), but I have seen people go
> from dabblers in Common Lisp to _enjoying_ the HyperSpec in three months.
The aestheticles may also be involved in the "cringe interval".
The "cringe interval" is the period of time between those intense
rushes of dread caused by the previouly mentioned signals from the
aestheticles. The "cringe interval" is a valuable metric indeed,
because it can be used to determine compensation.
For instance, over the weekend I was forced to take a 90% percent
solution, in perl (is there anything in Perl that is anything but a
<=90% solution?), into a 99% solution. Of course, that required a 90%
rewrite of the entire thing, with the "cringe interval" hovering
around 5 minutes. On average, every 5 minutes I would have some
overwhelming sense of aversion take control of my body, force me to
turn away from the screen and walk around the house, maybe open the
fridge up and contemplate drinking the last of the milk.
After the rewrite the "cringe interval" was up to 15-20 minutes.
Still much to low for my tastes. In perl the whole [$@%]variable
thing garauntees a "cringe interval" of at least 30 minutes.
arthurg...@my-dejanews.com
> well, you'll find that you write verbose code, but not lousy code. if
> you're used to Scheme, you might write Schemish code, which I think is
> lousy in Common Lisp mainly because run-time type dispatch is so strongly
> discouraged by the language specification and by the excessive focus on
> separately-named operators on only one type at a time.
I'm a long-time Scheme programmer who is dabbling more and more in Common
Lisp. Would you elaborate a bit on what you said about Scheme above:
"run-time type dispatch is so strongly discouraged by the language
specification" and "excessive focus on separately-named operators on only one
type at a time?" I think I see what you mean with respect to CLOS and
generic functions. Absent CLOS, is there some other way that CL supports
those capabilities better than Scheme? I'm of two minds about CL vs. Scheme,
so I'm eager to hear other people's opinions.
-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own