2 ms·

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 producti

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.

2 ms·

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 producti

by lifthrasiir 5y ago

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.