Why Perl Didn't Win

The same arguments can be said about Perl.

An expressive language is good to work in, because reading 1 line of code instead of 100 is always better for readability and also verbosity is a cause of accidental bugs - one line of code that does the same work as 100 lines is much less probable to contain accidental bugs. Plus, the closer you have code that precisely models the business logic, the more readable it is (assuming that we aren't talking about a retarded, badly designed, non-composable DSL).

However Perl is a heavy language that also lacks common means for abstractions that people do use in Perl, like OOP. Therefore, not only are we speaking about a heavy language, but one in which you get a dozen libraries for doing things like OOP, all of them slightly incompatible with each other. Of course, Moose came along, but Moose was late (i.e. the damage was already done) and I'd argue that Moose is also overly complex. This goes over the principles outlined by Guy Steele in his "Growing a Language" presentation - either a language is very simple, with a core set of orthogonal and powerful features that allows you to build whatever you want on top (i.e. Scheme), or it's a more complex language that provides everything you need. Perl is neither of those. So one can argue that Perl is badly designed.

So you could say that Perl tainted the idea of using expressive languages, just like Java tainted the idea of using simple languages. And actually "simple" in this context is incorrect, because there's nothing simple about Java's flavor of OOP, it's just that people are familiar with Java's blend of OOP, but familiarity is not necessarily about simplicity. But I digress.

And it's a pity. For example right now my favorite is Scala. In my opinion Scala's expressivity is very different from Perl's expressivity, in that Scala's constructs are necessary and almost orthogonal and usually properly used and the abstractions are well defined. I also programmed in Perl and after 2 years of doing it I would still have problems reading code from other people, whereas this never happens to me in Scala and even if that would be the case, I have an IDE to help me out. And in my experience of training rookies to work with Scala, it's not the syntax that's problematic, but rather the design patterns and abstractions used and that have been imported from Haskell and hence are foreign to many developers. Yet in spite of this, I've seen many superficial opinions floating on the web that a language like Scala is too complicated and then when you ask those people why, it turns out that in most cases we are talking about misconceptions and unjustified fear coming from a superficial understanding of a language.

Going back to Go, the problem with Go it that it lacks the means for abstraction that I'm looking for. Go lacks generics for example, which means that building abstractions that involve higher-order functions is not feasible. And I'm sure that Go will get generics at some point, since it is inevitable, however Go is not the type of language to ever implement higher-kinded types and type-classes. I personally need type-classes, being a very different means for ad-hoc polymorphism, when compared with OOP, with different use-cases.

For example I want to work with monads or applicative functors, which in spite of their scary reputation, are just design patterns that aren't very hard to understand, their reputation being a direct consequence of them being explained by Haskell developers with a mathematical mindset. And I want to build generic functions that work over monads or applicative functors, because once you discover their power, it's very hard to go back and life is too short to reinvent the wheel every single time. And Go is not the kind of language that will ever appeal to my needs, whereas languages like Scala, Clojure and arguably Rust are such languages.

But here's the real problem that I'm seeing - scaling a software development team is done in two ways ... you either hire more people, or you hire really good people that can produce better abstractions. This is horizontal scalability versus vertical scalability. And the problem is, in a software development company, these 2 approaches are incompatible. The companies that want to scale horizontally are exactly the companies that prefer familiar languages, whereas the companies for which that isn't feasible (i.e. startups) are the companies that prefer powerful languages.

And of course, you would think that it's better to scale horizontally, depending on the problems solved, but therein lies another problem - the difference between really good people that can juggle with abstractions and juniors is not necessarily one of productivity, but rather in the range of problems they can solve. Given enough difficulty, you can hire how many juniors you want and they might still not be able to solve certain problems, whereas those same problems might be feasible for 2-3 people that are really good. Amdahl's law is also very relevant to software development. The more people you have, the more you introduce concurrency and points of synchronization, which in turn kills the parallelization possible and thus productivity.

What I'm talking about is the software crisis problem, which is still very relevant. And my personal bet is on vertical scalability, which implies working with better tools and abstractions. Because that's how we scaled math and that's how we went beyond the pyramids.

> Python 3 broke backwards compatibility

While this is true, it's possible to write a script that will run on both Python2 and Python3, so long as you have that goal in mind. The breaking of backwards compatibility is the breaking of several APIs and assumptions.

> to my knowledge everybody is still using Python 2

This is mostly because the release of Python 3 didn't see everyone stop everything and immediately start coding in Python 3. Conversion has to bubble up from the major libraries (e.g. Django, Flask, SciPy, etc) first, before people are able to convert.

Also, switching the default Python on Linux distros takes time because you have to go through all of the packages in the package manager looking for Python scripts and make sure that anything pointed at /usr/bin/python will work with Python 3[1].

Another point is that a number of libraries delayed conversion, and didn't consider Python3 to be "stable" until around Python 3.3. Some of other libraries (cough Flask cough) delayed support for a long time because the maintainer just didn't like Python 3.

[1] I know that these aren't always working well though. A while back I found out that Comix (installed via Ubuntu) had "/usr/bin/env python" in the shebang line instead. Launching it from a Virtualenv that doesn't have PyGTK doesn't work so well... :P

I'm not sure by which measure you are determining that COBOL failed epically. I think the likelihood of Java, to say nothing of golang, having the presence COBOL has 50 years after its creation is essentially zero.

COBOL failed epically at its goal of making programming easy for everybody by creating an "English"-esque syntax that everybody could understand. It failed so epically that it has apparently destroyed the idea so thoroughly that you don't remember/realize that it was a first-class goal of the language.

If you go back and read what I said, notice that nobody could sensibly call Java a generalized "failure" either. It specifically failed to create a language that would be something that could be used by large groups of people easily, and to the extent it succeeded it did so with incredibly grit, perseverance, and tons of third-party tools and terribly abortive efforts over the years, and it also did it so badly that people entirely stopped talking about even trying it. This despite the fact that "how do we write programs in companies with hundreds of programmers working on tons of discrete projects" is by any measure a very large use case for programming languages, and that only Go is directly addressing this use case directly is in some sense a travesty. (Others address it indirectly, by claiming that their features that are really intended for code safety or power may also as a side effect have the ability to make big programming teams function well, if they even claim that.)

I just wanted to say I agree to everything you just said. I don't feel like I've heard this viewpoint expressed better before.