Java is pretty cool

General Discussions
#141

[quote=“ctomni231,post:134,topic:39917”]
I’m not sure I follow. When developing an app, you typically look at its performance, and verify it runs at reasonable speeds on your target devices. If not, you cut back on calculations, one way or another.

Web apps will never dictate at what speed (javascript) applications will run, just as the usual OS processes don’t dictate which speed CPUs should run at. The environment dictates the boundaries, and developers may or may not try to do as much as possible within those boundaries.

Webapps will never get too powerful for browsers, just like programs never get too powerful for a CPU, simply because they will be rejected by the users, and the developer either goes out of business or solves the performance problem. If javascript performance is tripled next month, you’ll see webapps pop up demanding three times as much performance as before. If javascript performance won’t increase from now on, web apps will cope. Nothing is going to break, there is no thin wire.

Last but not least, I don’t quite get why you attribute Google with a major role behind javascript for browsers. Google was the very last to enter the browser environment with Chrome. We should be most thankful for Firefox and to a lesser extent Safari.

#142

What is the best language is better left for an academic discussion. Reality rarely favors the “best” anyway, because “best” is a very subjective term, ask an engineer and a businessmen what is the “best” programming language, the engineer will answer “The best designed language”, the businessman will answer “The one that creates most value for me/my customers as cost effective as possible”. Sadly, there’s little correlation between a well designed language and productivity.

So far, all the con points here about javascript are exactly that, “it’s shit”, a very subjective thinking from an engineering standpoint.

Windows 95 crashed every day back in the day, it didn’t stop it from becoming the most popular OS in the world, because no matter how often it crashed it was always many times more productive than the alternative.

Which language will be used a lot (does not mean “used exclusively”) in the future, the trend favors Javascript (among others), but not so much Java.

It’s already falling out of fashion to have JVM’s installed on the desktop side, Applets are disabled by browsers by default, difficult to find devices that support Java. On the server end, Java still has a fighting chance, but I don’t it will be for long, new languages that scale better are already eroding Java’s base there. That’s the trend for Java, and you don’t need to be a javascript lover to see that.

Just recently I found out how horrible Java is doing multiple asynchronous calls (deferreds) in the backend. I had to fix this code someone had written, he wanted to do multiple asynchronous calls, and he ended up creating one thread for every call he made, or roughly 100 threads, PER CLIENT REQUEST. Of course this was rectified with a thread pool and executors, but even with that it was nightmarish, because we had to somehow manage the executor service for that particular controller, and that added to the complexity and counter-productiveness.
This was no junior programmer who made this mistake, and he writes java all day long. Why seasoned java programmer stumble on this is self-explanatory, the language doesn’t promote doing complex things in a instinct-like, easy, productive manner. Given how “well” java is designed, the language constructs just don’t scale for the modern reality of mass-core servers and asynchronicity. Compare it to javascript and how easy it is do use jquery’s $.when().

XML is falling out of favor too, and JSON seems to be the programmers choice nowadays. Ever tried reading JSON data with Java? Well, it’s a mess because Java is strong-typed. XML is no better in Java. Javascript and JSON is a happy marriage.

But there’s so much happening on the front-end, with all the devices, and in the back-end, that if you truly believe Java is the way to go (full steam ahead) then you’re in for a surprise when in 5-10 years junior programmers will not work on your projects because it’s java.

#143

@Cas

Google are attempting only now to do something called Dart but of course it won’t work anywhere outside of Chrome.

You can cross-compile it to (modern-ish) JavaScript. Right now you get about 75% of the speed of hand-written JavaScript, but I’m certain that they will reach at least 90% in the not too distant future.

You also get source-maps, which means it’s still somewhat debuggable in this state.

Furthermore, there is tree-shaking (=dead code removal), which allows you to use large kitchen-sink libraries without having to pay for it. This is something which always bothered me with JS: every feature of your library is just dead weight in most cases.

Well, there is also some overhead for every language feature you use. So, there is quite a bit of initial overhead, but you still break even somewhere at the 50-100 kB mark.

Browsers would probably have been far better off if they used some sort of bytecode […] Maybe LLVM

It’s funny that you say that. :wink:

“Google already works on a multi-language bytecode: LLVM bitcode in PNaCl.”

@ctomni231

If it weren’t for Google pushing to great lengths to keep JavaScript relevant

Fun fact: Compared to 2007, JavaScript is almost 100 times faster now.

The original goal was to make it 20 times faster. (Dart’s goal is to be 2 times faster than V8.)

#144

@appel All those arguments can be used against C too, where the situation is much, much worse. Still, it’s alive and kicking, just not serverside. Today, Java can hardly be beaten for large serverside projects, while C can hardly be beaten for… well any desktop project.

Once a language establishes itself in a certain area, a massive ecosystem will emerge. This will give the language / platform momentum, which certainly won’t break down in the next 5-10 years.

#145

I’m sorry, but if your senior programmer was spawning a thread per request, it was either a configuration error from making a threadpool unbounded, or he just doesn’t know concurrent programming. Concurrency has many great subtle oddments to it, but it’s not exactly subtle when spawning a new thread is your first and last approach. Nobody is an expert in every domain, so his seniority may mean he was stuck in his ways rather than having had long exposure to modern concurrent idioms.

java.util.concurrent is a decent start, but it’s only going to become actually pleasant to use in pure java when JDK8 lambdas land in the language. Even then, j.u.c.Future is pretty anemic as compared to the akka/scala-2.10 version or com.twitter.util.Future, so there’s still some limitations there, but any of them still beat the weak opaque tasks in JS any day.

#146

WRT: Macros. Forget c/c++ & asm. In the simple case you write a type once…like say a 3d vector. Then you’ve covered 3d vectors over singles, doubles and any extended precision. Useful, but small potatoes. Next some type that contains more than one subtype. Now it combinatorial. Now consider (like I mentioned in the latest operator overloading disscussion) dual-numbers. One usage is automatic differentiation. We’re now talking about removing up to something like 10 engineering years of coding from some projects. Macros rule.

#147

Actually, that depends on many factors. Java serverside is not highly efficient for say, a simple chat server app. But for desktop it’s the best write once, run anywhere, VM for full sized apps, like games. It got a bad reputation due to a rash of bad coders writing a bunch of junk applets that were either malware or so poorly written they should never have been uploaded in the first place, like most of the Java IRC chat clients they still use today, for example.

A huge problem is maintenance of apps written, either they were not versioned correctly or they just didn’t keep up with the latest versions of Java. A lot of really awesome desktop programs, some proprietary, are written in Java, or written to support Java. It’s now more of a desktop app VM than an applet VM, and it seems Oracle is following that trend, focusing on the desktop VM environment more.

#148

On what criterion do you base that?

Again, based on what observations? Has JavaEE stopped being developed? Have they stopped working on glassfish? Have they abandoned JRockit, or Java for Oracle RDBMS?

#149

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

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.

#150

The criteria I base it on is experience.

#151

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 :slight_smile:

#152

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


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

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

to this:


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.

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.

#153

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.

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

#154

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

#155

OpenOffice is a Java app.

#156

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

#157

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…

#158

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

LibreOffice is fine! try doing ANYTHING in word 2007!

#159

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.

#160

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.