Lambda (was: Refactoring in Tunes)

James Little
Wed, 12 Jan 2000 22:24:26 -700

> Laurent Martelli wrote:
> > 
> > Every one is also free to use OIL :-) (http://perso.cybercable
Massimo Dentico wrote:

>Another excerpt from "Thoughtful Programming"
> Chuck wants to make the computer simple and easily comprehended so
> that no extra layers of abstraction are needed to get at it or the
> problem.  Chuck wants to make the solution simple so that  it easy
> to write  and efficient  and has  no extra layers of unneeded fat.
> Chuck  seeks a simple efficient abstraction  of the actual problem
> to the actual computer.

The problem I have with this approach is that real-world problems lie 
in entirely different domains than that of the computer.  For 
example, I'm currently wrapping up a project whose problem statement 
could have looked like this:

"We need a way to store and access information about companies and 
contacts.  We need to be able to create "projects" involving these 
companies and keep a communication log and to-do lists involving 
these projects.  Furthermore, we need the information to be 
centralized and accessible over the Internet.  And we want to be
able to access the data from other people's computers, so it the
method of access can't require any special setup other than an Internet
connection.  Oh, and the solution needs to be easy to use and
understand, and reasonably speedy on a Pentium 100.

This is a classic "line of business" problem, the kind upon 
which the vast majority of America's programmers work.  (Presumably 
the same is true for the rest of the world, too.)  Computers, on
the other hand, do arithmetic, flow control, and bitwise I/O.
I don't see any simple abstraction of those concepts to the concepts
involved in the problem statement above.

> If they could  see beyond the illusion  to see only the
> simple  problem  and were only faced  with mapping it  to a simple
> computer things stay simple and simple methods work.  

I don't deny that the computer is simple.  It does arithmetic, flow 
control, and bitwise I/O.  But the problems are NOT simple.  And 
that's why abstractions are so crucial.  If I had to think about 
the simple computer's simple manipulation of bytes every time for 
every single kind of database query I send over the Internet, the 
proliferation of simple things would grow so huge it would overwhelm me.

No, give me abstractions, lots of them, so I can choose the ones 
that most closely relate to the problem I'm solving.  When I want 
to do arithmetic, then I'll consider giving them up.  But my 
customers don't want to do arithmetic.  (They've got calculators for 
that.)  They want to do things that don't relate to the computer at all.