Jonah Thomas wrote:
> 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.
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.
