Qualified name syntax/dot`.`tightfix
Quote from dandl on July 13, 2025, 12:53 amJava is unusable (and unused) for any kind of games development ...
Except for the original Minecraft, aka "Java Edition."
And these: https://en.wikipedia.org/wiki/Category:Java_platform_games
Though Java is an odd choice for games. If I were asked to write a videogame, I'd almost certainly choose Unity (C#) or Unreal Engine (C++).
There are also some odd items on the list, like Galaxian which was released in 1979 -- almost twenty years before Java.
I did some work for a games studio earlier this year, developing the Java-based backend for their customer service system. The game itself is Unity with a Go backend, but they wanted a Java backend for customer service, despite having only one in-house Java developer out of a team of twenty or so software engineers.
Quote from Dave Voorhis on July 13, 2025, 4:49 pm... they wanted a Java backend for customer service, despite having only one in-house Java developer out of a team of twenty or so software engineers.
Is the customer service system doing anything specific to games software, or could it equally be managing customer service for widget-suppliers? Just because they're a development shop doesn't mean they have to develop in-house every bit of software in the company.
(With no disrespect to your Java or commercial systems analysis skills; but programming shops are generally terrible at straightforward commercial operations.)
Quote from Dave Voorhis on July 13, 2025, 4:49 pmQuote from dandl on July 13, 2025, 12:53 amJava is unusable (and unused) for any kind of games development ...
Except for the original Minecraft, aka "Java Edition."
No, I didn't know that one. It's not surprising if there are some random outliers...
And these: https://en.wikipedia.org/wiki/Category:Java_platform_games
I checked a few (not all) and they're mostly ports to Java ME, not developed in Java. Some are pretty old (Frogger, Lode Runner) before Java even existed. Still, more than I would have expected.
There is no reason not to use Java, if you don't mind writing your own game loop and related libraries. It's just that the relevant toolsets are missing.
I think the reason Unity went for C# may have been native support for coroutines, which are heavily used.
Though Java is an odd choice for games. If I were asked to write a videogame, I'd almost certainly choose Unity (C#) or Unreal Engine (C++).
Godot is getting a lot of love recently. It has its own language and some support for C#. I would hate to be forced back into C++, although I know it can be civilised somewhat.
And returning to the original topic...
IMO in a language supporting relations the syntax should not be ambiguous between relation/tuple and record/struct/class. AFAIK the earliest language to use '.' was when structs were added to C in the early 1970s. C++ followed with method calls. The syntax is widely known, familiar and comfortable (regardless of Haskell difficulties).
But treating structs as records (with the implication that they can be saved to and restored from external storage) is a leap, and not one I'm happy with. And conflating struct/record/tuple is a serious mistake. SQL just makes it all worse.
The ideal solution IMO is to embed an extended RA in the language.
- The ERA is at least SPJRUN, New, Aggregation, While, Assign (see Alice).
- Relational variables and expressions are strictly typed.
- Attributes may be defined in a global or relation namespace.
- No tuples.
- A relation may be assigned to or from an array/list/enumerator of struct
- Any RA variable can be local or remote.
- ERA expressions can be executed locally or remotely. ORM good-bye.
Quote from AntC on July 13, 2025, 9:50 pmQuote from Dave Voorhis on July 13, 2025, 4:49 pm... they wanted a Java backend for customer service, despite having only one in-house Java developer out of a team of twenty or so software engineers.
Is the customer service system doing anything specific to games software, or could it equally be managing customer service for widget-suppliers?
It's specific to one video game. The frontend allows customer service personnel to make changes to the (typically live) environment of a massively-multiplayer online game. Technically, it's querying and updating SQL databases and making RESTful API calls to various APIs.
Just because they're a development shop doesn't mean they have to develop in-house every bit of software in the company.
Indeed, they outsourced a fair amount of development, both of the game backend (which I didn't work on, though had some interesting chats with the folks who did) and the customer service system that I worked on.
What was notable was their requirement that we use Java, despite the fact that they'd have to maintain the system and their in-house expertise is C# and Go, both of which are arguably the main competitors to Java for that kind of system. It says something about the popularity -- or at least the entrenchment -- of Java for information systems.
(With no disrespect to your Java or commercial systems analysis skills; but programming shops are generally terrible at straightforward commercial operations.)
The company that employs me (which, as an aside has just been absorbed into a much bigger company) has a reputation for doing commercial work, which is presumably why we were hired to do it.
Quote from dandl on July 14, 2025, 1:24 amQuote from Dave Voorhis on July 13, 2025, 4:49 pmAnd these: https://en.wikipedia.org/wiki/Category:Java_platform_games
I checked a few (not all) and they're mostly ports to Java ME, not developed in Java.
Java ME is (or was) Java, but a different VM (or more accurately, different VMs) and different standard libraries.
The modern equivalent is Android with its branch of the Java ecosystem and (mostly) Kotlin (i.e., Java++.) How many Android games are written in Java vs Kotlin vs Unity/C# vs UE5/C++ I don't know, though my impression is that Unity/C# dominates.
Quote from Dave Voorhis on July 12, 2025, 8:26 pm
A lot of Java criticisms come from those who haven't looked at Java -- or at least good Java code -- since before Java 8 (where it changed significantly), and sometimes before Java 2. The current version is Java 24.
That number became meaningless from the moment they decided it would increase by one every half year, even if nothing had changed compared to previous version.
Quote from Erwin on July 15, 2025, 10:52 amQuote from Dave Voorhis on July 12, 2025, 8:26 pmA lot of Java criticisms come from those who haven't looked at Java -- or at least good Java code -- since before Java 8 (where it changed significantly), and sometimes before Java 2. The current version is Java 24.
That number became meaningless from the moment they decided it would increase by one every half year, even if nothing had changed compared to previous version.
Yeah. A retroactive renumbering of all Java before 8 to Java 1.x and all Java after and including 8 to Java 2.x would have been more meaningful, if it wouldn't have inevitably caused more confusion.
Have there been releases with no changes?
I thought they all added at least something.
Quote from Dave Voorhis on July 15, 2025, 4:00 pmQuote from Erwin on July 15, 2025, 10:52 amQuote from Dave Voorhis on July 12, 2025, 8:26 pmA lot of Java criticisms come from those who haven't looked at Java -- or at least good Java code -- since before Java 8 (where it changed significantly), and sometimes before Java 2. The current version is Java 24.
That number became meaningless from the moment they decided it would increase by one every half year, even if nothing had changed compared to previous version.
Yeah. A retroactive renumbering of all Java before 8 to Java 1.x and all Java after and including 8 to Java 2.x would have been more meaningful, if it wouldn't have inevitably caused more confusion.
Have there been releases with no changes?
I thought they all added at least something.
It's wrong to consider the Java version number meaningless. There have in fact been major improvements to Java with every 6 month version. Even though it's true they would release a new version number regardless of how much was changed, there are a lot of resources put into Java and it actually does improve a lot in that time. Moreover, the more frequent major releases are good for Java, as it means users can get improvements in a stable supported version relatively quickly rather than having to wait several years for them. Similarly, .NET has a major release every year, regardless of how much has changed, and every other major language I look at also goes on a regular 1 year cycle, rather than waiting longer.
Quote from Dave Voorhis on July 15, 2025, 4:00 pmHave there been releases with no changes?
I thought they all added at least something.
Changes to the language or changes to the runtime ?
IMO, there have been zero changes to the language from java 8 (which introduced functions-as-arguments - I no longer remember the precise jargon term) up to and including java 14.
I do not consider the runtime as being part of the language. Introducing "records" in the runtime does not change the language. It changes the amount of things you can achieve with some particular implementation that delivers that particular runtime, but it does not change the language. The world might disagree, largely because of a mistaken belief that the only thing that matters is how much you can achieve. My personal belief is that the first thing that matters is the solidity of what you can achieve. Bridges built in the roman era are still standing to this day. Which bridge that we have built in our age will still be standing in 4025 ?