Re: [Oberon] Incremental evolution of piping system?
On Tue, January 10, 2017 8:24 pm, eas lab wrote:
*Importantly* FP/piping gives extreme modularity
Piping also gives danger... make one little mistake and your entire pipe could be very dangerous.. This is what has always scared me about unix commands, one little error and you can eff up your system.. even a typo... There is no "recycle bin" to back up and get out of what you just did, unless, you made a backup of your system before running a command. That would mean every single command you ever run, you have to make a backup first, which no one does.. Now on the other hand if your pipe isn't doing that much which is dangerous, i.e. just getting a read only output of something....
It is dangerous as piping is typeless. Jörg
Am 11.01.2017 um 22:10 schrieb Lars <noreply@z505.com>:
On Tue, January 10, 2017 8:24 pm, eas lab wrote: *Importantly* FP/piping gives extreme modularity
Piping also gives danger...
make one little mistake and your entire pipe could be very dangerous..
This is what has always scared me about unix commands, one little error and you can eff up your system.. even a typo...
There is no "recycle bin" to back up and get out of what you just did, unless, you made a backup of your system before running a command. That would mean every single command you ever run, you have to make a backup first, which no one does..
Now on the other hand if your pipe isn't doing that much which is dangerous, i.e. just getting a read only output of something....
-- Oberon@lists.inf.ethz.ch mailing list for ETH Oberon and related systems https://lists.inf.ethz.ch/mailman/listinfo/oberon
It is dangerous as piping is typeless. Jörg ====== That is correct: at the level which you are seeing it. But I'm considering a higher level.
Yes, wasn't the <space-craft disaster> of some decades ago, avoidable by typing. But the human aspect trumps the technology, in IT. That's why ETHO is so great: they got the HCI right; which is much more important [increase productivity] than technology to increase speed. I'm not proposing casual-piping for going to Mars. I'm talking about improving the efficiency [cost-benefit] for <scratching your ear>. When I discussed transferring info between my MOBO and the RPi lying on the table next to it, they told about eth0 with secret decoding. That's as aburd as using the National railway system to fetch a glass of water from the adjacent room. Consider an extreme example of what I'm proposing:- [since I'm using M$ now I must just guess the syntax] I want to count the number of times that <string> appears in files:*name*. MANUALLY this might go: System.Directory *name* returns a Frame listing the files <Find.Domain & Find.All ^ <string> as I remember finds the matches and I don't know how to fit-in the counting. In *nix the 3 FUNCTIONS are something like: find <directory> -name files"name* | .... grep <string> | wc -l Do you want to enforce strict type declarations here? How do you want to do this in ETHO. With piping/functional/concatenative the 3 functions are independent re-usable modules. And there are no extra variables to consider [burden the mind with]. As I've repeately pointed out: ETHO's manual method, already uses piping, where the stages consist of extra Frames. == Chris Glur.
participants (3)
-
eas lab -
Jörg Straube -
Lars