From ... From: Erik Naggum Subject: Re: teaching and learning with LISP/Scheme Date: 2000/06/20 Message-ID: <3170508583880858@naggum.no>#1/1 X-Deja-AN: 636868857 References: <393D4239.1F24F1E1@rice.edu> <8hktjo$fo7$1@nnrp1.deja.com> <87itvlu426.fsf@frown.inka.de> <2hya4hadx1.fsf@dslab7.cs.uit.no> <8766rlu0wj.fsf@frown.inka.de> <2hu2f5aamy.fsf@dslab7.cs.uit.no> <87itvlsg2k.fsf@frown.inka.de> <8ikj70$j05$1@wanadoo.fr> <8inig7$o5u$1@wanadoo.fr> mail-copies-to: never Content-Type: text/plain; charset=us-ascii X-Complaints-To: newsmaster@eunet.no X-Trace: oslo-nntp.eunet.no 961521160 4627 195.0.192.66 (20 Jun 2000 17:12:40 GMT) Organization: Naggum Software; vox: +47 8800 8879; fax: +47 8800 8601; http://www.naggum.no User-Agent: Gnus/5.0803 (Gnus v5.8.3) Emacs/20.6 Mime-Version: 1.0 NNTP-Posting-Date: 20 Jun 2000 17:12:40 GMT Newsgroups: comp.lang.lisp * "fab" | C is efficent, clean, and fast, that's what I think C was "efficient" on a PDP-11. It is inefficient on everything created ever since that CPU design was abandoned. On modern processors, C is actually anti-efficient due to a number of relationships between processor, memory, and the outside world. C is not clean -- the language has _many_ gotchas and traps, and although its semantics are _simple_ in some sense, it is not any cleaner than the assembly-language design it is based on. C is not fast -- it is instead microoptimizable, so it looks as if you control the speed of your code, but instead of generating fast code for problem-solving, the compiler generates no excess machine code relative to _your_ code. This is the same "fast" as assembler, where you would have to be lobotomized beyond recognition to believe that instructions counts equated speed. | C++ is complicated as far as I know. I'm going to work to learn it, | cause it's impossible to avoid it if you're going on modern | programming such as Java. And I don't want to begin with Java. Of the two languages, I think you should begin with Java, and get yourself Bruce Eckel: Thinking in Java. It is in its second edition, but I don't know whether you're likely to find that version on bookshelves, yet. You can find it on the net: www.BruceEckel.com. | Scheme (lisp?) can have a control of his own code this is much | farther than the macro possibility of c c++. Whatever you think, | c++ will always remain a freezed language, not evolutive, whereas | scheme is. Aren't the last features of Mzcheme including good | object-programming-style tools ??? I'd like to visit your planet once. It sounds like it's the inverse of earth, and the earth sucks, so it just might be a nice place. Scheme and Common Lisp are two languages so different you are better off believing they have nothing in common except the parentheses. Scheme is frozen solid. C++ has had an _amazing_ evolution of the past few years -- so much in fact that it is impossible to program in the _language_ -- you always program some particular _compiler_. The same is true of Scheme, which is useless without extensions, which are all incredibly ugly compared to the language itself. | But, in fact, a C programmer "can" go into scheme if he is amazed by its | possibility, I'm just afraid he won't be amazed at all by the syntax ;-) He is a wise man who speaks for himself on such mattes. | However Scheme as a main drawback, I would like to know if lisp as | the same, it's about using OS resources (sound, graphism, | input/output, IRQ hardware drivers, etc...) It's not like visual | c++ or java, does somebody have an advice on that ? It is generally a good idea not to reinvent wheels. Therefore, a good programmer sees little or no prestige in which language is used as long as it is the best for the purposes at hand. Common Lisp is far superior to any other language in one particular area: It is the best programming language for humans to express themselves in. Other languages may be more suitable to device drives than humans, and in some cases the needs of the machine may outweigh that of the human, but is getting more and more rare. #:Erik -- If this is not what you expected, please alter your expectations.