Writing code and prose | Hacker News Reader

Writing code and prose

ericsuh.com

50 pointssuchire12 comments

I have found that writing code is much easier than reading it. Interestingly, reading prose is much easier than writing it.

Therefore, I wish there was some tool that allowed me to write prose in a more formal (code-like, hence "boring") style, and have it translated to more vivid prose. For example, if I use the same word ten times in the same paragraph, this tool would replace it by synonyms; or if I make sentences which are too long, it would automatically break them up, or vice versa. Basically, I want to code the meaning of what I want to say, and have the tool generate the prose.

The key for maintainability is to write code that is easily readable, and this is not an easy feat.

A good rule of thumb is that a code is written once, but will be re-read maybe 50, 100 or 1000 times in the life of the product.

So, in my opinion, it is crucial to optimize for ease of comprehension.

"For example, if I use the same word ten times in the same paragraph, this tool would replace it by synonyms;"

Very funny. This would make terrible prose, I guess. It is part of the art to say things only once and thus make repetitions unnecessary.

Repetition is useful for memory. If your aim is conversational, like this, it's unnecessary. But if you're telling a story, it's useful. Besides, the GP wants to reduce the literal repetition by replacing the identical words with synonyms. This is akin to writing in Inform 7 or similar interactive fiction systems. Or if, like me, you're terrible at coming up with character names, you can use <PROTAGONIST>, <ANTAGONIST>, etc. throughout while you're making outlines and such. GP would want to do something like that, with proper substitution of the name with other identifiers later on (full, partial, first, last, pronoun, nickname).

Makes me think of The Eye of Argon. Stygian cloud of charcoal ebony etc.

The auto-thesaurus would make your prose worse a lot of the time, because often you want to hold the word choice constant to make other choices salient ("We shall fight on the beaches, we shall fight on the landing grounds, we shall fight in the fields and in the streets, we shall fight in the hills; we shall never surrender", but the principle extends to less obtrusive cases).

Maybe if you make it really easy to reroll the dice and get another rewording, or go back to the original? That could be interesting then.

I think that's true for everyone. I've found that working my way into an existing codebase involves multiple passes, and each time I get a bit more immersed in the code and my assumptions change. It's also good to write documentation in parallel, as you can capture and address all the things that were initially confusing.

(Also, hi Eric!)

I don't disagree, but I love contrarian opinions, and I'm reminded of a video I saw from a talk at an old RubyConf (I think). The talk was about beauty and aesthetics in code. It described some principles of beauty—simplicity, elegance, clarity, etc—and explained how these qualities also describe good code. But I loved that someone from the audience after the talk asked the question, what about more postmodern notions of beauty? Is there anything missing in this classical picture?

It's just an interesting question. One way to start thinking about it is to consider the role of the author in both coding and postmodern texts: we can't really point to a clear notion of an author anymore. Who's the author of any given file in the Linux repository? There might be dozens of people involved. Maybe they together give rise to some emergent super-author, shaped by the code itself and its culture... Maybe different styles intersect and collide and create some kind of fruitful chaos. And so on.

So one hypothesis is that classical beauty in code might lead to problems in cooperation. Like, this code is so perfect that I don't want to touch it. Or the literate elegance of this module intimidates me as a non-native speaker. Lots of interesting issues.

Focusing on just how the code looks is like concentrating on the paint job of a car and ignoring everything else. The deeper, more important concept, is that is the theory of the program understood and communicated lucidly through the code.

I'm once more evoking Peter Naur's "Programming as theory building"

http://pages.cs.wisc.edu/~remzi/Naur.pdf

"Maybe different styles intersect and collide and create some kind of fruitful chaos. And so on."

No, coding is not an art where noise synthesis produces reasonable results.

Who's the author? Run git/svn blame

> Like, this code is so perfect that I don't want to touch it.

And the paradox: You want the code to be simple and neat, to make it easy for others to contribute. But, you have to be very strict with accepting contributions to keep it that way... so it's not so easy for them to contribute.

Reply on news.ycombinator.com