I've always enjoyed what I call uncoding, which is taking a working piece of code and taking stuff away until things break, and examining how they break. It's really helped me understand what each piece does, and be more efficient when I'm writing it myself.
A significant amount of programming is done by superstition
41–50 of 214 posts
Re: A significant amount of programming is done by superstition
#42Earlier quoted context omitted.
I think this is more commonly called "cargo cult programming", defined by Wikipedia[1] as: "the ritual inclusion of code or program structures that serve no real purpose". [1] https://en.wikipedia.org/wiki/Cargo_cult_programming
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 applicable to that example. (They serve no purpose at the point in time when they're added by cargo-cultists but cause problems much later when someone/something assumes that they are actually meaningful.)
[1] http://utcc.utoronto.ca/~cks/space/blog/linux/SystemdAndSysV...
Re: A significant amount of programming is done by superstition
#43Earlier quoted context omitted.
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.
Nonsense. We test stuff all the time we don't understand "completely" (which is some kind of magical standard, as we obviously don't understand the universe completely, so the very atoms and molecules that the machine is made of are in some sense not well understood.) Certainty is the alchemist's stone of philosophy. People have done all kinds of interesting stuff while attempting the impossible: turning knowledge in…
"Evidence: most shipping code actually works."
The vast majority of time spent on software development is on bug fixing and on many projects the construction/coding defects make up more than half of all the defects.
Re: A significant amount of programming is done by superstition
#44I 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 think this is more commonly called "cargo cult programming", defined by Wikipedia[1] as: "the ritual inclusion of code or program structures that serve no real purpose". [1] https://en.wikipedia.org/wiki/Cargo_cult_programming
I think there's a significant distinction here to be made between "configuration" and "programming".
Do I copy/paste swaths of code that I don't understand and put them in my programs? No, absolutely not, because each line is one I can reason about and want to understand.
But do I copy/paste swaths of configuration files / init scripts / etc, without understanding the implications of every single configuration? Yes, absolutely, because the depth behind each of those options is often irrelevant to me. (until I discover otherwise late at night when an alarm goes off (!!))
I think it is important to distinguish these. I don't think any dev that's done ops work would claim they aren't guilty of the latter, but at the same time I think very few good devs ever, and I mean ever, do the first.
Re: A significant amount of programming is done by superstition
#45Earlier quoted context omitted.
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.
The first principles of computation are not the first principles of software development. A computer is not a Turing Machine: it is an electro-mechanical wrapper around the limited imitation of a Turing-like core, and that wrapper and the physical properties of the system put extreme limitations on what can or cannot be proven. Software development is a perfectly ordinary engineering activity, or should be (although…
As I said, I was only attempting to clarify the author's intent [in so far as I could divine it]. So perhaps your counter-argument might be better directed there.
Out of curiosity, if the first principles of software development are not based in mathematics, what do you believe are their basis and how does it differ from "folk wisdom" if we take "folk" to include communities of engineers rather than as merely pejorative?
Re: A significant amount of programming is done by superstition
#46I'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 to science. You have to observe, change, guess, run, observe, change, observe until you can successfully predict what will happen for each change you make. The scientific method is taught to everyone, even if most ignore it and skip steps. 'Guess/check' is the correct way to do real-world engineering and design, not pure-logic simulation, because we still don't know all the first principles.
Re: A significant amount of programming is done by superstition
#47A 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…
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.
Re: "buried behind a lot of clutter"
If your code has a lot of clutter it's usually telling you something about your design.
For readability a better way of handling it might be for the function could return a boolean instead of an int:
if (is_valid(param1, param2)) {
self documenting code and all that.
Re: A significant amount of programming is done by superstition
#48I've always enjoyed what I call uncoding, which is taking a working piece of code and taking stuff away until things break, and examining how they break. It's really helped me understand what each piece does, and be more efficient when I'm writing it myself.
Amusingly, that's also more or less how we've learned to understand the various functions of the different parts of the human brain. We don't know what it does until it's been removed/damaged.
Re: A significant amount of programming is done by superstition
#49A 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…
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) {
printf("\n\nYay, it worked!");
}
In higher level, modern languages you have even more, much more sophisticated tools for doing this kind of things.
Re: A significant amount of programming is done by superstition
#50even 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.