Java-Gaming.org    
Featured games (79)
games approved by the League of Dukes
Games in Showcase (477)
Games in Android Showcase (107)
games submitted by our members
Games in WIP (536)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: 1 ... 4 5 [6]
  ignore  |  Print  
  Java is pretty cool  (Read 12474 times)
0 Members and 1 Guest are viewing this topic.
Offline princec

JGO Kernel


Medals: 343
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #150 - Posted 2012-11-01 22:56:49 »

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 Smiley

Offline sproingie

JGO Kernel


Medals: 202



« Reply #151 - Posted 2012-11-02 00:27:03 »

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.

Offline gene9

Senior Member


Medals: 9



« Reply #152 - Posted 2012-11-02 16:53:51 »

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!
Legends of Yore - The Casual Retro Roguelike
Offline gene9

Senior Member


Medals: 9



« Reply #153 - Posted 2012-11-02 17:57:42 »

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
Online Cero
« Reply #154 - Posted 2012-11-02 19:19:50 »

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.

Offline nsigma
« Reply #155 - Posted 2012-11-02 19:30:09 »

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.

Praxis LIVE - open-source intermedia toolkit and live interactive visual editor
Digital Prisoners - interactive spaces and projections
Online Cero
« Reply #156 - Posted 2012-11-02 19:58:34 »

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...

Offline deepthought
« Reply #157 - Posted 2012-11-02 20:31:44 »

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!

jocks rule the highschools. GEEKS RULE THE WORLD MWAHAHAHA!!
captain failure test game
Offline appel

JGO Wizard


Medals: 50
Projects: 4


I always win!


« Reply #158 - Posted 2012-11-02 20:51:50 »

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.

Check out the 4K competition @ www.java4k.com
Check out GAMADU (my own site) @ http://gamadu.com/
Offline gene9

Senior Member


Medals: 9



« Reply #159 - Posted 2012-11-02 22:41:11 »

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.
Pages: 1 ... 4 5 [6]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

Riven (18 views)
2014-07-29 18:09:19

Riven (13 views)
2014-07-29 18:08:52

Dwinin (12 views)
2014-07-29 10:59:34

E.R. Fleming (31 views)
2014-07-29 03:07:13

E.R. Fleming (12 views)
2014-07-29 03:06:25

pw (42 views)
2014-07-24 01:59:36

Riven (41 views)
2014-07-23 21:16:32

Riven (28 views)
2014-07-23 21:07:15

Riven (29 views)
2014-07-23 20:56:16

ctomni231 (60 views)
2014-07-18 06:55:21
HotSpot Options
by dleskov
2014-07-08 03:59:08

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:58:24

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:47:22

How do I start Java Game Development?
by ra4king
2014-05-17 11:13:37

HotSpot Options
by Roquen
2014-05-15 09:59:54

HotSpot Options
by Roquen
2014-05-06 15:03:10

Escape Analysis
by Roquen
2014-04-29 22:16:43

Experimental Toys
by Roquen
2014-04-28 13:24:22
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!