Re: a relational database done in forth would r0ck

Jonah Thomas wrote:
John Passaniti <john.passaniti@xxxxxxxxx> 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.

Bad programmers are a constant in *any* language. They are bad because they ignore best practices, lack experience, and ignore the experience of others. Your claim is that Forth somehow magically provides feedback to bad programmers that they are engaging in bad practices. And you still haven't demonstrated that claim.

A block editor doesn't constrain the programmer to words of just 16 lines. Every Forth system I ever used that offered blocks had an immediate word like "-->" which loaded the next block or a word like "thru" which loaded a span of blocks. And even if a word's definition was limited to a page, it says nothing about the number of definitions a programmer could write in an application. All your definitions might be wonderfully short, but the overall application might still be poor because you've written far too much code to solve the problem. Forth doesn't stop you. No warning bells ring if you've crossed some threshold of complexity.

Regardless, most Forth development these days is not under blocks. But that's fine because the number-of-line constraints you apparently love of old-school Forth development have been a part of programming for years and continue today. I remember watching a interview with Gracie Hooper saying that she knew a routine was probably too complicated if it was more than an "pinch" worth of punch cards. Programmers pounding out code with their DECWriter terminals would know things were getting out of control if it took more than a page of green-bar paper. And until bitmapped displays with arbitrary windows existed, every video terminal system had a fixed line limit.

So those soft limits were always there. And they are *still* there. Programmers have warned for years against exceeding such obvious limits of terminal screen size. Such a concern didn't spring from Forth block editors.

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.

No, I'm assuming that you're making (yet another) unsupportable argument in comp.lang.forth that appears to come from taking your personal experience and projecting it on others. And I'm assuming because you continue to avoid answering the question (how Forth makes bad programming practice show up "right away".)

It's great that Forth made you a better programmer. But the realizations you came to (such as managing code with definitions spanning hundreds of lines is a bad idea) would have come to you regardless of the language you used. Or at least they would have come to you if you followed the best practices of pretty much every programming language on the planet.

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.

Depending on the platform, functions could have a lot of overhead. But in the late 1960's when the ideas behind structured programming were taking hold, it was a cost that was gladly taken as it was less than the cost of unmaintainable programs.

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.

There are plenty of bad programmers today. But one key difference (and important to this discussion) is that most *know* they are engaging in bad practices. They just don't care. And there is another class of bad programmers today-- those who don't understand the underlying machine. But that's a separate discussion.

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?

I'm not sure where your magical limit of 16 methods comes from. Most references I have to what is considered good practice with objects focuses not on arbitrary limits, but on minimal interfaces. When the focus isn't on arbitrary limits (like your beloved Forth blocks) but instead on doing only what is necessary to solve the problem, you end up with better systems (and better programmers).

Or put another way, I would much rather a programmer not keep stupid arbitrary limits in their head ("no word more than 16 lines!") and instead use those brain cells to *think* about their choices. I'd much rather programmers engage in "thoughtful programming" than mindlessly following rules without understanding *why*.

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?

How? You write code. You gain experience. You learn by reviewing your own code, and the code of others. You seek out and study best practices. You gain a bit of humility when you see programmers write better code than you. You teach others what you've learned, forcing you to express the ideas concretely.

It's how I developed my skills, and it's how anyone who is even moderately successful at what they do got there.

The difference between you and me appears to be that you strangely attribute your learning to Forth and the perceived limits you think it held you to. I on the other hand, learned my lessons by seeing that there are some basic, fundamental, underlying principles that are completely language independent. I think that gave me a much more powerful message, because I can carry that forward regardless of what language I'm using. You seem to be stuck thinking these lessons are somehow bound to 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.

But you still haven't demonstrated how Forth was "crippled". Blocks weren't a limitation as you had the ability to span blocks. The fixed number of lines on your screen wasn't any more a limitation than any other programming language.

The crippling was in your mind. It was never in Forth. And when you realize that, you can see that you could have achieved the same results in pretty much any language if you applied the same limits. And that's a far more powerful message than imagining Forth is somehow special in this regard.

There is a certain truth to the notion that being constrained-- even when those constraints are artificial-- can open up one's mind to better (or at least different) ways of thinking. I love constrained programming contests (such as the Obfuscated C code contest) because ignoring the silly obfuscation aspect of that particular contest, the size limits for the code force the programmer to think differently.

One of the things I've been thinking about recently is coming up with a constrained programming contest for Forth that challenged assumptions and forced people think differently. For example, most Forth programmers are concerned (sometimes overly so) with space and time efficiency. But here's a question: What would happen if that wasn't the concern? Say that space and time didn't matter. Instead, what mattered was how fast you could code a correct solution. Or let's say we challenge the notion of the "lone wolf" programmer by coming up with a contest that forces collaboration (and thus forces communication, delegation, common definitions of interfaces, etc.). I'd love to see how such a contest would affect the thinking and priorities of programmers.
.

Relevant Pages

  • Re: CollabRx seeks brilliant engineers for an excellent e-science adventure
    ... belief that lisp programmers are smarter/better. ... Java or PHP programmers. ... a type of language that attracts a personality that meets my perceptions ...
    (comp.lang.lisp)
  • Re: Question concerning object-oriented programming
    ... programming language, not his. ... there has usually been a toString. ... I know it's "unrealistic" to expect actual programmers to do this, ... tell me what a dog is. ...
    (comp.programming)
  • Re: Does Python really follow its philosophy of "Readability counts"?
    ... with enforcing that "shouldn't" in the language itself? ... In Python, direct access to pointers is a MUST NOT. ... where you are allowed to mess with the implementation. ... human assembly language programmers? ...
    (comp.lang.python)
  • Re: FORTH levels
    ... Most working on a collaborative project do not choose the programming language they are using: it is thrust upon them by the needs of the collaboration. ... When Iverson and Hui came up with J-- in part to remove APL's special character set and make it more "user friendly" not much of a community formed around it. ... And people who are by not by any reasonable stretch of the term "programmers" seem to take to Perl. ... But RPN does not require a visible stack, any more than any language requires a visible stack to rebuild its semantic trees from its flat expression. ...
    (comp.lang.forth)
  • Re: Common Lisps fixable issues?
    ... language by following its syntax and API specification and mistakenly ... assuming they reflect current best practices. ... Now, since I'm learning Common Lisp, I'd like to ask more experienced ... programmers which features they think don't reflect best practices ...
    (comp.lang.lisp)