Re: too much OOP ?

On Wed, 2 Jan 2008 09:49:38 -0800 (PST), frebe wrote:

The point is that when the language constructs are in terms of
records, while you can say "customer," in the language, then "customer" is
a higher level abstraction (relatively to the built-in language core), so
the design is.

So a relation named customer is a high-level construct?

Yes, if that fully implemented all relevant aspects of customer. In
philosophy relations do. In programming it could be very tricky to describe
abstractions in terms of their relations.

If you had a language which could directly describe the
customer as a term, then that language would be low-level. It is all
relative.

Sorry, you lost me again... I think both Java and SQL are able to
directly describe customer as a term.

Term was meant as "terminal symbol."

And you still claim that MOV and UPDATE have the same algorithmic
complexity?

Yes. A primitive operation has alleged complexity 1. You can't look into,
it is dark in there...

So if any primitive in the language has complexity 1, how can
different languages ever have different complexity?

They don't have in this sense. That's why people wanted to nGL in order to
do things complex in nGL,simple in n+1GL. But we still talking about
different complexities.

Having to think of only some things in the implementation of the
constructs, is much better than actually having to implement the
constructs by yourself.

There are two issues:

1. When reused, then from the complexity point of view it makes no
difference whether you have to analyse built-in constructs or ones
designed.

2. When designed new, programming is like an exploding universe. There is
no chance keep pace with by mounting 5326GL on 5325GL.

Bigger is n in nGL, more
attention you have to pay and increasingly difficult it becomes to foresee.
This breaks abstractions of the language constructs.

I can imagine the same discussion in the 60's, when 3GL was
introduced.

It is not same. That time there were no abstract data types. The dominating
ideas were extensible and specialized programming languages. Extensible
languages died first. Specialized lingered a while.

For 5GL it became just
catastrophic. We cannot go this way.

I think that when we get some sound theory backing up more 4GL or even
5GL, we will go this way.

OK, foundations is an important issue, though I see it differently. Note
that some 4GL languages survived not only because they reduced complexity.
Another important thing was correctness. A specialized language is much
weaker and limiting than a universal one, so some of them, quite
unintentionally I guess, appeared relatively easy to analyse for some
aspects of correctness. So we have a lot of modeling 4GL languages used for
code generation. Differently to you I believe that sound foundations will
sweep them out by making reasonable correctness analysis possible at the
3GL level.

Currently one of the few sound theories to
backing up 4GL is relational algebra.

Huh, it was very unfortunate to all of us that RA was first used in 4GL. If
"relational people" did it in a 3GL with an elaborated types system then it
would have became just a decent part of mainstream OO. There is nothing in
RA that limits it to databases only. Databases will die sooner or later, RA
will not.

I have to ask you another question. In your first post, you claimed
SQL being low level. Now you seem to agree that SQL is high level
language.

I didn't say that. I only said that when C and SQL were compiled into, say,
x86 machine code, then likely SQL-code would look more complex. But, if we
took a LISP-machine as the target, then it could turn otherwise. Again, it
makes no sense to talk about absolute level height.

Instead you argue that too high level languages shouldn't be
used. Is this observation correct?

Yes, if they do not fit exactly.

Do you think that all developers
using SQL database are making a mistake? Would it be better if they
implemented the data management logic in their applications instead?
Or should they use some other kind of database?

They should not consider the target platform, unless absolutely necessary.
Already the mindset "we use SQL database" is as wrong as "we use AMD
processor." Database is a part of hardware platform.

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
.

Relevant Pages

  • Berlinski paper presented 1985 at Applied systems analysis
    ... Complexity, Language and Life: Mathematical Approaches, ... This paper explores the idea that life comprises a language-like ...
    (talk.origins)
  • Re: Programmers unpaid overtime.
    ... The cache solution's execution time formula is a function of the total ... The campaign is part of what I consider the deprivation of language by ... You can't, in other words, document, and management wonders why ... >> complexity with a few benchmarks. ...
    (comp.programming)
  • Re: Kolmogorov complexity and logical languages
    ... I have looked into the Kolmogorov thingie a bit. ... it is hard to say that one language is more complex than another. ... with linguistics. ... instead of the more abstract notion of complexity. ...
    (sci.lang)
  • Re: Responding to a challenge
    ... > Why do you think such complexity actually exists? ... I would think it noncontroversial that language itself serves the ... were to create an artificial dialect of English in which all verbs ... one an artificial dialect of English with regular pluralization. ...
    (sci.lang)
  • Re: AI project & concepts
    ... > hierarchies where complex concepts are ... > with a concept determines its complexity. ... > thereof like for instance language) you ... For that reason I would ...
    (comp.ai.philosophy)