Re: Is OO a deliberate fraud?

[tjoccam@xxxxxxxxxxx]

>
> Hi,
>
> On Wed, Jun 07, 2006 at 11:10:05AM -0700, tjoccam@xxxxxxxxxxx wrote:
>>
>> We need to go back to scratch, to static non-virtual assembly language
>> design, and build all serious design in a higher-level language free of
>> OO
>> and other infinite metaphor. Once we control the harness, they can use
>> OO
>> if they want for what it is good for: manipulating graphic widgets in a
>> GUI.
>
> I'm not completely convinced that OO is good for this either -- makes for
> good reasoning about the system's structure, but I've had issues with this
> sort of thing and C++ in the past (Java suffers a bit less here).  Won't
> bore you with the detail here; for the curious, http://frmb.org/rapp.html

I agree, but I want to leave SOME opening for OO: it's legacy code that
needs to be made workable, even in a "dream system" that is robustly
founded on process-oriented design. In other words, there will be a way to
do it right, IF we control the harness, and IF robust design principles
are applied even within the OO domain. For instance, the intuitive notion
of a GUI screen as overlaid opaque subscreens needs to be supported by a
model that enforces exactly that.

>
> On language design, we were pondering a while back about an occam-ish
> scripting language for bolting systems together.  It's currently
> incomplete, though there is a bit of a parser and execution engine in
> the pipeline.  A description of what we were thinking about can be
> found at, http://frmb.org/oscript.html

I looked at it, and it really looks promising. Be sure and look at the old
Inmos toolset ".PGM" files, which are strongly analogous to scripts, and
work robustly in both multitasking and multiprocessing. Imagine yourself
with total control of both boot and OS. If you want to look at my recent
white paper or old papers and programs, let me know; I did get this kind
of thing working in DOS with an extension of .BAT files. I am convinced
that a clean scripting language is the way to introduce the rest of the
world to CSP/occam/process-oriented (i.e. robust) programming.

Larry

>
>
> Cheers,
>
> -- Fred
>
>