[Oberon] Need V4 Code for trivial task.

[Bob Walkden]

The pipe'n'filter style arises from the batch processing habits of yore whereas Oberon was written for an interactive workstation. They each have their uses, and I wouldn't dismiss either of them out-of-hand, or consider either of them to be the final grand answer to everything.

They're not the only options either. Clements, Bass et al. have written a lot about software architectural styles, their strengths and weaknesses. Worth being familiar with them.

http://resources.sei.cmu.edu/library/asset-view.cfm?assetid=30264

B

On 7 Dec 2016, at 09:21, Douglas G Danforth <danforth at greenwoodfarm.com<mailto:danforth at greenwoodfarm.com>> wrote:

W,
Thank you for saying that!
I was paid $3,000 in 1979 by Three Rivers Computer to implement a Unix shell with pipes.
I did that on a Terak<https://en.wikipedia.org/wiki/Terak_8510/a> machine written in Pascal.
I never want to go back to that form of "linear thinking".
I greatly prefer the GUI Oberon approach.
-Doug Danforth

On 12/6/2016 7:44 PM, Skulski, Wojciech wrote:

But it's not as modular/simple/safe as the canonical piping syntax:
  InputFile |Filter1 |Filter2....|FilterN > OutputFile


Unix pipes are based on a certain programming paradigm which is different from the Oberon System and from GUI-based systems in general. The piping paradigm is based on the notion of a program transforming input into output, which was inspired by the chain "card reader --> computer --> card punch". You may recall:

PROGRAM CALC (INPUT, OUTPUT)

In Unix input is named stdin, output is named stdout, but the idea is the same. Piping means that the output of one program becomes the input to another one. It can be achieved with punched card decks, files on disk, or FIFO in memory. The technical details are secondary. The key to understanding is the word "sequential". Unix pipes can give you an illusion of concurrent execution, but the data is in in fact transformed sequentially.

The GUI paradigm is a different one. GUI systems do not have one input and one output. GUI can take its input from anywhere and it can put the output anywhere. The GUI is manifestly parallel, even though under the hood all the processing is performed sequentially. But here the sequential processing becomes a secondary implementation detail. The paradigm itself is parallel.

After saying all this I would declare that you are advocating a paradigm which Oberon System (and any other GUI system) has explicitly disposed of. Your piping can be implemented in Oberon with an executable program whose interface would explicitly say PROGRAM (input, output) or "function main (stdin, stdout)", or something compatible. There are Oberon compilers which will produce this kind on an executable. Oberon System is not one of of them.

W.
--
Oberon at lists.inf.ethz.ch<mailto:Oberon at lists.inf.ethz.ch> mailing list for ETH Oberon and related systems
https://lists.inf.ethz.ch/mailman/listinfo/oberon




--
Danforth of the Greenwood

--
Oberon at lists.inf.ethz.ch<mailto:Oberon at lists.inf.ethz.ch> mailing list for ETH Oberon and related systems
https://lists.inf.ethz.ch/mailman/listinfo/oberon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.inf.ethz.ch/pipermail/oberon/attachments/20161207/57c621aa/attachment.html>