A call to semplicity (was: Lambda (was: Refactoring in Tunes))
Massimo Dentico
m.dentico@teseo.it
Thu, 13 Jan 2000 16:06:18 +0100
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