peter@nuchat.UUCP (Peter da Silva) (04/07/88)
I'm sorry, but REXX just doesn't feel right. It's too big (conceptually) for
what I want to do. It ties too many functions into one package. It isn't zen.
I have the same feelings about Conman and a host of other programs that
people have written for the Amiga.
I'm sure they're great programs, but I just don't like the way they taste.
At the risk of sounding like the Emperor of Austria, they have too many
notes.
I have been given to understand, for example, that Conman includes a pipe
device. What's a pipe doing there? It doesn't make sense to me. Now, a clip-
board interface, that'd make sense. But not a pipe.
Similarly, REXX combines two dissimilar functions (at least they seem
dissimilar to me): a message system and a programming language.
I don't like the programming language. I'm NOT saying it's bad. I'm
just saying that I don't like it. Why should I have to write programs in
a language I don't like just to use the message ports?
I'm sure there are those of you who feel that awk is totally brain-dead,
but I'm not trying to convince anyone to use it. Use REXX if you prefer.
Just don't force me to... which is what will end up happening if it becomes
a standard.
Someone suggested I write a minimal REXX driver that just provides the message
ports. I'd rather not. I'm busy enough as it is doing work I get paid for.
I suppose I'll have to buy REXX just to see if I should provide a REXX port
in Browser. Grumble.
----------
And now for a plea. Please, people, before you do anything stop and ask
yourself if you can do it within the namespace of the file system. Programs
already know how to use that.
Let's not pull a System V and start adding new namespaces all over creation.
To quote from the Intuition manual (page whatever, under OpenWindow):
"Meanwhile, I still opt (and argue) for simplicity and elegance."
Pleaces that people have started doing this:
IPC.
REXX.
Multiple serial boards.
----------
And now an egoboo...
Peter Schachte... at first I didn't much care for your variant of my
PATH: proposal, but it's begone to grow on me. Yeh, I like it a bit better
than my own idea. Suggestions:
Please provide an easy way for programs to do AddPath and
DeletePath calls (say, by getting a lock on PATH:foobar and
passing non-standard packets).
You should be able to cd to a PATH: entry.
Doing an Open("PATH:c/foo", MODE_READONLY) should send
the Open packet to whatever foo's DeviceProc is and get
out of the way, for performance reasons. Otherwise I suspect
that you'll start seeing a slowdown in loading stuff from
PATH:c.
--
-- a clone of Peter (have you hugged your wolf today) da Silva `-_-'
-- normally ...!hoptoad!academ!uhnix1!sugar!peter U
-- Disclaimer: These aren't mere opinions... these are *values*.miner@dino.ulowell.edu (Rich Miner) (04/08/88)
In article <900@nuchat.UUCP> peter@nuchat.UUCP (Peter da Silva) writes: >I'm sorry, but REXX just doesn't feel right. It's too big (conceptually)... >I have the same feelings about Conman and a host of other programs ... Next thing you know he'll stomp on Bill's gold fish! :-) >I'm sure they're great programs, but I just don't like the way they taste. >I have been given to understand, for example, that Conman includes a pipe >device. What's a pipe doing there? It doesn't make sense to me. There is no pipe in Conman, get your facts straight! Conman is a replacement console device that adds functionality like command line editing. If you don't like the "taste", use workbench, because Conman "tastes" like standard console device, with a little gravy. Bill H. has also implemented a true pipe handler that can be accessed via shells, with or without running conman. >Similarly, REXX combines two dissimilar functions (at least they seem >dissimilar to me): a message system and a programming language. The concept of a procedural language accessible via message ports provides a powerful, flexible, and consistent environment. As an example: From within an editor (such as versions of DME, EMACS, and TxEd) you can interactively compile and locate errors in C code; startup Amiga-TeX to process a buffer; communicate with the MicroFiche Filer II running in server mode; interactively spell check an edit buffer... >Use REXX if you prefer. Just don't force me to... which is what will end >up happening if it becomes a standard. It is becoming a defacto standard. Over eight products I know of have ARexx interfaces, and ARexx is new. There are shells, editors, data bases, text processing systems, spell checkers, and other applications integrating ARexx interfaces. It helps the end user, and the developer. Just as intuition provides a common mouse/menu interface, ARexx provides a common procedural interface, and a method of application integration via message based IPC. >I suppose I'll have to buy REXX just to see if I should provide a REXX port >in Browser. Grumble. You haven't even worked with the system! How do you expect anyone to respect your opinions? Don't critique what you have not tried! >To quote from the Intuition manual (page whatever, under OpenWindow): >"Meanwhile, I still opt (and argue) for simplicity and elegance." If you looked at Bill Hawes programs you would see that he preaches and follows this same philosophy. I have used ARexx for several months, written a number of ARexx macros and an ARexx interface to an imaging library. It is a powerful tool that has been both easy to learn and work with. It saved me the effort of producing my own, non consistent, procedural interface and provides much more. Disclaimer: I know Bill Hawes personally and have worked with him on some of my ARexx adventures. -- Rich miner@dino.ulowell.edu 617/452-5000x2693 UL-CPE Imaging Research Lab
page@swan.ulowell.edu (Bob Page) (04/08/88)
miner@dino.ulowell.edu (Rich Miner) wrote: >There is no pipe in Conman, get your facts straight! There IS a pipe in conman. It costs only a few extra bytes of code, since conman was already doing most of the work. >Bill H. has also implemented a true pipe handler that can be accessed >via shells, with or without running conman. Well, when you mount the PIP: device you start the conhandler, that's conman. I don't know if the CON: replacement stuff starts up; I don't know anybody who's tried to get a PIP: without running conman. ..Bob -- Bob Page, U of Lowell CS Dept. page@swan.ulowell.edu ulowell!page
miner@dino.ulowell.edu (Rich Miner) (04/09/88)
In article <6042@swan.ulowell.edu> page@swan.ulowell.edu (Bob Page) writes: >miner@dino.ulowell.edu (Rich Miner) wrote: >>There is no pipe in Conman, get your facts straight! >There IS a pipe in conman. It costs only a few extra bytes of code, >since conman was already doing most of the work. I looked to hastely at my WShell, Conman, PIP: documents, to clear up my incorrect statement here is a quote from Bill Hawes' manual entry for piping in his WShell document. "9-1 The PIP: Handler Since piping must look like ordinary input or output to the reader and writer programs, respectively, the piping must be processed by and AmigaDOS handler. The WShell uses the pipe handler implemented as part of ConMan. This handler is named PIP: and must be mounted before the piping facility can be used." -- Rich miner@dino.ulowell.edu 617/452-5000x2693 UL-CPE Imaging Research Lab
peter@sugar.UUCP (Peter da Silva) (04/12/88)
Well, looks like I was wrong too... In article <1965@dino.ulowell.edu>, miner@dino.ulowell.edu (Rich Miner) writes: > The WShell uses the pipe handler implemented as part of ConMan. This > handler is named PIP: and must be mounted before the piping facility can ^^^^ ^^^^^^^^^^^^^^^ > be used." Looks like the piping in ConMan *is* done correctly, after all. Now if only ConMan itself was set up the same way. Now then, if I use (say) Ed Puckett's "P:" device and name it "PIP:" can I then use WShell without having to put up with ConMan? Or does it (as I suspect from Bill Hawes mention of special packets) not look like a regular PIPE: device? -- -- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter -- "Have you hugged your U wolf today?" ...!bellcore!tness1!sugar!peter -- Disclaimer: These aren't mere opinions, these are *values*.