Re: a relational database done in forth would r0ck
  Home FAQ Contact Sign in
comp.lang.forth only
 
Advanced search
POPULAR GROUPS

more...

 Up
Re: a relational database done in forth would r0ck         

Group: comp.lang.forth · Group Profile
Author: John Passaniti
Date: Aug 26, 2008 16:31

Marcel Hendrix wrote:
> John Passaniti JapanIsShinto.com> writes Re: a relational database done in forth would r0ck
> [..]
>> 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.
> [..]
>
> Who are these "plenty of others?" I know of only one, and we haven't been
> bothered by him in quite a while.

We can start with the many messages of the form "if only X was
implemented in Forth, then X would be more Y" offered in comp.lang.forth
over the years I've been here.

Here, X has been operating systems (Windows and Linux), applications
(Word, Excel, CAD tools, project management, artificial intelligence,
virus scanners), supporting services (web servers, database engines),
and library routines (searches, sorts, regular expressions, objects).
And these are just from memory. If you haven't seen these messages--
from a variety of sources-- then you simply aren't paying attention or
your threshold for noise is higher than mine. I see this nonsense with
surprising regularity and often comment on it, but to be fair, the
fanboys in other programming language newsgroups make the same stupid
claim about their fave languages.

It is entirely valid to say that if one doesn't just recode X in Forth
but also makes other changes (reconsiders the design, changes
priorities, focuses on just what is necessary, etc.), that X in Forth
would indeed be better. But then, if you did that, X in any language
would be better. The essential lesson is that design matters. Language
is just a tool to realize the design.
>> 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.
>
> As long as you have no evidence that doing Forth-like things in language X
> or framework Y is easier than doing it in Forth, I will appreciate that
> observation for what it is worth.

I will gladly provide examples for statements I made. I refuse to
provide examples for statements I didn't make. I am not claiming that
"Forth-like" things are necessarily any *easier* in other languages.
That is your incorrect spin on my statement.

Let's start with a single example of what I'm talking about. A sentence
or two later in Bernd's response to me, he states that one needs to
recreate facilities in Forth (he used the text interpreter as an
example) in order to do "Forth-like" things. Okay, let's look at that.

If the year is 1980 and the only practical languages for writing code in
embedded systems is assembly, Forth, and C, then Bernd's argument
stands. But my calendar says 2008, and I find a richness of other
programming languages that offer many of the same features I find
indispensable in Forth.

Let's take Lua as a single example. Lua is small (not much bigger than
gforth on my system), has fine text interpreter available either
interactively in stand-alone mode or programmatically, is extensible, is
reflective, has a reasonable FFI, etc.

So let's look at "Forth-like" things and see how if the year is 1980,
Forth provides unique advantages, and if the year is 2008, they are
pedestrian and freely available elsewhere:

Interactive testing! Hoo-boy! Nobody else has this! No technique is
more Forth-like than interactive execution and testing!

: square dup * ;
3 square .
9

Ahem.

function square(x) return x*x end
=square(3)
9

Okay, so at least one other language lets you build up code
incrementally and test it.

Ummm, but Forth lets you use the text interpreter to simplify
applications! Check this definition out from Bernd's web server in Forth:

: GET get-url data on active off ;

S" GET /some/example" EVALUATE

Isn't that cool! We create a new wordlist and use Forth's own text
interpreter to drive the process. We in effect extended Forth to
interpret the URL or in the breathless hype of comp.lang.forth, we've
CREATED LANGUAGE!!! We have to preprocess the request a bit to clean it
up, but then we can let Forth deal with it. So unique and totally
Forth-like!

Ahem.

function GET(url)
get-url(url); data = true; active = off
end
...more...

loadstring("GET '/some/example'")()

The point of all this is that if you compare Forth to a static language
(like C), you can easily generate a long list of "Forth-like" techniques
that are impossible or difficult without recreating facilities that
Forth already has. But if you compare Forth to other languages in use
today, "Forth-like" become standard language-independent techniques that
are applied widely.

If you want to say that Forth's facilities are presented with a brevity
and directness that most other languages can't match, I would agree.
But having to type an extra semicolon here or needing to surround an
expression with quotes there doesn't mean the "Forth-like" techniques
aren't available elsewhere.
no comments
diggit! del.icio.us! reddit!