a relational database done in forth would r0ck

Jonah Thomas wrote:
> What particularly impressed me about Forth was that if you use a very
> simple Forth that has no locals etc, bad coding practices tend to show
> up as bad right away. It takes good technique to get anything much done.

In what sense does bad coding practice show up as bad right away? Forth
is no different from any other language in this regard. Bad coding
practice (poorly factored definitions, deeply nested control structures,
undisciplined use of globals, etc.) compiles just fine if it is
syntactically correct under Forth. Where are the warning bells?

I don't believe bad coding practice in Forth (or any language) shows up
right away. I believe bad coding practice only shows up when some body
of code is extended, reworked, repackaged as a library, or in some way
changed. I don't see how Forth makes this any more obvious than any
other language.

> It's the difference between sophisticated woodworking tools that cover
> up your bad technique, versus simple tools that fail with bad technique.

It makes a nice statement, but I have yet to find any sophisticated
woodworking tool that has the ability to cover bad technique.

Bernd Paysan wrote:
> They changed the approach.

So again, I'm trying to figure out how you feel this story relates to my
point. My point, again, is that approach matters far more than
language. If your story was that the Java programmers took the *same*
approach of the Forth programmers (presumably building only what they
needed) and *then* failed, then your story would counter my statement.

> Unfortunately, in reality, most non-Forth projects don't end up with a
> Forth-like solution. Cultures are different, and many people stay in
> theirs. That's why I tend to agree with your statement that you *can*
> (theoretically) implement Forth-like solutions in other languages, but in
> reality, this usually won't happen.

But again, this has little to do with language. It has to do with the
skill and experience of the programmers.

I don't have a problem with the notion that different languages have
different cultures that drive different priorities which can produce
wildly different results. In the Java world, I've seen programmers
produce slow, bloated crap. And that's usually because the programmers
don't have an awareness of the cost of anything. But I've also seen
Java programmers who had an deep understanding of the underlying virtual
machine and the cost of library routines who were able to use that
information and create fast, tight code. Same language, different
results. That tells me the problem isn't with the language. It's with
the skill, experience, and priorities of the programmers.

Modern development practice (as seen in the agile development
methodologies) pushes forward the same agenda that Forth programmers
have for years-- simple, efficient systems that are well tested and
implement only what is needed. And those aren't just toothless generic
programming platitudes as are often expressed here in comp.lang.forth.
They are part of the development process.

The stories in comp.lang.forth about projects that go bad say little to
nothing to me. I'm not terribly surprised that there are programmers
who aren't skilled in the world. I'm not terribly surprised when the
projects they work on fail. What I am surprised at is how in
comp.lang.forth, there is a huge skepticism about anything that reeks of
being a "silver bullet." But when people hold up Forth as being the
solution, then skepticism flies out the window. The way people conflate
Forth the language with "Forth-like" techniques which are language
independent is depressing.

John Passaniti <nntp@JapanIsShinto.com> wrote:
> Jonah Thomas wrote:

> > What particularly impressed me about Forth was that if you use a
> > very simple Forth that has no locals etc, bad coding practices tend
> > to show up as bad right away. It takes good technique to get
> > anything much done.
>
> In what sense does bad coding practice show up as bad right away?
> Forth is no different from any other language in this regard. Bad
> coding practice (poorly factored definitions, deeply nested control
> structures, undisciplined use of globals, etc.) compiles just fine if
> it is syntactically correct under Forth. Where are the warning bells?

When I avoid globals and locals, it's difficult for me to wiret
poorly-factored definitions with deeply nested control structures and
make them work right. The approach is:

1. Write a poorly-factored command with nested control structures.

2. Compile the command. It fails to compile.

3. Look at the mess of nested control structures and try to figure out
what's going on. When this is hard to do, that's a good solid reminder
to factor the code into simpler pieces that are easier to figure out.

4. The multiple words with the simpler control structures now compiles.

5. Test the multiple poorly-factored commands, starting at the lowest
level and simplest of them. They don't do what I want, typically
different runs give different stack results and sometimes actual
crashes.

6. Debug the poorly-factored commands. When this is hard to do, that's
another good solid reminder to factor the code into simpler pieces that
are easier to figure out.

7. The factored code includes pieces that do almost the same thing, but
not quite. These have to be tested independently, which is a cue to get
rid of most of them and rewrite the high-level code to use just one.

8. Rewriting the high-level code is a late reminder not to spend too
much effort writing that code until after the lower code is somewhat
stable, since it will all have to be done over again anyway.

This doesn't guarantee great code, but it tends to provide early warning
about many of the mistakes.

When I first tried Forth my biggest experience was with batch Fortran. I
prided myself on my ability to keep a few hundred lines of code in mind.
I would add test code to generate intermediate output, and quickly
find my errors from that. When I tried that approach with Forth, a
16-line Forth program in one block didn't have room for complex stack
diagrams on each line and it didn't have room for much code to make
intermediate outputs. I had to factor the code before I could debug it.

Without local variables and attempting to avoid globals, I had to factor
the code to keep from being overwhelmed juggling deep stacks.

And when I looked at other people's code, they didn't have the attitude
that they were smart enough to make the complicated stuff work. They
wrote little short routines that had no purpose except to make things
easy. They didn't have to hold hundreds of lines of code in mind. They
made each step simple.

John Passaniti wrote:

> Bernd Paysan wrote:
>> They changed the approach.
>
> So again, I'm trying to figure out how you feel this story relates to my
> point. My point, again, is that approach matters far more than
> language. If your story was that the Java programmers took the *same*
> approach of the Forth programmers (presumably building only what they
> needed) and *then* failed, then your story would counter my statement.

Yes, but this is a very hypothetical assumption. The real world Java
programmers don't do this. They use the Java approach - include libraries,
and then fail, because they don't realize how constrained their environment
is. They look down on Forth and say "this is a useless language, because it
doesn't have lots of libraries, and you have to reinvent the wheel - and
even when Forth people could reuse code - like the web server - they
rewrite it". They completely fail to understand the point. That's how it
works in real live. Theoretically, I agree, that Java programmers could do
just the same, and that in this case, success is possible. But this is like
a discussion about how many angels can dance on a pin - the premise is
wrong, so the result is meaningless.

> But again, this has little to do with language. It has to do with the
> skill and experience of the programmers.

Managers pick mainstream languages to *avoid* skill and experience of the
programmers. They deliberately avoid that, i.e. they even drive the people
with skill and experience out of the project, since their opinions are just
too disturbing.

> I don't have a problem with the notion that different languages have
> different cultures that drive different priorities which can produce
> wildly different results. In the Java world, I've seen programmers
> produce slow, bloated crap. And that's usually because the programmers
> don't have an awareness of the cost of anything. But I've also seen
> Java programmers who had an deep understanding of the underlying virtual
> machine and the cost of library routines who were able to use that
> information and create fast, tight code. Same language, different
> results. That tells me the problem isn't with the language. It's with
> the skill, experience, and priorities of the programmers.

Yes, that's true. But it's again the angel dancing on pins question: If you
have 100 Java programmers in a team, 90 will write slow and crappy code.
One will write fast, tight code, and nine will be somewhere in between.
Your project is doomed, anyway, because the code of the 90 monkeys
dominates the result.

> Modern development practice (as seen in the agile development
> methodologies) pushes forward the same agenda that Forth programmers
> have for years-- simple, efficient systems that are well tested and
> implement only what is needed. And those aren't just toothless generic
> programming platitudes as are often expressed here in comp.lang.forth.
> They are part of the development process.

I certainly agree, except that I don't agree to the "toothless generic
platitudes"; Thinking Forth expressed these methodologies way before others
picked up the same ideas - because it was earlier, the methodologies are
less formalized. And the writers here are not as good as Leo Brodie or the
authors of XP/agile development/etc. books, which is not surprising ;-).

> The stories in comp.lang.forth about projects that go bad say little to
> nothing to me. I'm not terribly surprised that there are programmers
> who aren't skilled in the world. I'm not terribly surprised when the
> projects they work on fail. What I am surprised at is how in
> comp.lang.forth, there is a huge skepticism about anything that reeks of
> being a "silver bullet." But when people hold up Forth as being the
> solution, then skepticism flies out the window. The way people conflate
> Forth the language with "Forth-like" techniques which are language
> independent is depressing.

The Sapir-Whorf hypothesis tells you that languages and thinking influence
each other (actually, the hypothesis is only one direction, but QM tells
you that all influences are bidirectional ;-). I usually dismiss this for
human languages, because human languages are all remarkable similar, and
quite expressive. Computer languages however are much less similar (except
those from the same family tree), and often lack expressiveness. John Doty
comes up with the theory that Forth is unpopular because it doesn't fit
with the typical structure of a human language, but if that's true, you
can't dismiss that Forth then influences the programmer much more than a
more human-language shaped language would. This is both strength and
weakness of Forth - strength, because it makes the programmer think more
like a computer, weakness, because it alienates many potential programmers,
who don't want to think like a computer.

Once you have been influenced by Forth or another powerful language, your
programming style in other languages will change, too. But where the
expressiveness of other languages is more limited, you'll miss it. You
mentioned lua, a scripting language. There, you have a lot of similar
expressiveness, because it's an interactive language. Java, e.g. is not. On
the other hand, Java has lots of libraries, while Forth has not. That's
also a different expressiveness, which certainly has effects on
native "speakers" of these languages (notice the importance of "native"
here: Someone who speaks such a language as second language carries a lot
of the culture of his native language into it).

So while I don't accept the Sapir-Whorf hypothesis on natural languages, I
do so for computer languages. My advice to people who learn programming is
that they have to learn about 10 different languages to know all important
paradigms and ways of thinking:

* an assembler (or two to understand how they can differ)
* a more pure member of the Algol family (e.g. Pascal, Modula)
* a more pure object oriented language (e.g. Smalltalk)
* Prolog
* a functional programming language
* shell scripting
* Forth
* A library-rich language (to understand benefits and problems of this
approach), e.g. Java or Perl
* A hardware description language (like VHDL or Verilog)
* A highly popular language like C

When you have done that, the Sapir-Whorf hypothesis is not that important
anymore. But few people ever do.

--
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://www.jwdt.com/~paysan/

On Aug 27, 8:48 pm, Jonah Thomas <jethom...@gmail.com> wrote:
> This doesn't guarantee great code, but it tends to provide early warning
> about many of the mistakes.

You haven't answered my question. Let's review. You wrote this:

> What particularly impressed me about Forth was
> that if you use a very simple Forth that has
> no locals etc, bad coding practices tend to
> show up as bad right away. It takes good
> technique to get anything much done.

I asked you to provide an example illustrating how under Forth, bad
practice shows up as bad "right away." You started by describing a
monster nested control structure that didn't compile. That's called a
syntax error, and every programming language would have given you a
warning if your code didn't compile. You then go on to describe a
process that could be restated as "factor, test, repeat." And again,
I fail to see how Forth is showing you back coding practice "right
away."

Or let me ask the question a different way. You've just written a 300-
line function in language X. Are you seriously going to tell me that
only with Forth you would realize you've engaged in bad coding
practice? Or let's say you have a nested control structure that is 12
levels deep in language Y. Am I expected to believe that you wouldn't
have realized that such code would be a testing and maintenance
nightmare but thankfully some mysterious aspect of Forth was the only
thing to clue you in? How about writing code with more global
variables than you can count all with complex relationships to
conditional statements in language Z. You would helplessly write such
code in language Z, but thankfully Forth came along to tell you that
was bad?

> When I first tried Forth my biggest experience was with batch Fortran. I
> prided myself on my ability to keep a few hundred lines of code in mind.
> I would add test code to generate intermediate output, and quickly
> find my errors from that. When I tried that approach with Forth, a
> 16-line Forth program in one block didn't have room for complex stack
> diagrams on each line and it didn't have room for much code to make
> intermediate outputs. I had to factor the code before I could debug it.

Sitting in a dark corner of my basement is a box filled with old
programming books that I rarely or never use anymore. In that box is
a book about programming in Fortran 66, published around the same time
when I was in Kindergarten (1968). I enjoy keeping books like this
around because they often give fascinating insights into the past of
computer science. This book was basically a set of programming tips,
idioms, and suggestions for how to effectively use Fortran. And guess
what some of the tips are:

1. Keep subroutines short.
2. Use the mathematical notion of "factoring" to reduce redundancy.
3. Complicated streams of nested IF statements are confusing. Avoid.
4. Pick meaningful symbol names.

How radical. So at the time when you were priding yourself on keeping
hundreds of lines of code in mind, other Fortran programmers
apparently had a different view of what good coding practice was. How
could the authors of the book have come up with such advice without
Forth? Why, they must have been some kind of super geniuses...

....or not. Maybe there are some universal ideas at work here that
define "best practices" that are (largely) independent of language.
Maybe long functions, unfactored code, complicated control structures,
and stupid names are all bad ideas in any language for reasons that
become obvious the moment you write anything non-trivial.

In any case, I still don't get your point. Are you saying that if you
never came across Forth, you never would have figured out that trying
to keep hundreds of lines of code in mind was a bad idea? If so, how
is that a reflection on the language, and not you?

John Passaniti <john.passaniti@gmail.com> wrote:

> You've just written a 300-
> line function in language X. Are you seriously going to tell me that
> only with Forth you would realize you've engaged in bad coding
> practice?

Bad programmers believed that this was just the way it was. They
believed they were *good* programmers because they could get 300 line
functions to work. But a block editor that doesn't allow a function more
than 16 lines prevents that.

> Or let's say you have a nested control structure that is 12
> levels deep in language Y. Am I expected to believe that you wouldn't
> have realized that such code would be a testing and maintenance
> nightmare but thankfully some mysterious aspect of Forth was the only
> thing to clue you in?

If you assume that bad programmers are good programmers who naturally
use good technique, then you will not imagine that Forth could promote
good technique.

> Sitting in a dark corner of my basement is a box filled with old
> programming books that I rarely or never use anymore. In that box is
> a book about programming in Fortran 66, published around the same time
> when I was in Kindergarten (1968). I enjoy keeping books like this
> around because they often give fascinating insights into the past of
> computer science. This book was basically a set of programming tips,
> idioms, and suggestions for how to effectively use Fortran. And guess
> what some of the tips are:
>
> 1. Keep subroutines short.
> 2. Use the mathematical notion of "factoring" to reduce redundancy.
> 3. Complicated streams of nested IF statements are confusing. Avoid.
> 4. Pick meaningful symbol names.

That's fine. My Fortran course was careful to point out that subroutine
calls have more overhead than GoTos. They suggested keeping functions
short but not subroutines, and suggested that functions also have
considerable overhead.

Maybe there were a lot more bad programmers around in those days. I'm
glad to hear that somebody was using good technique back then. I'd never
heard of them. How nice that there are no more bad programmers today!
Though I've noticed C++ programmers tell me they always keep subroutines
short -- seldom more than one page. Or seldom more than 30 lines.

And are there programmers who sometimes make a single object with more
than 16 methods, where the overloading is not obvious? Where the hope is
that the system will choose the right methods without the programmer's
knowledge? Is this considered good practice today?

> In any case, I still don't get your point. Are you saying that if you
> never came across Forth, you never would have figured out that trying
> to keep hundreds of lines of code in mind was a bad idea? If so, how
> is that a reflection on the language, and not you?

How would I know that? Mostly every programmer thinks he's a good
programmer. It's good to make things as simple as possible, but no
simpler. How do you find out that some of your complexity is avoidable?

With batch Fortran it wasn't obvious that you did better to break things
into small pieces and test them in isolation. That required many small
runs and then assemble larger card decks. It worked to build the whole
thing and test as many parts as would execute all at once, up to your
ability to fit it together.

With Basic it made sense to test small pieces -- easy to say GOTO 2150
but it didn't make sense to have a lot of small subroutines, you'd get
code that looked like

1100 GOSUB 9850
1110 GOSUB 9920
1120 GOSUB 9810
1130 GOSUB 9970
etc.

If only Basic had line-number variables!

When you don't find a simpler way until you look for it, when you
believe what you're doing is the simplest, there you are. What Forth
gave me was a system that was too crippled to work the way I was used
to. I had to find a better way.

If you say that only bad programmers benefit from that, well OK. I never
meant to say that people who already use ideal Forth methods will learn
them from Forth.

> When you don't find a simpler way until you look for it, when you
> believe what you're doing is the simplest, there you are. What Forth
> gave me was a system that was too crippled to work the way I was used
> to. I had to find a better way.
>
So when they took away your crutches and training wheels, you found
that you could do just as well without them. Plus they weren't there
to get in your way.

-Brad

Jonah Thomas wrote:

> Bad programmers believed that this was just the way it was. They
> believed they were *good* programmers because they could get 300 line
> functions to work. But a block editor that doesn't allow a function more
> than 16 lines prevents that.

Blocks. I thought the "Forth" way was to provide all the power and
freedom, without training wheels or constraints, to the programmer.
Sure the programmer could always shoot himself/herself in the foot, but
that's life with powerful tools. I find text files to be far less
bothersome than blocks. With blocks I was frequently distracted by
running into issues of blocks management that had nothing to do with
good or bad programming practice. There may be other reasons to use
blocks files related to system type or resources or whatever. Or a
programmer may just prefer to use blocks. Fine. Go for it.


> And are there programmers who sometimes make a single object with more
> than 16 methods, where the overloading is not obvious? Where the hope is
> that the system will choose the right methods without the programmer's
> knowledge?

Is there some intrinsically magic number of methods (16?) that should
not be exceeded? If so, why? Should the Forth system invoke more
training wheels and enforce a max limit? Are there also a maximum limit
to the number of Forth words to be defined to solve a particular
problem? When overloading what would you suggest? More training
wheels? Force the programmer to declare "OVERLOAD" each time it is
done? How could the Forth system "choose" a method without the
programmer's knowledge? The rules for which methods are to be invoked
via inheritance or whatever mechanism are precisely defined. If the
programmer elects to not know these rules, then shame on the programmer.
Again, powerful tools that don't attempt to restrict the programmer.
Isn't that the "Forth" way?

Re: Locals. It appears that almost every post you make these days
denigrates them in some way. They are just another power tool that can
be used effectively, or abused, or ignored. You may want to do the latter.


-Doug

Doug Hoffman wrote:
> Jonah Thomas wrote:
>
>> Bad programmers believed that this was just the way it was. They
>> believed they were *good* programmers because they could get 300 line
>> functions to work. But a block editor that doesn't allow a function more
>> than 16 lines prevents that.
>
> Blocks. I thought the "Forth" way was to provide all the power and
> freedom, without training wheels or constraints, to the programmer. Sure
> the programmer could always shoot himself/herself in the foot, but
> that's life with powerful tools. I find text files to be far less
> bothersome than blocks. With blocks I was frequently distracted by
> running into issues of blocks management that had nothing to do with
> good or bad programming practice. There may be other reasons to use
> blocks files related to system type or resources or whatever. Or a
> programmer may just prefer to use blocks. Fine. Go for it.

Blocks were invented in the early days when Forths ran purely native on
disk-based computers. They were an incredibly fast and reliably way of
managing disk, because a block# was a computed representation of the
physical location of the data on the disk, rather than involving a
directory. You could even arrange your source and data on the disk to
take advantage of physical proximity and reduce head motion.

When Forths first became OS-hosted, blocks were retained for a period
because they maintained portability across native and hosted systems.
Nowadays there are still a few block-based Forths (Colorforth is the
best-known, as Chuck's Colorforth is a native system), but the vast
majority of modern Forths are OS-hosted and file-based.

Sure, there were issues involving block management, but there are also
file management issues. They're just different.

Cheers,
Elizabeth

--
==================================================
Elizabeth D. Rather (US & Canada) 800-55-FORTH
FORTH Inc. +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

Doug Hoffman <dhoffman@talkamerica.net> wrote:

> Re: Locals. It appears that almost every post you make these days
> denigrates them in some way. They are just another power tool that
> can be used effectively, or abused, or ignored. You may want to do
> the latter.

I ignored locals for a long time. Now I'm looking at when I want to use
them.

When I try to use locals often they let me produce a mediocre or even
good solution with less thought. When I try to avoid locals it usually
takes more thought and sometimes after a whole lot of thought I don't
come up with a better way. My current thought is to use locals for
prototypes when I want quick results, and then later, when I have a
clearer idea what I'm trying to do, remove locals from lower-level
routines and try for excellent code from the bottom up, and see whether
things improve quickly enough to justify the work.

I'll try that approach for awhile and see how it works, and then maybe
try something else.