Re: One Ring to Bind Them

From: Dawn M. Wolthuis <dwolt_at_tincat-group.com>
Date: Wed, 16 Jun 2004 10:20:13 -0500
Message-ID: <capofk$3rc$1@news.netins.net>

"Eric Kaun" <ekaun_at_yahoo.com> wrote in message news:h2Zzc.1822$Pt.1440_at_newssvr19.news.prodigy.com...
> "Dawn M. Wolthuis" <dwolt_at_tincat-group.com> wrote in message
> news:can9nq$q7r$1_at_news.netins.net...

<snip>
 <snip>
 > My issues with declarative include:
> >
> > 1) There seem to be no standards for the black box that does something
> with
> > the declarations. I don't need standards-committees with years of
process
> > to adopt a standard -- I don't even know anything that would help ensure
> > portability of such declarations. SQL has come the closest and does
have
> > standards, but we all know you can't just take any code you write
against
> > one database and run it against another.

>

> True enough; SQL is so convoluted, and the standard so large, that it's
> difficult to implement. Contrast with the J2EE spec which, while also
large
> (and overwritten in Sun's usual verbose style, writing 100 pages where 10
> would do), is implemented fairly quickly by commercial and open-source
> vendors within 6 months of its release. SQL is atrocious.

>

> That said, the standard for the black box should be a coherent spec, which
> implies the need for a coherent language.

One issue ties back into the UI used by a developer for specifying anything. We aren't just talking about languages that are typed in, but some drawn with boxes, some spec'd with drop-down boxes, etc, so that the data collected for a specification (whether declarative or not) is related to the proprietary UI. Somehow we need to get not only a language captured, but also an IDE (bad word for me), sort of. So, there are standards being developed for IDEs. Whether a declarative or procedural or OO language flows from the UI, the user (developer) ends up specifying data that gets stored by the toolset as well as generating anything that might be needed. That was said in a convoluted way, but my point is that language standards are not enough to protect my investment as soon as I opt for a tool from Oracle or IBM or MS or whomever.

>

> > 2) It doesn't read like English -- the verbs are missing, for example.
> I'd
> > like to keep some of Grace Hopper's goal alive of writing code that
human
> > beings can read

>

> I think that dream is dead. English is a poor basis for automation, and
> defining a useful subset would get us into even murkier water than the
c.d.t
> glossary. Nonetheless, relational offers a more useful basic structure
(the
> predicate, which is a sentence) than Pick/MV, which aspires to nouns.
> Objects also aspire to be nouns, leaving verbs and sentences
"encapsulated",
> whatever that means (I know that it means, but doubt its utility in all
> things).

and the others who spoke up were right that a declarative language (such as SQL) does have declarations that are like sentences (SELECT this, that FROM arelation) while a language that is spec'd -- options chosen -- is a set of parms (kinda RPG-like for those who don't think that means role-playing games). And I do agree that English as we speak it is not the goal, but just like the Palm Pilot taught us to write so it could understand, I do think that is a reasonable way to approach a language. COBOL has its charm. Java, along with other modern languages are unnecessarily cryptic to the seasoned IT professional picking up the language for a first time.

> > 3) While hiding much that should be hidden, it "feels like" so much gets
> > hidden that people spend time trying to figure out how it does things in
> > order to be good at writing declarations
>
> A valid criticism. I could chalk much of that up to the
operationally-minded
> education of most programmers ("we're going to teach you to program just
> like a compiler writes machine code!"),

I'd argue that it is not just the instruction, but the nature of people that we think in terms of what to do in what order.

> but it is true that it's harder
> initially. I just think it would pay off, and that the learning curve,
while
> somewhat steep, has dividends (and not just in the long term; perhaps in
the
> "medium" range).

>
> > 4) Invariably functions become one of the things to get specified. If
we
> > are going to specify both data and functions, which, afterall, is what
> needs
> > to happen,

>

> But I draw a distinction between specifying a function and implementing it
> operationally. I can code a function in Java (even though I have to attach
> it to a class)

or upset the OO purists and write a class that IS a function ;-)

, but contrast that with any algebraic specification of a
> function; maybe something like Prolog, where you are simply defining terms
> using input patterns (pardon the gross oversimplification). True, you may
> have to optimize later; but you don't have to decide on the optimization
(or
> on a sub-optimal algorithm) early.

>

> > then what benefit is there to specifying a function and
> > specifying where it is to be used rather than specifying the function
and
> > then using it where it needs to be used?

>

> I'm not sure what you mean here. If you're arguing for the separation of
> data and function, I tend to agree; however, that's a very non-OO position
> to take... is that what you intended?

No, rather the opposite -- data and functions are two sides of the same coin. So, clearly I wasn't writing clearly. My point is that you either write a function directly in procedural or OO code or you spec them and spec when they are to be used -- 6 of one, half-dozen of the other. Having seen so many languages without trying to collect them over my career, I have not yet seen one that makes an order of magnitude break-through in productivity for the developer. It seems to me that Java and OO languages had a good chance of providing large chunks for reuse, but they aren't there. It isn't a silver bullet, but I'm thinking the services strategy, which is language independent, has a chance at helping to get some of those bigger gains. Knock on wood.

--dawn Received on Wed Jun 16 2004 - 10:20:13 CDT