Thread: What's up with Java programmers, anyway?

>> Perhaps such a decision to make it an error rather than a warning is justified, if indeed static analysis can prove rather than merely suggest that the code is unreachable. (Then again, Snafuist pointed out recently that unreachable code is a valid obfuscation technique.)

I don't know. It seems to me that this should just be a warning. Unreachable code can be useful sometimes for debugging purposes.

>> If you want a more friendlier forum for java, i would suggest Big Moose Saloon

I took a quick look at the site, and it does indeed look promising. Thanks.

>> This C++ elitism doesn't impress anybody, and only does a disservice to yourself.

To be fair, I was really only joking (the Jell-O brained Java programmers bit), but to some degree I do feel that C++ is clearly a superior language. Take a look ar Java generics:

Code:

public static < Type > void foo( Type data )
{
	Type
		ref = data, // OK
		copy = new Type( data ); // Error
	ref.bar( ); // Error
	ref.baz = 1024; // Error		
}

The only way that this can "work" is if you specify the supertype in the declaration! The reason for all of this, of course, is because generics are compiled into bytecode (and reused via "type erasure"). But it still doesn't make sense. A more logical approach would be to either allow a dual facility where compile-time code could use the templates fully but run-time code could only use the more limited "type erasure" feature, or else provide full support with the aid of reflection or whatnot. Instead, the designers of the language chose a half-hearted and, frankly, dim-witted implementation. So while I agree that we probably shouldn't sit around and make fun of people (who could be just as talented as any other programmer), I reserve the right to have an "elitist" attitude with respect to the language itself.

>> We do that all the time on this board.

True, but we usually reserve those sorts of responses for the truly ignorant questions.

>> That response usually comes after a question that doesn't make sense within the bounds of the language. Something like, "In C++, how do I call my destructor function?".

Just as a side note, there are some occasions where this is actually necessary (think: std::vector, for one).

>> My whole point was that language ........ing contests are silly enough without the insulting of an entire base of programmers. I've worked with outstanding Java developers and I've worked with C++ hacks. I don't draw any conclusion from that other than that there are good and bad programmers in the world, and all kinds in between. Language has little to do with it. Anyway, in my experience the smartest programmers are the ones who know how to use multiple tools well, and know when to use each.

Agreed.

>> "Java is C++ without the guns, knives, and clubs." -- James Gosling

Originally Posted by Sebastiani

The only way that this can "work" is if you specify the supertype in the declaration! The reason for all of this, of course, is because generics are compiled into bytecode (and reused via "type erasure"). But it still doesn't make sense. A more logical approach would be to either allow a dual facility where compile-time code could use the templates fully but run-time code could only use the more limited "type erasure" feature, or else provide full support with the aid of reflection or whatnot. Instead, the designers of the language chose a half-hearted and, frankly, dim-witted implementation. So while I agree that we probably shouldn't sit around and make fun of people (who could be just as talented as any other programmer), I reserve the right to have an "elitist" attitude with respect to the language itself.

I've always viewed Java as a Bandaid programming language. When they want to add something new like Generics, they need to keep backwards compatibility, so they just put a bandaid on the language. Maybe it's because they're so runtime oriented instead of compile-time oriented?
I'd like to see a whole new version of Java that has the nice rich library that Java currently has but has all the things it's missing like: unsigned types, stack based variables, destructors, the option of passing by value or reference, real templates, const, C++ type casts, operator overloading, typedef, default values for function parameters, a separation of references & pointers instead of the strange reference/pointer mutation they have now...

Originally Posted by cpjust

I'd like to see a whole new version of Java that has the nice rich library that Java currently has but has all the things it's missing like: unsigned types, stack based variables, destructors, the option of passing by value or reference, real templates, const, C++ type casts, operator overloading, typedef, default values for function parameters, a separation of references & pointers instead of the strange reference/pointer mutation they have now...

That would just turn Java into C++ with garbage collection. What would be the point of doing this? The only real distinction between C++ and Java at that point would be the platform-independent nature of the binaries. But a platform-independent C++ is still C++, not Java. We just don't have it yet. (The garbage collection is just an add-on which could be suitably specified)

In fact, what you're talking about seems an awful lot like "Managed C++" by Microsoft. Seriously -- go have a look and tell me it's not.

Originally Posted by brewbuck

That would just turn Java into C++ with garbage collection. What would be the point of doing this? The only real distinction between C++ and Java at that point would be the platform-independent nature of the binaries. But a platform-independent C++ is still C++, not Java. We just don't have it yet. (The garbage collection is just an add-on which could be suitably specified)

In fact, what you're talking about seems an awful lot like "Managed C++" by Microsoft. Seriously -- go have a look and tell me it's not.

Exactly! I'd like a platform independent C++ with the huge library of Java. We could call it "C?"

That would just turn Java into C++ with garbage collection. What would be the point of doing this? The only real distinction between C++ and Java at that point would be the platform-independent nature of the binaries. But a platform-independent C++ is still C++, not Java. We just don't have it yet. (The garbage collection is just an add-on which could be suitably specified) In fact, what you're talking about seems an awful lot like "Managed C++" by Microsoft. Seriously -- go have a look and tell me it's not.

C++ with garbage collection, sounds like C# eh? No wait, C# is java with a new name and proprietary languge protectign it. I'm so confused, what was the need that was so great we needed a new flavor of language gain?

Originally Posted by cpjust

Exactly! I'd like a platform independent C++ with the huge library of Java. We could call it "C?"

I don't think a VM-based C++ environment is necessarily a bad idea. I just don't think Java is the correct starting point for such an endeavor. As was said, C# is already sort of what you're talking about. But I don't want a C++-like language, I want C++, but targetted to a virtual machine.

Native garbage collection is probably a fine idea as well, but there are really only a limited set of circumstances where it is useful. RAII and containers take care of a lot of problems (maybe most of them).

Originally Posted by cpjust

Exactly! I'd like a platform independent C++ with the huge library of Java. We could call it "C?"

Good thing we don't have a thread "What's up with C++ programmers?" in the C forum Someone might really find where all those knives and clubs are ("Java is defanged C++, without the sticks, knives, and clubs"). Love weaponry metaphors. Silliness.

Originally Posted by Sebastiani

>> "Java is C++ without the guns, knives, and clubs." -- James Gosling

Java is C++ without the guns, knives, clubs, hammers, alan wreneches, welder, or cutting torch. Java gives you one hell of a set of regular wrenches, but they only fit 1/2 inch and 9/16, and it gives you a nail gun, but it can only put nails in 1 inch plywood or 2x4's.

Code:

	Type
		ref = data, // OK
		copy = new Type( data ); // Error

The only way that this can "work" is if you specify the supertype in the declaration!

Pardon me for butting in but maybe that's not so bad. I'm not very clear on new and how it is different in Java, or "supertype" and if that means what it should in OOP jargon, but it seems like this error is only an error because you're doing too much on one line.

And we all know that's cute in C++ too. Your argument doesn't wash with me.

Of course, it's another thing that's great for obfuscation, but that shouldn't be how we make our preferences.

>> Pardon me for butting in but maybe that's not so bad. I'm not very clear on new and how it is different in Java, or "supertype" and if that means what it should in OOP jargon, but it seems like this error is only an error because you're doing too much on one line.

Java doesn't have "stack-based" objects (except for ints, floats, etc). All variables are references, and as such you have to call 'new' to allocate an object. So the code I posted is actually equivalant to this in C++:

Code:

Type
	copy = data;

The meaning of "super-type" is the same as in C++. A base class. But my point was, to actually be able to invoke functions (including constructors) or access variables from the object, you would have to change the declaration to something like:

Code:

public static < Type extends Bar > void foo( Type data )
{
	Type
		ref = data, // OK
		copy = new Type( data );  // OK
	ref.bar( ); // OK
	ref.baz = 1024; // OK
}

...where Bar is an actual type having, at the minimum, this interface:

Code:

public class Bar
{
	Bar( Bar rhs );
	void bar( );
	int
		baz;
}

In other words, using generics in this case would really buy you nothing, as it is the exact same thing as:

Code:

public static void foo( Bar data )
{
	Bar
		ref = data,
		copy = new Bar( data );
	ref.bar( );
	ref.baz = 1024;
}

[edit]
There is *one* thing it does buy you in this case, and that is to call the constructor of the derived type. But besides that, nothing.
[/edit]

Originally Posted by Sebastiani

The meaning of "super-type" is the same as in C++. A base class. But my point was, to actually be able to invoke functions (including constructors) or access variables from the object, you would have to change the declaration to something like:

Code:

public static < Type extends Bar > void foo( Type data )
{
	Type
		ref = data, // OK
		copy = new Type( data );  // OK
	ref.bar( ); // OK
	ref.baz = 1024; // OK
}

That's still invalid. You can't allocate an object of a parameter type.


There's nothing wrong with F-bound generics. It has slightly different applications than parametric generics (as C++ has), and it fits in better with a purely object-oriented language like Java. Once you understand the principle behind Java's generics, you can also trivially see why you need a type bound in the example above.

>> I'd like to see a whole new version of Java that has the nice rich library that Java currently has but has all the things it's missing like: unsigned types, stack based variables, destructors, the option of passing by value or reference, real templates, const, C++ type casts, operator overloading, typedef, default values for function parameters, a separation of references & pointers instead of the strange reference/pointer mutation they have now...

I would love to see those features as well, of course, but that would effectively mean completely overhauling the language, which will probably never happen. Besides that, there are some inherent limitations in the virtual machine itself that indicate that it may not be the "language of the future". Just as an example, the instruction set itself can never exceed 255 unique opcodes, since no bits were reserved to allow for multi-byte encoding (there are ways around this, of course, but it would be an ugly hack), and considering that there are already 200+ existing opcodes, real estate is already pretty scarce. Another problem is the fact that almost everything (relating to sizes/counts) are encoded in 16 bits or less. No function, for instance, can be larger than 65535 bytes. While that may be reasonable in *most* cases, it's nonetheless not very 'forward-thinking' (and would certainly make things such as inline functions practically impossible to implement in future versions). Other width-related limitations have even led to the introduction of things such as special 'widening' opcodes, adding yet another layer of complexity and inefficiency to the environment. And as time goes on, computers become more powerful, memory models grow, etc, these problems are just going to get worse - all of the sudden you could be faced with a development tool that just can't handle it. Which isn't to say that these problems can't be fixed, but it will definitely require some drastic changes to the specification itself.

Originally Posted by Sebastiani

I would love to see those features as well, of course, but that would effectively mean completely overhauling the language, which will probably never happen. Besides that, there are some inherent limitations in the virtual machine itself that indicate that it may not be the "language of the future". Just as an example, the instruction set itself can never exceed 255 unique opcodes, since no bits were reserved to allow for multi-byte encoding (there are ways around this, of course, but it would be an ugly hack), and considering that there are already 200+ existing opcodes, real estate is already pretty scarce. Another problem is the fact that almost everything (relating to sizes/counts) are encoded in 16 bits or less. No function, for instance, can be larger than 65535 bytes. While that may be reasonable in *most* cases, it's nonetheless not very 'forward-thinking' (and would certainly make things such as inline functions practically impossible to implement in future versions). Other width-related limitations have even led to the introduction of things such as special 'widening' opcodes, adding yet another layer of complexity and inefficiency to the environment. And as time goes on, computers become more powerful, memory models grow, etc, these problems are just going to get worse - all of the sudden you could be faced with a development tool that just can't handle it. Which isn't to say that these problems can't be fixed, but it will definitely require some drastic changes to the specification itself.

I'm not saying they should add those features to the current Java code. I don't think Java is flexible enough to handle those kinds of changes. They need to break backward compatibility and create a whole new Java. Isn't that what happened when they moved from the original Java to Java 2?

I'm pretty sure that Java1 is *binary* compatible with Java2, but I think I remember reading somewhere that some of the Java1 packages were deprecated (which of course would break an application just the same), but I'm 100% certain about that. I'd have to look it up.