4 ms·

It's kind of funny how the church of absolute simplicity above all things have became so dominant. As someone who has seen the cost of C++ templates metaprogra

It's kind of funny how the church of absolute simplicity above all things have became so dominant. As someone who has seen the cost of C++ templates metaprogramming wizardry gone wild I understand part of this reaction. I reckon we would have a real talent shortage bigger by orders of magnitude if we required familiarity with Alexandrescus' Modern C++ Programming and Herb Sutter's Exceptional C++ to onboard new programmers in a project. Yeah, definitelly there's such a thing in programming as "too clever". But should we so radically into the opposite direction? Should we sacrifice any attempt at expressiveness into the altar of simplicity? Aren't we going too far into the opposite direction?

illusive4080 2y ago
Yes we are going too far. Go treats us like we are inept.
- doctor_eval 2y ago
  I dunno, I think go simply treats us as if someone else will be reading the code we write.
  - euroderf 2y ago
    Where "someone else" includes values of "oneself, but in the future".
  - illusive4080 2y ago
    I’m capable of reading someone else’s Node, Python, Rust, C++, and Java. I’ve seen good code and bad code. I’ve also seen good Go code and bad Go code. I know this is what the designers of Go intended, but they accomplished it by dumbing down the language far too much.
GrantMoyer 2y ago
In my view, aiming for simplicity is good, but only simplicity of the whole system, and superficial simplicity is often at odds with total simplicity. The following code is composed from a small set of simple operations, transformed = [] for (i = 0; i < len(list); i = i + 1) { el = list[i] temp = transform(el) transformed.append(temp) } but together the simple operations form a complex operation. The effect of each individual line is immediately clear, but the effect of the whole procedure is (marginally, in this toy example) obscured. However, If we extend our small set of simple operations with complex but common operations, we can express complex operations with conciceness that, overall, makes them simpler to recognize and reason about: transformed = list.map(transform) The effect of the line now requires more background knowledge, but in return the effect of the entire procedure becomes more readily apparent.
soraminazuki 2y ago
Sadly, it's not just Go. Everywhere you look, some people argue that there shouldn't be a learning cost for anything. The problem with this kind of reasoning is that while it sounds nice in theory, it obviously isn't practical. It's the perfect pretext. The distinction between what's advanced knowledge vs. what's a given is totally arbitrary and is often a proxy for personal preference. Passing around functions or using them as return values is a common pattern in programming. It's also not the kind of knowledge that needs relearning either. You learn about it once and move on. If this can't be considered required knowledge for software professionals, I don't know what can.
zokier 2y ago
Considering that Rust is the most hyped language (and e.g. topping SO surveys) out there, and I definitely would not call many things in Rust simple, I wouldn't be worried about simplicity being overly dominant
pjmlp 2y ago
We are, that is why at the end of the day language like Go evolve into a kludge of poorly integrated designs, and the anti-complexity folks discover that those complex features exist for a reason, and then have to try to implement them into their earlier design decisions. We have been through this reboots multiple times, Pascal vs Algol 68, C vs PL/I, Java vs C++, .... Now compare where those "simpler" languages are 20 to 50 years later, compared with their version 1.0, and the amount of "could it been better" features if they were there in version 1.0. Go folks, thought they are special and this wouldn't happen to them.

illusive4080 2y ago

Yes we are going too far. Go treats us like we are inept.

doctor_eval 2y ago
I dunno, I think go simply treats us as if someone else will be reading the code we write.
- euroderf 2y ago
  Where "someone else" includes values of "oneself, but in the future".
- illusive4080 2y ago
  I’m capable of reading someone else’s Node, Python, Rust, C++, and Java. I’ve seen good code and bad code. I’ve also seen good Go code and bad Go code. I know this is what the designers of Go intended, but they accomplished it by dumbing down the language far too much.

GrantMoyer 2y ago

In my view, aiming for simplicity is good, but only simplicity of the whole system, and superficial simplicity is often at odds with total simplicity. The following code is composed from a small set of simple operations, transformed = [] for (i = 0; i < len(list); i = i + 1) { el = list[i] temp = transform(el) transformed.append(temp) } but together the simple operations form a complex operation. The effect of each individual line is immediately clear, but the effect of the whole procedure is (marginally, in this toy example) obscured. However, If we extend our small set of simple operations with complex but common operations, we can express complex operations with conciceness that, overall, makes them simpler to recognize and reason about: transformed = list.map(transform) The effect of the line now requires more background knowledge, but in return the effect of the entire procedure becomes more readily apparent.

soraminazuki 2y ago

Sadly, it's not just Go. Everywhere you look, some people argue that there shouldn't be a learning cost for anything. The problem with this kind of reasoning is that while it sounds nice in theory, it obviously isn't practical. It's the perfect pretext. The distinction between what's advanced knowledge vs. what's a given is totally arbitrary and is often a proxy for personal preference. Passing around functions or using them as return values is a common pattern in programming. It's also not the kind of knowledge that needs relearning either. You learn about it once and move on. If this can't be considered required knowledge for software professionals, I don't know what can.

zokier 2y ago

Considering that Rust is the most hyped language (and e.g. topping SO surveys) out there, and I definitely would not call many things in Rust simple, I wouldn't be worried about simplicity being overly dominant

pjmlp 2y ago

We are, that is why at the end of the day language like Go evolve into a kludge of poorly integrated designs, and the anti-complexity folks discover that those complex features exist for a reason, and then have to try to implement them into their earlier design decisions. We have been through this reboots multiple times, Pascal vs Algol 68, C vs PL/I, Java vs C++, .... Now compare where those "simpler" languages are 20 to 50 years later, compared with their version 1.0, and the amount of "could it been better" features if they were there in version 1.0. Go folks, thought they are special and this wouldn't happen to them.