Mueller has also gone on record to say that RedHat's business model destroys value, and that RedHat is a parasite (his words).
It's the whole "broken windows" economic fallacy.
The anti-Mueller campaign started on slashdot when he tried to BS a bunch of us on the weekend over TurboHercules, got caught in a bunch of misrepresentations, and tried to weasel out of them. There were more than a dozen of us who jumped in, because what he was saying was a huge distortion of history, as well as misrepresenting the instant situation.
I remember it because before then I didn't know the guy from a hole in the ground - I figured he was just one more idiot spouting nonsense. Then I find out that people think he's some sort of "authority", a lawyer (that I trashed immediately by pointing out that even the stupidest lawyer in the world wouldn't be making some of the statements he made since they had zero basis in law anywhere on THIS planet (I can't speak about Mars, or whatever:-), and if he's really a lawyer he should be disbarred, etc. - sure enough, he wasn't a lawyer, he just encouraged people to think he was, and never corrected the mistake when he had an opportunity.
The only "coincidence" was that he tried to continue elsewhere (as well as to some extent here), but people were now willing to challenge him head-on, and had the links to prove he was just spouting nonsense.
The whole groklaw thing was really pitiful - the guy who was the actual maintainer of the Hercules hardware emulator (istr his name was Jay Maynard) got stuck in the middle, made the mistake of assuming that the claim that IBM was threatening to sue the Hercules project was true (it wasn't), and really, REALLY put his foot into it.
TurboHercules (not the Hercules project) wanted to have IBM customers make unlicensed copies of IBM's mainframe OS to run on other machines, atop the Hercules hardware emulator. When that didn't fly, TurboHercules (again NOT the Hercules project) tried to claim it would be only "transferring" the OS to a second machine, for "recovery purposes."
But even under that scenario (again, not permitted under the license, since you'd still have 2 copies of the OS floating around, even if you weren't using both at the same time, and the OS is licensed to a specific machine because the fee is based on work units), at some point you'd have to have 2 copies running, to transfer updated data back to the mainframe.
TurboHercules then tried to pick a fight with IBM by asking what patents might be infringed by Hercules, and IBM sent them a list. All of a sudden, TurboHercules and Mueller are claiming that IBM is going to to sue the Hercules project for patent infringement, based on IBM's response to their request.
See the problem here? Then ask yourself if it's a coincidence that TurboHercules took moneyfrom Microsoft.
Pile on the FUD he pushed over supposed Android violations of the linux kernel, etc., and you have a clear agenda: The guy did what he could to worm his way into FLOSS territory so he could attack from inside, like a wolf in sheeps clothing, and it almost worked.
The problem is, when it comes to trolling on sites like slashdot, he's a rank amateur:-)
Nobody is saying that you'd have to use any of these features if you didn't want to.
But let's take a look at just one area where a macro preprocessor would be handy - #defines could be inlined with the final value immediately, instead of Key.VK_X, for example.
Now, with as simple a final static class, you'd expect that to happen at bytecode generation time anyway, but what about more complex values, that could still be inlined since the pre-processor can produce a single value?
It can also produce code without namespace clashes, since there is then no need for an import statement - the pre-processor could produce the FQN for each class, variable, and method. You could look at the intermediate representation to see what was actually going on "under the hood."
And be honest - you must have come across at least one time when you wished you could overload an operator, just like in c++. For example, how about an operator to prepend to a string? Or -=(count) to chop off the last count characters? Or -=(string) to remove all occurrences of string?, - (substring) to return a string with all occurrences of substring removed, or -(substring -2) to remove just the last 2 occurrences?
Or < to insert a member into an indexed container in order, or when you know that you're going to do a lot of insertions, and then a separate reorder, just use += to append them, or -= to prepend them, and << key to trigger a resort based on key, and >> key to extract just the values that match the key?
Nobody is saying any of it would be obligatory, just that in some cases, some of us would want the freedom to do so.
If you read the spec (I posted the link on one of these threads months ago, where people were going on about how java is a compiled language), the runtime interpreter will interpret the bytecode, then execute it (jump to the memory address where it's stashed the compiled version). It can save a copy of that set of compiled bytes in a cache for the next run, but profiling jits only do this for code that is repetitively executed, since it can only re-use the cached compiled code if the code execution path is exactly identical.
The next step of optimization is to replace the byte code for the entry into the method with a jump to that compiled code.
These are all things that take place at runtime, not compile time, which is why it's a just in time compiler.
However, even the most recent JITs don't do this with all the code, all the time. What gets shoved into the compile cache si run-dependent. The more often it's used, the more likely.
I know what you mean about making your own stl back in the bad old days. I didn't want to fork out extra for the source of Borland's BC 3.1 container class libraries, so implementing them was good practice.
It's not like today. You see a problem, and you suggest to the person that they solve it by using a ring buffer or a scatter-gather array, and they're totally lost. If it isn't either a pre-written class or easily derived, forget it. And if they do write it, it will often either leak memory, or try to double-free something. If you're lucky. If you're unlucky, they'll have a random off-by-one overflow. If you're REALLY "fortunate", they'll include an underflow (like, iirc, the XBox font buffer underflow homebrew hack)..
In fact I would love to have a "streamlined" C++ for the JVM.
It could probably be done with a specialized pre-processor. Simple macro substitution wouldn't be enough (been there, tried that, had a bit of success).
GC implementation is not a language feature, it's a runtime feature. This has nothing to do with Java as a language. Furthermore, any sufficiently complex C++ program implements some form of (at least) semi-automated garbage collection; even if it's just reference-counting smart pointers. You apparently have no experience writing real software.
Finalizers are a language feature. The fact that a finalizer is not guaranteed to ever run, not when your class does the java equivalent of c++ "out of scope" (no valid references left to it), or even on program termination, is a language flaw. The runtime just surfaces, or exposes, that flaw.
Would multi-threading real-time data servers that never kill off a thread from their thread pool between startup and shutdown months later while serving a thousand requests a second (because they never lose a byte of memory) qualify as "sufficiently complex"? No reference counting needed - just well-behaved code, and contracts between the loadable modules and the server as to who owns what memory.
It's called the "Dear Abby" school of memory management. If you pick it up, put it back when you're finished. If you give it to someone, either make sure that they know that they're expected to put it back when finished, or make explicit arrangements for them to return it to you so you can put it back.
It's not that hard to get right if such an obvious dummy as I can do it, right?
Really though, are you seriously arguing against non-deterministic GC because you think every program in the universe should be "well-behaved" and "provable" (on your own terms)? We might as well toss out, gee, I dunno, almost every modern language under the sun while we're at it. I think I can count on one hand the number of languages in regular, widespread use today whose standard runtimes leave memory management exclusively up to the programmer.
Finalizers in java can end up being just so much dead code, even on runs on the same machine. That's the sort of non-deterministic behaviour, where the code says one thing, but the behavior is "undefined" even between runs, that cries out for fixing. That's not "arbitrary" - that's a bug.
"Class explosion?" This sounds like a term that would be used by a C programmer who writes C code inside of C++ classes, but who doesn't actually design object-oriented programs. "Classes if necessary, but not necessarily classes" would be exactly the kind of tripe I would absolutely never expect an experienced C++ programmer to say.
Every non-trivial c++ program contains a fair chunk c code inside classes. All those flow control statements... for(), if(), else, switch(), break;, continue; they're all c, not c++. Same with all the non-overloaded operators. You can't write a c++ program without using some c code. Here's a hint - look at the declaration for main().
"Classes if necessary, but not necessarily classes" is a rule of thumb a lot of us use; in my case, it's because, before java was ever even a gleam in JG's eye, I tried the "make everything a class" idiom, and ran into the same class explosion problem everyone does. Some people think that a proliferation of classes shows how great they are at coding. I don't. Classes, like everything else, are just semantic tools for managing complexity. Nothing more. Anyone who invests them with more meaning than that doesn't understand what's actually going on behind the scenes - your classes aren't real "objects" - just a series of bytes handily organized to do the job.
It's a separate tool though. #define is not part of the C++ language in any way. It's part of the CPP language.
The pre-processor is an integral part of every c implementation, always has been. And what is this CPP you speak of? The c pre-proces
No, what I am saying is that Java is still not "there" yet - and the varied responses to this article are proof that there is room for improvement. Otherwise, we'd still all be coding in assembler and saving to paper tape.
Javanistas continually deny this. Case in point - operator overloading. It's "evil." Why? Because the programmer can't be trusted with "doing the right thing?" And yet, Java overloads the + operator for Strings, java code is rife with such uses, but still, people go around spouting that operator overloading is bad.
Then there's multiple inheritance. There's nothing wrong, per se, with multiple inheritance. Quite the contrary - nature has shown that it's the only way when building complex systems (or would you rather stick with interfaces and single inheritance, and start singing "I'm my own grandpa" - cue the theme from "Deliverance":-).
Yes, there are a ton of single-inheritance systems out there - and they all suffer from a natural limit to how complex you can make things, before you have to do work-arounds that would be a natural for multiple inheritance (and easier to maintain, since class hierarchies in multiple-inheritance schemes tend to be less "deep").
Nobody is saying that people would be forced to use either of these features if they were added to Java, just like some people continue to use c++ as just "a better c." But on a forum where everyone says "choice is good" when it comes to things like operating systems and desktop environments, saying that it's better to remove tools from the programmer... it's nothing if not inconsistent.
BTW - there is nothing stopping java from being a self-hosted language, if we get rid of the illusion that Java is a "write once, run anywhere" language (this was never true - just look at the mess in Java Mobile Edition), and give it the option of emitting fully native code as well as traditional, jvm-interpreted classes.
At the very least, the native versions could translate finalizers into proper class destructors, not dependent on when (or even if) the garbage collector would run them.
We could call it Java++ (or if you hate the idea, Java--, either works for me:-)
Obviously, just judging by the responses to the article, at least some people want a "better java", or at least a more flexible one.
if your program is running for months, may only be called when your program finally exits (really really REALLY dumb move there, people)..
Finalizers are not called on program termination. They only get called when the garbage collector collects an object...
... and the garbage collector may NEVER "collect" the object, even upon program termination, which is why, by the same token, I should be able to say that I hope YOU don't program much in Java, if you didn't even know that.
c++ destructors work. Java finalizers, obviously not so much. The garbage collector in java is conceptually flawed. Rather than having it happen at runtime, perhaps it's time that java was re-worked so that proper destructors can be injected into the emitted byte-code stream when the source is translated into the bytecode classes that the interpreter will interpret? Or maybe optionally have a compile-time switch to get rid of the byte-code interpreter and virtual machine entirely and emit native code?
The LAST people in the world I would ask for advice on programming language design would be people who think that C++ is a good language. That's like asking the blind for help with the colour scheme for your house.
By the same token, the last people who should be asked about language design would be those who don't understand the benefits of multiple inheritance over single inheritance, or overloading operators, or finalizers that should actually be guaranteed to run at some point instead of sometimes turning into just so much dead code because the garbage collector said "Sorry, honey, not this run. Maybe next time" because they lack the ability to think outside their tiny little box:-)
BTW - what language is Java written in? Hint - it's the language you're throwing rocks at as being so terrible. Isn't that being just a teeny bit hypocritical?
Just as c spawned c++, there's no reason why java can't learn how to do multiple inheritance, programmer-definable operator overloading, and deterministic garbage collection (even if the latter only means that the programmer is given the authority to manage memory manually for those classes they so mark.)
C and C++ programmers solved these issues back in the '80s. Here we are, 30 years later, and Java won't even try to address them.
In deterministic programs - no, I meant all java programs are potentially non-deterministic. Finalizers are not guaranteed to ever execute, for example, so you have code in your program that looks fine, but depending on the runtime environment, the implementation, resources available at the moment, the time of day or phase of the moon, may be effectively turned into dead code.
The so-called "diamond problem" is pretty much a boogie-man
It usually happens when people try to make too deep and comprehensive and deep a class hierarchy. The whole "stupid frameworks for stupid people" thing...
The:: scope resolution operator isn't that hard to use, if you don't want to bother with virtual functions.
C++ ain't really a good comparison-point for making a new clean object-oriented language. C++ is aproximately the thing its name indicates - C, but with object-oriented stuff bolted on, in a fairly ugly manner at that.
1980 called - they want your meme back. Yes, it dates back that far...
C++ used to be just c and a hacked-together pre-processor to add classes (CFRONT
C++ is now supported directly in the compiler, and has been for decades. There's nothing wrong with multiple inheritance that a day sitting down and having it explained properly to the people who b*tch and moan about how evil it is won''t cure.
Same as, if operator overloading is supposedly so evil, why does even Java do it with Strings? You can't have it both ways.
I can believe that some time, somewhere, someone may actually have overloaded an operator unnecessarily for "completeness" - and then that bit somebody else. But for those of us who write our own classes instead of being dependent on the STL or TR1, and learned how to properly manage our own memory instead of needing "smart pointers", operator overloading is just another arrow in the quiver.
Certainly it can't be that bad, if even Java overloads the + operator for Strings. Or is the javanista horde too unwilling to admit both their blind hypocrisy and that Java is dumbed-down for its' audience for a reason?
Java programmer: "I like that I can depend on the Java garbage collector."
c/c++ programmer: "Maybe you should just stop filling your programs with garbage"?
And in the end, who cares about stati type checking of macros? Really... it's a tool. If you can't use the tool without accidentally cutting yourself, then it's not the tool for you. Admit it and move on, instead of complaining about how "evil" it is because you can't keep track of the type for a variable and need compile-time checking. Bets are that the people who wrote the operating system you're using used macros.
... call me back when java is self-hosting, instead of being written in c or c++, because I'm looking at the source, and it sure isn't written in java. Operator overloading, memory management, and macro pre-processing are not evils, just not for everyone. For those of us who know how to use them, there's c and c++. For everyone else, there's java and other interpreted languages.
Multiple inheritance in c++ has always called the constructors in the order they're listed.
You can always specify which parent class's method to invoke via the:: scope resolution operator (double-double colon, aka the "Tim Hortons" colon). No ambiguity need exist.
Everything in Java is passed by value. And every object variable is a reference.
Those two statements are mutually exclusive:-)
Objects are passed by reference, which means that NOT everything is passed by value. Only the reference to the object is passed by value:-)
Adding more features to a language dramatically increases the chances that code will do something unknown or unexpected. No language is free from that sort of mistake, but Java is significantly more consistent and predictable than most languages.
Both the garbage collector and finalizers are unpredictable. You are never guaranteed as to when the garbage collector is run, and finalizers thus may not be called until your program terminates - and in fact finalizers may never be called.
This is one of the reasons why, even after so many years of saying that they'd come out with a jvm that can handle multiple programs at once, they haven't - it's been totally abandoned because the jvm needs to terminate so the OS can reclaim resources that the jvm failed to release because the gc and finalizers are both broken.
Now, in c or c++, the startup library is tiny - around 3k. It sets up the memory arena, the program environment variables, a bit of housekeeping, then jumps to main. The startup library for your java program is the entire jvm instance that has to be loaded into memory. This is not a fixable problem.
You missed my point - instead of coming up with YAJV (Yet Another Java Variant) that, contrary to what people seem to think, does not replace java or the jvm, just adds some syntactic sugar, they could have addressed the real issues.
Job #1 would be to fix finalizers. They've been broken since day 1. Everyone knows they're broken. Everyone ignores it...
Adding any and all the other things would also be nice. Its not like it would FORCE anyone to use any of those features, but for those who want them, they'd at least be there. C++ has had them for decades. Javanistas say "operator overloading is bad" - and yet they don't complain about + being overloaded for Strings. Willful blindness or hypocrisy - take your pick.
Making everything behave like an object can make things much cleaner
... but a lot of the time, it doesn't - it just results in having to write a bunch more classes because the language is lacking in basic flexibility - no programmer overloading operators, no multiple inheritance, no preprocessor - because the programmer "can't be trusted." Throw in a non-deterministic garbage collector and finalize methods that, if your program is running for months, may only be called when your program finally exits (really really REALLY dumb move there, people)...
.At least in c++, you're guaranteed that when the stack frame is popped as your object goes out of scope, your destructor is called immediately. Well-behaved, provable programs need to be deterministic. Until the gc is fixed, java by definition is not a well-behaved provable environment.
That brings up another thing that's missing from java - operator overloading. The String class is overloaded, but we can't overload operators (even the + or ==) when it would make sense.
This is a case of "we don't trust the programmer to get it right", same as the lack of multiple inheritance and the stupidity of interfaces as a work-around.
The problem is this doesn't "throw out the things that are flawed in the original java" - quit the contary.
No âoespecialâ types, everything is an object
(and TFA loses additional points for using Microsoft's smart quotes as demonstrated above)
Any experienced c++ programmer will tell you that "classes if necessary, but not necessarily classes" is the way to go. Class explosion is not pretty, and makes for over-complex stupid implementations.
If you REALLY want to fix it, add the things that are missing:
Kill off interfaces (even James Gosling admits that they were probably a mistake), add multiple inheritance.
A c/c++ style macro compiler and #include system
I guess you missed the part in the article where they quote the copy of the signed contract they introduced into evidence, along with the cashed check.
Google didn;t lie - they said that they have certification, and they do.
Also, for the stats, google is your friend. Just like it's predicted that linux=based tablets will eventually surpass apple-based (just like linux-based smartphones have surpassed the iiphone).
Posted Apr 10, 2011 17:57 UTC (Sun) by cyd (subscriber, #4153)
Hi Mr. Mueller,
I am flattered and pleased that you have deigned to reply! Not even in my dreams have I conceived of conversing, even over the Internet, with someone worthy enough to have been credited in three separate (!) Blizzard Entertainment titles. However, I sense that you are being overly coy in stating your qualifications. No doubt there are numerous employee-of-the-month and high school yearbook awards that you have omitted to mention, due to a misplaced sense of modesty. Please, don't hold back on this account.
Posted Apr 10, 2011 18:01 UTC (Sun) by FlorianMueller (subscriber, #32048)
@cyd, you are actually right that I didn't list all of them. CNET Networks UK handed me (jointly with an activist organization) the Outstanding Contribution to Software Development Award, Silicon.com put me on the list of the 50 Silicon Agenda Setters, Linux Magazine named me runner-up to its Outstanding Contribution to Linux & Open Source Award. But the reason I didn't mention those awards is because I wanted to focus on those with the most impressive fellow laureates -- more impressive than any fellow laureates Groklaw can point to.
Groklaw shutting down in May
Posted Apr 10, 2011 20:11 UTC (Sun) by elanthis (subscriber, #6227) [Link]
I think you failed the sarcasm test, buddy.:)
I know you're responding to someone claiming you're a nobody, but just as a friendly (really) bit of advice: waving your fame-dick around in public just makes you look like you're trying to compensate for something else, and doesn't impress anybody at all.
Really, you are priceless... but not in a good way:-p
And the servers, etc., are just duplicating an existing instance. As another article makes clear, this is mostly a paperwork issue.
Microsoft knows that it's lost the war to maintain its' monopoly. Now it's a question of fighting individual holding actions, to preserve as much as possible, for as long as possible.
By next year, not only will there be more devices shipping with linux than Windows, but when HP makes all their line dual-boot between their webOS linux variant and windows, linux will become the #2 shipping desktop OS, surpassing Apple.
After that, in 2013 you can be sure that the other manufacturers will follow suit. What that means is that on April 8th, 2014, when Microsoft finally kills off XP, most of those corporate users won't be switching to Windows. They'll have replaced those devices with a combination of tablets, smartphones, and desktops that run linux. Already, 12% of all iPad users are in corporations, and 1/3 of them are using their tablets as replacements, abandoning their desktops and laptops. It turns out that most managers don't need a desktop. It's not like they write long emails...
Slashdot Mirror
It's the whole "broken windows" economic fallacy.
The anti-Mueller campaign started on slashdot when he tried to BS a bunch of us on the weekend over TurboHercules, got caught in a bunch of misrepresentations, and tried to weasel out of them. There were more than a dozen of us who jumped in, because what he was saying was a huge distortion of history, as well as misrepresenting the instant situation.
I remember it because before then I didn't know the guy from a hole in the ground - I figured he was just one more idiot spouting nonsense. Then I find out that people think he's some sort of "authority", a lawyer (that I trashed immediately by pointing out that even the stupidest lawyer in the world wouldn't be making some of the statements he made since they had zero basis in law anywhere on THIS planet (I can't speak about Mars, or whatever :-), and if he's really a lawyer he should be disbarred, etc. - sure enough, he wasn't a lawyer, he just encouraged people to think he was, and never corrected the mistake when he had an opportunity.
The only "coincidence" was that he tried to continue elsewhere (as well as to some extent here), but people were now willing to challenge him head-on, and had the links to prove he was just spouting nonsense.
The whole groklaw thing was really pitiful - the guy who was the actual maintainer of the Hercules hardware emulator (istr his name was Jay Maynard) got stuck in the middle, made the mistake of assuming that the claim that IBM was threatening to sue the Hercules project was true (it wasn't), and really, REALLY put his foot into it.
TurboHercules (not the Hercules project) wanted to have IBM customers make unlicensed copies of IBM's mainframe OS to run on other machines, atop the Hercules hardware emulator. When that didn't fly, TurboHercules (again NOT the Hercules project) tried to claim it would be only "transferring" the OS to a second machine, for "recovery purposes."
But even under that scenario (again, not permitted under the license, since you'd still have 2 copies of the OS floating around, even if you weren't using both at the same time, and the OS is licensed to a specific machine because the fee is based on work units), at some point you'd have to have 2 copies running, to transfer updated data back to the mainframe.
TurboHercules then tried to pick a fight with IBM by asking what patents might be infringed by Hercules, and IBM sent them a list. All of a sudden, TurboHercules and Mueller are claiming that IBM is going to to sue the Hercules project for patent infringement, based on IBM's response to their request.
See the problem here? Then ask yourself if it's a coincidence that TurboHercules took money from Microsoft.
Pile on the FUD he pushed over supposed Android violations of the linux kernel, etc., and you have a clear agenda: The guy did what he could to worm his way into FLOSS territory so he could attack from inside, like a wolf in sheeps clothing, and it almost worked.
The problem is, when it comes to trolling on sites like slashdot, he's a rank amateur :-)
But let's take a look at just one area where a macro preprocessor would be handy - #defines could be inlined with the final value immediately, instead of Key.VK_X, for example.
Now, with as simple a final static class, you'd expect that to happen at bytecode generation time anyway, but what about more complex values, that could still be inlined since the pre-processor can produce a single value?
It can also produce code without namespace clashes, since there is then no need for an import statement - the pre-processor could produce the FQN for each class, variable, and method. You could look at the intermediate representation to see what was actually going on "under the hood."
And be honest - you must have come across at least one time when you wished you could overload an operator, just like in c++. For example, how about an operator to prepend to a string? Or -=(count) to chop off the last count characters? Or -=(string) to remove all occurrences of string?, - (substring) to return a string with all occurrences of substring removed, or -(substring -2) to remove just the last 2 occurrences?
Or < to insert a member into an indexed container in order, or when you know that you're going to do a lot of insertions, and then a separate reorder, just use += to append them, or -= to prepend them, and << key to trigger a resort based on key, and >> key to extract just the values that match the key?
Nobody is saying any of it would be obligatory, just that in some cases, some of us would want the freedom to do so.
The next step of optimization is to replace the byte code for the entry into the method with a jump to that compiled code.
These are all things that take place at runtime, not compile time, which is why it's a just in time compiler.
However, even the most recent JITs don't do this with all the code, all the time. What gets shoved into the compile cache si run-dependent. The more often it's used, the more likely.
I know what you mean about making your own stl back in the bad old days. I didn't want to fork out extra for the source of Borland's BC 3.1 container class libraries, so implementing them was good practice.
It's not like today. You see a problem, and you suggest to the person that they solve it by using a ring buffer or a scatter-gather array, and they're totally lost. If it isn't either a pre-written class or easily derived, forget it. And if they do write it, it will often either leak memory, or try to double-free something. If you're lucky. If you're unlucky, they'll have a random off-by-one overflow. If you're REALLY "fortunate", they'll include an underflow (like, iirc, the XBox font buffer underflow homebrew hack)..
It could probably be done with a specialized pre-processor. Simple macro substitution wouldn't be enough (been there, tried that, had a bit of success).
Sheesh, obviously I hit a sore spot :-)
Finalizers are a language feature. The fact that a finalizer is not guaranteed to ever run, not when your class does the java equivalent of c++ "out of scope" (no valid references left to it), or even on program termination, is a language flaw. The runtime just surfaces, or exposes, that flaw.
Would multi-threading real-time data servers that never kill off a thread from their thread pool between startup and shutdown months later while serving a thousand requests a second (because they never lose a byte of memory) qualify as "sufficiently complex"? No reference counting needed - just well-behaved code, and contracts between the loadable modules and the server as to who owns what memory.
It's called the "Dear Abby" school of memory management. If you pick it up, put it back when you're finished. If you give it to someone, either make sure that they know that they're expected to put it back when finished, or make explicit arrangements for them to return it to you so you can put it back.
It's not that hard to get right if such an obvious dummy as I can do it, right?
Finalizers in java can end up being just so much dead code, even on runs on the same machine. That's the sort of non-deterministic behaviour, where the code says one thing, but the behavior is "undefined" even between runs, that cries out for fixing. That's not "arbitrary" - that's a bug.
Every non-trivial c++ program contains a fair chunk c code inside classes. All those flow control statements ... for(), if(), else, switch(), break;, continue; they're all c, not c++. Same with all the non-overloaded operators. You can't write a c++ program without using some c code. Here's a hint - look at the declaration for main().
"Classes if necessary, but not necessarily classes" is a rule of thumb a lot of us use; in my case, it's because, before java was ever even a gleam in JG's eye, I tried the "make everything a class" idiom, and ran into the same class explosion problem everyone does. Some people think that a proliferation of classes shows how great they are at coding. I don't. Classes, like everything else, are just semantic tools for managing complexity. Nothing more. Anyone who invests them with more meaning than that doesn't understand what's actually going on behind the scenes - your classes aren't real "objects" - just a series of bytes handily organized to do the job.
The pre-processor is an integral part of every c implementation, always has been. And what is this CPP you speak of? The c pre-proces
No, what I am saying is that Java is still not "there" yet - and the varied responses to this article are proof that there is room for improvement. Otherwise, we'd still all be coding in assembler and saving to paper tape.
Javanistas continually deny this. Case in point - operator overloading. It's "evil." Why? Because the programmer can't be trusted with "doing the right thing?" And yet, Java overloads the + operator for Strings, java code is rife with such uses, but still, people go around spouting that operator overloading is bad.
Then there's multiple inheritance. There's nothing wrong, per se, with multiple inheritance. Quite the contrary - nature has shown that it's the only way when building complex systems (or would you rather stick with interfaces and single inheritance, and start singing "I'm my own grandpa" - cue the theme from "Deliverance" :-).
Yes, there are a ton of single-inheritance systems out there - and they all suffer from a natural limit to how complex you can make things, before you have to do work-arounds that would be a natural for multiple inheritance (and easier to maintain, since class hierarchies in multiple-inheritance schemes tend to be less "deep").
Nobody is saying that people would be forced to use either of these features if they were added to Java, just like some people continue to use c++ as just "a better c." But on a forum where everyone says "choice is good" when it comes to things like operating systems and desktop environments, saying that it's better to remove tools from the programmer ... it's nothing if not inconsistent.
BTW - there is nothing stopping java from being a self-hosted language, if we get rid of the illusion that Java is a "write once, run anywhere" language (this was never true - just look at the mess in Java Mobile Edition), and give it the option of emitting fully native code as well as traditional, jvm-interpreted classes.
At the very least, the native versions could translate finalizers into proper class destructors, not dependent on when (or even if) the garbage collector would run them.
We could call it Java++ (or if you hate the idea, Java--, either works for me :-)
Obviously, just judging by the responses to the article, at least some people want a "better java", or at least a more flexible one.
c++ destructors work. Java finalizers, obviously not so much. The garbage collector in java is conceptually flawed. Rather than having it happen at runtime, perhaps it's time that java was re-worked so that proper destructors can be injected into the emitted byte-code stream when the source is translated into the bytecode classes that the interpreter will interpret? Or maybe optionally have a compile-time switch to get rid of the byte-code interpreter and virtual machine entirely and emit native code?
By the same token, the last people who should be asked about language design would be those who don't understand the benefits of multiple inheritance over single inheritance, or overloading operators, or finalizers that should actually be guaranteed to run at some point instead of sometimes turning into just so much dead code because the garbage collector said "Sorry, honey, not this run. Maybe next time" because they lack the ability to think outside their tiny little box :-)
BTW - what language is Java written in? Hint - it's the language you're throwing rocks at as being so terrible. Isn't that being just a teeny bit hypocritical?
Just as c spawned c++, there's no reason why java can't learn how to do multiple inheritance, programmer-definable operator overloading, and deterministic garbage collection (even if the latter only means that the programmer is given the authority to manage memory manually for those classes they so mark.)
C and C++ programmers solved these issues back in the '80s. Here we are, 30 years later, and Java won't even try to address them.
In deterministic programs - no, I meant all java programs are potentially non-deterministic. Finalizers are not guaranteed to ever execute, for example, so you have code in your program that looks fine, but depending on the runtime environment, the implementation, resources available at the moment, the time of day or phase of the moon, may be effectively turned into dead code.
The so-called "diamond problem" is pretty much a boogie-man
It usually happens when people try to make too deep and comprehensive and deep a class hierarchy. The whole "stupid frameworks for stupid people" thing ...
The :: scope resolution operator isn't that hard to use, if you don't want to bother with virtual functions.
1980 called - they want your meme back. Yes, it dates back that far ...
C++ used to be just c and a hacked-together pre-processor to add classes (CFRONT C++ is now supported directly in the compiler, and has been for decades. There's nothing wrong with multiple inheritance that a day sitting down and having it explained properly to the people who b*tch and moan about how evil it is won''t cure.
Same as, if operator overloading is supposedly so evil, why does even Java do it with Strings? You can't have it both ways.
I can believe that some time, somewhere, someone may actually have overloaded an operator unnecessarily for "completeness" - and then that bit somebody else. But for those of us who write our own classes instead of being dependent on the STL or TR1, and learned how to properly manage our own memory instead of needing "smart pointers", operator overloading is just another arrow in the quiver.
Certainly it can't be that bad, if even Java overloads the + operator for Strings. Or is the javanista horde too unwilling to admit both their blind hypocrisy and that Java is dumbed-down for its' audience for a reason?
Java programmer: "I like that I can depend on the Java garbage collector."
c/c++ programmer: "Maybe you should just stop filling your programs with garbage"?
And in the end, who cares about stati type checking of macros? Really ... it's a tool. If you can't use the tool without accidentally cutting yourself, then it's not the tool for you. Admit it and move on, instead of complaining about how "evil" it is because you can't keep track of the type for a variable and need compile-time checking. Bets are that the people who wrote the operating system you're using used macros.
That's not true operator overloading. Programmers should be able to define the overloads they want for all operators.
You can always specify which parent class's method to invoke via the :: scope resolution operator (double-double colon, aka the "Tim Hortons" colon). No ambiguity need exist.
To refresh your memory ....
Those two statements are mutually exclusive :-)
Objects are passed by reference, which means that NOT everything is passed by value. Only the reference to the object is passed by value :-)
Both the garbage collector and finalizers are unpredictable. You are never guaranteed as to when the garbage collector is run, and finalizers thus may not be called until your program terminates - and in fact finalizers may never be called.
This is one of the reasons why, even after so many years of saying that they'd come out with a jvm that can handle multiple programs at once, they haven't - it's been totally abandoned because the jvm needs to terminate so the OS can reclaim resources that the jvm failed to release because the gc and finalizers are both broken.
Now, in c or c++, the startup library is tiny - around 3k. It sets up the memory arena, the program environment variables, a bit of housekeeping, then jumps to main. The startup library for your java program is the entire jvm instance that has to be loaded into memory. This is not a fixable problem.
Job #1 would be to fix finalizers. They've been broken since day 1. Everyone knows they're broken. Everyone ignores it ...
Adding any and all the other things would also be nice. Its not like it would FORCE anyone to use any of those features, but for those who want them, they'd at least be there. C++ has had them for decades. Javanistas say "operator overloading is bad" - and yet they don't complain about + being overloaded for Strings. Willful blindness or hypocrisy - take your pick.
You're not pronouncing it properly. Pronounce the two syllables as two words. "Ora Kill", same as Larry Ellison does.
This is a case of "we don't trust the programmer to get it right", same as the lack of multiple inheritance and the stupidity of interfaces as a work-around.
The problem is this doesn't "throw out the things that are flawed in the original java" - quit the contary.
(and TFA loses additional points for using Microsoft's smart quotes as demonstrated above)
Any experienced c++ programmer will tell you that "classes if necessary, but not necessarily classes" is the way to go. Class explosion is not pretty, and makes for over-complex stupid implementations.
Oh look, someone revived the Clipper dBASE compiler / Pascal syntax.
If you REALLY want to fix it, add the things that are missing:
Kill off interfaces (even James Gosling admits that they were probably a mistake), add multiple inheritance.
A c/c++ style macro compiler and #include system
I guess you missed the part in the article where they quote the copy of the signed contract they introduced into evidence, along with the cashed check.
Also, for the stats, google is your friend. Just like it's predicted that linux=based tablets will eventually surpass apple-based (just like linux-based smartphones have surpassed the iiphone).
We've seen what your so-called "analysis" is worth
Really, you are priceless ... but not in a good way :-p
Microsoft knows that it's lost the war to maintain its' monopoly. Now it's a question of fighting individual holding actions, to preserve as much as possible, for as long as possible.
By next year, not only will there be more devices shipping with linux than Windows, but when HP makes all their line dual-boot between their webOS linux variant and windows, linux will become the #2 shipping desktop OS, surpassing Apple.
After that, in 2013 you can be sure that the other manufacturers will follow suit. What that means is that on April 8th, 2014, when Microsoft finally kills off XP, most of those corporate users won't be switching to Windows. They'll have replaced those devices with a combination of tablets, smartphones, and desktops that run linux. Already, 12% of all iPad users are in corporations, and 1/3 of them are using their tablets as replacements, abandoning their desktops and laptops. It turns out that most managers don't need a desktop. It's not like they write long emails ...
Microsoft originally developed (but never released) a hosted cut-down version of office a decade ago. So stop being an ignoramus.
It's the same code base, just running on a different set of servers.and with some functionality removed.