On Mar 23, 4:20 am, "Paul E. Bennett" <Paul_E.Benn...@[EMAIL PROTECTED]
>
wrote:
> 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
(seehttp://en.wikipedia.org/wiki/Systems_engineeringfor
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.Benn...@[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..
> ********************************************************************
who is woldf wiggard of holon fame?
|
