Re: advantages of forth over other languages

On Oct 3, 9:42 pm, John Passaniti <n...@[EMAIL PROTECTED]
> wrote:
> hel...@[EMAIL PROTECTED]
 wrote:
> > Many of the seen disadvantages are the advantages someone else sees.
>
> Sure.  But that doesn't make it any less of a disadvantage to the person
> evaluating it.  My point is simply that you can't approach comparing
> languages in terms of absolutes.  When a Forther proudly declares that
> with Forth you can have direct access to the hardware, that's a clear
> advantage for embedded systems programming, but is little advantage to
> someone doing (for example) web-applications.  That's a singular
example.

Well, I do have applications far from "embedded" market. You can see
them. Send me a private mail and I dont have any problems to show you.
For some reasons I can not publish it freely (even I want it!), since
it uses databases that are not in public now.

> > I seriously think that Forth needs to go away from that "only good for
> > embedded applications" image. Also in embedded world memory and
> > processor power gets cheaper and cheaper and the need for a small i.e.
> > Forth decreases with every month.
>
> Forth gets away from the "only good for embedded applications" when
> there is demonstrated evidence to the contrary.  Don't tell me that
> Forth can compete favorably in those other domains-- show me the
> applications.  What most people in comp.lang.forth seem to be doing is
> to say, "Forth works well for me in my embedded systems work, so clearly
> it must scale well and be competitive in other domains."  Prove it.

I'd have no problem. I use Forth for language research - mainly
ancient egyptian. One of the problems is that of course most people
can not estimate how interesting the software really is since they
dont do research in ancient egyptian language...

> > But how common are these languages?
>
> Depends on the problem domain, doesn't it?  Take one problem domain--
> web applications-- and you'll find that C is a minority language there.
>   Most anything serious in that problem domain is based on a scripting
> language (or if you believe Sun, Java).

Well the problem with Forth seems more that it is too unknown. More
publically available information, free of fee, systems free of fee are
needed. Most implementors follow their own problem domain. That's also
what I do (while I try to cover as much problem domains as possible or
at least that make sense for me). Gforth unfortunately is not really
the solution imho. There is the difference between say gcc and gforth
that your application does not run without the GPL-covered system...

>  > And I fear you mean the "C" up to
>
> > C# or even Perl and such ;)
>
> Three of the most common features of Forth that people point to when
> comparing against C is interactivity, extensibility, and the ability to
> do run-time evaluation.  And yes, when you compare against C, that's
> true.  But most scripting languages give you all that and more.  And
> beyond the world of scripting, we have languages like Smalltalk and Lisp
> (and the family of languages that come from them) that either pre-date
> or were concurrent with Forth that provide the same features.
>
> My point is that for people who are limited by Forth and C, the
> advantages of Forth are clear.  For those without such limits, the
> advantages of Forth are less strong.

Oh, Forth has also very strange disadvantages. No matter that also a
small HTTP-server is possible with gforth, I still prefer to use Perl
for simple "text tasks". As I prefer Tcl/Tk for quickly writing a
graphical interface (also interfacing Forth-programs) ( - that's a
reference to a recent post on this list I'm thinking about how to
answer...).
Forth is good if you have to make your own domain specific language.
If for your problem domain there is a language out there, dont use
Forth if you dont have good reasons...

-Helmar