Subject: Re: How to get a wider audience for CL From: Erik Naggum <erik@naggum.no> Date: 29 Aug 2002 13:39:08 +0000 Newsgroups: comp.lang.lisp Message-ID: <3239617148698671@naggum.no> * Pascal Costanza | Now here are some of my thoughts about what could help or, in my opinion, | what is in fact needed to have CL reach a wider audience again. More important than just a wider audience is where you will go to find the wider audience. In other words, who to attract and whence. | However, there are some drawbacks. I think people who cannot read specifications need to learn to read specifications -- and not just language specifications. Some think this an arrogant and elitist position, but Common Lisp /has/ a specification and you are expected to write to the specification, not only to the implementation. So you do not try something you dream up and see if it works, you employ yourself to understand what the language allows and then let your creativity roam free when it has a sound foundation. Really nasty things happen to people who randomly try something they envisioned in a pipe dream and wonder what it means without any ability to predict the machine's response. Trial- and-error mode is actually unsuitable for all languages, but some languages have no specification and you /have to/ test things you dream up from insufficient understanding and see if it "works" and even what it does. I think it behooves a novice to Common Lisp to shed such notions of the only proper approach to learn a programming language. Trial and error is based on intuition, but you need to build that intuition first. Using intuition from one language to be creative in another does not work very well. Perhaps, however, the reason you still appear to be look at Common Lisp from the outside. | The ANSI specs doesn't provide rationales so you can't understand the | specifications if you haven't got an idea about the topics upfront. I spent a fair amount of time with Ada 83 and the development towards Ada 95. The annotated standard has an excellent rationale liberally sprinkled throughout the entire document, and it is indeed very valuable. Back when C was ANSI X3.159, it came with the rationale as a sort of add-on document. However. the committee decisions for Common Lisp actually form a rationale relative to the base document, which is CLtL1, the Silver Book. | Furthermore, the deprecated sections are highly confusing: first of | all, a newbie (me, at least) doesn't care at all wheter someone from a XJYIZ | committee voted for this and that (I am intentionally exaggerating here); | this is (probably still) interesting for historical reasons but not when you | actually want to learn the language. I think you should read more of these decisions before you dis them all. | (We could use "CLtL3" as a working title for such a refactoring?) But who would ensure that this new document agrees with the standard? | This already would mean a lot of work but would pay off in the long run for | the CL community. I actually doubt that. So do all the others who have not started writing it. | What do you think? I think the HyperSpec is an amazingly high-quality document that it pays off handsomely to learn to read and navigate and that it would /not/ pay off to write another complete document. However, it would pay off to link from the HyperSpec pages to "commentary" pages. This could be a useful thing to do with cliki. | P.S.: Perhaps you need this background information: usually, I don't read | tutorials or introductions to languages on a tutorial level. I highly prefer | to learn languages from their specifications. Could it be that you lack the background to be able to read this particular specification and that you would benefit from getting the conceptual models right rather than read a tutorial? From reading your article, I trust that you are quite capable of internalizing the fundamental concepts, but you should consider the possibility that you started writing your article too soon and that the thinking that would normally pulsate with the energy of change have coagulated during the writing process that exposed them to your conscious verbalization of these ideas. (I frequently find myself writing both code and prose mainly to clarify my thinking on a subject, but there is a level of commitment to that which has been expressed involved in publishing or sharing that makes it surprisingly hard to revise in fundamental ways. Annoyingly common psychology that is hard to beat.) I do not think we gain anything if we attract people who do not know how to program or how to read a specification -- the cost of entertaining them could well be very more on the community than any benefits. Those who desire to write tutorials should get paid for this by people who want to buy the books or take the courses. Something on the level of How to Design Programs for Common Lisp would be great (ignoring cost/benefit analyses), but this has to be done in an existing educational setting. This quality level is immensely expensive to attain. I have written scattered sections of what could become a book under favorable conditions. I have aimed to lead people from the Unix and C environment into the Unix and Common Lisp environment, using Emacs. I am a firm non-believer in the Windows experience for a large number of reasons, many political, but Unix and Linux have some problems when it comes to Unicode support and the entertainment industry. I believe people are more productive using Common Lisp than C++ with the visually oriented programming environments for the simple reason that you live within the evolving Common Lisp world, but more work needs to be done on collaborative efforts, versioning not just of source code but of loaded executable code, and some sort of Common Lisp server that works like a database engine where an individual programmer has his own work space that he commits to the system, much like CVS does today, but within the Emacs/Common Lisp server world. I have also been dabbling in a Common Lisp Emacs (clemacs) that would integrate all of these facets, but there are features in Common Lisp that need to evolve and features in implementations that are required to support this mode of work. Many of the ideas that form the foundation for Common Lisp and Unix are actually very similar and should have been able to work tightly and well together. That they do not is perhaps one of the major failures of the Common Lisp community. -- Erik Naggum, Oslo, Norway Act from reason, and failure makes you rethink and study harder. Act from faith, and failure makes you blame someone and push harder.