Re: what kind of non microconroller app are done in forth?

jennifer.spykerman@[EMAIL PROTECTED]
 wrote:

> It may be that writing an entire modern OS may be a surmountable
> obstacle that you could 'solo'.
> 
> But you go do that and you're stuck with.... the problem of....
> 
> It looks like WAY WAY too much work to write device drivers etc... I
> mean, look every PC's gonna be different, you're gonna have one with
> this network card, that GFX card etc, mmmm... PCI bus...mmm... USB...
> Sounds like a royal pain. How you gonna cover all the devices people
> are reasonably expected to have? Even writing drivers for just the
> stuff you own yourself's gonna be a right pain.
> 
> Then you got to convince everyone your OS is the next great thing and
> to come and write drivers, utils and apps for it etc..
> 
> = Dead OS.

Yes. The point of an OS is to provide a steady interface between
variable/changing apps and variable/changing hardware. In the ideal case
hardware manufacturers would pay for the information they need to write
their own drivers, and application developers pay for the information
they need to write apps for your OS, and Bob's your uncle. But it
doesn't usually work like that unless Bob's your uncle.

You might get a foothold if you have an application that could use a
dedicated platform similar to a PC. If the PC is cheaper than dedicated
hardware, then use it even though it does more than you want. You write 
your limited OS that works on a particular common PC architecture, maybe
specific components, and you can sell it because people want the
application and of course it works much better with your OS thasn it
would if it was rewritten to run under Windows or Linux. You might need
drivers for new components as the one it works on become unavailable and
your customers need replacement parts, and as you upgrade. Expand to
other drivers as you find the time. If possible, publish the specs of
what your OS demands of drivers in case somebody else wants to do some
of that.

Then you might get a second dedicated application, and maybe a third.
Let other people make dedicated apps for your OS. If there's some
special function your OS does particularly well they might do that. And
move on from there.

The Java guys tried to widen that bottleneck. Java serves as an OS for
java apps. Get a good java compiler/interpreter/JIT-compiler etc for a
particular set of hardware and in theory all the java apps will run on
it. Once your OS has java then it has everything. Java doesn't run all
that fast (no faster than a good Forth) and it's very slow to write and
debug apps in it. But more and more code is being written in it anyway.
The TIOBE measure puts java at 20% usage. (Disclaimer -- I don't know
what the survey measures or whether it actually measures anything
interesting. It's merely a convenient source of factoids, and I lack a
good source that says what I want to know.) That might translate into
roughly 20% of new desktop apps in Java? It would be a big deal to have
a new OS and 20% of the apps people might want, run on it out of the
box.

It ought to be easier to ****t one particular Forth compiler than a java
compiler, but then you don't get so many apps. And Forth doesn't have
anything like a standard GUI user interface. What might work is to write
a java compiler in Forth. Then you ****t the Forth and the Java compiler
****ts too. Even if it isn't the best Java compiler it could be the first
that ****ts to a new system. And it could get improvements as fast as
somebody wants to bother.

Again going by the utterly unreliable TIOBE numbers, if you write other
langauges in Forth and ****t the Forth, you could theoretically ****t a
lot of apps easily.

Java           20%
+ C            35%
+ C++          45%
+ PHP          55%
+ Perl         61%
+ Python       66%

Of course, in reality some of these languages have multiple incompatible
implementations so of course you can't compile all the code. And some of
them use lots and lots of conditional compilation so that you can only
run their code if you pretend to be some system they chose to write for.
But this is certainly suggestive. We say that Forth is particularly good
for low-level hardware type things. And Forth is particularly good for
writing application-specific languages. If the specific application is
"tools to easily write traditional languages"....

I'd start with a tool that parses traditional EBNF. Anton Ertl's Grey
and Brad Rodriguez's BNF parser both parse BNF, but as I understand it
they both use their own idiosyncratic commands and they both parse by
whitespace. Traditional BNF code doesn't care about whitespace and
usually will have to be massaged to fit a Forth parser. If we can accept
EBNF as it's usually written that might be a start toward writing
compilers for languages that have EBNF descriptions. 

Doing the whole thing looks like a big job. But as one end-point, you'd
have a bunch of Forth applications, and on any particular new OS that
somebody else made, you could ****t the Forth and a lot of applications
in other languages would come with it. And it would be very easy to ****t
those applications to an OS written in Forth. 

You'd still be left with the problem of drivers for a bewildering
variety of hardware components. But at least solving that problem
wouldn't be building a road to nowhere.