alt Hacker NewsThat's saying the same thing. If you give someone the ability to understand a brilliant language, they will turn their attention to the language and away from the problem. That's just human nature. Shiny attracts us. Let's be honest, we all have way more fun diving deep into crafting the perfect type in Haskell. But Pike indicates that if you constrain developers to bounds that they already know, where they can't turn their attention to learning about what is brilliant, then they won't be compelled away from what actually matters – the engineering.
Replies
Is there any evidence that the Go style of constraints increases productivity or code quality or other metrics compared to "shiny" languages? I've heard that point repeated many times, but people have done a decent amount of engineering in many other languages too, without the need to be limited like that.
> If you give someone the ability to understand a brilliant language, they will turn their attention to the language and away from the problem. That's just human nature.
Not sure which languages you define as brilliant but I’ve never seen this pattern anywhere in my career, in any language. Including Rust, which is often offered by Go fans as an example of an esoteric exotic language.
In everywhere I’ve seen, people are focused on solving some engineering problem, not on showing off their brilliance by solving language puzzles.
This defense of Go is REALLY common but as far as I can tell is purely based on myth.
I recognized exactly that way back in 1995. I used to teach Clipper in the late 80s and early 90s and you could do so much with it. It's competitor was FoxPro, which was far less capable.
However, in hindsight after I quit using it I realized that Clipper developers often focused on perfecting code — myself included — whereas FoxPro developers just got shit done for the client/end-user. #fwiw
> then they won't be compelled away from what actually matters – the engineering.
Maybe it is, to the extend that playing with lego blocks authorised by the lego corporation is considered engineering. That, of course, is a silly line to draw for defining the discipline.
> we all have way more fun diving deep into crafting the perfect type in Haskell
What Haskell allows you to do in practice is defining required and missing control flows (for solving your problems) as types[0], and constraining those types with rules that define your business domains the control flows must operate in. That is the actual engineering, as opposed to joining plastic bricks.
[0] https://hackage.haskell.org/package/foldl-1.4.17/docs/Contro...