5 ms·

Tangential question: how come "modern" languages (like Go, first release 2009) seem to ignore basic PL Theory, that you learn in the first chapters of any suita

by dgan 3y ago

Tangential question: how come "modern" languages (like Go, first release 2009) seem to ignore basic PL Theory, that you learn in the first chapters of any suitable book (see Pierce, "Types and Programming Languges", 2002) ? I am specifically talking about how the seem to have forgotten (omitted?) parametric polymorphism, the absence of sum types, presence of "nil", lack of type inference?

vsnf 3y ago
For the most part, they don't. This is a Go specific problem, which was created with a very explicit anti-intellectualist stance and threw out 40 years of PL theory and practical research.
- calini 3y ago
  Yet somehow it's one of the most productive and successful languages to have appeared in the last 20 years.
  - Capricorn2481 3y ago
    That sounds anecdotal. There's not really evidence of it being more productive than anything else
  - codr7 3y ago
    I don't find it weird at all that simpler languages are more popular/successful. They're easier to pick up and support the idea of plug and play programmers that is very popular among managers. Productive as a consequence of the above, maybe; in that more code is written in Go; but certainly not as a quality of the language. And there's numbness and denial involved. I've been writing Go full time for about a year now at work. Every time I use another language I'm reminded of how much time and energy I'm wasting.
    - mbernstein 3y ago
      It's not even that it's popular among managers to move people around all the time. That's an awful framework for getting great work done. People change jobs and you need to choose a language you can either easily hire for or train someone up in. Go fits the second requirement very well, and as more people learn it, starts hitting on the first. I introduced Go at two different companies to great success not because it's my favorite language (I would much prefer Rust, Haskell, Clojure, etc) but in reality, in my role as a leader of a tech org, hiring smart people and getting giving them the means to be productive as soon as possible for however long they want to work with us is key.
      - louthy 3y ago
        Is being productive immediately better than a constant loss of productivity due to manual boilerplate writing? It seems to me to be the wrong trade
        mbernstein 3y ago
        Depends on a number of factors. I think GitHub copilot is reducing that trade off a bit more. If the average dev stays somewhere for 2.5 years (our average is quite a bit higher because I tend to think we’re good place to work) - how long are you willing to invest in them learning the new tech (and on top of the, business logic/etc)? The lower the investment number the less you’re willing to dive into rust sans specific technical reasons (which go and elixir would easily meet). Separately, I don’t buy the notion that a language that has a bit more boilerplate is less productive than one with virtually none.
        codr7 3y ago
        This is all from a managers perspective, which I suspect is the main reason we disagree. From a coders perspective, using sub-optimal tools and churning out boilerplate day in and day out makes the difference between keeping a job and looking elsewhere. Which turns it into a managers problem, because if your developers are not happy, you won't be either in the long run.
  - JackMorgan 3y ago
    I would argue that title belongs to Typescript. Every client I talk to wants help getting started with it.
    - bigfishrunning 3y ago
      If the clients need that much help getting started, is it really that productive?
      - JackMorgan 3y ago
        One would think it is a false equivalency to compare the initial installation and training efforts with the eventual, enduring gains in productivity.
  - pjmlp 3y ago
    Productive, beauty is in the eye of the beholder. JavaScript, PHP and C are also widely successful, despite their design flaws. Technical excellence doesn't driver adoption, unfortunely.
    - jstimpfle 3y ago
      Seems like they weren't bad enough to prevent success, plus what were the alternatives? In Javascript's case, maybe Python since it has quite a similar runtime model. But was Python of fhe 2000's really better suited than Javascript at the time? And hasn't Javascript caught up considerably? Same for PHP?
      - pjmlp 3y ago
        The alternatives never had an opportunity, given that free beer OS with source code (C), only implementatation available (JavaScript), only language available on cheap ISP hosting without additional infrastructure costs (PHP), closed the door to them.
        jstimpfle 3y ago
        Plenty of opportunities. The alternatives could just have created a mod_php equivalent. I can't imagine ISPs "closing the doors" to newcomer languages, the market should have been competitive enough to allow for penetration. The thing is that productivity of a language depends on many factors, including many softer ones that are typically forgotten or discounted by language geeks. It also depends on the target audience. In some important ways, PHP was/is brilliant. A technically brilliant language should be able to recognize the adoption driver mechanisms and build the necessary infrastructure. The point of a language is not (only) to build a theoretically sound framework, but to be an ergonomic vehicle for expression of ideas.
sesm 3y ago
I've heard the following explanation: Go was designed for internal use at Google, and one of the primary goals was to reduce compilation time for huge codebases (the size of Google monorepo). For such amount of code even `javac` was too slow for them. To solve this problem, Go was designed to be compiled with 1-pass compiler (similar to Pascal and Modula-2) which makes features like generics and type inference very hard (if not impossible) to implement.
- louthy 3y ago
  If that’s true it’s insane that they didn’t try to solve the code explosion problem. Perhaps even a Google-specific DSL that captures their common patterns behind an abstract syntax. Creating a new general purpose language with such a limited feature set - that it’s likely to result in even more code - seems to be an odd solution.
- pjmlp 3y ago
  Except history shows otherwise, ISO Modula-2 common extensions (including generics), https://modula2.awiedemann.de/manual/comp3.html https://modula2.awiedemann.de/manual/comp3.html While using Go is certainly better than plain C, most of its design steams from the authors' bias.
- arc619 3y ago
  Interestingly, Delphi Pascal has a single pass compiler with generics, though I'm not sure about type inference. I was under the impression Go originally avoided generics more for a perceived abstract complexity for developers, the idea being they are hard to understand for new recruits.
kitd 3y ago
If a PL allows effective, "good enough" code to be written and maintained efficiently, but doesn't meet your definition of basic PL theory, who is at fault?
AnimalMuppet 3y ago
"In theory, there's no difference between theory and practice. In practice, there is." There's more to designing a useful language than is found in Pierce's book. The Go design team had some very specific things they were trying to do, and they did pretty well at doing them, and they produced a language that some people have found to be useful for writing some kinds of software. I'm going to guess that they had a lot more experience at actually writing software than Pierce did. So maybe you shouldn't automatically assume that Pierce is the final word, and that anyone who decides different has to be wrong.

by dgan 3y ago

vsnf 3y ago

For the most part, they don't. This is a Go specific problem, which was created with a very explicit anti-intellectualist stance and threw out 40 years of PL theory and practical research.

calini 3y ago
Yet somehow it's one of the most productive and successful languages to have appeared in the last 20 years.
- Capricorn2481 3y ago
  That sounds anecdotal. There's not really evidence of it being more productive than anything else
- codr7 3y ago
  I don't find it weird at all that simpler languages are more popular/successful. They're easier to pick up and support the idea of plug and play programmers that is very popular among managers. Productive as a consequence of the above, maybe; in that more code is written in Go; but certainly not as a quality of the language. And there's numbness and denial involved. I've been writing Go full time for about a year now at work. Every time I use another language I'm reminded of how much time and energy I'm wasting.
  - mbernstein 3y ago
    It's not even that it's popular among managers to move people around all the time. That's an awful framework for getting great work done. People change jobs and you need to choose a language you can either easily hire for or train someone up in. Go fits the second requirement very well, and as more people learn it, starts hitting on the first. I introduced Go at two different companies to great success not because it's my favorite language (I would much prefer Rust, Haskell, Clojure, etc) but in reality, in my role as a leader of a tech org, hiring smart people and getting giving them the means to be productive as soon as possible for however long they want to work with us is key.
    - louthy 3y ago
      Is being productive immediately better than a constant loss of productivity due to manual boilerplate writing? It seems to me to be the wrong trade
      - mbernstein 3y ago
        Depends on a number of factors. I think GitHub copilot is reducing that trade off a bit more. If the average dev stays somewhere for 2.5 years (our average is quite a bit higher because I tend to think we’re good place to work) - how long are you willing to invest in them learning the new tech (and on top of the, business logic/etc)? The lower the investment number the less you’re willing to dive into rust sans specific technical reasons (which go and elixir would easily meet). Separately, I don’t buy the notion that a language that has a bit more boilerplate is less productive than one with virtually none.
        codr7 3y ago
        This is all from a managers perspective, which I suspect is the main reason we disagree. From a coders perspective, using sub-optimal tools and churning out boilerplate day in and day out makes the difference between keeping a job and looking elsewhere. Which turns it into a managers problem, because if your developers are not happy, you won't be either in the long run.
- JackMorgan 3y ago
  I would argue that title belongs to Typescript. Every client I talk to wants help getting started with it.
  - bigfishrunning 3y ago
    If the clients need that much help getting started, is it really that productive?
    - JackMorgan 3y ago
      One would think it is a false equivalency to compare the initial installation and training efforts with the eventual, enduring gains in productivity.
- pjmlp 3y ago
  Productive, beauty is in the eye of the beholder. JavaScript, PHP and C are also widely successful, despite their design flaws. Technical excellence doesn't driver adoption, unfortunely.
  - jstimpfle 3y ago
    Seems like they weren't bad enough to prevent success, plus what were the alternatives? In Javascript's case, maybe Python since it has quite a similar runtime model. But was Python of fhe 2000's really better suited than Javascript at the time? And hasn't Javascript caught up considerably? Same for PHP?
    - pjmlp 3y ago
      The alternatives never had an opportunity, given that free beer OS with source code (C), only implementatation available (JavaScript), only language available on cheap ISP hosting without additional infrastructure costs (PHP), closed the door to them.
      - jstimpfle 3y ago
        Plenty of opportunities. The alternatives could just have created a mod_php equivalent. I can't imagine ISPs "closing the doors" to newcomer languages, the market should have been competitive enough to allow for penetration. The thing is that productivity of a language depends on many factors, including many softer ones that are typically forgotten or discounted by language geeks. It also depends on the target audience. In some important ways, PHP was/is brilliant. A technically brilliant language should be able to recognize the adoption driver mechanisms and build the necessary infrastructure. The point of a language is not (only) to build a theoretically sound framework, but to be an ergonomic vehicle for expression of ideas.

sesm 3y ago

I've heard the following explanation: Go was designed for internal use at Google, and one of the primary goals was to reduce compilation time for huge codebases (the size of Google monorepo). For such amount of code even `javac` was too slow for them. To solve this problem, Go was designed to be compiled with 1-pass compiler (similar to Pascal and Modula-2) which makes features like generics and type inference very hard (if not impossible) to implement.

louthy 3y ago
If that’s true it’s insane that they didn’t try to solve the code explosion problem. Perhaps even a Google-specific DSL that captures their common patterns behind an abstract syntax. Creating a new general purpose language with such a limited feature set - that it’s likely to result in even more code - seems to be an odd solution.
pjmlp 3y ago
Except history shows otherwise, ISO Modula-2 common extensions (including generics), https://modula2.awiedemann.de/manual/comp3.html https://modula2.awiedemann.de/manual/comp3.html While using Go is certainly better than plain C, most of its design steams from the authors' bias.
arc619 3y ago
Interestingly, Delphi Pascal has a single pass compiler with generics, though I'm not sure about type inference. I was under the impression Go originally avoided generics more for a perceived abstract complexity for developers, the idea being they are hard to understand for new recruits.

kitd 3y ago

If a PL allows effective, "good enough" code to be written and maintained efficiently, but doesn't meet your definition of basic PL theory, who is at fault?

AnimalMuppet 3y ago

"In theory, there's no difference between theory and practice. In practice, there is." There's more to designing a useful language than is found in Pierce's book. The Go design team had some very specific things they were trying to do, and they did pretty well at doing them, and they produced a language that some people have found to be useful for writing some kinds of software. I'm going to guess that they had a lot more experience at actually writing software than Pierce did. So maybe you shouldn't automatically assume that Pierce is the final word, and that anyone who decides different has to be wrong.