S72UZAW@TOWSONVX.BITNET (Yahn Zawadzki) (01/08/90)
Greetings...
I have been witnessing the arguments between you folks for/against a
windowing standard (and other standards). I am running a forth version for a
C128. It has a window 'interface' (the 128 does not really support windows in
the sense Macs or Amigas do). The interface is nice and simple - because it
uses features unique to the 128. After all - do you want your system to be
FAST, or to be 'compatible'??? What about colours? Sound? Just how far is
the standarization reaching..? As a poor student - I cannot afford the new
Forth Standard. And until I will be making $20+ an hour, I will not buy one.
Maybe not even then... If my forth runs on my machine only, but does it well,
why standarize? I don't see why you people use Forth, if you expect your code
to work on different machines. If you want to port a small application, you
might as well rewrite it - optimize it for the particular machine... If you
are trying to port a larger application - well, consider yourself lucky if at
least a minor portion of the code isn't written in assembly. Use C, or Pascal,
or whatever... We do NOT need a Reverse-Polish C! (I apologize: I do not
have the memory for names... Whoever said this before...)
Certain things should remain the same for us to be able to call 'it'
Forth - by all means... But this is too much like trying to standarize system
calls between VMS, DOS, UNIX, and whatever else.. However 'neat' an idea - but
unrealistc and, I feel, unneeded.
---
Jan (Yahn) Zawadzki
INET: yahn@midget.towson.edu
Bitnet: s72uzaw @ TOWSONVX
---bouma@cs.purdue.EDU (William J. Bouma) (01/09/90)
In article <9001081531.AA15962@jade.berkeley.edu> Forth Interest Group International List <FIGI-L%SCFVM.bitnet@jade.berkeley.edu> writes: >... >As a poor student - I cannot afford the new >Forth Standard. And until I will be making $20+ an hour, I will not buy one. >Maybe not even then... If my forth runs on my machine only, but does it well, >why standarize? I don't see why you people use Forth, if you expect your code >to work on different machines. If you want to port a small application, you >might as well rewrite it - optimize it for the particular machine... If you >are trying to port a larger application - well, consider yourself lucky if at >least a minor portion of the code isn't written in assembly. Use C, or Pascal, I think these are stupid arguments against a forth standard. If some people can't afford to buy it that is tough. The benefits of a standard outweigh petty individual problems. As for using some other standardized language instead, where would we be if everyone thought like this? Every- one would be using fortran because stuff in c and pascal would need to be "re-written" to run on different machines. Sure, as long as you do your own stuff on your own machine you are fine. But if you want to share code, (and that is the what people in the real world want), you need a standard or you spend your whole life porting. Just what does it take to make a standard forth? I have read arguments in this group that making a true standard will take away some of the flexibility. This seems like it is probably the case, but again I believe the benefits exceed a minor loss in flexibility. To me the definition of "standard" implies that there should be absolutely no machine dependency. The language will not allow assembly, but should provide better high- level ways to do the things one would otherwise want to do in assembly. Sure, the f83 standard says assembly is not standard, but so many things are easier and faster to do in assembly that nearly everyone who uses forth uses it. Another thing the standard needs is types. It should not be a part of the standard how big an integer or how big a stack element is. All machine level junk must be eliminated. >or whatever... We do NOT need a Reverse-Polish C! (I apologize: I do not >have the memory for names... Whoever said this before...) This has been said by several people now in this group, but I do not see any basis for it. It seems I am in a small minority that thinks forth could be a much improved language by changing it a bit. Why does it bother some of you so much that some of us entertain this idea? Where would forth be now if Chuck hadn't been inspired to try something different? I thought forth people would be more open-minded! >... certain things must remain the same for us to call it FORTH. What things? When does my language stop being FORTH and begin to be Reverse-Polish C or Reverse-Polish LISP? Why don't you people who are griping use a little imagination? If you are not interested in creative contribution, just wait until you have something solid to criticize. -- Bill <bouma@cs.purdue.edu> || ...!purdue!bouma
wmb@SUN.COM (Mitch Bradley) (01/09/90)
> If my forth runs on my machine only, but does it well, > why standarize? ... If you want to port a small application, you > might as well rewrite it - optimize it for the particular machine... With standardization, the community as a whole can make forward progress, instead of everybody having to rewrite everything for every different machine. With computers as inexpensive and as commonplace as they are today, many people routinely use more than one type of machine. I routinely use about 9 different machines. I don't have time to rewrite for all the machines. These are the benefits of standardization. However, I still think that, at this time, it would be impractical for the Forth community to adopt a standard window model. In other areas, in particular file system interfaces, strings, and floating point, things have settled down to the point where standardization would be practical and timely. Mitch
mccarrol@topaz.rutgers.edu (Mark C. Carroll <MC>) (01/10/90)
In article <9001081531.AA15962@jade.berkeley.edu> S72UZAW@TOWSONVX.BITNET (Yahn Zawadzki) writes:
]Greetings...
] I have been witnessing the arguments between you folks for/against a
]windowing standard (and other standards). I am running a forth version for a
]C128. It has a window 'interface' (the 128 does not really support windows in
]the sense Macs or Amigas do). The interface is nice and simple - because it
]uses features unique to the 128. After all - do you want your system to be
]FAST, or to be 'compatible'??? What about colours? Sound? Just how far is
]the standarization reaching..?
] As a poor student - I cannot afford the new
]Forth Standard. And until I will be making $20+ an hour, I will not buy one.
]Maybe not even then... If my forth runs on my machine only, but does it well,
]why standarize? I don't see why you people use Forth, if you expect your code
]to work on different machines. If you want to port a small application, you
]might as well rewrite it - optimize it for the particular machine... If you
]are trying to port a larger application - well, consider yourself lucky if at
]least a minor portion of the code isn't written in assembly. Use C,or Pascal,
]or whatever... We do NOT need a Reverse-Polish C! (I apologize: I do not
]have the memory for names... Whoever said this before...)
] Certain things should remain the same for us to be able to call 'it'
]Forth - by all means... But this is too much like trying to standarize system
]calls between VMS, DOS, UNIX, and whatever else.. However 'neat' an idea - but
]unrealistc and, I feel, unneeded.
]---
]Jan (Yahn) Zawadzki
]INET: yahn@midget.towson.edu
]Bitnet: s72uzaw @ TOWSONVX
]---
The included article, to my reading, raises the following points:
1> He uses forth on a machine with a different set of abilities
from the Unix machines that I want to aim a standard towards. A
standard way of handling abilities that his machine doesn't really
have is bound to be horrible.
2> The forth standard is too expensive, so he'll never really see the
thing. The same holds for a very large part of the forth community.
3> He doesn't see any purpose for writing portable programs, for the
following reason:
a> if the program is small, you're better off completely recoding
it for efficiency on the new machine.
b> if the program is large, it's probably at least partly in
assembly, which is completly non-portable anyway.
So now, let me respond to these points, one by one:
1> I'm not suggesting an exhaustive standard. Things like window
environments, graphics, and other machine specific features should
not be covered by a standard, because they are non-standard. You
include non-standard words for non-standard functions! When you
use those functions, you do it with the understanding that you are
no longer completely portable.
2> I agree with you about the ANSI Forth standard. To me, one of the
attractive things about Forth is that it's a small, inexpensive
system to work with. I bought a complete Amiga Forth system with
a developers liscence for under $100. Now, they want me to pay that
much for a stack of paper? Ridiculous... But what I'm proposing is
a completely free standard. You want it? Fine, here's a copy for
you to download...
3> Both of these complaints are, in my opinion, utter nonsense. I
basically make a living porting software to Pyramid Unix boxes.
I've been doing it for about 7 months, and I've worked on over
200 different programs. The packages I've worked on have ranged
from 10 line Perl scripts, to multi-megabyte monstrosities like
gcc, and SRC-Modula3. In that time, I've never completely recoded
a package - at most, I've had to tweak a couple of routines. I've seen
a total of two packages that required ANY assembly language at all -
and each of them needed a total of two short subroutines. And I've
never seen a package where the CPU time I can save by writing
Pyramid specific code is more valuable than the time I take writing
it.
And finally, why do I want to use Forth at all if it's so
non-portable? Simple: productivity. I can do more work in less time
using a decent Forth system. The way things stand now, I totally lose
that advantage because of the time that I have to spend recoding each
of my programs for each of my machines. I could be more productive,
and do better work with a standard Forth system. And that goal,
increasing my productivity is the ENTIRE goal of the Forth as a
language!
In a different post, someone mentioned that screens give you the
ability to do incremental compilation. I concede the point.
The ability to do incremental compilation in a system like
Forth, without sacrificing speed and efficiency is worthwile.
I did a simple comparison: A4th on the Amiga, doing incremental
compilation using screens, works very nicely on a 512K machine,
without filling the machine. Tile with GnuEmacs on this pyramid
requires over a megabyte just for the object files, without even
considering the dataspace that Emacs requires. So, despite the
fact that I don't like screens, I do see how that can be useful!
<MC>
--
\ Mark Craig Carroll: <MC> \ "Humanity isn't a physical description,
\ Student Systems Programmer - LCSR \ it's a spiritual goal. It's not
\ Rutgers University \ something we're given, it's something
\ mccarrol@topaz.rutgers.edu \ we earn" -- Richard Bach, _One_dwp@willett.UUCP (Doug Philips) (01/10/90)
One thing that strikes me as curious is the reaction to the upcoming
ANSI standard. One of the more amusing things about comp.std.c is how
someone will post saying 'The standard breaks <X>'. The response is
almost always: 'The standard only documents that <X> is already broken.'
(or 'The standard only documents that <X> is not portable.')
Since I've only been reading comp.lang.forth for a short time, I'm sure this
has come up before. Could someone send me (or send me pointers to) the
articles about:
why Forth was brought to ANSI for standardization, and what
the politics were.
Is it a coincidence that 'C' came up at about the same time?
Is this a step in the maturation process of the language?
Is it time for Forth to mature some more?
Can it mature and still be Forth?
Thanks in advance,
Doug
---
Fastest: (willett!dwp@gateway.sei.cmu.edu OR ...!sei!willett!dwp)
...!{uunet,nfsun,sei}!willett!dwp [in a pinch: dwp@vega.fac.cs.cmu.edu]