Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A significant amount of programming is done by superstition

utcc.utoronto.ca

Post reply on HN
Print view View original

51–60 of 214 posts

Re: A significant amount of programming is done by superstition

#51

Post by mreiland »

ptx wrote: post #42
mreiland wrote: post #36

Earlier quoted context omitted.

not applicable either, the code and program structures serve a purpose and the article specifically described removing parts that are not applicable.

The part about how people "copied an existing init script or thought ... that init scripts needed LSB headers that looked like this" sounded like it to me. I didn't initially manage to follow the right sequence of links to find the example[1], but now that I have, the context seems to be that "System V init ignores all of these" (the parts people copied without understanding), so the description still looks applicabl…

In other words, you're willing to try and try to find a way to convince yourself you're not wrong despite having it explained to you already.

good day.

Re: A significant amount of programming is done by superstition

#52

Post by brudgers »

frandroid wrote: post #10

The problem here is that if it works, how is it superstition? When I knock on wood or throw salt over my shoulder, I don't have a way of verifying that I've averted disaster. However, I can test the code I don't understand, and if it does what it says it does (or does what I want it to do, since that's why I've selected it in the first place), then we're a step removed from superstition. There might be unintended con…

The problem here is that if it works, how is it superstition?

Consider Bertrand Russell's Chicken:

The man who has fed the chicken every day throughout its life at last wrings its neck instead, showing that more refined views as to the uniformity of nature would have been useful to the chicken. [1]

Sometimes things working but not in the way we imagine they work is worse than them not working at all.

[1]: http://www.ditext.com/russell/rus6.html

Re: A significant amount of programming is done by superstition

#53

Post by betenoire »

dandelany wrote: post #20
rjbwork wrote: post #11

I think a better title might be "A vast majority of programming is done at a level of abstraction that this author is slightly uncomfortable with". If you work in Java or Ruby or Python or C#, or even C++ all day with say, an IoC container for argument's sake, you're certainly not constantly thinking "okay this interface will be resolved to this type, which has these dependencies which will be resovled to these types…

I don't think this is about abstraction. Abstraction implies having a deep understanding of the problem domain and encapsulating it in such a way that the implementation details can be ignored and the domain can be reasoned about at a higher level. I think a better title would be "A significant amount of (shipped, so-called production-quality) code is not fully understood by its authors".

I agree: layers of something != abstraction

Re: A significant amount of programming is done by superstition

#54

Post by ericb »

klibertp wrote: post #49
Peaker wrote: post #27

Earlier quoted context omitted.

A lot of us find Yoda conditions easier to read: if(0 == very_long_function_name_here(param1, param2)) { Tells me a lot after I've read a little of the line, whereas: if(very_long_function_name_here(param1, param2) == 0) { Makes the == 0 part easy to miss, and buried behind a lot of clutter.

Why would you ever have a function with a name that long in the first place? Also, there are many more ways of dealing with readability: try different formatting and indentation rules, wrap lines manually where you think it makes sense and so on. As for your example, even the lowly C let's you do something like this: int (*short_name)(int) = &veeeeery_long_and_ugly_and_unnecessary_function; if(short_name(1) == 2) { p…

Explicit function naming requires slightly longer function names, but you can actually read a program and get a sense of what is happening. Give me long function names over short ones any day. In my book, 5 words is a little long, but not out of bounds.

Re: A significant amount of programming is done by superstition

#55

Post by Lewton »

depsypher wrote: post #16

A nice example of this is yoda expressions in, say Java. The initial reasoning for them was to prevent accidental assignment, since a C/C++ compiler will complain on this: if (null = x) but not on this: if (x = null) In Java, neither is allowed, so the whole yoda construct is almost pointless. The exception is boolean assignment which does benefit from this idiom, but the loss in readability is a trade off to conside…

Yoda expressions are still useful in Java when we're talking strings.

someString.equals("someString") vs "someString".equals(someString)

Re: A significant amount of programming is done by superstition

#56

Post by klibertp »

rbanffy wrote: post #13
frandroid wrote: post #10

The problem here is that if it works, how is it superstition? When I knock on wood or throw salt over my shoulder, I don't have a way of verifying that I've averted disaster. However, I can test the code I don't understand, and if it does what it says it does (or does what I want it to do, since that's why I've selected it in the first place), then we're a step removed from superstition. There might be unintended con…

If you do not understand the code, you cannot say you tested it. It may have corner cases you did not anticipate. The test may be incomplete and only cover what you think the program should do.

Tests are always like this, no matter how well you know the code. A test that covers every possible case is called a proof.

Re: A significant amount of programming is done by superstition

#57

Post by eric_h »

eric_h wrote: post #50
dsugarman wrote: post #29

even with code I write myself, I can't remember the line by line implementation on the entire code base. To be honest I often forget implementation details on code I wrote last week.

Ditto. When a coworker asks me about implementation details of some code a wrote just a few weeks ago, my first answer is always "I haven't a fucking clue". Then I scan the code in question and it all comes rushing back.

I should add that the extent to "it all comes rushing back" is directly and inversely correlated with how long ago I wrote it, and positively correlated with how interesting/difficult the problem was to solve at the time.

Also, almost every time I go back to review code I wrote more than a year ago, my first reaction is "jesus, that's a stupid pattern/implementation. Why did I do it that way?". I've been a professional developer for about 12 years now and I suspect that will never change.

Re: A significant amount of programming is done by superstition

#58

Post by Sir_Substance »

betenoire wrote: post #53
dandelany wrote: post #20

Earlier quoted context omitted.

I don't think this is about abstraction. Abstraction implies having a deep understanding of the problem domain and encapsulating it in such a way that the implementation details can be ignored and the domain can be reasoned about at a higher level. I think a better title would be "A significant amount of (shipped, so-called production-quality) code is not fully understood by its authors".

I agree: layers of something != abstraction

I might keep that one.

Re: A significant amount of programming is done by superstition

#59

Post by Gravityloss »

anon4 wrote: post #14

I'll have to admit something about myself -- I've never been able to learn how to do anything from just reading its first principles. I need to have a working example that I can then adapt and change and observe changes in the result. This has been especially true in programming. I've been writing programs in some capacity for 18 years now and not once in that time have I been able to simply read the reference manual…

Gall's law is related to this.

I think it's reasonable that people want to create software components that have been proven to work and then just forget about their internal details and copy-pas... apply them.

It's also what Bret Victor has been getting at. Very often the component's input-output mapping is much more relevant than implementation details. And you can get a feel for that by fiddling with the components.

Re: A significant amount of programming is done by superstition

#60

Post by copsarebastards »

I'm surprised by the number of people who don't see this as a problem.

I've worked pretty recently as the most senior developer on a team, and I saw tons of issues caused by copy/pasted code. It results in a lot of issues. Subtle bugs around `==` versus `===` in JavaScript, unecessary variables that obfuscate the code, Python that isn't Pythonic, C that was written as an example and therefore doesn't include the error handling that is constantly necessary in C (how many C examples check the return value of malloc?).

The biggest problem, I think, is that often you end up with 10 different ways to solve the same problem in the code because instead of looking at the existing code, people Googled for a solution with subtly different keywords than the previous person and found a different blogger. This kind of duplication is very hard to identify and remove, and this does cause bugs.

Of course a more experienced developer can work around these issues, but a more experienced developer also knows off the top of their head how to write the code themselves and usually does it.

Post reply on HN