The world is not Java, nor even the JVM.
Internet of Things, a market that looks tailor-made for the technology
Erlang, COUGH, COUGH.
Oracle appears to be making redundancies in the ranks of its Java evangelists team. One of the evangelists, Simon Ritter, has taken to Facebook to say: “I've heard it said that you should try something new every day. Yesterday I thought I'd see what it was like to be made redundant.” It's not hard to see why Oracle might …
I might be showing my age here, but back when I were a lad an erlang was a single telephony circuit occupied for 1 hour.
Ah the good ol' days of working for the Post Office in a Strowger exchange.
My hearing has never recovered,
Sad in the short term for the people kicked out, but in the long run they're probably better off away from Oracle, as we all would be.
Erlang was also a town in Germanysome weird-ass country in a prolonged post-war-crispy-bacon scenario, but then again Java was some Island that could be found in the Pacific, Oracle was a professional occupation held by crazy, drugged-up females from ancient Greece while Sun was a big yellow ball in the sky. Later, we also had Plan 9 (a movie) and Limbo (something an Italian once wrote a book on). Penguins were found in Antarctica only etc.
Errr quite.
What is it with all these fucking lame;
what about erlang?
what about haskell?
what about rust?
Because no-one can earn a living with them! I know.... I can say I know some esoteric language...before going to sign on for JSA/dole or whatever it's called these days.
What's replacement? PHP, Ruby, and Python have lightning fast development for small projects but their weak typing makes large projects a nightmare. Golang too often feels like an ancient language with a fresh coat of paint. C++11 and Java handle big apps well, but differently enough that I wouldn't want to be stuck with just one of them.
"C++11 and Java handle big apps well"
No, actually they give you the _illusion_ of handling big apps well, and that's where the problem starts. You end up writing huge applications with tens of thousands of lines, even though the core of your problem could be solved in a couple of hundred of lines. Even then you end up using huge libraries and frameworks which may have bugs or you might misunderstand.
The only way to deal with complexity is to avoid it, and that's something neither the C++ nor the Java crowds have managed. So far the only way to do this I've found is to train in Assembler. That way you learn that every control structure hurts, therefore you avoid it and tend to write better code in any language.
So far the only way to do this I've found is to train in Assembler.
Absolutely. But you have to do it in winter, using only vi and going uphills both ways. And no ordering books at amazon, you have to PERSONALLY drive to a shop 120 miles away and demand that their ordering process take three months and that they lose the package in transit. Did I mention bank switching?
How else can you make the children learn?
Christian Berger, 100% agree.
I was a Java developer in 2000-05 and saw this start happening, the simplest applications, about 500kb compiled were using 200Mb worth of external jars, it was crazy. So I moved onto PHP, and in recent years, I've seen the same thing happening here.
Lazy ass developers using the Zend Framework for 2-3 pages websites, or inappropriately using Doctrine to run a query which borks a server with 6GB RAM, but if done in raw SQL code would work on a machine with 256MB.
What those developers don't seem to understand is, there is a time and place for a Framework, but choose the right tool for the job!
A common mistake. The SIZE of the framework is irrelevant for many applications because there's plenty of CPU, ram, disk and network capacity. What's important is time to market, feature set, responsiveness to change requests, resilience, and the degree to which you want to piss off your users with bugs.
If you create a three page site outside a framework and then get change requests, a page here, a page there, never so much it's ever worth rewriting in a framework, eventually you end up with a mess.
Of course if you want to spend your time writing code that others have already written, debugged and actively support, you can. I always thought life was too short...
@Steve Crook - That is hyperbole. Framework size is everything, especially when it makes up 90%+ of the execution stack and response time. Memory and CPU may be in excess supply, but they still cost money, also the extra resources the OTT framework is utilising could be put to other use.
Also, who said not to use a Framework? Just choose the right one for the job at hand. Often developers resort to a position of comfort such as using Zend and Doctrine for that 3 pages website, rather than practicality and using something like Slim.
As a side note, developers who do choose right tool for the job, find they'll get the implementation done quicker, with less bugs and the project is more easily expanded.
@Steve Crook, That logic is why I get panicked calls from small companies wondering why their webserver can't even come close to meeting their needs. Lets assume your application takes 50 mb ram per user (I've actually seen this amount on a server) Now you have 100 hits per second in the evening and that's nearly 5 GB ram already and you aren't even making much money on the app yet.
"we don't care how much ram this takes" is Desktop centric thinking and even then customers are getting sick of it.
Agree, we have some sites, very, very basic pages, 1 image, form to fill in for amount and a shopping cart to put it in, done with dot net nuke, each site takes 500mb of ram when it starts up. Its been decided from now on developers will get VMs with little ram and CPU and they have to get it running well on them before it goes onto production machines. If it runs slow on their vm, they have to improve its efficiency.
@K
Spot on there, I agree with your thoughts on frameworks.
However your sentiment towards PHP heading down a similar road to Java im not so sure about.
I am excited about PHP7 and the vast performance improvements it brings and ive recently discovered HHVM for bringing down RAM and CPU usage. Its suprisingly awesome. Though I suspect it will be overtaken by PHP7 in the performance stakes...not so sure on the resource usage stakes though.
The thing that sucks about PHP is it is seen as a modern day "Visual Basic" level language to some devs (Java and Ruby devs usually)...ive no idea why though.
This post has been deleted by its author
If Oracle dumped their evangelists I suspect it's because people pretty much know instantly if they need it or not. Java isn't over and done with, not by a long shot although it's unlikely to outgrow its existing roles.
Let's not forget either that if you had a reason to use another language it doesn't necessarily preclude Java since Java is both a language and a runtime. The JVM does support Python, Ruby, Javascript, Groovy, Scala and a raft of other languages.
There are many languages to choose from and I have programmed in many (assembler, LISP/SCHEME, C, C++, TRAC(!), BASIC, ML etc.). I find that Java is good as a cross-platform language with graphics on all platforms. The current Java language is not developing in the right direction (or any sane direction) though. If I don't need the graphics I would use another language.
For raw computation I prefer C++ - the standard template library is great.
For more AI-type programming and fun I prefer LISP.
For enterprise computing I would retire.
"Might I suggest you take a look at Qt."
I looked at it a year or so back. (Version 4 if I recall.) I saw a homebrew string class, homebrew collections classes, homebrew dynamic casts and a simple slots and signals framework. It reminded me of nothing more than MFC -- a child of the 1990s before C++ actually standardised all these things and forever-after encumbered with their now-non-standard solutions to the problems.
The cross-platform would have been nice, but if it forces me to divide my code into bits that can use C++14 features and bits that have to stick with C++98 (or even ARM), then I'd rather code a native UI for each platform.
Most of the would-be "interwebs of things" Java devs I've talked to say one of two things:
"Don't you have to use some mobile edition version for embedded stuff? And they sue you if you don't? I don't understand. Let's steer clear of that."
"Oracle's suing Google for using Java. Let's steer clear of that."
The feel when you realize it's been 20 years and a few wars back that it has been "put onto the market".
It was nothing new back then but it was just time to have it ... no-one wanted to properly use Lisp or Smalltalk and people were dicking around with C and derivatives.
I have memories from long ago when Java was young and people found her attractive.
AFAICR it took a while to discover that there were three major variants covered by the same name.
Server side Java
Client side Java
Javascript
Further confusion when I was told that they didn't have as much in common as you might expect.
It might be helpful if articles made it more clear which variants were being discussed.