Re: The Promise of Forth
- From: Jonah Thomas <jethomas5@xxxxxxxxx>
- Date: Sun, 23 Mar 2008 10:11:02 -0400
"Rod Pemberton" <do_not_have@xxxxxxxxxxxxx> wrote:
"Jonah Thomas" <jethomas5@xxxxxxxxx> wrote
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.)
Forth could be considered the assembler for a simplified virtual
machine. Designed to be easily extendable.
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.
Done right, this is not a time issue for Forth. It takes as long to
define your variables as it does to comment your 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.
Carefully-written Forth compilers come within shouting distance of C.
Pretty impressive considering how few Forth programmers are involved in
writing them.
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.
Sure. It only works for the people it works for. Before I started using
Forth I thought the biggest thing that made me good at programming was
that I could hold a lot of detail in my mind at once. I could look at
the output of a complicated buggy program and easily guess where the
problems were, and fix them. When I tried Forth I started with a Forth
system that came with 8 pages of documentation. There were two pages
that listed the commands with short comments about what they did, and 6
pages that explained how to write a colon definition, CREATE DOES>
VARIABLE CONSTANT and control structures. I picked up that stuff pretty
quick but my coding methods didn't work. I'd write a long string of code
and get stuck in stack comments 17 items deep. It was slow and
confusing. I thought, other people can write in Forth, why can't I? Are
they smarter than me? I didn't want to admit I wasn't smart enough to do
it, so I kept trying. It didn't work. Then I tried to make it as simple
as I could hoping I could at least get something done that way. And that
was just fine. All of a sudden I was getting stuff that worked, that
very often worked right the first try. The smaller the procedure, the
more likely it worked right the first time.
I think a lot of people say "I'm smart and I'm good at what I do, and
Forth doesn't work for me. So Forth is bad." Maybe some people who're
not good at other computer languages would be good at Forth because some
of the needed skills are different.
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:
If you use global variables and you don't initialise them, you can
occasionally run into hard-to-find bugs when you re-use a name and
clobber some of your results.
If you use global variables and you do initialise them, you have the
bother of initialising them each time and the possibility you'll make
mistakes doing that. But it will tell you when you re-use a name that's
in scope. There's a place for global variables but it's better not to
overdo it.
If you use locals then you have to initialise them each time. Most Forth
routines ought to be short enough that you get very little benefit from
locals. There's a place for local variables but it's better not to
overdo it.
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?"
If it's harder for you, you don't have to do it that way. In Forth you
can define as many variables as you want and use them. If you don't like
having to do @ ! on variables, you can use values that present their
data and you use TO [name] to put new data in. Or you can use locals
that do the same thing.
VALUE A
VALUE B
VALUE C
: 2+2=4
2 TO A
2 TO B
A B + TO C
C . ;
This looks kind of ridiculous to me, but it works.
10 a=2
20 b=2
30 c=a+b
40 print c
It's more complicated than the same thing in Basic because you have to
declare your values first.
: 2+2=4
2 2 + . ;
Is this really harder? As long as the routine is simple, it shouldn't be
hard.
10 PRINT 2+2
You can do some simplicity in Basic, too.
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?
It's a problem. To some extent you have to understand what's come before
or you won't know which problems are unsolved. You can spend your life
re-inventing the wheel. But when it takes too long to understand that,
it's bad. So we have a continual process where we try to simplify the
existing knowledge to make it easier to learn, so we'll have the
headspace to learn more. Sometimes we wind up throwing away stuff that
could be useful because nobody has the time to learn it. I noticed that
with microbiology, there are lots of things from the early 1900's and
late 1800's that you can sort of read about now, but that nobody really
follows anymore. Work done on bacterial cultures that nobody maintains.
If you look you could surely find similar cultures, and if you try you
could figure out enough of how they were grown to get similar results,
and you could do a lot more with the new methodologies -- but nobody
has.
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.
Figuring out how the math worked has been good for me. It provided
techniques that have been useful for other things too. Sometimes they're
useless -- mathematical reasoning is if anything worse than useless for
legal problems, for example -- but often it works. YMMV.
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.
So, simple factoring doesn't work well for management. Try to divide a
problem into pieces and assign them to different people, and the people
tend to want job preservation, which means their part of the problem is
never actually solved but only managed. It's hard to divide up the
problem into pieces with clear interfaces, so one guy can do sneaky
sabotage that gets the failure blamed on somebody else. Without a clear
method to detect quality, how can they pay for quality? If they're
likely to get shoddy work even with high pay, why not pay less and still
get shoddy work?
It's a problem and Forth doesn't give us a solution. Find a good
solution to the management problem, start a company, build it up, split
it into two good companies, build them up, in 5 generations you might go
a long way toward taking over the country.
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.
Yes, and when that gets done well Forth might be driven out of that
market niche. Why pay for a Forth expert when you can get results that
are almost as good by hiring an average C programmer and giving him a
great compiler?
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...
With some modern Forths you can produce compiled code and still keep it
supremely interactive. Even on a small microcontroller.
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.
Isn't the "redundant code" issue either a lack of a standardized
library or a lack of separation of tasks?
Yes. If you already have a good standardised library then everybody can
use what they need from it. Or if you have a standardised library that
partly fits the needs everybody can contort their code around it. If
you're building the special-purpose library for the particular project,
somebody has to notice what's needed and build the library, except
everybody else is busy coding while the library is being built. You
don't always know what you'll need until you see it being used.
Separation fo tasks at least keeps people out of each other's way. But
there are likely to be libraries that could be profitably used within
the different separate tasks. You lose some chances for simplification
if you don't follow up on that. The more people involved, the harder it
gets to keep it simple. The "surgical team" approach can help. Get one
great programmer in at the beginning, who organises the project, and
then bring in assistants as he finds use for them. They can design
widgets for him. The lowest-level code is the most likely to be mostly
independent.
.
- References:
- The Promise of Forth
- From: Jonah Thomas
- Re: The Promise of Forth
- From: Rod Pemberton
- The Promise of Forth
- Prev by Date: Re: Creating and using arrays - again
- Next by Date: Re: The word RECURSE
- Previous by thread: Re: The Promise of Forth
- Next by thread: Re: The Promise of Forth
- Index(es):
Relevant Pages
|
