Subject: Re: free lisp compilers? From: Erik Naggum <erik@naggum.no> Date: 1999/09/09 Newsgroups: comp.lang.lisp Message-ID: <3145856171456452@naggum.no> * Friedrich Dominicus | If the problems exist very much, why isn't than antther solution choosen? | As explained above, I do not know about C++ to tell something against or | pro. Just one point seems to be clear. Large projects are done in C++ | and there are a million tools out there and even with tools like the GNU | Tools developer have written e.g KDE and it worked quite fine. But there | isn't any GUI-Toolkit I know of which was written in Common Lisp and is | in widespread news for open software projects. And even worse many of | the GUI-Toolkits for Common Lisp are not supported any longer and look | quite a bit old. So why should people which do programming for the fun | of it choose Common Lisp? The advantages do not seem so large that they | would switch from C++, and in fact they prefer to write software with C++. using Franz Inc's cbind utility, a fairly new Lisp user (he just got the Allegro CL Trial edition for Linux) compiled up gtk bindings and wrote some Lisp source that basically did gtk calls from Lisp in a few hours. it seems fairly verbose to me, but that was his first approximation. fairly impressive, still, and if it doesn't take more than this to get access to such toolkits, what's holding us back is probably only that we think it's a lot of work. beginners don't know that, so they just do it. why should people who do programming for fun choose Common Lisp? because it's a lot _more_ fun programming in Common Lisp! I chose to rebuild my carreer and switch away from C/C++ when I had to use C++ in a project (and like so many other programmers, I had heard mostly good things about it at the time (August 1993)), but the language is really, truly braindamaged. I was complemented on my design and coding from the few people I got to know who were seasoned C++ programmers at the time, but it still took forever to write, there were always unwanted side effects of the most seamingly innocuous code and no way to have the compiler or system tell you about them, and the redesigns that had to be made as we discovered more details of the problem space were so costly the project didn't reach its goals even with two more programmers on it and almost twice the time, but we did publish a small useful core and a lot of useful design papers. this experience had "there has to be a better way" virtually flashing over us all the time, and I decided to take a good serious look at Common Lisp, which I had been using for fun off and on for longer than I har programmed in C. it took me three years of other useful work (I wrote articles for various newspapers and journals, and covered various IT-related news events, and also began writing a book about SGML, which led me to conclude that that language was braindamaged, too, so I stopped working on SGML) before I could go out there and say "I'm a Lisp programmer" and expect to be paid for it. since it was clear to me that I could sustain myself as a writer, and I had no plans to return to hell and write C++ code ever again, the risks were pretty low and I could invest my time in Common Lisp, which I really _like_. this would not have been possible in a _less_ fun language. (now, three years may seem like a long time, but I want to be really good at whatever I do, and good articles and columns don't exactly come for free, either.) | I just can say, it seems not to matter. And I can say the same for | Eiffel. But relatively few are using Common Lisp and Eiffel instead of | C++. So the problem seems not to big for them. they don't know how easy it could be. they expect changes to be so and so expensive. the result is that fewer changes are made than necessary for correct operation, broken designs survive into products, and new versions are harder to get out the door without massive rewrites. this is how the C++ world works. since C++ people tend to know C++ only, which is actually good for them when you think about it, they don't see it as a problem. many other disciplines talk about "baselines" and the work required to establish them, and it is fair to say that the baseline for correcting errors in C++ is much, much higher than that for Common Lisp, but those who have internalized the C++ baseline won't believe the Common Lisp figures. I think we have some evidence of that right here. | I found no comparable book to ANSI C from K&R with solution books. And | another book I asked for, was out of print for MIT-Press. So it's not | damn easy to find stuff for Common Lisp. BTW the handbooks whic come | with Allegro CL und LispWorks are quite good and useful. And the | Hyperspec is really a good organized reference. But this are IMO quite | advanced docs. And not very suitable for a beginner or even worse a | complete beginner to programming. a complete beginner to programming would probably have a hard time getting a job if all he knew was Common Lisp. those who employ Common Lisp people tend to expect good knowledge of several languages. it may therefore be a disservice to a future programmer to teach him the best language first... several of the good Common Lisp programmers I know who have been taught Scheme and Common Lisp have asked me time and again to show them more low-level stuff. new Common Lisp users seem to find the low-level access "panels" intriguing and opening them to see what's inside is entertaining and adds a feeling of being in control. then we put the panels back on and we don't have to _work_ at that level. #:Erik -- it's election time in Norway. explains everything, doesn't it?