hammers and nails (was: objects and forth)

Vaded wrote on Mon, 09 Feb 2009 18:38:02 -0700
> Jecel,
> 
> You wrote: 
> 
> but sometimes I see Forth fans deny that by refusing to
> consider as valid problems for which their favorite language is not the
> best option.
> 
> If you wouldn't mind, could you explicate what contexts you find cf to
> be a fitting approach and in what contexts you don't think cf would be
> the best match in?  While I understand your point about people thinking
> their hammer is best for all nails, in the case of cf, all things being
> equal, I have a hard time imagining many situations where I would prefer
> to use C, Lisp, Smalltalk, etc.  Of course there are reasons like: 
> "my clients don't want it in Forth", etc., but I mean from a more pure
> perspective of elegant problem solving rather than from a perspective 
> of the socioeconomic realities of programming languages.  

Good question. The issue is subjective, of course. What one person finds
readable, another might think is simply horrible.

And it is important to take the development process into account. If I
show you some program that I wrote in Self, for example, you might claim
that it looks essentially identical to the same program in Smalltalk-80.
And I would have to agree - the final product is pretty much the same in
both. But the path that I took to get there has some differences and
that can be important in practice even if most people don't think about
it.

One big difference in the development styles for Color Forth and
Smalltalk is that the latter aims for "extremely late binding". That is,
things are left undefined until the very last possible moment. In
contrast, Color Forth is about moving things from run time to compile
time and from compile time to edit time whenever possible. Yet we still
have many of the advantages of late binding by compiling on demand: you
define some code and global variables, load some blocks in the context
of these new definitions, load some application blocks on top of that,
run the code, forget all these definitions and start over for the next
application.

So I enjoy using Color Forth as a small, personal computing environment
where I have read all of the code and written some more of my own. A
system with lots of data and relatively little code, like Okad, is a
very good match. Such a system evolves quickly because I will be
constantly rewritting the parts to keep it consistent and adapt to new
needs.

For a larger system built by several people with parts that might evolve
independently then I might prefer Smalltalk or Lisp. As Alan Kay likes
to point out, when you change scale you sometimes have to change
materials and/or methods. Doing a 30 story building the same way you
would build a dog house is not a good idea.

This doesn't mean you can't use Forth for this kind of project. Whether
you personally enjoy a programming language or not probably makes more
of a difference than all other factors combined. Some large computing
systems that I know of built in Forth include the Xerox Valdocs, Gavilan
OS, Canon Cat and the iTV one.

Note that I am typing this in a Smalltalk application called Celeste. Is
anyone posting from a Forth based email tool? That shouldn't be very
hard to write, but in real life we are all busy with many things and
this isn't a big priority since there are other tools out there that get
the job done.

Here is an example: when the One Laptop Per Child project was started,
they decided to make it as close to a Python (which I think is a very
nice language) machine as they could. The main motivation was that it
had been created for teaching programming (BASIC led to ABC which
evolved into Python) and there was a large and very energetic community.
On the other hand, in Squeak Smalltalk there was the Etoys visual
programming system that can been tested in schools for years. So the
solution seemed simple enough - in his Pycon 2006 keynote address, Alan
Kay urged the Python programmers to create their own equivalent of
Etoys. But it didn't happen until very recently (an application called
TurtleArt) because in general Python people find vi and emacs user
friendly enough.

My point is that we have the "Turing tarpit" which says that any
language can do anything that any other language can, but there are many
other factors which will influence what will actually get done or not in
some specific language. For my truck terminal application, I added
objects, garbage collection and a nice concurrency system so there was
little reason to use Smalltalk instead except for a prettier syntax (I
find it funny that people are so obsessed with syntax that they think
Java is related to C when it is clearly a Pascal, for example). But I
did a lot of string manipulation and other things that would have been a
bit more awkward in a plain Color Forth.

-- Jecel