a relational database done in forth would r0ck

http://www.firebirdsql.org/index.php...irebird&nosb=1
something like this
but substitute c/c++ for forth

gavino wrote:
> http://www.firebirdsql.org/index.php...irebird&nosb=1
> something like this
> but substitute c/c++ for forth

You were impressed with the performance of Bernd's web server, but you
apparently didn't get the point.

The performance of Bernd's web server comes not from being coded in
Forth, but because he took a different approach. Web servers like
Apache are general-purpose; they support everything from simple web
sites serving static content to insanely sophisticated applications
spread across multiple servers. There is a *lot* of infrastructure
there to support that range, and if you need some of those features,
you're glad it's there. But if you don't, then it's bloat.

Bernd's web server takes a different approach. He doesn't need a
generic web server like Apache. He had a specific problem (or specific
class of problems) he wanted to solve and his web server implemented
just what he needed and nothing more.

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.

And that applies to databases as well. If someone was to recode a
generic SQL-based relational database system like Firebird in Forth, it
would be unreasonable to expect much if any of a performance increase.
On the other hand if you designed a database system that was specific to
the problem you were trying to solve, then you would expect potentially
huge increases in performance. And you would expect them largely
regardless of the language you chose.

You've written elsewhere that you've gotten some books on Forth.
Great... now here's something I strongly suggest you do as part of your
learning. There are three steps:

1) Take some non-trivial code you've written in some other language and
code it taking the _same_ approach using Forth. You may see some slight
performance improvement, but it won't be much if anything.

2) Now, take that same non-trivial code and now write it using a
different technique. Focus on doing just what is needed, coding
everything to be specific to the problem you're solving. Do this in
Forth. You're going to see a dramatic performance improvement.

3) Finally, take the Forth code you just wrote-- the code that does just
what is needed and is specific to the problem being solved-- and code it
in pretty much any other language you're familiar with. What you will
find is that the same dramatic performance improvement you saw with
Forth will also be seen with the other language.

I'm not telling you that there is no value to Forth. Forth is a great
language. But your messages seem to consistently confuse where the
performance you admire is coming from. It isn't from Forth. It's from
programming with a mindset towards writing code to solve specific
problems instead of general ones.

I wouldn't mind a Forth setup to host and/or interface with SQLite, since it
is in nearly everything.

-- Charlie Springer

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.

You can often implement Forth-like strategies in other languages to get to
the same effect. However, you have to know these strategies. 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). And when the main reason for choosing
another language is that people who never have seen these strategies can
contribute, you are doomed. Suddenly, code size, performance, and
especially simplicity matters. Culture shock!

--
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://www.jwdt.com/~paysan/

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.

John Passaniti <nntp@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.

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

-marcel

Marcel Hendrix wrote:
> John Passaniti <nntp@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.

John Passaniti <nntp@JapanIsShinto.com> wrote:

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

What particularly impressed me about Forth was that if you use a very
simple Forth that has no locals etc, bad coding practices tend to show
up as bad right away. It takes good technique to get anything much done.

It's the difference between sophisticated woodworking tools that cover
up your bad technique, versus simple tools that fail with bad technique.

John Passaniti wrote:
> 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?

They changed the approach. This change of approach came from adding people
and changing language. After all, Sun brags about Java for Smartcards
*because* you have so many libraries available to do all these things out
of the box instead of having to rewrite everything. And since Java
is "easy", you have lots of people who can work for the project.

> These strategies *are* known.

But not to these people. They even alienated the original authors of the
demo, so those left the company in despair.

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

Unfortunately, in reality, most non-Forth projects don't end up with a
Forth-like solution. Cultures are different, and many people stay in
theirs. That's why I tend to agree with your statement that you *can*
(theoretically) implement Forth-like solutions in other languages, but in
reality, this usually won't happen.

--
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://www.jwdt.com/~paysan/

On Aug 27, 4:17 am, Bernd Paysan <bernd.pay...@gmx.de> wrote:
> John Passaniti wrote:
> > 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?
>
> They changed the approach. This change of approach came from adding people
> and changing language. After all, Sun brags about Java for Smartcards
> *because* you have so many libraries available to do all these things out
> of the box instead of having to rewrite everything. And since Java
> is "easy", you have lots of people who can work for the project.
>
> > These strategies *are* known.
>
> But not to these people. They even alienated the original authors of the
> demo, so those left the company in despair.
>
> > 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.
>
> Unfortunately, in reality, most non-Forth projects don't end up with a
> Forth-like solution. Cultures are different, and many people stay in
> theirs. That's why I tend to agree with your statement that you *can*
> (theoretically) implement Forth-like solutions in other languages, but in
> reality, this usually won't happen.
>

Forth, for better or worse, hasn't built up a large collection of
common libraries. Because of this, many Forth programmers design from
the bottom up - really taking the time to understand the concepts and
features required to drive the project or application.

This is a generalization of Java programmers, but damn me if you will
- they are given a plethora of library tools - "black boxes" - and
they feel it necessary to plug these in and use them. When you utilize
general program tools, your design is not tailored to the application
as "tightly" as it could be if you design from the bottom up. And
Forth programmers are more likely to take a "tool" they have and
modify it to "fit" the design desired, whereas Java programmers are
sitting looking at a black box they really know little about.

Just my $0.02...