3 ms·

If experts' code never becomes more clear and concise than novices', there's no payoff for getting better with the language, and nobody ever really gets up to s

If experts' code never becomes more clear and concise than novices', there's no payoff for getting better with the language, and nobody ever really gets up to speed.

zxcmx 7y ago
Big IMHO disclaimer, but: Yes! If expert code and novice code look pretty much the same, that is great! I think rather than futzing around with the language, go frees you to think harder about the problem domain. Better architecture, design decisions, problem domain modelling, documentation / communication, core data structure and algorithm selection, api design - these are the things that distinguish expert from novice output, not statement level expressiveness. There's obviously a line to be drawn somewhere! - an expert can write "good" code and develop useful systems in GW Basic, but few would voluntarily choose to in 2019. Really though, the runtime limits the problems you can solve in GW Basic more than the language syntax. I think this is why go focuses a lot on the runtime - low latency gc, concurrency, etc - at the high end of programming ability the limits on what problems you can solve in a language (without dropping down / calling out) are dictated by the power of your runtime, not language syntax. As a data point, when I think about programmers with the most impactful software outputs (rather than talks, essays etc) it's hard to overlook the C programmers. Git could have been written in any number of languages but fairly straightforward C is enough to get the job done. The "expert" work in git exists at a much higher level than the source code.
nemothekid 7y ago
>there's no payoff for getting better with the language, and nobody ever really gets up to speed. Or maybe it's an indication that I should spend less time playing code golf and more time building what I actually set out to build. I'd imagine an expert could write a better, performant database than a novice and the fact that can be achieved in language that will effectively communicate to a novice is arguably a good thing.
- erik_seaberg 7y ago
  Novices should see queues and sorted sets by their proper names. They should see reduce(map(filter(…))), not big loops that inline all three written from scratch repeatedly because experts didn't want the compiler doing work that might make it slower.

If experts' code never becomes more clear and concise than novices', there's no payoff for getting better with the language, and nobody ever really gets up to speed.

zxcmx 7y ago

Big IMHO disclaimer, but: Yes! If expert code and novice code look pretty much the same, that is great! I think rather than futzing around with the language, go frees you to think harder about the problem domain. Better architecture, design decisions, problem domain modelling, documentation / communication, core data structure and algorithm selection, api design - these are the things that distinguish expert from novice output, not statement level expressiveness. There's obviously a line to be drawn somewhere! - an expert can write "good" code and develop useful systems in GW Basic, but few would voluntarily choose to in 2019. Really though, the runtime limits the problems you can solve in GW Basic more than the language syntax. I think this is why go focuses a lot on the runtime - low latency gc, concurrency, etc - at the high end of programming ability the limits on what problems you can solve in a language (without dropping down / calling out) are dictated by the power of your runtime, not language syntax. As a data point, when I think about programmers with the most impactful software outputs (rather than talks, essays etc) it's hard to overlook the C programmers. Git could have been written in any number of languages but fairly straightforward C is enough to get the job done. The "expert" work in git exists at a much higher level than the source code.

nemothekid 7y ago

>there's no payoff for getting better with the language, and nobody ever really gets up to speed. Or maybe it's an indication that I should spend less time playing code golf and more time building what I actually set out to build. I'd imagine an expert could write a better, performant database than a novice and the fact that can be achieved in language that will effectively communicate to a novice is arguably a good thing.

erik_seaberg 7y ago
Novices should see queues and sorted sets by their proper names. They should see reduce(map(filter(…))), not big loops that inline all three written from scratch repeatedly because experts didn't want the compiler doing work that might make it slower.