Java was designed to solve the problem of way too many productive programmers having fun solving interesting problems.
To solve this, they created a language that would subtly shift focus away from the problem itself, to the code you were writing.
Tasks that used to take a small team of five programmers, would now require twenty, mostly occupied with mindless repetitive tasks, like writing getters/setters and FactoryFactories.
First-class functions, closures, and metaprogramming were early on identified as great productivity boosters that would let you get around most of the artificial hurdles, and the vote to leave them out was unanimous.
The type system was designed to prevent code reuse and encourage copy-paste coding.
Common programming tasks were identified by a designated committee, and the standard library was carefully pessimised to require at least five lines of code and two elements of redundancy for the ten most common tasks.
Name:
Anonymous2011-09-04 10:59
Java is probably the most-hyped programming language ever, and deserves almost none of its fame. All of it's promises can be fulfilled by existing languages or moved to standardized protocol design instead of a language. There is nothing really new that Java brings to the table. Sun is much better at marketing than at creating new languages. HP and IBM products are often technically superior or better deals, but those companies have not learned how to market the way Sun and Microsoft have.
Java's Flaws in a Nutshell
- Cross-platform GUI's and networking should be API's or protocols that other languages can use as well. There are plenty of other cross-platform languages already (Lisp, Samlltalk, Factor, Nial, etc.). What is needed most are standard protocols that any language can use, not yet-another-language. Insufficient cross-platform protocols is the current bottleneck, not languages.
- Case-sensitivity Dumb dumb Dumb dumb: Thingy thingy = new Thingy(); Why does the Unix crowd hold on to case-sensitive tokens? It should have gone out with vacuum tubes. CPU speed? Come on! Make the machine be the slave, not the human programmers. How much speed does it buy? A 0.000001 increase?
- OOP: it is clear that Java is not suited for procedural programming. For example, some API's don't work with Static methods, at least not without contortions. Even C++ lets one easily do normal procedural programming if they wish. The designers of Java appear to think that OOP is the silver bullet for every problem. The irony of this is that Java is not even a good OO language. There are languages like Smalltalk and Lisp's CLOS, that object fans find much more object-friendly.
- The static typing model is not ideal for many types of applications, for example, applications that interface with many different systems and protocols. Some JDBC Java applications spend half their code converting types. This is not only a waste of code, making it cluttered and hard-to-read, but databases may change their field types, making a JDBC application fragile. A nice feature would be to make static typing optional. This can be done via optional type specifiers for declarations, like (declare (int X)) in Lisp. Besides, programs are easier to read if the type declaration and other specificers come after variable names, because types are less important than variables.
- The "Break" clause in case statements. Another idiotic hold-over from C.
- High protocol coupling. Using the Java libraries often requires one to know about protocol B even if one wants to use only protocol A features. Further, protocol B may require knowing how protocol C used, etc.
- Lousy reflection. Reflection, the ability to know and/or change information about run-time items or the application itself, was added to Java as an afterthought, and it shows.
- Normal: say "Hello world"; Java-way: System.out.println("Hello world"). Java is the most bureaucratic claptrap thing ever seen since the Chernobyl computer. I've used grid widgets in other tools/languages, and they were far more approachable. For example, if you wanted to turn on scrollbars and change the color of the selected cell, you'd do something like this: myGrid.scrollbars=True; myGrid.selectedColor=#ffff00; However, Java never makes things this easy. You have to embed the grid in a scroll-panel widget; and to change selected color, you have to create a "column model" object, and a couple of other screwy middle-men classes. You can't just drop the food in front of the tiger, you have to guide the food through its intestines via an Intestine Model and an Enzyme Timing Manager on through to some Excretion Model Coordinator Manager objects, one for each glistening log.
Name:
Anonymous2011-09-04 11:20
>>15
>There are cross platform libraries that are pretty nice, like Qt, that support pretty much anything you would want to do, and they (usually) port perfectly fine.
Qt is so enormously bloated, that WINE emulator cant run it correctly.
Name:
Anonymous2011-09-04 11:22
>>20 Java doesnt have unsigned types
What are you talking about? To the CPU there is no difference between "signed" and "unsigned". -N = 0xFFFFFFFF-N+1
Name:
Anonymous2011-09-04 11:48
>>43 WINE emulator WINE is not and never was an emulator.
>>44 To the CPU there is no difference between "signed" and "unsigned". That's not always true. For instance, x86 has different integer comparison instructions for signed and unsigned numbers.
Name:
Anonymous2011-09-04 12:01
>>42
You're also a fucking moron. The following url is a proper criticism of Java...
>>45
I like how C handles the situtation. You have the C abstract machine that defines the behavior and then you have the actual implementation. All the standard requires is that the implementation produce behavior that is consistent with the abstract machine.
Note: I'm not defending Java nor disagreeing with the statements, I just can't COMPREHEND some of the ABSTRACT BULLSHITE that is going on. >>42 - Case-sensitivity
Why is it bad?
Any examples of it done ``right'' (in modern languages preferably)? >>29
Is the client/server disparity common enough for this to be important? >>23-24
You should learn how /prog/ works and apply that when posting.
Like /prog/'s policy on emoticons, abuse of punctuation and contents of email field (this one applies to vast majority of new/prog/, though). >>41 I LOVE YOUR POST!
Your solution solves the problem of comparisons, but there are still difference in the behavior for addition, subtraction, multiplication, division, and modulus. You may be able to find ways to perform these operations using signed arithmetic (and hey, it would be interesting to see), but you'll never be able to take advantage of the hardware that already supports these operations, and if the application relies on these operations intensely, it will be optimistically 4x slower. That was a good point that the operations could still be supported without using more memory. There is still, more time, though.
>>50
>Is the client/server disparity common enough for this to be important?
Well, it is only an issue if the client is using values in an unsigned int that are so large they would show up as negative in the signed context, which can be dangerous since that is getting a bit close to overflow. But if it is known that the values will always stay within a range that is contained within that of an unsigned int, then it is fine. But if the unsigned int is used appropriately in one environment to express values that fit within that range, but do not fit within the range of the positive, signed ints, then that creates a problem for other applications in an environment with no support for unsigned ints.
One application could be transmitting a series of indecies within a very large array, that is so large that it's length is larger than the largest signed integer. This could come up in transmitting a graph with a ton of nodes. It could come up when transmitting a model, where you first specify a very large array of vertices (3 floating point values per vertex) and then an very large array of faces (a very large array, where each element is an array of indecies within the vertex array). If you knew that the number of vertices would always be less than the largest unsigned integer, then you could use unsigned ints within the face array, and this would save quite a bit of memory. Although if you wanted to take it to the next level, you could compress it somehow, although it would take time to compress and decompress the data. Using a smaller data type for the index saves space while avoiding the cost of compression and decompression.
Name:
Anonymous2011-09-05 7:17
x86 has different integer comparison instructions
No, it just has cmp and signed/unsigned conditional jumps.