There should only ever be one way to express yourself
By @edent
· Computer Science language programming python · 7 comments · 300 words
I've been thinking about programming languages and their design.
In her book about the divergence of the English and American languages, Lynne Murphy asks this question:
wouldn’t it be great if language were logical and maximally efficient? If sentences had only as many syllables as strictly needed? If each word had a single, unique meaning? If there were no homophones, so we’d not be able to mix up dear and deer or two and too?
That got me thinking about the creativity which can be expressed in code - and whether its a good thing.
Let's take an incredibly simple and common operation - incrementing an integer variable by one. How would you do that? You've probably see these variations:
$i = $i + 1;or
$i = $i++;or
$i = 1 + $i;or
$i = int( float_adder( float($i), 1.00 ) );or
i1, i2 = i1^i2, (i1&i2) << 1I'm sure you can come up with a few more esoteric methods.
The Python programming language has a list of aphorisms for good programming practice. One of which is:
There should be one-- and preferably only one --obvious way to do it.
Is that right? As described in What is Pythonic?, the Python language itself has multiple ways to accomplish one thing.
But, is it a good idea?
Back to Lynne Murphy again:
No, absolutely not. No way. Quit even thinking that. What are you, some kind of philistine? If Shakespeare hadn’t played with the number of syllables in his sentences, he would not have been able to communicate in iambic pentameter.
Shakespeare wasn't writing Python though, was he?
@blog I've been thinking about this recently.
An update to MS Outlook at work has made the style/grammar checker more fussy. My new phone does it, too.
Yes, "we definitely should do X" is more verbose than "we should do X", but the "definitely" is my voice and I wanted to convey the enthusiasm.
If everyone takes the suggestion all the time, our communication may be more efficient, but it will also be bland.
@volcan01010 @blog I've had the same argument with the Office grammar editor. I want to tell it to mind its own business and be quiet. But then I also work with a lot of people where English is not their first language, and think it might be easier for them if I simplified my writing.
I'm always reluctant but I end up following the suggestion about 50% of the time—and hating how dull and flat it ends up sounding.
spiffytech says:
I've always felt that Pythonic rule was about intuition and idioms, rather than restriction. It isn't saying only one way should be available. It's saying a problem should have an obvious solution, one that all Python programmers agree is clearly the right call.
I agree with that. It makes code easier to maintain, and by more people, and reduces the chance of errors because solutions are obvious, not clever. In fact it's the same thing people like about writing Go code.
It's worth remembering that when this was written, Python was growing because it converted ex-Perl devs. The statement was partly a stance against Perl's TIMTOWTDI, one important factor (among others) for Perl's notorious unreadability.
Both Homer and Luís de Camões wrote epic poems (Illiad, Odyssey, Os Lusíadas) using a fixed set of syllables. So it's possible, and at least Odyssey is considered the second most influential book in the West after the Bible.
@Edent one obvious way doesn't mean there can't be other understandable ways, or non-obvious ways.
Flexibility allows for the fact that the obvious way might depend on context.
Ivan says:
The goals of a particular programming project determine what's optimal for it in terms of the programming language of choice and particular idioms that will be used. I wouldn't want to play four-dimensional chess against Rust's borrow checker for a one-off analysis that can be done in one line of R (or even without any programming at all, in Calc). But I also wouldn't want an unchecked dynamically typed virtual machine with a stop-the-world garbage collector piloting my spaceship.
For common tasks, use a universal programming language and the most common idioms it can offer; it's probably the best solution, and reality says it should work (since it works for everyone else). For quirky projects with their own special requirements, the best tool may be different. Make sure to define a code style and follow it.
It's annoying how in certain areas of programming, "the one obvious way to do it" is a function of time. Think of how many web frameworks, nay, whole paradigms about how the Web should be programmed we have witnessed coming and going: we went from simple but slow to launch CGIs to application servers for faster response and dedicated application virtual machines for easier deployment (and switched approximately 6 languages in the process). All of these approaches were probably locally optimal for most projects they powered at the time. Should I rewrite my
numpypipeline totensorflowso that it would work faster on a GPU? Or is ittorch? Should I wait for better GPU support injax? Will the pile of dependencies come crashing anyway when I revisit the code a year later?furicle says:
Oh look, it's Larry Wall with a pitchfork, and he's brought friends....
(Honestly, looks like you can out run most of them though....)
More comments on Mastodon.