Java is pretty cool

[princec]

There are other criteria than how much RAM something uses or how much CPU it uses.... it is for example the work of an hour to make a chat server in Java having never seen the language before (It was the first program I ever wrote in Java, and indeed, the first TCPIP socket code I ever wrote). An hour well spent. Job done, server uses a few megabytes of extra ram over lovingly hand-baked C code that does the same job but which took a day to write and has a dangerous buffer vuln in it which will only be discovered in 3 years time when the server is rooted.

Cas

[sproingie]

AFAIK, none of java.util.concurrent is very dependent on lambda expressions. Can you elaborate on where that would really benefit?

Sure, it would cut down on the boilerplate.  From this:

1	executor.execute(new Runnable() { public void run() { dostuff() } })

(and let's face it your IDE will probably reformat that to several lines)

to this:

1	executor.execute(() => dostuff())

Sure, it may look minor, but when it stops looking and feeling awkward to use something, that thing tends to get used a lot more.

From my limited understanding, Akks is more on the level of JMS as a high level cross computer message queueing system. java.util.concurrent is much lower level and works with threads/pools/tasks.

Akka's got a lot of pieces you can mix and match.  It doesn't impose a distributed computing use case, and I'm not even fond of using it that way.  The Future interface it has is interesting on its own though, and can be used by itself without having to bring up an ActorSystem or any of that stuff.  There's plenty of other high-level concurrency stuff out there that isn't Akka, I just bring it up as an example.

[gene9]

Sure, it may look minor, but when it stops looking and feeling awkward to use something, that thing tends to get used a lot more.

That looks extremely minor. In normal threading-type code, I don't think that will matter much at all.

Now, for heavy higher order function usage with lots of map/flatMap, the simpler lambda syntax is very important.

Akka's got a lot of pieces you can mix and match.  It doesn't impose a distributed computing use case, and I'm not even fond of using it that way.  The Future interface it has is interesting on its own though, and can be used by itself without having to bring up an ActorSystem or any of that stuff.  There's plenty of other high-level concurrency stuff out there that isn't Akka, I just bring it up as an example.

You're right. Akka has a more complete Future and some other workflow stuff that is usable without a fully distributed setup.

Games published by our own members! Check 'em out!

[gene9]

Today, Java can hardly be beaten for large serverside projects, while C can hardly be beaten for... well any desktop project.

I disagree on both counts:

For server work: Scala on the JVM is substantially better than Java for the programmers that can pass the learning curve.

For desktop apps, I believe it's split:

Some apps seem best done in C: Text editor, music player, web browser, chat client. The OS-native GUI widgets and lack of runtime baggage of the VM is nice.

For my mega-IDES (IntelliJ and Eclipse) and tools like GePhi which I use for graph analysis, JVM seems to work better. My suspicion is the developer tools helps them manage and organize the complexity better.

A lot of the more complex C/C++ desktop apps I use seem to be a mess: OpenOffice/LibreOffice is one high profile example. I suspect that the team would have had better luck cleaning that up and improving it if it was in Java.

Games is another big category. It seems that C/C++ are successful at doing multi-platform iOS/Android/Console work, but for Linux/Mac/Win, C/C++ is just awful. I suspect that JVM is really untapped in it's potential for desktop games. I believe the dev tools are much better, you have to deal with way less hacks than C/C++, and the performance is close enough to C/C++. The downside to JVM for games is that it's mobile and console story is terrible. Even for Android, I'm skeptical that the Dalvik code path is performance competitive with the C/C++ NDK

[Cero]

A lot of the more complex C/C++ desktop apps I use seem to be a mess: OpenOffice/LibreOffice is one high profile example. I suspect that the team would have had better luck cleaning that up and improving it if it was in Java.

OpenOffice is a Java app.

[nsigma]

A lot of the more complex C/C++ desktop apps I use seem to be a mess: OpenOffice/LibreOffice is one high profile example. I suspect that the team would have had better luck cleaning that up and improving it if it was in Java.

OpenOffice is a Java app.

Actually, it's mostly C++, and in LibreOffice there's ongoing work to remove the dependencies on Java that are there.

[Cero]

A lot of the more complex C/C++ desktop apps I use seem to be a mess: OpenOffice/LibreOffice is one high profile example. I suspect that the team would have had better luck cleaning that up and improving it if it was in Java.

OpenOffice is a Java app.

Actually, it's mostly C++, and in LibreOffice there's ongoing work to remove the dependencies on Java that are there.

why would you even mix the 2 ?
It's like in one of the first commercial games to ever use some Java, I think it was Vampire the Masquerade; and it used Java only for AI or pathfinding I think...
Why would you mix 2 languages which can do the same in integral parts of the project ? Some C++ for deploying I could understand for example...

[deepthought]

I wouldn't know. i was able to use all of the functions i needed even if it couldn't find a JRE.

A lot of the more complex C/C++ desktop apps I use seem to be a mess: OpenOffice/LibreOffice is one high profile example. I suspect that the team would have had better luck cleaning that up and improving it if it was in Java.

LibreOffice is fine! try doing ANYTHING in word 2007!

[appel]

A preference of language over talent to make software is highly erroneous.

And talents prefer languages that get the job done, efficiently and well.

Choose the wrong talent, he'll choose the wrong language, and the end product is a mess.

[gene9]

LibreOffice is fine! try doing ANYTHING in word 2007!

I can't stand Microsoft Office either.

Personally, for spreadsheets, I like Google Docs: launches quickly, closes quickly, super responsive, clean and easy to use GUI, plus the cloud hosted and live sharing features. Just perfect!

For docs and slides, I prefer LaTeX. You can get precisely what you want, the editors are lighting fast and simple, and the whole workflow is well suited to the mind of a programmer. And final output .pdf documents look *beautiful*. Particularly math equations, but even basic text and tables look eye wateringly gorgeous. You can also get excellent chemical symbol notation, scientific unit output, electric schematics, diagrams, auto formatted bibliographies and citations, and pretty much everything else. Microsoft Office generates junk in comparison.