161–170 of 233 posts
> I decided Scala made it too easy to write code unreadable for most developers As a side note, this seems to be the biggest detractor for Scala. Any team that I have spoken to with Scala experience seem to have had projects that went too 'Scala/functional'.
Scala is the Perl of the JVM. :D
Earlier quoted context omitted.
The killer feature of Groovy is Spock tests. It really shines there.
sincerest form of flattery? http://spekframework.org
Earlier quoted context omitted.
Java will slowly absorb useful features from Kotlin until it's no longer necessary.
And eventually the C++ification of Java will scare away new developers who don't have years of context that explains the organic growth. Languages encumbered by backwards compatability and bolt on new features will eventually collapse under their own weight.
If the language designers keep their heads, Kotlin will slowly eat away at Java. Java itself is never going away: it's a Fortran or Cobol situation, only maybe three or four orders of magnitudes bigger. Xtend never was alive, and it's clear Ceylon has lost at this point, even though it is arguably better designed than Kotlin. However, they made some bad syntactic decisions (not shedding enough of the Java verbosity,…
> it's a Fortran or Cobol situation, only maybe three or four orders of magnitudes bigger. You underestimate the amount of COBOL code that is still out there running our daily lives: http://collaboration.cmc.ec.gc.ca/science/rpn/biblio/ddj/Web...
Fortunately, it has a JVM target too. http://documentation.microfocus.com/help/index.jsp?topic=%2F...
Earlier quoted context omitted.
groovy is great. It doesn't have much marketing behind it, so it's seems to be a bit of a quiet achiever. But for dsl makin', groovy is such a good language.!
We use Groovy in production, working with SQL, Transactions or JSON is much easier than Java. Meta programming and Traits are other advantages. The biggest advantage is that it is so similar to Java code, that any Java developer can pick it up and understand it immediately. We still love and use Java a lot and they both complement each other very well.
Perhaps Java 7, but Apache Groovy doesn't have the lambda syntax from Java 8. Development on Groovy has stagnated -- someone even contributed a fully working Antlr-4 based parser to replace their outdated Antlr-2 based one last year, but it's been sitting in their development repository at Github going nowhere ever since.
This article is very poorly thought out. First and foremost it talks about the __fall__ of JVM languages yet it forecasts good things for all of those languages. The author also failed to check out things like the TIOBE index where Java is still at the top. Not to mention that Clojure hasn't even been mentioned which is a __huge__ letdown since Clojure is the only pure functional language which is native to the JVM.
You may also be interested in Eta. Clojure reaslly isn't pure functional, strictly.
I'm not a Java guy, but I'm still wondering why nobody every wrote a JVM with near-zero startup time.
Well I am a Java guy and have two points to make. First. What are you even talking about? Quiet:test user$ time java Test Test real 0m0.104s user 0m0.074s sys 0m0.028s Quiet:test user$ That's on a current MBP 13" top end. And second: Who cares? What us "Java guys" do with Java, well, it doesn't matter in the slightest that it takes half a second to start. Because, we deploy to running processes. "We" power things lik…
If I want to write code that (say) is run dozens of times during a large build process, that's not really acceptable. The JVM is a poor fit for the Unix model in particular, which tend to use lots of small processes with a single purpose that work together.
Yes, there are workarounds (been there, done that), but the larger point is that the JVM and its ecosystem are primarily targeted at fairly heavy-weight and long-lived server processes that have obvious implementation biases along these lines.
The slow startup time is just one symptom of these implementation biases, and the question is not whether you can work around these problems, but why you should bother in the first place if the JVM is a poor fit for your application domain.
Earlier quoted context omitted.
You forgot Jini, https://en.wikipedia.org/wiki/Jini Also Oberon was another system that also allowed for something like Java applets, called Juice. http://www.modulaware.com/mdlt69.htm
Ugh, yes, so I did, though that was less about software deployment.
The other stuff like JNI (a registry for RPC endpoints) and java rmi itself were baked into the standard libraries from the beginning as well. But the envisioned "software agents running on arbitrary machines on the network" never took off, seems kind of foolhardy in hindsight, that anyone would think that's a good idea.
If the language designers keep their heads, Kotlin will slowly eat away at Java. Java itself is never going away: it's a Fortran or Cobol situation, only maybe three or four orders of magnitudes bigger. Xtend never was alive, and it's clear Ceylon has lost at this point, even though it is arguably better designed than Kotlin. However, they made some bad syntactic decisions (not shedding enough of the Java verbosity,…
> I started developing in Java, late 2001. At that time, Java was really cool. As someone who was there in 2001, I just have to say: Java was never cool, and especially not at that time. It was bloated and ugly and slow, the GC was terrible, applets were simply the worst, the UI toolkits available looked horrible on every single platform. There were no decent IDEs or editors and the language was if possible even more…