5 ms·

The "blub" thesis assumes that languages can be linearly graded on some, unspecified objective quality, which is a joke.

goto11 4y ago
The Blub-paradox is that everyone thinks those other languages are blub but their own favorite language is the non-blub pinnacle of creation.
- deleted 4y ago
  [deleted]
- deleted 4y ago
  [deleted]
- deleted 4y ago
  [deleted]
- a9h74j 4y ago
  That's the blub-paradox. There's also the excuse that one could have completed an assignment if they could have used blub language; this is the fizz-blub excuse.
- pdimitar 4y ago
  There are many programmers, myself included, that are under no illusions about the deficiencies of their own favorite languages. Most languages are Blub. Where we the programmers at large fail IMO is that we don't recognize that no language is universal. Some are good at X, others at Y, another group is only good for Z. But we all want to pretend that no no no, language A is perfect and you all are sheep for not seeing it and sticking to languages B, C and D.
  - kaba0 4y ago
    Is there really any language that is all that more productive for a given task? Libraries (somewhat including the standard lib as well) and experience aside, I don’t think one would finish a given task 2x faster in any other general purpose language, let alone more than that. (in agreement with Brook’s famous paper) So by extension, a single language with a huge ecosystem should suffice for any task.
    - goto11 4y ago
      If a given task can be solved in both assembler and Python, then surely Python would be more than 2x as productive, given a developer with experience in both. This is why assembler is only used for tasks which just cannot be solved in a high-level language. For most purposes Python would also be more than 2x as productive than C, again given a developer with experience in both.
      - kaba0 4y ago
        I meant high-level, managed languages. You wouldn’t get this 2x multiplier between Python and Java, JS, Haskell, etc.
        goto11 4y ago
        Probably not. At least any difference will be dwarfed by the effect of prior experience by developers and available libraries.
    - pdimitar 4y ago
      I code Rust, Elixir, Golang and shell scripts these days. Scrapped all other 5-6 languages that I also learned over my career. Elixir is not just 2x but very likely anywhere from 4x to 10x more productive. (I dislike PHP a lot but same can be said for it as well btw.) I got a REPL in which I can easily code 80%-100% of my workflow and test it in real time. After you recall REPL history a few times, copy paste in editor, run 1-2 more times to make sure it's still working and you're done (apart from unit tests). I love Rust a lot and apply it more and more but I haven't had anything I ever finished in 10-ish minutes like I did with Elixir. I do love the guarantees it brings however and I am making an active effort to become fast and efficient (thus productive) with it. Golang, as much as I dislike it in general -- because it doesn't go far enough with its static strong typing and people abuse its escape hatches way too much, effectively turning it into a dynamic language -- is a fairly productive language sitting somewhere between the above two. I am planning on partially replacing my shell script incantations with it. And finally, shell scripting I've used and abused hundreds of times and my failure rate there is extremely low. There has almost never been any task requiring stitching different other programs that I didn't manage to do with it. And productivity is super high. > in agreement with Brook’s famous paper Meh. There is a good amount of timeless computer science writings but this saying isn't one of them. Some of the advice from older masters is simply outdated; they postulated things with certain assumptions and a good chunk of them no longer hold true (famous example is "storage is super slow" which is longer a given, you have NVMe SSDs that are like 10x-20x slower than RAM). Which is fine, I appreciate and cherish their contributions. But we shouldn't get stuck in our ways and should periodically re-evaluate our foundations. > So by extension, a single language with a huge ecosystem should suffice for any task. Yes, as long as the language itself enables productivity and as long as the ecosystem isn't a humongous collection of half-done and abandoned two-week passion projects. And as long as the language itself isn't a half-done mess that's never going to get fixed due to obsession with backwards incompatibility even though transpilers exist and a good amount of companies don't have ancient mastodons to support (hint hint, all of the above applies to Javascript / Node.JS). IMO Golang and Rust do seem to satisfy your criteria. Maybe Java and C# as well (wouldn't know, I abandoned Java long ago). My favorite Elixir -- sadly less so because even though most of the common paths have been beaten / trodden, there are huge gaping holes at places. PHP and JS technically qualify although their ecosystems and the languages themselves are a huge mess. But I suppose "if you know what you're doing it's fine" (famous last words through which I made a lot of money fixing the messes of those "that know what they're doing").
DennisP 4y ago
PG described it that way, but two languages could each have a weird and powerful feature that programmers in the other language don't understand, and then each language is a blub for the other.

goto11 4y ago

The Blub-paradox is that everyone thinks those other languages are blub but their own favorite language is the non-blub pinnacle of creation.

deleted 4y ago
[deleted]
deleted 4y ago
[deleted]
deleted 4y ago
[deleted]
a9h74j 4y ago
That's the blub-paradox. There's also the excuse that one could have completed an assignment if they could have used blub language; this is the fizz-blub excuse.
pdimitar 4y ago
There are many programmers, myself included, that are under no illusions about the deficiencies of their own favorite languages. Most languages are Blub. Where we the programmers at large fail IMO is that we don't recognize that no language is universal. Some are good at X, others at Y, another group is only good for Z. But we all want to pretend that no no no, language A is perfect and you all are sheep for not seeing it and sticking to languages B, C and D.
- kaba0 4y ago
  Is there really any language that is all that more productive for a given task? Libraries (somewhat including the standard lib as well) and experience aside, I don’t think one would finish a given task 2x faster in any other general purpose language, let alone more than that. (in agreement with Brook’s famous paper) So by extension, a single language with a huge ecosystem should suffice for any task.
  - goto11 4y ago
    If a given task can be solved in both assembler and Python, then surely Python would be more than 2x as productive, given a developer with experience in both. This is why assembler is only used for tasks which just cannot be solved in a high-level language. For most purposes Python would also be more than 2x as productive than C, again given a developer with experience in both.
    - kaba0 4y ago
      I meant high-level, managed languages. You wouldn’t get this 2x multiplier between Python and Java, JS, Haskell, etc.
      - goto11 4y ago
        Probably not. At least any difference will be dwarfed by the effect of prior experience by developers and available libraries.
  - pdimitar 4y ago
    I code Rust, Elixir, Golang and shell scripts these days. Scrapped all other 5-6 languages that I also learned over my career. Elixir is not just 2x but very likely anywhere from 4x to 10x more productive. (I dislike PHP a lot but same can be said for it as well btw.) I got a REPL in which I can easily code 80%-100% of my workflow and test it in real time. After you recall REPL history a few times, copy paste in editor, run 1-2 more times to make sure it's still working and you're done (apart from unit tests). I love Rust a lot and apply it more and more but I haven't had anything I ever finished in 10-ish minutes like I did with Elixir. I do love the guarantees it brings however and I am making an active effort to become fast and efficient (thus productive) with it. Golang, as much as I dislike it in general -- because it doesn't go far enough with its static strong typing and people abuse its escape hatches way too much, effectively turning it into a dynamic language -- is a fairly productive language sitting somewhere between the above two. I am planning on partially replacing my shell script incantations with it. And finally, shell scripting I've used and abused hundreds of times and my failure rate there is extremely low. There has almost never been any task requiring stitching different other programs that I didn't manage to do with it. And productivity is super high. > in agreement with Brook’s famous paper Meh. There is a good amount of timeless computer science writings but this saying isn't one of them. Some of the advice from older masters is simply outdated; they postulated things with certain assumptions and a good chunk of them no longer hold true (famous example is "storage is super slow" which is longer a given, you have NVMe SSDs that are like 10x-20x slower than RAM). Which is fine, I appreciate and cherish their contributions. But we shouldn't get stuck in our ways and should periodically re-evaluate our foundations. > So by extension, a single language with a huge ecosystem should suffice for any task. Yes, as long as the language itself enables productivity and as long as the ecosystem isn't a humongous collection of half-done and abandoned two-week passion projects. And as long as the language itself isn't a half-done mess that's never going to get fixed due to obsession with backwards incompatibility even though transpilers exist and a good amount of companies don't have ancient mastodons to support (hint hint, all of the above applies to Javascript / Node.JS). IMO Golang and Rust do seem to satisfy your criteria. Maybe Java and C# as well (wouldn't know, I abandoned Java long ago). My favorite Elixir -- sadly less so because even though most of the common paths have been beaten / trodden, there are huge gaping holes at places. PHP and JS technically qualify although their ecosystems and the languages themselves are a huge mess. But I suppose "if you know what you're doing it's fine" (famous last words through which I made a lot of money fixing the messes of those "that know what they're doing").

DennisP 4y ago

PG described it that way, but two languages could each have a weird and powerful feature that programmers in the other language don't understand, and then each language is a blub for the other.