A call to semplicity (was: Lambda (was: Refactoring in Tunes))

James Little wrote:
> 
> > Laurent Martelli wrote:
> > >
> > > Every one is also free to use OIL :-) (http://perso.cybercable
> Massimo Dentico wrote:
> 
> >Another excerpt from "Thoughtful Programming"
> >- http://www.ultratechnology.com/forth.htm
> [...]
> > 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.
> 
> Jim

Please Jim,  you make banal  the reasoning  and end  up with banal
statements!  He has  never asserted (nor I)  that abstractions are
useless, read well:

==================================================================
[...]
Chuck *seeks* a simple efficient abstraction of the actual problem
to the actual computer.

[... and ...]

Chuck  originally created  Forth to avoid  problems  introduced by
*unneeded*  abstractions.
[...]
==================================================================

Mr. Moore  uses this  minimalistic approach  and Forth to solve so
called  *real-world problem*  with success  since about the second
half  of the sixty. He considers himself an application programmer
*not*  a researcher into  the field  of programming  languages  or
operating  systems.    He has refined  his  method and tool  under
constant pressure to developing reald world applications.

For an history of Forth  and examples  of successful  applications
see: - http://www.forth.com/Content/History/History1.htm

I have posted here these references  exactly bacause  I'm a strong
proponent of solid theoretical  basis for Tunes,  but at  the same
time this theory could not be an end in itself.  As understand it,
the Tunes project  wants to address  *pratical*  problems with the
best possible  theoretical  approach.   We need  to object  to the
theory by means of objective facts.

Sometimes a wrong abstraction  could create more problems  than it
could solve them.  An example from the theory of complexity(?)  is
the big-O(?) notation  (I don't know if these terms are correct in
english).  Coarse  semplification  of this technique idealize  the
machine and the algorithm in a manner that the results can be only
poorly correlated to the reality or, worse, not correlated at all.
So, I propose an empirical approach.

As Brian Rice has written recently:

> It's great that you're working on your ideas, but please be open
> to  ideas  that others  have had  so  you can build  from  their
> mistakes  and  successes.   Otherwise,  you  will  (I guarantee)
> stumble  into problems, that others have addressed  and studied,
> without any sort of vision.

What we can learn  from Moore is that his call  to simplicity  has
proven been successful.  So,  the big  questions  are:  what  is a
*good* abstracion?  What is an *unjustified*  (to introduce into a
system) complexity?

However Jim,  yours is a fairly common reaction  even in the Forth
community. Jeff Fox address it in a passage from the cited article:

==================================================================
- http://www.ultratechnology.com/forth3.htm
[...]

People try to distort and trivialize Chuck's by saying that he has
removed  everything  that is needed  from  Forth  and  they  don't
understand  why.  But Chuck didn't just  remove  things  to remove
things. He removed things when he found a simpler way to solve the
same  problem  that something  was there solve.  Often  to solve a
problem you have to add x-y-z. But then x-y-z introduces some more
complexity  and as  a result you have  to then also add a-b-c  and
d-e-f.  Now everyone gets used to x-y-z  and  never  considers any
other way to solve  the problem that x-y-z has solved for everyone
for so many years.  They also never consider  that a-b-c and d-e-f
may also  be viewed  as problems  that are begging  to be fixed by
being removed.  Otherwise as time goes by  they become bigger  and
bigger problems  and as code is developed  and added to the system
they will lead to more complexity.

- http://www.ultratechnology.com/forth3.htm#rethink
So Chuck will rethink the problem. He will find a different way to
do x-y-z, or better yet  to avoid  the problem  that x-y-z solved.
Now  the x-y-z  solution  that  everyone has been  using  for some
problem  is no longer  needed  because  something  better  is  now
available.  It gets done because  now he can also remove a-b-c and
d-e-f since they were just needed to support x-y-z.  Things become
simpler,  clearer,  easier  to use,  easier  to maintain,  because
unneeded fat has been removed and there are fewer complications.

But  people  who  have  been  doing x-y-z  for  twenty  years  are
horrified  at the prospect  of not  using it.  They cannot imagine
Forth without it.  None of their code  would run without it.  They
would have to rewrite code  to not use x-y-z  and writing  code is
hard for them.  They also cannot imagine living  without a-b-c and
d-e-f because  they once again their old code  is full of that and
they never considered doing it any other way.

Chuck  doesn't  just throw stuff  out because  he is compelled  to
minimize.  He is compelled  to experiment and improve his code. He
is not against throwing something out if he finds a way to be more
productive  without  it.  He  throws  stuff  because  he can  more
productive  by doing  things  in a better way,  cleaner,  clearer,
simpler.   He does  not  think  that he came up  with  the perfect
language  30 years ago any more than  he feels  he has the perfect
language now. He will always want to change and improve what he is
doing  and  he will always  be looking  for  new ideas  to make it
better.  He has been on a clear path to make his language,  Forth,
smaller, simpler, easier, more powerful, faster,  less buggy, more
maneuverable,  etc.   But each time  he  finds  a way  to  improve
something,through extensive experimentation and pragmatic analysis
many people have knee jerk reaction and say, "He took out what? I
can't live without that!  What is he thinking?".   But rather than
ask what he is thinking and ask him to explain why it is better to
do  Forth without x-y-z  many people just say,  "x-y-z is standard
practice  by  the  average  programmer  and  is part  of  the  ANS
standard. I don't want to even consider the idea of removing x-y-z
and  I have interest  in listening  to the arguments.  I will just
post stuff for other people about how I know that Chuck knows that
x-y-z is really good and that he is just trying to mislead people.

[...]
==================================================================

-- 
Massimo Dentico