[Oberon] Essential facility missing.

[eas lab]

No!
This clown gmail system that I'm forced to use has fragmented the thread ideas
but: the <deeper idea is this>.

Understandably, when computing started in 50's they used the methods of
baking cakes. Later <the Algol boys> realised that the correct way is
stack-based;
which has not been replace since [did I explain how ants use it].

ML seems to carry it to extremes: conceptually there need be no names.
The previous result is called "it".

That's also why I've been harping on about <the functional paradigm>
 eg. to relocate that important file you read before being separated from your
system for 6 weeks.
  list all file in dir-tree <TreeName> |
  but not with name "*.pdf" NOR <add/modify *here* with out concern of
other stages!!>
  which are older than <42 days> |
  but only the ones containing "*oeing" |
  and also containing "efault" |
  <add further stages as required, without concern for previous stages>

So yes, of course you can/will be able to order the dir-listing in many ways.
But by NOT making [stack-like]/recentcy the default order, you show that
you've not analysed/understood to work process.

Like using the [apparently prairie-farmer-based] US method of
ordering dates by: Month-day-year ?!?

Alphabetical ordering is NOUN-based for casual/ignorant visitors.
stack/recentcy based is VERB-based for systems/users who are in flight,
  needing to perform the task at minimum cost.

NON-based is learning what it's called, which is arbitrary and even
language dependent..
VERB-based is knowing where it fits in the structure. Never mind what
it's named is.

== Chris Glur.



On 3/30/16, Lars <noreply at z505.com> wrote:
> On Tue, March 8, 2016 4:39 am, Douglas G. Danforth wrote:
>> In the BlackBox version of Oberon (Component Pascal)
>> one has access to the underlying operating systems directory structure.
>> So
>> when one selects Files->Open one sees the directories.  One can then
>> specify that they be listed in chronological order (or reverse order).
>> The same holds
>> true when one descends into a directory and sees the files. Here's what
>> that looks like
>>
>> You obviously are using the a version of Oberon not suited to your needs.
>>  -Doug Danforth
>>
>>
>
> But isn't this a bit like saying, the sports car doesn't have heated seats
> available so you should just try the Truck or Sport Utility vehicle
> instead.  But if the sports car had heated seats as an option, that would
> give you the best of both worlds - and it's not super hard to implement
> for the car company.
>
> This is where I see fragmentation becomes an issue.  Oberon doesn't have
> this, so use the other version... Whereas something like Python, there is
> only one python to really use, one main python distro. One main golang
> tool. Oberon becomes super fragmented with about 100 different flavors.
> Linux also suffers this fragmentation issue with 10,000 different linux
> distros.
>
> Not saying I have a cure all solution to the problem nor should anyone
> form a monopoly that packs the kitchen sink into one package (emacs).
> --
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
> https://lists.inf.ethz.ch/mailman/listinfo/oberon
>