Jonah Thomas wrote:
> The Forth promise is that the extra thinking will pay off. That the
> normal exponential crufty buildup will be slowed. That the simplicities
> will work together so that you'll wind up with less total work. Fewer
> places for bugs to hide means faster debugging and the possibility for
> actual correct code. The less that extra complexity leaves you making
> work for yourself, the more time you have available to think and
> simplify and the more actual results you can produce.
The extra thinking does pay off very handsomely. Project managers have to
be enlightened to see this though. Sadly, too many expect the code
monkey's to churn out the solutions then they end up with very extensive
debug cycles. With Forth, because the thinking was up front where, in
proper systems engineering terms it belongs, there is less time and
money wasted late in the project.
> It's true for some Forth programmers. When people try Forth and decide
> it wouldn't work for them, they may be right. The Forth Promise can't
> pay off except for programmers who think of ways to keep it simple.
Only those who think complex problems demand complex solutions think that
way. By all accounts this is a large number.
> 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.
I'd rather they are thinkers myself (not that I employ often).
> 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? There are people who try to
> measure functionality with function points etc, but I predict that
> automated methods to do that will fail, and that to do it correctly
> takes competent programmers and requires more time than it does to
> produce the code in the first place.
There are tools that assist (not all automated ones and some of the best
are simple pen & paper techniques). Forth is really for those into
proper systems engineering (see
http://en.wikipedia.org/wiki/Systems_engineering
for an explanation).
However, it is probably harder to see where the dividing line for
improvements in solutions due to systems engineering and improvements in
solutions due to use of Forth would lie.
[%X]
> The promise of Forth should be manifest more in larger projects. The
> bigger the project, the more opportunity for simplification. A project
> that's 10,000 lines of code in some other language will have more
> functional redundancy than one that's only 1,000 lines, and one that's
> 100,000 lines should have even more opportunities.
....and only a systems engineering approach would be likely to find such
opportunities in the first place. The trouble is, using a systems
engineering approach, these opportunities would become more apparent no
matter what programming language was used.
> But in practice there are limits. Forth is great when it's one great
> Forth developer doing it all himself. Three Forth experts can cooperate
> well, particularly when they have different specialties -- for example
> one writes device drivers and low-level code while a second writes the
> guts of an application and a third does the user interface. But a large
> Forth team is if anything more likely to write redundant code because
> they're likely to produce faster. To avoid that it would be necessary
> for all of them (or all but one) to know what everybody else is doing.
> If you figure that it takes half as long to look at somebody else's
> code and see whether there are possible common factors with your own as
> it does to write that same code from scratch, a team of 9 Forth
> programmers might need to each spent 80% of their time looking at what
> the others are doing and only 20% of their time doing things
> themselves.
In order to keep track of the components it only takes a database that is
easy to search. That was essentially what Wolf Weiggard (of Holon fame)
did. However, you need such databases to very searchable using the sort
of terms that each individual programmer would use.
> Forth is OK for big projects. But it appears the experience with Forth
> for big projects involves first getting the specs very very clear.
Always a good start on any project.
[%X]
> This works, but it doesn't get such obviously great results
> that lots of managers want to try Forth for large software projects.
Yet Forth has been used for some truly massive projects with a great deal
of success.
> How could Forth break into the large-project market?
Given that your number guesses are anywhere near right why would we want
to? The only large system projects that would occupy a single system
that I could think of would be massive database projects (National
Health Records, Licencing Records etc). I am not sure that I would
consider projects in that vein but I am sure there are those Forthists
who would.
--
********************************************************************
Paul E. Bennett...............<email://Paul_E.Bennett@[EMAIL PROTECTED]
>
Forth based HIDECS Consultancy
Mob: +44 (0)7811-639972
Tel: +44 (0)1235-811095
Going Forth Safely ..... EBA. www.electric-boat-association.org.uk..
********************************************************************
|
