Re: too much OOP ?

I think we can agree that

update employee e set salary=salary+:diff
where active=true and exists (select * from emp_department ep where
ep.empid=e.empid)

is much more high level than
MOV 1,A

Why? It is based on an assumption that the black box UPDATE is constructed
out of MOVs. But we may not assume that, because it would be not a black
box then. If you can look into UPDATE and see MOV there, then it is not
SQL. It is Assembler then.

Sorry, I don't follow you here.... I guess your definition of
abstraction has something to do with "black boxes". Since I probably
not share that original definition, all derived conclusions doesn't
matter either.

Consider topmind's wrong claim that SQL is
Turing-complete. Let it be.

Many SQL dialects (like PL/SQL) are Turing-complete.

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.

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.
I think the use of "abstraction levels" are overused and many times
high-jacked in different contexts. But I think most people that knows
both 3GL programming and SQL, would agree that SQL is a rather high-
level language.

I know that there are no really objective ways of determinate the
"level of abstraction", but most IT professionals would agree that SQL
is an 4GL and most OO programming languages like Java, C++, etc, are
3GL.

By the way, 4GL was a flop,

SQL is one of the few successful 4GL languages. The main reason 4GL
was a flop, was the vendor dependence, which also is a major drawback
of SQL.

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.

As I said before, the key question is - to which subject should
"abstraction" apply? To the program or to the language of?

I entered this discussion then you claimed SQL to be low-level. So for
me "abstraction" apply to the language.

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? Didn't my previous example show the opposite?

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.

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?

But don't call this high level.

I keep calling SQL high level and assembler low level.

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.

//frebe
.

Relevant Pages

  • Re: too much OOP ?
    ... if you managed to solve the problem in Assembler and if the ... Consider topmind's wrong claim that SQL is ... makes no sense to talk about *immanent* abstraction levels of the ... To the program or to the language of? ...
    (comp.object)
  • Re: too much OOP ?
    ... know almost nothing of the domain, but it seems to me that SQL is ... pretty high level language in its own right. ... view determined by *remoteness* of solutions from concrete problems. ... If we don't share your view that the abstraction level is determined ...
    (comp.object)
  • Re: too much OOP ?
    ... I'm just wondering if OOP is a bit overkill for a database app. ... these systems are designed at an extremely low abstraction level. ... know almost nothing of the domain, but it seems to me that SQL is ... pretty high level language in its own right. ...
    (comp.object)
  • Re: Generating SQL
    ... >> builds strings in another language for some other compiler to parse? ... > Abstraction is horrible? ... > SQL translator. ...
    (comp.object)
  • 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)