John Passaniti
JapanIsShinto.com> wrote:
> 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.
I told you about my experience. I don't know what more you'd want.
>> 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".)
I described it and you said I didn't.
> 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. They came to me quickly with Forth. I certainly don't claim
I could never have found them any other way.
> 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.
I found I could write Forth in other languages. But often there's some
overhead. When functions require arguments, it's like writing a stack
diagram for every single word in the definition. (But you can put them
in any order, so juggling the stack isn't an issue. And you can give
them descriptive names.) When intermediate results that will be used
again each demand a name, I have to define locals for each of them which
is tedious. Various little things that add up to more verbose code and
more chances to make mistakes. But those things aren't show-stoppers,
they just slow down the process some.
I've been interested in things from other languages that don't come
naturally to Forth. I've found regular expressions gave a tremendous
amount of power and a tremendous ability to allow rare strange errors,
for example.
>> 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".
I'm real unclear what you're looking for. I found it difficult to keep
track of items on the stack, particularly when the stack got deep.
Factoring let me keep individual routines simple enough to debug. I
could have done that using lots of global variables, but compared to
languages that implicitly define a variable when you use it, that was
tedious and it was obviously wasteful. I could make a large Fortran
program work because I was good at holding the whole thing in mind. (And
also I divided it up into logical pieces that fit together in obvious
ways.) With batch Fortran I had no big advantage submitting lots of
little jobs instead of one big one. I thought I was good at what I did
because I could handle a lot of complexity -- some people could do that
and some couldn't, and I was special because I could. Nobody told me
different. I couldn't do that with Forth. The stack was too hard to
juggle in complex ways. When I added print statements to see what was
going on, they added too much complexity themselves.
Apparently you weren't making those mistakes so you didn't see how Forth
discouraged them. Good for you!
> 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.
Forth was special in that regard. I could have achieved the same results
in pretty much any language once I got the idea that those were the
results I should look for. Forth strongly encouraged that idea. Maybe
there are other languages that strongly encourage that idea but I hadn't
tried them. APL encouraged short routines but I didn't learn the
character set well enough to read it easily, and I wound up writing
short routines I couldn't understand later. I had to trust they did what
i wanted, or look at them so carefully it was faster to rewrite them.
Probably if I'd spent more time with it I would have learned it better.
> 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.
That sounds interesting! I'd like to try it.
