It’s a common mistake to confuse programming with typing. If someone’s just sitting there staring into space, it doesn’t look like they’re doing anything useful. If they’re rattling furiously on a keyboard, though, we assume they’re achieving something. In fact, real programming often happens before the typing, and sometimes instead of it.
I often describe Go as a language which expects you to arrive at your editor with a well-defined plan already in mind. It’s not a language that encourages or even really supports “exploratory” programming, like you might do in more REPL-oriented languages like Clojure, Ruby, or Python.
It was a design goal to make the compiler fast, absolutely. But I don’t think the motivation for that goal was to support experimentation, I think it was primarily motivated by pain from the very slow compile times for large e.g. C++ and Java projects (at the time).
This is quite a beautifully written article. I like the idea of applying this to all circumstances and not just to go. The idea of being kind, compassionate and thinking about other people as we code. We would have a much better it landscaping. All of this followed this advice.
You could write a regex to make this apply to anything with garbage collection and not-too-many features. The author also carelessly (and offensively) misapplies the concept of, and the word, “Tao”. Water’s flowing may be it’s wu wei, it’s lack of doing, it’s being: the water is flowing downhill, rather downhill-ness being some innate property of the water. It doesn’t have “a Tao”. Tao isn’t just “work[ing] with the grain”, it’s understanding the natural order that resulted in the grain to take the most effortless next action. I guess it’s just advertising copy so it’s not that important, but if I was a Taoist I’d be pretty miffed
I particularly appreciate this bit at the end:
I often describe Go as a language which expects you to arrive at your editor with a well-defined plan already in mind. It’s not a language that encourages or even really supports “exploratory” programming, like you might do in more REPL-oriented languages like Clojure, Ruby, or Python.
Some may disagree with that description. Wasn’t one of the design goals to make the compiler fast to support quick iteration and experimentation?
It was a design goal to make the compiler fast, absolutely. But I don’t think the motivation for that goal was to support experimentation, I think it was primarily motivated by pain from the very slow compile times for large e.g. C++ and Java projects (at the time).
This is quite a beautifully written article. I like the idea of applying this to all circumstances and not just to go. The idea of being kind, compassionate and thinking about other people as we code. We would have a much better it landscaping. All of this followed this advice.
Is this actually specific to Go? I feel like it could be about nearly any language from the 1980s.
You could write a regex to make this apply to anything with garbage collection and not-too-many features. The author also carelessly (and offensively) misapplies the concept of, and the word, “Tao”. Water’s flowing may be it’s wu wei, it’s lack of doing, it’s being: the water is flowing downhill, rather downhill-ness being some innate property of the water. It doesn’t have “a Tao”. Tao isn’t just “work[ing] with the grain”, it’s understanding the natural order that resulted in the grain to take the most effortless next action. I guess it’s just advertising copy so it’s not that important, but if I was a Taoist I’d be pretty miffed
Don’t be miffed. Mabye you’re already a Taoist dreaming that you’re a WilhelmVonWeiner.
But then you get only 1% of the clicks…
Given Go is essentially a reskin of Algol 68…
What isn’t, these days?