Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A significant amount of programming is done by superstition

utcc.utoronto.ca

Post reply on HN
Print view View original

141–150 of 214 posts

Re: A significant amount of programming is done by superstition

#141

Post by rtpg »

avmich wrote: post #81
GauntletWizard wrote: post #46

Earlier quoted context omitted.

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…

> Experimentation is the key to science. Computer science is a branch of mathematics. Here you build models, reason about them, find properties, then prove them, then rely on them. Tests - a.k.a. experiments - are usually not exhaustive and don't provide guarantees of correctness. Having said that, I agree that experiment is of crucial importance - how else you would validate your models in the first place? However,…

Even in math, you don't build models, you discover them. Pythagoras wasn't worried about the axiom of choice, he was discovering how geometry works.

I don't mean this to be a "mathematics from nature argument" (even infinite sets are hard to justify as coming from nature), but the course of history has usually been "solve similar problems in an ad-hoc manner many times, then generalize"

Re: A significant amount of programming is done by superstition

#142

Post by copsarebastards »

superuser2 wrote: post #132
copsarebastards wrote: post #60

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

I don't agree at all, but even if I did, that's only one of tons of cases. There are plenty of very recoverable errors which aren't handled by example code you copy off the internet, but which you really should be handling.

Take networking code for example: do you really want to be dying without a visible reason because you didn't check `errno` and do a retry? This is really basic stuff.

Re: A significant amount of programming is done by superstition

#143

Post by vacri »

brudgers wrote: post #52
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…

The problem here is that if it works, how is it superstition? Consider Bertrand Russell's Chicken: The man who has fed the chicken every day throughout its life at last wrings its neck instead, showing that more refined views as to the uniformity of nature would have been useful to the chicken. [1] Sometimes things working but not in the way we imagine they work is worse than them not working at all. [1]: http://www.…

Had the chicken been living in the wild, it might have lived a long, full life... or it might have been painfully maimed or slaughtered in the myriad of nasty ways that nature has to offer, at any age from before it hatched on up.

I don't think it's at all safe to assume that a comfortable life with a definite-but-unknown end point in your prime is definitively worse than a life subject to the random events of the wild. Particularly for something that's down the lower end of the food chain.

Re: A significant amount of programming is done by superstition

#145

Post by lawnchair_larry »

superuser2 wrote: post #132
copsarebastards wrote: post #60

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

It has nothing to do with being able to recover. It's about not continuing with unknown state.

Re: A significant amount of programming is done by superstition

#146

Post by SilasX »

ackalker wrote: post #108
mreiland wrote: post #38

Earlier quoted context omitted.

why write unit tests when we don't understand the microcode in the CPU? We can't have "tested" it because we don't understand said microcode. Or wait... no, maybe your characterization is wrong. Yeah... that's probably it.

That's why they're called unit tests. They are supposed to test precisely one unit of functionality, while assuming everything else works as specified (using mocks if necessary). Taking into account the effects of microcode execution on the test result is in fact a kind of integration testing.

I think the GP's point was that you can't mock out the computer chip's opcodes.

Re: A significant amount of programming is done by superstition

#147

Post by martininmelb »

I think this is what I refer to as SODD - or 'Stack Overflow Driven Development'. Somebody is not sure how to do something, so they look for an example on SO and they copy the code without really understanding what they're doing. (note: this is different to when they get an answer on SO and copy it knowing what they're doing).

Re: A significant amount of programming is done by superstition

#148

Post by kenzokai »

avmich wrote: post #81
GauntletWizard wrote: post #46

Earlier quoted context omitted.

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…

> Experimentation is the key to science. Computer science is a branch of mathematics. Here you build models, reason about them, find properties, then prove them, then rely on them. Tests - a.k.a. experiments - are usually not exhaustive and don't provide guarantees of correctness. Having said that, I agree that experiment is of crucial importance - how else you would validate your models in the first place? However,…

I think "write code and see if it works" may be tad more succinct and closer to reality than "build models, reason about them, find properties, then prove them, then rely on them. Tests ... provide guarantees of correctness." wrt to OP's comment.

Re: A significant amount of programming is done by superstition

#149

Post by Tenobrus »

ecnahc515 wrote: post #124
avmich wrote: post #81

Earlier quoted context omitted.

> Experimentation is the key to science. Computer science is a branch of mathematics. Here you build models, reason about them, find properties, then prove them, then rely on them. Tests - a.k.a. experiments - are usually not exhaustive and don't provide guarantees of correctness. Having said that, I agree that experiment is of crucial importance - how else you would validate your models in the first place? However,…

Physics of also a branch of mathematics. But experimentation is key to proving correctness.

What? Physics is not a branch of mathematics, it just uses mathematics and mathematical properties. That's like saying psychology is a branch of mathematics because it involves statistics. Using math isn't the same as being math. Admittedly physics is one of the "mathiest" fields, but it still involves doing experiments and coming up with mathematical models that fit the data rather than coming up new kinds of mathematics. The line was much more blurred in Newton's time, but these days the distinction is pretty obvious.

Re: A significant amount of programming is done by superstition

#150

Post by nostrademons »

coldnebo wrote: post #135
Swizec wrote: post #68

Earlier quoted context omitted.

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…

It's interesting that you mention TCP/IP, because that's the most famous example of a technology that "works in practice, but not in theory". Take a look at Van Jacobsen's presentation on the history of ARPANET:

http://www.youtube.com/watch?v=oCZMoY3q2uM

Packet switching was "utter heresy" (20m in) when it was invented. It "wasn't a network, it was an inefficient way to use an existing network". And it almost collapsed 25 years after it was invented; the presenter is famous for inventing the modern TCP/IP congestion control that saved the Internet [1]. The TCP/IP flow congestion algorithm has been redesigned several times since [2]. It works not because it was designed well, but because it wasn't designed and instead evolved over many years with many contributions from people devoted to keeping it working.

Alan Kay is usually who I think of for great ideas that "work in theory, but not in practice". He's done some crucially important work in OOP, programming languages, and GUIs. But note that we don't actually use SmallTalk; instead we got C++ and Java. Nor do we use Dynabooks and Altos; instead, we got Microsoft Windows.

[1] http://en.wikipedia.org/wiki/Van_Jacobson#Career

[2] http://en.wikipedia.org/wiki/TCP_congestion-avoidance_algori...

Post reply on HN