OO and 'information oriented' programming (was Re: Simple Parser)

From: Ian Woods (newspub2_at_wuggyNOCAPS.org)
Date: 04/28/04 

Date: Wed, 28 Apr 2004 14:26:19 +0000 (UTC)

spinoza1111@yahoo.com (Edward G. Nilges) wrote in
news:f5dda427.0404280411.7f593d3c@posting.google.com:

> Ian Woods <newspub2@wuggyNOCAPS.org> wrote in message
> news:<Xns94D8ED295B645newspubwuggyorg@217.32.252.50>...
>> spinoza1111@yahoo.com (Edward G. Nilges) wrote in
>> news:f5dda427.0404271308.36681719@posting.google.com:
<snip>
>> If you're developing a compiler for a language for the first time,
>> having a parse tree is exceptionally handy IMO: you can check that
>> the grammar you're using does what you want, that some input parses
>> how you think it should and chase bugs more easilly in the parser or
>> grammar. It also separates the parsing and code generation parts of
>> the compiler in a natural way, allowing them to be developed with
>> little to no interdependency - something which 'object orientation'
>> fails to address in some contexts.
>
> I agree that in traditional non-OO development, a parse tree is a
> useful deliverable. You can print it out and see if it is correct.

What makes it not a useful deliverable in OO development?

The parse tree tells the developer a lot about the behaviour of a part of
the system in an easilly observable and verifiable manner. That's a good
trait to have during development no matter how the code which produces is
structured.

> But the situation, in my experience in OO development, changes and is
> radically novel...in OO development.
>
> You see, if you want a parse tree, you find that the recursive object
> "parse tree" (ideally a container for subtrees, objects of its own
> type) violates typing in that it occupies mental and electronic space
> alongside REAL entities, external to the compiler, such as "variable
> type" and "variable".

The point of parsing in the first place is to ensure that the input is a
valid sentential form of the grammar and to extract information from the
input which will later be used. It isn't the 'job' of the parser to
ensure that the code is semantically correct, merely that it is
syntactically correct.

As such, there's no need for the parser to 'violate typing', since it's
inputs and output are simply and well defined.

<snip>
>>
>> The lexer, parser and code generation stages could in fact be
>> developed as completely seperate entities with the only 'links'
>> between them being the data format used to communicate from one stage
>> to the other. They can be tested for both functionality and against
>> their respective specifications in isolation on a wide range of
>> inputs and outputs without any problems in one effecting another.
>>
> Yes, they could use a data base or XML to speak to one another,
> although computing purists might shudder at the very idea.

Or a data structure made of objects stored in memory, or a binary file,
network connections, pictures moved around via carrier pigeon or encoded
in the behaviour of some quantum-entangled particles.

Computers don't just process for the sake of it. The old 'garbage-in,
garbage out' is simply a very dumbed down statement about what programs
running on computers do: they consume some information (encoded as data),
perform some operation on it, and produce some other information (encoded
as data). If you put data in which /isn't/ information suitable for the
process, you don't get useful information out.

This is true no matter what programming methodology you use, what
operating system, what great new whizz-bang techniques you like. It all
comes down to the moving and processing of information. If a 'computer
purist' has a problem with such a concept, I suggest they need to look at
what their computers are doing and not how they're doing it.

> But an OO alternative would be producer/consumer such that the scanner
> populates a message queue which the compiler works on asynchronously.

But you don't need OO to do this... you're just doing what I've already
suggested but in a more complex manner:

As seperate tasks, the various parts of the compiler can be run either
synchronously or asynchronously without any alterations to their code.
The data produced by one unit is consumed by another: it is already a
producer/consumer system. Such asynchronous processing has been done on
UNIX and UNIX-like OSs without relying on object orientation for quite
some time now.

What you've suggested is no different from what I've suggested, except in
one regard: you've explicitely stated that it's an 'OO' alternative. I
suggest this: it's not an OO alternative at all but a IO (information
oriented) or 'flow based programming' alternative. You've merely decided
to implemented it using OO.

Way back when, in the days before C++ and other such 'OO' languages,
objects in OO communicated information using messages. An interesting
similarity.

> Since lexxing is merely low-level parsing, and there is no reason to
> "parse" without emitting some object code, perhaps for the same reason
> Marx said "the philosophers have attempted to understand the world;
> the point is to change it", I think it may be a mistake to so reify
> and hypostatize the pragmatism of "lexing", "parsing", and "generating
> object code" that you end up with a Frankencompiler, patched out of
> shreds.

If modulatity makes a Frankencompiler, then the whole of the computer
industry has been going in the wrong direction regarding complexity
reduction right from the beginning and all pieces of software should be
written as a single monolithic block of 'stuff'.

As I said earlier in this post, breaking down a problem into smaller
subproblems which are more easilly solved is the bread and butter work of
reducing complexity, a task at the core of software development. How you
like to divide your subproblems is up to you of course, but a different
division than what you prefer isn't by definition a bad way to do things.

Verify that code which 'solves' a subproblem behaves as specified is
terribly important, and, if I were in an evil mood I might even suggest
that complexity management techniques which don't make such a task
trivial are at fault for (at least some of) the 70-80% failure of
software systems.

> The original distinction is after all not theory but praxis, and an
> artifact of "not enough memory". One consistently finds that
> dignifying computing praxis as theory retards progress.
>
>> Personally, I have absolutley no qualms about 'breaking OO
>> encapsulation' if it reduces complexity, makes debugging easier and
>> reduces the difficulty of verifying that a subsystem conforms to
>> spec.
>>
> The problem is that if you start with properly designed OO
> encapsulation then breaking it increases complexity.

I have two OO objects, A and B which communicate information between them
using messages. In order for A and B to have a meaningful dialogue, the
messages sent and received must conform to a specification which is known
to both A and B.

I have two programs, A and B which communicate information between them
using messages. In order for A and B to have a meaningful dialogue, the
messages sent and received must conform to a specification which is known
to both A and B.

A and B are not objects - they're complete programs. They could be
written in different languages, using different methodologies... and yet
the mechanisms for how they work are no more complex than those used in
OO.

Riddle me this... where is the added complexity, where is
'encapsulation' in an OO sense broken?

<snip>

Ian Woods 

-- 
"I'm a paranoid schizophrenic sado-masochist.
My other half's out to get me and I can't wait."
Richard Heathfield
Quantcast