The main problem I see is that code is read left to right, top to bottom (for the most part) but it is rarely, if ever, written that way. The order that decisions are made is almost as important as the decisions themselves. But, we lose almost all of that order or 'context'. Worse, although we can place comments in the code, we cannot attach comments to the evolution of code. Evolutional comments could describe why things are changing in the proper context and make reading code a lot easier.
Code is not Literature
41–50 of 88 posts
Re: Code is not Literature
#42Earlier quoted context omitted.
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.
Being tool-agnostic is a feature. The most important feature.
If there are other known features that are more important, they would have taken off by now.
Re: Code is not Literature
#43Asking people what they've read "just for the heck of it" is the wrong question, because code is not linear , so it's extremely ungainly to read without purpose. But as soon as the skilled code reader has a purpose in mind -- a question to answer -- he or she can rapidly find a meaningful narrative. Put into that context, programmers read code constantly, and the more they read the better they get. So I don't like th…
Exactly. I think that asking "what repos have you cloned just so that you could look at something, not intending on actually building or using that particular code" is probably roughly analogous to asking "what Wikipedia pages have you read recently" I frequently do both of those for the same reasons. I might pull up the wikipedia page for the Apollo Lunar Module because I suddenly realize that I don't know how the R…
You just made me realize that github needs better search. I like the presentation on github but, without git grep, I just pull it local and read from there.
Re: Code is not Literature
#44Earlier 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?
You could, ya know, just write code that's easy to understand.
Re: Code is not Literature
#45Earlier quoted context omitted.
Exactly. I think that asking "what repos have you cloned just so that you could look at something, not intending on actually building or using that particular code" is probably roughly analogous to asking "what Wikipedia pages have you read recently" I frequently do both of those for the same reasons. I might pull up the wikipedia page for the Apollo Lunar Module because I suddenly realize that I don't know how the R…
You just made me realize that github needs better search. I like the presentation on github but, without git grep, I just pull it local and read from there.
Where I work we have a well-maintained OpenGrok instance which works great.
I still end up pulling down the repo and using grep 90% of the time. OpenGrok is what I use when I don't even know which repo I'm interested in.
Re: Code is not Literature
#46Asking people what they've read "just for the heck of it" is the wrong question, because code is not linear , so it's extremely ungainly to read without purpose. But as soon as the skilled code reader has a purpose in mind -- a question to answer -- he or she can rapidly find a meaningful narrative. Put into that context, programmers read code constantly, and the more they read the better they get. So I don't like th…
gratuitous "I agree" post :-)
Re: Code is not Literature
#47Earlier quoted context omitted.
But text files are easy to generate, easy to edit, and simple to read. What alternatives are there which remain language and tool agnostic?
You could, ya know, just write code that's easy to understand.
I try to, but that's beside the point. What passes for 'easy to understand' when you move past 'flat text files as a representation of code' and how is it better?
Re: Code is not Literature
#48I think the author has a somewhat limited definition of “literature”, though he ultimately comes to the right conclusion that code must be “studied”, not “read”. It’s true, code is typically less linear than a pulp novel, but other types of literature are also involved, with layered meanings, which must be examined carefully, with reference material handy, and lots of flipping back and forth between sections. For ins…
Have you ever had a reason to read just part of a book? Pages 236-241 of Moby Dick, with no intention to ever read the rest? That seems to be a crucial difference between the two activities.
Re: Code is not Literature
#49Earlier quoted context omitted.
You could, ya know, just write code that's easy to understand.
I try to, but that's beside the point. What passes for 'easy to understand' when you move past 'flat text files as a representation of code' and how is it better?
Good naming practice. Either pull each line of non-trivial code out into it's own method, or assign the output of the code to a variable that tells you what it's doing.
If you find yourself repeating an assignment, pull it out into a function and remove the duplication.
Rinse and repeat until everything in the file is assigned to a descriptive function or variable. Doing this with someone else's code gives you a feel for how to do it with your own.
Re: Code is not Literature
#50I am not English major, but I am pretty sure that the idea of becoming a writer by reading pieces of other people's texts is wrong. This is simply not enough. There is a "second component" in good writing, and it is not just about language usage.
One could read Selinger or Pamuk or Sartre or Hesse, to realize that this second component is much more important, while masters like Nabokov whose speciality is playing with words might show you that wording is also important.)
The transition from reading to writing ones own texts, not imitating or copy pasting is also not clear, and, of course, one never could become a good writer only by excessive reading. Writing and speaking are different cognitive tasks from reading or listening.
So what? Reading of good code is important, it teaches style, how to be brief, concise, precise. But where to find the good code? Well, the recursive list functions in Scheme are worth reading. Some parts of Haskell Prelude are worth reading, some macros of Common Lisp, etc.
The code of "the top writers" are worth reading. Code from PAIP or On Lisp or SICP are obvious examples, while some code, like from Practical CL which is mostly a mechanical translation of OO stuff only adds more confusion.
So, reading "good" code is still the must, the same way that reading Catcher In The Rye or Zen And Art Of Motorcycle Maintenance or Atlas Shrugged is still the must.
But programming is about writing, which means expressing ones own ideas and realizations and understanding, so one must have these in the first place.
In this sense programming is like writing a poetry - it must emerge and form in ones mind before it could be written down. The best poetry is written exactly like this - committed to the paper suddenly as it emerges, without any later changes.
This reflects the process of "emergence" of ideas or profs in a mind of scientists who are continuing to persue a problem for years - suddenly it is here, as if it came from subconscious. It seems that the best code, like these classic Lisp procedures or parts of Prelude has been written this way.
Of course, reading Java is as meaningless as reading graphomans or some lame and lenthy political pamphlet in a third-rate newspaper.)