* Soren Dayton <···············@cs.uchicago.edu>
| 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?
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.
Erik Naggum <····@naggum.no> writes:
> 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.
From: ··············@my-dejanews.com
Subject: Re: Learning curve for common lisp
Date:
Message-ID: <76rtua$2tc$1@nnrp1.dejanews.com>
In article <················@naggum.no>, Erik Naggum <····@naggum.no> wrote:
> 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