On Aug 16, 3:20 pm, gavino gmail.com> wrote:

I work with a guy who states he is relatively weaker in C than the
other engineers at work. He's not dumb, but he does tend to get
distracted by the details. He commented once that he admired that I
and others can just glance at a screen full of C and quickly figure
out what it does. I explained that when reading source code in any
language I know (and languages I don't), what I'm looking for are big-
picture kinds of things. If I want to know what a block of code does,
I'm going to look at things like symbol names and comments. I'm going
to look for control structures-- what are the predicates in "if"
statements; what are the control variables in a loop; what arguments
are being passed in; what values are being returned. Once you get
this gross sense of what the code does, *then* you can dive into the
details and figure out what you need to know.

It's no different with Forth. Take this word from code you're looking
at:

: rework-%% ( add - ) { url } base @ >r hex
0 url $@len 0 ?DO
url $@ drop I + c@ dup '%% = IF
drop 0. url $@ I 1+ /string
2 min dup >r >number r> swap - >r 2drop
ELSE 0 >r THEN over url $@ drop + c! 1+

I find this code readable. It's standard Forth, nothing really exotic
here. There are some private words ($@len, $@, $!len), but I can
guess what they do from the names and context. There is a lot of
stack noise, but that par for the course for lower-level words like
this.

But let's say I didn't know Forth well, and I didn't know Forth
idioms. When I look at this word, I start by looking at gross
structure. I see the number base being changed to hex, but don't see
any hex numbers, which suggests that the code either inputs or outputs
hex numbers. I don't see any obvious output statements, but do see

loop. I don't yet know what $@len is, but from it's name and from the
preceding "url" I'm guessing that the loop iterates over the length of
the loop. Inside the loop I see an IF, and so I look for the
predicate. Here we're apparently comparing something to a %%
character. And since this is a URL, and since as you should know
characters in a URL are encoded with %% followed by two hexadecimal
characters, this should give you a very strong clue as to what the
code does.

So you start with the big picture. And in this case, if you don't
know the underlying HTTP protocol and if you don't understand how a
web server works, then none of this is going to make any sense to
you. Like with anything, if you don't understand the domain and the
problem being solved, then understanding the code probably isn't going
to help you much.

Unfortunately for the novice, when you get past the big picture and
dive into the details, Forth pretty much forces you deal with even the
most mundane issues. Here we have lots "stack noise." In other
languages, you only see this if you choose to look at the underlying
details. In Forth, you see it all. This is both a strength and
weakness of the language.

You're right, and this is something I (and I believe others) told you
quite some time ago when you first gushed over the fact that someone
wrote a web server in Forth. And noting the size and complexity of
web servers like Apache, your mind seemed to latch onto the notion
that by simply writing a web server in Forth, it would be faster,
smaller, better, more chocolately. But that's okay. It's a repeated
theme here in comp.lang.forth. There are *lots* of people here who
love comparing apples with oranges, often resulting in nonsense that
doesn't survive even a casual analysis.

What Bernd gives you with his code is a stripped-down, bare-essentials
web server for Unix or Unix-like systems, suitable for light-duty work
or embedded systems. Great stuff for what it is, but modesty isn't a
common attribute with Forth programmers. He claims he has "delivered
an ``almost'' complete Apache clone." Ummm, no. What he has done, at
best, is recreated the functionality of those specific parts of Apache
that he cares about. That's a very different thing.

He's only running a single site so he doesn't support virtual hosts or
bother parsing the "Host" header. He doesn't care about respecting
caching, so he has no code to support that. He doesn't care about
mapping URLs, SSL/TLS encryption, session authentication, or content
negotiation. He only cares about text/html, so other media types
(like images) can be handled with another server. And while no inetd
server would survive a site being Slashdotted or Digged, he doesn't
care-- this is code that goes into an Internet-enabled refrigerator.

The claim that his code is an "almost" complete clone of Apache
bothers me for the same reason I'm bothered when someone in
comp.lang.forth states with horror that a "Hello World" program in C
resulted in a megabyte (or more) of code. Ignoring the usual
comparisons of apples and oranges (or in the case, specific-function
bare-metal embedded systems and generalized server/desktop operating
systems), we have people who confuse actual code with debugging
support symbols. We have people who confuse actual code with headers
specifying things like libraries to link, relocation tables, and so
on. Oh, and we have people who don't understand that functions like
printf are an interpreter for a formatting language, and functions
like puts is just a loop over a character string. But details like
that don't interest the Forth-faithful. They want to hear short,
punchy stories about Forth. Doesn't matter if they are true, if they
can be verified by anything more than nth-person anecdote, or if they
even make logical sense.

My point is this: When conversations here in comp.lang.forth make
meaningful comparisons and are rationally qualified, I have no
problem. You tell me that Bernd's web server is a useful tool for
embedded systems and it implements a useful subset of the features of
Apache that Bernd cares about, and I'll agree with you. But you tell
me that it's a "almost" complete clone of Apache, and I'll point out
every real-world feature Apache has that Bernd's server doesn't.

gavino, in the past, you would periodically write messages in
comp.lang.forth asking questions of the form "can this be done in
Forth" applied to web servers and databases and other applications.
In response, I and others told you yes, and that if you wanted to
understand this better, you should learn Forth. Well, now it looks
like you're actually doing that, and you're hopefully learning both
the strengths and weaknesses of Forth. Congratulations!

Now it's time for the next step. It's time to get skeptical. It's
time to take people's claims and hold them up to the light. It's time
to look at the edges, where unqualified statements usually fall flat.
You've started tha