Re: Date's First Great Blunder

"Dawn M. Wolthuis" <dwolt_at_tincat-group.com> wrote in message news:c5kave$i4r$1_at_news.netins.net...
> "Eric Kaun" <ekaun_at_yahoo.com> wrote in message
> news:4Lhfc.281$%r4.200_at_newssvr16.news.prodigy.com...
> > And all of that is just for persistence - the value of constraints is
> > another large gap. Most OO languages are pure implementation, which
gives
> > much room for programmers to blunder and violate any number of useful
> > principles.
>
> There is a certain point where in order to give software developers the
> tools they need to do their jobs well, we have to give them enough rope to
> hang themselves.

That may be true, but giving them enough rope to hang themselves doesn't imply we've given them the right tools. I see lots of swingin' programmers... and OO really gives very little. At its best, OO languages are good for implementing types, but since there's no corresponding Relation type in most languages, object classes also have to be used like relations (relvars - variables). And then the line gets very fuzzy, which is where OO mistakes creep in. The failure to draw the line is one of the problems - simplify as much as possible, but not more so. OO's simple "everything is an object" mantra simplifies to the point of allowing developers to easily create unmanageable complexity, and without knowing it until it's too late.

> OK, then I see a class as the intension and the domain as the extension.

Hmmm... so the domain is all allowable objects, or the members that currently exist?

> > I'm not just splitting hairs - I think these are genuine issues. I don't
> > think code is metadata - I think it's implementation of a "spec". (Spec
> > meaning, loosely, constraints such as preconditions, postconditions,
> > invariants.)
>
> If someone uses an IDE and the specification of a GUI component, such as a
> drop-down, is stored in the IDE, do you consider such stored information
to
> be metadata related to the developed software?
>
> It is data about the "data"
> (the latter data being software components). Similarly, the written code
is
> a specification of the software that runs.

You're right. But what then specifies the code? We've moved beyond having to write machine code itself, so why did we stop with executable code that's basically very similar to the needs of the CPU? Procedural rather than declarative. We still don't trust the machines to figure it out, and in the process gives ourselves much work the machine could be doing.

> > Code can't be considered to be metadata about software-as-data, because
> > typically the code is the software. And in any event, (procedural) code
is
> > difficult to reason about, which is why specs are useful.
>
> "The code is the spec" -- the final blueprint for the software is the
> written code, which is then compiled and runs as software in some
> environment.

True, but again, very low level. You don't need those Pick dictionaries - you could access bytes directly. You just wouldn't want to. We should be beyond that by now, so we're talking about what abstractions are useful to computing.

> > As an aside, check out some "functional" languages (Haskell, ML, Lisp)
for
> a
> > look at effective reuse without objects. Reuse is hard for human
reasons,
> > and OO doesn't really help much. Inheritance, the unique OO spin on
reuse,
> > is overrated and, done poorly, undermines other useful properties like
> > substitutability and interface definitions.
>
> Interfaces are a good example of OO code reuse, don't you think?

Interfaces are more specification than reuse. Abstract base classes are for reuse, but it's very, very easy to get things horribly wrong. Most developers make a ton of member variables protected, let subclasses use them, and there the fun starts. Without constraints/contracts that go beyond the mere interface, there's no way to guarantee or even document that a subclass is breaking its superclass's contract. More reason to have constraints in the language, or to develop purely at the level of the constraints themselves.

> > But regarding my statement, it's impossible in many OO languages to
define
> a
> > function without a preferred parameter. I can't do "doFoo(x, y)", but
> > instead have to do either "x.doFoo(y)" or "y.doFoo(x)".
>
> Or doFoo(z) where z = (x, y)

But in Java, where do you place the doFoo method?

> Yes, I can see that there are some things that are very brittle. I don't
> mind Java, however, in spite of my closet procedural bent (having started
in
> the industry with FORTRAN, BASIC, and COBOL).

I don't mind Java either - it's a fine assembly language. I just want to move my development up a full notch, rather than just chasing crumbs from various Java-based frameworks.

> Declarative is my least
> favorite language, based on "taste" not logic.

It's possible to write Java in a more functional style, by aiming for immutable classes (types) and methods as short as possible (e.g. if you've more than a few lines, you're probably missing a layer of abstraction). But other parts of the language get in the way...

• erk