Live data from Hacker News

Rise and fall of JVM languages

blog.frankel.ch

151–160 of 233 posts

Re: Rise and fall of JVM languages

#151
post #143

Earlier quoted context omitted.

Clojure supports class based OOP? Never heard of it. Could you give me a link to the relevant documentation page?

Clojure supports protocols and multi-methods, the building blocks of CLOS, Common Lisp Object System. Already at Xerox PARC, Lisps started to support OOP, with FLAVORS for Interlisp-D being one of the first ones. EDIT: Disregard the last paragraph, lispm is right.

'Loops' was developed at Xerox PARC for Interlisp. Flavors was from MIT for Lisp Machine Lisp. Multimethods were first developed for Common Lisp in CommonLoops around 1986 at Xerox PARC.

Re: Rise and fall of JVM languages

#152
post #126
post #32

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,…

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.

Re: Rise and fall of JVM languages

#153
post #9

I'm surprised to see that Groovy slightly beats Kotlin in on that graph. I really underestimated Groovy popularity, or overestimated Kotlin. I've yet to work with Kotlin but did like Groovy some years ago. Never used it professionaly though, only for play-projects.

The killer feature of Groovy is Spock tests. It really shines there.

sincerest form of flattery?

http://spekframework.org

Re: Rise and fall of JVM languages

#154
post #104
post #74

Earlier quoted context omitted.

Kotlin is essentially Java with some sugar sprinkled on top. That's its strength: the semantics & the concepts are the same. I also never said Kotlin will replace Java, but that it will gradually grow to the detriment of Java, which is still here to stay.

I don't believe Kotlin will get much strong outside Android. In all these years of alternative languages customers still don't allow us to use anything other than plain Java.

Your customers can tell what programming language you're using?

Re: Rise and fall of JVM languages

#155
post #151
post #143

Earlier quoted context omitted.

Clojure supports protocols and multi-methods, the building blocks of CLOS, Common Lisp Object System. Already at Xerox PARC, Lisps started to support OOP, with FLAVORS for Interlisp-D being one of the first ones. EDIT: Disregard the last paragraph, lispm is right.

'Loops' was developed at Xerox PARC for Interlisp. Flavors was from MIT for Lisp Machine Lisp. Multimethods were first developed for Common Lisp in CommonLoops around 1986 at Xerox PARC.

Thanks for the correction. I typed it on the go without checking first.

Re: Rise and fall of JVM languages

#156
post #78
post #64

Earlier quoted context omitted.

That's incorrect. Scala had 13 years to achieve something while Kotlin is only around for a few years. If you extrapolate the current trends you will see that Kotlin will surpass Scala __very__ soon.

Kotlin is 6 years old, so about half the age of Scala - and, despite the heavy marketing, less than half the popularity on the chart in the article. We'll see what happens; Scala's growth has been slow and organic, but the flipside of that is that its success is down to the merits of its design. (There's plenty I don't like about Scala qua Scala, but I don't see it ever being displaced by a language that lacks HKT. K…

It's 6 years old if you count from the time it started development.

But nobody was seriously using it at scale until it stabilised, which was the start of last year.

Judged from its 1.0 "ok you can use this now" release, it's a little under 2 years old.

Re: Rise and fall of JVM languages

#157
post #104

Earlier quoted context omitted.

I don't believe Kotlin will get much strong outside Android. In all these years of alternative languages customers still don't allow us to use anything other than plain Java.

Your customers can tell what programming language you're using?

Yes, it is usually defined in the project contract, and we usually have to use customer configured environments, including source code control systems and CI infrastructure.

Also there are acceptance reviews from customer teams.

Re: Rise and fall of JVM languages

#158
post #145
post #86

Earlier quoted context omitted.

The Java servlet API and ecosystem was quite cool at least in the early years, IMO. Very simple and elegant model, and I did some commercial work with Java servlets. There were 3-rd-party servlet engines (before they started calling them fancier names like containers after J2EE v1 started :), like LiteWebServer and JRun (good fun using them), apart from the Sun reference implementation and and more heavyweight ones l…

We still mostly use JEE and Spring. I did a few Grizzly deployments last year.

Cool, thanks for the info. Had not heard of Grizzly, checking it out. Seems it uses NIO.

Re: Rise and fall of JVM languages

#160
post #19

Earlier quoted context omitted.

Maybe Gradle is the 'killer app' that keeps Groovy popular? I've heard from people with tricky build tool requirements that it's one of the best options out there.

I see Groovy in 3 places: Gradle files (a Kotlin alternative is coming), Jenkins pipeline build scripts, and the Spock testing framework. I don't have a good read on how popular Grails is anymore. I liked it a lot in the past but I don't need it anymore with Kotlin and Spring Boot.

> Gradle files (a Kotlin alternative is coming)

Gradle's been able to use Kotlin for build files since Gradle 3.0 which was released last year.

For Jenkins, only a subset of Apache Groovy can be used. None of the functional methods will work when used.

Grails 2.x is still around, but virtually no-one's converting their projects to version 3, or starting new Grails projects in version 3.

Groovy development has come to a standstill, and even contributions from outside developers just sit there, such as the new Antlr 4-based parser which someone contributed a whole year ago.

Post reply on HN