[Oberon] Re: Some questions about BB evolution.

[eas-lab at absamail.co.za]

> > Even with 'zero cost' hardware (redundant machines
> > from 1st world)
> > usage will not grow without applications. 
> > Net-working (email &
> > newsgroups: fidonet is strong in ex-soviet
> > countries) would drive usage.
> > I remember the days when 300 Baud connection speeds
> > were OK.
> > I believe that a minimumal cost modem - manchester
> > modem perhaps -
> > could suffice for < 2400 Baud.  I've tested the
> > transmit side driver from
> > a par.port via a few resistors: D to A; and
> > speculate/hope that the 
> > receive side is doable with minimum cost.   Since
> > the ex-soviet countries
> > have functioning telephone networks with low
> > charges, minimal cost
> > networking could build oberon user base ?
> 
John Drake wrote:
> At such low speeds you can skip the phone company
> and go with packet radio.
>  
Yes, packet radio is good for low-density (rural), but it doesn't
fit the near zero cost model ? I guess old modems get lost &
discarded easier than computers because of the size ?
So a new modem needs to be bought ?
I guess 20 redundant computers could be bought for the price
of a packet radio installation ?

In asia and africa packet radio is applicable, but ex-soviet
countries HAVE a functioning telco network.

> > Can any one remember when data was stored to audio
> > cassettes ?
> 
> Yes.  It was a very bad experience for me.  I had
> a trs-80 Coco.  I had to balance the slow tedious
> process of saving programs with the very real
> prospect of a power drop.  (I lived in a rural
> area).  

It's very difficult for a US resident to appreciate the value of
minimal vital information when we are bombarded with masses
of garbage.  Imagine yourself 300 years ago, on a hill top in 
England scanning the sea-horizon for the ship returning
from distant lands: a timely single-bit of information - perhaps
by a flag, could determine your life's savings !

> > I had a cassette version of a subset of Pascal from
> > Microsoft, with a
> > 10 page A4 pamphlet, for the Z80 based TRS. The
> > software consisted
> > of a small p-code interpreter, and the compiler was
> > directly from 
> > Wirth's book.   It was better than n-o, because as
> > the source was 
> > scanned it was written to display, and just stopped
> > at the error!
> > I really think 'smart compilers' that claim to find
> > multiple errors are 
> > a bluff. 
> > 
>  
> I don't see how you can charecterize that as 
> "better".  Getting a compiler to stop at the first
> error is trivial to do.  With a "smart compiler"
> you can still treat it as a "dumb compiler" if
> you so wish.  All you have to do is work from
> the top down, only fix the first error and 
> recompile.  

Well, the first time n-o compiled in 2 miliseconds
instead of 2'000 I was impressed at the 1998ms. saved.
But after I had to select the position number and 
MM 'locate', I was less impressed.   I suspect there is
great value seeing the source code scroll past, during the
recursive descent compilation, as it helps imprint the sources
'structure' on the mind.  The newish popup facility to
easily locate PROC <id> suggests that others besides me
get lost in navigating even small source code.

> But after gaining some familiarity
> with the language and system being used I've
> found that you can be much more productive with
> the smart compilers.  I always start at the
> top of the code and work my way down fixing
> compile errors.  That way if the error I'm
> looking at was actually produced by something
> I just fixed higher in the code I'll already
> be aware of that and move on to the next error.
> Also compilation is so fast in Oberon that
> it's practically instant.  Since the compiler
> and editor are much better integrated than in
> the "Pascal" days it's more of an "edit/test"
> cycle then an "edit/compile/test" cycle.

In the days when you had to submit and wait for
a compilation it might have justified trying to 
fix multiple errors.  Now it's not. And it discourages
successive refinement - small steps.

-- Chris Glur.