http://www.firebirdsql.org/index.php?id=about-firebird&nosb=1
something like this
but substitute c/c++ for forth

gavino wrote:

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.

Bernd Paysan wrote:

John Passaniti JapanIsShinto.com> writes Re: a relational database done in forth would r0ck
[..]

[..]

Who are these "plenty of others?" I know of only one, and we haven't been
bothered by him in quite a while.

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 Hendrix wrote:

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.

John Passaniti JapanIsShinto.com> wrote:

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:

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.

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

On Aug 27, 4:17 am, Bernd Paysan wrote:

Jonah Thomas wrote:

In what sense does bad coding practice show up as bad right away? Forth
is no different from any other language in this regard. Bad coding
practice (poorly factored definitions, deeply nested control structures,
undisciplined use of globals, etc.) compiles just fine if it is
syntactically correct under Forth. Where are the warning bells?

I don't believe bad coding practice in Forth (or any language) shows up
right away. I believe bad coding practice only shows up when some body
of code is extended, reworked, repackaged as a library, or in some way
changed. I don't see how Forth makes this any more obvious than any
other language.

It makes a nice statement, but I have yet to find any sophisticated
woodworking tool that has the ability to cover bad technique.

Bernd Paysan wrote:

So again, I'm trying to figure out how you feel this story relates to my
point. My point, again, is that approach matters far more than
language. If your story was that the Java programmers took the *same*
approach of the Forth programmers (presumably building only what they
needed) and *then* failed, then your story would counter my statement.

But again, this has little to do with language. It has to do with the
skill and experience of the programmers.