Thinking by analogy with Unix, there's many more people who write interesting and useful shell scripts than there are C programmers. The power of being able to script things together avoids the need for a good number of programs, and a good deal of programming.
So, programming may not be for everyone, but the right system design can let non-programmers do what they need, allows programmers great control over their code, and extends the reach of any given program to applications far beyond what the original scope might have been.
(But yes, we do shoot ourselves in the foot sometimes, too :)
Gotta agree with Djun. I wouldn't be able to use Linux/Unix without being able to "stitch" a few commands together and manipulate their output. Writing small script or composite command lines really helps to get things done quickly. Similarly, what would Apple be without Applescript? Here is a concrete example: Drupal blocks. Right now, we have a bunch of "per block visibility settings": 1. 'Show block on every page except ...' 2. 'Show block only on these pages ...' 3. 'Show block only on node pages of type ...' 4. 'Don't show this block when the throttle kicked in' While these offer a fair amount of control, more than once I bumped into the limitations of these "visibility rules". Concrete examples: 1. I wanted to create a block that is only visible to certain users. For example, I wanted to write a block that provides help to _new_ users. 2. I wanted to create a block that is only visible to certain user roles. 3. Various people want to display the 'book navigation' block on the main page. (This block is hardcoded only to show up when navigating a book.) 4. I wanted to create a block that is only visible on certain days or times of the year. (The 'Christmass Druplicon' block would be a good example. A 'Bugfix friday' block would be another example.) 5. I wanted to create a block that only shows up when the throttle kicked in (and not when the throttle is deactivated). To allow this kind of flexibility, we'd need to add various visibility settings. And even after we added these, it won't be possible to control how these rules interact. The current set of rules use implicit ANDs but maybe I want to use ORs or a combination of ANDs and ORs. The result? The block configuration page (1) becomes an "airplane cockpit" on its own and (2) even so, it can't take all possible configurations into account. The solution? Provide me a 70x8 textarea in which I can a write a block's "visbility check" using Drupal's APIs. Examples: 1. Only show block to 'authenticated users' that registered less than a month ago: return (time() - $user->created < x); 2. Only show block one week a year (eg. around Christmas): return (date('W') == 42); // only show block during week '42'. 3. Only show block to users with permission 'X': return user_access('X'); // I'm using a Drupal API here! ;-) 4. Only show block when looking at a forum topic: if (arg(0) == 'node' && is_numeric(arg(1)) { $node = node_load(array('nid' => arg(1))); // I'm using a Drupal API here! ;-) return ($node->type == 'forum'); } -- Dries Buytaert :: http://www.buytaert.net/