Perhaps it’s a matter of clarifying what your values (for the idealist) or priorities (for the pragmatist) are. And by this I mean going beyond throwing around names like “simplicity”, “predictability”, “reliability”, etc. You need to explain what those names actually mean to you, because they almost certainly mean something different to someone else.
For example, and as far as I can tell:
For a Go user, “simplicity” means that the operational interpretation of a program fragment is unique, straightforward and never in question after you’ve read the code. From this no-nonsense point of view, higher-order functions are already suspicious, and fancy ones like Clojure’s transducers and Haskell’s lenses/traversals are complete abominations.
For a Clojure user, “simplicity” means ontological parsimony. From this point of view, data abstraction is undesirable, because it grows the number of kinds of things that exist in your program.
For a Haskell user, “simplicity” means minimizing the amount of ad hoc design choices in any part of your program that doesn’t directly address the problem domain. This leads to using universal constructions as the basis for plumbing libraries (lens, conduit, etc.).
The article was about conversations among language designers, not miscommunications between language users.
It’s worthwhile to remember that the same words can mean different things, but I’m just not sure how that bears on this article.
The article also mentions miscommunication between language users:
Contrast that kind of discussion with the heated arguments or overly zealous statements you sometimes see from users of the same languages. There’s a real disconnect, possibly because the users don’t have the experience of weighing the arguments on both sides and don’t realize how easily a particular decision might have gone the other way.
And concludes with the following appeal:
If someone asks why Go does X instead of Y, please try to present the engineering reasons fairly, including for Y, and avoid argument solely by appeal to authority.
I just wanted to add that, in programming language design, those “engineering reasons” are often influenced by one’s opinions on what “the right way to program” is.
The idea that the go language designers and implementors are nondogmatic is an interesting assertion to make, but it’d be better if there were a citation or an example. Certainly there are, famously, many more counterexamples, so it would be great to understand why the author has this belief. Is it from experience? Or is it from an ardent wish that it be true?
I am a huge fan of Go, bet businesses on it, have had great successes with it, that said…
… why the author has this belief. Is it from experience?
I have no doubt that this is the truth. I believe the core team is very willing to discuss things at length, non-dogmatically with those they consider peers (language designers, researchers). But how they dealt with the community in both tone and substance was another thing all together – they set the dogmatic “no questions” (less charitably, “we are right”) tone absolutely, and the community followed.
Or is it from an ardent wish that it be true?
Or I suspect, a hope for the future. Which is fine, if your community has issues, try to change them and the change has to start from people with voices with enough reach, rsc is one of those voices.
The go team are a bit similar to how openbsd works. If its clear you dont know what you are talking about, you will be redirected to go-nuts.
Tbh i think they are incredibly patient with lots of bad and unresearched suggestions. Good suggestiona get a great deal of consideration
rsc is just one of the Go designers/implementers, and is probably somewhat less opinionated than, say, Rob Pike.
My guess is rsc is reposting this as much as a reminder to himself as to others. Go is probably more famous for what it expressly leaves out than what it leaves in, and so remembering to say why something was left out is pretty hard versus just saying “because that’s not Go.”
[Comment removed by author]
I was surprised to come here to see a lot of objection to the Lisper’s suggestion that language designers tend to be open to talking about tradeoffs because they had to consider them during the design process. I read the point of the piece as the conclusion, asking the community to be fair and complete in talking about pluses and minuses:
But we need help from everyone. Remember that none of the decisions in Go are infallible; they’re just our best attempts at the time we made them, not wisdom received on stone tablets. If someone asks why Go does X instead of Y, please try to present the engineering reasons fairly, including for Y, and avoid argument solely by appeal to authority. It’s too easy to fall into the “well that’s just not how it’s done here” trap. And now that I know about and watch for that trap, I see it in nearly every technical community, although some more than others.
The idea that the go language designers and implementors are nondogmatic is an interesting assertion to make
I don’t think he’s actually making that assertion - he’s saying that the conversations language designers (of different languages) have amongst each other don’t appeal to dogma. Citations, then, could really only come from specific recorded conversations amongst only language designers.
There is this slightly disappointing panel with Bjarne Stroustrup, Rob Pike, Niko Matsakis (of Rust), and Andrei Alexandrescu (of C++ and D), whose most dogmatic participant seems (to me) to be Rob Pike, but if you’re hoping for an in-person flame war, it’s not there.
Replied something like this to dwc, but I’m surprised the focus here ended up on the Lisper saying that language designers are comfortable talking about tradeoffs because they had to wrestle with them while designing.
Seems like a nice enough anecdote and my reaction wouldn’t be to demand citations proving anyone’s thoughtfulness. But more fundamentally, the story was just a stop on the way to asking users to “[r]emember that none of the decisions in Go are infallible” and “present the engineering reasons fairly.” Hard for me to find that objectionable.