Linked by kap1 on Thu 25th Apr 2013 11:45 UTC
Java The Lightweight Java Game Library provides a simple API to OpenGL, OpenAL, OpenCL and Game Controllers enabling the production of state of the art games for Windows, Linux and Mac. Version 2.9.0 contains a complete rewrite of the mac backend, support for FreeBSD, new OpenGL/OpenCL extension and bug fixes. The library is used by many high profile games such as Minecraft, Spiral Knights, Revenge of the Titans, Project Zomboid, Starsector, JMonkeyEngine, etc.
Thread beginning with comment 559832
To view parent comment, click here.
To read all comments associated with this story, please click here.
moondevil
Member since:
2005-07-08

You are right about that one. These languages are designed for VM work, but nothing prevents one from translating VM bytecode to its native equivalent, no matter how inefficient it can get without the optimizations made possible by knowing the run-time state of the program at translation time.


The fact that strong typed languages are usually mixed up with VM implementations is an unfortunate fact from young generations not understanding what compiler design is all about.

Strong typing or automatic memory management have nothing to do with VMs.

Besides the issue of context discussed above, it would only eliminate the runtime compilation overhead of the VM, without tackling some other kinds of runtime inefficiencies which are intrinsic to those languages, such as garbage collection cycles.


Using GC enabled languages means you need to code in a different way, just that.

Malloc and friends can be slower than reference counting/GC implementations, depending on the use cases. Not all compilers for languages with manual memory management have performant heap management.

Since my Oberon and Modula-3 days, I am firmly convinced that it is only a matter of time until the hard code C developers get replaced by developers that appreciate GC enabled systems programming languages, generation change will help the process.

Reply Parent Score: 3

Alfman Member since:
2011-01-28

moondevil,

There are pro's and cons of each. Sometimes I prefer having unmanaged pointers and non-GC languages because they give more control and they are more deterministic, but a counterpoint could be that few developers really need this low level control and the sort of determinism we're talking about isn't significant in the grand scheme of things.

There's no doubt that many programmers screw up unmanaged code and it's the cause of some of the most dangerous vulnerabilities. If someone will not or can not do unmanaged code correctly, they'd undeniably be better off with a GC language.


"Using GC enabled languages means you need to code in a different way, just that."

I actually prefer coding style with explicit allocation/deallocation since I think it makes the program's intention clearer than a GC program, and it motivates developers to truly understand the problem better than the GC solution. With GC, we often take memory management for granted, but this can cause oversight of unnecessary alloc/frees activity going on under the hood that would have been caught if it were explicit.


"Not all compilers for languages with manual memory management have performant heap management."

That's true, GCC's default C allocator was pretty bad for multithreaded code the last time I benchmarked it. Although it depends on too many factors to make a generalization.



"I am firmly convinced that it is only a matter of time until the hard code C developers get replaced by developers that appreciate GC enabled systems programming languages, generation change will help the process."

I'm not convinced GC enabled programming languages are better, but I can probably admit that GC languages will tend to produce better code in the hands of the most typical software developers ;)

Reply Parent Score: 2

snowbender Member since:
2006-05-04

With GC, we often take memory management for granted, but this can cause oversight of unnecessary alloc/frees activity going on under the hood that would have been caught if it were explicit.


This is a good, important point: when GC is available, a lot of developers take memory management for granted, and do not care about it anymore. I have the impression that the newer generations of developers do not even know what exactly is going on behind the scenes. And, personally, I think that you can only fully take advantage of things like e.g. GC if you do know what is going on behind the scenes. For the same reasons, I do think that it's very important to know the complexity of operations on data structures that are included in the vast libaries of e.g. Java and C#. Sadly, I've realized that only very few developers know for example the cost of adding a new element to an ArrayList.

Reply Parent Score: 2