[Oberon] Need V4 Code for trivial task.

[eas lab]

Skulski wrote:-
] 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.

No: GraphicalUserInterface is orthoginal to "number of inputs/outputs.
It's just that the CommandLineInput [ie. instead of selecting from a
menu] is more tolerable with the economy of concepts and corresponding
economy of tokens in a command.
-----------------
]..you are advocating a paradigm which Oberon System (and any other
] GUI system) has explicitly disposed of.

No, and that's also why lisp and Forth are not being replaced.
Haskell seems to be taking the lead, but lacks a NW who can analyse
and explain the subtle aspects, instead of lapsing into "it feels nice".

We have a reader here who built an <Oberon Functional system> and who
presumably should have plently to tell, but his system uses the absurd
MocroSoft convention of haveing multi-word-tokens, which kills the
UserInterface aspect, which you have rightly emphasised is vitally
important.

For me the User-Interface, which is quite independant of imperative,
declarative, functional/piping style, is of great importace and a big
plus for ETHO. Apparently python & Haskel, also use format/indentation
as part of the syntax; and case-of-1st-letter-of-tokens.
Similarly syntax hi-lighting/colouring has value.
--------------------------
]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.

What happened to nested functions which TurboPascal & my P-code
interpreter used?   Like:
count the sentences in dirTree:D in Files:F which contain "blue" & "red"

 ListAllFilesIn D | Filter F| extract sentences |\
 grep "blue" | grep "red" | IncrCounter

   NameMatches [ListFiles (Dir),NameF]
... it's too difficult. That's why the piping-notation is good.
------------------------------------
Chris Burrows wrote:-
] the following command sequence to get a directory listing
] sorted by descending date and then paged to the screen:
]
] dir /O-D | more

That's a perfect example of a vital command/tool,
implemented by merely 4 tokens.
 -----------------
Douglas G Danforth wrote:-
> 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 machine written in Pascal.
> I never want to go back to that form of "linear thinking".

You conflate the BUILDING of the item with the USE of the item.
Perhaps it's not as much fun PRODUCING choclate as EATING it?

Yes LINEAR thinking is ONE dimensional.
I like to reduce the thinking to the MINIMAL <dimensionality>.
It's the MULTI-dimensionality that most tasks seem to entail that
pains me. That's where ETHO proves superior to even `wily` by
handleing an extra dimension by MULTIPLE colorS.

> I greatly prefer the GUI Oberon approach.

One of the few substantial projects I did was via TurboPascal-3,
and I've been wondering how the DOS-based system made the menues
and different source-files so effortlessly available, whereas
gmail & M$: via a generation later [MODERN giant corporationS]
are so lame! Gmail cut off 2 of my 3 accounts, when my system was
stolen and I was forced to use my RPi with a TV-set and slow Inet,
because they "detected strange activity". So they used their
multidimensional game of sending you passwords to one account to
confirm/unlock another account, and then cut-off the game/cycle
once you had used the confirming phone-number N-times,
because they had simplistically designed <limitation of N accounts
per single phone-number>.
If the above had been linear, it would be easier to understand?