"Jonah Thomas" <jethomas5@[EMAIL PROTECTED]
> wrote in message
news:20080322215618.3618af65.jethomas5@[EMAIL PROTECTED]
> People who don't like Forth say, why bother with a data stack at all?
> Declare variables, declare locals, let the compiler do the work of
> figuring out where everything is.
The same issue affects assembly doesn't it? (I'll basically use assembly
as
a synonym for FORTH for most of the rest of my response.) I prefer C to
assembly, in part, because I can focus on programming instead of keeping
track of, losing track, tracking down, and correcting the register, stack,
and memory locations of variables... For assembly, I've spent unknown
amounts of time on this. I spend no time for it in C. It's just handled
correctly. It shows the advantage of an implemented solution to a solved
problem. One step forward...
> And Forthers say that with a data stack we get a simpler compiler
> and we get simpler subroutine calling.
That's true. But, most don't have to deal with say C's prolog, epilog, or
the stack.
> ... you're
> handling details the compiler could do better and it costs you in
> efficiency.
That's true too. Well written C can almost match assembly. But, I
usually
can't out code a C compiler, in assembly, in areas where it's optimization
are strong: constant folding and constant propagation. Although, there
are
places where C compilers aren't strong and hand coded assembly can
outperform a compiler.
> The Forth promise is that the extra thinking will pay off.
That makes quite a few assumptions about people's abilities. It implies
"practice makes perfect," but assumes the result of extra time and thought
happens to be productive and not wasteful - "going 'round in circles". My
academic experience has proven to me very few people can solve problems.
And, of those that can solve problems, very few can actually think. I've
seen numerous people deemed "exceptionally bright," supposedly far
brighter
than me in most cases, who could solve numerous problems as effectively as
I, not be able to solve similar problems if a trivial change was
introduced... This is a strong indication to me that they'd developed
some
method to solve problems without real comprehension of the problem.
> 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.
All of your statements can be applied legitimately to the argument for
using
variables and not the stack or registers... Each thing you must do to
solve
a problem in code has the potential to introduce error. From that
perspective, which is more likely to reduce coding errors: 1) keeping
track
of variables by yourself or 2) not keeping track of variables by yourself?
The variable tracking has already been solved and debugged in a HLL, like
C,
so these are all true when it comes to using variables:
1) "That the simplicities will work together so that you'll wind up with
less total work."
2) "Fewer places for bugs to hide means faster debugging and the
possibility
for actual correct code."
3) "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 question in my mind is, "If someone or something else can solve the
problem, why must the rest of society be forced to waste time and
resources
resolving the problem over and over again?" How many people have to spend
their lives mastering mathematics, when those who came prior could've
provided solutions to real world problems instead of providing books of
problems to solve? Shouldn't we be producing means to advance the next
generation from our generation's "solved problems" to the next generations
"unsolved problems"? How do we expect the next generation to advance if
they are well over age sixty before an exceptionally few of them have
learned enough to solve more challenging problems? Are we going to depend
on IQ's increasing on generation to generation, or are we going to reduce
the next generation's comprehension requirements and work load?
Your statements could also be applied to learning mathematics. I had four
semesters of Calculus (plus AP Calculus in HS), Differential Equations,
Engineering Mathematics, only to learn that 98% of all Calculus problems
that I'd ever face in engineering can be solved with Laplace Transforms.
Basically, all math from Linear Algebra (10th grade?) in HS to my senior
year in college was a complete waste... of time, money, energy, life.
And,
in reality - since I didn't end up in engineering - I never needed any of
it.
> 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?
I want someone who can both think and can correct the cause, not the
effect,
of a problem effectively and correctly. But, that's not what employers
I've
worked for cared about. They cared about: people getting to work on time,
making unrealistic deadlines, denying people raises because performance
goals weren't met and then giving millions to charity, paying as little as
possible to the least experienced and poorest thinkers they could get
who'd
do the job - "cut 'n' paste", being able to tell upper management the
problem was fixed - without telling them it was buggy, inefficient, and
would require much rework and costs later - "job preservation", rewarding
employees for solving "big" problems - even if that same employee created
the "big" problem, etc.
> ... that to do it correctly
> takes competent programmers and requires more time than it does to
> produce the code in the first place.
True.
> Forth's proven successes have been in resource-constrained systems,
> where Forth has gotten results smaller than assembly or C. This is
> partly because C "optimization" has focused more on speed than size.
There are a number of language design differences that "bloat" C compared
to
FORTH. I see little reason why a C variant (might not be ISO C compliant)
couldn't produce code as compact.
> Forth has also done well for things like debugging hardware interfaces.
> Very interactive, easy to modify it for low-level details, etc.
I still miss the interactiveness of interpreted BASIC as compared to
assembly or C. But, you either get a compiler or interpreter - it's rare,
except for some FORTHs - to get both. Today, you have to produce compiled
code...
> 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.
Isn't the "redundant code" issue either a lack of a standardized library
or
a lack of separation of tasks?
Rod Pemberton
|
