Code is not Literature • Hacker News Board

Re: Code is not Literature

#11

Post by ironparlance » Mon, Jan 20, 2014, 10:02 PM UTC

Reading code is regularly useful for discovering language specific idioms/patterns about efficiencies, safety and clarity. That is why you should try to read well written code for learning. Reading poorly written code for any kind of edification is a waste of time.

In this sense code can be used like a well written novel can be used by an aspiring novelist -- to better learn the craft.

Re: Code is not Literature

#12

Post by shalmanese » Mon, Jan 20, 2014, 10:04 PM UTC

thangalin wrote: post #5

Why do we still embed natural language descriptions of source code (i.e., the reason why a line of code was written) within the source code to the exclusion of intrinsically linked separate documents? http://i.stack.imgur.com/JlUiE.png The potential advantages include: - More source code and more documentation on the screen(s) at once - Ability to edit documentation independently of source code (regardless of languag…

Because we're stuck in a tyranny of flat text files as a representation of code.

There have been countless proposals over the years for some kind of richer file format for representing code and they have all been busts because so much of our tooling, assumptions, interoperability and culture is centered on flat text code that it's proven impossible thus far to switch.

Re: Code is not Literature

#13

Post by thedudemabry » Mon, Jan 20, 2014, 10:07 PM UTC

scottcha wrote: post #9

I agree with the author that code may not be literature. Taken from the opposite line of reasoning there have been movements in the past to make literature more like code. Specifically I thinking of Oulipo (which included Calvino as probably the most famous) on bringing new structures to literature including some generative ones which could be thought of as programming or combinatorics. http://en.wikipedia.org/wiki/O…

A great group blog that keeps tabs on interactive and generative literature is http://grandtextauto.org/. I highly recommend it.

I wonder how blurred the lines can truly become between code and literature, though. If a piece of code is primarily intended to be read and discussed, does that make it literature?

Re: Code is not Literature

#14

Post by [deleted] » Mon, Jan 20, 2014, 10:07 PM UTC

shalmanese wrote: post #12

thangalin wrote: post #5

Why do we still embed natural language descriptions of source code (i.e., the reason why a line of code was written) within the source code to the exclusion of intrinsically linked separate documents? http://i.stack.imgur.com/JlUiE.png The potential advantages include: - More source code and more documentation on the screen(s) at once - Ability to edit documentation independently of source code (regardless of languag…

Because we're stuck in a tyranny of flat text files as a representation of code. There have been countless proposals over the years for some kind of richer file format for representing code and they have all been busts because so much of our tooling, assumptions, interoperability and culture is centered on flat text code that it's proven impossible thus far to switch.

[deleted]

Re: Code is not Literature

#15

Post by mattlutze » Mon, Jan 20, 2014, 10:07 PM UTC

thangalin wrote: post #5

Why do we still embed natural language descriptions of source code (i.e., the reason why a line of code was written) within the source code to the exclusion of intrinsically linked separate documents? http://i.stack.imgur.com/JlUiE.png The potential advantages include: - More source code and more documentation on the screen(s) at once - Ability to edit documentation independently of source code (regardless of languag…

- The developer is usually the best person to write down the reasons a line was written. - It's quicker to add an inline note than to switch context to a documentation panel. - It's more complex to have to link a line to a documentation blob as in the example. - A lot of people don't use IDEs; something like that would be necessary given the lower-level work that would need to go on with timestamping and linking code and documentation bits.

"Good enough" principles make inline comments a clear choice, I'd think. Plus, seeing the comment in context may provide cognitive benefits; the comment and code block grouped in the same space helps recognize and associate their linkage in a way cross-highlighting one or the other may not.

Re: Code is not Literature

#16

Post by scott_s » Mon, Jan 20, 2014, 10:09 PM UTC

Every time I have a serious question about how something works in the Linux kernel, I use it as an excuse to do a dive into the code: http://lxr.free-electrons.com/

I still look through other sources, including man pages, books and a lot of googling. But sometimes I just want to see what it is I'm dealing with. I do this with all code bases I deal with. I think it's a good practice to get into.

Re: Code is not Literature

#17

Post by krapp » Mon, Jan 20, 2014, 10:14 PM UTC

shalmanese wrote: post #12

thangalin wrote: post #5

Why do we still embed natural language descriptions of source code (i.e., the reason why a line of code was written) within the source code to the exclusion of intrinsically linked separate documents? http://i.stack.imgur.com/JlUiE.png The potential advantages include: - More source code and more documentation on the screen(s) at once - Ability to edit documentation independently of source code (regardless of languag…

Because we're stuck in a tyranny of flat text files as a representation of code. There have been countless proposals over the years for some kind of richer file format for representing code and they have all been busts because so much of our tooling, assumptions, interoperability and culture is centered on flat text code that it's proven impossible thus far to switch.

But text files are easy to generate, easy to edit, and simple to read. What alternatives are there which remain language and tool agnostic?

Re: Code is not Literature

#18

Post by thebear » Mon, Jan 20, 2014, 10:18 PM UTC

Perhaps the most important insight to be gained from this article is Abelson's statement that "a lot of times you crud up a program to make it finally work and do all of the things that you need it to do, so there’s a lot of extraneous stuff around there that isn’t the core idea." There is an old blog entry by Joel Spolski that elaborates on this phenomenon:

http://www.joelonsoftware.com/articles/fog0000000069.html

Re: Code is not Literature

#19

Post by sp332 » Mon, Jan 20, 2014, 10:21 PM UTC

krapp wrote: post #17

shalmanese wrote: post #12

Earlier quoted context omitted.

Because we're stuck in a tyranny of flat text files as a representation of code. There have been countless proposals over the years for some kind of richer file format for representing code and they have all been busts because so much of our tooling, assumptions, interoperability and culture is centered on flat text code that it's proven impossible thus far to switch.

But text files are easy to generate, easy to edit, and simple to read. What alternatives are there which remain language and tool agnostic?

I can make a file format as tool-agnostic as you like, if it doesn't actually have to have any features.

Re: Code is not Literature

#20

Post by thebear » Mon, Jan 20, 2014, 10:21 PM UTC

I would be interested to know what the OP thinks about stepping through code as opposed to reading it. To me, reading code and stepping through it in a debugger are two complimentary ways of understanding it. I call those the static and the dynamic way of viewing code.