|
|
 Up |
|
|
  |
Author: Jonah ThomasJonah Thomas Date: Mar 22, 2008 18:56
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. Don't bother your little brain about
it. And Forthers say that with a data stack we get a simpler compiler
and we get simpler subroutine calling. We're encouraged to factor
deeper, and that helps us write simpler code. And they say it isn't
simpler, programming in Forth is like solving a Rubik's cube, you're
handling details the compiler could do better and it costs you in
efficiency.
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.
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.
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...
|
| Show full article (7.61Kb) |
|
| | 476 Comments |
|
|
Author: Axel HarveyAxel Harvey Date: Mar 22, 2008 21:57
On Mar 23, 1:56 am, Jonah Thomas gmail.com> wrote:
> simpler, programming in Forth is like solving a Rubik's cube, you're
> handling details the compiler could do better and it costs you in
> efficiency.
>
> [ ... ]
>
> 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.
As for the Rubik's cube analogy I find it odd that
so many people have the same reaction. Programming
is not my first occupation, probably not even my
twelfth, but I have translated C manuals and looked
at other languages, and I know that Forth is the
simplest for me.
|
| Show full article (1.00Kb) |
|
| | no comments |
|
|
Author: Rod PembertonRod Pemberton Date: Mar 23, 2008 03:09
"Jonah Thomas" gmail.com> wrote in message
news:20080322215618.3618af65.jethomas5@gmail.com...> 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.
|
| Show full article (7.75Kb) |
| 8 Comments |
|
|
Author: Paul E. BennettPaul E. Bennett Date: Mar 23, 2008 04:20
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.
|
| Show full article (5.45Kb) |
| no comments |
|
|
Author: Marcel HendrixMarcel Hendrix Date: Mar 23, 2008 03:50
"Rod Pemberton" writes Re: The Promise of Forth
[..]
> 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?
Exactly 50%% of any generation will have an IQ below 100 :-)
[..]
-marcel
|
| |
| no comments |
|
|
Author: Jonah ThomasJonah Thomas Date: Mar 23, 2008 05:23
Axel Harvey wrote:
> Jonah Thomas gmail.com> wrote:
> >> simpler, programming in Forth is like solving a Rubik's cube, you're
>> handling details the compiler could do better and it costs you in
>> efficiency.
>>
>> [ ... ]
>>
>> 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.
>
> As for the Rubik's cube analogy I find it odd that
> so many people have the same reaction. Programming
> is not my first occupation, probably not even my
> twelfth, but I have translated C manuals and looked
> at other languages, and I know that Forth is the
> simplest for me. ...
|
| Show full article (2.60Kb) |
| no comments |
|
|
Author: Andrew HaleyAndrew Haley Date: Mar 23, 2008 05:58
Jonah Thomas gmail.com> wrote:
> 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...
|
| Show full article (1.50Kb) |
| no comments |
|
|
Author: Jonah ThomasJonah Thomas Date: Mar 23, 2008 07:11
"Rod Pemberton" wrote:
> "Jonah Thomas" gmail.com> 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.
|
| Show full article (13.66Kb) |
| no comments |
|
|
Author: Jonah ThomasJonah Thomas Date: Mar 23, 2008 09:16
> Jonah Thomas gmail.com> wrote:
> >> 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.
>
> Do you have any actual data or experience to support this, or is it
> just what you've heard from somewhere? ...
|
| Show full article (4.50Kb) |
| 2 Comments |
|
|
|
|
|
Author: Andrew HaleyAndrew Haley Date: Mar 23, 2008 09:45
Jonah Thomas gmail.com> wrote:>> Jonah Thomas gmail.com> wrote:
>> >>> 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.
>>
>> Do you have any actual data or experience to support this, or is it ...
|
| Show full article (4.16Kb) |
| no comments |
|
|
|
|
