vorg

India's started doing it too. The situation with Indian foreign students in Australia/NZ right now closely resembles that with Chinese ones in the 1990's, so I predict the high immigration that happened with Chinese then will happen with Indians soon.

Nigeria won't have 800 million people by 2100, nor Africa 4.4 billion. There'll be some catastrophe well before then.

> There's a reason people with less social contacts have, in general, a shorter life span

Or people who are obviously going to die earlier will get less social contacts -- the causation could be in either direction. Perhaps they don't form the social contacts because they don't want to make others who get to know them be the ones to suffer sadness when they die first, or they don't want to burden others with feeling they should look after them when they get sick first. Or perhaps it's the others who don't want to risk the sadness or incur the burden.

That would mean evolution was smart enough to use those mechanisms in quantum computers, using human brains as a transient intermediary to that end.

> They do this with a few trains in a row until there are enough people waiting in the station to fill up a train to some acceptable level

The "acceptable level" probably doesn't account for everyone getting a seat on the continuation train. This used to happen with buses in Wuhan 10 years ago. If two buses on the same route met up and each had only seated passengers, one would send its passengers to the other bus to stand for the rest of the journey. This was annoying because I would travel places at off-peak times just so I could get a seat.

And of course, because this happens occasionally, it affects everyone using the Shanghai Metro because they all need to build in contingency time when planning a trip to get somewhere by a certain time for an appointment.

> Microsoft was pushing VB, which sort of resembles what you're saying, but VB wasn't a 4GL

Every marketing department was calling their company's new software development product/language/whatever a "Fourth Generation Language" back then. There's no actual definition for what it really means. Perl, Python, Ruby, and PHP represent a trend that peaked the 1990's, some came before and some after, so there's no need to read "1990's" literally.

My total memory (i.e. work, study, and hobby) of that extended decade (1985-ish to 2005-ish) was VB, VBA (Access, Excel), Java on Windows, Quattro Pro, dBASE 3+, Perl, Cobol on IBM (and ICL), and a myriad other obscure mainframe languages and mini-languages that probably still get used in banks and insurance companies.

> I don't recognize your description as corresponding to any events I remember

My previous description of that time was quite typical for many of us. For example, I remember in 2001 developing a five-line Word macro for an accounting department on a leftover 386 sitting in the corner running Windows 95 that read in a file couriered in daily from some other company's Unix system that stripped out some incompatible data from each line. After I deployed it into production, the user every morning started Word, opened a Word document that contained a button on a form, clicked on the button, selected the day's file from the floppy, then waited (at the water cooler) while the macro ran. They then renamed the output file so the date was in the name, and copied it from the LAN to the mainframe using some proprietary program, so it could be input (with the funny Unix bytes removed) to the overnight processing run. Perhaps you worked in the other company sending that Unix-based file to us every day, and didn't see the ongoing after-effects of your C++ program that produced the file.

> they soon built their own

C#, Go, Swift, etc.

> it seems unlikely Google would have a page listing trademarks it doesn't actually own

Putting a ™ symbol after a name is only a claim on that name to be one's own property for use as a mark on some product or service when trading, and big corporates do this all the time. So I think it's likely Google would have such a page.

> I also don't think there is actually a trademark on the term "Go" based on this USPTO search

There's a distinction between a trademark and a registered trademark. Registering the name in some jurisdiction's database just means the corp has begun its defense of that claim before it sees a perceived infringement.

I would imagine everyday words like "Go" (or "Groovy") wouldn't be accepted by the US trademark office anyway, so perhaps Google tried but failed to register it there. They might get "Golang" accepted but the Go team have said the name of the language is "Go" not "Golang".

> PHP, Python, Ruby, Tcl, OCaml, Lua

Many of those languages came out in the 1990's when the big corporates were busy pushing visual 4GL's to replace programming languages. But programmers prefered to write a Perl ten-liner rather than fire up a visual environment, click on some toolbars to place some widgets on a form, link in the data files using the right-click form, wait while the OS thrashes the hard drive as it paints the screen for the first test, and on and on. When those corps realized they'd dropped the ball, they soon built their own.

> the implementation of Go, and people who can make changes to the specification of Go

Should that be "the reference implementation of Go" ?

The specification mentions "implementation restriction" many times, so the Go spec writers seem to be encouraging other implementations. Besides gc, google also provide gccgo. If you download the gc source, change it a little so it still conforms to the spec, and publish, then that would be another implementation of Go. I believe there's an incomplete JS-based version of Go around as well, so if that's ever finished, that would be another implementation of Go.

Even if the Tiobe rankings said Rust was popular, it wouldn't mean much. Their May 2019 rankings also say Apache Groovy has risen from #91 to #17 over the past 12 months, which is clearly wrong. Those rankings are being fiddled with via search engines such as Baidu.

Apache Groovy's string syntax is deficient, not great. It doesn't have the docstrings syntax that Python, Ruby, and Perl all use.

An early beta version of Groovy 1.0 had it (thanks to a Sam Pullara), but it was later yanked out. Groovy's self-styled Project Manager at the time said he only wanted syntax in Groovy that would cause the Java syntax highlight rules in Eclipse and Netbeans to highlight Groovy code similar to Java, so if a manager was walking around the programming area, the screens would look like the programmers were using Java.

And that's how Groovy got its deficient string syntax.

Kotlin's main improvement on Java is its seamless integration with the most popular IDE on the JVM. Of course, it helps that IntelliJ and Kotlin are put out by the same company, but Jetbrains did emphasize when they first announced Kotlin that its integration with IntelliJ would be top priority. Groovy and Scala never had this improvement.

The rise-and-fall adoption of Scala and Apache Groovy is because their whole rationale for existing was to be a better something. Groovy (2003) tried to be a better Beanshell (1998) by adding closures to it. Beanshell tried to be a better Java (1995) by adding dynamic typing to it. Scala (2003) tried to be a better Java by adding definable operators to it. But when something even better comes along, their rationale for existing disappears. They will try to catch up by adding features later (e.g. Groovy 2's inferred typing to compete with Scala, or its more recent macros to compete with Clojure) but by then the newer language has made a foothold, and it's too late.

Apache Groovy really improved on Beanshell (by adding closures, in 2003), which is what improved on Java (by adding dynamic typing, in late 1990's).

As the author says:

> because the parser generator knows about all patterns you want to match in advance, it will match longer terminals before shorter—more ambiguous—terminals

If you don't mind manually ordering your choices in your alt operators, then PEG and parser combinators are OK.

Oh, and you often need to restructure your grammar to avoid left recursion.

> there are no obvious improvements to learning tools that will address the fundamental problem: you need to talk to actual humans

When learning to speak and listen, you need to already understand perhaps 80% of what actual humans are speaking in order to learn the other 20% you don't already understand. If you speak to someone and only understand say 30% of what they're speaking and they you, you won't pick up any of the 70% you don't understand, assuming the native speaker even wants to continue talking to you. Interactive software tools must deduce what vocab and grammar you can already understand and speak only that plus the 10% extra it wants you to practise and reinforce. And those tools don't exist. Good language teachers who can do the same are expensive.

Reading materials are far better in this regard, but even there, most of them use a specific learning sequence as defined by national language testing and don't cater for most learners who learnt haphazardly and thus whose current knowledge is scattered all over that continuum.

You can use the YAML-like declarative syntax [1] instead to configure the pipelines for 90% of what you do, and just use Apache Groovy for the more complex logic, or interfacing with plugins.

[1] https://jenkins.io/doc/book/pipeline/syntax/

The Java methods with up to 70 arguments are highlighted. This code defines methods with up to 250 arguments. I wonder why the Apache Groovy people didn't choose a number like 256, which is more compatible with other magic numbers in the JVM.

> As soon as it was possible for other languages to run on the JVM, the huge amount of developers working around JVM [...] started looking at alternatives

This is true, but...

> Groovy, Scala and Clojure were the early contenders that people were exploring

... Jython and BeanShell were much earlier than those three.

Jython, JRuby, Rhino, and Clojure are JVM languages that are syntactic copies of existing non-JVM languages, and it seems JVM developers didn't want these. Clojure has won within that group.

But the other group is what developers really wanted, i.e. languages with a Java-like syntax but with extra features added. Beanshell came first with dynamic typing. Then Apache Groovy cloned Beanshell and added closures, and Beanshell never kept up. Scala had all that but also had inferred static typing, which Groovy later added but was too late to the game to have much impact. Kotlin then came and merged the best features of Scala and Groovy, and became successful on Android.

> there is essentially fully programmable type configurations like Jenkins Pipeline Groovy `Jenkinsfile`, which can be a nightmare, too. I think it is tough to find a sweet spot between making it configurable and expressive for users while retaining a low barrier of entry and not turning the configuration into a complete program itself.

Nowadays, Jenkins pipelines can be configured in either the Jenkins-provided "Declarative Syntax" [1] or the Apache Groovy-based "Scripted Syntax", with the Declarative Syntax used as the default for examples on the Jenkins website. I guess they've found the best way to not have users turn the configuration into a complete program is to provide declarative syntax only in the default option. It's good to see Kustomize is built with this in mind, too.

[1]: https://jenkins.io/doc/book/pipeline/syntax/

When Apache Groovy had dynamic types only, it was marketed as a complement to Java, but when Groovy 2 came along with static typing added, its backers started pitching it as a replacement for Java, even targeting Android. This endeavor was ultimately unsuccessful, though, and the programmer who wrote the static typing enhancements recently pulled out of Groovy's project management group at Apache. Groovy doesn't run on Android anywhere I know of, and converting large swaths of dynamic code to static using @CompileStatic doesn't work -- you need to repeatedly compile the code and add manual type conversions all over the place until it all runs OK.

Best use Groovy for dynamically typed scripty stuff only, and a JVM language built with static typing from the ground up for building the actual systems, such as Java, Scala, or Kotlin.

Counting French and Germans as a single population group doesn't really make sense, since their languages are far more different than, say, the different flavors of Bengali spoken in Bangladesh and the Indian state of West Bengal. And of course the French government's childcare policies are quite different to Germany's. France is also more liberal than Germany in granting citizenship to those of other ethnic groups.

If the EU is one country, then why not India/Bangladesh, whose combined population overtook China's in 2008 ?

Most interesting to me is Japan's projected population of 85 million in 2100, compared to 125 million today.

> you can do whatever feels right for a given case

Too bad you can't use whatever specification language feels right. Spock only provides Apache Groovy, with its tacky syntax hacks like long strings for function names, block labels having special meanings based on their name, or the OR and LOR operators being used for drawing tables in the code. In the past when software has provided Groovy for writing specs, they eventually provide an alternative when Groovy's shortfalls become obvious, e.g. Kotlin for Gradle [1], or the Declarative Pipeline Syntax [2] for Jenkins.

[1]: https://docs.gradle.org/5.0/userguide/kotlin_dsl.html

[2]: https://jenkins.io/blog/2016/12/19/declarative-pipeline-beta

> Why would you want to figure out the dependencies without executing script?

Originally, the whole point of using configuration files for builds was to eliminate the programmatic element where you used lots of little scripts to run builds. Config files are easy to read and reason about.

> Programmatic configuration allows e.g. specify some library version once (e.g. springVersion) and use it for 10 dependencies as a variable

Declarative syntax can also include variables which can't be reassigned to later.

Gradle's original marketing message was based around its syntax, i.e. Apache Groovy being easier to read than XML, which is true. But providing the programmatic ability of Groovy as well is a step backwards for configuration best practice, ultimately resulting in an increase in technical debt. Thankfully, almost all the Gradle build scripts out there are simple 20-liners which don't use programmatic logic.

Gradle ought to follow the example of Jenkins pipelines, which later provided a Declarative Syntax as an alternative to Groovy to mitigate this very issue.

> So I don't have to worry about Groovy dying off (which is not to say it is)

Apache Groovy is dying off. Whenever some software product bundles it as a built-in scripting language, after a short time Groovy's snags become apparent and that software starts bundling another scripting solution, e.g. Kotlin for build scripts in Gradle [1], or the Declarative Pipeline Syntax for Jenkins [2].

[1] https://docs.gradle.org/5.0/userguide/kotlin_dsl.html

[2] https://jenkins.io/blog/2016/12/19/declarative-pipeline-beta...

> all the interesting keywords are already very popular method names for other forms of pattern matching

When I first read that, I thought he meant run-time lookups of overloaded method names, which is a form of pattern matching on parameter lists.

The underscore is fairly pleasant to read:

  [1,2,3].map{_*2}

I think that's what Scala has. For multi-args, perhaps:

  [1,2,3].reduce{_1+=_2}

> Absolutely! There's a big 4.0 release happening soon

Virtually no-one's updated from Grails version 2 to version 3, or released any plugins for version 3, so it's hard to believe anyone's interested in a 4.0 release.

> restaurant owners lower prices on the app because app orders are more convenient to them

They also cook app-ordered meals quicker, and make in-store diners wait until there's no pending app-ordered ones to cook.