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.
