> From: "Florin X Mateoc" <mateoc_florin at jpmorgan.com>

> But all programming tasks are inherently procedural (at least in part).

Well that's inherently contradictory, because those other parts can  
be non-procedural, but never mind :-)

For example, you can encode fairly nifty program behavior using  
constraint systems, no 'procedures' involved, at least not visible to  
the user specifying the constraints.  Note that the user experience  
is all that I am concerned with, the fact that there is a constraint  
engine dilligently solving all those constraints is a different  
matter.

> Please
> note that what I call here a procedure is not a "method" in  
Smalltalk sense,
> rather a code path.

By calling it a code path, you are already defining-away what I meant.

For example, let's say I have a triangle.  The three edges can have  
different colors.  Now, from this concrete triangle with different  
colors, I create a 'template' that has a single 'parameter', namely  
the color of one of the sides.  This template now has flexibility, it  
is a dynamic element, a parametrized object.

Now, I decide I want to have all the edges have the same color.  I  
introduce a dependency between the colors attributes of the remaining  
two edges and the edge that I have already made variable.  You could  
also call this a one-way dataflow constraint.

Am I programming yet?

I could also specify more complex relationships, such as that the  
color should be complementary, or that their RGB values should add up  
to white (which would be underspecifed were it not for starting  
conditions and stay constraints).

The object, though primitive, is now pretty damn smart.  Have I  
started to program yet?

As you add complexity to the constraints, you will run into  
situations where either the constraints cannot be expressed using a  
constraint satisfaction formalism, or where their formulation would  
be more complex than just specifying a piece of 'procedural' code to  
compute the result(s).

I am pretty sure that I am programming now, but the activity hasn't  
really changed fundamentally.  All I am doing is adding more powerful  
abstractions.

Of course, the triangle is kind of boring.  It gets much more  
interesting when I have richer base-objects to play with, and for  
example a more powerful sketching/drawing application to create  
graphics that I can then turn into smart objects.  However, rich and  
powerful applications currently don't have the ability to create  
'smart' objects, and interactive object oriented systems typically  
lack powerful 'applications' (smart objects tied together  
intelligently).

So what I am saying is that maybe the difficulty in teaching  
programming is viewing it as an isolated activity, and not as simply  
one of many means of getting my objects to do what I want.  Viewing  
'programming' as something you do when you need to teach your objects  
new tricks might be more productive, especially if it starts out  
with objects that people actually want to interact with.

> When putting them together in an "application" we glue all
> these procedures to be triggered by some external (user) event.

Well, the concept of application is one of the problems, as it  
produces the distinction between programmer and user of the  
application.  I think that can and should be a fluid boundary, with  
programmers being called in by users when they don't know how to  
proceed further.

The core activities are creating and using abstractions (moving from  
the concrete to the abstract and from the abstract to the  concrete,  
respectively).  Many abstractions can already be created without  
'real' programming.  The task of programmers is both to create those  
abstractions that still require programming ( the user's meta-level,  
the programmer's concrete level) *and* to create new mechanisms to  
give users more ways of creating more powerful abstractions without  
our help ( the programmer's meta-level, the language researcher's  
concrete level).  And so forth...

[snip]

> The procedural part of this process is the one that resembles  
solving math
> problems (and unfortunately children are repeatedly told (in US  
schools) that
> math is very difficult).

Hmm, programming is simply also very maths oriented, which isn't  
really necessary, and which hurts because most people aren't  
particularly interested in solving math problems.  For example, my  
mom took an intro to programming course at my highschool (long ago).   
They sat her in front of an ADM-3 ASCII Terminal hooked up to a  
PDP-11, with BASIC.

> The distribution part is the "art" part, with much fuzzier rules.  
Hopefully we
> can also control redundancy in this distribution stage. Only this  
part of the
> programming process makes things different in OO. (This also maps  
into how I
> write code: I usually start in a workspace, then grow that  
procedure until it
> becomes too large, then I factor it into classes/methods and  
continue there)

Sure, that's how a lot of us work, but we're all 'programmers'.

[snip]

Regards,

Marcel