I'm a C++ programmer of more than 5 years now.
This year (I'm a sophomore), I'm taking AP Comp Sci. I'm the only sophomore in there since I skipped the introductory class.
We're forced to use Java.
Every day I use Java, I find something new that sucks about it. Shall I begin?
1) everything inherits from Object. This is Java's way of "efficient" and "useful" runtime type information.
2) exception to #1, basic types do not inherit from Object. Meaning that you can't use them with any Containers because Containers expect stuff that inherits from Object
3) addition to #2, there are types that inherit from Object and mimic basic types, and their naming is the same except with an uppercase letter. So Integer for int, Double for double, etc.
4) limitation with #3, these types cannot change. So if you have an ArrayList<Integer> and you iterate over it, you can't do x++.
5) exception to #4, these types can be automatically casted to and from the basic types (AKA "autoboxing")
7) even with the introduction of generics (like C++ templates in concept), Java stuck with Object. So ArrayList<Integer> is actually just a plain old ArrayList of Objects that happen to be restricted to Integers. And this is why you can't have Containers holding a basic type
8) Everything is reference based, except for basic types. Explicit references do not exist. Based on this knowledge, what do you think these two basic functions do?
[code]
static void foo(Integer x)
{
x = 5;
}
static void bar(int x)
{
x = 5;
}
[/code]
If you said that foo() modifies the original variable and bar() modifies a copy of it, you would be
wrong. With the genius combination of #4 and #5, foo()'s x = 5 is actually equivalent to x = new Integer(5). AKA the same thing as bar()'s x = 5.
9) No operator overloading. Piece of RK4 code in Java:
[code]
// compute the weighted average of the derivatives
// d = 1st + 2 * (2nd + 3rd) + 4th
// ---------------------------
// 6
Vec2 dp = Vec2.mul(
// a +
Vec2.add(a.pos,
Vec2.add(
// (b + c) * 2 + d
Vec2.mul(Vec2.add(b.pos, c.pos), 2), d.pos)
// * 1/6
), 1.0 / 6.0);
[/code]
10) limitation of #8, this means that functions cannot return multiple values. Many languages can return multiple values from a function directly, and other languages do this via references and/or pointers. However, Java can't do any of that. So, basically, you need to create a wrapper class every time you want to return multiple values from a function.
11) no such thing as a destructor, even though constructors and copy constructors exist
12) "fix" to #11, finalize() method is called before an object is garbage collected. Garbage collection is not guaranteed,though (for example, System.exit()).
13) no unsigned types
I can go on and on, but 13 issues are enough for this rant. Notice how many of the issues are actually additions or "fixes" to the other issues. Basically, Java is a big mess of "fixes" and "fixes" for those "fixes".
Related, don't ban please:
"Yo dawg I herd you like fixes so we fixed ur fixes so you can fix while ur fixed"
None of this is actually that bad. The only actual problem is that it's slow.
[QUOTE=Catdaemon;18407961]None of this is actually that bad. The only actual problem is that it's slow.[/QUOTE]
Compare it to another language like C++ or C# and, yes, it is actually that bad.
The only positive argument I've heard so far is "GUI." .... use C# for GUI stuff.
Almost all of these issues you have with Java seem be because you have some sort of closet love with C++.
That being said, some are very valid. Autoboxing was a feature Sun thought would be useful, but it just introduced more quirks than it helped solve. I think they should have been designed so that explicit conversions are required.
#10 => return an array or List?
#12 =>
[quote=Effective Java, 2nd ed. by Josh Bloch] C++ programmers are cautioned not to think of finalizers as Java’s analog of
C++ destructors. In C++, destructors are the normal way to reclaim the resources
associated with an object, a necessary counterpart to constructors. In Java, the gar-
bage collector reclaims the storage associated with an object when it becomes
unreachable, requiring no special effort on the part of the programmer. C++
destructors are also used to reclaim other nonmemory resources. In Java, the try-
finally block is generally used for this purpose.
[/quote]
It is my belief that finalize is broken and should be immediately depreciated.
#13 => seems like nitpicking
edit:
full disclosure: I am a fan of Java. I love the idea of write once, run anywhere (even if Java doesn't quite live up to this, with different platforms offering different JVMs that can differ pretty radically).
It's better than Flash in general. There needs to be some kind of really good hardware accelerated browser compatible standard. I thought Java was it, but apparently not.
[QUOTE=tjl;18408251]
#10 => return an array or List?
[/quote]
No, different types. For example, return a list of objects, and also how many of those objects should be foo (where foo is any condition or statement). You'd want to return an ArrayList<Bar> and an int, easily achievable in anything but Java.
[quote]
#12 =>
It is my belief that finalize is broken and should be immediately depreciated.
[/quote]
It's not just about resources, sometimes there's some logic on a destroyed object.
[quote]
#13 => seems like nitpicking
[/QUOTE]
No, there are valid reasons for unsigned types - anywhere where the value should indeed be unsigned. With Java, you're forced to assert that values are positive if you need them to be unsigned.
And, of course, Java doesn't have assertions. Just exceptions. Which it used for EVERYTHING -.-
[QUOTE=windwakr;18408293]The only good thing about Java is that it can run in a browser and is faster than Flash.[/QUOTE]
And also Java is an open standard.
Maybe you could return an ArrayList<Object>? Sure, it's a kind of ugly solution, but it might still work.
And I remember that Java does have assertions, but you have to start the VM with some flag or something to enable them.
Wow, no destructors, and that foo bar example sucks dick.
Oh and don't forget there is no multiple inheritance in Java.
Call me a C++ fanboy (I started with it, maybe that's why I think like this) but I've actually never found a programming language which has got a scratch on C++.
The only circumstances in which I would use a language other than it is for a convenient library or functionality like C#'s .net forms, or because I had to for my course (hence Python at the moment)
[QUOTE=Jallen;18408992]
Call me a C++ fanboy (I started with it, maybe that's why I think like this) but I've actually never found a programming language which has got a scratch on C++.[/QUOTE]
C# for GUI stuff, any scripting language for scripting, stuff like that.
But, yeah, the most general case C++ wins hands-down.
This isn't a C++ is better than Java thread, it's just a Java sucks thread.
3 things I hate the most are...
-Filename/Classname must match
-Exception handling
-Barely any functions, anything that is "OS specific" forget about it.
[QUOTE=ZeekyHBomb;18408841]
Maybe you could return an ArrayList<Object>? Sure, it's a kind of ugly solution, but it might still work.
[/quote]
Just another fix for Java's broken-ness. Like I said, you could just do this:
[code]
class Out
{
public int foo;
public Bar bar;
};
Out returnStuff()
{
Out out = new Out();
out.foo = 42;
out.bar = new Bar();
return out;
}
Out ret = returnStuff();
[/code]
But that requires a wrapper class every time you need to return more than 1 of something.
[quote]
And I remember that Java does have assertions, but you have to start the VM with some flag or something to enable them.[/QUOTE]
Oh, any more info?
[editline]05:49PM[/editline]
[QUOTE=high;18409141]
-Barely any functions,
[/quote]
Um, what? Java has integrated EVERYTHING for the most part. That's another good part, I guess. If you don't consider how slow it all is.
[quote]anything that is "OS specific" forget about it.[/QUOTE]
That's a plus, not a minus...
[url=http://java.sun.com/j2se/1.4.2/docs/guide/lang/assert.html]Java does have assertions[/url], and they are a first-class language statement.
For #12 I guess you could do something ugly like this:
[cpp]
Object[] objs = ...; // acquire polymorphic array
List< ClassA > clsAobjs = new ArrayList< ClassA >();
List< ClassB > clsBobjs = new ArrayList< ClassB >();
for( int i = 0; i < objs.length; i++ )
{
if( o instanceof ClassA )
{
clsAobjs.add( (ClassA) o );
}
else if( o instanceof ClassB )
{
clsBobjs.add( (ClassB) o );
}
}
[/cpp]
edit: nevermind this code, I see what you want to do. Ya, you need a new object for that. Your point is valid.
[QUOTE=tjl;18409190][url=http://java.sun.com/j2se/1.4.2/docs/guide/lang/assert.html]Java does have assertions[/url], and they are a first-class language statement.
[/QUOTE]
Oh, thanks. I'll put that to use.
[editline]05:52PM[/editline]
[QUOTE=nullsquared;18409240]Oh, thanks. I'll put that to use.[/QUOTE]
My fault here, then. My teacher doesn't teach us the useful things it appears.
I think Java has a lot of redeeming features also that no one really talks about. I'll just list a few as they come off my mind.
1. enums. (they are much more than a constants)
2. open source SDK (grepcode.com)
3. lack of pointers (ya everyone will say this is a con, but personally pointer arithmetic and management give me a headache more often than not)
4. anonymous class objects (probably not the right name, i'll provide an example if you don't know what i'm talking about)
5. (more) easily debuggable
6. inner classes (can provide something like namespaces, but also so much more)
7. fantastic standard library
8. separation from the machine through the JVM (yes, java is slow, but JVMs of today are much better than JVMs of just a few years ago. Using a VM allows you to utilize a CLR system, letting you execute different languages.)
9. very consistent standard naming conventions
10. annotations
[QUOTE=tjl;18409511]
1. enums. (they are much more than a constants)
[/quote]
Strong enums, ok.
[quote]
2. open source SDK (grepcode.com)
[/quote]
What is this?
[quote]
3. lack of pointers (ya everyone will say this is a con, but personally pointer arithmetic and management give me a headache more often than not)
[/quote]
And lack of references, since most things are implicit references. Just because it gives [b]you[/b] a headache doesn't mean anything.
[quote]
4. anonymous class objects (probably not the right name, i'll provide an example if you don't know what i'm talking about)
[/quote]
C++:
[code]
class
{
public:
int foo;
} bar;
bar.foo = 42;
[/code]
[quote]
5. (more) easily debuggable
[/quote]
Not really. MSVC's debugger > Eclipse's Java debugger, and I can't find anything to match Eclipse's Java debugger.
[quote]
6. inner classes (can provide something like namespaces, but also so much more)
[/quote]
??
[code]
class foo
{
class bar {};
};
[/code]
Oh, and it doesn't have namespace, right. Another con.
[quote]
7. fantastic standard library[/QUOTE]
It's not that efficient, though. Vast, yes. And it's inconsistent. Why is there a Collections.shuffle() but no Arrays.shuffle()?
O god, don't even get me started on LoadLibrary.
C++ has it's own problems too, and maybe I'm wrong, but it looks like C++ is your only point of reference.
[QUOTE=nullsquared;18409602]
C++:
[code]
class
{
public:
int foo;
} bar;
bar.foo = 42;
[/code]
[/QUOTE]
I'm talking more like
[cpp]
// this is code for android, which is why you won't find these methods in the JDK
button.setOnClickListener( new OnClickListener() // this is an interface - NOT CONCRETE
{
// now in here I implement the interface anonymously
@Override // I also love annotations
public void onClick( View v )
{
System.out.println( "button clicked..." );
}
} );
[/cpp]
Does any other statically typed language language have an idiom like this? (besides C#, i think they are called delegates?)
[QUOTE=nullsquared;18409602]Strong enums, ok.
What is this?
And lack of references, since most things are implicit references. Just because it gives [b]you[/b] a headache doesn't mean anything.
C++:
[code]
class
{
public:
int foo;
} bar;
bar.foo = 42;
[/code]
Not really. MSVC's debugger > Eclipse's Java debugger, and I can't find anything to match Eclipse's Java debugger.
??
[code]
class foo
{
class bar {};
};
[/code]
Oh, and it doesn't have namespace, right. Another con.
It's not that efficient, though. Vast, yes. And it's inconsistent. Why is there a Collections.shuffle() but no Arrays.shuffle()?[/QUOTE]
packages? you learn those yet?
Packages can provide namespace support, but only across multiple files. With static inner classes you can do something similar, all in one class.
[url]http://yosefk.com/c++fqa/[/url]
And I'm sure you could come up with such a list for C# too.
[QUOTE=tjl;18409881]I'm talking more like
[cpp]
// this is code for android, which is why you won't find these methods in the JDK
button.setOnClickListener( new OnClickListener() // this is an interface - NOT CONCRETE
{
// now in here I implement the interface anonymously
@Override // I also love annotations
public void onClick( View v )
{
System.out.println( "button clicked..." );
}
} );
[/cpp]
Does any other statically typed language language have an idiom like this? (besides C#, i think they are called delegates?)[/QUOTE]
Kinda pointless imo. I only find that stuff useful in scripting languages.
[QUOTE=tjl;18409881]I'm talking more like
[cpp]
// this is code for android, which is why you won't find these methods in the JDK
button.setOnClickListener( new OnClickListener() // this is an interface - NOT CONCRETE
{
// now in here I implement the interface anonymously
@Override // I also love annotations
public void onClick( View v )
{
System.out.println( "button clicked..." );
}
} );
[/cpp]
Does any other statically typed language language have an idiom like this? (besides C#, i think they are called delegates?)[/QUOTE]
That's not very useful. I'd rather have a "clickedPlay()" than a "onClick()" like so:
[cpp]
void playGame()
{
...
}
void foo()
{
playButton.setOnClick(boost::bind(&playGame)); // forget about "anonymous interfaces", just do shit
}
[/cpp]
Makes a lot more sense than anonymous classes.
[editline]06:52PM[/editline]
[QUOTE=Ortzinator;18409662]C++ has it's own problems too, and maybe I'm wrong, but it looks like C++ is your only point of reference.[/QUOTE]
C++ and C#. And scripting languages.
[editline]06:55PM[/editline]
[QUOTE=gparent;18410021][url]http://yosefk.com/c++fqa/[/url]
And I'm sure you could come up with such a list for C# too.[/QUOTE]
[quote]
C++ is not "mature" in the sense that different compilers will interpret it differently, and C++ modules built by different vendors will not work with each other. C++ is not "well-supported" in the sense that development tools for C++ lack features and are unreliable compared to other languages.
[/quote]
Um, what?
Yes, different compilers might have various quirks, but MSVC and GCC compile the same code quite successfully. BTW, C++ is not interpreted.
C++ modules build by different compilers won't work because different compilers use different name mangling. This isn't a C++ issue.
Development tools for C++ lack features and are unreliable? Never used MSVC and VAX?
I'm not so sure if I want to read that FQA.
[editline]07:00PM[/editline]
Yeah I read some more of it and it's basically "C++ doesn't have garbage collection and you gotta copy things manually, WHAT A SHIT LANGUAGE". And I don't think the author has heard of boost.
[editline]07:04PM[/editline]
[quote]
What about the allocation of our result - where does that Matrix live? If it's allocated dynamically with new and returned by reference, who is supposed to clean it up, in particular, who keeps the list of all temporaries created by a+b+c...? But if it's returned by value, then the copy constructor is going to copy lots of matrices. Bad if you care about performance. And if you don't, you surely wouldn't mind the smaller run time overhead of garbage collection (not to mention run time boundary checking and other kinds of safety belt), so you'd probably choose a different language in the first place.
[/quote]
This guy really doesn't know what he's talking about :bang:
[editline]07:11PM[/editline]
[quote]
As to the "arrays are evil" mantras - how about chanting them to the authors of the C++ standard library that defined an std::ifstream constructor accepting const char*, but not std::string? And they didn't define an operator const char* in std::string, either. std::ifstream in((std::string(dir) + "/" + file).c_str());. Give me a break.
[/quote]
Maybe because ifstream came before string?
And an implicit std::string -> char* conversion is a Bad Thing, I'll let you do your own research on why.
Aren't we forgetting the fact that the API is fucking huge? I spent an hour looking for one function and recreating it, only to find out that it existed in some really offbeat portion of the API.
Agree with OP, it's shit that we're also forced to use Java in my school, hate those fuckers.
Hey guys, don't hate your school, hate the CollegeBoard. Java is the only approved language by them, so if you take AP CS in the United States, you'll be learning Java. Even the catholic schools out here in SoCal have to teach it for AP CS.
My school didn't offer AP CS however. I always get the short end of the stick :(
can you debug java programs backwards?
:smug:
[url=http://stackoverflow.com/questions/282329/what-are-five-things-you-hate-about-your-favorite-language]What are five things you hate about your favorite language?[/url]
[editline]08:25PM[/editline]
[QUOTE=Eleventeen;18411655]can you debug java programs backwards?
:smug:[/QUOTE]
No but I can debug upside-down.
Java is a simpler language than C++, relatively lacking in language-level features that can be used to write concise code. (Generics are much less powerful than templates, for example, and the lack of operator overloading has already been mentioned). It's also more runtime-oriented: advanced stuff in C++ tends to involve template metaprogramming, which is all resolved at compile time, whereas advanced stuff in Java tends to involve reflection, looking up classes and methods dynamically at runtime.
The language's simplicity can actually be beneficial, in a way, because there are fewer subtleties in the code so it can be easier to read and understand. In C++, for example, a simple statement like "return a+b;" might actually result in execution of a complex operator+() followed by multiple destructors, hiding a potentially expensive operation behind what looks, at a glance, like a simple one. In Java there's no operator+() so a plain method call would be used instead, and destructor-like cleanup logic tends to be done with try/finally (implementing finalize() is discouraged) so there'd be a visible "finally" block following this hypothetical return statement. It's easier to tell at a glance that this code is doing something nontrivial.
On the other hand, Java code tends to be "less dense" than C++, requiring more lines of code to implement something, which can counteract the readability benefit somewhat.
I think Java's main strength is not the language, but the large and comprehensive standard library, and the even larger set of third-party libraries available, both free and proprietary. Many of these are oriented toward back-end business applications (Java EE), where processing power and memory generally aren't at a premium, so Java fits well in that niche.
tl;dr
[highlight](User was banned for this post ("Shitpost" - Lithifold))[/highlight]
Sorry, you need to Log In to post a reply to this thread.