4 ms·

> You cannot reduce the complexity of your problem by increasing the complexity of your language. This strikes me as backwards. There’s a certain amount of irr

> You cannot reduce the complexity of your problem by increasing the complexity of your language. This strikes me as backwards. There’s a certain amount of irreducible complexity in any requirements, and every commonplace problem the language refuses to solve is one more problem for me to face with no help. Nearly every feature that makes a language more concise and powerful (reentrant functions, higher-order functions, tail recursion, continuations, dynamic dispatch, multiple dispatch, garbage collection, sum and product types, pattern matching, exceptions, concurrency, laziness, macros) makes it harder to specify and implement, but reusing a heavily tested implementation that everyone knows is always better than trying to roll my own. > Language is (comparatively) easy to pick up. This is not a good thing. The shorter the learning curve, the quicker you run out of ways to improve your work. It’s like boasting that your toolbox is easy to carry, because it’s empty. > Deploy by running a single executable. This is not a good thing. It guarantees you can’t reuse any code provided by the platform. Static linking was a problem that was solved in the 1980s, and being able to choose it is always better than being forced into it. Anyway, Go does have a GCC-based toolchain with a normal linker, even if proponents prefer the one that reinvents everything incompatibly. > Being stuck in the 70s means no breaking changes since flared pants. I actually agree that languages should commit to “if you ask for the 2021 semantics that’s exactly what you get now and forever,” but any language can do that, we don’t have to settle for weak ones.

zetalyrae 5y ago
>This is not a good thing. The shorter the learning curve, the quicker you run out of ways to improve your work. I disagree with this. There are many languages that are perfectly productive which are reducible to a very small core: Haskell, Standard ML, OCaml, Modula-2/3. The size of the ecosystem is an extrinsic property to the language. Simple languages are easier to learn, easier to implement, and it's easier to understand code written in that language, since the semantics are simpler. Very rarely does language complexity buy you anything except painful surprises or obfuscated code contest entries. For example: Rust is a much simpler language than C++ and you can use it to do essentially anything reasonable you'd want to do in C++.
- lifthrasiir 5y ago
  Counterexample: Brainf*ck is very easy to learn and very difficult to program in. You have a point that a large feature set doesn't necessarily mean a productive language, but the same can be said for a small feature set. Your examples only show that there is some set of features that can subsume other features, so the number of features can be effectively reduced. At some point however there would be an irreducible set of features.
  - hnlmorg 5y ago
    There's obviously going to be a happy middle ground between too many features and too few. That middle ground is going to differ for different people too. That's the beauty of having different languages. If Bob finds Go too simplistic then he can use something else. Personally I like Go and don't want the language to change into yet another C++-like jack of all trades. The real problem with languages these days is people conflate personal preference with irrefutable fact. Probably because we're taught our profession is a science.
    - kortex 5y ago
      > The real problem with languages these days is people conflate personal preference with irrefutable fact. This bears repeating. I've found language preference and style depends a huge amount on education, language exposure, and even neurotypes. For example, personally I dislike keeping pieces of state in my head. I have gravitated towards a very functional style, eschew OOP, short functions, lots of static typing. I need it to stay sane. My kryptonite is long, scripty things with tons of mutable state and magic. Some people can work like that. They can keep a big chunk of varying state in their head. I don't proscribe that either type is better (though the former is much more approachable for those new to the codebase). It's just different tradeoffs.
- qsort 5y ago
  I believe you are mixing 'complex' and 'complicated'. > productive which are reducible to a very small core That's like saying first-class continuations are easier than coroutines or generators because they effectively subsume both. I don't think that's the case at all: you now need to understand continuations in addition to coroutines and generators. > Rust is a much simpler language than C++ C++ is more complicated than Rust, but Rust is more complex than C++. If you don't understand RAII, lifetime annotations are going to be tough to figure out...

zetalyrae 5y ago

>This is not a good thing. The shorter the learning curve, the quicker you run out of ways to improve your work. I disagree with this. There are many languages that are perfectly productive which are reducible to a very small core: Haskell, Standard ML, OCaml, Modula-2/3. The size of the ecosystem is an extrinsic property to the language. Simple languages are easier to learn, easier to implement, and it's easier to understand code written in that language, since the semantics are simpler. Very rarely does language complexity buy you anything except painful surprises or obfuscated code contest entries. For example: Rust is a much simpler language than C++ and you can use it to do essentially anything reasonable you'd want to do in C++.

lifthrasiir 5y ago
Counterexample: Brainf*ck is very easy to learn and very difficult to program in. You have a point that a large feature set doesn't necessarily mean a productive language, but the same can be said for a small feature set. Your examples only show that there is some set of features that can subsume other features, so the number of features can be effectively reduced. At some point however there would be an irreducible set of features.
- hnlmorg 5y ago
  There's obviously going to be a happy middle ground between too many features and too few. That middle ground is going to differ for different people too. That's the beauty of having different languages. If Bob finds Go too simplistic then he can use something else. Personally I like Go and don't want the language to change into yet another C++-like jack of all trades. The real problem with languages these days is people conflate personal preference with irrefutable fact. Probably because we're taught our profession is a science.
  - kortex 5y ago
    > The real problem with languages these days is people conflate personal preference with irrefutable fact. This bears repeating. I've found language preference and style depends a huge amount on education, language exposure, and even neurotypes. For example, personally I dislike keeping pieces of state in my head. I have gravitated towards a very functional style, eschew OOP, short functions, lots of static typing. I need it to stay sane. My kryptonite is long, scripty things with tons of mutable state and magic. Some people can work like that. They can keep a big chunk of varying state in their head. I don't proscribe that either type is better (though the former is much more approachable for those new to the codebase). It's just different tradeoffs.
qsort 5y ago
I believe you are mixing 'complex' and 'complicated'. > productive which are reducible to a very small core That's like saying first-class continuations are easier than coroutines or generators because they effectively subsume both. I don't think that's the case at all: you now need to understand continuations in addition to coroutines and generators. > Rust is a much simpler language than C++ C++ is more complicated than Rust, but Rust is more complex than C++. If you don't understand RAII, lifetime annotations are going to be tough to figure out...