Nature herself has caused far, far more destruction than a million industrialized revolutions.
A pointless observation, even if meant anything to speak of "Nature" as representing some kind of agency, which it doesn't.
The greatest chance we have at a peaceful world is beginning to unfold.
War in the middle east, horrible, atrocious wars in Africa, civil war in Russia, the former eastern European states sprawling with right-wing malcontents, massive unrest in Venezuela, financial collapse in Argentina, war in Afghanistan, religiously motivated bombings in Indonesia and the Phillipines, the Bank of Japan's continuing flirtations with bankruptcy, unprecedented loss of life and property in the terrorist attacks on US soil. Yes; world peace must be just around the corner.
our globalization policies can help to bring about positive change in the third world
Arguably globalization reached its peak at the end of the 19th century. Then we got World War I, World War II, and the Cold War. So I'm not so optimistic.
When I saw this article, I thought "Great! Another sign of Microsoft opening up, sharing their knowledge; finally they're getting rid of the faceless megacorp bollocks that has dominated their PR for all these years". And I mean, it is great, a Microsoftie talking about difficulties, explaining processes and workflow. Great.
Then I started reading.
Now, there's a philosophical issue about the desirability of increasingly complex software, but I'm not going to discuss it here.
Philosophical? Is that a euphemism for "useless"? I mean, what else can it mean? Simpler software that does the job is better than more complex software that does the same job. It's as simple as that. Nothing philosophical about it.
And I'm just not all that interested in getting bogged down in an endless debate without the possibility of resolution.
Well, the resolution is simple: simpler software is better. But that would leave him without a job. So obviously he's not interested in getting "bogged down" in that kind of debate. Anyway, can't fault him for trying to sidestep the issue. Still a fascinating look into the belly of the beast. Let's continue.
I mention the issue of complexity because it leads to subtle interactions that can be difficult to track down.
So true! This is getting interesting!
...some interesting history...
Right, right... <nods>
Moreover, it's easy to say that one should have thought of a particular interaction in a complex piece of software, but that's way easier said than done.
Uh, yes, that is indeed a problem with complex software.
When you're implementing any given feature, you're totally focused on the basic problems involved in the feature itself.
Totally. What else? Since surely before you implement the feature, you consider carefully how it interacts with the rest of the system. Well, if that's possible of course. If the system's not too complex and all that.
To put this into perspective, the person who implemented multiple undo in Word is one of the best developers who has ever worked on Word,
But Word was too complex even for him? God help us!
Sorry, I couldn't resist. God knows these kinds of things can be tricky. You just carefully track down the root cause of the problem, and fix it structurally, right? Let's see:
In order to understand this, we have to understand a basic principle of fixes. You make the simplest code change required to fix the problem.
So, um, no structural fix? Just local band aids to stop the bleeding? I suppose... that would work... If your program is so big and fragile that anything but the simplest fix might introduce a whole boatload of unknown problems...
And, always remember that I can't fix what I can't see. I have to be able to reproduce the problem while being able to run some kind of diagnostic tool.
Yes, that's a common problem with closed source software.
What would also have helped is a more meaningful error message. Why show a "Disk full" message when the file descriptor table is full?
Without predictability, I can't fix it,
It would certainly be nice if Word was a bit more predictable. Maybe the complexity has something to with it.
Ah, forget it. Probably just a philosophical quagmire.
Bah, you have no idea how the man feels, or how his jawbone feels, or anything really. Look at you: you're bitching about people you don't even know.
Re:Time for X11R7 or even X12
on
The Power of X
·
· Score: 1
Both were a success and both taught us a lot.
They taught nothing that MacOS didn't already teach us.
Ever thought of how KDE got it's name?
KDE got it's name because CDE was a failure. Otherwise, there wouldn't have been a need for KDE.
Of course all of these things are applications that live on top of X, have absolutely nothing to do with the X consortium or the ICCC,
They're desparate attempts to bring some much-needed structure and policy to the X platform. In that sense they're very closely related to the ICCC and the X consortium.
Re:Time for X11R7 or even X12
on
The Power of X
·
· Score: 5, Interesting
Time and time again, X11 has showed us that it is better to provide mechanism, not dictate policy--even unto the protocol itself.
Um, X is a textbook example of that philosophy gone horribly wrong.
To its credit, the X consortium tried to rectify their mistake thru the ICCC, but again they fell into the trap of creating something with so much misguided "flexibility" that it's almost impossible to find any apps which actually implement the ICCC in full, let alone cooperate in any meaningful way.
The ICCC has been such a joke, that ten years on something as elementary as copy-paste is still a hit-and-miss affair. And what about projects like the CDE, or Enlightenment? Everybody's who been serious about using X to craft a desktop has felt the need to introduce policy above and beyond what X has to offer. That's not a sign of X's flexibility or time-tested design: it's a sign that X sucks.
Let's hope freedesktop.org manages to beat some shape into the mess that is X, but they'll only succeed if they're willing to provide policy rather than mechanism. Bad policy that's followed by many is much more useful than good policy that's followed by few, or no policy at all.
The inertia is too big. Projects like XFree86 are slow to accept changes, and adoption of new features goes very very slowly.
It could be argued that the whole environment is a big bag of application level hacks: widget sets, transparent windows, color management, window management, etcetera.
Font handling is an operating system service which should be provided to applications, each application should not mess about deciding how best to craft it's fonts.
Well, yes, but if the font handling provided by the OS sucks, then what?
(calling it a problem is a bit strong though, sub pixel font hinting or coloured fonts in general falls in to the eye candy enhancement bucket rather than the problems to fix bucket)
The whole point of fonts is to look good. Fonts on X look like shit. That is a very big problem.
Sorry in advance, for the terse reply. I have little time since I have to be in Prague by the afternoon.
The football is a passive carrier of the energies that act on it. It has no active causal power associated with it.
Exactly. But this is no different from a program; programs don't "run themselves", rather they just happen, like sand flowing through an hourglass. But clearly humans do "run themselves". So how can they be programs?
If the brain does not process, then it does not make decisions.
But the brain (humans) does (do) make decisions. It's programs which cannot make decisions. That's why the brain (a human) is not a program.
The brain likes to create programs and run them, but it's not clear that it is a program itself.
Is there any reason to believe that the football processes that input?
Since it's flying through the air, clearly it is doing something with the input.
And are you really telling me that visual, auditory, or other such perceptions are not inputs?
Well, if we model a human being as a system, then obviously that system has inputs and outputs. The problem is that we can model plants, rivers, and the Earth as a whole as a system as well. It doesn't alter their nature.
Either you were able to process the visual input and make the determination that there is four baseballs on the ground, or that idea was somehow innate, and declaring the number and type of objects on the ground is mere reflex and involved no learning whatsoever.
Well, that's a rather presumptuous conclusion. When a football falls on the ground, it bounces. Did it process the input of hitting the ground and make the determination that it should bounce? Or is it a reflex? Clearly it is neither -- it is just the way the world works.
Your only real out if to claim to be a devout determinist, where absolutely everything is predetermined by physics or some pseudoscientiffic avenue. If this is the case, though, words have no meaning and all we're doing is playing the predetermined symbol game.
You seem to surmise things into my words that I don't know are there.
By program, I assert any process that takes input, processes the input, and provides output in a methodological fashion.
Words like "input", "processing" and "output" only make sense when you're talking about programs. But we don't know that we're talking about programs, so we don't know that it makes sense to use these words.
We also don't say that throwing a football "programs" it to hit the ground at some point. But that's pretty much what you're saying.
It's a while since I did neural nets and university, but IIRC a 'nueron' in a nueral net lacks nothing from its biolgical equivlent.
That's true only in a very general and abstract sense. Reality, as always, is complex and messy. But since it's one of the few mechanisms in the brain that we understand well, we are tempted to reduce everything to it.
I believe that even the basic machinery of the brain is still very poorly understood. But since we naturally tend to elevate the significance of what we know and downplay the significance of everything else, it always looks as if we're on the brink of a breakthrough. Hammers and nails.
If they put creation date in than it would not be portable.
There are lots of ways they could have approached the problem. They could have provided an API like File.setProperty(String what, Object value) and fail gracefully for non-existant properties. Or more fundamentally, Java could have provided the ability to send arbitrary messages to objects, Objective C style.
Most Java programmers never play with this since the very extensive java libs cover almost everything imaginable.
No, Java programmers don't play with it because their world pretty much stops where the class libraries stop. Which is why their applications never seem to quite fit in with the rest of the environment.
If you need to change the creation date use JNI in Java (Java Native Interface).
Yes -- you need to escape from Java in order to be able to do many useful things. This illustrates Sun's failure to deliver on the write-once, run-anywhere promise.
So if you were trying to say its not possible in Java you were wrong.
Of course it's possible. But having to write glue code to interface with the system is hardly what I'd call a Java "advantage".
If so, a Java developer could simply use SWT.
SWT is pretty good. The question is: why didn't Sun come up with SWT?
Simple -- because it didn't fit into their vision of what Java ought to be. The problem is that their vision has proven to be radically misguided not once but twice.
Azureus is one of the most downloaded apps on Sourceforge.
A single swallow doesn't make summer.
Tell me, how many Java apps do you use on a regular basis, that are not related to your work or development activity?
Writing an app to run on these OSs that checks for creation date screams STUPID.
Any kind of archiver type tool would need to be able to read and modify these properties. The API simply isn't (or wasn't, I stopped caring around 1.4) any good.
And what, dare I ask, should developers use to write applications that have this sophistication and polish you spoke of for multiple platforms and OSs?
Nothing. They should either target each platform separately if they want polish or create faceless/rudimentary applications if they want wide deployment. The snake oil is the notion of write-once run-everywhere.
Tight integration kills portability and produces large, sloppy, and hard to maintain code that needs to be constantly updated to keep up with even the simplest hardware upgrades.
It also produces apps that people like to use. Isn't that the point?
I don't see what hardware has to do with it. But one should commit to a platform, yes, whether that means committing to a particular version of the Java runtime or committing to a particular CPU ISA or committing to a particular appliance architecture -- it doesn't really matter.
Even Mozilla developers stated that they wanted to move away from that level of integration because they "were losing fingers and toes" trying to maintain it and keep it portable.
They are losing fingers and toes because they tried to shoehorn all platforms into a single codebase on top of an abstraction layer, just like Java.
This is why languages like C and assembly are not in large demand.
That's as may be, but that doesn't explain the piss poor demand for general-purpose desktop Java apps.
If you distribute your application on a CD what is 15M?
That's true. Kind of weird for what was supposed to be the Web-language of choice, but true nevertheless.
Wow, talk about serious FUDding.
Sorry, I encountered each of those issues. Either you never wrote the kinds of apps I wrote, or you just don't appreciate the problems, the way you don't appreciate that having to download a Java runtime is a problem.
This became obvious when you wrote the line "considerable amount of time writing platform specific code".
You need code to do something elementary like get/set a file's creation date for christ sakes, let alone to provide the sophistication and polish that users expect from a normal app.
I never, ever, seen the problems you falsely claim.
Then you either haven't been using Java for a very long time or tight integration with the host environment wasn't a requirement for your apps.
Um...yeah. Whats your point? Java Web Start is part of the java runtime from Sun. If you go to www.java.com and "Get Java" you'll get Java Web Start too. Just think of it as a bonus feature.
The point is that it is exactly one of the integration issues which keeps Java from being adopted as a platform for desktop apps. It's madness to require users to download and configure a 15MB runtime just to run your app.
But pure Java itself has no functionality that is platform specific which is why its cross platform.
There are so many cross-platform issues it isn't even funny. From minor things like cosmetics to major accessibility problems due to widget focus getting messed up. From minor things like system configuration to major things like data interchange between apps. Things like font management and things like widget z-ordering.
Pure Java is so limiting that you just can't write a decent cross-platform desktop app in it, except in the narrowest sense of "with work, it runs". You always need to spend a considerable amount of time writing platform specific code to solve the integration and deployment/packaging issues, or your app will look bad.
This is an area where Java simply has failed to deliver. The fact that you think it's no big deal to, say, download a Java runtime, only serves to illustrate the train of thought that lies at the root of this failure.
You could just as well say C++ wastes memory because it reimpmlements code that exists as a shared library. So does C. So does Fortran. All languages have their core libraries.
Pretty much all apps on GNU/Linux that need SSL end up using openssl. Except Java -- it has to have its own implementation. There are many examples like that, Swing probably being the most egregious one.
Not true since a long long time. 4-5 years.
It's true for 1.4.1 on GNU/Linux. Maybe 1.5 fixes it, I don't know, I've pretty much given up developing with Java for the desktop.
Java Web Start, atleast the one from Sun, is available on SPARC, Solaris X86, Linux, Mac OSX, and Windows.
Did you ever actually use it?
Java Web Start "works only if the client machine has version 1.3 or later of the Java Runtime Environment installed."
In other words, it's a Java app installer that requires that you have Java installed.
As a programmer, I can write in Java and know it will run on multiple platforms.
That was never contested. The issue is that most classes of desktop applications run poorly in cross-platform fashion, due to deployment issues, GUI and UI issues, and/or the use by the app of technology that exists isn't cross-platform, because Pure Java doesn't cut it (which.
Since java is backwards compatible this means your incompatibility version issue is not really an issue.
It's not really an issue until something breaks, yes. Even if Java itself remains backwards compatible, that doesn't mean there won't be versioning issues between the OS/environment and the Java runtime, leading to application problems. The LD_ASSUME_KERNEL mess on GNU/Linux comes to mind.
Regardless, even Sun itself recommends that you deploy applications using the Java runtime that you tested the application on. After all, the backwards compatibility is a best-effort thing, hardly a guarantee.
My point was that my web browser is using 2.5 times as much RAM as my Java LDAP explorer app.
And JBuilder is using more memory that all the other apps combined...
Compare apples with apples. Compare the memory use of HotJava with Mozilla. Compare the memory use of jEdit with TextPad.
It's not about the number of bytes used. It's about the number of bytes wasted. Java wastes memory because it reimplements code that exists as a shared library. Java wastes memory by not sharing memory between applications. Java wastes memory by not returning memory to the OS once it's no longer used by the application.
adding RAM is generally very cheap.
In general, yes, but it depends. It becomes quite expensive once you need more than 4 GB, since at that point you need to move to a different, and still expensive, architecture.
Not really. There is Java WebStart which solves this issue. Commericial products like InstallAnywhere solved this also. Old issue.
For Windows perhaps. But if you're going to confine yourself to Windows, why bother with Java?
Memory swapping? You must have a mighty large java app or very little memory. As for java being a memory pig that is questionable since IE, mozilla, and about a dozen other apps I run on my computer consume more memory than my java apps like Azurues. Go figure.
It's kind of pointless comparing different kinds of apps. You should compare a Java text editor to a native text editor, or a Java browser to a native browser.
Anyway, the point isn't how many bytes any particular Java program uses -- the point is that so many of them are wasted from the OS perspective. Some VMs can be tuned to somewhat mitigate this problem, but, again, if you're going to tie yourself to a specific version of a VM on a specific platform, why use Java at all?
I just wrote a java app the other day that embeds an activeX control within it. Worked great. Ive written C++ apps that use Java (gcj) and it worked great. I think youll have a hard job trying to prove that strange view.
I think that the fact that you felt the need to escape from Java and use an ActiveX control is all the proof that's required.
Javas invisible niche is kinda hard to miss since it covers most IT departments here in the United States and abroad.
Slashdot Mirror
It's an adventure! It's a new experience for the human race.
It's big and empty and scary as hell.
It's lonely and hostile and cold.
There are no monsters. There are no space babes. There is no fame. There is no fortune.
Keep dreaming. There is no place for us in space.
Nature herself has caused far, far more destruction than a million industrialized revolutions.
A pointless observation, even if meant anything to speak of "Nature" as representing some kind of agency, which it doesn't.
The greatest chance we have at a peaceful world is beginning to unfold.
War in the middle east, horrible, atrocious wars in Africa, civil war in Russia, the former eastern European states sprawling with right-wing malcontents, massive unrest in Venezuela, financial collapse in Argentina, war in Afghanistan, religiously motivated bombings in Indonesia and the Phillipines, the Bank of Japan's continuing flirtations with bankruptcy, unprecedented loss of life and property in the terrorist attacks on US soil. Yes; world peace must be just around the corner.
our globalization policies can help to bring about positive change in the third world
Arguably globalization reached its peak at the end of the 19th century. Then we got World War I, World War II, and the Cold War. So I'm not so optimistic.
Yes, I suppose, but what does any of that have to do with the IOCCC?
It's just a competition, and like most competitions, the results are fairly pointless outside the intended domain.
Reading your rant is like watching a spectator in the Tour de France yell "learn how to drive a car you idiot!" at Lance Armstrong.
Of course not. I was just having fun.
Sorry, I couldn't resist. God knows these kinds of things can be tricky. You just carefully track down the root cause of the problem, and fix it structurally, right? Let's see:
So, um, no structural fix? Just local band aids to stop the bleeding? I suppose... that would work... If your program is so big and fragile that anything but the simplest fix might introduce a whole boatload of unknown problems... Yes, that's a common problem with closed source software. What would also have helped is a more meaningful error message. Why show a "Disk full" message when the file descriptor table is full? It would certainly be nice if Word was a bit more predictable. Maybe the complexity has something to with it.Ah, forget it. Probably just a philosophical quagmire.
Bah, you have no idea how the man feels, or how his jawbone feels, or anything really. Look at you: you're bitching about people you don't even know.
Both were a success and both taught us a lot.
They taught nothing that MacOS didn't already teach us.
Ever thought of how KDE got it's name?
KDE got it's name because CDE was a failure. Otherwise, there wouldn't have been a need for KDE.
Of course all of these things are applications that live on top of X, have absolutely nothing to do with the X consortium or the ICCC,
They're desparate attempts to bring some much-needed structure and policy to the X platform. In that sense they're very closely related to the ICCC and the X consortium.
Time and time again, X11 has showed us that it is better to provide mechanism, not dictate policy--even unto the protocol itself.
Um, X is a textbook example of that philosophy gone horribly wrong.
To its credit, the X consortium tried to rectify their mistake thru the ICCC, but again they fell into the trap of creating something with so much misguided "flexibility" that it's almost impossible to find any apps which actually implement the ICCC in full, let alone cooperate in any meaningful way.
The ICCC has been such a joke, that ten years on something as elementary as copy-paste is still a hit-and-miss affair. And what about projects like the CDE, or Enlightenment? Everybody's who been serious about using X to craft a desktop has felt the need to introduce policy above and beyond what X has to offer. That's not a sign of X's flexibility or time-tested design: it's a sign that X sucks.
Let's hope freedesktop.org manages to beat some shape into the mess that is X, but they'll only succeed if they're willing to provide policy rather than mechanism. Bad policy that's followed by many is much more useful than good policy that's followed by few, or no policy at all.
The inertia is too big. Projects like XFree86 are slow to accept changes, and adoption of new features goes very very slowly.
It could be argued that the whole environment is a big bag of application level hacks: widget sets, transparent windows, color management, window management, etcetera.
Font handling is an operating system service which should be provided to applications, each application should not mess about deciding how best to craft it's fonts.
Well, yes, but if the font handling provided by the OS sucks, then what?
(calling it a problem is a bit strong though, sub pixel font hinting or coloured fonts in general falls in to the eye candy enhancement bucket rather than the problems to fix bucket)
The whole point of fonts is to look good. Fonts on X look like shit. That is a very big problem.
You'd think it would be able to get the idea that _yes_, I do want to save it back as Excel.
If you set Tools->Options->Load/Save->General->Standard File Format to "Excel" it won't ask you again.
X font handling sucks so horribly bad, though, in so many ways, that programs like OO roll their own.
Sorry in advance, for the terse reply. I have little time since I have to be in Prague by the afternoon.
The football is a passive carrier of the energies that act on it. It has no active causal power associated with it.
Exactly. But this is no different from a program; programs don't "run themselves", rather they just happen, like sand flowing through an hourglass. But clearly humans do "run themselves". So how can they be programs?
If the brain does not process, then it does not make decisions.
But the brain (humans) does (do) make decisions. It's programs which cannot make decisions. That's why the brain (a human) is not a program.
The brain likes to create programs and run them, but it's not clear that it is a program itself.
What input is the football given?
The energy from the throw.
Is there any reason to believe that the football processes that input?
Since it's flying through the air, clearly it is doing something with the input.
And are you really telling me that visual, auditory, or other such perceptions are not inputs?
Well, if we model a human being as a system, then obviously that system has inputs and outputs. The problem is that we can model plants, rivers, and the Earth as a whole as a system as well. It doesn't alter their nature.
Either you were able to process the visual input and make the determination that there is four baseballs on the ground, or that idea was somehow innate, and declaring the number and type of objects on the ground is mere reflex and involved no learning whatsoever.
Well, that's a rather presumptuous conclusion. When a football falls on the ground, it bounces. Did it process the input of hitting the ground and make the determination that it should bounce? Or is it a reflex? Clearly it is neither -- it is just the way the world works.
Your only real out if to claim to be a devout determinist, where absolutely everything is predetermined by physics or some pseudoscientiffic avenue. If this is the case, though, words have no meaning and all we're doing is playing the predetermined symbol game.
You seem to surmise things into my words that I don't know are there.
By program, I assert any process that takes input, processes the input, and provides output in a methodological fashion.
Words like "input", "processing" and "output" only make sense when you're talking about programs. But we don't know that we're talking about programs, so we don't know that it makes sense to use these words.
We also don't say that throwing a football "programs" it to hit the ground at some point. But that's pretty much what you're saying.
Is there any reson to believe that it is an "intelligent fighter" rather than a machine doing what it is programmed to?
Since it's a machine doing what it is programmed to do, that's what it is. You could sell it as an "intelligent figher" I suppose.
But alas, is there any reason to think that we do more than what we are programmed to?
That assumes that we have been programmed. What's this assumption based on?
It's a while since I did neural nets and university, but IIRC a 'nueron' in a nueral net lacks nothing from its biolgical equivlent.
That's true only in a very general and abstract sense. Reality, as always, is complex and messy. But since it's one of the few mechanisms in the brain that we understand well, we are tempted to reduce everything to it.
I believe that even the basic machinery of the brain is still very poorly understood. But since we naturally tend to elevate the significance of what we know and downplay the significance of everything else, it always looks as if we're on the brink of a breakthrough. Hammers and nails.
If they put creation date in than it would not be portable.
There are lots of ways they could have approached the problem. They could have provided an API like File.setProperty(String what, Object value) and fail gracefully for non-existant properties. Or more fundamentally, Java could have provided the ability to send arbitrary messages to objects, Objective C style.
Most Java programmers never play with this since the very extensive java libs cover almost everything imaginable.
No, Java programmers don't play with it because their world pretty much stops where the class libraries stop. Which is why their applications never seem to quite fit in with the rest of the environment.
If you need to change the creation date use JNI in Java (Java Native Interface).
Yes -- you need to escape from Java in order to be able to do many useful things. This illustrates Sun's failure to deliver on the write-once, run-anywhere promise.
So if you were trying to say its not possible in Java you were wrong.
Of course it's possible. But having to write glue code to interface with the system is hardly what I'd call a Java "advantage".
If so, a Java developer could simply use SWT.
SWT is pretty good. The question is: why didn't Sun come up with SWT?
Simple -- because it didn't fit into their vision of what Java ought to be. The problem is that their vision has proven to be radically misguided not once but twice.
Azureus is one of the most downloaded apps on Sourceforge.
A single swallow doesn't make summer.
Tell me, how many Java apps do you use on a regular basis, that are not related to your work or development activity?
Writing an app to run on these OSs that checks for creation date screams STUPID.
Any kind of archiver type tool would need to be able to read and modify these properties. The API simply isn't (or wasn't, I stopped caring around 1.4) any good.
And what, dare I ask, should developers use to write applications that have this sophistication and polish you spoke of for multiple platforms and OSs?
Nothing. They should either target each platform separately if they want polish or create faceless/rudimentary applications if they want wide deployment. The snake oil is the notion of write-once run-everywhere.
Tight integration kills portability and produces large, sloppy, and hard to maintain code that needs to be constantly updated to keep up with even the simplest hardware upgrades.
It also produces apps that people like to use. Isn't that the point?
I don't see what hardware has to do with it. But one should commit to a platform, yes, whether that means committing to a particular version of the Java runtime or committing to a particular CPU ISA or committing to a particular appliance architecture -- it doesn't really matter.
Even Mozilla developers stated that they wanted to move away from that level of integration because they "were losing fingers and toes" trying to maintain it and keep it portable.
They are losing fingers and toes because they tried to shoehorn all platforms into a single codebase on top of an abstraction layer, just like Java.
This is why languages like C and assembly are not in large demand.
That's as may be, but that doesn't explain the piss poor demand for general-purpose desktop Java apps.
If you distribute your application on a CD what is 15M?
That's true. Kind of weird for what was supposed to be the Web-language of choice, but true nevertheless.
Wow, talk about serious FUDding.
Sorry, I encountered each of those issues. Either you never wrote the kinds of apps I wrote, or you just don't appreciate the problems, the way you don't appreciate that having to download a Java runtime is a problem.
This became obvious when you wrote the line "considerable amount of time writing platform specific code".
You need code to do something elementary like get/set a file's creation date for christ sakes, let alone to provide the sophistication and polish that users expect from a normal app.
I never, ever, seen the problems you falsely claim.
Then you either haven't been using Java for a very long time or tight integration with the host environment wasn't a requirement for your apps.
Um...yeah. Whats your point? Java Web Start is part of the java runtime from Sun. If you go to www.java.com and "Get Java" you'll get Java Web Start too. Just think of it as a bonus feature.
The point is that it is exactly one of the integration issues which keeps Java from being adopted as a platform for desktop apps. It's madness to require users to download and configure a 15MB runtime just to run your app.
But pure Java itself has no functionality that is platform specific which is why its cross platform.
There are so many cross-platform issues it isn't even funny. From minor things like cosmetics to major accessibility problems due to widget focus getting messed up. From minor things like system configuration to major things like data interchange between apps. Things like font management and things like widget z-ordering.
Pure Java is so limiting that you just can't write a decent cross-platform desktop app in it, except in the narrowest sense of "with work, it runs". You always need to spend a considerable amount of time writing platform specific code to solve the integration and deployment/packaging issues, or your app will look bad.
This is an area where Java simply has failed to deliver. The fact that you think it's no big deal to, say, download a Java runtime, only serves to illustrate the train of thought that lies at the root of this failure.
You could just as well say C++ wastes memory because it reimpmlements code that exists as a shared library. So does C. So does Fortran. All languages have their core libraries.
Pretty much all apps on GNU/Linux that need SSL end up using openssl. Except Java -- it has to have its own implementation. There are many examples like that, Swing probably being the most egregious one.
Not true since a long long time. 4-5 years.
It's true for 1.4.1 on GNU/Linux. Maybe 1.5 fixes it, I don't know, I've pretty much given up developing with Java for the desktop.
Java Web Start, atleast the one from Sun, is available on SPARC, Solaris X86, Linux, Mac OSX, and Windows.
.
Did you ever actually use it?
Java Web Start "works only if the client machine has version 1.3 or later of the Java Runtime Environment installed."
In other words, it's a Java app installer that requires that you have Java installed.
As a programmer, I can write in Java and know it will run on multiple platforms.
That was never contested. The issue is that most classes of desktop applications run poorly in cross-platform fashion, due to deployment issues, GUI and UI issues, and/or the use by the app of technology that exists isn't cross-platform, because Pure Java doesn't cut it (which
Since java is backwards compatible this means your incompatibility version issue is not really an issue.
It's not really an issue until something breaks, yes. Even if Java itself remains backwards compatible, that doesn't mean there won't be versioning issues between the OS/environment and the Java runtime, leading to application problems. The LD_ASSUME_KERNEL mess on GNU/Linux comes to mind.
Regardless, even Sun itself recommends that you deploy applications using the Java runtime that you tested the application on. After all, the backwards compatibility is a best-effort thing, hardly a guarantee.
My point was that my web browser is using 2.5 times as much RAM as my Java LDAP explorer app.
And JBuilder is using more memory that all the other apps combined...
Compare apples with apples. Compare the memory use of HotJava with Mozilla. Compare the memory use of jEdit with TextPad.
It's not about the number of bytes used. It's about the number of bytes wasted. Java wastes memory because it reimplements code that exists as a shared library. Java wastes memory by not sharing memory between applications. Java wastes memory by not returning memory to the OS once it's no longer used by the application.
adding RAM is generally very cheap.
In general, yes, but it depends. It becomes quite expensive once you need more than 4 GB, since at that point you need to move to a different, and still expensive, architecture.
Not really. There is Java WebStart which solves this issue. Commericial products like InstallAnywhere solved this also. Old issue.
For Windows perhaps. But if you're going to confine yourself to Windows, why bother with Java?
Memory swapping? You must have a mighty large java app or very little memory. As for java being a memory pig that is questionable since IE, mozilla, and about a dozen other apps I run on my computer consume more memory than my java apps like Azurues. Go figure.
It's kind of pointless comparing different kinds of apps. You should compare a Java text editor to a native text editor, or a Java browser to a native browser.
Anyway, the point isn't how many bytes any particular Java program uses -- the point is that so many of them are wasted from the OS perspective. Some VMs can be tuned to somewhat mitigate this problem, but, again, if you're going to tie yourself to a specific version of a VM on a specific platform, why use Java at all?
I just wrote a java app the other day that embeds an activeX control within it. Worked great. Ive written C++ apps that use Java (gcj) and it worked great. I think youll have a hard job trying to prove that strange view.
I think that the fact that you felt the need to escape from Java and use an ActiveX control is all the proof that's required.
Javas invisible niche is kinda hard to miss since it covers most IT departments here in the United States and abroad.
Like COBOL, yes.