1. 19
  1.  

  2. 7

    PHP being more popular than Perl is not hard to explain: PHP had properties that made it easy to host a large amount of it (especially by being an Apache Mod and being written for web pages specficially), so a lot of hosts did that. Perl, on the other hand, is no where nearly as designed for HTML output as PHP.

    Python vs Ruby is a bit harder, but I’d say it’s mostly down to Python having a reputation for being “Easy”, where Ruby can be easy, but is known more for being part of a counter culture. Python tends to be like Pop, where Ruby is either Jazz or Punk (if you’d excuse the mixed metaphors). Of course, both Ruby and Python expose rather large amounts of complexity as you start writing larger programs.

    1. 11

      IIRC Python, with some weird backing from Google, ended up as the de-facto teaching language. I think that’s what is responsible for its comparative popularity. Now the same thing is happening/has happened with Go.

      I think a lot of people are ignorant about the role evangelism plays in shaping language ecosystems.

      1. 2

        Indeed, evangelism definitely plays a large role in how popular languages end up. Thanks for pointing that out.

      2. 5

        PHP was also much easier to get into for beginners. I still remember not knowing what I was doing at all, and successfully programming something in PHP. All it took is some persistence a lot of F5-reloads. This instant feedback property is so valuable to beginners.

        1. 3

          Python vs Ruby is a bit harder, but I’d say it’s mostly down to Python having a reputation for being “Easy”, where Ruby can be easy, but is known more for being part of a counter culture.

          I started with Perl (doing apps with HTML::Template, mod_perl and the likes) then moved to Ruby on Rails during its hype (I did learn Ruby proper, outside of rails though). What got me moving from Ruby to Python was essentially the standard library and I think many people went a similar path. It was just easy to get stuff running and all the modules seemed good quality and worked out of the box. I still prefer Ruby over Python (but that is mostly because I like Smalltalk and Ruby draws much more from it) but back then it was simply more pragmatic to reach out for python when doing anything except a Rails web app. I think this xkdc pretty much nailed it: https://xkcd.com/353/

          1. 3

            Python vs Ruby is a bit harder, but I’d say it’s mostly down to Python having a reputation for being “Easy”, where Ruby can be easy, but is known more for being part of a counter culture. Python tends to be like Pop, where Ruby is either Jazz or Punk (if you’d excuse the mixed metaphors). Of course, both Ruby and Python expose rather large amounts of complexity as you start writing larger programs.

            Ruby was driven by the popularity of rails, and I’d argue Python was driven by scientific computing. Python only really went stratospheric this decade with the rise of data science and ML.

            1. 3

              Python was driven by scientific computing.

              Was this historically true though? Clearly, today’s popularity of Python is due to the fact that everyone uses ML for everything. But I would think that the niche of scientific computing was much smaller when Python already was more popular than Ruby?

              1. 2

                I think you’re right. Python was a successful back-end web language back when “data science” was just statistics and scientific computing had never heard of (and couldn’t afford) these newfangled “high-level” “scripting” languages. On the other hand, the numpy/scipy stack has been around quite a while. I think it’s more like Python was already prevalent in education as ML was starting to expand, had decent ergonomics, and the ecosystem was fairly robust due to (web-driven) industry adoption.

                1. 1

                  I would even bend this to my theory: the reason why Python won ML is numpy, and the reason why Python has numpy is a runtime which can easily be extended with native modules.

                  The fact that Python exposes the guts of the interpreter is oft cited as drawback (“that’s why every implementation converges to CPython design”), but it also is an explanation of the popularity.

                  1. 3

                    I agree NumPy is Python’s strategic advantage, but I disagree it has anything to do with CPython runtime. NumPy is mostly historic accident: it took three tries to get right (Numeric, Numarray, and then NumPy), and it basically burned out two extraordinary programmers (Jim Hugunin and Travis Oliphant).

                    In other words, I agree with “runtime matters” theory, but “runtime that matters” credit goes to NumPy itself, not CPython.

                    1. 1

                      Oh, interesting! Do you have some link to read about the history of NumPy by any chance?

                      1. 3

                        Travis Oliphant published a book titled “Guide to NumPy”. Its first chapter is titled “Origins of NumPy” and is probably the most definite account. It should be easy to find but I don’t think it’s appropriate to link to the web version of the published book.

                2. 1

                  I certainly used Python much more than Ruby before ML became a thing. These days though, I don’t use a lot of either.

            2. 4

              PHP won, because:

              • mod_php for Apache (everything else was a pain to install),
              • “just ftp a file” deployment method (no init files to set up, no need to restart anything)
              • stateless runtime. It was “serverless” before it was cool. It limited memory leaks and damage bad scripts can do. It allowed one server with one runtime to serve many different projects.

              These properties together created ubiquitous cheap shared PHP hosting, which in turn made PHP projects safe to write.

              1. 3

                I would be curious how the author explains the differences in popularities of languages that use the same runtime, e.g. Clojure vs. Scala vs. Kotlin

                1. 2

                  Scala and Kotlin are pretty close together. Clojure uses the runtime in a very different way which not a lot of people asked for.

                  1. 2

                    Theory prediction is that generally the original language would dominate, unless the alternative differentiates in terms of runtime.

                    The biggest counterexample here would be C++.

                  2. 1

                    Fourth, I predict that Nim, Crystal and Zig (which is very interesting, language design wise) would not become popular.

                    Would love a deeper explanation of this.

                    1. 9

                      I can’t speak for the author, but I’ve looked into all three of those languages, and came to more or less the the same conclusion. In some sense, they’re not doing anything that can’t already be done with more popular languages that people already know.

                      Nim, for example, is similar to Python but compiles to efficient machine code. If it were invented 20 years ago, then maybe it would have won out, but nowadays Python that needs to be fast just calls out to C, and everybody is used to doing that, and there are pre-built libraries like numpy. Most of the time vanilla Python is “fast enough” in any case.

                      Crystal is similar, but replace Python with Ruby.

                      Zig seems to be competing with Rust and Go and then also against C and C++, and runs into the same problems. Contrary to what people online like to claim, modern C++ isn’t the buffer overflow, null-pointer, morass that it’s made out to be, and there are a bunch of static and dynamic analysis tools for finding and fixing the problems that do exists. It’s a lot easier to use Valgrind and Coverity than it is to move to an entirely new, unproven language ecosystem.

                      Basically, they’re not solving any really big problems.

                      And just to be clear, I’m not saying they’re not good languages, or that people shouldn’t use them, or that anything is wrong with them, or they’re better or worse than any other language. But they’re not so much better that people will rush out and drop what they’re familiar with to use them.

                      1. 2

                        Basically, they’re not solving any really big problems.

                        What do you think those are? Seems to me that the current problems are mostly outside of PL technology. Management, culture, psychology. Getting teams and individuals to work as efficiently as possible while maintaining maximum happiness.

                        Zig seems to be competing with Rust and Go and then also against C and C++, and runs into the same problems. Contrary to what people online like to claim, modern C++ isn’t the buffer overflow, null-pointer, morass that it’s made out to be, and there are a bunch of static and dynamic analysis tools for finding and fixing the problems that do exists. It’s a lot easier to use Valgrind and Coverity than it is to move to an entirely new, unproven language ecosystem.

                        Somehow Rust seems to be doing well, nevertheless. Admittedly, it has had significant PR effort behind it.

                        1. 3

                          Somehow Rust seems to be doing well, nevertheless. Admittedly, it has had significant PR effort behind it.

                          It also has sans-gc memory safety, which differentiates it from other languages in terms of runtimes. I can’t think of a way to tease apart “it’s runtime” vs “it’s PR” though, this is the same situation as with Java.

                          Did we ever have languages which were heavily marketed, but didn’t go anywhere?

                          1. 1

                            Did we ever have languages which were heavily marketed, but didn’t go anywhere?

                            Depends on what you mean by “didn’t go anywhere”, but Dart comes to mind. Haskell might be another one. Jane Street did some PR around O’Caml, and that hasn’t gone too far. And, in contradiction to what I’ve said before, Rust hasn’t gone too far really outside of some sort of a bubble, perhaps?

                          2. 3

                            What do you think those are?

                            In the case of Zig/Rust/Go vs C++ it’s an inconvenience - one more stage in the Jenkins pipeline, or even in the local build, to run Coverity.

                            Like you said, the biggest problems lately aren’t related to programming language, so moving a project to a new language is a big headache for a little gain. These languages are great for new projects to cut down on overhead, but most developers spend their time doing maintenance and feature development on existing projects.

                          3. 2

                            Eh, Nim’s similarity to python is seems mostly at the superficial level. For one, Nim uses a lot more metaprogramming (to the point of probably edging a lot closer to Ruby when a lot of DSLs get involved, especially with something like Karax). For two, Nim has a static type system, has had one from the start, and is a lot more likely to use first class functions.

                            To be honest, I think Nim owes a lot more to Pascal and Ada.

                            I don’t see it becoming massively popular a la C or Java, but it’s definitely got a big edge on both Python and Go from a strictly language standpoint, IMO.

                            1. 2

                              I suspect you’re probably right, although it breaks my heart. Superior technology never wins out on the mere basis of its technical superiority. On the other hand, if somebody were to double down on one of these and produce the sort of killer app that drives adoption (like Rails or Numpy or something) then the tides could turn.

                            2. 2

                              Well he’s saying that they don’t have interesting runtimes. C has the Unix kernel, C++ is an upgrade from C; JavaScript had the browser, etc. Emacs Lisp has Emacs, etc.

                              I agree with the general argument, but I don’t necessarily agree with the specifics. The reasoning about Rust and Julia seems pretty light, i.e. not that substantive. I could just as easily see some analogous reasoning for Zig, etc.

                            3. 1

                              Fifth, I predict that Swift will be pretty popular on Apple hardware due to platform exclusivity, but won’t grow much outside of it, despite being very innovative in language design (generics in Swift are the opposite of the generics in Go).

                              (If you’re not familiar, I’ll describe Swift as having Rust’s type system, ARC for reference semantic classes, value semantic structs / enums, rich generics, functional style inclinations, high performance, high safety, no borrow checker, no garbage collection.)

                              The Swift team wants their language, which is so far excellent for its high-level uses, to grow and travel down the tech stack until it’s suitable for the same system-level cases as Rust. I have no doubt they’ll accomplish that. But from that basis they want Swift to be accepted as the next great general-purpose language. Their challenge is to reach people Apple hasn’t usually bothered to reach, who dismiss their work due to different values.

                              1. 3

                                If they want swift to be popular outside of iOS and other apple platforms, they need to put their money where their mouth is. First, a lot of marketing/PR is needed to tell people that swift cares about other platforms. Then, they need to make sure that the ecosystem isn’t locked to some proprietary (cough cocoa cough) APIs, because that means other platforms are second class.

                                For me, as a user of OCaml and rust, swift seems somewhat interesting, but it’s unclear when I look at the website if it’s even officially supported on my OS (archlinux; it’s on AUR but not a proper package). Is there a package manager, a LSP server, a set of posix utils, networking primitives that would work here; what are the stability guarantees? Swift seems to have broken compatibility a lot in its past, how do I know it won’t do it again 3 or 4 times?

                                1. 2

                                  Agreed about the publicity for sure.

                                  Swift isn’t locked to Cocoa APIs. The Cocoa APIs call the Swift standard library, not the other way around, and they’re not needed to write Swift code and ship it. While it’s true that the first party Objective-C frameworks aren’t published outside Apple platforms, those that aren’t functionally Apple OS-specific are being reimplemented with the open source community in pure Swift for portability.

                                  Linux distro support is limited so far. The last update about that was a blog post which expanded beyond Ubuntu to add a couple more, and Windows. No Arch yet to my knowledge. I’m looking for Alpine, personally, but it’s got to go everywhere before people really take it seriously.

                                  There is a package manager, SPM. I don’t think we really love it yet, but it’s picking up speed.

                                  LSP support is there; I’m not sure if it’s super mature yet?

                                  Regarding POSIX utilities, Swift can directly import and call C libraries. This was necessary to replace Objective-C which has the same capability. Swift has native C type aliasing, bounded unsafe memory access, and other facilities to make this feasible.

                                  Networking primitives are underway; look at SwiftNIO. This, and the package manager, are part of Swift’s current goal of making headway into the server application space. That’s viewed as a milestone on the way to systems level code.

                                  For stability guarantees, there was a lot of flux especially in Swift 2 to 3, but it’s source code stable since Swift 4 and ABI stable since Swift 5. Those types of breaking changes are over, and when they happened, Apple provided automated source code migration help.

                                  One thing I’m not sure about is whether Apple’s product-oriented structure is interested in these growth goals, or if the goals are really just those of the language team. We hear these kinds of statements from the devs on stage at WWDC sessions, so it does look officially backed, but time will tell. If they are not really that unified, then Apple’s lackluster reputation in the open source community could really get in the way.

                                  1. 2

                                    Thanks for the very detailed answer. It sounds like it’ll take at least a few years before it’s there in a robust and stable enough fashion (package manager and foundation libraries), but then it does look promising.

                                    1. 2

                                      You’re very welcome.

                                      One thing I’ll correct about what I wrote: it’s not a matter of whether the standard library calls Cocoa or vice versa. Swift apps for Apple platforms usually call Cocoa APIs, the Swift standard library, and a few third party dependencies built in Swift, Objective-C, or sometimes plain C. For Apple platform targets, the compiler is rich enough to provide smooth bindings from Swift to Objective-C especially in the basic types like strings and dates, the error throwing mechanism, and so on. In that sense there is a tight relationship between Cocoa’s Foundation framework and the Swift standard library. However, it’s all optional, and on both Apple platforms and Linux you can build a Swift only, or Swift and C, command line tool.

                                      Foundation is one of the frameworks that is being ported to plain Swift for use outside Apple-land. What’s not offered in Linux is, basically, all of Objective-C and the nice bindings to it. And honestly the only reason we have that on Apple platforms is because it would be impossible to migrate off of Objective-C without it.

                                      Something I do want to see offered on other platforms is SwiftUI. That’s one of the first Swift system frameworks offered from Apple, which is only possible now because of ABI stability. (Open sourcing it is an alternative, but we’re all unsurprised that Apple likes their competitive advantages.)