- 5 year olds should be able to learn how to make multithreaded applications
- Cross platform
- Great development tools (IDEs and such)
- You don't have to make/download amounts of libraries to develop great and helpful apps, the standard library is huge
Bad:
- Memory hog
- Java programmers: Herppppp Derpppp, internal char array?? nooo, its a string, what internal char array?? what is that
- No function pointers
- No operator overloading
- Everything is a reference, unless you implement Cloneable, sorry, i prefer "&"
- No #define
Name:
Anonymous2010-11-12 14:15
- No cudders
Name:
Anonymous2010-11-12 14:44
No function pointers
But you can make a function reference through the use of Reflection.
No operator overloading No #define
Nothing of value is lost.
I do agree, however, with your char array versus String point, mostly. "Mostly," in that I believe Java made a poor decision in making the basic String type that is likely to be returned by methods immutable. Immutability should have been a well-touted feature, not the product.
Another issue is get and set properties, which would solve all the language's cumbersome boxing/un-boxing issues.
Name:
Anonymous2010-11-12 15:49
All languages have great Dev tools if you know how to google
Most languages can be multi platform unless you make them platform specific
std is bloated
5 year olds that don't understand anything isn't a good thing
Citing ``cross-platform'' as being an advantage of Java over other programming languages is a great way to advertise you don't actually know any other programming languages.
Good:
It's an ENTERPRISE LEVEL PROFESSIONAL, ROBUST, SCALABLE, CROSS-PLATFORMING AND OBJECT-ORIENTED STRONGLY STATICALLY TYPED PROGRAMMING LANGUAGE.
Name:
Anonymous2010-11-12 20:20
Memory hog
its a VM language, there is no executable
Java programmers: Herppppp Derpppp, internal char array?? nooo, its a string, what internal char array?? what is that
buffer overflows anyone??
No function pointers
again....ITS A VM LANGUAGE, memory does not directly map to hardware memory
No operator overloading
not something you want in enterprise programming
Everything is a reference, unless you implement Cloneable, sorry, i prefer "&"
everything is Object Oriented, oh and did I mention that its a VM LANGUAGE
No #define
a preprocessor is not part of the compiler and is none to create/harbour very hard to find bugs
in conclusion:
just because you failed at Sepples, dont think that someone is going to turn Java into an idiot-proof Sepples for you
Name:
Anonymous2010-11-12 20:23
correction: and is none to create/harbour very hard to find bugs
and its known to create
Good, from I LOVE THIS to GOOD:
- Cross platform.
- Batteries included.
- Module system.
- Good VMs available.
Bad, from most annoying to annoying:
- No real functional programming support.
- No first-class functions.
- No decent lambdas.
- Statements and expressions (why this difference, you fucking pieces of FORTRAN shit?).
- No operator overloading. I can overload equals but not +, why, faggots? What's so different between the symbol "add" and the symbol "+"? Stupid idiots, if you had done any Lisp you'd understand.
- Static and explicit typing; shitty generics. As a result, we have nurupo too.
- ENTERPRISE multi-tier mission-critical turnkey professional scalable five-nines HA standard library (and third party libraries); really abhorrent and blasphemously queer and unproductive.
- No native syntax for cudders, dictionaries, etc.
- Formal OO bullshit: interfaces, visibility, final, etc.; keep it simple faggots.
- Java has got no macro system (nor C has a decent one), but then again languages outside Lisp don't.
- Not homoiconic.
No first-class functions
And they are not necessary.
I can overload equals but not +, why, faggots?
If primitives weren't so useful, there's a chance Java would have done away with them and we'd never see a +-/*% again. Additionally, the only non-primitive that uses any of those operators is String and they only use +. So you basically have a language that is designed to be devoid of your precious primitive datatype operators. Overloading only add() and not + is a deterrent against people misunderstanding the language.
As a result, we have nurupo too
In an object oriented language of any kind, I argue the concept behind a null pointer error is impossible to completely deprecate away. Besides, nurupo is cute.
No native syntax for cudders, dictionaries, etc.
We do have native dictionary syntax. Maybe it's not your "grandfather's holy dictionary syntax," but it is dictionary syntax.
Also, your car and cdr in Java is contained within the class method System.arraycopy().
Additionally, the only non-primitive that uses any of those operators is String and they only use +
Irony is strong in that. String should not used + for concatenation. Strings+Concatenation is not group, not field. It's monoid and therefore should use · operator. For the science, bitches.
>>16
Not a true module system, but the class dynamic linking is good enough for me. Well, almost anything will be enough as long as it's not the piece of shit multi-step [meta]configuring, compiling, library mongling, linking and the whole toolchains used in C and C++.
Clojure would be my language of choice on the JVM.
>>17
Yes, I said so (standard library ENTERPRISE).
>>18
Batteries included means the standard library is useful to get things done, i.e. unlike C.
First class functions are necessary unless you're some sort of Fortran faggot.
What you call operators are just functions (or "methods"), only they use infix syntax in your language. The fact you can overload some and you cannot overload some others is ridiculous, especially when they have some supposedly claimed to be syntax advantage (or wait, should we trash away infix syntax and use pure M- or S-expressions?). "+" means "add"; and writing a method "add" is not any bit least (or more) confusing than writing a "+" method, and there's nothing to misunderstand from using "+" versus any other kind of method. Nothing you can do will stop idiots from writing idiotic code; every attempt to thwart idiocy tends to bother good programmers when writing good code.
In an object oriented language of any kind, I argue the concept behind a null pointer error is impossible to completely deprecate away.
HIBT? Any decent, dynamically typed object-oriented language doesn't have nurupo. Python doesn't, for example; for special cases you use other, regular values like None (which is an object and has its methods, responds to reflection, etc.).
>>35
Are you trying to say that Google appended 'PHPSESSID...' to the output?
everyone put on your tinfoil hats, Google is plotting to overthrow... something/someone!
Name:
Anonymous2010-11-14 22:28
Things Java got right:
- Fast JIT compilation
- Pretty good bytecode language
- Lots of good VM research which will also benefit better languages
- Immutability for Strings. Although it'd be nice if they had some kind of Immutable marker interface and a type system that knew how to handle it LOL JASKAL
- No operator overloading
- No preprocessor
Things Java got wrong:
- Nothing functional
- Forcing programmers to distinguish between scalars and objects, when the language implementors should've worried about this instead. Also == and switch should work on Strings.
- Generics are fucking useless, a compile-time stopgap solution which delivers a lot of complexity and very little benefit. Almost worse than templates in Sepples.
- Standard library is too big
- J2EE and everything around it need to be killed as quickly as possible
>>37 Things Java got right: - Fast JIT compilation - Pretty good bytecode language WHBT
- No operator overloading
How is that a good thing?
Things Java got wrong: - Generics are fucking useless, a compile-time stopgap solution which delivers a lot of complexity and very little benefit. Almost worse than templates in Sepples.
Generics are indeed useless, in both Java and C#. Templates in C++, however, are not (Unless you're one of those Faggots that don't understand templates).
Name:
Anonymous2010-11-15 3:28
I think C# (at least on windows cuz honestly who gives a fuck about linux) is shit loads better then java.
1. Java has this shitty UI that looks like something from a 1990's kid movie.
2. C# has built in shit to work with native code. Java trys to act like it it doesn't exist.
3. OPERATOR OVERLOADING OMG /faint
>>39
Nobody uses C# on linux, but it's still better than Java. 'cause Java sucks, of course.
Name:
Anonymous2010-11-15 3:52
>>40
Of course. I mean I wanna fucking strangle the bitch who made minecraft with java. Seriously? It's like he tried to pick the one that would work the worst.
>>39
1. "Java" doesn't have a UI. A number of different UI toolkits for Java exist, including SWT, which uses the native widgets from your platform and looks exactly as you would expect.
2. Java has JNI, which is also "built in shit to work with native code", in your words.
3. Stop trying to write your own Complex and Matrix implementations, and you won't need operator overloading.
Name:
Anonymous2010-11-15 9:37
>44 3. Stop trying to write your own Complex and Matrix implementations, and you won't need operator overloading. FUCK YOU I WON'T DO WHAT YOU TELL ME
>>44 1. "Java" doesn't have a UI. A number of different UI toolkits for Java exist, including SWT, which uses the native widgets from your platform and looks exactly as you would expect. That's very nice and all, but I've yet to use a Java application whose UI doesn't look and feel completely out of place. Extra points if it doesn't even follow basic keyboard conventions.
All things considered, the end result is not much better than running something in a VM. Sure, the benchmarks will tell you you're getting 90% of the native performance, but the rest of the experience will be so mediocre that you'll desperately want out.
>>46 All things considered, the end result is not much better than running something in a VM.
It's not any better. Running an application in wine is much more seamless both in terms of performance and in terms of window dressings than running java apps.
Total run time benchmarks don't tell you anything about a UI application. Latencies have to be measured, and they never are. (I recently watched a Perl 6 talk in Japan by Larry Wall, he was saying "garbage collect!" every time you could spot the VM doing GC stutter... it was pretty obvious too.
>>39,44
1. SWT, ha ha ha ha ha ha ha ha, yeah it looks "exactly like a native app" put together by a monkey. There's a reason no sane developers are using Java on the desktop as of 2010 with the sole exception of... the people writing Eclipse. It's also a goddamn pain to use, especially compared to Cocoa or .NET. RIP, Java GUI toolkits.
2. JNI, funny joke. Take a look at .NET native interface or Haskell FFI to see how it's done in a way that makes actual sense and works the way you want. Just look at JNI code: you have to write all this messy C glue to stick it together. What did .NET and Haskell FFI get right that Java got wrong? In these cases, the glue code is written in Haskell or some .NET language, where it actually makes sense and you don't have to jump through a bunch of hoops just to avoid screwing with the runtime. In particular, if you need to pass a NUL-terminated string to a C function, you can do that pretty easily in both C# and Haskell without writing any additional C code.
3. It's kind of embarrassing that the Java folks say, "No, don't do operator overloading" and yet they overload the addition operator to concatenate strings. It doesn't make any sense. And what about quaternions? Multivectors? Versors? Groups? These are things for which you'd want to overload operators
>>42
Recommend ibuprofen to control inflammation, and stay at home to avoid infecting others.
>>48
Your post was 8.5/10, but the last line was really 10/10.
Name:
Anonymous2010-11-15 11:59
It must drive people in this thread insane, keeping them up at all hours of the night, that people still use Java or, worse, that people know what might be called "good" languages and yet still agree to program in Java.
>>48
But you don't need to and that's the point. Don't do things you don't need to do. That goes both ways: if the language is stupid about something, go around it and not against it.
>>37 - No operator overloading
Yes, because it's so far more confusing to define "+" rather than define "add". Down with infix operators! Oh, wait, this sort of bullshit about "operator overloading" (I like to call it defining infix-syntax functions) being wrong usually comes from the same people who claim Lisp's strictly prefix syntax sucks. The irony.
Also == and switch should work on Strings.
More irony.
- Standard library is too big
It's too shit, not too big. It does what it should do, but it does so in an overengineered, complicated, overdone, queer and abhorrent enterprise way that challenges your sanity and peace of mind. One day this inane, enormous pile of enterprise blasphemy and aberration will grow temporary eyes and limbs and become your master, not unlike a Shoggoth. Ever hear tell of a Shoggoth?
Name:
Anonymous2010-11-15 16:08
>>52
Syntax should be minimal and transparent. Adding additional methods with infix syntax complicates the language by making it more harder to tell at a glance what a given piece of syntax will really do. There is nothing wrong with Lisp's prefix syntax, but macros are unacceptable.
It's too shit, not too big.
I agree with your point about it being overengineered, but it is also too big. The rj.jar file from a recent Sun JRE is over 47MB on my machine. A trivial application causes around 330 classes to be loaded by the VM.[1]. That's way too much memory overhead.
>making a tile based game
>taught to keep everything object oriented; even the tiles themselves
>make it so each tile class is 1 byte
>make a 128x128x128 map
>look at memory consumption
>It's over 150mb of ram usage
god damnit are you serious?
>>59
I think he mena to say class EnterpriseLevelTinyTileClass {
byte TheTileInfo;
}
Name:
Anonymous2010-11-15 20:26
>>52 Adding additional methods with infix syntax complicates the language by making it more harder to tell at a glance what a given piece of syntax will really do.
Yes, because given objects a, b of any class, a + b is cryptic while a.add(b) is perfectly clear in intent and proceeding.
A trivial application causes around 330 classes to be loaded by the VM.[1]. That's way too much memory overhead.
True. Perhaps if the library weren't insanely overengineered, it could be as powerful in terms of functionality, but not require entire class hierarchies larger than Mordor to be loaded in order to display hello world.
Java programmers: Herppppp Derpppp, internal char array?? nooo, its a string, what internal char array?? what is that
It's more likely "Hey guys! We can be as fast as c++. But we could not use Vector<int> because our templates sucks. And we could not use Vector<Integer> because autoboxing is slow as hell. We will not use containers at all and will be fast! ha-ha!"