On Mar 23, 3:09 am, "Rod Pemberton" <do_not_h...@[EMAIL PROTECTED]
> wrote:
> "Jonah Thomas" <jethom...@[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
you sound like one smart d00d
laplace trandforms! woa, and I thought I knew some math...
|
