1. 6
  1.  

  2. 3

    Meh. The advantages some programming languages bring to the table are sometimes very significant. They don’t just make the problem “slightly easier”. It’s likely that Go is popular because it makes concurrent networking programs significantly easier to write, compared to most mainstream languages; similarly, using OCaml (or something similar) to write a compiler or symbolic program is a huge improvement over doing it in C.

    1. 3

      It’s not about the language per se and more about how many primitives the language integrates, and how well chosen those primitives are.

      C has no automatic memory management nor concurrency primitives, and Go has both.

      Among languages that use async/await-style concurrency, their concurrency expressiveness is largely similar.

      All the “P languages” form a family based on the set of primitives they’re built on, in which they’re very close to each other, and so programs written in them tend to be structured broadly similarly, despite significant differences in some of the design choices of the languages. Sometimes those differences have practical impact too, but rarely from a zoomed-out perspective on the code structure.

      So the answer to “which language should I learn?” is fairly irrelevant if it’s to be taken as “which P language should I learn?” but is rather more meaningful if it implies “should I use Go, Haskell or Prolog?”. (Although even then it’s just one topic among the many you need an understanding of, as the article says.)

      1. 1

        On the other hand, none of these languages have improved the ways people use their databases, write their queries, set their indices, deploy their servers, configure their networks, ….

        Programming languages bring a lot to the table, but they are not the core of dealing with computers anymore. It’s a huge chunk, but not as central as people make them to be.

        1. 2

          Though not Go or OCaml, all the tasks you describe benefit from declarative languages, like SQL and Prolog. (Or Greenspunned versions thereof)

          1. 2

            Sure, if you span the net wide enough, you could also call Elasticsearch query syntax (which is bascially the AST of a simple Lucene search program) a programming language. This isn’t practical though and not what people mean by “I’ll learn another programming language”.

            SQL is a perfect example of that: it is rather worthless to know without at least having a hunch on how your specific database executes it. Plus, each of the product comes with extensions.

            1. 2

              it is rather worthless to know without at least having a hunch on how your specific database executes it

              I feel this is deeply true of any programming language — it is mostly useless divorced from an implementation. I feel that knowing how to program in C is inseparable from knowing compiler extensions and intrinsics. And with the exception of (seemingly increasingly rare) languages defined by standards, one may not have any choice.

              One difference between logic languages and imperative languages, here, is that most programmers have already deeply internalized a mental model of how imperative languages are executed (which still often fails to match the actual implementation… note the way one still finds people making performance assumptions that held perfectly well on the ZX Spectrum and not in the modern era).

              Maybe we actually agree on something here: I think something the OP is successfully pointing out is that most people’s definition of “I’ll learn another programming language” is so shallow that it yields little compared to the effort they could put into learning other things. But, for example, I think learning something like Prolog (well enough to write production software: i.e., understanding at least one implementation well enough to reason accurately about performance and so on) is an exercise that yields knowledge transferable to plenty of other areas of programming; I suspect one can make this argument for any language and implementation that differs significantly from what one already knows.

            2. 2

              Like SQL and Prolog = Datalog. Seems like a good example where a new language can help with database queries.

              https://en.wikipedia.org/wiki/Datalog

        2. 2

          I mostly agree with this, except for the statement that all “non-trivial” programs need/benefit-from a database.

          The only programs I’ve ever worked on (personally, professionally or academically) which used databases were Web sites, when I used to be a Web dev. I’d claim that, as far as programs go, most of those sites were actually “trivial”, and the databases were just an over-complication (if I were choosing the tech stack, they’d be static sites).

          Then again, I tend to favour idempotent batch jobs rather than long-running programs with persistent internal state.

          Maybe such things count as “trivial”, but I’d say that’s a good thing (KISS). The author’s statement could be interpreted in a different way: if you make your solutions trivial enough, they don’t even need a database!

          1. 3

            the statement that all “non-trivial” programs need/benefit-from a database.

            Maybe author of the linked piece meant “systems” instead of “just” programs.

            I’d read “database” in this context as “data store”. Doesn’t have to be a RDBMS, can be a simpler key-value store like BerkeleyDB.

            1. 2

              Maybe author of the linked piece meant “systems” instead of “just” programs.

              True, but then again “there’s more to programming than building systems” :)

              We can get pretty far with Web scraping, “data processing” (e.g. images/video/music/email/etc.) and other interesting tasks with short-running programs reading data from existing files in normal formats, and writing output to the same. Even sophisticated interactive GUIs don’t need a “persistent data store” other than a normal file, if all the data they need is present in the file format. A paint program, for example, can be very non-trivial, but it can still make do with just an image file. It seems unhelpful to consider such files as “the paint program’s datastore”, because they’re inputs and outputs which aren’t specific to the program: my holiday photos would be there on my disk whether or not that paint program was ever made.

              We can even encroach somewhat into the “systems” world with something as simple as a cron job.

              Likewise for programming languages, which is one of my main interests: compilers can do just fine with env vars and filesystem paths, without needing to persist even a key/value database. There are lots of problems where the data is already being stored elsewhere, and the interesting thing is what we’re going to do with it :)

              1. 1

                We can argue back and forth for ages… I’d just like to conclude for my part, that a great feature of the image editing suite I use is unlimited edit history, which kinda sorta requires a data store.

                1. 1

                  In my comment I actually wrote that “persistent undo” is a great example of a useful, but (subjectively) non-essential feature of an image editor that using a data store would provide. I removed it before posting to prevent going off on too many tangents :)

                  Note that I’m not arguing againt the use of databases or data stores, they’re great pieces of tech which solve many problems. I just disagree with the author’s claim that they’re “essential for non-trivial programs”, which I think depends on the domain. Especially so if we have local filesystem access (not the case for Web apps, hence their widespread use of databases), and/or an API or scraper for someone else’s database-backed service :)

                  1. 2

                    We could probably have saved a lot of time if we’d just agreed (with the author of the linked piece) what “non-trivial” means :)

                    Personally I’d find the development of an IRC client, say, non-trivial, but that doesn’t require a database at all.