and it's laughable if it weren't so sad.... Coal Burning throws mercury, arsinic and sulfur into the air, unlike plutonium the halflife of these poisions is infinite. The damage coal does to everything is not reversable in your or my lifetime.
Sulfur gets bound up in normal biological and geologic processes. And there is no need to release appreciable quantities of mercury and arsenic when burning fossil fuels. Of course, we don't have to choose: we don't need nuclear reactors and we don't need to burn appreciable quantities of fossil fuels either. There is more than enough renewable energy around. (Incidentally, it is "arsenic"; you're not a chemist or biologist, eh?).
With nuclear waste you 1) have it contained as opposed to releasing it. 2) there are ways of getting rid of it, encasing it in lead/cement and dropping it into a subduction zone is a pretty good idea. let it sink to the center of the earth and help keep the planet healthy by keeping it geologically active. Didn't you know life on earth owes it's existance to the earth being geologically active and the earth would not be geologically active without nuclear decay. This is a nuclear powered planet you live on.
Sure, I "did know" that. You forgot to mention that the sun is a big fusion reactor. And in both cases, I prefer the radioactive decay and the fusion processes to remain where they are: safely undeground and a few light minutes away, respectively.
Arguing from geological facts about the desirability of creating nuclear waste in power plants in our backyards is idiotic, in particular since we don't need the extra power to begin with.
Yes you can. As long as it is radioactive it can potentially be used for further reactions (actually it isn't even a requirement that it is radioactive, only stable iron cannot be used for energy production through fission or fusion).
No, sorry, that's just not true. Not all radioactive elements can be used for "further reactions".
But there is a more practical problem: out of those reactions comes an increasingly complex mix of radioactive elements; even if you could design nuclear reactions to get rid of the major components, you can't realistically separate the mix and deal with all of them. Furthermore, a lot of the radioactive waste that is generated doesn't come from fuel, it comes from the reactor housing and other components.
Basically, you can't win: the more you do with radioactive stuff, the more radioactive waste you generate and the harder the problem generates.
The biggest real issue is whether the reactor contents could be adequately contained during a worst case accident. If this is possible, and I suspect it is, there is no real danger associated with this technology.
I'm aware of no technology that is capable of preventing breakup of an object that reenters into the atmosphere unexpectedly, or, alternatively, that guarantees that such an object burns up reliably in the upper atmosphere. The worst case scenario, as far as I can tell, is that the reactor breaks up partially and finally disintegrates completely at low altitude over some densely populated area.
the biggest practical issue is whether anti-nuclear hysteria will stop this thing because of the neglible amount of radiation produced at high altitudes when it fires.
You are assuming that people who are against nuclear power are just irrational. That's a bad assumption. Radiation release during normal operation is clearly not much of an issue. The issue is the safety of producing the rockets, launch pad accidents, and reentry events. Disposal of the spent fuel is also a big issue: you can't leave these things in earth orbit, so you either have to lift them out further (unlikely), or dispose of the stuff on earth.
You cannot destroy nuclear waste: it stays around for tens and hundreds of thousands of years. The best you can do is stick it in some remote place and hope it will stay hidden there for a very, very long time. So far, none of the disposal options we have give us even a moderate assurance that they are going to be safe for more than a few thousand years. That's an excellent reason not to produce nuclear waste, no matter how unpleasant the alternatives may be.
The pollution from coal and oil may be very harmful in the short run, but it degrades over time, and the carbon dioxide does get reabsorbed over a time span of at most hundreds of years.
Furthermore, there doesn't need to be "more and more pollution"--the US could get with it and cuts its energy use down to a fraction of current levels by conservation. Many of the things you do for conservation have other, non-energy related benefits as well, such as reducing road congestion, improved quality of life, creating job opportunities, making the US more internationally competitive, and spurring innovation and research.
The only "ignorance barrier" is the one created by existing energy companies and conservative interests, which mislead people into thinking that their lives would be miserable if they couldn't drive a gas guzzling SUV or live in energy wasting homes.
I wonder "Which will first be portable to CygWin?" XFree is now working on CygWin, or nearly so.
Well, obviously, if you have an X11 server and a UNIX emulation layer, both should work. And Gtk+ seems to work acceptably for some applications (Gimp, AbiWord).
In any case, the real open source competition to MS Office is neither Gnome nor KDE, it's StarOffice/OpenOffice, which already runs well on Windows (much better than it does on Linux).
Platform has nothing to do with it, but ownership and other business interests do. If Google were run by the company producing Windows XP and owning Passport, Hailstorm, and various on-line advertising bureaus, the company that tries to link all our digital information together, then, yes, it would be.
Gnome is based on the Gtk+ toolkit, which is distributed under the LGPL. KDE is based on the Qt toolkit, which is dual licensed under the GPL and a commercial license. The LGPL allows Gtk+ to be used for the development of various forms of commercial applications without paying money to anyone.
The GUI toolkit is almost as fundamental to applications developers as the C library and the kernel. Imagine where Linux would be today if everybody developing a commercial application for Linux would have to pay several thousand dollars to some small company somewhere? I think most of the commercial supports of Linux would have gone with BSD or something else instead; even developing for Windows is cheaper than that. Well, dual licensing the GUI toolkit is very close to that situation.
I fully agree with the goals of the GPL. But in some cases, for strategic reasons, another license is more sensible. The core GUI toolkit used for a desktop seems to me is such a case. That's why I think KDE's reliance on a GPL'ed toolkit ultimately dooms it to failure, no matter how nice the desktop itself may be.
Marshal tried to computerize bookkeeping. Yes, that may indeed not be what developing nations need.
The PS2's are not for "surfing the web" in the way we necessarily understand it. They are for downloading and displaying multimedia content. The idea is to get information to the people about how to prevent AIDS, TB, and malaria, how to build better sanitation systems, how to prevent malnutrition, etc. For that, a PS2 showing videos and images may work a lot better than written materials (illiteracy is high). You may even be able to provide language and literacy courses with it. Unlike other IT projects, it should require little maintenance or instruction: just put in the right disk and turn it on. And unlike a DVD player, it has the ability to get and store content from satellites and radio transmissions, at nearly the same price.
Furthermore, unlike other kinds of IT projects, if it doesn't work, there is little harm done: people aren't arranging their life around this device; it's just an optional, potentially useful source of information. It promises to give people what Marshall says empowers them: skills.
I'm a little bit confused. Well first of all most of the pages linked to from that Linda page come back with 404.
The page is old (Linda was done in the 1980's), but the links to the papers and introduction still work. Linda is a well known and pretty widely used approach. JavaSpaces is loosely based on it. (The guy who invented it has the unfortunate distinction of being one of the Unabomber's victims; fortunately, he survived.) For more academic references, look here.
I'm also a bit unclear what you mean regarding asynchronous components. If I read you correctly, COM+ already supports this by way of queued components. It's simply implemented on top of message queues, which is a very good mechanism for asynchronous communication.
Sure, and you can similar things in CORBA--it's all a small matter of programming. But both CORBA and COM are very complex ways of achieving this.
What distinguishes Linda is that it is very simple, it makes asynchronous communications the default, it greatly reduces coupling among software components, and it gives you a bit of database functionality as well. I think it is much better suited to the needs of desktop applications and communications among desktop components than CORBA or COM.
Why do you assume that it's the government's responsibility to fund solar research. why must every man, woman and child be forced to fund your favourite area of research?
Personally, I'd much prefer if the prices oil, gas, and nuclear energy would simply reflect the actual cost they impose on society: health costs, defense costs, environmental costs, etc. The real costs of those energy sources are many times as high as what you pay on your bill. Some of that cost, you pay in seemingly unrelated taxes (defense, health care, etc.), others you pay in quality of life, diminished lifespan and health, diminished quality of life, etc.
But since it is wildly unpopular to charge for those traditional energy sources what they actually cost, the second best thing to do is to subsidize the development of alternative energy sources to the point where they are competitive even with the current, distorted prices for oil, gas, and nuclear power.
But one way or another, public health and externalities are two areas that governments are supposed to worry about, even in a completely capitalist system.
C#'s delegates kick ass - no equivalent in Java. (Java's interface impose a method name on the caller and a class hierarchy)
Both "C# delegates" and nested classes were considered for Java by the designers, and they decided to go with nested classes. Nested classes are more powerful and also give you independence from method names. (As an aside, "delegates" is a misnomer for what C# provides.)
Java's op codes prevent languages like C and C++ to target their VM, whereas.NET allows C and C++ programs to target their VM as well as efficiently as any other language.
Microsoft's runtime does not run C or C++, it runs "managed C++", which is a subset of C++; you could do the same on the JVM. They also integrated their C++ compiler with the Java runtime so that C++ code compiled to native code can interoperate with the Java runtime, kind of like what gcc and some commercial Java compilers offer for Java, but that has all the usual disadvantages of native code.
C#, CLR submitted as standard to EMCA. Java is proprietary. Sun may charge a fee for the use of their JVMs, libraries in the future.
That's a red herring. There is no guarantee that Microsoft will continue to comply with their ECMA submission; they may well add extensions. In fact, since their ECMA submission lacks most libraries real programs rely on, they already have. And unlike C#/.NET, there are already dozens of third party Java implementations, several of them open source. So, it doesn't matter what Sun does or doesn't do. Sun controls the "Java" trademark and their implementation, nothing more (and it is those that Microsoft ran afoul of).
Templates to be built into.NET virtual machine for greater efficiency and code sharing unlike GJ's template afterthought mechanism.
Right now, they are absent. It's also unclear whether there is any significant advantage to having them built in. Any implementation that wants to share a lot of code would essentially end up with an implementation similar to Java anyway.
C# code is compiled whereas most Java code is interpreted.
That's just wrong. Both C# and Java use an intermediate "virtual machine", which can get handled by an interpreter or a compiler. Sun's JDK mostly compiles, and its native code compiler is very good, better than Microsoft's C# native code compiler.
It would be interesting to see how GCC 3.0 compiled Java code would compare with C# code.
While quite usable, the GCC 3.0 Java compiler doesn't generate highly optimized code in my experience. Sun's JDK seems to beat it handily. The big advantage of GCC 3.0 for Java right now is that it generates more traditional executables that start up fast.
the OSS community needs to come up with it's own OPEN standard version of this concept as opposed to a compatible OSS version of the actual ".net"
We already have. It's called "Java". There are several good open-source implementations and lots of libraries. The real question is: why didn't Gnome start using it a couple of years ago?
C# introduces some ideas that are, imho, an improvement over java such as boxing, where for example, a native type such as an integer is transparently converted to the object type without the need for function calls.
That idea predates both Java and C# by decades. The Java designers surely considered it.
Is it a good design decision to automate this? That is an open question. If you automate boxing/unboxing, most programmers won't know it's happening, and they will wonder while their code runs so slowly. It also leads to unobvious behavior when people try to use inheritance with number classes.
A huge cool aspect is that the runtime seemlessly allows interaction between none runtime and raw code. Thus, you can implement parts of your c++ code in the same module to run in the runtime environment and other parts to be 'raw'-- but they can still call each other without the need of special interface layers (aka JNI).
Specific compilers do that for Java as well. GNU GCJ treats C++ and Java classes interchangeably, and some commercial compilers do (or have in the past) as well. The disadvantage is, of course, that if you rely on this, your code is now machine dependent and unsafe.
That's an argument related to Microsoft's.NET offering. As far as Gnome is concerned, those might as well not exist: if Microsoft is going to provide access to those other services, it is only for their own purposes.
I think something like Linda would be a much better choice for communications in a desktop environment than something like CORBA or COM. Linda is much easier for people to learn, it allows asynchronous communications (very useful in many desktop applications), and it's easy to implement (it gets hard if you want a high-performance implementation for supercomputing, but that doesn't matter on the desktop). It also doesn't have the versioning problems and tight coupling among components that those other systems have.
It's java, Swing in particular. It's reasonably responisive half of the time but when it enters one of its mood swings (pun intended) it can take up to ten seconds for the UI to 'wake up' again.
There are several possibilities for what might be causing this, none of which are intrinsic to Java. Many UI delays occur when a UI action triggers the loading and compilation of a lot of new classes. For now, well-written Java UI programs arrange for that to happen at less inopportune times. Upcoming releases of Sun's JDK avoid this overhead altogether by keeping compiled classes around.
In any case, for the issue of whether Gnome should use Java or C#, that's irrelevant. Gnome would most likely use Gnome bindings to Java, which have the same advantages (speed, backwards compatibility) and disadvantages as C#'s bindings to the Win32 API.
I completely agree. I think Ximian's decision to clone.NET is a mistake. Some specific points:
Lots of universities are teaching Java, and there are many programmers who know it.
Sun has delivered a very complete set of APIs for which we already know that they can be implemented on many different platforms;.NET/C# relies on a lot of Windows-specific APIs.
There are already lots of open source libraries for Java.
It looks like the embedded and handheld market has widely adopted Java already.
There already is a
gcc frontend for Java, allowing you to compile standalone applications.
There are already several open source JIT compilers, including Kaffe, Intel's Open Runtime Platform, and OpenJIT (the latter isn't open source compliant, but maybe could become so).
Despite frequent claims to the contrary, Sun's recent JDK's (1.3, 1.4) have excellent compilers and runtimes, rivaling C++ performance.
Also, while I think it would make sense for the Gnome project to use Java bindings to Gnome, I think Swing itself is getting a bad wrap. It's a well-designed toolkit that runs fine on reasonably fast machines. It's completely written in, and completely extensible in, Java. In a year or two, nobody will think twice about its speed. Most of the performance complaints about Swing are actually just the cost of the initial class loading and JIT compilation. Well-written Java programs structure that load process so that it doesn't bother users, but Sun is addressing these issues with each release.
There are no significant technical differences between Java and C# as languages. C# is neither harder nor easier to compile than Java. C# is not more expressive and it isn't less expressive. As languages, they are interchangeable. The question is: given these other considerations, which is the right choice? To me, the answer is pretty clearly Java, not C#.
speed - VC# is a LOT faster than Java. I notice no difference between native C++ and JIT translated C#
If you mean, subjectively, your C# programs run as fast as your C++ programs, that's probably because C# relies on a lot of native code in its libraries. You can do the same thing with Java--in particular, there are native interfaces from Java to Gnome. The.NET runtime itself is nowhere near as good as the Java runtime at this point.
*amazing* IDE and dev tools [...] it takes about 6 _mouse-clicks_ to connect your code to a data source
That is not specific to C# or.NET: whatever you like in a C#/.NET environment could be implement in a Java development environment. In fact, it has been if you check your commercial Java IDEs.
I think microsoft realizes that the key to their continued hyper-success is making it really easy for developers to build great solutions.
Well, so far, I haven't seen any such "great solutions" on Windows--just a lot of really mediocre software that it took companies a long time to develop and debug.
That's the problem these days. Society is so litigious, to the point where you really DO have no rights unless you get a lawyer and go to court. None at all... [...] The lack of common decency
This isn't society's problem, or a problem of decency, it's a concrete, specific problem with the US laws governing copyrights, trademarks, patents, personal injury, and the like. Copyrights, trademarks, and patents have extended far beyond their original intent, and they have become far more central to our society. Trying to fix such problems by an appeal to "decency" is futile.
We need some kind of Federal SLAPP law, one that imposes HARSH penalties on lawyers, and even JUDGES who become parties to such harassment.
Now that's an idea: create more opportunities for frivolous lawsuits.
No, the real solution is to clarify the law: rely less on legal precedent and interpretation and more on precise language. This also may mean taking away some rights. For example, to clarify trademark use, you might define any use in advertising of a trademark you don't own as "infringing", but define all other uses as "non-infringing"--much easier to adjudicate. Or, for medical malpractice, patients might get awarded damages and pain and suffering according to a fixed schedule by an arbitration board, but in return would not have to prove conclusively that the doctor actually made a mistake but merely present a plausible argument that this outcome should not have occurred with the procedure they have undergone.
Lowering the stakes is also another way of avoiding problems. If the choice is between bankruptcy or a 50-50 legal fight, people will pick the legal fight. If the choice is between an administrative fee that hurts and a 50-50 legal fight, many people will will probably choose the former.
Unfortunately, your objections are pretty typical. Most CL users seem to confuse a great experience with a particular implementation with what the language standard actually guarantees. I think the CL standard is probably what ultimately doomed Lisp, failing at ensuring compatibility, making the development of new implementations unnecessarily burdensome, and succeeding at stifling language innovation and evolution.
Some specific points:
Threads only exist in some experimental versions of CMU CL.
ANSI CL is full of unspecified behaviors. Check "defconstant" and "/" for some particularly egregious examples.
I claimed that ANSI CL lacked efficient binary I/O, meaning, bulk operations like READ-ARRAY and WRITE-ARRAY. It does.
and on and on...
I always thought, and I still think, that Lisp is a great idea, and specific implementation have been wonderfully productive for me. I do hope that someone will start a project like O'CAML for a full-features modern Lisp system: something with the clean design of Scheme, but with some more practical design choices (e.g., no call/cc, more built-in types, etc.).
I'm a lot more interested in "this is how fast straightforward, readable, portable code runs" as opposed to "this is how fast obscure code runs on one particular processor configuration after three weeks of manual tuning by several CS Ph.D. candidates".
I agree that CL's syntax is nice, as is its interactive system. But the CL language definition has serious limitations, foremost lack of a number of important facilities like threads, sockets, efficient binary I/O, well-defined runtime errors, and full reflection. CMU CL also has a number of problems, including lack of threads (except experimental in one version) and lack of packed binary structures (there is only an inefficient hack based on typed arrays).
Furthermore, type declarations are not there for speed, they are there for correctness. ML programs (O'CAML or SML) usually run correctly once they compile; with CL, you spend a lot of time unit-testing for silly type errors.
I think an updated version of CL would be great, something that is based on UNICODE, throws out the old pathname and character set cruft, gets rid of some other obsolete features, defines error handling and reflection carefully, and adds threads, sockets, and binary I/O. But I don't see it happening. Most of the people who want CL-like interactivity are now using Python or Java+Beanshell. The syntax isn't as nice, but they are so much more practical.
If I recall correctly, German law differs substantially from US law in this regard. Someone should check.
As I recall, in Germany, law firms can independently police certain laws and write "cease and desist letters"; Adobe need not have been involved in this. I believe they can also charge the recipient of those letters for their work.
However, it seems that 4684DM far exceeds their expenses. The law firm seems to use the threat of sueing to achieve compliance in order to recover excessive legal fees for themselves. If I were Sattler, I would write a letter stating that I disagree with their interpretation of trademark law and admit no wrongdoing, but that I am changing the name immediately to avoid further legal harrassment by their lawyers. Then I would separately ask the law firm for an itemized bill for their labor (that's what the money is for, so one can expect a bill). I'd check the work and rates with another lawyer or a consumer agency and pay only what's fair and reasonable (I suspect no more than 100-200DM).
I think if this went to court, the law firm would have a hard time recovering more than reasonable costs for writing the letter. I think any case about the trademark would also be hard to make: "killustrator" is a non-trivial variation on a generic term, it doesn't seem "confusingly similar" to "Adobe Illustrator", and furthermore "killustrator" is not a product that is for sale and therefore may not even infringe. Again, talking to a lawyer should help here, since trademarks like "Adobe Illustrator" may be protected differently in Germany.
Slashdot Mirror
Sulfur gets bound up in normal biological and geologic processes. And there is no need to release appreciable quantities of mercury and arsenic when burning fossil fuels. Of course, we don't have to choose: we don't need nuclear reactors and we don't need to burn appreciable quantities of fossil fuels either. There is more than enough renewable energy around. (Incidentally, it is "arsenic"; you're not a chemist or biologist, eh?).
With nuclear waste you 1) have it contained as opposed to releasing it. 2) there are ways of getting rid of it, encasing it in lead/cement and dropping it into a subduction zone is a pretty good idea. let it sink to the center of the earth and help keep the planet healthy by keeping it geologically active. Didn't you know life on earth owes it's existance to the earth being geologically active and the earth would not be geologically active without nuclear decay. This is a nuclear powered planet you live on.
Sure, I "did know" that. You forgot to mention that the sun is a big fusion reactor. And in both cases, I prefer the radioactive decay and the fusion processes to remain where they are: safely undeground and a few light minutes away, respectively.
Arguing from geological facts about the desirability of creating nuclear waste in power plants in our backyards is idiotic, in particular since we don't need the extra power to begin with.
No, sorry, that's just not true. Not all radioactive elements can be used for "further reactions".
But there is a more practical problem: out of those reactions comes an increasingly complex mix of radioactive elements; even if you could design nuclear reactions to get rid of the major components, you can't realistically separate the mix and deal with all of them. Furthermore, a lot of the radioactive waste that is generated doesn't come from fuel, it comes from the reactor housing and other components.
Basically, you can't win: the more you do with radioactive stuff, the more radioactive waste you generate and the harder the problem generates.
I'm aware of no technology that is capable of preventing breakup of an object that reenters into the atmosphere unexpectedly, or, alternatively, that guarantees that such an object burns up reliably in the upper atmosphere. The worst case scenario, as far as I can tell, is that the reactor breaks up partially and finally disintegrates completely at low altitude over some densely populated area.
the biggest practical issue is whether anti-nuclear hysteria will stop this thing because of the neglible amount of radiation produced at high altitudes when it fires.
You are assuming that people who are against nuclear power are just irrational. That's a bad assumption. Radiation release during normal operation is clearly not much of an issue. The issue is the safety of producing the rockets, launch pad accidents, and reentry events. Disposal of the spent fuel is also a big issue: you can't leave these things in earth orbit, so you either have to lift them out further (unlikely), or dispose of the stuff on earth.
The pollution from coal and oil may be very harmful in the short run, but it degrades over time, and the carbon dioxide does get reabsorbed over a time span of at most hundreds of years.
Furthermore, there doesn't need to be "more and more pollution"--the US could get with it and cuts its energy use down to a fraction of current levels by conservation. Many of the things you do for conservation have other, non-energy related benefits as well, such as reducing road congestion, improved quality of life, creating job opportunities, making the US more internationally competitive, and spurring innovation and research.
The only "ignorance barrier" is the one created by existing energy companies and conservative interests, which mislead people into thinking that their lives would be miserable if they couldn't drive a gas guzzling SUV or live in energy wasting homes.
Well, obviously, if you have an X11 server and a UNIX emulation layer, both should work. And Gtk+ seems to work acceptably for some applications (Gimp, AbiWord).
In any case, the real open source competition to MS Office is neither Gnome nor KDE, it's StarOffice/OpenOffice, which already runs well on Windows (much better than it does on Linux).
Platform has nothing to do with it, but ownership and other business interests do. If Google were run by the company producing Windows XP and owning Passport, Hailstorm, and various on-line advertising bureaus, the company that tries to link all our digital information together, then, yes, it would be.
The GUI toolkit is almost as fundamental to applications developers as the C library and the kernel. Imagine where Linux would be today if everybody developing a commercial application for Linux would have to pay several thousand dollars to some small company somewhere? I think most of the commercial supports of Linux would have gone with BSD or something else instead; even developing for Windows is cheaper than that. Well, dual licensing the GUI toolkit is very close to that situation.
I fully agree with the goals of the GPL. But in some cases, for strategic reasons, another license is more sensible. The core GUI toolkit used for a desktop seems to me is such a case. That's why I think KDE's reliance on a GPL'ed toolkit ultimately dooms it to failure, no matter how nice the desktop itself may be.
The PS2's are not for "surfing the web" in the way we necessarily understand it. They are for downloading and displaying multimedia content. The idea is to get information to the people about how to prevent AIDS, TB, and malaria, how to build better sanitation systems, how to prevent malnutrition, etc. For that, a PS2 showing videos and images may work a lot better than written materials (illiteracy is high). You may even be able to provide language and literacy courses with it. Unlike other IT projects, it should require little maintenance or instruction: just put in the right disk and turn it on. And unlike a DVD player, it has the ability to get and store content from satellites and radio transmissions, at nearly the same price.
Furthermore, unlike other kinds of IT projects, if it doesn't work, there is little harm done: people aren't arranging their life around this device; it's just an optional, potentially useful source of information. It promises to give people what Marshall says empowers them: skills.
The page is old (Linda was done in the 1980's), but the links to the papers and introduction still work. Linda is a well known and pretty widely used approach. JavaSpaces is loosely based on it. (The guy who invented it has the unfortunate distinction of being one of the Unabomber's victims; fortunately, he survived.) For more academic references, look here.
I'm also a bit unclear what you mean regarding asynchronous components. If I read you correctly, COM+ already supports this by way of queued components. It's simply implemented on top of message queues, which is a very good mechanism for asynchronous communication.
Sure, and you can similar things in CORBA--it's all a small matter of programming. But both CORBA and COM are very complex ways of achieving this.
What distinguishes Linda is that it is very simple, it makes asynchronous communications the default, it greatly reduces coupling among software components, and it gives you a bit of database functionality as well. I think it is much better suited to the needs of desktop applications and communications among desktop components than CORBA or COM.
That's questionable. It turns out that at 220V, people usually let go quicker than at 110V, making 100V potentially more dangerous.
Personally, I'd much prefer if the prices oil, gas, and nuclear energy would simply reflect the actual cost they impose on society: health costs, defense costs, environmental costs, etc. The real costs of those energy sources are many times as high as what you pay on your bill. Some of that cost, you pay in seemingly unrelated taxes (defense, health care, etc.), others you pay in quality of life, diminished lifespan and health, diminished quality of life, etc.
But since it is wildly unpopular to charge for those traditional energy sources what they actually cost, the second best thing to do is to subsidize the development of alternative energy sources to the point where they are competitive even with the current, distorted prices for oil, gas, and nuclear power.
But one way or another, public health and externalities are two areas that governments are supposed to worry about, even in a completely capitalist system.
Both "C# delegates" and nested classes were considered for Java by the designers, and they decided to go with nested classes. Nested classes are more powerful and also give you independence from method names. (As an aside, "delegates" is a misnomer for what C# provides.)
Java's op codes prevent languages like C and C++ to target their VM, whereas .NET allows C and C++ programs to target their VM as well as efficiently as any other language.
Microsoft's runtime does not run C or C++, it runs "managed C++", which is a subset of C++; you could do the same on the JVM. They also integrated their C++ compiler with the Java runtime so that C++ code compiled to native code can interoperate with the Java runtime, kind of like what gcc and some commercial Java compilers offer for Java, but that has all the usual disadvantages of native code.
C#, CLR submitted as standard to EMCA. Java is proprietary. Sun may charge a fee for the use of their JVMs, libraries in the future.
That's a red herring. There is no guarantee that Microsoft will continue to comply with their ECMA submission; they may well add extensions. In fact, since their ECMA submission lacks most libraries real programs rely on, they already have. And unlike C#/.NET, there are already dozens of third party Java implementations, several of them open source. So, it doesn't matter what Sun does or doesn't do. Sun controls the "Java" trademark and their implementation, nothing more (and it is those that Microsoft ran afoul of).
Templates to be built into .NET virtual machine for greater efficiency and code sharing unlike GJ's template afterthought mechanism.
Right now, they are absent. It's also unclear whether there is any significant advantage to having them built in. Any implementation that wants to share a lot of code would essentially end up with an implementation similar to Java anyway.
That's just wrong. Both C# and Java use an intermediate "virtual machine", which can get handled by an interpreter or a compiler. Sun's JDK mostly compiles, and its native code compiler is very good, better than Microsoft's C# native code compiler.
It would be interesting to see how GCC 3.0 compiled Java code would compare with C# code.
While quite usable, the GCC 3.0 Java compiler doesn't generate highly optimized code in my experience. Sun's JDK seems to beat it handily. The big advantage of GCC 3.0 for Java right now is that it generates more traditional executables that start up fast.
We already have. It's called "Java". There are several good open-source implementations and lots of libraries. The real question is: why didn't Gnome start using it a couple of years ago?
That idea predates both Java and C# by decades. The Java designers surely considered it.
Is it a good design decision to automate this? That is an open question. If you automate boxing/unboxing, most programmers won't know it's happening, and they will wonder while their code runs so slowly. It also leads to unobvious behavior when people try to use inheritance with number classes.
A huge cool aspect is that the runtime seemlessly allows interaction between none runtime and raw code. Thus, you can implement parts of your c++ code in the same module to run in the runtime environment and other parts to be 'raw'-- but they can still call each other without the need of special interface layers (aka JNI).
Specific compilers do that for Java as well. GNU GCJ treats C++ and Java classes interchangeably, and some commercial compilers do (or have in the past) as well. The disadvantage is, of course, that if you rely on this, your code is now machine dependent and unsafe.
That's an argument related to Microsoft's .NET offering. As far as Gnome is concerned, those might as well not exist: if Microsoft is going to provide access to those other services, it is only for their own purposes.
I think something like Linda would be a much better choice for communications in a desktop environment than something like CORBA or COM. Linda is much easier for people to learn, it allows asynchronous communications (very useful in many desktop applications), and it's easy to implement (it gets hard if you want a high-performance implementation for supercomputing, but that doesn't matter on the desktop). It also doesn't have the versioning problems and tight coupling among components that those other systems have.
There are several possibilities for what might be causing this, none of which are intrinsic to Java. Many UI delays occur when a UI action triggers the loading and compilation of a lot of new classes. For now, well-written Java UI programs arrange for that to happen at less inopportune times. Upcoming releases of Sun's JDK avoid this overhead altogether by keeping compiled classes around.
In any case, for the issue of whether Gnome should use Java or C#, that's irrelevant. Gnome would most likely use Gnome bindings to Java, which have the same advantages (speed, backwards compatibility) and disadvantages as C#'s bindings to the Win32 API.
Also, while I think it would make sense for the Gnome project to use Java bindings to Gnome, I think Swing itself is getting a bad wrap. It's a well-designed toolkit that runs fine on reasonably fast machines. It's completely written in, and completely extensible in, Java. In a year or two, nobody will think twice about its speed. Most of the performance complaints about Swing are actually just the cost of the initial class loading and JIT compilation. Well-written Java programs structure that load process so that it doesn't bother users, but Sun is addressing these issues with each release.
There are no significant technical differences between Java and C# as languages. C# is neither harder nor easier to compile than Java. C# is not more expressive and it isn't less expressive. As languages, they are interchangeable. The question is: given these other considerations, which is the right choice? To me, the answer is pretty clearly Java, not C#.
If you mean, subjectively, your C# programs run as fast as your C++ programs, that's probably because C# relies on a lot of native code in its libraries. You can do the same thing with Java--in particular, there are native interfaces from Java to Gnome. The .NET runtime itself is nowhere near as good as the Java runtime at this point.
*amazing* IDE and dev tools [...] it takes about 6 _mouse-clicks_ to connect your code to a data source
That is not specific to C# or .NET: whatever you like in a C#/.NET environment could be implement in a Java development environment. In fact, it has been if you check your commercial Java IDEs.
I think microsoft realizes that the key to their continued hyper-success is making it really easy for developers to build great solutions.
Well, so far, I haven't seen any such "great solutions" on Windows--just a lot of really mediocre software that it took companies a long time to develop and debug.
This isn't society's problem, or a problem of decency, it's a concrete, specific problem with the US laws governing copyrights, trademarks, patents, personal injury, and the like. Copyrights, trademarks, and patents have extended far beyond their original intent, and they have become far more central to our society. Trying to fix such problems by an appeal to "decency" is futile.
We need some kind of Federal SLAPP law, one that imposes HARSH penalties on lawyers, and even JUDGES who become parties to such harassment.
Now that's an idea: create more opportunities for frivolous lawsuits.
No, the real solution is to clarify the law: rely less on legal precedent and interpretation and more on precise language. This also may mean taking away some rights. For example, to clarify trademark use, you might define any use in advertising of a trademark you don't own as "infringing", but define all other uses as "non-infringing"--much easier to adjudicate. Or, for medical malpractice, patients might get awarded damages and pain and suffering according to a fixed schedule by an arbitration board, but in return would not have to prove conclusively that the doctor actually made a mistake but merely present a plausible argument that this outcome should not have occurred with the procedure they have undergone.
Lowering the stakes is also another way of avoiding problems. If the choice is between bankruptcy or a 50-50 legal fight, people will pick the legal fight. If the choice is between an administrative fee that hurts and a 50-50 legal fight, many people will will probably choose the former.
Some specific points:
I always thought, and I still think, that Lisp is a great idea, and specific implementation have been wonderfully productive for me. I do hope that someone will start a project like O'CAML for a full-features modern Lisp system: something with the clean design of Scheme, but with some more practical design choices (e.g., no call/cc, more built-in types, etc.).
I'm a lot more interested in "this is how fast straightforward, readable, portable code runs" as opposed to "this is how fast obscure code runs on one particular processor configuration after three weeks of manual tuning by several CS Ph.D. candidates".
Furthermore, type declarations are not there for speed, they are there for correctness. ML programs (O'CAML or SML) usually run correctly once they compile; with CL, you spend a lot of time unit-testing for silly type errors.
I think an updated version of CL would be great, something that is based on UNICODE, throws out the old pathname and character set cruft, gets rid of some other obsolete features, defines error handling and reflection carefully, and adds threads, sockets, and binary I/O. But I don't see it happening. Most of the people who want CL-like interactivity are now using Python or Java+Beanshell. The syntax isn't as nice, but they are so much more practical.
As I recall, in Germany, law firms can independently police certain laws and write "cease and desist letters"; Adobe need not have been involved in this. I believe they can also charge the recipient of those letters for their work.
However, it seems that 4684DM far exceeds their expenses. The law firm seems to use the threat of sueing to achieve compliance in order to recover excessive legal fees for themselves. If I were Sattler, I would write a letter stating that I disagree with their interpretation of trademark law and admit no wrongdoing, but that I am changing the name immediately to avoid further legal harrassment by their lawyers. Then I would separately ask the law firm for an itemized bill for their labor (that's what the money is for, so one can expect a bill). I'd check the work and rates with another lawyer or a consumer agency and pay only what's fair and reasonable (I suspect no more than 100-200DM).
I think if this went to court, the law firm would have a hard time recovering more than reasonable costs for writing the letter. I think any case about the trademark would also be hard to make: "killustrator" is a non-trivial variation on a generic term, it doesn't seem "confusingly similar" to "Adobe Illustrator", and furthermore "killustrator" is not a product that is for sale and therefore may not even infringe. Again, talking to a lawyer should help here, since trademarks like "Adobe Illustrator" may be protected differently in Germany.