Message from discussion Olympic Spririt for Forth
Received: by 10.66.77.227 with SMTP id v3mr1836096paw.11.1349379675213;
Thu, 04 Oct 2012 12:41:15 -0700 (PDT)
From: Paul Rubin <no.em...@nospam.invalid>
Subject: Re: Olympic Spririt for Forth
Date: Thu, 04 Oct 2012 12:41:12 -0700
Organization: Nightsong/Fort GNOX
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux)
NNTP-Posting-Date: 04 Oct 2012 14:41:12 CDT
Content-Type: text/plain; charset=us-ascii
Bernd Paysan <bernd.pay...@gmx.de> writes:
> In Forth, you write a program which draws the robot, you don't write an
> interpreter for complex nested robot data structures. The program is
So what do you do if you want to describe a few different robots in the
program? Write separate programs for each?
>> compare its sophistication to something like Unity3D.
> You know that we don't do the "breakfast machine" in Forth. We try to
> write to the point, not to all possible future extensions. We can
> extend our systems as we go.
But all the features in Unity3D are there because somebody wanted them.
And if you're making a toolkit for other people to use, I think you
really do have to anticipate their requirements.
> The homepage of Glforth (Gerald Wodni's game engine) is here:
This looks nice.
>> Forth though has no machine-checked types at all... spend a lot of time
>> tediously debugging.
> No, you just write your program piecemeal, and debug a few additional
> word at a time.
But then you end up modifying the code and that usually introduces
errors, so you're back to debugging.
> Furthermore, we don't really have that many types in
> Forth, so the most likely confusion is between integers and floats.
Don't forget addresses and xt's, which are easy to get confused with
data. And I don't think Forth's lack of strings, arrays, associative
tables, closures, etc. help its attractiveness to programmers used to
such newfangled conveniences.
> I probably would use string.fs from Gforth; it's not really difficult to
> add reasonable string handling to Forth.
I'd think reasonable string handling absolutely has to use garbage
collection (or at least, C++-style finalization on exit from a scope) to
clean up the intermediate results of complex string manipulation.
If strings.fs does that then it's interesting.
> As I said, it's probably a skill issue. Just look for people who have
> experience in incrementally and quickly compiling code at run-time, and
> you end up finding Forth implementers.
Oh come on, there just aren't that many Forth programmers. Lisp systems
have done on-the-fly compilation since the dawn of time, Java probably
uses the best-known JIT, etc.
>> Rust is really a more advanced language than Java or C++.
> Somewhat, yes. But it's still an ahead-of-time compiled language. I
> don't consider ahead-of-time compiled languages (as only option) as
> "advanced". Less retarded, maybe, is the right word.
Meh, once you've got a fast build system (maybe not possible for certain
styles of C++ but quite reasonable for other languages), ahead-of-time
> I'm usually not trying to reinvent wheels which are actually good. So
> maybe I will just use Lua as the high level scripting language for
Probably a reasonable choice. Lua has some traction, has a very nice
embeddable implementation, and is lightweight and efficient. I'm not
that crazy about the Lua language itself but I think alternatives
(mostly Lisp-based, like Guile) will probably stay unpopular.