Hacker News Reader

Comment by amelius | Hacker News Reader

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.

View on HN

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!)

Reply on news.ycombinator.com