vorg

The roadblocks for Apache Groovy migrating to version 3 are imposed by Groovy's backers themselves. They want to keep it as is for as long as possible to keep Gradle users hooked. If a non-compatible Groovy 3.0 comes out, then Gradle users would more likely upgrade from Groovy 2.x to Kotlin instead of to Groovy 3.0 for their build scripting language. The ASF Groovy project managers want to keep their consulting-and-conferences gravy train running for as long as they can.

> the history of the Universe occurred instantly when the first observation of it was made

Perhaps that history could still collapse into existence in stages, as subsequent observations of it became more detailed. The first observer would see far-off galaxies as small white dots in the sky, but not the composition and interaction of each, so perhaps those aspects don't decohere until later observers see more using telescopes.

And not only history but also laws of physics could come into existence in this way. If earthlings are the only observers in the Universe, perhaps dark matter holding galaxies in a circular shape is a law of physics which only came into existence when observers on Earth could start seeing inside other galaxies.

The iT industry is full of people who don't have a talent for tech stuff. A common path for them is to get work as a programmer, survive by keeping a knife hidden under their tongue, then get promoted to manager, architect, designer, or recruiter as soon as they can. It also happens in open source software.

When Apache Groovy was first released, it offered closures and dynamic typing on the JVM ecosystem, but nowadays Java has lambdas and inferred typing, so Groovy doesn't really have much fundamentally different to offer anymore. And since version 2.x, Groovy is also "trying to compete on Java's home turf" because it has static-typing annotations, but Kotlin and Scala are probably better choices if you want static typing on the JVM because it was baked into them from the get-go instead of being bolted on as in Groovy 2.x.

Grails is on version 3.x but not many people upgraded from version 2.x or are starting new projects in it, and the Grails 2 plugin ecosystem is dead. I don't know of any other web framework which uses Apache Groovy for its scripting. Groovy is mainly used in industry to script Gradle and write glue code for Java. If you want static typing, best skip Groovy and use Java, Kotlin, or Scala which were statically typed from the ground up, instead of having it bolted on in version 2 as did Groovy.

> Other JVM languages like Groovy are significantly ahead of Clojure in all rankings.

Apache Groovy fluctuates on TIOBE a lot. Six months ago it was at the same 50-ish position as Clojure, which is its usual ranking. It's shot up only in the past 6 months, which has also happened a lot in the past and is always followed by a sudden fall -- perhaps someone's gaming the search engine rankings. On Redmonk, Groovy and Clojure have ranked equal-ish for a long time. In the CloudFoundry report, Groovy is at the same very low rank as Others which would include Clojure if present.

So Groovy and Clojure are at the same ranking in all rankings I've looked at.

The multiplication table in the image is how school students learn multiplication in China -- the lower number is always first and it goes up to 9 only, down the columns shown in the image. That means there's only 45 different combinations instead of the 144 in the typical English-speaking system, so it's far easier to learn.

> to die a slow death

The operative word is here slow. Software is taken to the ASL by its backers so they can extract as much benefit as possible for as long as possible. They get an ASL Vice-Presidency position which they tout on their CV's. No upgrades to new major versions, just the current version milked via consulting and conferences.

There seem to be a few standard ways to evolve to the next major version of a programming language:

(1) Announce the next major version to be far off into the future, and say it will be as backwards compatible as possible to keep developers supporting the old version, e.g. Go 1->2.

(2) Build next version to be a little different to current version, provide no facility for interoperating between versions, then expect developers to switch over because of the branding, e.g. Python 2->3.

(3) Announce next version to be far off into the future, and say it will be a totally different language and expect developers to switch because of the branding, e.g. Perl 5->6.

(4) Don't announce or build a new major version, and keep profiting from developers using the current version for as long as possible, e.g. Java 1.x.

(5) Announce next version to be very soon, but delay it for as long as possible with unofficial roadblocks and keep profiting from developers using the old version for as long as possible, e.g. Apache Groovy 2->3.

> trying to find people who can work in Groovy on Grails projects - it's not easy.

That's because many of the people who used Grails to build a website didn't intend sticking around to fix the bugs or maintain it -- they just wanted to get paid and move on to hawking themselves as experts in the next fashionable technology. Others chose Grails because they saw they could introduce loads of technical debt thus giving themselves an opportunity to charge a high hourly rate later on.

> I won't be making the Groovy mistake again any time soon

Oh, so you didn't choose Grails so you could skim an agent's fee from sourcing these people? Many did.

... and Kotlin is a rip-off of Apache Groovy. But with static typing everywhere so it always works properly in IntelliJ.

> What's wrong with using Ant

XML

> or Gradle?

Apache Groovy

> groovy, scala, clojure, and kotlin injected some cool ideas, but might have done more harm by cannibalizing the community and proving that just because it runs on the JVM doesn't make it great

1. Apache Groovy gave people closures and builders on the JVM but at the cost of static type checking, and developers happily embraced it.

2. Then Scala came along and showed you could have closures without losing the static type checking, so many developers moved there instead.

3. Then Clojure came and brought closures to the JVM and lost the syntax, but no-one embraced it.

4. Then Kotlin came and showed you could have both closures and builders on the JVM without losing the static typing, and it's now everyone's favorite.

5. Finally, Java bolted on closures and Groovy and Clojure bolted on static typing annotations, but who's using them?

This article uses the word "hacker" solely to mean activities like breaking into computer systems and conducting illegal business online. This is perhaps appropriate because in Chinese, the word is always translated as the soundalike "heike" (黑客) which literally means "dark guest", thus alluding to that same meaning. If you talk about, or are seen using, Hacker News in China, they will initially only think of you as being a criminal or wannabe criminal, despite the other definition of hacker as being anyone interested in tech and programming (according to Wikipedia and Paul Graham).

The people nearby and friend invite requirements being in problem in India but not in China can be explained by:

> QQ messenger – already had over 750 million monthly active users by the time WeChat launched. A user could port her entire QQ social graph to WeChat by just logging in with her QQ ID.

It sounds like WeChat is really just a renamed QQ of sorts. So any adoption comparison of messenging app uptake in other countries with that of WeChat in China should use the QQ launch of 1999, which makes WeChat's rise to ubiquity far less impressive.

> Sometimes I think I should just use Kotlin, but then I would miss the ability to drop seamlessly into dynamic mode

You can use Apache Groovy for just the glue code and Gradle build scripts, and use a statically-typed language like Java, Kotlin, or Scala for the actual system you're building -- that's what most programmers do.

> My Scala started off much prettier than my Groovy code usually is, but by the time I finished it was an abomination

> Sometimes I think I should just use Kotlin, but then I would miss the ability to drop seamlessly into dynamic mode

Have you considered Clojure for this use case? That might alleviate your problems with using Kotlin and Scala, without having to resort to a single-target language like Apache Groovy. After all, unlike what Clojure, Kotlin, and Scala all offer now, we're never going to see an edition of Groovy that targets Javascript, Android, or native CPU.

When statically typed language C# added a dynamic keyword, that's a language going the other way.

Of course, no-one actually thinks of C# as being a dynamically typed language despite its dynamic keyword, nor does anyone think of Apache Groovy as being a statically typed language despite its @CompileStatic annotation. In the everyday world, C# is used for building performant systems and Groovy is used for glue code and build scripts.

Languages tend to go both ways nowadays. Go first shipped with both static typing (though without generics except for builtin datatypes) and dynamic typing (though using the wordy interface{} marker).

The whole point of these bikeshare services is that each bike has a GPS and the central system can livefeed the guaranteed location of nearby available bikes to a user's phone. If O-bike didn't have GPS, then it wasn't a real bikeshare service.

I wouldn't trust Mobike to be more about the bike than O-bike was, though. A few months after joining Mobike in China earlier this year, they decreased the default scale on the location map in their app when you first open it. Within a few months, the usual number of nearby bikes had noticeably decreased, but this was obscured in the app map because of the smaller scaling. It seems like they changed the app map scaling because they were planning the decrease in bikes in the local area. Perhaps they had collected enough deposits in this district, and moved the bikes in bulk to another district of the city with fewer signups to make it look like bikes were always available there, thus encouraging people there to pay deposits.

The article also says

> Scots never incorporated all that Norman stuff

So wouldn't that mean these 20 Norman words from your English-language comment above:

> enjoy, accent, difference, language, dialect, army, navy, insist, separate, nation, article, mention, real, study, master, local, pronounce, point, claim, apparent

wouldn't exist in Scots? That's a language, not a dialect.

When I worked in IT, both in mainframe programming and before that in ops, I saw many cases of this. "borderline" is just another word for "plausibly deniable". Programmers doing it can claim to have made a mistake. Managers turn a blind eye to it because it's easier than getting pay rises for staff they don't want to leave.

Many programmers who automate portions of their workload will use the extra time they gain to place bugs in the systems. When those systems fail, they quickly fix them and look like a savior. If they are on after-hours standby, they make extra money from the callouts. They thus reduce the stress in their own jobs, but increase the stress in other peoples jobs.

Perhaps humankind needs a "Butlerian Jihad", as defined in the Dune novels, where all machines made in the image of a human brain are banned for all time.

If anti-matter falls "up" wrt ordinary matter, but still self-attracts, then there wouldn't be any gamma producing zones.

Tiobe's faulty ranking method isn't even reliable. Three years ago Apache Groovy was in the top 20, but six months ago it wasn't even in the top 50. Now it's supposedly rising rapidly again. And this isn't the first time this has happened with Groovy -- it was also in the top 20 in Oct 2013 but three months later out of the top 50. I suspect Tiobe's rankings are being gamed somehow.

But mostly the language picked for a system is a well-used legacy language (e.g. Java / C / Befunge / Cobol ) chosen by a business manager.

Your Apache Groovy example doesn't work in Jenkins Pipelines, which cripples Groovy so the functional methods such as `collect` don't work.

You wrote elsewhere that

> I won't miss Grails because I think that, a bit like Gradle, it is an antipattern use of Groovy - needlessly applying its dynamic features where they are not even required

Groovy was designed as a dynamic language to complement Java. Its static compilation was tacked on much later, whereas Kotlin and Scala, like Java, were designed to be statically typed from the ground up, and they, unlike Groovy, also run on other platforms besides the JVM. If you're not going to use Groovy's dynamic features, you might as well use Java, Kotlin, or Scala.

Just because the currently-proposed Go generics is less bloated than those of C# and Rust doesn't mean it isn't "bloated" compared to Go 1.11. And I wouldn't call the description of contracts in the discussion document from last month "minimum complexity".

> Grails (built on spring boot) won't support anything higher than Java 8 until end of 2018.

Grails 3 is built on Boot but virtually no-one uses it. Websites using Grails have largely remained with version 2 and no-one's starting new projects in version 3, so I doubt the Grails backers will even bother to add Java 9+ support to Grails 3.

The Apache Groovy backers also seem to have given up on releasing a version 3. A few months ago, they pulled preview support for version 3 features from the upcoming Groovy 2.6. Since then, Groovy 3 has been stuck on permanent alpha version, with no-one in their project management committee showing any interest in moving it forward.

You needn't worry about Go being too simplistic for much longer. It looks like they're going to add a bloated form of generics soon, with something called "contracts" that's almost the same as "interfaces" but a little different. A few versions back, Go added "aliases" of types, but it was almost aliases of anything -- only intense community pressure prevented that bloat. And having had a special rule in its short-form declarations to make error handling a little terser, Go is looking at bringing another syntactic shortcut called "handle-check" to bring a little more error-handling tersity. Go's simplicity will be gone in a few short years.