A significant amount of programming is done by superstition • Hacker News Board

Re: A significant amount of programming is done by superstition

#11

Post by rjbwork » Wed, Mar 25, 2015, 9:18 PM UTC

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, which generate this byte code, which generates this JITed assembly code, which generates this machine code, which generates these executions of instructions on the processor and accesses these memories, which invokes these manipulations of these gates and flip flops on this particular part of the ALU".

Doing so would be the mark of an unproductive madman.

Re: A significant amount of programming is done by superstition

#12

Post by amyjess » Wed, Mar 25, 2015, 9:18 PM UTC

nicpottier wrote: post #5

I actually really like the content of the article, but I'm not convinced superstition is the right word here. Yes, absolutely I have copied an init script / makefile or whatnot and if it worked after I tweaked it then I went on my business. But I didn't use it as is because of superstition, but rather because it now worked I believed it correct. Yes, quite often that came without a perfect knowledge of every single o…

> Yes, absolutely I have copied an init script / makefile or whatnot and if it worked after I tweaked it then I went on my business. But I didn't use it as is because of superstition, but rather because it now worked I believed it correct.

That, plus the whole "ugh, I don't want to have to write all this boilerplate from scratch".

Initscripts are mostly boilerplate, and it's just plain tedious do to anything other than copy/paste what you know works.

Re: A significant amount of programming is done by superstition

#13

Post by rbanffy » Wed, Mar 25, 2015, 9:19 PM UTC

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.

Re: A significant amount of programming is done by superstition

#14

Post by anon4 » Wed, Mar 25, 2015, 9:21 PM UTC

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 of anything and following that write working code on my first try. Well, obviously I've been able to do it for trivial things, like after the Python 2->3 switch when map/filter/range started returning iterables instead of lists, simply being told "map/filter/range/etc. now return an iterable and not a list" is sufficient to explain the change in behaviour, but that's only because I know all the concepts behind it. You could say the explanation is only one level removed from my intuitive knowledge. Things start getting exponentially harder the more levels removed they get, i.e. if it's a new concept explained using new concepts previously defined, but for which I have no intuitive knowledge what they mean.

Re: A significant amount of programming is done by superstition

#15

Post by ggchappell » Wed, Mar 25, 2015, 9:21 PM UTC

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…

That's an interesting way of putting it.

The issue is that we all have our own (more or less completely undocumented) abstractions that we mentally put on top of whatever language/library we're using. And sometimes these mental abstractions are out of sync with reality.

Re: A significant amount of programming is done by superstition

#16

Post by depsypher » Wed, Mar 25, 2015, 9:23 PM UTC

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 consider. In any case, I suspect most uses of this construct in languages like Java fall into the "superstition" category, where the people using it aren't really considering why.

Re: A significant amount of programming is done by superstition

#17

Post by nightski » Wed, Mar 25, 2015, 9:25 PM UTC

I am sorry, the only reason I have been as successful as I have been is because I am not superstitious at all. I know that if something goes wrong, there is always a logical explanation for it. The quicker I can find that logical explanation the better I am doing.

I don't think I am alone in this.

Re: A significant amount of programming is done by superstition

#18

Post by brudgers » Wed, Mar 25, 2015, 9:27 PM UTC

nicpottier wrote: post #5

I actually really like the content of the article, but I'm not convinced superstition is the right word here. Yes, absolutely I have copied an init script / makefile or whatnot and if it worked after I tweaked it then I went on my business. But I didn't use it as is because of superstition, but rather because it now worked I believed it correct. Yes, quite often that came without a perfect knowledge of every single o…

I'm not picking at what you do just trying to explain the author's context.

The first principles of computation are mathematical and believing something to be correct is not the standard. Proving is the mathematical standard. I take the author's point of reference to be more formal processes than the ordinary practical programming practices they criticize.

Re: A significant amount of programming is done by superstition

#19

Post by lectrick » Wed, Mar 25, 2015, 9:28 PM UTC

nightski wrote: post #17

I am sorry, the only reason I have been as successful as I have been is because I am not superstitious at all. I know that if something goes wrong, there is always a logical explanation for it. The quicker I can find that logical explanation the better I am doing. I don't think I am alone in this.

> The quicker I can find that logical explanation

The quicker your test suite can find that logical explanation... ;)

Re: A significant amount of programming is done by superstition

#20

Post by dandelany » Wed, Mar 25, 2015, 9:28 PM UTC

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".