Express What, not How.

[Albert Lai]

gt5163b at prism.gatech.edu (Brian McNamara!) writes:

> I agree with your one of your overall theses, which is that we should
> focus on the "what" rather than the "how".  Where our opinions diverge,
> however, is that I think sometimes the best way to communicate an
> abstraction is to show the "how" inline, rather than creating a new
> name in an attempt to capture the "what".

There are also times when "what" and "how" are literally the same,
which is when the "what" is a very trivial task.

It is a very slippery slope to insist coding styles in the name of abstraction:
- every value must have a name
- every function or procedure must be christened
- everything must be put in a class or object (I call this OOP - object
  obfuscation pomposity)
- every line of code must be commented

There is an adverse social effect (since social effect was mentioned)
whenever an abstraction mechanism like the above ones is doctrinized.
Programmers will begin devaluing the mechanism.  If you insist on
comments, they start writing silly comments; if you insist on naming
things, they start giving silly names; and if you insist on classes,
well, they start putting everything into one single class and making
all members static and public.  They start seeing the abstraction
mechanism as a bother and stop seeing its potential benefits.

It is when you allow some freedom of not using a mechanism that the
the mechanism becomes valuable.  (The political parallel: some people
like to stay in their countries precisely because their laws permit
them to leave.  Once you remove that freedom, people begin to smuggle
themselves out.)

Now no one is suggesting to make all functions anonymous, all code
unstructured, and all aspects uncommented.  Nothing of that sort!  In
practice we give names to all non-trivial functions.  Someone asserted
that we should judge a mode of expression for what it does when put in
good use, not what it could do when abused.  That person should not
argue against anonymous functions by noting all the gory details of
implementation it might expose in the wrong hands.

And now I would like to sidetrack a bit and give an unrelated example
of Brian's point that sometimes "what" without "how" is completely
unclear.

I have an abstract data type to present you.  This exercise is to test
how well you understand the "what" presentation, so the names of the
operations will not give you a clue.  They are meaningful names though
- meaningful to me, a Cantonese speaker.  (Just to show you how
meaningless the whole notion of "meaningful names" is.)  But I will
present you "what" it does without mentioning "how".

It is a functional (immutable) abstract data type, so most operations
take an existing instance as a parameter and return a new instance.
The name of the abstract data type is LiDui.

Hung  : LiDui
MoYun : LiDui -> Bool
PaiDui: (LiDui,Object) -> LiDui
DuiTau: LiDui -> Object
LeiDui: LiDui -> LiDui

MoYun(Hung) is true.
For any LiDui d:
  If MoYun(d) is true, we have LeiDui(PaiDui(d,o))=d and DuiTau(PaiDui(d,o))=o.
  If MoYun(d) is false, we have LeiDui(PaiDui(d,o))=PaiDui(LeiDui(d),o).

That's it.

I have never seen any first-year CS class present this abstract data
type this way.  All presentations either show a simple pseudocode
implementation, or appeal to a mental model derived from a real life
experience, which is still a kind of simple pseudocode implementation,
except it is in real life terms instead of CS terms.