You've obviously never used Java if you have to ask that question. The damn thing dig its own grave, and now it's only used by people who don't have a choice, for very good reasons.
>>6
Execution speed is only a small part of the picture, specially for commodity software which generally isn't computation-heavy. The time the actual program takes to run is noise.
Hint: Gecko has always been quite a bit faster than WebKit, but see Firefox and Chrome. Who cares how fast it draws the page if you just had to wait 5 seconds until it started up.
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.
I think the world would be a much better place if we could just tolerate each other's tastes... =)
...Some like Java, some prefer C... Others might love lisp... =D
Name:
0n3n72011-09-04 0:22
*Permutes name
...You can be anonymous and still be -identifiable- ??
...Imitation is the highest form of flattery ;)
*Agree's with #23 =D What?!
Name:
Anonymous2011-09-04 0:34
>>20
I'm a student studying programming, comments like this is why I don't participate in forums like this. Who gives a FUCK that java can't use unsigned types. What kind of program did you create that needed an unsigned type.
There is a server written in Java, and a client in C sends over an array of 200032435 unsigned integers. The server receives 200032435 signed ints, and needs to assign each one into a different array, that is twice as large, using a conversion formula. You must use at least twice as much memory.
There is a server written in Java, and a client in C sends over an array of 200032435 unsigned long longs. Guess what, now you are fucked, and you have to make an array of BigInts, which need allocation, which uses dynamic memory, which causes the gc to run periodically, which causes you to get out of sync with the client, periodically, and now the application has a jump, periodically.
Not supporting unsigned types is ridiculous. I can't imagine there being an architecture with support for signed arithmetic and no support for unsigned arithmetic. It's madness.
>>29
Cool contrived example bro. Don't forget that it's trivial to covert from unsigned to signed and vice versa (one operation).
The only real difference is you don't have to put up with the file.cpp:12: warning: comparison between signed and unsigned integer expressions
file.cpp:34: warning: comparison between signed and unsigned integer expressions
file.cpp:55: warning: comparison between signed and unsigned integer expressions
file.cpp:59: warning: comparison between signed and unsigned integer expressions
file.cpp:68: warning: comparison between signed and unsigned integer expressions
file.cpp:102: warning: comparison between signed and unsigned integer expressions
file.cpp:116: warning: comparison between signed and unsigned integer expressions
file.cpp:125: warning: comparison between signed and unsigned integer expressions
file.cpp:182: warning: comparison between signed and unsigned integer expressions
file.cpp:256: warning: comparison between signed and unsigned integer expressions
file.cpp:340: warning: comparison between signed and unsigned integer expressions
file.cpp:912: warning: comparison between signed and unsigned integer expressions
Bullshit.
Name:
Anonymous2011-09-04 5:26
>>30
You don't understand. It's not trivial to convert from signed to unsigned in Java. You have to use a larger signed-type, which involves sign/zero extension and eats up twice as much memory. To support 32-bit unsigned values in Java while retaining unsigned semantics during comparison, you have to use a 64-bit signed type.
>>29 was write. You are stupid, you don't even see the consequences.
>>31
Moving the goal posts now to retaining unsigned semantics
huh?
It's still easy to convert between unsigned and signed while preserving order. Are you going to require we meet all the obscure unsigned quirks of C now too?
No, you don't need to use a larger data type to read an unsigned integer. Not to mention this entire example is completely contrived, if you ever got into this situation you have bigger problems to worry about than allocating (and good heavens, having the gc collect) 4 extra bytes.
Name:
Anonymous2011-09-04 6:16
>>34
Wow you're stupid. You just don't get it. There's more to unsigned integers than just "reading" them as you put it. Just because they're two's complement notation doesn't mean that you can use signed comparisons on numbers where you expect unsigned semantics.
// C version, assuming int is a 32-bit integer on target platform
unsigned int a = 0xFFFFFFFF;
unsigned int b = 0x00000005;
if (b < a) {
printf("fuck you >>34\n");
}
// Java version
int a = 0xFFFFFFFF;
int b = 5;
if (b < a) {
System.out.println("fuck you >>34\n");
}
The C version will print the message, whereas the Java version will not. There are different semantics involved. In C compilers and the JVM, with signed integers, signed comparison machine instructions are emitted. For unsigned types in C, unsigned comparison instructions are used. There is a difference which affects order. In Java, the only way to get the same semantics is to use a larger signed integer type which can represent all of the unsigned values possible with the smaller unsigned type.
You're also stuck in OO-thought processes focused on tiny toy one-man projects. In large scale projects, if you have to support lots of unsigned integers has a big impact.
>>35 public class Main {
public static void main(String[] args) {
int a = convert(0xFFFFFFFF);
int b = convert(5);
if(b < a) {
System.out.println("magic!");
}
}
private static int convert(int x) {
if(x >= 0) return x - 0x80000000;
else return (0x80000000 - (~x + 1));
}
}
Name:
Anonymous2011-09-04 8:07
>>36
That's fucking bullshit. I thought Java was supposed to make things easier, not make you jump through hoops. Fuck Java.
>>36
You're saying that that is an improvement over just having support for the unsigned types built in? Now I have more reason to stay away from Java.
I never really believed it, but this thread convinced me: if it ain't Lisp, it's crap!
Name:
Anonymous2011-09-04 9:21
>>37,38
I never said it was easier, just that the example wasn't a valid one. I was correct.
Java makes things easier by decreasing cognitive load. The designer(s) had a well reasoned justification for removing unsigned types. You can disagree with the philosophy, and many people do.
Frankly, I think it takes one look at some boost source to understand Gosling was right. Adding features because someone, somewhere, might want to use your language to solve a problem it wasn't designed to solve is not a good strategy.
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.