"the implementors choose not to be fully ANSI-compliant. You won't notice it at first, but if you get into advanced object-system hacking CLISP will become unsuitable."
This used to be true at one time, many many years ago. Nowadays, CLISP by default will start up in a mode where it's not fully ansi compliant (probably because the changes they made are more user friendly), but with the -ansicommand line flag CLISP drops into a fully ansi CL compliant mode (except for bugs, of course). I guess by the object-system hacking you mean the Meta Object Protocol, which the ansi spec doesn't cover. The baseline for the MOP seems to be Kiczales' PCL CLOS implementation, which is used as the base for the CMUCL, SBCL and ECL implementations (and maybe a few of the commercial ones too). CLISP doesn't use the PCL for it's CLOS implementation, but there is a port available.
"Also, it's a byte-code interpreter system. This severely affects performance (except in bignums, due to some numerical methods magic), but it does have a smaller memory footprint. And it's widely ported."
Well, it's one of the faster bytecode compilers out there (I haven't tested this myself, but every once in a while this comes up on Usenet, where CLISP seems to be at least 2-3 times faster than the Python bytecode compiler). The "numerical method magic" is probably the hand-optimized C code (the non-ansi part of CLISP also includes arbitrarily precision floats, which are supposed to be quite fast). The base memory footprint for CLISP is just over 1.5mb, and it's probably the most widely ported CL implementation right now (it does run on Windows under Cygwin).
"I use libraries like AllegroServe (HTTP server)"
Me too:). AllegroServe is really a kick-ass web server, especially if the web application sits in the same Lisp image.
"You can investigate GCL or ECLS, which compile to C and may work under mingw."
GCL runs under Windows quite fine (that's what they use for the Windows version of Maxima). I don't think anyone is working on porting ECL (the Spain is no longer in the acronym:) to Windows, but it shouldn't be very hard, since the core bytecode compiler/interpreter is written entirely in C.
"Well, most Scheme implementations aren't anywhere near the same quality as the CL ones (with a few notable exceptions) and they all have to implement incompatible supersets of the language (because R5RS defines approximately nothing)."
I started out as a Schemer, and I agree on both points. The lack of useful iteration constructs quickly gets annoying, and there really are no Scheme compilers (except for Stalin, but where's the top level?:) that come close to the CL ones (well, there really aren't that many compilers period that can match CMUCL). But DrScheme has a really nice window IDE and development environment (wxWindows), and there really isn't anything like that (ie - free) for CL. CLISP, however, comes with GNU readline, and has the best command-line interface out of any of the lisp implementations (paren matching, completions, history, etc.)
Well, I imagine it would be the end of virtual memory systems as we know them. This could make operating systems drastically easier to write, and will hopefully (but I don't think likely) lead the re-birth of persistent "world" operating systems like the Smalltalk virtual machine and Genera. At least this type of memory will finally make it practical to keep all computers on all the time, and so there would be a very strong incentive to move away from Windows and Unix-style systems to something more persistent.
"Similarly, silicon is actually a pretty tough material. Particularly in compression, it's inherently a lot stronger than some of the normal building materials we use today. If you can generate artificial atoms with the right magnetic properties, you could keep silicon under compression and make it stronger in tension."
Given that silicon is the second most abundant element on Earth, this is very interesting indeed. Something like this material would be perfect for building superstructures, such as arcologies. As pointed out elsewhere in this thread, the only thing we need now is flying cars, and it's Blade Runner time!
But are they simultaneous (time-sharing) users? The thing about the kind of PC sharing you describe is the trust everyone has in the other users of the system. Multiple accounts would make more sense for keeping application preferences, and I guess you can have everyone in the wheel group and configure the devices and other things to work that way.
The worst part about these patches is that they penalize everything else in favor of broken C programs.
"so the overhead in the context-switch path is a very cheap, unconditional 6-byte write to the GDT, costing 2-3 cycles at most."
That's a penalty for all processes, whether they do their own bounds checking or not. In this case, since the penalty is incurred on every context switch, it would be infinitly (well, proportional to the run time of your program) cheaper just to do the damn array bounds checking that you suggest. Even worse is the restrictions this places on trampolines, and JIT and other dynamic compilers, which only further promotes the use of broken C.
I really hope this doesn't become the default among the free Unices.
"Some were produced, sure, but they were not workable in that they were expensive. In the real world price is an integral component of usability."
There really was no special reason why the Lisp Machine hardware was expensive. In it's time, it did ship with a huge amount of memory (I think the minimum was about 4 megabytes for the early 3600s), and nice high-resolution displays. As postings and other accounts indicate, the problem was that the Lisp Machine companies overcharged for both the hardware, support and software upgrades. When VLSI silicon became available, the hardware could fit on to a single NuBus board for a Macintosh, and really wasn't expensive to manufacture.
"You're right, DEC wasn't any of those things."
And DEC was a Unix vendor. You seem intent on confusing the Lisp Machine vendors (the whole three of them) with the actual Lisp Machine computers when you try to put blame on why the Lisp Machines didn't take off.
"People used to buy Alphas because they were bloody fast. But they lost that advantage by not keeping up with their otherwise inferior competitors."
Oh yeah, the EV7 is a real snail. That must be why, in their great wisdom, the HP management is betting the farm on the uber-fast Itanic.
"Took a whole quarter in at school. I hated it then"
"particularly when you had to pay for the CPU by the second"
"beginning programmers can grok procedural programming faster than functional programming."
Well, taking these statements into account, it's easy to see why you hated Lisp. When you need to balance parenthesis on punch cards for a time shared mainframe, and your instructor forgets to tell you about the goto and loop, of course you're going to hate it.
"Long have C people rallied behing it for all uses simply because it can (and usually should) be used for writing drivers or kernels"
"The value of an interactive environment cannot be understaed in the realm of learning, debugging, and development. I imagine this could be especially useful with kernel development, where debugging can be a bit harder than the usual user-space app."
I find this attitude that C is the only language with which to do systems programming really surprising. No one seems to remember that Forth was the preferred language for systems programming on the early micros. It was really well suited to interacting with hardware, it had fast I/O, good compilers (especially compared to the slow bloated mess that is a modern optimizing C compiler), and really fast execution speed - and it also had an interactive top-level, including interactive debuggers (with stepping, tracing, etc.), run-time definition and re-definition of words (functions), etc. Since the x86 doesn't have a lot of registers, Forth's stack-based computation model does make it a small amount slower than an optimizing C compiler, but on most RISC machines this isn't the case. It's a wonder it didn't catch on more. Maybe the curse of the pre/post-fix notation really is true?
Well, the obvious thing to do would be to write non-consing Scheme code (possibly by restricting yourself to a subset of Scheme - see the reference to "pre-scheme" in this article on the history of the T Scheme compiler). The other thing would be to write a garbage collector for kernel memory (or at least those parts that Schemix uses - again, see the abovementioned article on T for a mention on how they built a GC for T in T). I think the former is doable, and the latter (just for Schemix; I don't like the idea of messing with Unix kernel memory allocators, and Unix people don't like the idea of generalizing their interfaces) can probably be done as well.
"Perhaps more importantly, true high-level languages let us achieve a much higher degree of portability, at least in theory. And interpreted languages let us do all sorts of nifty things (like closures) for when you really need the power."
You should really stick to calling them "high-level" instead of "interpreted" languages. There's certainly no reason lexical closures can't be compiled (personally, I use CMUCL, so I get the benefit of an optimizing native-code compiler, but bytecode compilers also aren't really interpreters in the literal technical meaning of the word). Even though the Perl and Python projects haven't gotten around to making native code compilers (and now that it took Java to make byte-code VMs seem suddenly not so slow to most of the lemmings in the "programming" (I use the term loosely here) community, they may never need to get around to it), they still have some fairly decent bytecode systems right now.
I like the idea of a dynamic language in the kernel, but looking at this project from a higher level, I think it would be nicer to have a microkernel with some standard set of interfaces for the servers/modules, so that there really could be the possibility of true language independence in writing system code. With Schemix, the fact that the rest of the kernel is written in C makes function loading/unloading and patching of that kernel section at run-time impossible - at least with a microkernel approach, this would be slightly more modularized.
"Both of those statements led me to believe that you were trolling because they were just so silly."
Sorry to mislead you, but I thought the extra "and" in the sentence you quoted would be a bit redundant.
"But I think they're still to be found, even in kernel implementations."
By referring to the 4.3 BSD book, I meant to point out the ugly things about the Unix kernel (the surface ones have of course been mostly fixed by now, but the basic design is still there). It's not the traditional Unix UI I have a problem with (the spartan terminal interaction is a good model for remote work, and I enjoy writing Bash scripts for some things), but rather the whole mess of signals, memory mapping, sockets, pipes, and the entire IPC mess. This is what really makes Unix such a pain - any UI or program you put over it will still have to deal with all these things.
"The Linux kernel, for instance, is very modularized and accessible."
Well, this is relative. You can load/unload kernel modules dynamically, but you really can't interact with them (in kernel space) beyond that. And if you need to change something inside the kernel, the whole thing has to be recompiled (at least with user-mode linux a reboot isn't always necessary). You refer to Mach, and I think microkernels are a step in the right area, but the modularity and accessibility still isn't of a fine enough grain. I guess this is really a problem with C not having any run-time facilities, rather than with Unix itself, but even the Hurd has all the servers written in C. None of the Unix kernels make it particularly easy to write system code in languages other than C.
"Build your own kernel with your own choice of modules and options, hack on the kernel, choose your own C libraries, your own toolset, etc."
Well, this is exactly the problem I referred to above. I'd rather not have to write C code whenever I can avoid it, and Unix makes this difficult. Even with a complete VM environment, there is still a point where the VM ends and the Unix kernel begins. This really only comes up when fixing bugs, but these are frequent enough to make it a real problem (I'm wrestling with randomly broken sigpipe handling in FreeBSD right now). There is lots of dead-tree documentation on the kernel, but as far as run-time information and facilities, there really aren't any. (On the user side, man pages aren't exactly the best model for interactive help, but that's another problem, and I don't think it needs a solution).
"There is a lot more enthusiastic support for do-it-yourselfers in the Linux and BSD community than there is among Windows or Mac users."
I think this is really because Linux and BSD are free software. How many people do you see that have the same level of enthusiasm for Solaris or BSD/OS?
Allright, fine, I accept your trolling challenge, troll.:)
"But modern Windows operating systems are competent and will do the job perfectly well for most people."
That's why "most people" use Windows. The point I was making was that some people use Unix because they have needs that Windows can't fulfill (such as security and basic electronic privacy), and there is no other alternative.
"I never said, 'Everybody uses UNIX because....'"
And I never claimed otherwise.
"Windows uses the BSD networking stack. It's true that you don't get the same level of administrative tools but you can always get better ones."
Maybe we have different definitions of "decent" and "networking." By networking, I mean also the higher-level services provided by the OS, including firewalls and file servers. By decent, I mean something that has decent security support, and doesn't broadcast your browsing history to third parties without your consent. Actually, I find the default networking tools on Unix quite dissatisfactory, but most of them (like ifconfig) I never have to use often, and others I replace with better alternatives (Darren Reed's IPFilter, for example, and I will dump NFS as soon as I find anything better).
"Windows? BeOS? Amiga?"
If you insist on discussing Windows 2000 and up, you might as well stick to recent versions of the other OSes as well (which BeOS and Amiga (which is still pretty much vapor) don't have).
"It's only been in the last 5 years or so that Linux has been getting any kind of real support from hardware manufacturers. And not even a lot of that."
Funny, Linux ran fine enough on all my hardware (and I bet if I still had it 2.2 would) seven years ago.
"At least there's a chance that Objective-C and the OpenStep frameworks will see some acceptance now."
I'd still rather have Smalltalk-80, thanks.
"'Each task has its own separate tool or tools.' 'Modularity.' 'KISS.' 'If it's not absolutely necessary, keep it in user space.' 'Offer the user as much information and flexibility as possible.' 'Everything is possible with a command line.' UNIX has much more of a linguistic mindset than Windows."
Umm, when I said "read it", I really meant that. There is a very wide gap between what you claim the Unix "philosophy" is (honestly, the 'Offer the user as much information and flexibility as possible' bit is a new one to me), and what the actual implementation is like.
"Why would your location have anything to do with it? If you don't enjoy the freedom of technical details, the willingness to help each other learn, and the hobbyist programming environment, so be it. A lot of people enjoy it, however."
I take it you've never heard of Theo de Raadt and his infamous exploits (the fiasco with the abovementioned IPFilter being one of them).
It's interesting that you mention these qualities of Java as being important, and I think they are. But as you mention, Java does have competitors in those fields. I'm not too keen on.NET (although it really is inevitable that it will become a popular language/environment), but Erlang makes a good alternative in all the points you mention. It's really growing phenomenally fast in the past couple of years (especially considering where everything else is heading economically), and of course it does have Ericsson supporting it (at least for telecom applications).
"given enough decades we will eventually produce the workable Lisp Machine."
What exactly do you mean by "workable"? Is it the same definition as that of your "practicality"? As far as history goes, the first Lisp Machine took only a couple of years to be completed, and they were being built until Symbolics went bankrupt in 93 or 94 (LMI had gone under years before, and TI quite intentionally destroyed their Lisp business before selling off their computing division to HP). You can still get a fully working Genera virtual machine for $5000 for an Alpha workstation (but hey, I guess DEC wasn't pragmatic, nor practical, nor affordable, and that's why you can't get a new Alpha anymore).
"C isn't a tenth the language that Lisp is, but it has ten times the speed, can be learned with a tenth the effort, and runs on that same cheap hardware."
"The reason so many people prefer Linux (or other UNIXes) to Windows is the UNIX design philosophies, the rich history, and the community spirit."
Maybe you should look beyond your closest social circle to see why "so many" people prefer Unix to Windows. Many (like me) are forced into it because Windows doesn't work, and Unix is the only other thing that comes close to working (and then it's only two and a half flavors that do). How many other operating systems are there that feature decent network support, a graphical interface, and a decade's worth of drivers for pc hardware? Even Macs ship with essentially NeXTSTEP nowadays.
As far as design philosophies go, read The Design and Implementation of the 4.3BSD UNIX Operating System. I really wish I had the Unix Haters barf bag when I did. I don't know anyone who prefers technical products on the base of their "rich history." Maybe it's because I live in Calgary, but the Unix "community spirit" is certainly not something I want to identify myself with too closely.
Actually, from what I've read, one of Kiczales' motivations for AOP was to simplify the idea of the Meta Object Protocol programming, since apparently not many people could use (or even grasped) the ideas of MOPs. So in a way, the CLOS MOP is a superset of what AOP can do (certainly, the CLOS offers much deeper reflection than Java even pretends to).
Combine this with Pascal Costanza's rather recent (he just revealed it this week) discovery that dynamically bound functions (it's not a CL standard, but he provides a full implementation in his paper in one page of code - try that with Java!) generalize Method Call Invocation and the like, and you really see that AOP isn't anything really new.
It is a way for Kiczales to bring his ideas (and I think they are very good ideas) about programming language reflection to Java. But I don't think this is a good thing, because I don't think Java is a good thing. Chances are only the most trivial parts of the AOP (which is itself a subset of the MOP idea) will make it into mainstream programming in a half-assed way, and then everyone is going to say "we're done, nothing more to do here", just like Java is currently held to be the best OO language ever by some people. (I am especially annoyed by the multiple-inheritance-is-inherently-evil part of the Java camp).
I've recently been reading The Urban Ideal, which is a book of interviews with Paolo Soleri, and in one of them he makes a very lucid statement about the above type of problem, and many of the problems in the world in general. It's now my sig. That is basically what I think of AOP.
Now I know what book not to buy (David Kushner, the guy who wrote the article, has a much hyped book, titled Masters of Doom, due out soon). I was expecting some interesting history and insider bits, but if the article is any indication of the quality of the book, it'll be overhyped, distorted BS.
"In 1991, coding a game called Hovertank, Carmack faced a challenge no programmer had yet tackled: how to get a computer to quickly render a three- dimensional world from a first-person perspective."
I have it on good authority that Carmack was also responsible for pixels, Quicksort, and the plastic spork.
"Carmack presented the idea to id in early 2000, not long after he finished Quake III Arena, but all he got was blank stares. His colleagues wanted to make Doom III, a sure-fire hit, not some futuristic environment the market might not embrace."
According to my interpretation of the teachings of Saint IGNUcius, my suggestion that 486 users should use free software absolves all my sins:)
(If I get run over by a bus while preaching Emacs, I'm automatically entitled to Sainthood on the account of my martyr status - ohh yeah, I got all my bases for the afterlife covered =)
Yeah, dammit, no one bothers to support my 386 anymore! Even the Commodore 64 got an OS upgrade!
But seriously, if you don't want to use OpenGL for your X server, then don't use it. Likewise, if 4 doesn't support your videocard (I heard that some drivers got broken) then use 3.3.6 - anything it breaks your videocard is too slow to display anyway. And if you want games that run on older PCs, buy shareware! People need to use that new hardware for something, and given the choice between getting shiny new hardware and optimizing crap for someone's 486, I choose shiny new hardware. You can always optimize later, and the 486 users should just go use free software so they can compile whatever they need for their own machines.
Oh, and if you have a 386, don't junk it, run FreeDOS!
I typed in coordinates for a large majority of the points anyway (AutoCAD used to have a "line here there" command, IIRC?) because mousing isn't as precise.
AutoCAD has some really nifty point-snapping controls. When I used to do architectural drafting, at the worst I'd have to type in half the coordinates I needed (and fill in the rest). Going back to the parent post, it is also an application that would benefit enormously from a better-designed right-click context sensetive menu (maybe it already has, I haven't used it in a few years now).
Lisp is backwards compared to how mathematics is done therefore making it difficult (relatively) to translate things back and forth.
Then get Lisp macros to do it for you, free of run-time charge.
And the lack of readable "blocking" of code is more annoying than useful, Lisp requires insane amount of parenthesis where most languages would have nice readable plain blocks of code.
If you want to build complex systems fast, nobody is going to turn to LISP for a solution. There isn't one. LISP is a beautiful language which I think any programmer would benefit to learn, but its not a language to get things done with.
LISP is a powerful and interesting language and as a language has its merits. I don't mean to pick on LISP.
Stop contradicting yourself. Also, nowadays the preferred spelling is "Lisp."
What irks me is not that Paul Graham is saying this, but that he might get listened to
So because Graham is promoting Lisp, it's not ok for him to spout off BS? Gosling says some pretty dumb things when evangelizing Java, but I don't see anyone complain (and a lot of people sure seem to listen to him). At least Graham has the decency to admit it's BS.
Perhaps there were other VM-based languages with garbage collection, reflection API, comprehensive cross platform UI, language-based security model, RMI and so on. But none of them really took off. Not to the point that big companies started using them for important applications.
None of them took off because none of them made the compromises that haunt Java. The two biggest reasons Java grew so much so quickly is because it's a lot like C++, and because Sun put enough marketing energy behind it. Nothing in Java is really packaged nicely, it's packaged to be familiar to the hordes of C++ programmers (which is packaged to be familiar to C programmers). Java provides a lot of comfort in that respect, but in no way is it a really outstanding language for development. Yes, a future language might very well be based on Java, but it won't be a good language by any measure.
BTW, I find your comment on the reflection API particularly reflective of the mediocrity and compromises of Java, considering the work Kiczales is doing on Aspect Oriented Programming.
Any of y'all that have programmed LISP know that it takes a long time just to make sure you get your parentheses lined up right
Huh? Why do you need to line up your parenthesis? This isn't Python after all. Maybe you mean balancing parentheses - for that case, maybe something a little better than notepad is needed for editing. I've been programming in C and Java longer (well, two year longer) than I have in Lisp, and with Emacs I find that I write Lisp code faster than I do C code (partly because I don't have to bother with declarations, and partly because I can lay down more of my thought trail meaningfully per line than I can with C - I am considering learning K to see how much denser I can go).
I've looked over a lot of other's code and never had much trouble understanding it. As a matter of fact, my pet project right now is getting several thousand lines of code from a decade old interface toolkit to work under a new constraints solver and generally cleaned up - so far I haven't had any trouble with the Lisp code (now constraint solvers, that's another thing...).
A good rule you should always keep in mind is that an s-expression is a car and a cdr, so just open a paranthesis for a function call and close it after the arguments are over. I only really need to use Emacs' highlighting when going through my own spaghetti numeric expressions. This isn't a problem since s-expressions let you have real macros, and I can just use the inline arithmetic one. With a C-like (or pretty much any non-trivial in-order) syntax this would require essentially writing a new parser for each macro.
C-derived, half-assed OOP damages the brain.
Having spent a year in University temporarily attached to the cult of C++ (I'm still recovering, thanks), I can now spot the tell-tale sign of Java-induced brain damage in this "mainstream programming industry" of yore. Among its more tell-tale signs:
Obsession with encapsulation and single inheritance
Dissing dynamic programming as being "slow" and "difficult to use." This is only true when you don't know any better than to program in a brain dead language. Otherwise, users of Lisp-derived languages have, in one way or another, been using an OO approach to programming even while passing around closures with dynamic data types.
A pathological, unhealthy obsession with language bloat. Having several-hundred odd special case libraries because your language doesn't support dynamic typing is A-OK. C++ designers admitted they lost and just added STLs.
"There is no logical need for a programming language to use dynamic typing or first-class procedures!" This is something that drives Java programmers nuts because they're constantly forced to cut-and-paste code for their stupid interfaces. However, they're not at all upset as this makes them seem more productive in terms of written LOC.
Computing Power makes programming language inefficiency irrelevant. That's why today's native-code Common Lisp compilers feature tail-recursion removal and nearly optimal numerical compilation, while Java programmers are stuck running out of memory and C++ programmers are tweaking bits (the common expressions "penny wise pound foolish" applies very well to code optimization, it seems).
I'm thinking we need to establish some standards of base common sense for Computer Science graduates. They still fail to realize that because something looks easy and everyone's doing it, it doesn't mean it's good. Maybe send them to a "dealing with peer pressure" seminar?
Please check your facts. Development on Lisp started long before the 1960 paper.
We do not know which translation rules McCarthy used in the end of 1958... When McCarthy was working on this function S. Russel saw it and suggested translating it by hand - as he had done so often - and adding it to the program system . McCarthy recalls (22): "... this EVAL was written and published in the paper [I think this is referring to AI memo number 4, where
apply first appeared] and Steve Russell said, look, why don't I program this EVAL and you remember the interpreter, and I said to him, ho, ho, you're confusing theory with practice, this EVAL is intended for reading not for computing. But he went ahead and did it. That is, he compiled the EVAL in my paper into 704 machine code fixing bugs and then advertised this as a LISP interpreter which it certainly was, so at that point LISP had essentially the form that it has today, the S-expression form..."
PS -
Anyone who's done more than a little programming knows that strings need to be "first class" objects. The lack of genuine strings is one of the worst problems in the C language, and the source of most of the published vulnerabilities at CERT.
You do know that Lisp (unlike C) includes higher order procedures that make data representation irrelevant, or are you just speaking out of ignorance?
Slashdot Mirror
Well, I imagine it would be the end of virtual memory systems as we know them. This could make operating systems drastically easier to write, and will hopefully (but I don't think likely) lead the re-birth of persistent "world" operating systems like the Smalltalk virtual machine and Genera. At least this type of memory will finally make it practical to keep all computers on all the time, and so there would be a very strong incentive to move away from Windows and Unix-style systems to something more persistent.
But are they simultaneous (time-sharing) users? The thing about the kind of PC sharing you describe is the trust everyone has in the other users of the system. Multiple accounts would make more sense for keeping application preferences, and I guess you can have everyone in the wheel group and configure the devices and other things to work that way.
I really hope this doesn't become the default among the free Unices.
I like the idea of a dynamic language in the kernel, but looking at this project from a higher level, I think it would be nicer to have a microkernel with some standard set of interfaces for the servers/modules, so that there really could be the possibility of true language independence in writing system code. With Schemix, the fact that the rest of the kernel is written in C makes function loading/unloading and patching of that kernel section at run-time impossible - at least with a microkernel approach, this would be slightly more modularized.
It's interesting that you mention these qualities of Java as being important, and I think they are. But as you mention, Java does have competitors in those fields. I'm not too keen on .NET (although it really is inevitable that it will become a popular language/environment), but Erlang makes a good alternative in all the points you mention. It's really growing phenomenally fast in the past couple of years (especially considering where everything else is heading economically), and of course it does have Ericsson supporting it (at least for telecom applications).
As far as design philosophies go, read The Design and Implementation of the 4.3BSD UNIX Operating System. I really wish I had the Unix Haters barf bag when I did. I don't know anyone who prefers technical products on the base of their "rich history." Maybe it's because I live in Calgary, but the Unix "community spirit" is certainly not something I want to identify myself with too closely.
Combine this with Pascal Costanza's rather recent (he just revealed it this week) discovery that dynamically bound functions (it's not a CL standard, but he provides a full implementation in his paper in one page of code - try that with Java!) generalize Method Call Invocation and the like, and you really see that AOP isn't anything really new.
It is a way for Kiczales to bring his ideas (and I think they are very good ideas) about programming language reflection to Java. But I don't think this is a good thing, because I don't think Java is a good thing. Chances are only the most trivial parts of the AOP (which is itself a subset of the MOP idea) will make it into mainstream programming in a half-assed way, and then everyone is going to say "we're done, nothing more to do here", just like Java is currently held to be the best OO language ever by some people. (I am especially annoyed by the multiple-inheritance-is-inherently-evil part of the Java camp).
I've recently been reading The Urban Ideal , which is a book of interviews with Paolo Soleri, and in one of them he makes a very lucid statement about the above type of problem, and many of the problems in the world in general. It's now my sig. That is basically what I think of AOP.
(If I get run over by a bus while preaching Emacs, I'm automatically entitled to Sainthood on the account of my martyr status - ohh yeah, I got all my bases for the afterlife covered =)
But seriously, if you don't want to use OpenGL for your X server, then don't use it. Likewise, if 4 doesn't support your videocard (I heard that some drivers got broken) then use 3.3.6 - anything it breaks your videocard is too slow to display anyway. And if you want games that run on older PCs, buy shareware! People need to use that new hardware for something, and given the choice between getting shiny new hardware and optimizing crap for someone's 486, I choose shiny new hardware. You can always optimize later, and the 486 users should just go use free software so they can compile whatever they need for their own machines.
Oh, and if you have a 386, don't junk it, run FreeDOS!
BTW, I find your comment on the reflection API particularly reflective of the mediocrity and compromises of Java, considering the work Kiczales is doing on Aspect Oriented Programming.
I've looked over a lot of other's code and never had much trouble understanding it. As a matter of fact, my pet project right now is getting several thousand lines of code from a decade old interface toolkit to work under a new constraints solver and generally cleaned up - so far I haven't had any trouble with the Lisp code (now constraint solvers, that's another thing...).
A good rule you should always keep in mind is that an s-expression is a car and a cdr, so just open a paranthesis for a function call and close it after the arguments are over. I only really need to use Emacs' highlighting when going through my own spaghetti numeric expressions. This isn't a problem since s-expressions let you have real macros, and I can just use the inline arithmetic one. With a C-like (or pretty much any non-trivial in-order) syntax this would require essentially writing a new parser for each macro.
- Obsession with encapsulation and single inheritance
- Dissing dynamic programming as being "slow" and "difficult to use." This is only true when you don't know any better than to program in a brain dead language. Otherwise, users of Lisp-derived languages have, in one way or another, been using an OO approach to programming even while passing around closures with dynamic data types.
- A pathological, unhealthy obsession with language bloat. Having several-hundred odd special case libraries because your language doesn't support dynamic typing is A-OK. C++ designers admitted they lost and just added STLs.
- "There is no logical need for a programming language to use dynamic typing or first-class procedures!" This is something that drives Java programmers nuts because they're constantly forced to cut-and-paste code for their stupid interfaces. However, they're not at all upset as this makes them seem more productive in terms of written LOC.
- Computing Power makes programming language inefficiency irrelevant. That's why today's native-code Common Lisp compilers feature tail-recursion removal and nearly optimal numerical compilation, while Java programmers are stuck running out of memory and C++ programmers are tweaking bits (the common expressions "penny wise pound foolish" applies very well to code optimization, it seems).
I'm thinking we need to establish some standards of base common sense for Computer Science graduates. They still fail to realize that because something looks easy and everyone's doing it, it doesn't mean it's good. Maybe send them to a "dealing with peer pressure" seminar?Please check your facts. Development on Lisp started long before the 1960 paper.
PS -You do know that Lisp (unlike C) includes higher order procedures that make data representation irrelevant, or are you just speaking out of ignorance?