Subject: Re: Learning curve for common lisp From: Erik Naggum <erik@naggum.no> Date: 1999/01/04 Newsgroups: comp.lang.lisp Message-ID: <3124481565367657@naggum.no> * Soren Dayton <csdayton+usenet@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.