Discussion:
Blackbox Component Builder is now free!
(too old to reply)
n***@top-post
2004-07-24 16:22:24 UTC
Permalink
Is there anything implemented in Blackbox for data acquisition or
signal processing? I assume that a killer application, like an
alternative to Labview/Agilent VEE, would boost its popularity.
--- [snip ]---
The native Oberon-systems
are really interesting (BlueBottle), since e.g. they
need no distinction between user- and kernel-space etc.
But not everyone is going to boot into Oberon to use e.g.
an instant messenger ;-)
Well the boot time is seconds.
My normal OS is native oberon which is up continually.
Some times I need to 'boot into' Linux to eg. view *.pdf
which is done on another box.
Usually users do not care what
language their applications are written in. It seems to me
that it is more important how useful they are, how much
memory they need, speed matters and of course reliability
and stability.
That's really what it's about.
IMO n-o's addicting attribute is the interface - mouse cording
with the text-frame-design.
Although this has no direct link to the oberon syntax; my theory
is that Wirth's influence facilitated the evolution of this powerful I/O.

Yesterday I needed to extract some 250 lines off of the public
library CD to a fd0 to bring to my n-o box.
What an awkward turkey M$win is compared to n-o !
From what I have read Oberon claims to be a safe
language, it's implementations have modest memory requirements
and decent code quality. So it ought to be perfect!?
--- [snip ]---
Ciao,
Dominic
P.S. Still wondering, if anyone is using Oberon besides Niklaus Wirth...
7 days a week; typically 3 times a day on line for 5 minutes:
6 emails [most http fetched by email] + 8 news articles per session.

One of the many differences of n-o [as noted, I suspect the radical
improvement from convention was from Wirth's "work from first
principles, rather than just copy 'how ist is usually done' " ability]
is that net-fetched-stuff is not by default to a file.
'The deliveries go on the work bench instead of to the store'.
So the text frames are stacked, and you don't want to power down
ever. Like in hardware: when you've got a 10 meter long work-bench
[movable, or your chair on wheels] and you have typically 8 projects
open at a time - eg. waiting for parts to arrive. Typically a project
may be on the work-bench for 10 days before it's completed and
sent to the store. To acheive the potential productivety, you can't
be re-booting like M$ !

== Chris Glur.
Dominic
2004-07-24 18:36:11 UTC
Permalink
Post by n***@top-post
P.S. Still wondering, if anyone is using Oberon besides Niklaus Wirth...
6 emails [most http fetched by email] + 8 news articles per session.
One of the many differences of n-o [as noted, I suspect the radical
improvement from convention was from Wirth's "work from first
principles, rather than just copy 'how ist is usually done' " ability]
is that net-fetched-stuff is not by default to a file.
'The deliveries go on the work bench instead of to the store'.
So the text frames are stacked, and you don't want to power down
ever. Like in hardware: when you've got a 10 meter long work-bench
[movable, or your chair on wheels] and you have typically 8 projects
open at a time - eg. waiting for parts to arrive. Typically a project
may be on the work-bench for 10 days before it's completed and
sent to the store. To acheive the potential productivety, you can't
be re-booting like M$ !
I am sorry. I must admit this has been a troll attempt ;-)
It is not like I do not care about Oberon. I had been
trying to figure out what the "spirit" of Oberon really is.
Now, I think I have a pretty good idea.

For the 80s Oberon-2 is/was a great programming language.
Obviously, there have been various attempts to cure some
shortcomings (e.g. Blackbox Component Pascal).
However what bothers me most after reading some Oberon
source-code and Mössenböcks "OOP in Oberon-2" are

(1) Split of interfaces into event-(records) and method-interfaces -
since type safety is lost and interface-specification suffers.
Compare this e.g. with bi-directional interfaces in TinyOS's
nesC-language. Or if events are deemed necessary:
Java's Swing event system, though I think it's to verbose.
(fixed in Oberon for .net ?)
(2) Data structure libraries suffer from the lack of
generics or templates. Type safety lost again.
A "counter-measure", which seems to be quite popular
among Oberon users, is to use linked-records
(easy to code) and re-implement list iteration and
insertion etc. for every type needed!
Other data-structures are hardly used.
(generics considered in Gardens Point Component Pascal for .net ?)
(3) Exceptions + Concurrency
(done)
(4) The one I forgot :-( - maybe it was error-handling
in Oberon-(2) source.....

Many Oberon related papers praise Oberon's safety since
it has a sound type system and uses garbage collection.
Well, I agree as long as C is considered the only competition.
Nevertheless if I had to to an embedded project today I
would choose Oberon over C or C++. Besides: Is the source
code of xo2 or xoberon available for download?

ciao,
Dominic


P.S. Regarding Bluebottle - I'll download it and see myself.
Dominic
2004-07-24 18:57:32 UTC
Permalink
Post by n***@top-post
P.S. Still wondering, if anyone is using Oberon besides Niklaus Wirth...
6 emails [most http fetched by email] + 8 news articles per session.
One of the many differences of n-o [as noted, I suspect the radical
improvement from convention was from Wirth's "work from first
principles, rather than just copy 'how ist is usually done' " ability]
is that net-fetched-stuff is not by default to a file.
'The deliveries go on the work bench instead of to the store'.
So the text frames are stacked, and you don't want to power down
ever. Like in hardware: when you've got a 10 meter long work-bench
[movable, or your chair on wheels] and you have typically 8 projects
open at a time - eg. waiting for parts to arrive. Typically a project
may be on the work-bench for 10 days before it's completed and
sent to the store. To acheive the potential productivety, you can't
be re-booting like M$ !
It is not like I do not care about Oberon. I had been
trying to figure out what the "spirit" of Oberon really is.
Now, I think I have a pretty good idea.

For the 80s Oberon-2 is/was a great programming language.
Obviously, there have been various attempts to cure some
shortcomings (e.g. Blackbox Component Pascal).
However what bothers me most after reading some Oberon
source-code and Mössenböcks "OOP in Oberon-2" are

(1) Split of interfaces into event-(records) and method-interfaces -
since type safety is lost and interface-specification suffers.
Compare this e.g. with bi-directional interfaces in TinyOS's
nesC-language. Or if events are deemed necessary:
Java's Swing event system, though I think it's too verbose.
(fixed in Oberon for .net ?)
(2) Data structure libraries suffer from the lack of
generics or templates. Type safety lost again.
A "counter-measure", which seems to be quite popular
among Oberon users, is to use linked-records
(easy to code) and re-implement list iteration and
insertion etc. for every type needed!
Other data-structures are hardly used.
(generics considered in Gardens Point Component Pascal for .net ?)
(3) Exceptions + Concurrency
(done)
(4) The one I forgot :-( - maybe it was error-handling
in Oberon-(2) source.....

Many Oberon related papers praise Oberon's safety since
it has a sound type system and uses garbage collection.
Well, I agree as long as C is considered the only competition.
Nevertheless if I had to do an embedded project today I
would most likely choose Oberon over C or C++.
Besides: Is the source code of xo2 or xoberon available
for download?

ciao,
Dominic


P.S. Regarding Bluebottle - I'll download it and see myself.
Sjur Vestli
2004-07-25 09:41:58 UTC
Permalink
Post by Dominic
Besides: Is the source code of xo2 or xoberon available
for download?
No, but XO/2 is used for a number of commercial systems and is available
with BSP (Board Support Package) for PowerPC based VME and PowerPC based
CompactPCI. You may also want to check www.xo2.org.

Kind regards

Sjur J. Vestli

Loading...