Thinking Factor beats Thinking Forth

[WJ]

On physical page 71 of the pdf file, Brodie presents a problem.

All charges are computed by the minute, according to distance in
hundreds of miles, plus a flat charge. The flat charge for
direct dial calls during weekdays between 8 A.M. and 5 P.M. is
.30 for the first minute, and .20 for each additional minute; in
addition, each minute is charged .12 per 100 miles. The flat
charge for direct calls during weekdays between 5 P.M. and 11
P.M. is .22 for the first minute, and .15 for each additional
minute; the distance rate per minute is .10 per 100 miles. The
flat charge for direct calls late during weekdays between 11
P.M. or anytime on Saturday, Sundays, or holidays is .12 for the
first minute, and .09 for each additional minute; the distance
rate per minute is .06 per 100 miles. If the call requires
assistance from the operator, the flat charge increases by .90,
regardless of the hour.


On physical page 263, Brodie gives a "solution" that is
no solution.


Screen # 103
0 \ Telephone rates 03/30/84
1 CREATE FULL 30 , 20 , 12 ,
2 CREATE LOWER 22 , 15 , 10 ,
3 CREATE LOWEST 12 , 9 , 6 ,
4 VARIABLE RATE \ points to FULL, LOWER or LOWEST
5 \ depending on time of day
6 FULL RATE ! \ for instance
7 : CHARGE ( o -- ) CREATE ,
8 DOES> ( -- rate ) @ RATE @ + @ ;
9 0 CHARGE 1MINUTE \ rate for first minute
10 2 CHARGE +MINUTES \ rate for each additional minute
11 4 CHARGE /MILES \ rate per each 100 miles

Screen # 104
0 \ Telephone rates 03/30/84
1 VARIABLE OPERATOR? \ 90 if operator assisted; else O
2 VARIABLE #MILES \ hundreds of miles
3 : ?ASSISTANCE ( direct-dial charge -- total charge)
4 OPERATOR? @ + ;
5 : MILEAGE ( -- charge ) #MILES @ /MILES * ;
6 : FIRST ( -- charge ) 1MINUTE ?ASSISTANCE MILEAGE + ;
7 : ADDITIONAL ( -- charge) +MINUTES MILEAGE + ;
8 : TOTAL ( #minutes -- total charge)
9 1- ADDITIONAL * FIRST + ;


Look at this:

VARIABLE RATE \ points to FULL, LOWER or LOWEST
\ depending on time of day

Of course, the comment is wrong. It also depends on whether
the day is a weekday.

There is no code here that accepts a time of day and a boolean
to indicate a weekday and that then selects the proper rate.

The source is broken up into so many tiny pieces of code
that it is hard to understand how they interact and fit
together. This is a type of spaghetti-coding.

Look at this:

0 CHARGE 1MINUTE \ rate for first minute
2 CHARGE +MINUTES \ rate for each additional minute
4 CHARGE /MILES \ rate per each 100 miles

What is the significance of the 0? Of the 2? Of the 4?
Are you telling me that the programmer has to tell the
compiler the offset in bytes for each integer that he
is storing? What a damned, pitiful language. What a
damned, pitiful programmer.

This language is not designed to make things easy for the
programmer. It is designed to make things easy for the
implementor of the language. To hell with the programmer.



Factor:

USING: math.parser locals splitting ;

: full-rate ( -- base rate dist-rate ) 0.30 0.20 0.12 ;
: low-rate ( -- base rate dist-rate ) 0.22 0.15 0.10 ;
: lowest-rate ( -- base rate dist-rate ) 0.12 0.09 0.06 ;

:: determine-rate ( time-of-day weekend? -- x y z )
weekend?
[ lowest-rate ]
[ time-of-day ":" split first string>number :> hour
{ { [ hour 8 16 between? ] [ full-rate ] }
{ [ hour 17 22 between? ] [ low-rate ] }
[ lowest-rate ]
} cond
] if ;

:: calc ( base rate dist-rate minutes distance operator? -- x )
dist-rate distance * minutes *
rate minutes 1 - *
base
operator? 0.9 0.0 ?
+ + + ;

:: calc-charge ( minutes time-of-day distance weekday? operator? -- x )
time-of-day weekday? not determine-rate
minutes distance operator? calc ;

10 "09:33" 1 t t calc-charge .
4.2

10 "19:33" 1 t t calc-charge .
3.47

10 "23:33" 1 t t calc-charge .
2.43

10 "09:33" 1 f f calc-charge .
1.53

[A.K.]

Factor seems to create euphoria. Good for those addicts. ;-)

[rickman]

No, actually, that's not right. You need to read the problem more
carefully. The solution Brody posts is for the charge calculation. It
does not cover how the various variables are updated for a given call.
The price for weekend/holiday calls is the same as for weekday calls
between 11 PM and 8 AM, "LOWEST". So the comment is basically correct.
I'm not going to fault him for not spelling out the entire problem
again in the comments.

> There is no code here that accepts a time of day and a boolean
> to indicate a weekday and that then selects the proper rate.

That's right because that is being left to the portion of the problem
that deals with noting the nature of a call. That code just selects
FULL, LOWER or LOWEST based on the time and the day of the week, let's
call it "time of the week".

> The source is broken up into so many tiny pieces of code
> that it is hard to understand how they interact and fit
> together. This is a type of spaghetti-coding.

I may not be a newbie, but I am no expert at Forth and I don't have any
trouble understanding what he is doing. BTW, breaking the code down
into bite sized pieces is call "factoring"... that name sounds familiar
somehow...

> Look at this:
>
> 0 CHARGE 1MINUTE \ rate for first minute
> 2 CHARGE +MINUTES \ rate for each additional minute
> 4 CHARGE /MILES \ rate per each 100 miles
>
> What is the significance of the 0? Of the 2? Of the 4?
> Are you telling me that the programmer has to tell the
> compiler the offset in bytes for each integer that he
> is storing? What a damned, pitiful language. What a
> damned, pitiful programmer.

Have you been coding much in Forth? This is not much of a criticism.
The only exception I would take to this is that he should have been
using CELLS or CELLS+ with 0, 1 and 2 rather than specifying the byte
offsets. But then, I don't know when CELLs started being used and I
know Brodie's books are fairly old.

> This language is not designed to make things easy for the
> programmer. It is designed to make things easy for the
> implementor of the language. To hell with the programmer.

Lol! When Forth was created that was the same person!

What are you trying to show here? Obviously I don't know this language,
but I see no reason why this is inherently better or easier.

BTW, your solution has the same "problem" that you complained about in
Brodie's code. The rate depends not only on the time of day and the day
of week, but also on whether it is a holiday! So clearly your weekday?
variable is more than just "is it a weekday?"

--

Rick

[Brad Eckert]

On Wednesday, April 10, 2013 7:02:22 AM UTC-7, rickman wrote:
> On 4/10/2013 9:10 AM, WJ wrote:
>
> No, actually, that's not right. You need to read the problem more
> carefully. The solution Brody posts is for the charge calculation.

You're responding to a straw man argument. Don't bother.

[rickman]

I notice that WJ has been posting some programming challenges, but I
haven't really read them. Is he coming here looking for an argument?

--

Rick

[Sieur de Bienville]

On Apr 10, 11:55 am, rickman <gnu...@gmail.com> wrote:
> I notice that WJ has been posting some programming challenges, but I
> haven't really read them.  Is he coming here looking for an argument?
>
> --
>
> Rick

Well, he posted this "challenge" with the sole seeming purpose to
insult both Forth and Forth programmers. It sounds like he wants
a fight. He should probably be plonked instead.

Virtually,
Michael Morris

[daveyrotten]

Seems like to be fair you should also include all parts of the mysterious math.parser, locals, and splitting that are being used. Then let's see how easy those are to understand. I don't think Brodie employed any secret, behind-the-scenes code in his solution, did he?

[rickman]

Yeah, I had time now to go back and look at his other posts. They were
out of context posting of programs with few responding. The few that
did respond to his posts didn't get direct replies from him.

I can't say I understand what his point is.

--

Rick

[Pablo Hugo Reda]

WJ is a good point for NOT programing in FACTOR..
I try FACTOR some years ago and I feel like a good idea (the forth simplification) crash with a bad idea (bloating software and others..) and the result is a mess.
I encourage to WJ to promote FACTOR in comp.lang.c or comp.lang.java or others when the people not have a good languaje for programing..

[Bernd Paysan]

rickman wrote:

>> The source is broken up into so many tiny pieces of code
>> that it is hard to understand how they interact and fit
>> together. This is a type of spaghetti-coding.
>
> I may not be a newbie, but I am no expert at Forth and I don't have any
> trouble understanding what he is doing. BTW, breaking the code down
> into bite sized pieces is call "factoring"... that name sounds familiar
> somehow...

A coworker of mine, who used to program pretty flat, without much factoring
(things like multiplication and division were factored), and had learned
programming with Fortran; when first exposed to Forth, he complained to
another one that "Forth is really horrible - the whole program is decomposed
in subroutines of subroutines, and to understand it, you must know them
all".

He was exposed to Forth, since he had to use the processor emulator I wrote
to debug his PIC program (written as perfect spaghetti code - the main
routine was a few thousand lines long ;-). However, as he added a few words
to the simulator for debugging his code, all of the words he wrote were neat
little one-liners.

Seems to be something you just have to overcome as newbie. IMHO, the mental
problem WJ addressed here is that in Forth, programming is a tool-building
exercise, while WJ has just the tool-user mentality. His Factor examples
show that - it's always "include some magic" plus some code using the pre-
fabbed magic.

Maybe as schoolboy magican you can get along with pre-fabbed magic. You buy
your wand in diagon alley, you buy a few books there, where you can learn
pre-fabbed spells (some common spell library the wand maker must have
installed on the wand), the magic plants come from the greenhouse of Mr.
Sprout, and you steal the incredients of magic potions from Snape's
dungeons.

--
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/

[Zbiggy]

In comp.lang.forth, Sieur de Bienville wrote:

> Well, he posted this "challenge" with the sole seeming purpose to
> insult both Forth and Forth programmers. It sounds like he wants
> a fight.

He must be very unhappy - poor thing... :'(
--
The consensus was, as usual in this community, that there is no consensus. (RA)