Bernd Paysan wrote:
> John Passaniti wrote:
>> So it's the approach and not the language that provides the performance
>> you admire. And that performance comes from implementing only what is
>> needed. Of course, the question of what is needed is relative.
>
> I would tend to agree on that, but I know better from real world stories,
> including this web-server-on-Forth thing: Two of the people in the Munich
> Forth group implemented a smart card with an embedded web server in Forth -
> one was responsible for porting Gforth EC to it, and the other to rewrite
> the web server (it was a complete rewrite - that's completely ok, the main
> purpose of such small web servers is to give people the idea *how* to code
> purpose-specific software). There was another guy from that company also
> working on the project, so in total three people.
>
> They succeeded to build a demo, and then upper management decided to create
> a real product; first thing they choose is to switch to Java instead, and
> then put a lot more people on the project. They failed to deliver even what
> the Forth-based demo could do.
I'm not sure how this "real world story" negates the point (the "but" in
your first sentence) I made and that you "tend" to agree with. My point
is that approach matters far more than language. You gave a story that
doesn't indicate that the Java-based solution followed the same approach
as the Forth-based demo. Instead, you stated they changed language and
added people; you stated nothing about the similarity taken in the
approach. So how does your "real world story" invalidate the point?
> You can often implement Forth-like strategies in other languages to get to
> the same effect. However, you have to know these strategies.
These strategies *are* known. If they are actually followed is a
separate matter. Most of the strategies commonly associated with Forth
programmers are part of modern software development practice. Agile
methodologies in particular echo virtually every "best practice" Forth
programmers have.
Those who care more about keeping score or passing out awards will note
that Forth was there first, pushing forward this agenda years ago. Yea!
Those who care more about results don't care about historical
timelines-- they just follow these strategies and get the same results
regardless of language.
It also needs to be pointed out the key here is knowing the strategies,
not using Forth. This is the point I don't think gavino gets. He (and
plenty of others) seems to think that if you merely recode an
application in Forth, it magically gets smaller, faster, better. These
people confuse the tool for the skill in using the tool. They are the
same people who think if they go to the hardware store and buy the most
sophisticated woodworking tools, they will instantly become world-class
carpenters.
> Often enough,
> it's then easier to do it in Forth, instead of making another language
> behave as much like Forth as you need for the project (typically, you need
> at least some text interpreter).
I make no argument against the idea that doing Forth-like things in
Forth is best. My argument is that "Forth-like" really has little to do
with Forth.
