[catnaroek]

> Unfortunately for the author, there is a chicken and egg problem here. Few programmers understand the sophisticated type system required for the reasoning solution, or can understand the weird errors that the type system can give you to say why it won't let you do something stupid. So developers shy away from languages that provide such types. Therefore there is little demand for languages that provide it.

Somehow Haskell and OCaml programmers manage to get by! OCaml has proper variance management built into the core language. Similarly, GHC Haskell with Rank2Types (or anything subsuming it) enabled, this is what lets you say things like “every Lens is a Traversal”: Lens (resp. Traversal) has a Functor (resp. Applicative) constraint in contravariant position in what's otherwise the same type, and Applicative is a subclass of Functor, so Lens is a subtype of Traversal.

The notions of covariance and contravariance are too natural and useful to get rid of them. If your type system doesn't have them, people will work around it to express as much variance as they needed. Except the workarounds will be clumsy, ad-hoc and most likely incorrect.

[btilly]

Most programmers shy away from Haskell and OCaml. :-P

Seriously, the average programmer trying to learn Haskell starts with wanting to print "Hello, world", eventually winds up at a tutorial about monads, then retires with their head spinning. Haskell remains on the, "I should learn that some day" bucket list and remains unlearned.

This is not to say that you don't have plenty who don't learn them. But now we have another problem. One of the biggest reasons to use a language is available libraries. Because of the initial barriers to entry for these more sophisticated languages, there is a smaller pool of people writing useful libraries. Which means in the real world that when you want to get something done, you'll be more likely to find what you need pre-written if you use a more mainstream language.

Just to get a sense, in the (admittedly highly flawed) TIOBE index, the top language with a strong inference system is Scala, and the next is F#, then Haskell, and nothing else is in the top 50. The sum of popularities for these three would tie with Groovy at #18.

I have never written anything more than a toy program in any of these languages. I doubt I ever will.

[vorg]

> The sum of popularities for these three would tie with Groovy at #18

You said "highly flawed TIOBE index". Look at http://www.tiobe.com/tiobe_index?page=Groovy and notice the sudden jump from 0.33% in Nov 2015 to 1.2% a month later. I would say grossly unbelievable, even massively fabricated. I suspect Groovy's backers pulled off this trick by having "Gradle DSL" added to their Groovy keyword list, but with the announcement that Gradle are adding Kotlin to their supported DSL languages, Groovy's top 20 listing won't last.

[kbenson]

Unfortunately, I think this speaks more towards the failing humans have towards assessing risk in complex systems. The cheaper to learn (considering time and effort required) languages that provide less safeguards routinely get far more new users over time. These languages can be useful in their ease of use (hey, I'm a Perl programmer, so I can't knock them entirely), but they have a far wider share of the market than I think is warranted.

[btilly]

ahem

PHP

[kbenson]

Indeed.[1]

There's definitely a trade-off between on-boarding new programmers and teaching good software engineering practices. I think that programming language mind-share is so overvalued at this point that to some degree we are shooting ourselves in the foot. There's some point at which the number of new users you can get based on how easy your language is to learn and the average quality of the software produced in that language are at an equilibrium[2], and I think we've seen a few languages which have blown straight past that equilibrium.

1: As I suspect most Perl programmers feel when they've had to spend time writing PHP, the event can be infuriating. Here's a language that purported to take a lot of ideas from Perl, and all you can conclude is they took all the wrong things.

2: Obviously affected by other language traits as well. I think Python keeps a higher average of quality than you would think likely though strict dogmatism, so that works well for them, even if it doesn't attract me.