Does Common Lisp lend itself easily to kernel, systems, or real-time programming on mass-market computer architectures?
(Operating System) Kernels? Sure (there's been more than a few projects over the years). Systems? It's a programming language, after all. Oh, you mean highly complex, interactive models of real-world processes? I don't know too many people who are not using Lisp doing that sucessfuly (no, seriously, there really haven't been too many systems like those described in the link period, and most of those were aborted or had failed miserably). Is music performance real-time enough? If not, maybe you'll find robotics fits the bill. When did the Lisp Machines start making a comeback? All those applications run on regular PCs (with the exception of the robots of course).
I know that the developers of a popular PS2 game have disclosed that the game's business logic is written in Lisp
Naughty Dog have developed all of their PS1 and PS2 games (mostly) in Lisp; I didn't know this was a secret. But, a video game's business logic? Man, you need to stop sniffing the Sharpies with the guys from the marketing department.
but would one want to write a 3D engine or a cellphone game in Lisp?
There are a few projects doing 3d games in Lisp (but so far I haven't seen anything in terms of purdy screenshots). The CAD and animation packages in Lisp have shown that it's certainly possible to get good 3d performance (Izware's Mirai has the fastest IK/FK solver for skeleton constraints I have ever seen anywhere - the closest competitor in terms of features, Sega's Animanium, is about four to five times slower (in terms of minimum system requirements for interactively solving a ~two-dozen bone human skeleton - Mirai can do this on a 200Mhz PPro with 192M of RAM; Animanium needs at least an 800Mhz PIII with 256M of RAM). I don't know of any Lisp implementations that support cell phones, so I guess you're out of luck until the cell phone companies start offering Lisp (you're pretty much limited to their supported platforms if you want to develop cell phone games).
I've heard before that python got anonymous functions wrong, and it was argued that the problem is that they don't see the scope in the correct way. Could you please elaborate?... Here the anonymous functions do see their scope (pivot). However, unlike Perl for example, these "functions" really can be only expressions so in that sense they're more limited as. Just out of curiosity, is that what you meant with "python got it wrong"?
Anonymous functions should really be called anonymous subroutines - after all, that's how lambda is implemented in Lisp, Smalltalk, and pretty much any other language with assignment (except of course Python). The functional programming weenies might say otherwise, but I find it inconvenient, especially considering that Python is really an imperative programming language. I wrote a little bit about this in a previous post of mine. As far as scoping problems go (I'm not exaclty sure what the scoping problem is either), I don't think it poses too many problems since you can't do anything except look up the value of variables anyway (I think in this case you can even get away with just copying the value of the variable). Here is an old (probably outdated) usenet post about the issue in Python 2.1 (it seems the main problem is the fact that there is no difference between variable definition and variable assignment in Python). I'm still surprised something as simple as lexical scoping can be confused so thoroughly.
No, it also means that a poor notation was chosen for the members of the finite group.
Is there any realistic alternative for modular arithmetic? And surely you're not also implying that just because x^2 can be i, exponent notation is unsuitable for composition.
Well, 3 + 4 * 5 ==> 35 would be confusing to anyone with a background including elementary school mathematics.
The fact that in some finite groups 2+3 = 1 also seems to be confusing to anyone with a background in elementary school mathematics just means the persons in question only have a background in elementary school mathematics, nothing more.
Bjarne
wanted [emphasis retained] to make C++ more like Smalltalk, but he couldn't because of the backwards compatibility with C requirement.
Are you some kind of sick Bjarne Stroustrup apologist? The people who did Objective C managed to implement way more Smalltalk features than C++, while having way better C compatibility than C++. "Backwards compatibility" is not a viable scapegoat for the design holes of C++.
I can't imagine how you'd dispatch multimethods based on prototype.
How about a parent search? All you would have to determine is whether the current object is the object or a child of the object on which the method is specialized.
You know, I really love it when people flame about Emacs (what's e-macs?) Lisp, because Emacs didn't start out based on Lisp. The original Emacs was based on TECO, which was another text editor with a built-in command language (it looked something like "l z-."g -l @o/CONT/ '" - kind of reminds you of Perl, doesn't it?). But then this brilliant programmer named Bernard Greenberg decided to write an Emacs in Lisp. Now, this was unheard of at the time (the time being late 70s). After all, Lisp was slow, had lots of funny parenthesis, and there really weren't any large interactive programs besides Macsyma written in it. Even funnier was that he was writing it for Multics - there were no other Lisp programs running on it, so it would be the first major Lisp application and interactive screen editor for Multics. After about a year's worth of work, he got it done. And guess what? It was a tremendous success. The users loved it, and pretty soon all the Multics installations were running it. Multics Emacs was convenient, fast, and very handy. So handy, in fact, that secretaries learned to write extensions for it. That's right, secretaries learned to program Lisp. Keep in mind this wasn't the fancy kind of Lisp that you get with GNU Emacs - this was really down and dirty Maclisp - no fancy debugging support or the nice data structures. Now, ask yourself this, if the secretaries could learn to program in Lisp, why can't you? Maybe it's time to switch to a different profession.
Oh, nobody cares about Lisp.
You seem to care enough to spend your time arguing about it.
I have written many small routines in Lisp only to have to scrap them because when it came time to debug the programs I couldn't follow my own logic.
Looks like you have trouble following your own logic when writing English too.
PS - did you know that you can script AutoCAD in Visual Basic? It's been available now for several years.
PPS - Bernard Greenberg wrote a very beautiful paper on Multics Emacs that was published in the Proceedings of the 1980 Lisp Conference. A much larger, mostly technical paper is available on-line, but it doesn't have the same usage stories. RMS recounts the secretaries story in a speech given at ILC 2002. It seems that Multics Emacs had a large impression on the development of GNU Emacs. From this (and another document that he authored) I think that Bernard Greenberg deserves a lot of credit for originating the modern Lisp programming style.
Laundry list of several nifty Lisp features. (It doesn't really matter which ones.)
Boy, you haven't been keeping up with the trolls, have you? Nowadays, it's essential that you mention macros. A lot of languages (Python included) claim to have features like "lambda functions," "lexical closures," etc. that "fanatical Lisp user[s]" once used to tout. A lot of these languages (Python included) don't really implement them, but unfortunately the Lisp fanatics are too busy posting inflammatory messages to learn that, so they have to resort to thinking up crazy new excuses why their programming language can beat up yours.
Implication or outright statement that every feature in programming language in question has already been implemented in Lisp [twenty or thirty years ago].
Lisp weenies tend to love to point out how far behind the times you are. Never mind that most of them aren't even that old.
What? Do I hear someone accusing me of being a Slashdot Lisp troll? Nonsense! Now, if you'll excuse me, I have to get back to pointing out why your programming language sucks...
Can you please explain your claim that a prototype-based object model is "MUCH more space compact"? It seems to me that each such object would be at least twice the size of an equivalent class-based object (assuming message-passing*). Here is a breakdown of what I think each object would need in the prototype system: a pointer to it's parent(s), a table for slots, and a table for any new/shadowed methods. All a class-based object is is a pointer to it's class and a vector for slots.
Another of your points I must contend is that prototype-based object systems can't have strong typing. They certainly can - there'd just be a lot more types. If you mean static typing, that's true, but I wouldn't consider the lack thereof a disadvantage.
* - If you use a multi-method approach, you can get rid of the message table, but I have no idea how you would get good performance out of message dispatch (it's hard enough to do in class-based object systems).
Python is Free as in Speech, Free as in Beer, a unified language with no spun-off dialects.
I have to disagree on your last point. Python is an implementation-defined language, and there currently is more than one implementation. You mention Psyco, which has "some subtle semantic differences (i.e. bugs) with the way Python works; they should not be apparent in most programs." This is not too bad, but there is also Jython, which has some significant deviations from the main Python implementation. Most of these are in terms of Unix hooks and the lack of C FFI, but I consider these to be the strongest features of Python.
One thing I'd like to see cleaned up in Python is support for functional programming. Proponents like to go on and on about how well Python handles FP, but in reality it is awkward at best. The first thing that jumps out is that a lambda body can contain only one expression. This doesn't sound terribly restrictive until you realize that Python has a sharp divide between "expressions" (they may return values) and "statements" (they don't return values, and may have an implicit block), and that there is no explicit block construct. The former makes it kind of hard to make useful closures (since assignment statements are statements, after all), and the latter makes lambdas useless for all but the most trivial uses (after which you have to fall back on named functions for their implicit block). The obvious solution would be to make an explicit block-making expression, but I don't know how this would work with the current practice of specifying all (implicit) block scope through identation. Another annoying thing is the inability to pass operators as HOFs (but then again, this ends up as one of the few uses for the crippled lambda).
One thing that Python totally rules at is structured imperative programming. Here is where the block-indentation really pays off - it allows a minimal syntax in terms of irrelevant punctuation, and mandates a legible writing style. Indeed, in C (and especially in C++), it is very easy (in the case of C++, I think it's encouraged) to write unreadable code - all the Python I've seen and done so far makes me think that one has to work against the language to produce hard to read code. And the C++ integration of Python can't be beat (the only Qt I like is PyQt). As I've stated in a recent posting, I think the best way to write C++ applications is in Python.
I first learned Python because I needed to quickly build a prototype application using Qt, based on some C++ source. The whole thing (including learning Python) took me just two days - granted, it wasn't very big (just north of 1k lines), but the Python version actually worked (the C++ project didn't), it worked quickly, and most impressively my Python code was not very much shorter than the C++ code but took me much less time to write and debug.
Unfortunately, they wanted the thing in C++ (I don't know what this gained them besides bugs and the possibility of more bugs to come). The two things I learned from this experience are that PyQt is a very nice wrapper, and Python is a very good way to write C++ applications. From writing the C++ code, I learned that Qt is indeed an awesome toolkit from the vantage point of a C++ programmer, but unfortunately it is a bloated monster from the perspective of someone not lying in the gutter.
Not quite. Weak is not the opposite of dynamic, but the opposite of strong. Type systems may be either weak or strong, and may be either dynamic or static.
I never claimed the opposite. I consider Java's type system weaker than that of Python and Lisp - explicit conversion or not, casting to Object still loses type information. I wouldn't have a problem with this if Java didn't make it a necessary programming technique.
JVM/.Net are designed from the ground up to support systems languages (like Java and C#). They optimize for static typing and languages where most complexity happens at compile time. Parrot is a VM for languages like Perl, Python, and Ruby, (and TCL, and Lisp etc) whose typing is weaker, and where a runtime eval is a moderately common occurance.
I have to disagree about typing. Python and Lisp (don't know about the others) type systems aren't "weak," but rather dynamic, meaning that they keep type information around at runtime. Java (don't know about C#) is weakly typed in comparison, as you can cast any class to Object and vice-versa, throwing away the type information, and an incorrect cast will only give an error at run-time (and then it may be difficult to track down if the original class type and the one cast to are closely related). This doesn't happen in dynamically typed languages, where you don't need to cast ("coerce" is a more appropriate term for dynamic type systems) objects to a generic type just to put them somewhere.
The Musical Instrument Digital Interface (MIDI) is twenty+plus years old. Imagine if you were trying to do your networking using Banyan... oh, never heard of Banyan? Think on it.
I agree that anything so new has got to be crap. That's why my network is based on 30 year old Ethernet.
On a serious note (no pun indended), I do think MIDI has to go, at least as the main interfacing standard (there's just too many cool, older synthesizers around for it to be gotten rid of completely, and of course some people like their older keyboards). I also think the concept of sequencer (and the whole damn word with all it's connotations too!) has to be gotten rid of. Software allows one to create an infinitely flexible and interactive environment for both composition and play.
Because it's faster and doesn't suck up a lot of memory.
And what's your scientific explanation for this? The "speed" of a language is mostly dependent on implementation, with language features (or lack thereof) playing second fiddle. Unfortunately, C's second fiddle tends to be off-key on modern architectures. Arbitrary pointer arithmetic will cause a large slow-down when accessing unaligned memory locations or uncached pages. It's a lot easier to optimize these bottlenecks away in a language with a strict object reference model. Combine pointer arithmetic with manual memory management, and you get fragmentation and locality lossage, which causes cache misses for your program (I'm ignoring page faults here - hopefully everyone has enough main memory by now!), and allocation problems for the rest of the system. A decent garbage collector will remove both problems. Automatic memory management also eliminates all of the unnecessary copying that goes on in C applications due to unknown object lifetimes. The reason that C programs appear smaller is that the C runtime doesn't really provide anything except for memory allocation. Once you bring in shared libraries to actually do anything useful, the picture changes dramatically (especially with the code bloat of the GCC 3.x series of compilers as compared to 2.9).
If you want to see a compiler that can produce tighter, smaller code than most C compilers, from a supposedly inefficient functional source language, all the while providing type and bounds safety, take a look at OCAML.
It wasn't until recently that John Carmack switched to writting in C++ instead of C for his new DooM ]|[ engine.
Which only serves to reinforce the point about implementations I made above, as C++ has exactly the same memory model and mechanics as C.
For example, critical parts of the Remote Agent autonomous spacecraft system (which flew successfuly on the DS1 mission) were verified using SPIN. Unfortunately, the team did not have enough resources to verify all of the system, and although they found bugs in the parts they did analyze (most (all?) of these were race conditions), during flight one of the parts of the system they didn't verify (but which was thought "safe") caused a race condition. One of the team members talks about it in a USENET post.
Another interesting thing about the RA experiment is the way the error was found and fixed. Because the RA was written in Lisp, it had interactive debugging and loading features, and the race condition was diagnosed without having to stop the experiment, and patched without having to reload the whole system. The same project team member (Erann Gat) said it "proved invaluable in finding and fixing the problem."
Forget for a moment the fact that free software drivers are mostly better made than their proprietary counterparts. Disregard the fact that anyone can fix bugs and make improvements to free drivers without restriction. Let's ignore the fact that you can't port binary-only drivers over to other free OSes. Let's even overlook the problem of getting binary drivers to work on different versions of the Linux kernel. One thing you cannot ignore are the implications of Digital Restrictions Management and laws banning reverse-engineering. If we do not set a precedent for all Linux drivers being released as free software, it may be impossible to run Linux with certain hardware devices without breaking the law (of course if the hardware has mandated hard-wired DRM features, it may be impossible to run Linux period!). The fight against anti-reverse engineering laws has already been lost, but at least the preceding scenario can still be avoided.
I don't believe the current response from the Slashdot community is in any way hypocritical, considering that most of them only want these drivers for the same reason they're using Linux - it doesn't cost anything. Unfortunately, this is just greed, and greed tends to make one's views short-sighted. The only way to ensure the growth of Linux development is to set a precedent for Free Software drivers - it's not much fun having an OS without hardware to run it on!
It was called the Programmer's Apprentice, and sat on top of Interlisp. I think that PA built on top of a lot of features already came with Interlisp, like spelling correction (DWIM - Do What I Mean), versioning tools, undoable assignment, and a program cross-referencing/refactoring tool called Masterscope. What it added was an AI-enabled layer for error detection and source generation. This is kind of neat, but although I've never tried it I don't think this is all that useful of a tool (I can't help but think that anything that deals out programming advice at such a high level will get in the way more often than it helps). Do a google or citeseer search on it - there are about a dozen papers on the project.
I think in the end the lower-level techniques of such a system prove more useful to a programmer. At the very least they have had a higher rate of succesful adoption. Most modern programming languages use Lisp's ideas of uniform object referencing and automatic memory management, and stuff like quasiquoting pre-processors has started popping up for other languages in the past couple of years. Concepts a little higher-level, like AOP and refactoring, go a very long way toward the intelligent programmer's apprentice. Of course, if nothing else all this stuff makes making programming apprentices much easier - just try to imagine building one to deal with C's pointer referencing!
Oh, you mean there were no news articles, radio broadcasts or even eye-witness accounts before 1944? Not even movies? I guess Charlie Chaplin's "The Great Dictator" must have been about some other Jew-hating megalomaniac...
Here is the Verse project page (it used to be on SourceForge for a while before now). The project is basically an implementation of what was once known as Virtual Reality on top of a more modern framework. It's been around for a couple of years (although for most of that time I think Eskil put it on hold as he could not actively develop it).
That being said, I think that Verse is far too low level for the things it is designed to do. I think the Open Croquet project holds far more promise, both because it has a very well developed object-oriented model of virtual worlds (it's based on top of Squeak Smalltalk), and because the scheme it is using for networking has some very good ideas and promises to scale quite nicely (it is based on David Reed's PhD thesis, and it's pretty surprising it hasn't been "rediscovered" before). You can see an impressive (but now quite a bit out of date) video of Alan Kay and another Croquet developer (sorry, I forgot his name!) giving a presentation on the project. Unfortunately, the early demo of the project received a lot of negative attention from some quite ignorant people, and as a result the development of Open Croquet is not currently open to the general public (although if you don't mind becoming a Squeak developer you can certainly participate in it).
Now as to what I think of the funding. It's certainly a lot of money, but I don't entirely agree with the purpose. I think too much of it will be spent on implementation (not that it's a bad thing, as it's all Free Software), but I don't think that either Blender nor Verse foster enough research. Mostly they are doing what has already been done, and at that I don't think they are doing it particularly well.
Re:Language/tools are secondary
on
How C# Was Made
·
· Score: 2, Insightful
There are so many parts of the whole software development process that needs to be improved. With the right process, people and management it is possible to make great software regardless of the language.
There is no such thing as the right process, there is no such thing as the right people, and there certainly is no such thing as the right management, because none of these things can be designed. On the other hand, tools can be designed and implemented to perform optimally, and it is not all that hard to do so. The efficiency gained by using such tools will cover their cost many times, and this is not even considering the psychological effect of craftsmanship that I will discuss below.
When automobile engineers argue, do they argue about the quality of their cars, their features and design or do they childishly bicker about which wrench is better?
A universal quality of nearly all craftsmen is pride in their tools, because almost all craftsmen are overwhelmingly dependent on them (and with some this starts to approach symbiosis). Automobile designers don't argue about wrenches, because they don't use them. Mechanics argue about wrenches. Automobile designers argue about CAD systems.
Why do people spend so much effort fighting over which tool/language is better?
The fact that in this case the tool is the language answers your question. Why do you think the Quebecois resist the anglicization of their language so strongly? Or how about Esperanto? Another thing you should consider is that despite computational universality, the Sapir-Whorf hypothesis applies much more strongly to most programming languages than to natural ones because there is no way to introduce new concepts into those languages.
The truth is - existing software quality sucks. There are a few exceptions, but there are too many poor quality products being shipped everyday sometimes costing millions of dollars. The fault is seldom with the tools or the language of choice.
Just as the fact that a plumber installed your toilet improperly is seldom the fault of his tools. The question now is how do you propose to improve the result of the end product? There is only a finite amount of capable people to do the job (and I believe that this number grows arithmetically while the general population grows almost exponentially). You can't select good "management" (if it even exists), because you cannot choose your own boss. Despite what you imply, process is a function of people and tools, and not some fixed, abstract plan. The only thing you can change quantitatively for the better is tools.
I don't think I'd be going out on a limb to say that you don't really know what generics are as they apply to C++ and Java.
I think I will have to agree with you here.
Given that Lisp is a dynamically typed language in the first place, I'd imagine that "generics" are a very different feature entirely in that language. So what are generics in Lisp, exactly?
What the parent is probably referring to when he talks about Lisp "generics" is macros, which are a totally unrelated concept.* Like you said, Lisp is dynamically typed, and the closest parallel to C++ generics is multimethods.
* - A Lisp macro is a function that manipulates it's arguments before they are evaluated, with the result spliced back in the place of the macro call (this is pretty much the same thing as parse-tree manipulation in languages without explicit program representation). Peter Seibel's upcoming bookexplains them very well.
PS - Note that when I say Lisp here, I'm referring to Common Lisp. Scheme macros ("syntax-case") are a bit different, and Scheme doesn't come with multimethods or other goodies.
I'm not saying that we should hold back progress. If these languages are really better than Java, then by all means support them and encourage people to adopt them. That's not where you're wrong. Where you're wrong is saying that people should "skip" Java for these languages. That is, quite simply, insane, at least if you're trying to program for a living.
No. What the smart programmer does in these situations is to learn the lesser language, write a translator (or two, or three) to the lesser language, and call it "code generation."
Slashdot Mirror
PS - in a recent dick-measuring benchmark (the "Coyote Gulch" floating-point ephemeris calculator), CMU Common Lisp and Steel Bank Common Lisp produced code 5% faster than GCC on a Pentium IV. The participants claim it was "an hour-or-so's work".
at roulette, by Edward Thorp and Claude Shannon.
PS - did you know that you can script AutoCAD in Visual Basic? It's been available now for several years.
PPS - Bernard Greenberg wrote a very beautiful paper on Multics Emacs that was published in the Proceedings of the 1980 Lisp Conference. A much larger, mostly technical paper is available on-line, but it doesn't have the same usage stories. RMS recounts the secretaries story in a speech given at ILC 2002. It seems that Multics Emacs had a large impression on the development of GNU Emacs. From this (and another document that he authored) I think that Bernard Greenberg deserves a lot of credit for originating the modern Lisp programming style.
Boy, you haven't been keeping up with the trolls, have you? Nowadays, it's essential that you mention macros. A lot of languages (Python included) claim to have features like "lambda functions," "lexical closures," etc. that "fanatical Lisp user[s]" once used to tout. A lot of these languages (Python included) don't really implement them, but unfortunately the Lisp fanatics are too busy posting inflammatory messages to learn that, so they have to resort to thinking up crazy new excuses why their programming language can beat up yours.
Implication or outright statement that every feature in programming language in question has already been implemented in Lisp [twenty or thirty years ago].
Lisp weenies tend to love to point out how far behind the times you are. Never mind that most of them aren't even that old.
What? Do I hear someone accusing me of being a Slashdot Lisp troll? Nonsense! Now, if you'll excuse me, I have to get back to pointing out why your programming language sucks...
Another of your points I must contend is that prototype-based object systems can't have strong typing. They certainly can - there'd just be a lot more types. If you mean static typing, that's true, but I wouldn't consider the lack thereof a disadvantage.
* - If you use a multi-method approach, you can get rid of the message table, but I have no idea how you would get good performance out of message dispatch (it's hard enough to do in class-based object systems).
One thing I'd like to see cleaned up in Python is support for functional programming. Proponents like to go on and on about how well Python handles FP, but in reality it is awkward at best. The first thing that jumps out is that a lambda body can contain only one expression. This doesn't sound terribly restrictive until you realize that Python has a sharp divide between "expressions" (they may return values) and "statements" (they don't return values, and may have an implicit block), and that there is no explicit block construct. The former makes it kind of hard to make useful closures (since assignment statements are statements, after all), and the latter makes lambdas useless for all but the most trivial uses (after which you have to fall back on named functions for their implicit block). The obvious solution would be to make an explicit block-making expression, but I don't know how this would work with the current practice of specifying all (implicit) block scope through identation. Another annoying thing is the inability to pass operators as HOFs (but then again, this ends up as one of the few uses for the crippled lambda).
One thing that Python totally rules at is structured imperative programming. Here is where the block-indentation really pays off - it allows a minimal syntax in terms of irrelevant punctuation, and mandates a legible writing style. Indeed, in C (and especially in C++), it is very easy (in the case of C++, I think it's encouraged) to write unreadable code - all the Python I've seen and done so far makes me think that one has to work against the language to produce hard to read code. And the C++ integration of Python can't be beat (the only Qt I like is PyQt). As I've stated in a recent posting, I think the best way to write C++ applications is in Python.
Unfortunately, they wanted the thing in C++ (I don't know what this gained them besides bugs and the possibility of more bugs to come). The two things I learned from this experience are that PyQt is a very nice wrapper, and Python is a very good way to write C++ applications. From writing the C++ code, I learned that Qt is indeed an awesome toolkit from the vantage point of a C++ programmer, but unfortunately it is a bloated monster from the perspective of someone not lying in the gutter.
and never get any better again." -- Kurt Vonnegut, Jr.
On a serious note (no pun indended), I do think MIDI has to go, at least as the main interfacing standard (there's just too many cool, older synthesizers around for it to be gotten rid of completely, and of course some people like their older keyboards). I also think the concept of sequencer (and the whole damn word with all it's connotations too!) has to be gotten rid of. Software allows one to create an infinitely flexible and interactive environment for both composition and play.
If you want to see a compiler that can produce tighter, smaller code than most C compilers, from a supposedly inefficient functional source language, all the while providing type and bounds safety, take a look at OCAML.
Which only serves to reinforce the point about implementations I made above, as C++ has exactly the same memory model and mechanics as C.Another interesting thing about the RA experiment is the way the error was found and fixed. Because the RA was written in Lisp, it had interactive debugging and loading features, and the race condition was diagnosed without having to stop the experiment, and patched without having to reload the whole system. The same project team member (Erann Gat) said it "proved invaluable in finding and fixing the problem."
I don't believe the current response from the Slashdot community is in any way hypocritical, considering that most of them only want these drivers for the same reason they're using Linux - it doesn't cost anything. Unfortunately, this is just greed, and greed tends to make one's views short-sighted. The only way to ensure the growth of Linux development is to set a precedent for Free Software drivers - it's not much fun having an OS without hardware to run it on!
I think in the end the lower-level techniques of such a system prove more useful to a programmer. At the very least they have had a higher rate of succesful adoption. Most modern programming languages use Lisp's ideas of uniform object referencing and automatic memory management, and stuff like quasiquoting pre-processors has started popping up for other languages in the past couple of years. Concepts a little higher-level, like AOP and refactoring, go a very long way toward the intelligent programmer's apprentice. Of course, if nothing else all this stuff makes making programming apprentices much easier - just try to imagine building one to deal with C's pointer referencing!
Oh, you mean there were no news articles, radio broadcasts or even eye-witness accounts before 1944? Not even movies? I guess Charlie Chaplin's "The Great Dictator" must have been about some other Jew-hating megalomaniac...
That being said, I think that Verse is far too low level for the things it is designed to do. I think the Open Croquet project holds far more promise, both because it has a very well developed object-oriented model of virtual worlds (it's based on top of Squeak Smalltalk), and because the scheme it is using for networking has some very good ideas and promises to scale quite nicely (it is based on David Reed's PhD thesis, and it's pretty surprising it hasn't been "rediscovered" before). You can see an impressive (but now quite a bit out of date) video of Alan Kay and another Croquet developer (sorry, I forgot his name!) giving a presentation on the project. Unfortunately, the early demo of the project received a lot of negative attention from some quite ignorant people, and as a result the development of Open Croquet is not currently open to the general public (although if you don't mind becoming a Squeak developer you can certainly participate in it).
Now as to what I think of the funding. It's certainly a lot of money, but I don't entirely agree with the purpose. I think too much of it will be spent on implementation (not that it's a bad thing, as it's all Free Software), but I don't think that either Blender nor Verse foster enough research. Mostly they are doing what has already been done, and at that I don't think they are doing it particularly well.
There is no such thing as the right process, there is no such thing as the right people, and there certainly is no such thing as the right management, because none of these things can be designed. On the other hand, tools can be designed and implemented to perform optimally, and it is not all that hard to do so. The efficiency gained by using such tools will cover their cost many times, and this is not even considering the psychological effect of craftsmanship that I will discuss below.
A universal quality of nearly all craftsmen is pride in their tools, because almost all craftsmen are overwhelmingly dependent on them (and with some this starts to approach symbiosis). Automobile designers don't argue about wrenches, because they don't use them. Mechanics argue about wrenches. Automobile designers argue about CAD systems.
The fact that in this case the tool is the language answers your question. Why do you think the Quebecois resist the anglicization of their language so strongly? Or how about Esperanto? Another thing you should consider is that despite computational universality, the Sapir-Whorf hypothesis applies much more strongly to most programming languages than to natural ones because there is no way to introduce new concepts into those languages.
Just as the fact that a plumber installed your toilet improperly is seldom the fault of his tools. The question now is how do you propose to improve the result of the end product? There is only a finite amount of capable people to do the job (and I believe that this number grows arithmetically while the general population grows almost exponentially). You can't select good "management" (if it even exists), because you cannot choose your own boss. Despite what you imply, process is a function of people and tools, and not some fixed, abstract plan. The only thing you can change quantitatively for the better is tools.
* - A Lisp macro is a function that manipulates it's arguments before they are evaluated, with the result spliced back in the place of the macro call (this is pretty much the same thing as parse-tree manipulation in languages without explicit program representation). Peter Seibel's upcoming book explains them very well.
PS - Note that when I say Lisp here, I'm referring to Common Lisp. Scheme macros ("syntax-case") are a bit different, and Scheme doesn't come with multimethods or other goodies.