Eric's funny for the day 
Author Message
 Eric's funny for the day

Eric Johansson write>>>>>>
Subj:   RE: ANS TC Magnet for Cont. Ref. Set

And speaking of interesting opinions, here is another....  read with
a bit of salt :-)

There is one way I could agree to shrinking the ANSI wordset
thereby eliminating all of these controversies over the string or file
or ... wordsets.  Define a standard way of calling C functions from
forth.  Then anyone could use all the functions in libc.a or any other C
library and not need to reinvent the wheel (or words) in forth.
Think about it, interface to C in an standard sequence and all the
issues of strings, files, floating point, networking, GUI are
mostly solved.  Use the C names, with the C specified arguments in a
forth context. real easy.  But I figure this will never fly because
the forth hackers of the world have their egos too wrapped up
in reinventing the wheel in the forth way to get any real work done
and make money using forth.

Ha, ha, ha! This is exactly what J-forth and (in a slightly clunkier
fashion, IMHO) Multi-forth do on the Amiga. There's only a few objections
I'd have to `standardizing' that:

Can you get TurboC to use libraries compiled for use with MicroSoftC
on the PC? Can you get C libraries at reasonable cost for the 68hc11?
(I know right off of two compilers that run in the $1000 range!)
Also, if you actually roll-your-own C library interface, you
have to know how the compiler it is intended for keeps its stuff
on the stack, which I believe is implementation dependant, and not
specified in the ANSI standard. That you must have a stack, that's
standard. How you keep things there (in what order) is up to
you and your machine.

In addition, this can be easily done on one platform, like the Amiga,
because the whole hardware-software interface is determined by
EXEC. There are other systems that don't have such a strict (nor
so benevolent a) dictator.

The Amiga also has the ability to share libraries, while talk of
this is just now happening for some other OSs. Using another
language's libraries is OK if they're there...

Also, once you have a whole set of libraries, you have to have a way
to add to them or modify routines: this is what forth is all about.
If I don't like emit, or want it to emit somewhere's else... I can
change it. With C libraries, you need the source (no real decompiler
possible), you need a librarian, and you need to be able to compile
into the library...Why not use C in the first place?

Or you suggesting that we take all of the C library routines, and write
them in forth, verbatim (as it were)? Then, I guess the next thing to do
is to change WORD and EXPECT, etc. to work with Zero-terminated
strings, and trash enumerated strings... After all, enumerated strings
are fine if you want speed, but we're talking C libraries here...

What you'll end up with, IMHO (alright, IMRO, R for righteous?), is C.
And you'll still have a big hole where FORTH used to be, and a lot of
people using un-standardized forths to fill the hole because there won't
be a real FORTH any where near the standard...

[NOTE: this is not a flame. [TINF?] The idea is OK for practice where
the operating system (and its implementation) make a c-like interface
and library access desirable, but I don't think it belongs as a foundation
of the standard. These sorts of things become non-portable real quickly...

Quote:
>--- eric

>--
>...

>* *     a juggling fool  AT&T (617) 577-4068 (w)
> o                       HAM  ka1eec


>       source of the public's fear of the unknown since 1956

raybro


Mon, 02 Aug 1993 21:47:00 GMT  
 Eric's funny for the day
I'm glad I made you smile. (it's a wonderful day in the neighborhood...)

[the following has been edited a bit - esj]

Quote:

> Ha, ha, ha! This is exactly what J-forth and (in a slightly clunkier
> fashion, IMHO) Multi-forth do on the Amiga. There's only a few objections
> I'd have to `standardizing' that:

> Can you get TurboC to use libraries compiled for use with MicroSoftC
> on the PC? Can you get C libraries at reasonable cost for the 68hc11?
> (I know right off of two compilers that run in the $1000 range!)

The issue of different binary formats and library formats is a sticky one
that gives compiler venders another reason to use Tums.  The PC world is
a messy place whereas in the unix world we only have a half dozen
binary formats (count as of last week).  I guess the only answer I
have for you is state that which binary/library format used is a
vendor specific issue.  suppliers of libraries usually support the top
X popular binary formats so if you had a forth that linked to C
libraries, you probably could find a vendor that supported the library
format you needed.  Object/library format is one of my selection
criteria when I choose a compiler and library suppliers no matter
what language I work in.

C libs for small machines at "reasonable cost" ( example: 6811 )
I could claim that routines you find in an ANSI C RTL you would not be
able use in a micro-controller environment like the 6811 but you would
be justified in calling that a arguable point.  Since you claim that
you know of two suppliers of 1000$ C compilers, I suggest one could
look there for a library supply.  BTW, I consider 1000$ reasonable (if
not cheap) for a compiler when a company is buying it.  The only
beter deal I know of are the FSF compilers for unix systems.  They are
less buggy than most commerical C/C++ compilers and better
supported. (argue this point with me in email :-)

Quote:
> Also, if you actually roll-your-own C library interface, you
> have to know how the compiler it is intended for keeps its stuff
> on the stack, which I believe is implementation dependant, and not
> specified in the ANSI standard. That you must have a stack, that's
> standard. How you keep things there (in what order) is up to
> you and your machine.

The issue of calling sequences is strongly tied to object format.
A compiler that produces object files in the same format as
another compiler but uses a different calling sequence will tend to
not have a very large market place.

Quote:

> Also, once you have a whole set of libraries, you have to have a way
> to add to them or modify routines: this is what forth is all about.

I tend to view libraries as a fixed set of atomic objects.  I can't
change them (except for bug fixes), or add to them.  Changing
the behaviour or adding routines is not acceptable IFF the library
is defined by a standard.  On the other hand, changing or adding to
my local libraries is ok because no-one outside of my work group
is counting on them. ( I will rant about resuable code at another time.)

Quote:
> If I don't like emit, or want it to emit somewhere's else... I can
> change it.

hmmm. *i* just redirect stdout if i want the equivelent of
redirecting emit. :-) :-)

Quote:
> With C libraries, you need the source (no real decompiler
> possible), you need a librarian, and you need to be able to compile
> into the library...Why not use C in the first place?

Well... Using C instead of forth *is* the option picked by most
managers of software projects.

Quote:
> [NOTE: this is not a flame. [TINF?]

Understood and not taken as a flame.

Quote:
> The idea is OK for practice where
> the operating system (and its implementation) make a c-like interface
> and library access desirable, but I don't think it belongs as a foundation
> of the standard. These sorts of things become non-portable real quickly...

I sort-of dissagree.  I believe an inter-language interface belongs in
the standard of any language.  I also believe that the INTERFACE can
be made portable whereas the implementation will tend to not be portable.

Quote:

> raybro

--- eric
--
...

* *     a juggling fool  AT&T (617) 577-4068 (w)
 o                       HAM  ka1eec


        source of the public's fear of the unknown since 1956


Thu, 05 Aug 1993 22:15:52 GMT  
 Eric's funny for the day

        ... <stuff> ...

Quote:
>Well... Using C instead of forth *is* the option picked by most
>managers of software projects.

        Yeah, it's a gas. To program our Vesta Technology SBC68K
68000/68010-based single board computer you can:

        a) Grab an XT Clone with two floppies and MSDOS 2.1 and buy
        our Vesta Forth-83A+ for $99.00, or

        b) Grab a 386 with a big harddrive and buy our C Compiler and
        source-level de{*filter*} for $3495.00.

        In house we use our Forth-83A+ for projects because we run
coencentric rigns around C programmers in terms of productivity.

        I'm sure glad that most of our competitors use C, it guarantees
that we underbid them every time. For your next custom engineered
control project, give Vesta a call. <plug>

        When in UNIX, do as the C programmers do, but when in Realtime,
Forth!

--


 <JAX on GEnie             >< for ANS  > \\\  /// ///====\\\   ///\\\
 <SYSOP RCFB (303) 278-0364><  Forth   >  \\\/// ///      \\\ ///  \\\



Sat, 07 Aug 1993 12:19:38 GMT  
 Eric's funny for the day

Quote:

>    ... <stuff> ...

> >Well... Using C instead of forth *is* the option picked by most
> >managers of software projects.

>    Yeah, it's a gas. To program our Vesta Technology SBC68K
> 68000/68010-based single board computer you can:

>    a) Grab an XT Clone with two floppies and MSDOS 2.1 and buy
>    our Vesta Forth-83A+ for $99.00, or

>    b) Grab a 386 with a big harddrive and buy our C Compiler and
>    source-level de{*filter*} for $3495.00.

In my 14+ years in the field, I have worked for 6 companies.  5
would choose this option and I can name you about a hundred
other companies that would do the same. (sigh)

Quote:

>    In house we use our Forth-83A+ for projects because we run
> coencentric rigns around C programmers in terms of productivity.

>    I'm sure glad that most of our competitors use C, it guarantees
> that we underbid them every time. For your next custom engineered
> control project, give Vesta a call. <plug>

I sure will <grin>.  Although you probably would not underbid as far
as you think you might be able to.  I am managing a contract for
Polaroid now and we are paying 40K$ for a scanner toolkit.  Approx. 30K$
is for documentation, unit test and regression test suites.  Only 10K$
of the bid is for coding and testing.  AND! if they don't pass our
reviews (design, code, test) they don't get paid!

When I write Forth code, I am about 10 times more productive than when
I code in C.  Coding in C++ without a class library is the same level
of productivity as coding in Forth.  Unfortunatly, coding is 20% of
the effort that goes into building a software product.  The rest
is specifications, design, testing and acceptance.

Quote:

>    When in UNIX, do as the C programmers do, but when in Realtime,
> Forth!

Hell, I want to make it possible to use forth *anywhere* not
just realtime!  Using forth and C++, I have gotten real {*filter*}ed
to powerful tools but my boss pays me to write specs and make designs
that fit those twisted nightmares that come out of marketing.  But, on
the upside, they let me experiment with formal notations and OOD.
--
...

* *     a juggling fool  AT&T (617) 577-4068 (w)
 o                       HAM  ka1eec


        source of the public's fear of the unknown since 1956


Sun, 08 Aug 1993 02:24:42 GMT  
 
 [ 4 post ] 

 Relevant Pages 

1. Y'all must read this it's very funny :-)

2. Reference to Eiffel GC in Eric Raymond's new book

3. Eric's question

4. Unix's Zoo of Languages (Eric Raymond)

5. Eric S. Raymond's newest writings

6. (OT) This just gets funnier and funnier

7. module path:funny bug, funny solution

8. Availability of a 'AWT'-like windowing interface to Smalltalk these days

9. Why procedure returns 8 ( It's gonna be funny )

10. help display's funny in windows 2000

11. It's a funny thing about MEMOs

12. The world's funniest GPF

 

 
Powered by phpBB® Forum Software