Live data from Hacker News

"My current theory is that programming is quite literally writing."

ask.slashdot.org

191–199 of 199 posts

Re: "My current theory is that programming is quite literally writing."

#191
post #44

Earlier quoted context omitted.

Is it? In prose you say "first he rushed to the exit door, then he leaped down the stairs, finally he ran to get the train" while in programming it is better to write socket.close(); window.close(); file.close()

You don't want to write one paragraph like a romance novel, another like a patent application then a third like an advert.

Some artists do. Writing is an art, and breaking rules in art is not the same as breaking rules in programming.

If not, you just say "consistency is good" which also applies to architecture, painting and so on.

Re: "My current theory is that programming is quite literally writing."

#192
post #16

Most code sucks because we have the fluency equivalent of 3 year olds trying to write a novel. Let's get a little more specific... Most code sucks because the programmer: - didn't name his variables what the really were - didn't understand variable state - didn't understand variable scope - didn't understand the basic concepts of iteration - didn't understand any of the algorithms he needed - wrote the same lines of…

I think that the point of original post is precisely that many do know and understand all the things you listed, but for some reason fail to apply them on the job.

Re: "My current theory is that programming is quite literally writing."

#193
post #68
post #16

Most code sucks because we have the fluency equivalent of 3 year olds trying to write a novel. Let's get a little more specific... Most code sucks because the programmer: - didn't name his variables what the really were - didn't understand variable state - didn't understand variable scope - didn't understand the basic concepts of iteration - didn't understand any of the algorithms he needed - wrote the same lines of…

I think you can check off everything on this list and still write inscrutable code. The worst code I've seen is code that was written so that only one person understands what's happening -- the author. Typically the code has too many branches and ridiculous call stacks. The writing analog is a run-on sentence. This usually happens when the programmer at fault is really smart but still hasn't learned that at some poin…

This problem is hard to solve.

It is not in the interest of the programmer to allow others to understand his code. That would make him easily replaceable. I know quite a few consultants who write like that on purpose and secure their jobs this way.

Programmers are also not rewarded for clean code. They are rewarded for quickly delivered code. Beautiful code that is delivered two weeks too late is usually a bad idea. This is business logic.

It is easy to measure, how long it takes a programmer to develop code. It is much harder to measure, how much time is wasted to maintain badly written code.

Much speaks against writing clean code, little is in favour. The only persons interested in this are later maintainers and academics.

Lets face it: whats wrong with code that is a bit messy but does its job correct and quick? If the author himself has to edit it and does not understand it anymore, then he/she will refactor. If there is no need to touch this code because it does its job, who cares? If the original author is already gone and there was no time to make someone else familiar with his code and style, think about how people are treated in your company and refactor management instead of code.

Re: "My current theory is that programming is quite literally writing."

#194
I don't think that I can agree with the op on slashdot.

Programming is not about knowing lots of words or grammar. It is about getting the thoughts clearly structured and understanding quickly what a problem is really about.

THIS is quite the same problem as writing text. But, IMHO, the author approached this as someone who does not know how to write text, too. Its not about ingenuous choice of words and correct application of grammar. It is about clarity of understanding the problem and then find a solution how to get to the point clearly and quickly.

If a solution is in the mind, 70% of the way is gone. Then it is important not to give up unless this idea is on paper in the same shape as it was in the head before. So I think the analogy is a good one, but the op has not necessarily found the reasons why.

Re: "My current theory is that programming is quite literally writing."

#195
post #148
post #144

Earlier quoted context omitted.

Just curious, is that taken from an actual language? Because I've wanted a feature like that for ages.

It exists in Ruby: [socket, window, file].each{|item| item.close()} http://codepad.org/GqNp94Iw It sort-of exists in Lisp-inspired languages (anything from Arc to Lua to Io) with appropriate boilerplate, for example: function apply(tbl, func) for key, val in ipairs(tbl) do func(val) end end apply({socket, window, file}, function (item) item.close() end) http://codepad.org/SNWO1Y6K

It'll work in JavaScript, too:

   [socket,window,file].forEach(function(o){o['close']();});

Re: "My current theory is that programming is quite literally writing."

#196
Of COURSE. Why would anyone think anything else?

For more, let's start with source code. Suppose we have source code line

     a = b*c
Reading this line, we want to know what it does and check that it's correct. So, we need to know what the line 'means'.

But, we conclude that

     a = b*c
doesn't really mean anything.

Of course if we saw

     F = m*a
we might guess that the variable names were mnemonic and guess Newton's second law that force equals mass times acceleration. Okay, now we know what the line means and can check if it's correct.

Okay, we are beginning to see:

A line of code such as

     a = b*c
doesn't mean anything. So, we have nothing to read and no way to check. So, we don't have anything.

We could write

     F = m*a
and begin to guess what this means. But we are still in trouble: We still have no good way to communicate meaning to permit understanding or checking.

So, we have to ask,

     F = m*a
came from physics books, and what did those books do? Well, they wrote in a natural language, say, English. Always, an equation such as

     F = m*a
was just an abbreviation of what was said in English. And, in particular, from the English there was no question about the meaning of each of the variables.

Net, math, and science with math, are written in complete sentences in a natural language. The variables are all clearly defined, discussed, explained, etc. At no time is an algebraic expression of such variables regarded as a substitute for the natural language. Take a physics book, throwout the English and leave just the equations, and will have nothing.

Physics and math understand; so far computing does not.

So computing tries to write

     force = mass*acceleration
or some such and omit the English. For simple things, can get by this way. Otherwise, this approach is hopeless, at best presents the reader a puzzle problem of guessing.

The matter of using mnemonic variable names as parts of speech in English is a grand mistake but common in writing in computer science. Bummer.

Bluntly computing has not figured out that there is so far just one way to communicate meaning: Use complete sentences in a natural language. Period. That's all we've got. But computing has fooled itself into believing that algebraic expressions with mnemonic variable names form a 'new language' that, in computer source code, can provide the needed meaning without a natural language. Wrong.

For

     F = m*a
the situation is simple. But significant source code has much more complicated cases of 'meaning' to communicate. Again, computing tries to get by, say, using a big library of software classes, relying the mnemonic spelling of the classes and members and the documentation of the classes. In simple cases, can get by this way. But fundamentally, for some complicated code, the meaning, workings, etc. just must be explained, and there's only one way to do this: Complete sentences.

So, writing these complete sentences to communicate meaning effectively is 'writing'.

Done!

Re: "My current theory is that programming is quite literally writing."

#197
post #142

Earlier quoted context omitted.

I get tired of the "blame the shitty programmers" line of thought. We're all shitty programmers. Yet we all "understand variable scope" and "what the code was supposed to do." Some of us have such a large ego that we think it's others. No, Sancho. It's you. Code gets complex as hell very quickly. If it was building a house, it would be built in a week and architected on the fly. The person mixing the concrete, who ha…

I agree that we are too slow to point the blame at ourselves. It's healthy to be self-critical. That said, there are programmers who are legitimately lacking both in basic skills and desire to attain those skills. It's orthogonal to the problem you're talking about, but these people do exist, and they're not as uncommon as one might hope. I can teach the difference between pointers and references; I can't teach you t…

This. I have ascended to a managerial position a couple of years ago, rising from the ranks to steer what used to by a group of my peers. A lot of cruft had been ailing the team for years, but one guy stood out: he had been fired, rehired and now acted as if there was nothing he could do to damage his standing in the team. When we were peers, it bothered me; when I became his boss, I really tried to sway his attention into the product, into learning, into becoming more than a "drag this out of the component box" programmer.

Needless to say, it failed. The guy was irreparably lazy, and trying to get him excited about building the things we are fortunate enough to get paid to build only made him try to put me under a bus when he got the chance. I had to let him go, and have slept better ever since.

Re: "My current theory is that programming is quite literally writing."

#198
post #148

Earlier quoted context omitted.

It exists in Ruby: [socket, window, file].each{|item| item.close()} http://codepad.org/GqNp94Iw It sort-of exists in Lisp-inspired languages (anything from Arc to Lua to Io) with appropriate boilerplate, for example: function apply(tbl, func) for key, val in ipairs(tbl) do func(val) end end apply({socket, window, file}, function (item) item.close() end) http://codepad.org/SNWO1Y6K

It'll work in JavaScript, too: [socket,window,file].forEach(function(o){o['close']();});

And all of these ways are longer and less clear than the original. Better to write code like Hemingway than like Proust.
Post reply on HN