Programming and Writing • Hacker News Board

Re: Programming and Writing

#61

Post by k__ » Fri, May 14, 2021, 7:01 PM UTC

jonnycomputer wrote: post #39

As a programmer and aspiring writer, the two activities don't really feel the same to me at all. I understand that there are many similarities. Building a piece of software and writing a novel are complex projects that span long periods of time, requires iteration, attention to detail, and cognizance of structure at varying scales, planning, etc.... But when I'm writing prose, it does not feel anything like writing c…

I write (technical) articles and develop software.

Good devs can be bad writers and the other way around. But good code is as good writing. It's a planned endevour which takes a few iterations to get right.

Most people who code bad and/or write bad are doing so because ther code and text are just streams of thoughts typed down as they had them. Sure, iteration can fix a bug here and there, but if their thoughts don't follow a red line, nobody can understand what they wanted to create.

Re: Programming and Writing

#62

Post by antirez » Fri, May 14, 2021, 7:20 PM UTC

vidarh wrote: post #59

hegelguy wrote: post #27

As someone who has done both extensively, I humbly disagree. Writing involves thinking in a much less instrumental way, in my experience. In programming, there is often a clear pre-defined task, and the only question concerns the proper means of achieving that task. Writing, on the other hand, necessarily compels something much more dynamic & non-linear at the level of composition. I'd toss this one under the categor…

Writers tend to report very different ways of working. Some plan out everything and write a huge synopsis, others sit down and write start to finish. Some iterate somewhere in between. For my part I plan out the high level plot, and a list of scenes. At most a 2-3 pages synopsis. Then I write start to finish. No exceptions: Scene by scene, paragraph by paragraph, without going back. Interestingly seeing as you sugges…

I used the same process. I wrote the novel from the start to the end, never reading back during the first draft if not for recalling certain details that affected the latter part of the story. Before starting I had just a subject of a couple of pages and a few main characters descriptions. All the rest happened while writing. But while the first draft is so much a matter of inspiration and letting things happen in front of your eyes, what comes next is a lot more similar to improving a large software system. Reading again and again, finding weak spots, improving, reiterating this process.

Re: Programming and Writing

#63

Post by pcmaffey » Fri, May 14, 2021, 7:41 PM UTC

dkarl wrote: post #29

An underappreciated aspect of programming that is taught well and consistently in the context of writing is the need for iteration. Never publish something without rereading it first. Anything longer than an email, you should have a break between writing a first draft and taking a second look at it. Murder your darlings: learn to recognize things that you're proud of for the wrong reasons, things that other people wo…

To carry the metaphor, iteration is not just about refactoring and optimizing, it’s mostly about debugging. Finding what isn’t working and trying something new. I wrote about how I use my programming logic to “debug my art”.* The same can be applied to writing.

*https://www.pcmaffey.com/debugging-your-art

Re: Programming and Writing

#64

Post by WorldMaker » Fri, May 14, 2021, 7:42 PM UTC

masswerk wrote: post #55

I've always thought of programs as "functional prose". The notion of software engineering may have hidden this somewhat in the past few years, but the two domains have very much in common. Including various strategies to tackle them. (From which follows somewhat implicitely: Whenever you set up a process for shared project development, also ask yourself, would this work for a shared writing effort?)

I tend to think of code much more like "poetry" than "prose". Programming languages provide required "meter", "rhyme", and other similar "format requirements" like poetry styles. Style guides and lint tools even further "refine" the "poetry style" agreed on by a development effort. I haven't found any particular use for this analogy for deep insights (there rarely were collectives focused on long form poetry in history, depending on what you think of oral storytelling traditions and/or if you agree with conspiracy theories that the output attributed to William Shakespeare was more of a collective effort than a lone auteur), but I still find it an interesting analogy.

Re: Programming and Writing

#65

Post by faustlast » Fri, May 14, 2021, 7:48 PM UTC

> Sentences must be well written, but the overall structure and relationship between the parts is also crucial.

He does not consider that writing is an art form, a means of creative expression, not just to get you idea across. For instance, one of the greatest novels "The Devil to Pay in the Backlands" is confusing and hard to read.

Re: Programming and Writing

#66

Post by proc0 » Fri, May 14, 2021, 7:58 PM UTC

masswerk wrote: post #55

I've always thought of programs as "functional prose". The notion of software engineering may have hidden this somewhat in the past few years, but the two domains have very much in common. Including various strategies to tackle them. (From which follows somewhat implicitely: Whenever you set up a process for shared project development, also ask yourself, would this work for a shared writing effort?)

Yeah, I have referred to asking questions as 'mind queries', if they're technical in nature, since it's just trying to acquire a piece of knowledge.

Re: Programming and Writing

#67

Post by antirez » Fri, May 14, 2021, 8:02 PM UTC

faustlast wrote: post #65

> Sentences must be well written, but the overall structure and relationship between the parts is also crucial. He does not consider that writing is an art form, a means of creative expression, not just to get you idea across. For instance, one of the greatest novels "The Devil to Pay in the Backlands" is confusing and hard to read.

In this case for the sentence to "work" is that it's confusing, anything that creates the effect (explicitly wanted or not) works. Like the single sentence of a program participating to an obfuscation programming context must work in order to create confusion. I left the artistic part of the process out of the post because in the artistic process the similarities are very far, IMHO. I think I use a creative process while programming as well, but is not alike to the one used to write.

Re: Programming and Writing

#68

Post by robotresearcher » Fri, May 14, 2021, 8:16 PM UTC

a4isms wrote: post #16

magpi3 wrote: post #7

It's an interesting perspective, but from what little creative work I have done I would say the big difference is programming is very logical, very precise, and creative work is very expressive, and very, very imprecise. Creative work really requires you to listen to how you feel about the final product, how it sounds, how it is experienced, while programming is really about being organized and correct. I suppose the…

And yet, we say that “programs are written for people to read.” Writing for people to read is not “very logical and very precise.” It’s “very expressive,” and sometimes, although the part the compiler reads is correct, the thing the human infers from the program is imprecise and expressive. Working with code teaches that code is experienced, too. We read a thing, go hunting for its downstream dependencies, learn othe…

> Writing for people to read is not “very logical and very precise.” It’s “very expressive,”

There’s a continuum between writing technical manuals and ‘Ulysses’, with airport-bookstand thrillers somewhere in between.

Re: Programming and Writing

#69

Post by proc0 » Fri, May 14, 2021, 8:40 PM UTC

> I believe programming, in this regard, can learn something from writing: when writing the first core of a new system, when the original creator is still alone, isolated, able to do anything, she should pretend that this first core is her only bullet. During the genesis of the system she should rewrite this primitive kernel again and again

This is a very subtle and interesting point. This notion of the 'primitive kernel' that is hard to change, is the problem of how much abstraction to invest in, at the beginning of a feature or project. It seems to always be a balance between doing what is needed for the immediate specifications, and doing what is needed for future reusability and extensibility of that same piece of code. In other words, how much should this piece of software be abstracted for future reusability?

It is tempting to think that highly abstracted code is overkill. However, abstracting code on the first introduction of a feature, allows for this "primitive kernel" to be as solid as possible, such that it doesn't need to change often. There is an illusion of doing too much work by considering all the use cases before needing them, but what I think really happens is that

*the longer you put off abstracting something (i.e. copying code instead) the more expensive the abstraction will be once you get to it.*

So the first abstraction, nicely put in the quote above, "During the genesis of the system she should rewrite this primitive kernel again and again", illustrates why it should be done right the first time around. It is cheaper to do so on the first try when nobody is using the abstraction. Compare this to a later time, a time when the kernel is already being used by lots of other components, now you have to take those use cases with their exceptions into account, making the process of abstracting more complicated and risky.

*NOT abstracting as much as possible, is setting the software up for an inevitable increase in complexity, and therefore cost in effort to reduce it.*

Summarizing: abstracting code on the first pass is avoiding the increase in cost of that same abstraction if you wait until there are multiple concrete cases of it. I suspect it's a function of how many concrete cases there are to abstract, multiplied by environment's stability (once it's shipped, abstracting gets even more difficult and costly).

Re: Programming and Writing

#70

Post by stakkur » Fri, May 14, 2021, 9:03 PM UTC

Having done both, in my experience the two have almost nothing in common, especially in process. Some of the most famous novels have no real structure at all, solve no problem, and don't adhere to any consistent rules of construction/grammar/style.

And: a 'successful' program is easy to spot; a 'successful' novel defies that, beyond the most superficial (and ultimately subjective) measures.