Re: too much OOP ?

On Wed, 2 Jan 2008 06:26:11 -0800 (PST), frebe wrote:

On Jan 2, 3:03 pm, "Dmitry A. Kazakov" <mail...@xxxxxxxxxxxxxxxxx>
wrote:
On Wed, 2 Jan 2008 03:19:25 -0800 (PST), frebe wrote:
If we don't share your view that the abstraction level is determined
by the "remoteness", the rest of your post is rather meaningless.
Assembler is pretty "remote" from the problem domain payroll
processing, but that doesn't make it very high level.

It would, if you managed to solve the problem in Assembler and if the
solution covers a wide class of problems. My point is that there is no
difference between "MOV" and "UPDATE," when both are just black boxes.

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. Consider topmind's wrong claim that SQL is
Turing-complete. Let it be. Then we could implement MOV in SQL and program
in Assembler emulated by a database engine. Would it make MOV higher-level
then? 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 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.

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. Though complexity is a bad measure.
But even then, why the platform should play any role? One could argue that
human brain could serve as a universal target platform for comparison. But
that also leads to nowhere. For example sin(x) is conceptually far more
complex for humans than UPDATE, yet sine is an Assembler instruction.

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.

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. But don't call this high
level. Is management troops of dish-washers higher-level than playing
chess? That depends, or?

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

Relevant Pages

  • Re: RPN maps to basic mathematic expressions nicely
    ... fact that Factor is postfix means that it is really only an assembler ... The fact that C-style syntax is the most popular ... reasonable level of abstraction, but are ugly and a hassle to work with ... HTTP client and RSS/XML parsing libraries, since any decent language ...
    (comp.lang.forth)
  • Re: too much OOP ?
    ... If you can look into UPDATE and see MOV there, ... abstraction has something to do with "black boxes". ... Many SQL dialects are Turing-complete. ... specialized language. ...
    (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)