21–30 of 214 posts
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.
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 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".
only when i get stuck do i engage critical thinking. maybe this has been to my detriment.
very often i notice myself and colleagues making up nonsense explanations for why c++ behaves the way it does without any real basis other than intuition and truthiness.
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…
if(0 == very_long_function_name_here(param1, param2)) {
if(very_long_function_name_here(param1, param2) == 0) {
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.
Software development is a perfectly ordinary engineering activity, or should be (although it is mostly done by non-engineers), and the same standards should apply. No mechanical engineer or electrical engineer has ever shipped a "provably correct" machine. They have shipped machines that conform to best practices, including heuristic analyses of MTBF and so on.