Programming C, C++, Java, PHP, Ruby, Turing, VB
Computer Science Canada 
Programming C, C++, Java, PHP, Ruby, Turing, VB  

Username:   Password: 
 RegisterRegister   
 Why Java sucks
Index -> Java
Goto page Previous  1, 2, 3, 4 ... 14, 15, 16  Next
View previous topic Printable versionDownload TopicSubscribe to this topicPrivate MessagesRefresh page View next topic
Author Message
rizzix




PostPosted: Mon Oct 10, 2005 7:33 pm   Post subject: (No subject)

ehm? how am i to do that?... i actually don't think you understood me.. when i said that mix-ins was possible in Java i was talking about the java platform.. (the jvm).. then i further went on describing how it can be made compatible with java "lang".... i.e the mechanism involved in implementing the mix-in also ensures to implement the respective interface..

and i said that you can mimic such behaviour in java (the lang).. using aspectj yea.. but it's just the same thing as implementing the interfaces and writing delegate methods to the class in question.. (well in effect anyways).. well basically your gool old wrapper class technique.
Sponsor
Sponsor
Sponsor
sponsor
Martin




PostPosted: Mon Oct 10, 2005 7:56 pm   Post subject: (No subject)

I remember in my CS134 class when they were talking about the features of Java and they listed (as features) that it didn't support operator overloading or multiple inheritance.

I have to say, Java's kind of boring to program in. If I want something similar, I'd go with C++ instead (PLEASE, WE NEED A PREPROCESSOR (or something similar)). Or for fun, I'd go with Perl. Or Scheme. Or Ruby. Nah, just Perl.
rizzix




PostPosted: Mon Oct 10, 2005 8:01 pm   Post subject: (No subject)

operator overloading isin't all that cool.. so you took fancy for a new syntax... but just look at how it has been abused in C++... i see no point to it..

java isin't boring to program in.. specially when ur more worried about getting the job done rather than the crazy leet features that the language has in store for you..

i like java for what it is (i.e. simple).. i hate languages that are bloated.. (especially c++)

actually in that respect, even java has it's flaws.. but its much better than the rest.


PS: but when i'm in the mood of using the language for the sake of "features" i'm all ready for Perl6. Wink Nevertheless all my serious programming is only done in java
Martin




PostPosted: Mon Oct 10, 2005 8:10 pm   Post subject: (No subject)

I'll give you that Java is simple, but really, operator overloading wouldn't be a bad thing. Yes, it'd let you write gross(er?) Java code, but you can do that anyway without it.

I don't see how C++ is bloated compared to Java though.
rizzix




PostPosted: Mon Oct 10, 2005 8:20 pm   Post subject: (No subject)

Martin wrote:
I'll give you that Java is simple, but really, operator overloading wouldn't be a bad thing. Yes, it'd let you write gross(er?) Java code, but you can do that anyway without it.
what's the point of encouraging bad code? keep in mind that after operator overloading.. the code can literally get unreadable.. otherwise the worst it could get is "hard to read"

Martin wrote:
I don't see how C++ is bloated compared to Java though.
how can you NOT.. it's filled with useless grabage: direct raw-multiple inheritance, operator overloading, preprocessor directives, object-by-value, typedefs, structs, the void*, unions, bitfields, two different notations for initializations, awkward class member initialization rules, awkward template notations, implicit conversion (as in when you implement a conversion constructor, or whatever it's called), non-virtual methods, the extern keyword (which is actually completly redundant), static variables in methods, static file-scope methods (once agian it's completly redundant)...

and within it's operator overloading stuff you can actually overload the casting operator, the dereferencing operator, and even the new and delete operator... ack! ....total bloat! and heck yea there's a lot more..
Martin




PostPosted: Mon Oct 10, 2005 8:47 pm   Post subject: (No subject)

Like I said, you can write bad code without operator overloading too.

In Java it's perfectly valid for me to give all of my classes and functions single letter names and write everything in one long line of code without comments. Bad code? Yes. Unreadable? Yes. Do you think that Java should stop that too? I don't.

Yeah, you can write bad code with operator overloading, but it can also make code a lot easier to read and a lot more intuitive too. It all depends on the developer. You can overload casting so that you can create say, an Integer class and have it so that it can be cast to an int. Hmm...

And you're calling the preprocessor and typedef useless? Are you kidding me? Structs are useless? Huh? void* useless? I'm not really following you here...
rizzix




PostPosted: Mon Oct 10, 2005 9:02 pm   Post subject: (No subject)

Martin wrote:
In Java it's perfectly valid for me to give all of my classes and functions single letter names and write everything in one long line of code without comments. Bad code? Yes. Unreadable? Yes. Do you think that Java should stop that too? I don't.
Actually i think it should.. But how the hell can you ensure the programmer writes meaningful names..? besides when the programmer starts writting Japaneese or chineese character methods.. then it's a whole other story.. hence it's best the way it is..

Martin wrote:
Yeah, you can write bad code with operator overloading, but it can also make code a lot easier to read and a lot more intuitive too. It all depends on the developer. You can overload casting so that you can create say, an Integer class and have it so that it can be cast to an int. Hmm...

And you're calling the preprocessor and typedef useless? Are you kidding me? Structs are useless? Huh? void* useless? I'm not really following you here...
what can't you follow? it's useless.. or it simply clashes with other more dominating features... and void* only encourages bad code..

as for preprocessoer directive.. please.. it is soo totally pointless.. use inlines if you have to.. but seriously those perprocessor macros are useless.
wtd




PostPosted: Mon Oct 10, 2005 10:50 pm   Post subject: (No subject)

rizzix wrote:
Martin wrote:
Yeah, you can write bad code with operator overloading, but it can also make code a lot easier to read and a lot more intuitive too. It all depends on the developer. You can overload casting so that you can create say, an Integer class and have it so that it can be cast to an int. Hmm...

And you're calling the preprocessor and typedef useless? Are you kidding me? Structs are useless? Huh? void* useless? I'm not really following you here...
what can't you follow? it's useless.. or it simply clashes with other more dominating features... and void* only encourages bad code..

as for preprocessoer directive.. please.. it is soo totally pointless.. use inlines if you have to.. but seriously those perprocessor macros are useless.


Preprocessor directives are a bad thing, but that's an issue of implementation, not a condemnation of the idea entirely.

As mentioned, look at D's static if.

Instead of something like (yes, incredibly simple):

code:
#ifdef 42 < 56

#else

#endif


You might have:

code:
static if (42 < 56)
{

}
else
{

}


The difference is deeper than syntax. In the former, we simply perform text manipulations on the source code without any regard to the semantics of the programming language.

Additionally, macros can be incredibly valuable, but they should be implemented at a higher level than text substitution. See Dylan's macros for an excellent example.
Sponsor
Sponsor
Sponsor
sponsor
rizzix




PostPosted: Tue Oct 11, 2005 1:55 pm   Post subject: (No subject)

yea static ifs can be usefull for languages like C++.. but they are not of much use in java..
wtd




PostPosted: Tue Oct 11, 2005 5:09 pm   Post subject: (No subject)

Are you certain? More compile-time evaluation could be a very good thing for Java.
rizzix




PostPosted: Tue Oct 11, 2005 5:44 pm   Post subject: (No subject)

yes... but static ifs? i can't see how that can be of much use.
wtd




PostPosted: Tue Oct 11, 2005 6:03 pm   Post subject: (No subject)

Allowing compile-time resolution of platform-dependent issues, rather than forcing them to be evaulated at run-time? Admittedly, platform-dependencies should be avoided, but for optimization purposes they cannot always be.
rizzix




PostPosted: Wed Oct 12, 2005 1:03 am   Post subject: (No subject)

ehm... distributing source files is less a fad in java than it is in c++... in java it's preferable to just distribute the .class files and the javadocs that come along with it.. (the sources may also be distribute optionally if it's opensource.. but no one is exptected to recompile the software to just run in on the different platform..)

permiting static ifs only break java's concept of Compile once Run Anywhere..

how platform-specific issues are resolved in java:
native or platoform specific stuff is distributed separatly from the primary .jar file. since the code is designed from the ground up to be polymorphic... the sytem simply works.. (for a good example look at the JOGL library of java)

we just work differently.. get used to it.. we prefer good design over unnecessary bloat.. don't try to change the language when it's already proved to be quite successful.. in it's own little way.
wtd




PostPosted: Wed Oct 12, 2005 1:09 am   Post subject: (No subject)

rizzix wrote:
permiting static ifs only break java's concept of Compile once Run Anywhere..


I'm pretty sure J2ME did that perfectly well all by itself. Wink
wtd




PostPosted: Wed Oct 12, 2005 7:58 pm   Post subject: (No subject)

I'd like to add continuations to the list of features that would make Java suck less.
Display posts from previous:   
   Index -> Java
View previous topic Tell A FriendPrintable versionDownload TopicSubscribe to this topicPrivate MessagesRefresh page View next topic

Page 3 of 16  [ 228 Posts ]
Goto page Previous  1, 2, 3, 4 ... 14, 15, 16  Next
Jump to:   


Style:  
Search: