Live data from Hacker News

A significant amount of programming is done by superstition

utcc.utoronto.ca

111–120 of 214 posts

Re: A significant amount of programming is done by superstition

#111
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,…

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…

This is a great comment. The category error you've identified is manifest in more than the comment you're replying to as well: it's at the heart of one of the biggest problems with software interviews in a certain sector of this industry (the heavy focus on academic CS in startups and many Bay Area tech companies).

Re: A significant amount of programming is done by superstition

#112
post #106

That's right, but I guess we're missing the real problem here. The real gold are these words: > You've really read the LSB specification for init scripts and your distribution's distro-specific documentation? If so, you're almost certainly a Debian Developer or the equivalent specialist for other distributions. Many of us would agree, that it's true. But why is it true? Shouldn't that make us suspicious in the first…

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

Re: A significant amount of programming is done by superstition

#113

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…

Any time I have to develop something from first principles, I do it 2-3 times in different ways, and only then make a serious attempt at actually writing it. It's still terrible, of course, but at least has a chance of working since I have a bit of experience in what can go wrong.

That's exactly my method. What I've noticed in the last couple of years that there are more and more programmers that could not start from a 'blank page' if their life depended on it. That's a sad thing in my opinion, programming is a creative job and creation sometimes needs to start from nothing or extremely little.

Re: A significant amount of programming is done by superstition

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

> 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 bridges is easy, it's anything but.

Re: A significant amount of programming is done by superstition

#115

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…

The issue isn't so much in the medium (shell), but the underlying program itself (sysvinit) being overly primitive. See the daemontools family where runscripts are largely as short or shorter than systemd unit files: http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/ru...

In addition, the BSDs have much shorter rc scripts mainly by putting all the boilerplate functions into a single library file that is then sourced. Gentoo's OpenRC framework, as well.

Re: A significant amount of programming is done by superstition

#116

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…

> The biggest problem, I think, is that often you end up with 10 different ways to solve the same problem in the code because instead of looking at the existing code, people Googled for a solution with subtly different keywords than the previous person and found a different blogger. This kind of duplication is very hard to identify and remove, and this does cause bugs. It's interesting to code in large code bases. Th…

IMO if your code base is large, you have already failed.

Re: A significant amount of programming is done by superstition

#117

A very sigifigant part of Ansible service module code was done to deal with misbehaving init scripts. They are very much cargo-culted just like RPM or debian package formats - borrow the ones from your previous project. They are hard to get right and many apps don't daemonize correctly or return OK before they are ready to be running - and then are actually running much later. Upstart/systemd didn't neccessarily make…

I've used pleaserun a little in the past. When you're being quick and dirty and using fpm it fits into the workflow quite nicely. It can be a bit awkward if you're deploying things that need anything complex in their init script, like a bootstrap command or something, but if it's just a straight start|stop|restart it works quite well. It's probably not up to generating distro-guideline-compliant init scripts (and fpm obviously doesn't either for spec file) but so long as that's not the goal it's a useful tool.

Re: A significant amount of programming is done by superstition

#118
I have a tendency to not use things I dont feel that I fully understand. This makes me stick to using the more basic elements of the language. In C# for example recently, there was a part of a game I am writing in my spare time for which 'events' would have suited. But I still dont feel I understand what events in C# is doing exactly. So instead I just put all the things I want the event to happen to in a list, and when the event happens everything in the list has a particular function called on it. I will probably get around to using C# events eventually when I have looked at them more and feel like I understand them. There is maybe a very small performance cost to what I did (according to some stuff I read, but I havent tested this so I dont know) But at least I have an architecture for my game and code that makes sense to me and that I feel like I understand completely (at least at the abstraction level of C#)

Re: A significant amount of programming is done by superstition

#119
post #106

That's right, but I guess we're missing the real problem here. The real gold are these words: > You've really read the LSB specification for init scripts and your distribution's distro-specific documentation? If so, you're almost certainly a Debian Developer or the equivalent specialist for other distributions. Many of us would agree, that it's true. But why is it true? Shouldn't that make us suspicious in the first…

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

Re: A significant amount of programming is done by superstition

#120
post #106

That's right, but I guess we're missing the real problem here. The real gold are these words: > You've really read the LSB specification for init scripts and your distribution's distro-specific documentation? If so, you're almost certainly a Debian Developer or the equivalent specialist for other distributions. Many of us would agree, that it's true. But why is it true? Shouldn't that make us suspicious in the first…

I think for a lot of people reading man pages is not as fun and satisfying as just making things and watching them work. It's a form of instant gratification.
Post reply on HN