JOIN US!! persons who hate JAVA!!

Seriously though, you gotta be into S&M if you decide to develop something in Java yourself and you'll be doing part of the job.

The Ruby language is ok but I hate the Ruby community. Their perl bashing is especially irritating.

They bash perl? Perl is one of the largest influences on the design of Ruby, along with Lisp and Smalltalk.

>>42
Yes they do. Their mailing lists are filled with low attacks. Also they are trying to move away from perl apparently. They actually want to deprecate the range operator that perl has. ie: if(/start/../end/) { etc etc }
I can understand wanting to make it more orderly and whatnot but throwing away perfectly good things just because it came from perl is so retarded.

I rather people bash ASP than anything else.

I find using ranges in if expressions is confusing. I don't understand it anyway.

>>45
let us not allow anyone else to use something because i am too much of a retard to understand it

>>41
Lol, then again the Perl community bashes PHP.

>>46
Did I say that dumbass?

If you can't grasp something as simple as ranges, then >>46 is correct: you are retarded.

Ranges are simple.
Ranges used as booleans are weird.

>>35

You had trouble passing functions as a value?

What the fuck were you doing to mess that shit up?

>>51
Um, you can't pass functions in Java. That's the trouble.

>>52
That's what happens when using shitty languages. Sorting was a mess, I believe I had to write an entire new class implementing an interface with several functions to fucking sort an array, I was so pissed at it I ended up writing a small quick sort function straight from my memory for the array I needed to sort.  Shit sux man.

>>50
Not really. If it's in range, true. If it's not in range, false.

>>41
>>43
Python seems to have a similar issue with Lisp. Guido seems bent on assassinating the power of the language by removing anything Lispy that seems to have crept in - when they were only put in there in the first place to attract lispers to get a good user base for Python.

What happened to the java hate? Did it die?

Java rocks.

>>57
Lisp papers, paper wraps rock, Java loses.

That was unsynchronized. :(

>>59
but it's public, static AND void so you've no right to complain

The main power of interned strings (and other such objects) is the pointer compare.  if two immutable objects have the same pointer, then they have the same value as well; and by interning them, if they have unequal pointers, then the objects must also have unequal values. 

This solves a common type of computing problem, but not all.  Typically, processing the input of a large stream of text involves moving in and around a buffer, which you write to often, resize infrequently, and would never compare to another unit of text as a whole.  Interning this buffer is a massive waste of memory and computation.

Java has a bit of a nice compromise, as far as strings are concerned, having both interned strings, (String and its descendants) as well as mutables (Buffer, and its descendants).  Problem is, they are mutually incomprehensible.  Most of the operations that involve processing text work on strings, but not on buffers.  there is no suitable class adaptor since these methods assume that their arguments ARE immutable strings.  No part of the Java language or API treat strings and buffers uniformly.  The operations available to buffers are, at best, minimal, but more realistically, are broken.  Working with buffers is still faced with interning and then collecting a large number of single-use, immutable strings.

Objective-C has a very similar API design to Java, with most of the same features in the Foundation.framework, but with one major difference.  All structures are implemented both mutable and immutable, with immutables automatically interned (where appropriate), and all operations on those structures work in the expected fashion weather the object is mutable or immutable.  It even has a built-in localization mechanism which is minimally invasive to the programmer.  Objective-C's only boner is its garbage collection, or lack there of; reference counting is broken in Obj-C, since reference counting doesn't work period.  Wish they'd switch to boehmGC or some other sensible mark and sweep.  I am very fond of obj-c

>>61
Immutable strings: 10% of my stuff
Mutable strings: 90% of my stuff
Mutable strings: superset of immutable functionality, in theory, and may be computationally as efficient if you use stuff like reference counters and write on change. Immutable strings thus look absolutely useless to me.

Java immutable and mutable functions are incomprehensible. And what's worse, the good ones are only available for the useless strings. Furthermore, the buffer functions suck ass and you end up converting to crappy strings.

I believe the technical term for this situation is "shitty API".

It would be nice if there were a String interface that you could implement. Or if you could add things to classes after definition; that's a really powerful tool.

Obj-C has a half-finished garbage collector, which should hopefully be actually finished in 10.5.

There's nothing wrong with Java.  If you want raw speed and low level functionality then fine, go use C.  Java provides well structured OOP functionality and a wealth of base-classes to aid the programmer (try coding networking in C).  Hell, these days with the JIT compiler (correct, I said compiler, not interpreter) Java byte-code runs natively on your OS.  The things that make Java seem slow are AWT and Swing. These provide the programmer with easy front-ends, and quicker program production while as a drawback require a lot of resources from the native classes.  When you say Java is slow, most of the time you're referring to the front-end.

Anyone want to discuss writing games in Java?  With native LWJGL back-end, Java OpenGL functionality and speed is directly comparable with a game written in C++.  No Swing or AWT to bog the application down.  Just a few seconds longer to load while the byte-code is compiled by the JIT compiler, then you get your C++ performance from Java.

THAT MUST BE WHY SO MANY GAMES ARE WRITTEN IN JAVA!

IS JAVA READY FOR DOOM 3? I DON'T THINK SO!

>>65
It's not the speed, or lackthereof that I dislike. Frankly I think everyone who says "zoomj java is slow!" is missing the point - like you said, if you honestly need speed then use C. If, as in the majority of cases, you don't, use a higher level language.

No, my problem is that it makes you jump through so many hoops just to get anything done. If I'm gonna use a high level language I'll use Ruby or Lisp or something that gets the fuck out of my way. If I need speed I'll prototype it in a high level language and then translate it into C++ or something.

I also think you're full of shit btw:
The things that make Java seem slow are AWT and Swing.
Newsflash: AWT and Swing are just Java's toolkits. If you're writing a GUI app in any language you're gonna be using a toolkit whether it's Tk (ew) or QT or GTK or win32 (ew).
Java OpenGL functionality and speed is directly comparable with a game written in C++.
And again if you're writing an OpenGL game in any language you're going to get the performance of OpenGL whenever you make a call to it; any speed penalties will come from the overhead of writing the rest of your game in $YourFavLang - physics engines, logic etc.

Java OpenGL... speed is directly comparable with a game written in C++

Having written an OpenGL game in Java, I can honestly say that's the most batshit crazy claim I've seen this week. You'd have to really fuck things up in C++.

Oh, cool, the card is still performing just as fast as always, but your game logic isn't fast enough to take advantage of that.

Well, most games spend the majority of their time in the draw-loop.  Any overhead incurred by the AI/networking is minimal.

Its like coding in C and ASM.  If you code a whole game in ASM, its fast.  If you code a game in C, but use ASM for the graphics code, its still fast.  You only take like 2% speed hit for your sins.  Its not quite the same with java, but the speed hit you take for using java with openGL API is still minimal.

Just some examples. cya

Fast C code is generally slow Java code today
(assuming modern JITs).

C is fastest doing everything through array refernces.  In Java non-linear array referenes are expensive. C is slow generally at recursion, Java recursion can be blindingly fast. (Faster then a local array based stack in fact.)

Memory allocation in most C compilers is dirt slow.  Memory allocation in Java is highly highly optimized.

>>70

you are either batshit insane or a troll, or both.

Fast C code is generally slow Java code today
I don't know what this sentence means. Someone please parse it for me.

Memory allocation in most C compilers is dirt slow.  Memory allocation in Java is highly highly optimized.
The compiler doesn't allocate memory since, you know, it's something that happens at runtime. The OS does it.

oh noes :( java is slow. sun should just give up.  Seems very few people in this thread can see any positive side to using java.  Java has a lot of uses in the software industry. If its too slow for your liking, or you dont like the overhead, then no-one is forcing you to use it.  Go use assembly language if that does the job to your satisfaction.  Program your shit in raw binary if that floats your boat.  But if Java does what you need, why avoid it?

also, I assume the reason you dont see games released in Java is that most developers rely on a custom version of the JRE.  And I'm  pretty sure Sun will not let them distribute a custom JRE.

Anyone who makes games know you minimize calling malloc()/free().

Duh, hur, hur, I'm an idiot.

>>75

Indeed, we just use static arrays. Who the fuck would ever build more than 128 units in my RTS anyway?

>>69
Its not quite the same with java, but the speed hit you take for using java with openGL API is still minimal.

Speaking from personal experience: no, it's not. Even something like preparing a scenegraph in Java is a whole lot slower than I'd like.

Well, most games spend the majority of their time in the draw-loop.

Nice oversimplification there. Excluding sound, networking, AI, physics, etc, etc, etc, what you're left with is still going to underperform.

I suppose you could develop and call external libraries, but what's the point? You've lost portability, and Java isn't exactly a hot glue language.

Java just isn't meant for making high-performance games. Strategy games with simple AI? Sure. Adventure games? No problem. 2D RPG? So/so, but it's workable. Anything with 3D or a heavy AI? Forget it. Java's strengths lie elsewhere.

>>76
I hope you're yanking my chain. Static arrays are a good idea.

For situations where they're not flexible enough, you use an ADT (that also minimizes malloc/free). The key point is that memory allocation is dog slow, so you want to do everything in your power to avoid it, particularly in inner loops.

As for the guy who claims Java's fast with recursion, big deal. Tail-call elimination isn't exactly voodoo.

>>73
As I've said a number of times in this thread it's not the slowness that's the problem, it's the fact that it's a shit language that's a hassel to code in. If I'm going to take a speed penalty - and don't get me wrong, I'm happy to do that, most of the stuff I write doesn't need to be --omg-optimized - I'd rather use a language that's fun and doesn't take incredible amounts of code to do simple things.

True though everyone seems to be jumping on the "Java is slow" boat, which entirely misses the point.

>>79
Exactly. We all know Java is slow, with or without Swing/AWT, and Perl is even slower I guess. For what I'm using it, I don't care.

The reason why this thread exists is that this "well structured OOP functionality" is really a very shitty API, it's made of inheritance and mess. Even though you're given a lot of functionality, the API is so fucked up you have to instantiate your grandma (who inherits from OldRelative, Relative, People, Stuff, Entities, Matter, and Universe). Since you have to call methods from who knows what godforsaken, abstract, absolutely useless, stupid great-grandparent class (hey, we need this generalization, think families with several grandmas or other kinds of families where your grandmas are imps with large penises), so you have to fight your way through the unholy, messy spaghetti the APIs are; you can't possibly memorize all that bullshit and end up being very unproductive (a well known OO problem); and you end up writing several lines of code to do it, beating the original purpose of having libraries to do stuff.