Does really game development on Java suck? Why are we still here?

I guess I develop a Linux version that specifically says, when buying, that due to technical complications it is not supported. However offering a linux support email address for obvious problems, if such things exist on linux.
Since Linux users usually have a hard time getting anything to run, one would think they could fiddle around for themselves.
But good to hear that porting to Mac is so simple, App Maker thing, no problems, no support needed… Sounds good.

WRT: OO not being the easiest. Yeah, Pascal is a fantastic learning language. But given the feature set of Eclipse (and I assume NetBeans), specifically things like easy project creation, auto-magic display of documentation and quick feedback of syntax problems…I’d lean towards thinking learning to program would be easier in Java. The “design” might be ugly for awhile, but so what.

WRT: Performance and usability. I skipped on that cause I figured it has been covered ad nauseam. Short list off the top of my head:

  • structures
    Kill pointer bloat. Makes small composition reasonable. Possible to have linear access to memory. Possible to add SIMD operations and caching hints. This is a really really big one.
  • Packaged & versioned libraries.
    Lots of implications here. Footprint reduction and tossing poorly designed APIs are examples
  • Versioned language.
    Kill off some of the bad ideas. Type erasure, per object locks and identity hash come to mind. Covariant overrides: feature or bug?
  • Sealable packages.
    Allows much more aggressive optimization.
  • Caching of compilation aux data
    One big problem with Java vs. C++ is that AOT compilers have all the code that will run upfront and can spend a fair amount of time “thinking”. Java’s a dynamic language and can only spend small time slices. So rather than perform redundant work every time some set of code is run, cache out known features for a given set of code and use that as a starting point. Spend them slices on something new, dang it!
  • Change transport IR from Forth to some high level IR.
    (And yeah, you can half-assed create a high level IR from the current, but it’s not ideal) Makes high level optimizations very easy. Another biggy here is Hygienic macros (or templates that don’t suck) would be very easy and expand at runtime. Rewriting the same code over and over for various types is sucky. Verifier becomes easy. The size of the classfile would be reduced. It would make the JVM much easier to target for “other languages”. There’s no downside here kids! (other than that evil change thing)

Notice that a lot of these kinda tie together. I’m sure that there’s lots of other things, but I’m running out of steam.

Anyone know what the state of Maxine/Graal is? Or how Shark is doing? I know that Shark is in the JDK8 hotspot codebase (edit: I incorrectly had JDK9 here.) but haven’t bothered to check if it’s actually in use.

WRT: Coolest language ever - SmallTalk for the thousandth time you heathen!


true become: false

Do something cooler than that in BASIC.

That’s a fair point.

Covariant return value overrides are absolutely a good feature. The popular wisdom is “reads should be covariant, writes should be contravariant, read/write should be invariant” and there’s more formal ways of putting it with the LSP. A covariant return value from a subclass should be sound by that reasoning.

Now covariant arrays on the other hand are the worst idea since null.

As for become, check out http://bpaste.net/show/2753/ – I don’t know it’ll let you redefine True and False, since those are int subclasses, but everything else, pretty much.

Oh, I forgot a very big one (which ties in, yet again, to the above) concrete and packed arrays.

WRT: Convariant - This is one of the features that bother mean since language nannys deny me operator overloading, which is pretty easy to understand, and convariant overrides will be pretty difficult for most people. And yeah, the Map array thing is really annoying. What do you mean I can do map[“Some String”] = 3.5f; ??? And I have to do foo.getSomething()? You kidding me???

I don’t have a problem understanding operator overloading; I have a big problem understanding the code that people produce as a result of it :wink:

Anyway, I don’t think that the lack of it is what’s kept big studios from embracing Java wholeheartedly…

Cas :slight_smile:

Its probably also closer related to the skill pool; there aren’t that many good Java game programmers out there to complete a team. C++ is a safe bet and it works for all major gaming platforms too; Java doesn’t because of that blasted runtime. You know, the more this thread progresses, the more I start to see why the runtime is what keeps the platform down :s

What would be the smallest size the runtime could be crunched to when only implementing the very basic and gaming related classes?
I think for leagal reasons its not allowed.
But couldnt the runtime be shrunk to like 4MB when the developer only publishes the basic runtime+linked classes?

That would be some interesting project for the OpenJDK.
To have a tool that compiles a customized distributable and small runtime.
(With builds for Win,Mac and Linux)

That’s in the works as part of the library packaging thingy (JIGSAW maybe? JDK8 maybe?)

Really? Even for bignums? Complex numbers? Vectors? They already overloaded it for strings, making Java more loosely typed even than Python for that use case. You’re also soaking in it when it comes to basic arithmetic operators, as opposed to languages like SML which require different overloaded infix operators for floats and ints.

No modern language should be designed that constantly requires its users to petition its maintainers for special cases.

Perhaps I’m just naive, but do people really use operator overloading in, say, C++, for any cases other than mathematical types and stringish types? Now that I’m typing this, I guess people would also want to use them for various data structures as well (intersection and union of collections, etc.).

I guess my question is: how often do you come across code that uses operator overloading in a non-intuitive context?

Every time I see someone trying to use cout in the “canonical example” of C++ operator overloading :cranky:

Cas :slight_smile:

In code that I’d actually what to use? Never. And that’s my point. Lack of operator overloading sucks. Bad usage is BS…bad programming is already a given, so stop making my life harder. WRT: Outside of algebraic types, getter and setter are big.

Smart pointers (and similar resource handles) often use operator overloading. Iterators are common too. std:io streams are a weird case because I don’t think I’ve ever seen any other C++ stream classes use that style (even though I think it’s quite nice).

I’ve made heavy use of operator<< in a unit test framework to get nice error reporting out of it (kind of a turbo-charged Object.toString()) but again that was mostly just following the std::io conventions.

I don’t think I’ve come across many uses in real code other than that. Boost of course tends to do really weird things with them, but IMHO boost is pretty much an example of why you never want to write in C++ unless you really have to.

I’m a big fan of minimalist programming languages. If you want a language that gives you all the rope you want to hang yourself use c++. In my professional career I have seen so many more bad examples (eg std::io) of operator overloading than good ones. The day Java gets operator overloading is the day I’m looking for a new language.
Currently I am much more limited by my inability to stay focused on a single idea than any issues with my chosen toolset.

It’d be great if I could say “everyone’s free to make their own choice of language”, but it’s a naïve view of things when you take into account the edicts from customers and managers. It’d sure be nice if one of the most prominent languages of the world wasn’t making “hobble your programmers because they cannot be trusted with power” the byword of project management everywhere.

Given my experience and location, I have a pretty good choice of management environments too, should I need to exercise it, but not everyone’s that lucky.

I always thought that allowing operators to be defined as normal Java identifiers (eg. a dot b) would have been a pretty perfect compromise between the two camps especially given the very small amount of code that would actually benefit from custom operators, but then I’m always wrong :slight_smile:

Cas :slight_smile:

That reminds me of BASIC, no idea why. The more expressive a language, the higher the risk that a team of programmers will make it an unmaintainable hell. Hand out just enough bullets to shot everone in the foot once. Java is “nice” in that regard. I couldn’t imagine the team i work in switching to something like Scala.

It’s entirely possible there is a happy medium. My opinion is just that it lies somewhere beyond the 1960’s in terms of language design. Hell, I’d be happy if we could even build on the ground that algol-68 broke