Live data from Hacker News

A significant amount of programming is done by superstition

utcc.utoronto.ca

71–80 of 214 posts

Re: A significant amount of programming is done by superstition

#71

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 erro…

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

It's interesting to code in large code bases. They end up getting to the point where no single person can ever understand the entire thing. It is usually at this point that things like Hungarian and strict coding guidelines really help. If you need an array of pointers to some kind of object, you can be reasonable certain that search will be able to find it.

Re: A significant amount of programming is done by superstition

#72
What that means is that if you're writing the system you want someone to do 'right' -- you better provide lots of good examples in the docs.

A 'good' example is one that you've actually tested for real to make sure it works, that follows the intended principles for the system in question, that meets actual use cases developers using it will have, etc.

A significant amount of software is released without good docs -- examples being just one part of good docs. So of course developers copy from the examples they can find.

Re: A significant amount of programming is done by superstition

#73

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 erro…

"copy and paste is the root of all evil."

Re: A significant amount of programming is done by superstition

#74
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…

Almost nobody can. Some people think they can, and charge forward with it, but rarely do they produce something that actually works. Usually, they bang on it and test it and cargo-cult it until it works, then convince themselves that it's from 'first principles'. Even if it were a common ability to produce engineering work from written design principles, I'm not certain that's what we want. Experimentation is the key…

[deleted]

Re: A significant amount of programming is done by superstition

#75
post #7

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…

Yeah, I don't really get what definition of "superstition" the author is intending here. It seems like "laziness" or "lack of rigor" would be more appropriate terms.

Traditional superstitions include not walking under a ladder, and throwing spilt salt over the left shoulder. "Lack of rigor" would apply to these but "laziness" would not.

Superstition connotes that an act is performed due to faith that it is beneficial or necessary, rather than an understanding of the underlying mechanism or controlled experiments to demonstrate the need.

Re: A significant amount of programming is done by superstition

#76
post #31

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.

Is the reward for getting a comment posted so quickly so great that you don't bother reading the article even when the price of making yourself look like a fool?

I did read it, there were quite a few comments before I even posted.

What he described was not superstition.

Re: A significant amount of programming is done by superstition

#77

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…

The term "blind faith" works, but may be a bit harsh.

Call it "trust", and it looks different.

Do I trust my OS to have a memory allocator that works and to protect processes from reading and writing each other's memory? Yes, but not totally.

Do I trust its more modern and complex APIs? Less so.

Do I trust code I copied from stackoverflow that has 100+ points? Yes, but even less so than I trust the complex or new corners of my OS. So, I read every line I copy. On the other hand, I am lazy, so if this gets to 1000+ lines, chances are I won't read every line. I will think a bit more about the trust issue, though.

Do I trust the documentation of the libraries shipping with my OS? More than stack overflow answers with 20-ish points, but certainly not completely.

Do I make assumptions about APIs? I try not to, but it is hard. There is lots of documentation where it is hard or impossible to find out what the code claims to do in edge conditions.

For example, in https://msdn.microsoft.com/en-us/library/352y4sff(v=vs.110)...., can one pass a null transaction? I wouldn't know, and the page doesn't tell me, so this afternoon, I wrote a conditional operator calling another constructor if transaction is null.

I did consider a "let's try it and assume it always works if it works once" approach, though. I also think many people do that ('if it compiles and runs, it must be valid C')

Re: A significant amount of programming is done by superstition

#78
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…

[deleted]

Re: A significant amount of programming is done by superstition

#79
Article: Reinvent the wheel, because if you just mount whatever wheels fit the axle they will inevitably work poorly for your purposes.

Wheels work just fine. Choose the best wheel from those available and tweak it as desired. Test it to make sure it doesn't shatter under too much weight. Apply and move on.

This pervading notion of "if you don't understand you shouldn't do it" is silly. Sure it is nice to understand, but it doesn't put food on the table. Sometimes it's just handy to use the gun as is and go shoot your dinner in the woods. You don't need to understand the formulation of gunpowder or rifling in order to use a gun properly for it's intended use.

Post reply on HN