Re: too much OOP ?

On Wed, 2 Jan 2008 08:28:02 -0800 (PST), frebe wrote:

Then we could implement MOV in SQL and program
in Assembler emulated by a database engine. Would it make MOV higher-level
then?

The same argument could be applied to assembler vs Java. MOV could be
emulated in Java, and still we consider Java being more higher-level.

Which is what I am arguing against. In general case you cannot tell before
seeing the application domain.

In which sense this MOV is higher than CPU's MOV? See? It is just
makes no sense to talk about *immanent* abstraction levels of the
languages, if you can translate them into each other. This notion of
abstraction is useless.

I have to remind you that you started to talk about abstraction
levels. You claimed SQL being at a extremly low level of abstraction.

No, I said that designing it in terms of records is low level. If the
application about customers etc, and people talk about records, then it is
low level. 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. 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.

It could not be otherwise, it was a drawback of the concept of having a
specialized language.

Anyway, SQL is a rather successful specialized language.

Huh, so C is.

This is not a workable concept. The only way you could formalize it is by
considering some a target language and then measuring algorithmic
complexity of the language constructs.

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...

That was the reason why the 5GL project collapsed. Their primitive
operations could not be implemented uniformly efficient. SQL suffers this
problem too. Writing an application you have constantly to keep in mind the
implementation of the constructs you are using. 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. For 5GL it became just
catastrophic. We cannot go this way.

What software developers have understood is that levering up abstraction of
the language is nonsense.

Ok, why don't you continue with 1GL in that case?

Because they cannot handle abstraction in there. The idea of modern
languages is to provide tools to abstract solutions within the language,
rather than outside it by adding new bigger and bigger black boxes.

I might add that SQL also have constructs for adding new bigger black
boxes. One is called views.

The OP meant UPDATE, not views.

Views is a step in right direction, away from climbing up the ladder to
hell.

It might look attractive in 80's, when systems
were small, short-living and insulated from each other. But it is different
today. So the programming languages design turned to a side direction,
towards supporting abstraction on the system design level, while level "3"
was found high enough to support abstraction but not too high to loose the
control over what's going on when things get complex.

3GL was not considered high enough for data management.

Data management is just yet another misconception. I don't need either data
or their management, I need the work done. If you can describe your
problems in terms of managed data, fine to you.

In my domain, everything is about recording and transforming (manage)
data. For example: Isn't payroll processing and invoicing, just data
transformations?

Isn't it just about lighting right LEDs in right time on the display? (:-))

Is management troops of dish-washers higher-level than playing
chess? That depends, or?

According to your previous argumentation, I don't have any idea. You
could probably provide arguments for both things being the most high-
level.

No, one cannot tell without seeing the language used for.

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

Relevant Pages

  • Re: object system...
    ... for that you need machine language. ... But the price of abstraction is performance. ... involves the function call overhead, the cost of copying the structs around on the stack, much less efficiently crafted ASM output (since the compiler may lack most of the context from the caller), ... ... But because of the 3GL type system compromises the way one must do that is with a different mindset towards design, not OOPL programming. ...
    (comp.object)
  • Re: object system...
    ... for that you need machine language. ... isn't even as fast as other systems programming languages. ... Stroustrup's stated design goal was to enable ... all manner of elegance or abstraction can be sacrificed for speed, ...
    (comp.object)
  • Re: object system...
    ... what the C compiler typically produces... ... C++ is a versatile language, as one can use it in some places mostly like it ... in general, this compiler provided abstraction, will somewhat beat out the ... but I still don't see how this relates to "programming based on ...
    (comp.object)
  • Re: Ann: Sketchy LISP, Third Edition
    ... So now when I want a language with pure abstractions I ... A character should be an abstraction. ... about its binary representation, ... I think we should strive for exactness. ...
    (comp.lang.scheme)
  • Re: object system...
    ... for that you need machine language. ... there are many other cases where "abstraction" can be leveraged to the ... never have an interface to access not doing something. ... based on class systems rather than type systems. ...
    (comp.object)