2 ms·
They have one more thing in common; the text is read by other people. And the better written, the more effortless it is to understand. I think this aspect of i
by tjogin 15y ago
They have one more thing in common; the text is read by other people. And the better written, the more effortless it is to understand.
I think this aspect of it is what the slashdot author is mostly talking about, suggesting that if you write code as if you were writing to the next programmer, rather than to just the computer, your code will be better for it.
Clearly, programming and writing isn't the same thing. Nobody is claiming that and, guaranteed, nobody here thinks that. It's a metaphor and like any other metaphor it breaks if you bend it enough.
- kenjackson 15y agoUnfortunately, this metaphor breaks at the onset. Programs aren't primarily written to be read by people. They're primarily meant to enable functionality. Readability of code is important, but not the ultimate ends -- it is part of the means. But the important part of my post was that programming is about automation. It's not about weaving a story, even for the next programmer. It's about building abstractions for automation. And yes, its important for other programmers to build on top or service it, but given a choice between the right user experience and dev experience, user experience should usually win (although there will be some exceptions).
- tjogin 15y agoThe author argues that good code should be written for people. The metaphor doesn't break just because you disagree with the author's point. IMHO, any dolt can produce code that only works. All too often I have to sift through horrible code that works, and I think the author is right in that if the programmer who wrote that (sometimes that's me, sometimes it's someone else) had had the next programmer in mind when he/she wrote it, it'd be much less of a pain.
- kenjackson 15y agoThe author argues that good code should be written for people. If good code were written only for people there'd be no quicksort. No fast implementations of FFT. Probably no fast versions of memcpy. The reason is that coding is not primarily about writing for other people. Look at Donald Knuth's code. Extremely well-written, yet certainly doesn't stand on its own. And there are certainly design decisions that optimize for both asymptotic complexity and small constant factors. My point is that analogizing this to books does no one any favors at all. We're having a conversation on the merits, w/o having to allude to neither haikus nor novels, nor gerands, nor foreshadowing. Programming is difficult, even for code that "only works" (you'd be a billionaire if you could find a way to quickly produce code that "only works"). It has little more in common with writing than tarot cards -- which also are made to be read by humans.
- tjogin 15y agoThe author never claimed the code should be written only for people, then it wouldn't work, would it? You're either trolling or mistaking the rest of us for complete morons.
- kenjackson 15y agoMy current theory is that programming is quite literally writing. That's what the author wrote. Lets take another (stupid) quote from the author: Most code sucks because we have the fluency equivalent of 3 year olds trying to write a novel. There's no absolute nature regarding the state of ability for any given task. There is no way to map fluency in English to fluency in any other domain. It just doesn't make sense. This is just all around lazy thinking. It's buying into a metaphor because you either don't have the ability or desire to actual think about the real issues. edw earlier in this thread actually took a little time to think about the issue. This slashdotter made no effort, had no substance, no data, just a cheap metaphor that fell apart upon first glance. or mistaking the rest of us for complete morons How's this for lazy thinking -- I use duck typing.