> > The only 2 usable free implementations of Common Lisp i know of are > > CLISP and CMUCL. CLISP is the only one that you can actually take and > > compile yourself.
> Depends on whether you use that weird patented meaning of "free" that people > have forced onto many of us who don't like it. In the ordinary meaning of > free ("gratis"), you'll find excellent implementations from Harlequin/Xanalys > and from Franz. Also, Cormon Common Lisp, last I checked, had a very low > cost or free implementation. And certainly GNU CL (formerly KCL) is free > even in the bizarro sense. See the ALU web page to see if this is complete; > it might still not be. The ALU web page is a better source of authority.
Well, Corman is a great system, for Windows or Power Mac (though it has a different name on the Mac).
Harlequin and Franz distribute trial versions of their systems, but they're limited enough to make them useless for anything other than learning (nothing wrong there, it's their right to to so).
I'm not sure about GCL; i thought it was just a system for translating Lisp to C. I'll take another look when i have a minute.
<theglau...@my-deja.com> wrote: > Well, Corman is a great system, for Windows or Power Mac (though it has a > different name on the Mac).
PowerLisp from Roger Corman is a different system from "Corman Lisp" and outdated.
> I'm not sure about GCL; i thought it was just a system for translating Lisp > to C. I'll take another look when i have a minute.
GCL is a "normal" Lisp system - it just happens to use the C compiler to generate native code in an intermediate step - but the user does not see this directly.
> I keep thinking the level of attention to detail and the necessity > to learn a tremendous amount of "stuff" for modern programmers is > closer to very established professions like medicine and law than > some of the undereducated punks would dream of in a nightmare.
Steve McConnell argues for a true profession of Software Engineering including licensing that would require some years of practice. You can read chapter one of his book, _After_the_Gold_Rush_, at this site: http://www.construx.com/stevemcc/gr.htm An overview of his proposal is at: http://www.construx.com/SEPG2000.pdf
Thanks, Jeff Sandys, P.E. (licensed Mechanical Engineer)
* Jeff Sandys <sand...@asme.org> | Steve McConnell argues for a true profession of Software Engineering | including licensing that would require some years of practice. | You can read chapter one of his book, _After_the_Gold_Rush_, at this site: | http://www.construx.com/stevemcc/gr.htm | An overview of his proposal is at: | http://www.construx.com/SEPG2000.pdf
The reference may be useful to others, as I have already acquired and read the book, which is quite good, despite being published by the evil empire. This book led me to read Code Complete, which I had previously scoffed at out of prejudice towards the publisher, but it is still _not_ to his credit to have chosen that publisher.
#:Erik -- Does anyone remember where I parked Air Force One? -- George W. Bush
In our last episode (25 Oct 2000 05:37:26 GMT), the artist formerly known as Rob Warnock said:
>Christopher Browne <cbbro...@hex.net> wrote: >+--------------- >| Will Hartung said: >| >Somewhere, perhaps PG's home page (not that I have the URL, mind you), is >| >his enumerations about "Web Success". In them he frowns on server generated >| >HTML pages, so this would fit in quite well philisophically. >| >| <http://www.paulgraham.com/mistakes.html> >| The thing that seems most relevant: >| Dynamically generated HTML is bad, because search engines ignore it. >+--------------- >Also see Philip Greenspun's comments on this issue, and his solution:
... elided up to ...
>Briefly, his solution was:
> Write another AOLServer TCL program that presents all the messages > from URLs that look like static files, e.g., "/fetch-msg-000037.html" > and point the search engines to a huge page of links like that. > The text of the Q&A forum postings will get indexed out of these > pseudo-static files and yet I can retain the user pages with their > *.tcl URLs.
That's a good response to the issue.
It still leaves the performance issue, namely that if you can generate the web page "at compile time," then it's easy to let a web cache like Squid stream it out without imposing the dynamic load of querying databases and generating HTML at run time.
I would think this particularly critical at the time that a search engine starts spidering your site; as the spider hits, watch the load average [assuming Unix here ;-)] head Rather High.
The point is that it's interesting to see the trade-off of doing things at compile time versus doing them at run time. I'll bet there are some entertaining macros in the Yahoo! Store... -- (concatenate 'string "cbbrowne" "@" "hex.net") <http://www.ntlug.org/~cbbrowne/lsf.html> "If Ada became the hot, in-language you would see a lot more bad code in Ada." -- Thaddeus L. Olczyk <olc...@interaccess.com>, comp.lang.C++
>> Scheme is not that young. Actually, Scheme predates Common Lisp.
>Yep. The first Scheme report was 1978, I believe. The earliest CL >draft was 1981. Steele was key in the creation of both. Scheme >contributed the "controversial" notion of lexical scoping to Common >Lisp.
Those that claim Scheme is "new" just have no sense of history :-).
>> I think the reason every second Scheme programmer reimplements the >> language is the same reason every Forth programmer does. The language >> is by design very spartan and a lot of things you need to do real >> applications is missing and has to be added, either by the >> implementation or by the programmer. Given that you're forced in the >> role of language implementor anyway, many people chose to start from >> their own foundation. >I think it goes deeper than this. I think the people who teach it >and the examples they choose when they teach it lead people to >believe that reimplementing it is a "mitzva" ("good thing"). It >takes a while for students to understand that just because a thing is >"possible" it's not always a "good idea". (Not to draw too sharp a >parallel between two hopefully unrelated concepts, but I think this >is the reason viruses get written as well.)
>Students come out of school with a tremendous amount of zeal and >energy that is often worn away in the first few years. Companies >parasite on this by working them hard and paying them little. But >often before companies get to them, they sit around making projects >for themselves to prove themselves. A thesis is one such thing. But >we owe it to students to point them in the direction of new things >that need to be done, rather than have them repeat things that are >done deals.
I tend to agree. There's another perspective; more anon...
>When I was at MIT, it was often pointed out to me, sometimes >implicitly and as often explicitly, that one must strive never repeat >what others have already done. There was always the pressure for the >new and different. You'd see it in thesis topics especially. >Someone could write a masters' thesis at many colleges in "a compiler >for Lisp" and get away with it, but even in 1980, that was "already >done" and not an acceptable masters' thesis topic unless you had a >specific new theory of how that compiler should work. At the same >time, I distinctly remember noting (often with the MIT-induced >disdain for the outside that I hadn't yet learned to question) that >"other colleges" (say it with a sneer to get a proper sense of it >all) allowed their students to get away with that kind of stuff. At >the time, it was always explained to me as that they just didn't care >to force their students to think or maybe the students weren't up to >it. (Over the years, I've come to think much more highly of those >"other schools", but it was something I had to learn gradually.) >However, as often happens, perhaps there was a core value here that >was good without being recognized for its proper nature. Maybe the >issue of whether people are capable or not of new ideas isn't >relevant. But the push to go through the exercise of looking for new >ideas, regardless of whether you find them, and of saying "if it's >already been done, maybe there's a better use of me to find something >that's not" isn't such a bad plan and perhaps some of those "other >schools" should be doing more of what MIT was doing. Not to prove >that they are as smart as smarter than the "MIT way", which is an >utter red herring, but because it's simply a good idea to say "let's >teach people to stretch".
I think I can characterize this a bit more briefly by suggesting that the "MIT Way" is oriented towards the "Ph.D Way."
A Ph.D thesis is supposed to include some notion of the "novel;" it is supposed to extend knowledge into outright New Things. To get a Ph.D, it does not suffice to do a "good survey," and perhaps to "reimplement the wheel," both of which may be quite acceptable at the Master's level.
MIT is certainly in the business of "generating Ph.Ds," and thus puts considerable emphasis on "doing novel stuff."
>This is the reason that Java is succeeding in spite of its poorly >constructed and extremely painful language layer. Because it has >moved on to libraries, and is not obsessing forever with language >design. Lisp is better at the language level, but that's not enough. >It matters to be better at all the stuff that follows before you can >compare something that's been left behind. If Lisp can't commit to >move on and focus on libraries at an aggressive level, and teach its >followers that this is where the investment of what youthful energy >we are graced with should go, the lack of foundation argument will >sink into insignificance with time.
I'll suggest a "flip side" to this...
At some point it makes more sense to start from scratch when it gets too difficult to bolt the "new, novel stuff" onto the "previously implemented stuff."
I'll cite GCC as an example, even though there are several good contradictions.
I think there probably should have been a reasonable alternative to GCC by this time, LCC and TENDRA both having been plausible candidates.
My reasoning is that GCC basically takes a code generation model from around 15 years ago, tying the compiler components together too closely (to my taste). There are changes that are reasonably easy to make, and there have been developments in peephole optimization as well as in flow analysis. But the architecture is sufficiently rigid that it is fairly difficult to make more sweeping changes to improve it.
And therein lies the point: Once enough "details" accrete together in any system, it becomes more and more difficult to make further changes. It should be easier to improve a less mature system, as suggested by Alan Perlis' quote:
"Optimization hinders evolution." -- Alan Perlis
The big contradiction comes in that after a "hiatus" when GCC seemed "unimprovable," the EGCS project has evidently revitalized it, seemingly in that a significant body of people have grown sufficiently intimate with the code base that they can in fact find further improvements to make.
Another system that might be closer to home is GNU Emacs; its being so tied strongly to Emacs Lisp makes it seemingly impossible to take advantage of more "modern" innovations such as compiling to faster machine language as well as making use of some form of multi-threading to allow more things to go on at once. [e.g. - At present, if GNUS is busy downloading messages, nothing else can take place.]
On the one hand, adding a new variation on "Calendar Mode" to Emacs is no big deal. The more radical surgery required to evolve Emacs to "multiplex" better is almost certainly hindered by the past optimizations. It might very well be an utterly unrealistic hope. -- (concatenate 'string "cbbrowne" "@" "acm.org") <http://www.hex.net/~cbbrowne/emacs.html> We all live in a yellow subroutine, a yellow subroutine, a yellow subroutine...
In article <yDL8OTvhATaf+qdjOwIl8nfWI...@4ax.com>, Paolo Amoroso
<amor...@mclink.it> wrote: > On Sat, 28 Oct 2000 22:49:13 GMT, Kent M Pitman <pit...@world.std.com> > wrote:
> > A thesis is one such thing. But we owe it to students to point them in the > > direction of new things that need to be done, rather than have them repeat > > things that are done deals.
> Any suggestions concerning worthy Common Lisp projects, not necessarily for > students?
Not necessarily of "academic" interest:
- CMUCL support for multiple processors + GC. - CMUCL port to MacOS X. - (maybe portable) development environment based on (Free) CLIM - redesign/reimplement CL from a small kernel - See also the list of proposed CL-HTTP projects: http://wilson.ai.mit.edu/cl-http/projects.html (Hmm, we need to cleanup the list a bit.)
Rainer Joswig <jos...@corporate-world.lisp.de> writes: > - CMUCL port to MacOS X.
Well, the port to MacOS X itself shouldn't be much work (given that for the purposes of basic CMU CL it's just a BSD, and FreeBSD is already supported well). The hard part is writing a compiler backend for PowerPC. Although CMU CL supported the IBM RT/PC at some point in the distant past, this is architecturally quite different from the POWER architecture or the PowerPC, and anyway the backend has probably decayed beyond hope in the meantime...
Other projects in the porting area (in increasing order of difficulty, but probably also in increasing order of academic interest):
- Write a backend for CMU CL for the upcoming AMD Sledgehammer 64bit architecture.
- Write a conservative backend for CMU CL for the ia64 architecture (i.e. it is probably not possible to make decent use of the ia64 without rewriting the whole compiler framework, so this might be a study in how far you can go in compiling to ia64 within a traditional compiler framework),
- Rewrite compiler framework to fully support VLIW-style architectures (ia64).
Of course the problem with all of the above is that all the architectures are still emulation-only for mere mortals. But once the student has finished his port to PowerPC, the ia64 should be available in silicon ;)
Regs, Pierre.
-- Pierre R. Mai <p...@acm.org> http://www.pmsf.de/pmai/ The most likely way for the world to be destroyed, most experts agree, is by accident. That's where we come in; we're computer professionals. We cause accidents. -- Nathaniel Borenstein
<jos...@corporate-world.lisp.de> wrote: >> Any suggestions concerning worthy Common Lisp projects, not necessarily for >> students?
>Not necessarily of "academic" interest:
>- CMUCL support for multiple processors + GC. >- CMUCL port to MacOS X.
And win32. O:-)
>- (maybe portable) development environment based on (Free) CLIM >- redesign/reimplement CL from a small kernel
And an apache module? Yes, yes, I know, but sometimes you can't chose the http server... :-(
//----------------------------------------------- // Fernando Rodriguez Romero // // frr at mindless dot com //------------------------------------------------
In article <cpbuvs8dc1pb2a4fsaes5coiknn508s...@4ax.com>, Fernando Rodríguez <spam...@must.die> wrote:
> >Not necessarily of "academic" interest:
> >- CMUCL support for multiple processors + GC. > >- CMUCL port to MacOS X.
> And win32. O:-)
Yeah, why not. Also add support for LispOS. ;-)
For Win32 the Windows OS (ME/2000/whatever) support would have to developed. CMUCL currently runs more under Unix-like operating systems.
For MacOS X (which is a Unix OS underneath) the native code generation would have to be developed (which might be a worthwile start to later include other processors, too) and some OS support - since MacOS X has a lot of extensions and it is not using X11 for its window system.
> >- redesign/reimplement CL from a small kernel
> And an apache module? Yes, yes, I know, but sometimes you can't chose > the http server... :-(
Has anybody else something to add to the wishlist? :-) Oh, I have another one: port SK8 to CMUCL. See http://corporate-world.lisp.de/mcl/sk8.jpg for a screenshort of some basic SK8ing in Macintosh Common Lisp. It's kind of the mother of all interface builders.
> And an apache module? Yes, yes, I know, but sometimes you can't chose > the http server... :-(
fastcgi might be worth looking at. It should allow apache to talk to a persistent application server like a CL image. Since we were talking about protocol design, fastcgi is pretty braindead as far as I can see, but it exists, and so long as your lisp can do fast I/O it's probably pretty fast.
jos...@corporate-world.lisp.de writes: > Has anybody else something to add to the wishlist? :-)
Sure, but somewhat easier tasks:
- CL library for _writing_ PNG images, perhaps based on the png-reader code in the Closure web browser. - CL library for reading and writing TIFF - same for JPEG -- chr
> > Has anybody else something to add to the wishlist? :-)
> Sure, but somewhat easier tasks:
Sounds good.
> - CL library for _writing_ PNG images, perhaps based on the > png-reader code in the Closure web browser. > - CL library for reading and writing TIFF
| fastcgi might be worth looking at. It should allow apache to talk to | a persistent application server like a CL image. Since we were
FWIW, a friend of mine implemented a fastcgi interface (and possibly some sugar on top of it) for CMUCL. Unfortunately he (and thus also the code, which I didn't remember to ask from him in time) is going to be unavailable for a few months.
> On Tue, 31 Oct 2000 17:38:40 +0100, Rainer Joswig > <jos...@corporate-world.lisp.de> wrote: > And an apache module? Yes, yes, I know, but sometimes you can't chose > the http server... :-(
I've written an Apache mod_lisp but it's still in a very early stage.
>fastcgi might be worth looking at. It should allow apache to talk to >a persistent application server like a CL image. Since we were >talking about protocol design, fastcgi is pretty braindead as far as I >can see, but it exists, and so long as your lisp can do fast I/O it's >probably pretty fast.
Erik Naggum wrote: > * Jeff Sandys <sand...@asme.org> > | Steve McConnell argues for a true profession of Software Engineering > | including licensing that would require some years of practice. > | You can read chapter one of his book, _After_the_Gold_Rush_: > | http://www.construx.com/stevemcc/gr.htm > | An overview of his proposal is at: > | http://www.construx.com/SEPG2000.pdf
> The reference may be useful to others, as I have already acquired > and read the book, which is quite good, despite being published by > the evil empire. This book led me to read Code Complete, which I > had previously scoffed at out of prejudice towards the publisher, > but it is still _not_ to his credit to have chosen that publisher.
I am surprised that you read _Code_Complete_ which is mostly about C programming. You may also enjoy _Rapid_Development_. In this book Steve demonstrates how projects fail with fictional accounts of GigaSoft Corp. As Jack Webb said, "The stories are true, only the names have been changed ..." _Software_Project_Survival_Guide_ is the condensed version of _Rapid_Development_ without the stories, all published by the evil empire. These books are not language specific, but many of the arguments used for rapid development can also be made for lisp.
* Jeff Sandys <sand...@asme.org> | I am surprised that you read _Code_Complete_ which is mostly about | C programming.
C is still a very important programming language. As long as it is left reasonably alone by the C++ freaks who want very much to destroy it in the ISO process (i.e., inch it towards C++ and make it more "modern" (read: useless)), it will probably remain a very important programming language for a long time to come. It could become one of those languages that are stable enough to actually trust, and which means it will no longer be used by the hoi polloi of programmers (read: young, lonely geeks) who will flock to any novelty where it takes almost nothing to be best at _something_.
| You may also enjoy _Rapid_Development_.
Steve McConnell has a lot of good and important things to say, but I have read so many books on soi-disant rapid development over the years, the title put me off. I'll pick it up, after all. Yes, I have read his survival guide, too. Cost me several days of USENET time, but it was worth it. :)
#:Erik -- Does anyone remember where I parked Air Force One? -- George W. Bush
There was a depressing (to me) article this year in Embedded Systems Journal ( tag - Friends don't let friends write assembly language). It does imply 'C' hasn't made it everywhere yet (maybe Lisp should take heart?).
> C is still a very important programming language. As long as it is > left reasonably alone by the C++ freaks who want very much to > destroy it in the ISO process (i.e., inch it towards C++ and make it > more "modern" (read: useless)), it will probably remain a very > important programming language for a long time to come.
You will probably not answer technical questions if I am the one to ask them but in technical things you are really very reliable so here it is:
If you were to program in C for any reason: Would you stricktly follow the C standard or would you add C++ elements when necessary; are there additions of C++ to C which you regard as an enrichment of C?
For example: Does it make a sense to use the *language* of classes when I do not believe in inheritance and virtual functions and try to avoid them?
And another question: Does not the very idea of templates prove that something went wrong with C++?
J.B.
-----= Posted via Newsfeeds.Com, Uncensored Usenet News =----- http://www.newsfeeds.com - The #1 Newsgroup Service in the World! -----== Over 80,000 Newsgroups - 16 Different Servers! =-----
Janos Blazi <jbl...@netsurf.de> wrote: >> C is still a very important programming language. As long as it is >> left reasonably alone by the C++ freaks who want very much to >> destroy it in the ISO process
Too late, I think, although I haven't studied the results of the latest standardization process.
>You will probably not answer technical questions if I am the one to ask them >but in technical things you are really very reliable so here it is:
So I'll answer.
>If you were to program in C for any reason: Would you stricktly follow the C >standard or would you add C++ elements when necessary; are there additions >of C++ to C which you regard as an enrichment of C?
C is something of a universal assembly language. It's very low-level, but (when written very carefully) very portable. C++ isn't. If I write in C, it's for portability - and that's why I stick as closely as possible to the 1990 standard.
>For example: Does it make a sense to use the *language* of classes when I do >not believe in inheritance and virtual functions and try to avoid them?
That depends on what you're writing and why. If I were writing a program that could use classes, then either I'd write it is straight C for portability or I'd write it in another language. C is for portability or OS code. (And what would you use classes for without inheritance and virtual functions? Constructors and destructors? That's about all I can think of.)
>And another question: Does not the very idea of templates prove that >something went wrong with C++?
Why? I see it as an interesting form of polymorphism. It doesn't really work all that well, but that's true of lots of things in C++. Personally, I think C++ turned out very well, considering the design constraints. Obviously a language designed with other constraints could be much better for most purposes.
One thing C++ lends itself to is the creation of new sublanguages. It doesn't do that nearly as well as Common Lisp, but it does it better than other mainstream languages ((equal "mainstream language" "language with some job ads in the paper") here). Templates are part of that.
* "Janos Blazi" <jbl...@netsurf.de> | You will probably not answer technical questions if I am the one to | ask them but in technical things you are really very reliable so | here it is:
I don't react or respond to people, but to what they _do_. You have certainly made an impression, but that impression may change. If you do something that _isn't_ annoying, you wouldn't find anyone happier with that than me, but I would be slightly more irritated than usual if you didn't keep it up.
| If you were to program in C for any reason: Would you stricktly | follow the C standard or would you add C++ elements when necessary; | are there additions of C++ to C which you regard as an enrichment of | C?
There is nothing useful in C++ that is not already in ISO C. C++ is about hiding and obfuscation, both of which are ostensible qualities of abstraction if you do not understand at all what is going on around you. E.g., _defining_ the interface to the linker such that you require name mangling is simply retarded. There are many cases like that. If you do not want to walk the necessary distance, do not walk the extra mile in some other direction just to show that you aren't lazy. C++ has done more damage to programming language design than any other in the history of computing. For one thing, it showed the wrong people that you _could_ base something on C, which is really bad, because you can't. C is not the language you extend. C is the language you do _not_ extend. C is at the far end of its optimization path. It may be envied for its success, but if one does not understand that it was much, much prematurely optimized qua language, there is no hope at all of ever finding any other path (and I think the "progress" of programming languages in the past decade has shown _that_ with a depressingly strong forcefulness).
In my opinion, C cannot at this time be improved without breaking it in important ways (such as C++ in fact did). The ANSI/ISO process was already a little overzealous with those "const" jokes. (And its primary designer had to step in to stop them from adding "noalias".) Neither do I consider the feeble "support" for classes in C++ an improvement. There is a lot of really clever work in force-feeding C with stuff it could never really handle, but cleverness and good intentions do not make a metric for good results.
C++ is the worst kind of misfit: The niche it tries to fill (which is enabling programmers to think at a much higher level while forcing them to be concerned with the lowest level details) is a contradiction in terms and should not be created even though such contradictions _may_ exist in the software world. If I want what C++ wanted to give the world, I'll use Java, instead, and write the stuff that needs tight hardware coupling in pure C. I very seldom want what C++ tried to give the world in the first place, but that is another story.
Very few languages are better than C for their purposes. Very few languages are worse than C++ for their purposes. This is absolutely no accident. It is a necessarey consequence of optimization, of very bright people who considered a very narrow problem and solved it exceptionally well. It's like creating the perfect steam engine -- you simply cannot use any of that brilliant work if you want an internal combustion engine or an antigravity propulsion system, and it is _fantastically_ stupid to think you could, but if you watch people struggling with unknown problems and known solutions, they will rather apply more force and energy on making the problems fit their solutions than snap out of it and try the reverse for a second.
The worst that could "happen" to a very intelligent person is that is not "allowed" to break out of the conditions set for him by his precessors. If you cannot say "This is all wrong, let's zoom out and try over", the best you can hope for is good engineering, but good engineering should be coupled with good ideas, too, and the time you discover whether you have a really good idea is when you _don't_ have to be super clever just to do ordinary stuff, but for people who love to be clever, who are patted on the back and in many other ways rewarded for being clever, languages like C++ (and Perl) will win followers. _Anyone_ can be really clever in C++. _Any_ idiot can sit down with its _enormous_ definition and find some miniscule point that makes some fairly reaonable thing into a very special case with far-reaching ramifications that will impress other idiots. But it is anti-productive, the antithesis of good design, and a promulgator of cleverness to do the ordinary that means nobody has any time to be clever on the hard problems.
In C, there is an upper limit to how clever you can be, and that's a fantastically important property of the language: It means people tire of being the cleverest, so the cycle of useless rewards stops. Until a really stupid person came along and invented C with Classes, of course.
I still use C mainly because it's the Unix system language. It is hard to interface to Unix without being really good at thinking C. In like manner, Windows is married to C++, but at least Unix has real qualities, too.
#:Erik -- Does anyone remember where I parked Air Force One? -- George W. Bush
