- #Three principles from zen of python how to#
- #Three principles from zen of python code#
- #Three principles from zen of python windows#
There are many ways of discussing culture, but with respect to an engineering culture Lucovsky’s description is apt. The reason I mention it is Lukovsky’s description of a culture as a common way of evaluating designs and making tradeoffs.
#Three principles from zen of python windows#
Engineering Valuesĭan Luu found an old presentation by Mark Lucovsky about the engineering culture of the windows team around the windows NT-windows 2000 timeframe. Thus proverbs are perhaps not the best teaching tool in this scenario. It’s important to recognise that, in a growing community, at any time the people learning Go far outnumber those who claim to have mastered the language. The goal of the Go Proverbs are to reveal a deeper truth about the design of the language, but how useful is advice like the empty interface says nothing to a novice from a language that doesn’t have structural typing? Proverb (noun): a short, well-known pithy saying, stating a general truth or piece of advice. Again, the dictionary comes to the rescue: This is not to dismiss Pike’s work, it is just that the Go Proverbs, like Segoe Kensaku’s original, are observations, not statements of value.
#Three principles from zen of python how to#
Are these suitable teaching tools? Will these tell newcomers how to write good Go code? Stepping away problematic idioms, what other cultural artefacts do Gophers have? Perhaps we can turn to Rob Pike’s wonderful Go Proverbs. Wouldn’t it be better if the advice we gave didn’t alienate the author right at the point they were most willing to accept it? Proverbs
#Three principles from zen of python code#
I offer that idiomatic Go is not a suitable mechanism for teaching how to write good Go code because it is defined, fundamentally, by telling someone they did it wrong. It’s saying “you can’t sit with us.” After all, isn’t that what we mean when critique of someone’s work as non-idiomatic? They didn’t do It right. My concern with the mantra of idiomatic Go is, in many ways, it can be exclusionary. Idiomatic Go is not something you learn from a book, it’s something that you acquire by being part of a community. Idiom (noun): a group of words established by usage as having a meaning not deducible from those of the individual words. Why is this? Like all truths, the answer is found in the dictionary. More importantly, to say to someone that their code is not idiomatic does not explain why it’s not idiomatic.
If something is not idiomatic, it is not following the prevailing style. To say that something is idiomatic is to say that it follows the style of the time. If there’s a continuum between good and bad, how to do we know what the good parts are? What are its properties, its attributes, its hallmarks, its patterns, and its idioms? Idiomatic Go Something that I’ve been thinking about a lot recently, when reflecting on the body of my own work, is a common subtitle, how should I write good code? Given nobody actively seeks to write bad code, this leads to the question how do you know when you’ve written good Go code? If you’d prefer a shorter version, head over to .Ī recording of the presentation is available on YouTube. This article was derived from my GopherCon Israel 2020 presentation.
0 kommentar(er)
