Live data from Hacker News

A significant amount of programming is done by superstition

utcc.utoronto.ca

131–140 of 214 posts

Re: A significant amount of programming is done by superstition

#131

Earlier quoted context omitted.

Programming is a branch of engineering. Very little programming is done by proof; It's done by experimentation, debugger, and tests are human-reasoned and hopefully cover all codepaths and critical junctures (for every x > 0, you test x=1, x=0, x=-1). Proof is of critical importance - It's how you find those junctures, for example, how you optimize, how you design and how you reason about runtime, etc. But programmin…

Reminds me of the famous Knuth quote: > Beware of bugs in the above code; I have only proved it correct, not tried it. Deep thinking and mathematical proofs are tremendously useful when thinking about a well-defined and scoped problem at a more or less fixed level of abstraction. The problem with software engineering is that in practice all abstractions are leaky, and so you inevitably find yourself dealing with issu…

because it's simply not cost effective for the majority of software.

That's a great point. We utilize best practices, like automated tests, to narrow the gap between pure experimentation and mathematical proof. Proofs in most code would be difficult to impossible because most of use libraries that use other libraries, etc., so we just do the best we can given the time and monetary constraints that we have.

Re: A significant amount of programming is done by superstition

#132

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…

>doesn't include the error handling that is constantly necessary in C

I mean, I'm sure there are some cases, but how many C programs are capable of gracefully recovering from a malloc failure? Probably very few. If the program is going to crash anyway...

Re: A significant amount of programming is done by superstition

#133

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…

[deleted]

Re: A significant amount of programming is done by superstition

#134
post #119

Earlier quoted context omitted.

> it's pretty obvious that a couple of lines of code, showing how to do the work is better documentation than complete list of possible flags and parameters with no examples whatsoever. So no wonder people are reading stackoverflow instead of man-pages. And so on. the best manpage is a man page with a nice EXAMPLES section you can grep to quickly. though the permutations offered by many programs prohibit all bases be…

http://bropages.org to the rescue!

Thanks for reminding me why I hate ruby. Nothing against the language, it's the garbage dump of the software community misfits since it left Japan.

bro.

Re: A significant amount of programming is done by superstition

#135
post #68

Earlier quoted context omitted.

"A significant amount of (shipped, so-called production-quality) code is not fully understood by its authors" Of course. Time spent fully understanding the code before it's shipped is time that it's not shipped. This is sort of a Gresham's-Law situation, where "bad code drives out good code". The code that is fully tested & debugged with all situations understood isn't available to the user at first. As a result, the…

Anyone can build a bridge that stands up, but only an engineer can build a bridge that barely stands up. Good Enough is our main design goal. Anything more than good enough means you're wasting resources.

This sounds like Engineering, but be aware that in mechanical engineering the requirements are well-defined for materials and load. Consider the famous bridge resonance problem and you will see why wind resonance is now a required subject for structural engineering.

ME has an advantage over CSE in this regard because in CS the requirements are usually very poorly stated. About the best and most rigorous requirements you get are from mathematicans, but most devs and managers now certainly view that as wasting resources.

To make not to fine a point of this, I always like to turn to Alan Kay's comparison: TCP/IP vs the web. When was the last time any human technology like TCP/IP scaled so well and so invisibly, it's like air we breathe without even thinking about it. The web in contrast was the work of rank amateurs.

Alas, mathematics is really the "good enough" standard we in CS should strive for just like physics is the "good enough" standard behind ME and EE. Unfortunately as CS opened to the mainstream, I think a deep fear of mathematics led us to view this as "over engineering" even when it wasn't. The results are that the majority of the web is woefully underengineered, requiring far more money and time for inferior products.

We know they are inferior, because even the simplest gui application has more consistency than a web variation of it. And that's what marketing constantly compares things too when they can't understand why the web sucks as much as it does.

"Good Enough"? Please! For the last 20 years we haven't even come close!

Re: A significant amount of programming is done by superstition

#136
I'm a proud cargo culter.

Truth of the matter is you can't just stare at a man page or textbook all day and try to understand, then code. You'll code some mess you don't fully understand, sure, but later on you'll come back and either realize it was wrong and fix it, or you'll understand why it was right. But you will eventually understand.

The people trying to understand it will have gotten nowhere in the mean time.

Re: A significant amount of programming is done by superstition

#137
post #31

Earlier quoted context omitted.

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.

Indeed, what described was not superstition; there doesn't appear to be an exact word for what he was talking about (cargo cult is perhaps closer but not quite right), so it was a fuzzy match.

What you responded to, however, was superstition and as a result your comment had basically nothing to do with the article. I hope you can forgive my misunderstanding. :)

Re: A significant amount of programming is done by superstition

#138
post #128

Earlier quoted context omitted.

> Anyone can build a bridge that stands up, but only an engineer can build a bridge that barely stands up. That's a nice quip but once you cross spans of 5 meters or so you'll find out that that is a lot harder than it seems, especially for non-trivial loads. The joke of course refers to the fact that to build any structure that has to be both safe and economical is hard but please don't make it seem as if building b…

Jacquesm, yes, I agree completely. But the point of jokes like these is that they make a point succinctly and well enough. Hah. But yes, building bridges is hard. So is building software. But the job of an engineer is solving a hard task within budget and within deadline.

Again, sounds nice, but an ME wouldnt be so cocky if he had to smelt his own materials and quality grade them before even starting to build the bridge. ME's get the benefit of a older, more mature industry that surrounds them and enables them to make rational decisions. See how quickly that goes to hell when getting substandard parts from a sketchy supplier. Then you can see the schedules and the budgets go to hell.

Multiply this times 100 and you are just about in the same situation as web developers. Maybe in 100 years, an ecosystem will grow around to support us? I can only hope. For now, i cant even rely on xml to be marshalled the same unless i control both client and server.

Re: A significant amount of programming is done by superstition

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

teaching from first principles doesn't hold up experimentally. Every documented case of teaching e.g. mathematics or languages from first principles without first going through practical examples or the like has resulted in failures.

I'm pretty sure nobody actually learns from first principles,but understand first principles from things they've already seen

Re: A significant amount of programming is done by superstition

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

It's not really worthwhile to try to code from first principles, because the context can always multiply in complexity. You want to make a tic-tac-toe game. What language are you going to program it in? Is it going to be cross-platform? Are you going to code an AI engine?

Trying to do anything in computing from first principles is like trying to code without mistakes. You're losing the value of iterative design.

Post reply on HN