Why Forth is not doing so well 
Author Message
 Why Forth is not doing so well

Microsoft has designed the interfaces to its Windows GUI to be C/C++.  This
gives those pair quite a boost over everything else, even other C-like
languages such as Modula and Ada.  

For Forth to compete in this GUI world, somebody has to build and promote
even better tools for writing GUI code.

I think the future belongs to trigger code -- rules you put in your
database about editing that are automatically triggered when certain
condition happen. E.g. when a record is deleted, automatically all
references to it are tracked down and nullified.  Databases will have
PRIMITIVES like phone number, that automatically invoke editing rules any
time they are entered or displayed.

Side effects are currently considered wicked.  However, if we are ever
going to be able to hide the housekeeping details sufficiently to see what
is going on in a large app, we will have to hide more and more of the work
as side effects.  Forth, more than any other language I have used so far
lets you hide side effects.


-30-



Sun, 09 Nov 1997 03:00:00 GMT  
 Why Forth is not doing so well

Quote:

>Microsoft has designed the interfaces to its Windows GUI to be C/C++.  This
>gives those pair quite a boost over everything else, even other C-like
>languages such as Modula and Ada.  

Actually, the interface is Pascal, not C/C++.

Quote:
>For Forth to compete in this GUI world, somebody has to build and promote
>even better tools for writing GUI code.

That's certainly true. I wouldn't develop a GUI without having graphic tools.

--
Tom Almy

Standard Disclaimers Apply



Sun, 09 Nov 1997 03:00:00 GMT  
 Why Forth is not doing so well

Quote:

>>For Forth to compete in this GUI world, somebody has to build and promote
>>even better tools for writing GUI code.

>That's certainly true. I wouldn't develop a GUI without having graphic tools.

Agreed...  This is why we poured a huge amount of effort into GUI tools for our real-time
polyFORTH for PCs.


Sun, 09 Nov 1997 03:00:00 GMT  
 Why Forth is not doing so well

;)Microsoft has designed the interfaces to its Windows GUI to be C/C++.  This
;)gives those pair quite a boost over everything else, even other C-like
;)languages such as Modula and Ada.  

Not strictly true. They did use a stack frame based approach, but its
actually Pascal format *most* of the time. Given that they did not write
Windoze in Forth, I'd call that a reasonable decision.

C,C++,Pascal etc have an advantage because its normal practice to link
external modules, making bindings to the OS a natural extension to add.
Forth in constrast *is* the OS. Only some Forths provide external bindings.
(this is where the commercial vendors normally jump in to complain.... ;)

--
Paul Shirley: SemiProfessional Coffee & Chocolate Taster



Mon, 10 Nov 1997 03:00:00 GMT  
 Why Forth is not doing so well

Quote:


>>Microsoft has designed the interfaces to its Windows GUI to be C/C++.
>Actually, the interface is Pascal, not C/C++.

Actually, the interface is some standard sequence of byte's in Memory
and in the CPU-Registers...

It happens to be documented in the form of C-Function-Declarations
with the parameter-sequence in reverse (==Pascal) than normal "C".

Quote:
>Tom Almy

Greetings, Holger


Wed, 12 Nov 1997 03:00:00 GMT  
 Why Forth is not doing so well

   Microsoft has designed the interfaces to its Windows GUI to be C/C++.  This
   gives those pair quite a boost over everything else, even other C-like
   languages such as Modula and Ada.  

   For Forth to compete in this GUI world, somebody has to build and promote
   even better tools for writing GUI code.

   I think the future belongs to trigger code -- rules you put in your
   database about editing that are automatically triggered when certain
   condition happen. E.g. when a record is deleted, automatically all
   references to it are tracked down and nullified.  Databases will have
   PRIMITIVES like phone number, that automatically invoke editing rules any
   time they are entered or displayed.

This is what AI programmers mean when they talk about demons.  Using a
before method, you can set a demon to watch over the setter of a
variable so that other stuff get updated whenever the value of that
variable changes.

   Side effects are currently considered wicked.  However, if we are ever
   going to be able to hide the housekeeping details sufficiently to see what
   is going on in a large app, we will have to hide more and more of the work
   as side effects.  Forth, more than any other language I have used so far
   lets you hide side effects.

Side effects are not wicked; they just make provability more
difficult.  Side effects should be minimized, and should preferably
take place at only one point, so that maintenence is eased, but then
this is just good factoring anyway, and I don`t need to teach Forthers
about that.

Remember: I/O is *ALWAYS* a side effect!  Without it, computers would
just sit there and go "OM!" and not communicate their wonderful
results to the rest of the world.  They would be useless.


   -30-



Sat, 15 Nov 1997 03:00:00 GMT  
 Why Forth is not doing so well

Quote:
>   Remember: I/O is *ALWAYS* a side effect!  Without it, computers would
>   just sit there and go "OM!" and not communicate their wonderful
>   results to the rest of the world.  They would be useless.

No ! Just see how Haskell manages I/O. From the programmer's view-point,
there is no side-effect there, and this make proof of program correctness
*much* easier...

--
--    ,                                         ,           _ v    ~  ^  --

--                                      '                   / .          --
Join the TUNES project for a computing system based on computing freedom !
                   TUNES is a Useful, Not Expedient System
WWW page at URL: "http://acacia.ens.fr:8080/home/rideau/Tunes/"



Sat, 15 Nov 1997 03:00:00 GMT  
 Why Forth is not doing so well

Quote:

> >   Remember: I/O is *ALWAYS* a side effect!  Without it, computers would
> >   just sit there and go "OM!" and not communicate their wonderful
> >   results to the rest of the world.  They would be useless.
> No ! Just see how Haskell manages I/O. From the programmer's view-point,
> there is no side-effect there, and this make proof of program correctness
> *much* easier...

I would be very much interested in an elaborated _example_ how using monadic
(side effect free) I/O in Haskell makes proof of program correctness
*much* easier. I hear this claim often and would like to learn very much
that it is more than just wishful thinking.

Ulrich

--
Ulrich Hoffmann, Uni Kiel        WWW: http://www.informatik.uni-kiel.de/~uho/

Preusserstr 1-9, D-24105 Kiel, Germany      Tel: +49 431 560426   Fax: 566143



Sun, 16 Nov 1997 03:00:00 GMT  
 Why Forth is not doing so well

   I would be very much interested in an elaborated _example_ how using monadic
   (side effect free) I/O in Haskell makes proof of program correctness
   *much* easier. I hear this claim often and would like to learn very much
   that it is more than just wishful thinking.

   Well, basically, the idea is that input and output are partially/lazily
evaluated constructors. A function computing an output stream from an
input stream would be a regular function having lazily evaluated constructing
stream as input (e.g. the list of characters being typed in a window),
and returning some other list to be lazily evaluated by whatever program
consumes the list (e.g. a monadic function that outputs characters in the
list to the screen).
   Now, this makes program correctness *much* easier, because by removing
side-effects, you remove the need to study lots of possible (but not
happening) interactions between variables.
   More generally, programs with variables must track all interactions
between variables, whereas in pure languages, constants are not subject
to interaction any more once computed.
   By the way, I read a thesis and papers in which to compile efficiently
a low-level language (C), they had to transform it in pure functional
form, so as to optimize it. Actually, optimized compiling is just "proving"
how a program can be efficiently implemented in some way.

--
--    ,                                         ,           _ v    ~  ^  --

--                                      '                   / .          --
Join the TUNES project for a computing system based on computing freedom !
                   TUNES is a Useful, Not Expedient System
WWW page at URL: "http://acacia.ens.fr:8080/home/rideau/Tunes/"



Sun, 16 Nov 1997 03:00:00 GMT  
 Why Forth is not doing so well

uho>    I would be very much interested in an elaborated _example_ how using monadic
uho>    (side effect free) I/O in Haskell makes proof of program correctness
uho>    *much* easier. I hear this claim often and would like to learn very much
uho>    that it is more than just wishful thinking.

[motivation reluctantly removed]

Quote:
> Now, this makes program correctness *much* easier, because by removing
> side-effects, you remove the need to study lots of possible (but not
> happening) interactions between variables.

I heard this many times before and although it looks obvious, I cannot believe
that the problems involved in state will go away with just changing the
point of view (From side-effected IO to functional IO). This would be magic.
This is why I ask for an EXAMPLE. Repeating the claim is not convincing.

Ulrich
--
Ulrich Hoffmann, Uni Kiel        WWW: http://www.informatik.uni-kiel.de/~uho/

Preusserstr 1-9, D-24105 Kiel, Germany      Tel: +49 431 560426   Fax: 566143



Mon, 17 Nov 1997 03:00:00 GMT  
 
 [ 12 post ] 

 Relevant Pages 

1. Why I am not enthusiatic about OO COBOL

2. Why I am not reaching callbacks ?

3. I am not deaf, but am I mute?

4. Why NOT Forth?

5. Why is Postscript not Forth?

6. Preprocessor for Forth...and why not!

7. The Smalltalk Store: Why we've been slow, and why we're getting better

8. What am I doing wrong!

9. What am I doing wrong?

10. Stupid newb question: What am I doing wrong?

11. What am I doing Wrong

12. what am i doing wrong

 

 
Powered by phpBB® Forum Software