Home » forums » LtU Forum

Programming by page faulting

I would normally post this to G+, but I'm in a 3 day vacation weekend behind the great firewall, so here goes. Pursuing a CLOS submission on hackernews this morning, I came across an awesome quote in the comments section:

I'm a fan of reading the ****ing manual and thus you're preaching to the choir on that. But I'm not an evangelical baptist about it. Truth is that most people program by page faulting - writing some code, hitting a bug, and googling for a solution, lather rinse repeat.

Many would find this very controversial, but it is increasingly true for younger programmers (and I've gotten into this habit myself). It has serious implications on programming language design: efficient feedback loops are much more important as design occurs more by doing than being done up front, functionality should be discoverable at least by searching. What else?

By Sean McDirmid at 2014-09-08 00:00 | LtU Forum | previous forum topic | next forum topic | other blogs | 3386 reads

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Fixing the symptoms?

Fixing the symptoms?

By Ehud Lamm at Mon, 2014-09-08 06:16 | login or register to post comments

Worse than that

Some very strong programmers actually defend the practice of hacking new features into a code base by a caricature of TDD: write a test (which fails), write some code, run the tests again, make random modifications to the code until they all pass. The contention is that most code bases are (or very quickly become) so incoherent that attempting to understand them is a mug's game anyway. (If they were really random, of course, this would be genetic programming.)

Felix Winkelmann, the author of Chicken Scheme, summed it up thus:

Let's face it: software is crap. Feature-laden and bloated, written under tremendous time-pressure, often by incapable coders, using dangerous languages and inadequate tools, trying to connect to heaps of broken or obsolete protocols, implemented equally insufficiently, running on unpredictable hardware -- we are all more than used to brokenness.

By johnwcowan at Mon, 2014-09-08 13:12 | login or register to post comments

I think this is quite

I think this is quite different from "let's figure out how to do things as we go a long," but the necessary feedback loops are the same. Programming with a water hose...

By Sean McDirmid at Tue, 2014-09-09 00:11 | login or register to post comments

Programming by the seat of one's pants

Programming by the seat of one's pants has always been common, I think, used by some of the best and worst programmers (at guess, not as many in the middle). The feature of language design wanted —keeping in mind that all software development is language design, so this applies to how everything is written, not just how the language is initially set up— is that it should be possible to look at source code and see whether or not it's right: that is, anything that's wrong should leap out at the reader.

By John Shutt at Mon, 2014-09-08 13:19 | login or register to post comments

Debugging the null program

Programming by the seat of one's pants has always been common, I think, used by some of the best and worst programmers

Previously on LtU: Debugging the null program.

In that comment thread, Luke Gorrie identifies a reference to the practice in the "Anatomy of Lisp", from 1978.

By Anton van Straaten at Mon, 2014-09-08 14:40 | login or register to post comments