Ah, I see, you live by the "tough man" approach to programming. The fact is, people keep shooting themselves in the foot with this. It's unexpected because it's different from almost any other scripting language. And it's easy to get the same functionality with a different notation. That's why it's a design flaw and that's why the Bell Labs successor to the Bourne shell fixed it.
This may help a little, but in general, people haven't figured out how to make FPGA-based computing sufficiently useful, cheap, and easy in order for it to catch on. Programming an FPGA is still rather hard and the architecture limits severely what you can do. And there is the chicken-and-egg problem with the boards: if you write software for them, few people can run it, and few people are motivated to buy a board because there is no software that uses it. Right now, you are probably a lot better off buying a dual processor board or a cluster than an FPGA add-on.
This is really a problem in how the Bourne shell handles variables. Lots of UNIX scripts fail when file names contain spaces, which is why most people don't use spaces in file names.
The folks at Bell Labs seem to have realized that this was a mistake, which is why the "rc" shell (also available for Linux) now handles things differently: variable substitution does not result in re-tokenizing.
I challenge you to produce any kind of hard, real evidence that the viewing public, or even a significant majority of it, has ever "asked for useful, interesting, educational content."
The public is asking for better education, better public health, better jobs, and less crime. It is the responsibility of a democractically elected government to work towards those ends. And, whether the viewing public likes it or not, in order to achieve those goals, television needs to change.
If you want to see what was available essentially in 1980, you can get yourself a copy of Squeak. Squeak contains a complete Smalltalk-80 environment with the original Smalltalk-80 user interface (I think there is also a Smalltalk-76 emulator inside it).
Apple's user interface improved on Smalltalk-80 by making it easier to learn (more user interface functions are represented by explicit graphical elements) and with its graphical design. But I have a hard time coming up with any area in which Apple improved on Smalltalk-80 in terms of functionality or usability for experienced users. Even today, I find the Smalltalk-80 interface better than what you get on the Macintosh. Furthermore, Smalltalk-80 came with a development and debugging environment that puts even the best C++ and Java environments available today to shame.
Like many other people who have been in the computer industry for more than two decades, we can't help but shake the feeling that innovation in software has basically stopped since the 1980's; most of the change that we have experienced has been to make things "bigger" and "faster", but very little seems to have gotten "better".
To all the people who are working on software like Gnome, Java, KDE, etc., my message is: do your homework first. Find and use some of the old user interfaces. There is way too much reinventing the wheel, mostly very poorly.
GNU Emacs and XEmacs are using tiling for their windows, and they are one of the most widely-used user interfaces.
It's unfortunate that that paradigm hasn't caught on that much for independent graphical applications. I think the reason for that is that the Smalltalk paradigm of overlapping independent windows is very easy to implement, it's general, and it looks neat. Doing a good job at tiling window management is much harder. So, Macintosh, Windows, and X11 just followed the easy and flashy path.
Muscle memory (for the most part) doesn't work with current interfaces because the mouse performs relative positioning. Even if you put the menu bar along a screen edge, as in the Macintosh interface, you still need visual feedback of the mouse cursor position in order to position the mouse.
There are a few mouse-based interfaces where muscle memory works: the mouse wheel (in a very simple way), multiple mouse buttons, and pie menus. You will notice that the Mac uses none of those, but rather clings to a notion of "simplicity". Simplicity sells machines, but it doesn't make for an efficient user interface once people have used the machine for a few months or years.
Yes, in Tog's experiments, mousing is faster than keyboarding--in the specific population and with the specific applications Apple chose to test. Just read the description of the experiments to see how biased the experiments are.
User interface research is pseudo-scientific: it gives the appearance of being scientific, but it tells you almost nothing in most cases. When it does tell you something, it usually tells you something about the performance of "naive" user populations, because that's the kind of people a company like Apple is most interested in (once users are experienced, they are already stuck with a platform). It is very unfortunate that this kind of stuff gets published and that people then use it to make decisions.
Bell Labs holds a key patent on the implementation of overlapping windows (I think they never tried to enforce it). Work at MIT also involved overlapping windows.
You don't need to pay anybody to develop Motif applications: it comes with the OS for free, and you write your applications for it. Furthermore, Sun already is part of the consortium that owns the rights.
Right now, Qt is owned by a small company with definite exclusionary and monopolistic tendencies. If Sun or IBM buy Troll Tech and distribute Qt under LGPL or BSD, they don't "own" it in any interesting sense and everybody benefits. I'm all for it.
For most people, Gnome certainly beats OpenWindows. But if you don't like the Gnome desktop (I don't particularly) and the icons, you certainly have enough choices: XFCE, icewm, and many others. That's the nice thing about X11: you get the choice.
The business model is wrong, and it's always been wrong. It's been wrong not for the networks, which have traditionally been hugely profitable, it's been wrong for the public interest. The public has given use of the public airwaves to television companies almost for free, asking for useful, interesting, educational content in return. The networks instead have given us hypnotic junk in return, junk intended not to educate but to manipulate people into buying stuff. And anybody who thinks that the programs that the networks show are actually what people want (often making some kind of "market forces" argument) is kidding himself.
In my opinion, the public airwaves should be given only to not-for-profits, with a mix of public funding, fees, donations, and simple sponsorships. Then we wouldn't have to worry about "skipping commercials", and the content we get would be of higher quality.
Microsoft has claimed over and over again that Windows has lower TCO (total cost of ownership) despite the higher license fees, because it is supposedly better supported and supposedly easier to use. Other industry "experts" have made the same claims.
Amazon's experience suggests that Microsoft's claims are false: not only do you save on licensing costs, you also save on support costs, and possibly other costs.
Say goodbye to UNIX support. It's expensive to develop for UNIX compared to Windows. VB programmers are a dime a dozen and can be hired for $30k a year, so why would a software company want to hire anyone else? The former "LNUX" will soon be in bed with Microsoft before we know it.
That makes no sense. If UNIX support were as expensive as you say, it would be a highly attractive business proposition for a support provider. The reality is that UNIX/Linux support costs about as much as Windows support, but that companies need a lot less of it. Our support costs for UNIX systems are a tiny fraction of those for Windows, for example.
VA has no reason to support Slashdot, Sourceforge, Themes.org, and other very expensive sites that produce zero revenue.
I don't see why themes.org or Slashdot should be particularly expensive sites, at least in principle.
The business community will believe "Linux is dead" and it will be an uphill struggle to regain their confidence.
Who cares? If company A wants to pay several times as much for their software, maintenance, and support because it runs MS Windows than company B that runs Linux, let company A face the financial consequences. It's a free market, and stupidity has its costs.
Not a Linux company and not a company that has a vested interest in promoting open source. Back in the day, VA's success rested on the success of the Open Source movement. Not any longer - as a software company, they are going to be producing commercial wares that compete with open source solutions.
Who cares? VA Linux was not needed for the growth of open source software, and if they go away, life will go on. The nice thing about open source software is that contributions are, and remain, public and available no matter what happens to the companies involved.
We better get used to the fact that most open source software will have been created and supported by failed companies. That's not because open source strategies make companies fail, but because closed source software doesn't survive the failure of its creators.
So, let's stop belly-aching and get on with life. If VA Software keeps contributing to open source, great. If not, it doesn't matter.
Good data structure libraries in C/C++ are useful. The problem is that if you call any code not under your control, all bets are off: it can trash any data structure anywhere, and you won't even know it. With Java, you are guaranteed that any code you call (even dynamically loaded code), your own or someone else's, it will not trash data that the language specifies it doesn't have access to. That is one of the reasons why Java is so much better for component-based software development than C/C++.
As the article points out correctly, press photographs are not a historically accurate record of reality anyway--they already express a point of view (literally and figuratively). For example, experienced photographers can usually easily make a defendant in a trial look sympathetic or unsympathetic through selection of framing, angle, lighting, and timing. Now we add in-camera shot selection to that, so what?
Furthermore, the need for shot selection will likely disappear--there is little reason for image sensors to keep growing, but camera memory will keep growing. You can already get 512Mbyte solid state flash cards, and you will likely be able to get gigabytes in stamp-sized packages soon.
The editing and selection that should concern us much more is the selection of news stories itself, which tends to be driven by sensationalism, corporate sponsorship and business relationships, and political biases. And those biases are not giong to get fixed by keeping around a few more pictures locked away in an archive somewhere.
USB was never supposed to "eliminate all the wires to your PC", it was supposed to be a low-cost, reasonably fast interconnect replacing the mess of parallel, serial, PS/2, and low-power connections. It has succeeded very well at that. It also makes driver development easier because it standardizes so much more.
USB2 is a mistake; it has all the cost of FireWire without the functionality. It will probably be widely available, but it won't replace FireWire.
Bluetooth covers roughly the same space as USB, but it offers wireless convenience. I hope it will catch on and become cheap: the less wires the better as far as I'm concerned. And if Bluetooth is done right, it should be reasonably secure (certainly a lot more secure than the Logitech wireless numbers people buy right now).
The only reason why your camera, your PDA, your printer, your mouse, your keyboard, and all that are not on Ethernet is because Ethernet is too expensive. If you could make Ethernet as cheap as USB, serial, or parallel, many devices would have used it long ago (there are also configuration and real-time issues, but those would have been worked out).
If Bluetooth manages to live up to its claims of low power consumption and low price compared to 802.11b, then it offers a genuine advantage. If not, it's just another superfluous standard.
Java has a standardized C interface. Something like SWIG (swig.org) makes accessing it pretty trivial. Several vendors also make compilers that expose C++ classes directly as Java classes.
The problem with mixed language programming like that is that C/C++ code is unsafe, and that the semantics of C/C++ code often differ wildly from the semantics of the HLL. For example, how do you extend a C++ class with Python code and pass an instance of that back to a C++ class?
The point about Java is that it is a pretty "fast language" (i.e., its common implementations are fast). You can write reasonably efficient image processing or string handling code in Java if you put your mind to it. So there is generally no need to use C/C++ other than for interfacing to system services. As a result, you get more portability and more runtime safety.
Yes, you can compile Java reasonably well both with a batch compiler (like gcj or Jove) and with a JIT (like the Sun, IBM, and Intel runtimes). And you actually get good performance out of it.
The nice thing about JITs is that you don't have to worry about figuring out what to optimize: the runtime does it for you, and it is doing a better and better job at it.
Nobody has ever produced a compiler for Python or Perl that gave performance close to a good Java compiler. The situation with Lisp and Smalltalk is a bit more complex; there are good compilers for them, but getting good performance out of those usually ends up being more work than getting good performance out of Java.
I wouldn't go that far. There are several things impeding Java optimization: 1. It occurs at runtime. With C/C++, you have unlimited time to optimize the code. With Java, time spent optimizing counts against program execution time.
For any reasonably compute intensive task, compilation and optimization time is negligible. You can see that either by instrumenting a Java runtime. Or you can just look at where C/C++ compilers spend their time (a lot of reparsing of header files, as well as semantic checking and linking, none of which are incurred by Java compilers) and what fraction of the code of any real program really needs to be optimized.
2. Java bytecodes use a stack-based paradigm, which is notoriously hard to optimize. Most C compilers have a register-based paradigm, whose optimization is well-understood (if perhaps not yet perfected).
If the JVM supported general stack-based computations that would be true. However, the JVM prohibits general stack-based computations: it requires that the stack is in a "defined state" (in a certain sense) at each byte code. The upshot is that Java byte code is essentially just a binary postfix representation of the source code. Turning that into native code is no different from what the C compiler does. (In fact, the claims in the introduction to your JHP paper are wrong, precisely because Java does not use a general stack-based architecture.)
3. Java programs load classes dynamically. Every new class has the potential to clobber any assumptions you made in order to achieve any agressive dynamic optimizations. In the worst case, a Java runtime has to have all the functionality of "make" so it can compute what has changed and re-compile it as necessary.
Well, so what? The necessary dependency tracking is both trivial and fast. Furthermore, because of the way Java is designed (and unlike C), there are only very few important dynamic optimizations that dynamic loading can invalidate. Note that Java does not support class reloading in high performance code (it's supported only for debugging).
Dynamic optimization has a lot of promise, but with the state of technology today, it's hard to argue that C isn't faster than Java.
Dynamic optimization is completely up to the task of compiling Java as well as any C compiler compiles C code. Java pays a little bit of overhead for runtime safety (less than 20% by most estimates) and there are a few areas of Java where the language definition unnecessarily prohibits optimizations (this is being addressed). Except for those areas, Java as a language is pretty much as easy and efficiently compilable as C or C++. In fact, if anything, Java has additional opportunities for optimization because of its more limited pointer model. Dynamic optimization and (closely related) partial evaluation also have been understood for more than a decade, so this isn't exactly cutting edge.
Of course, Java libraries are often pretty slow. But that's because many Java libraries are written with a lot (too much in many cases) generality and abstraction.
Note, of course, that batch compilers for Java exist, but they generally perform no better than a good JIT these days.
If there is no written contract and if he has received no payments, they probably don't have a legal leg to stand on. Why any of this is relevant to Slashdot, I don't know, however.
It isn't just about ease. Dynamically typed programming languages allow you to radically decrease your line count and all else being equal that reduces your original development cost and your maintenance costs. We could argue whether "all else is equal" but I think rather that I'll point you to some evidence that significant systems can be created in dynamically typed programming languages. Python case study [lyra.org], Using Lisp to Beat your Competition [slashdot.org], Smalltalk in the Large [bytesmiths.com]
I have nearly 20 years of experience with Lisp and I can tell you that it doesn't live up to the hype. For large, multi-programmer projects, the mix of static and dynamic features Java offers works much better.
You don't have to look much further than the few open source projects based on Lisp and Smalltalk. GNU Emacs is very slow at releasing new versions and elisp packages are a mess; jedit is getting close to similar functionality after only a few years in existence. The Squeak implementation of Smalltalk is great, but it, too, has turned into a complex and largely undocumented mess. Languages like Smalltalk, Python, and Lisp are great for smaller projects and for single programmer projects.
In general, Java is bytecompiled, just as most scripting languages are. Sometimes Java can be JIT-ted to native code. Sometimes scripting languages can be JIT-ted to native code.
That's a mischaracterization. With the major Java implementations (Sun, IBM, Intel), Java is always JITted into efficient native code, and the Java byte-code is well-suited to that. None of the major scripting languages (Perl, Python, Tcl, Ruby) have a widely-used JIT, and nobody has ever demonstrated a native code compiler for those languages that results in performance anywhere near native code. CMU CommonLisp, arguably one of the best compilers for dynamic languages, does very poorly without type declarations.
I don't know about.NET, but Java is compiled into bytecode, which is run on a natively compiled byetcode interpreter. Just like Perl, Python, Ruby, etc. are. This has been a major piece of Java FUD for the longest time - it pretends to be a compiled language, because it doesn't want to be seen as "just another scripting language".
Sorry, but you don't understand how Java implementations work. When you run "javac", you produce byte code. That byte code gets turned into native code before being executed when it is part of a performance critical section--the native code compiler is part of the Java runtime.
Python, Perl, or Ruby do not have anything comparable: they are implemented as strict byte code interpreters (except for Jython, which piggy-backs on the Java runtime). In fact, the Java approach is better than the kind of batch compilation found in C/C++ because it allows for a lot more optimizations. For example, the JDK inlines code among dynamically loaded components.
As for the libraries and penetration available for Java, do you not think that if Sun had developed and spend untold millions marketing Perl or Python that they would not be in the same position?
Python or Perl are no replacement for Java. With a few exceptions, Java code runs at speeds pretty close to C/C++ under the JDK. Python and Perl implementations are orders of magnitude slower and nobody has figured out how to compile them into efficient code.
Slashdot Mirror
Ah, I see, you live by the "tough man" approach to programming. The fact is, people keep shooting themselves in the foot with this. It's unexpected because it's different from almost any other scripting language. And it's easy to get the same functionality with a different notation. That's why it's a design flaw and that's why the Bell Labs successor to the Bourne shell fixed it.
This may help a little, but in general, people haven't figured out how to make FPGA-based computing sufficiently useful, cheap, and easy in order for it to catch on. Programming an FPGA is still rather hard and the architecture limits severely what you can do. And there is the chicken-and-egg problem with the boards: if you write software for them, few people can run it, and few people are motivated to buy a board because there is no software that uses it. Right now, you are probably a lot better off buying a dual processor board or a cluster than an FPGA add-on.
The folks at Bell Labs seem to have realized that this was a mistake, which is why the "rc" shell (also available for Linux) now handles things differently: variable substitution does not result in re-tokenizing.
The public is asking for better education, better public health, better jobs, and less crime. It is the responsibility of a democractically elected government to work towards those ends. And, whether the viewing public likes it or not, in order to achieve those goals, television needs to change.
Apple's user interface improved on Smalltalk-80 by making it easier to learn (more user interface functions are represented by explicit graphical elements) and with its graphical design. But I have a hard time coming up with any area in which Apple improved on Smalltalk-80 in terms of functionality or usability for experienced users. Even today, I find the Smalltalk-80 interface better than what you get on the Macintosh. Furthermore, Smalltalk-80 came with a development and debugging environment that puts even the best C++ and Java environments available today to shame.
Like many other people who have been in the computer industry for more than two decades, we can't help but shake the feeling that innovation in software has basically stopped since the 1980's; most of the change that we have experienced has been to make things "bigger" and "faster", but very little seems to have gotten "better".
To all the people who are working on software like Gnome, Java, KDE, etc., my message is: do your homework first. Find and use some of the old user interfaces. There is way too much reinventing the wheel, mostly very poorly.
It's unfortunate that that paradigm hasn't caught on that much for independent graphical applications. I think the reason for that is that the Smalltalk paradigm of overlapping independent windows is very easy to implement, it's general, and it looks neat. Doing a good job at tiling window management is much harder. So, Macintosh, Windows, and X11 just followed the easy and flashy path.
There are a few mouse-based interfaces where muscle memory works: the mouse wheel (in a very simple way), multiple mouse buttons, and pie menus. You will notice that the Mac uses none of those, but rather clings to a notion of "simplicity". Simplicity sells machines, but it doesn't make for an efficient user interface once people have used the machine for a few months or years.
User interface research is pseudo-scientific: it gives the appearance of being scientific, but it tells you almost nothing in most cases. When it does tell you something, it usually tells you something about the performance of "naive" user populations, because that's the kind of people a company like Apple is most interested in (once users are experienced, they are already stuck with a platform). It is very unfortunate that this kind of stuff gets published and that people then use it to make decisions.
Bell Labs holds a key patent on the implementation of overlapping windows (I think they never tried to enforce it). Work at MIT also involved overlapping windows.
You don't need to pay anybody to develop Motif applications: it comes with the OS for free, and you write your applications for it. Furthermore, Sun already is part of the consortium that owns the rights.
Right now, Qt is owned by a small company with definite exclusionary and monopolistic tendencies. If Sun or IBM buy Troll Tech and distribute Qt under LGPL or BSD, they don't "own" it in any interesting sense and everybody benefits. I'm all for it.
For most people, Gnome certainly beats OpenWindows. But if you don't like the Gnome desktop (I don't particularly) and the icons, you certainly have enough choices: XFCE, icewm, and many others. That's the nice thing about X11: you get the choice.
In my opinion, the public airwaves should be given only to not-for-profits, with a mix of public funding, fees, donations, and simple sponsorships. Then we wouldn't have to worry about "skipping commercials", and the content we get would be of higher quality.
Amazon's experience suggests that Microsoft's claims are false: not only do you save on licensing costs, you also save on support costs, and possibly other costs.
So, yes, this is news, and it's not obvious.
That makes no sense. If UNIX support were as expensive as you say, it would be a highly attractive business proposition for a support provider. The reality is that UNIX/Linux support costs about as much as Windows support, but that companies need a lot less of it. Our support costs for UNIX systems are a tiny fraction of those for Windows, for example.
VA has no reason to support Slashdot, Sourceforge, Themes.org, and other very expensive sites that produce zero revenue.
I don't see why themes.org or Slashdot should be particularly expensive sites, at least in principle.
The business community will believe "Linux is dead" and it will be an uphill struggle to regain their confidence.
Who cares? If company A wants to pay several times as much for their software, maintenance, and support because it runs MS Windows than company B that runs Linux, let company A face the financial consequences. It's a free market, and stupidity has its costs.
Not a Linux company and not a company that has a vested interest in promoting open source. Back in the day, VA's success rested on the success of the Open Source movement. Not any longer - as a software company, they are going to be producing commercial wares that compete with open source solutions.
Who cares? VA Linux was not needed for the growth of open source software, and if they go away, life will go on. The nice thing about open source software is that contributions are, and remain, public and available no matter what happens to the companies involved.
We better get used to the fact that most open source software will have been created and supported by failed companies. That's not because open source strategies make companies fail, but because closed source software doesn't survive the failure of its creators.
So, let's stop belly-aching and get on with life. If VA Software keeps contributing to open source, great. If not, it doesn't matter.
Good data structure libraries in C/C++ are useful. The problem is that if you call any code not under your control, all bets are off: it can trash any data structure anywhere, and you won't even know it. With Java, you are guaranteed that any code you call (even dynamically loaded code), your own or someone else's, it will not trash data that the language specifies it doesn't have access to. That is one of the reasons why Java is so much better for component-based software development than C/C++.
Furthermore, the need for shot selection will likely disappear--there is little reason for image sensors to keep growing, but camera memory will keep growing. You can already get 512Mbyte solid state flash cards, and you will likely be able to get gigabytes in stamp-sized packages soon.
The editing and selection that should concern us much more is the selection of news stories itself, which tends to be driven by sensationalism, corporate sponsorship and business relationships, and political biases. And those biases are not giong to get fixed by keeping around a few more pictures locked away in an archive somewhere.
USB2 is a mistake; it has all the cost of FireWire without the functionality. It will probably be widely available, but it won't replace FireWire.
Bluetooth covers roughly the same space as USB, but it offers wireless convenience. I hope it will catch on and become cheap: the less wires the better as far as I'm concerned. And if Bluetooth is done right, it should be reasonably secure (certainly a lot more secure than the Logitech wireless numbers people buy right now).
If Bluetooth manages to live up to its claims of low power consumption and low price compared to 802.11b, then it offers a genuine advantage. If not, it's just another superfluous standard.
The problem with mixed language programming like that is that C/C++ code is unsafe, and that the semantics of C/C++ code often differ wildly from the semantics of the HLL. For example, how do you extend a C++ class with Python code and pass an instance of that back to a C++ class?
The point about Java is that it is a pretty "fast language" (i.e., its common implementations are fast). You can write reasonably efficient image processing or string handling code in Java if you put your mind to it. So there is generally no need to use C/C++ other than for interfacing to system services. As a result, you get more portability and more runtime safety.
The nice thing about JITs is that you don't have to worry about figuring out what to optimize: the runtime does it for you, and it is doing a better and better job at it.
Nobody has ever produced a compiler for Python or Perl that gave performance close to a good Java compiler. The situation with Lisp and Smalltalk is a bit more complex; there are good compilers for them, but getting good performance out of those usually ends up being more work than getting good performance out of Java.
For any reasonably compute intensive task, compilation and optimization time is negligible. You can see that either by instrumenting a Java runtime. Or you can just look at where C/C++ compilers spend their time (a lot of reparsing of header files, as well as semantic checking and linking, none of which are incurred by Java compilers) and what fraction of the code of any real program really needs to be optimized.
2. Java bytecodes use a stack-based paradigm, which is notoriously hard to optimize. Most C compilers have a register-based paradigm, whose optimization is well-understood (if perhaps not yet perfected).
If the JVM supported general stack-based computations that would be true. However, the JVM prohibits general stack-based computations: it requires that the stack is in a "defined state" (in a certain sense) at each byte code. The upshot is that Java byte code is essentially just a binary postfix representation of the source code. Turning that into native code is no different from what the C compiler does. (In fact, the claims in the introduction to your JHP paper are wrong, precisely because Java does not use a general stack-based architecture.)
3. Java programs load classes dynamically. Every new class has the potential to clobber any assumptions you made in order to achieve any agressive dynamic optimizations. In the worst case, a Java runtime has to have all the functionality of "make" so it can compute what has changed and re-compile it as necessary.
Well, so what? The necessary dependency tracking is both trivial and fast. Furthermore, because of the way Java is designed (and unlike C), there are only very few important dynamic optimizations that dynamic loading can invalidate. Note that Java does not support class reloading in high performance code (it's supported only for debugging).
Dynamic optimization has a lot of promise, but with the state of technology today, it's hard to argue that C isn't faster than Java.
Dynamic optimization is completely up to the task of compiling Java as well as any C compiler compiles C code. Java pays a little bit of overhead for runtime safety (less than 20% by most estimates) and there are a few areas of Java where the language definition unnecessarily prohibits optimizations (this is being addressed). Except for those areas, Java as a language is pretty much as easy and efficiently compilable as C or C++. In fact, if anything, Java has additional opportunities for optimization because of its more limited pointer model. Dynamic optimization and (closely related) partial evaluation also have been understood for more than a decade, so this isn't exactly cutting edge.
Of course, Java libraries are often pretty slow. But that's because many Java libraries are written with a lot (too much in many cases) generality and abstraction.
Note, of course, that batch compilers for Java exist, but they generally perform no better than a good JIT these days.
If there is no written contract and if he has received no payments, they probably don't have a legal leg to stand on. Why any of this is relevant to Slashdot, I don't know, however.
I have nearly 20 years of experience with Lisp and I can tell you that it doesn't live up to the hype. For large, multi-programmer projects, the mix of static and dynamic features Java offers works much better.
You don't have to look much further than the few open source projects based on Lisp and Smalltalk. GNU Emacs is very slow at releasing new versions and elisp packages are a mess; jedit is getting close to similar functionality after only a few years in existence. The Squeak implementation of Smalltalk is great, but it, too, has turned into a complex and largely undocumented mess. Languages like Smalltalk, Python, and Lisp are great for smaller projects and for single programmer projects.
In general, Java is bytecompiled, just as most scripting languages are. Sometimes Java can be JIT-ted to native code. Sometimes scripting languages can be JIT-ted to native code.
That's a mischaracterization. With the major Java implementations (Sun, IBM, Intel), Java is always JITted into efficient native code, and the Java byte-code is well-suited to that. None of the major scripting languages (Perl, Python, Tcl, Ruby) have a widely-used JIT, and nobody has ever demonstrated a native code compiler for those languages that results in performance anywhere near native code. CMU CommonLisp, arguably one of the best compilers for dynamic languages, does very poorly without type declarations.
Sorry, but you don't understand how Java implementations work. When you run "javac", you produce byte code. That byte code gets turned into native code before being executed when it is part of a performance critical section--the native code compiler is part of the Java runtime.
Python, Perl, or Ruby do not have anything comparable: they are implemented as strict byte code interpreters (except for Jython, which piggy-backs on the Java runtime). In fact, the Java approach is better than the kind of batch compilation found in C/C++ because it allows for a lot more optimizations. For example, the JDK inlines code among dynamically loaded components.
As for the libraries and penetration available for Java, do you not think that if Sun had developed and spend untold millions marketing Perl or Python that they would not be in the same position?
Python or Perl are no replacement for Java. With a few exceptions, Java code runs at speeds pretty close to C/C++ under the JDK. Python and Perl implementations are orders of magnitude slower and nobody has figured out how to compile them into efficient code.