Received: by 10.66.77.227 with SMTP id v3mr1836096paw.11.1349379675213;
        Thu, 04 Oct 2012 12:41:15 -0700 (PDT)
Path: t10ni23609719pbh.0!nntp.google.com!npeer02.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!nx02.iad01.newshosting.com!newshosting.com!news-out.octanews.net!indigo.octanews.net!auth.brown.octanews.com.POSTED!not-for-mail
From: Paul Rubin <no.em...@nospam.invalid>
Newsgroups: comp.lang.forth
Subject: Re: Olympic Spririt for Forth
References: <abka93F3k97U1@mid.individual.net>
	<cff5560a-b57c-46b5-b206-d4bd2ce724d4@c4g2000vbe.googlegroups.com>
	<70fba44e-473b-49b2-b04d-ae49a83bfe74@googlegroups.com>
	<k49s60$ha0$1@dont-email.me> <7x391zgx4p.fsf@ruckus.brouhaha.com>
	<38bc373a-aa2f-4251-9247-1fbfbfcf5f6c@googlegroups.com>
	<7xhaqc69sz.fsf@ruckus.brouhaha.com>
	<22489610.pnmz7RBueg@sunwukong.fritz.box>
	<7x391wsjjp.fsf@ruckus.brouhaha.com>
	<8997734.FPiUxMsVlB@sunwukong.fritz.box>
	<7xbogk71fc.fsf@ruckus.brouhaha.com>
	<1599725.MmvXeDaymt@sunwukong.fritz.box>
	<7xmx03bclp.fsf@ruckus.brouhaha.com>
	<1797229.DCWuoRaQ3N@sunwukong.fritz.box>
Date: Thu, 04 Oct 2012 12:41:12 -0700
Message-ID: <7x4nmauisn.fsf@ruckus.brouhaha.com>
Organization: Nightsong/Fort GNOX
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux)
Cancel-Lock: sha1:j2LV4w7CJT3z1ZhBP7gNO3lGGSI=
MIME-Version: 1.0
Lines: 71
NNTP-Posting-Date: 04 Oct 2012 14:41:12 CDT
X-Complaints-To: abuse@octanews.net
X-Received-Bytes: 4485
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 
> nested.

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:
> http://www.complang.tuwien.ac.at/anton/lvas/stack-abgaben/07w/glforth/

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
is fine.

> 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 
> net2o.

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.