Re: The Promise of Forth

Jonah Thomas wrote:
> And if you're an employer, do you want to pay people to think or do you
> want to pay them to crank out solutions? One way you get lots of
> solutions. Bang. Bang. Bang. Bang. Bang. Bang. Six problems solved
> quickly. If your employee spends more time to solve 4 problems and he
> changed the problems around to suit himself, how do you decide whether
> the time is worth it? It's obviously stupid to measure productivity by
> lines of code, but what do you use instead? 

Your message is chock full of false dichotomies.  You started with the 
false dichotomy of choosing Forth or another language.  That ignores 
that you can also choose both, using Forth where it gives maximum 
benefit and other languages where they excel.  Most systems of any size 
are decomposable into cooperative subsystems, and each of those 
subsystems can be individually considered for what language is most 
appropriate for the expression of the solution to a problem.

You next move into the false dichotomy of paying people to think or pay 
people to crank out solutions.  I work for a company that has clients 
who want both.  Some clients are paying us to come up with the smallest, 
most elegant, well thought-out solutions we can.  Then we have clients 
who say, "we have a trade show in 25 days and we need to show a 
prototype there."  So there are times when we're all huddled around a 
whiteboard diving into details, and other times when we're slapping 
together existing solutions.

Neither is right or wrong.  It depends on the needs of the client, the 
product lifetime, the level of innovation in a system and so on.

> Forth is OK for big projects. But it appears the experience with Forth
> for big projects involves first getting the specs very very clear. Then
> code rigidly to the specs. 

In other words, Big Design Up Front projects that follow strict 
waterfall processes and that turns programmers into mindless robots 
following orders.

> Forth's advantages ought to show up best with projects that can be done
> by 1 to 3 Forth programmers. I have the impression that large projects
> need to be larger than this because a software manager needs to manage
> 10 to 30 or more programmers to get the institutional respect an
> administrator needs. 

I love how nearly every discussion in comp.lang.forth that discusses 
project management usually degenerates into a series of insults about 
management.

Here's a more realistic view:  Large projects are large because they do 
more, and they incorporate a wider set of skills.  The largest project I 
was on had 30 engineers on it.  Why?  Not because they wanted to get 
"institutional respect" but because the project was complex.  There was 
low-level hardware that needed device drivers.  There was gateware that 
needed experts in FPGAs.  There was high level software to provide a 
sophisticated web interface.  There was some mid-level connectivity 
software that had to talk to other systems.  There were real-time 
aspects.  There were scripting aspects.  There was some sophisticated 
algorithms.  There was some dumb "jellybean" code.  We needed people who 
were aware of some esoteric networking technology.  And we needed people 
who could just slap some scripts together.

It was a large project because it was... large.  It combined the skills, 
interests, and insights that would be extremely unlikely to find any one 
person had.