Live data from Hacker News

A significant amount of programming is done by superstition

utcc.utoronto.ca

191–200 of 214 posts

Re: A significant amount of programming is done by superstition

#191

Earlier quoted context omitted.

No. We spend months and years fixing the issues with the specs (especially if they're committee-driven, they tend to be crappy). Yet it's easy to keep your implementation conformant to the specification without any hand weaving and looking at "examples".

You can keep it conformant, but that's not enough, because the real world isn't. Try writing a conformant HTML parser that rejects invalid input, and then run a crawler that uses it. You'll reject half the web!

In such a case the right way to go is to build a formal model of the informal expectations first. I.e., split scientific and engineering phases. Collect your data, build a theory, validate it, and only then engineer an implementation of it, mechanically, with zero mental activity.

And what you seem to suggest, start writing a parser and then experiment with various real-world inputs until you're satisfied, is certainly not a very productive way of doing things.

Re: A significant amount of programming is done by superstition

#192

Earlier quoted context omitted.

You can keep it conformant, but that's not enough, because the real world isn't. Try writing a conformant HTML parser that rejects invalid input, and then run a crawler that uses it. You'll reject half the web!

In such a case the right way to go is to build a formal model of the informal expectations first. I.e., split scientific and engineering phases. Collect your data, build a theory, validate it, and only then engineer an implementation of it, mechanically, with zero mental activity. And what you seem to suggest, start writing a parser and then experiment with various real-world inputs until you're satisfied, is certain…

I'm not suggesting anything but that you can't build it from first principles. Collecting data and building a theory is not working from first principles, it's just a more structured way of hacking it until it works. You're still liable to have the next website you crawl break your parser.

Re: A significant amount of programming is done by superstition

#193

sysv init scripts in particular are so pointless to write. In the end, the whole script usually revolves around four lines of actual code (starting a process, stopping it, querying the status, optionally sending it a SIGHUP to make it reload its configuration), but the result is a script with 50 lines of boilerplate. Which, of course, could nearly all be automated away by a sane, declarative format. Leaving all the p…

Not just systemd, but... everything else that's trying to replace sysvinit, too.

Upstart jobs are really simple, and OpenRC and modern BSD initscripts are also much simpler than SysV (and old BSD) initscripts.

I think we're at the point where regardless of the systemd vs. everything else debate, we can all agree that SysV initscripts are shite.

> I tried writing a sysv init script from scratch. I stopped because of sheer boredom, and resorted to copy&paste to save both time and nerves.

Better yet, at my last job, I had some extra time, so I rewrote Ubuntu's qpidd initscript as an Upstart job, and it was so satisfying to see that giant script get condensed down to a few lines.

Re: A significant amount of programming is done by superstition

#194
post #168

Earlier quoted context omitted.

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…

The web might have been created by amateurs, but it works incredibly well. Sure, we have browser incompatibilities and whatnot, but this is an effect of having multiple independent implementations of the standards, which is part of what makes the web work in the first place.

>The web might have been created by amateurs, but it works incredibly well.

The fact that it was created by amateurs helped make it work incredibly well for amateurs.

The professional CS alternatives - gopher and the like - were not successful in comparison.

There's a thing in CS where solutions become so clever they become stupid - because the goal stops being task-oriented usefulness, and becomes ideological and formal purity.

It's the process that turns a plain hammer into an atomic pile driver you can only control remotely from the moon by sending it messages using catapulted owls in space suits. It's better at hammering in some abstract sense, but maybe not so much for hitting nails.

Abstraction without contextual insight is one of the most powerful and destructive of all anti-patterns.

On the web the professionals took over from the amateurs, and now web technology is another example of design-by-committee.

It still works surprisingly well because interplanetary owls are kind of fun, maybe, for some people. But is it ever a mess of half-solved problems generating recursive epicycles of complication.

Re: A significant amount of programming is done by superstition

#195

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…

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.

I disagree. It's worth working things out from first principals as a method of practice, because when you have to do something completely novel, you won't be totally lost (If you never have to do this in your work, then I guess it doesn't apply).

Also, if you never work things out yourself, we'll only ever have one way to do things. What if a better approach exists but nobody's ever tried it?

It's good to double/sanity check what you came up with afterwards, and if the only way you can think of to do something is obviously seriously flawed, then don't go through with it and look it up instead.

Re: A significant amount of programming is done by superstition

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

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.

As I have stated multiple times in the past, I think the crux of the problem is that software is an immature field that needs to stratify into a proper engineering discipline as it matures. Computer science should be the "good enough" standard behind software engineering. "Computer scientists" should not be the ones actually implementing software systems any more than physicists should be the ones designing cam shafts or laying out circuit boards.

The opening to the mainstream you refer to illustrates the problem. The people in the mainstream should not be studying computer science, and what they practice should not be called such. They are the engineers, technicians, and mechanics of software; they are not the physicists. Forcing all of these strata into the same bucket is doing more harm than good at this point and is likely hampering the field's drive to mature.

Re: A significant amount of programming is done by superstition

#197
post #57
post #50

Earlier quoted context omitted.

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.

I should add that the extent to "it all comes rushing back" is directly and inversely correlated with how long ago I wrote it, and positively correlated with how interesting/difficult the problem was to solve at the time. Also, almost every time I go back to review code I wrote more than a year ago, my first reaction is "jesus, that's a stupid pattern/implementation. Why did I do it that way?". I've been a profession…

It won't. And sometimes you'll start to change it, hit a wall, and then realize "oh that's why I did it that way."

Re: A significant amount of programming is done by superstition

#198

Earlier quoted context omitted.

In such a case the right way to go is to build a formal model of the informal expectations first. I.e., split scientific and engineering phases. Collect your data, build a theory, validate it, and only then engineer an implementation of it, mechanically, with zero mental activity. And what you seem to suggest, start writing a parser and then experiment with various real-world inputs until you're satisfied, is certain…

I'm not suggesting anything but that you can't build it from first principles. Collecting data and building a theory is not working from first principles, it's just a more structured way of hacking it until it works. You're still liable to have the next website you crawl break your parser.

> but that you can't build it from first principles

Do not confuse principles (which are universal, simple and beautiful) with specs (which suck shit a metric ton per second).

> it's just a more structured way of hacking it until it works

You're confusing hacking with cargo cult coding. Hacking until it works is exactly this formal loop: collect the data, build a model, test if it's applicable. Cargo cult is "google for an answer, paste some code from stackoverflow, see if it works". The OP article is about the latter.

Re: A significant amount of programming is done by superstition

#199

Earlier quoted context omitted.

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…

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

What would software programming look like as a true engineering discipline?

Re: A significant amount of programming is done by superstition

#200

Earlier quoted context omitted.

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.

Can you expand upon what you mean?

The Rails community at least is infamous for drunken boorishness and generally being gratuitously offensive and unprofessional. Rails is the spiritual capital, if not the origin, of the worst of the brogrammer attitude.
Post reply on HN