3 ms·

And in programming you don't have to worry about capturing the audience, the development of the characters, the story arch, being clear but not being obvious, e

by tjogin 15y ago

And in programming you don't have to worry about capturing the audience, the development of the characters, the story arch, being clear but not being obvious, etc. Both in programming and writing, the actual writing part is the easiest part. And while bad programmers can make a program work, and bad writers can tell a story, it takes good ones to do it coherently, efficiently and enjoyably. It's not the exact same thing, which I don't think anyone is saying, but there are some similarities there, especially the aspect of writing readable code.

kenjackson 15y ago
They're not nearly the same thing. The scope of modern literature has hardly moved in hundreds of years. Compare Updike, Roth, or Mitchell to Dante or Shakespeare -- they'd seem like near contemporaries in programming. In contrast, in the past, programs to do Newtons method or compute trig tables were often the full scope of a program. You certainly never had a Halo 3, Windows 7, Google Search, or WordLens application written even 50 years ago. Good literature isn't about automating increasingly sophisticated processes. Programming is all about that. This leads to increasing complexity of programs, where the goal of software engineering is to abstract/hide as much of the complexity as possible. The only things they really share in common is that they're both written in text. If programs were written by soldering wires no one would make such odd acquisitions (do EE relate circuit design to writing literature?). I think we give this slashdot author far too much credit.
- 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 ago
    Unfortunately, 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 ago
      The 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 ago
        The 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.
- absconditus 15y ago
  This is called taking an analogy too literally.
  - kenjackson 15y ago
    I'd say its called creating an analogy where one shouldn't. As a general rule, and maybe I'm too influenced by Dijkstra -- don't introduce metaphors/analogies where you can reasonably talk w/o one. In this case, no clarity was introduced by its addition. It's like adding gravy to mashed potatoes. Sure it may make the potatoes taste better, but now you can't put the gravy back in the gravy bowl, can you?
    - reinhardt 15y ago
      I saw what you did there ;-)
- xsmasher 15y ago
  You're looking at a pretty mature art form, although "hardly moved" seems inappropriate for a time period that includes the rise of the novel. You might better compare the films of 100 years ago to the films of today to see an increase in complexity similar to the march of programming progress.

by tjogin 15y ago

kenjackson 15y ago

They're not nearly the same thing. The scope of modern literature has hardly moved in hundreds of years. Compare Updike, Roth, or Mitchell to Dante or Shakespeare -- they'd seem like near contemporaries in programming. In contrast, in the past, programs to do Newtons method or compute trig tables were often the full scope of a program. You certainly never had a Halo 3, Windows 7, Google Search, or WordLens application written even 50 years ago. Good literature isn't about automating increasingly sophisticated processes. Programming is all about that. This leads to increasing complexity of programs, where the goal of software engineering is to abstract/hide as much of the complexity as possible. The only things they really share in common is that they're both written in text. If programs were written by soldering wires no one would make such odd acquisitions (do EE relate circuit design to writing literature?). I think we give this slashdot author far too much credit.

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 ago
  Unfortunately, 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 ago
    The 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 ago
      The 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.
absconditus 15y ago
This is called taking an analogy too literally.
- kenjackson 15y ago
  I'd say its called creating an analogy where one shouldn't. As a general rule, and maybe I'm too influenced by Dijkstra -- don't introduce metaphors/analogies where you can reasonably talk w/o one. In this case, no clarity was introduced by its addition. It's like adding gravy to mashed potatoes. Sure it may make the potatoes taste better, but now you can't put the gravy back in the gravy bowl, can you?
  - reinhardt 15y ago
    I saw what you did there ;-)
xsmasher 15y ago
You're looking at a pretty mature art form, although "hardly moved" seems inappropriate for a time period that includes the rise of the novel. You might better compare the films of 100 years ago to the films of today to see an increase in complexity similar to the march of programming progress.