Re: too much OOP ?

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. Same
applies to all languages. So deriving a new class in an OOPL is also
low-level if the problem is to derive a class.

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, but 5GL was a total fiasco. If you really
believe that a bigger n makes the language better, why do you stick to
outdated 4GL?

Most IT professionals would also agree that 4G languages could be
considered as having an "higher level of abstraction" than 3G
languages.

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

What software developers have understood is that levering up abstraction of
the language is nonsense. 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.

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

Relevant Pages

  • Re: UML Question (Object <-> ObjectFinder?)
    ... (We're talking about pure FSAs here, not object state machines where the alphabet can be attributes.) ... It doesn't even use any stereotypes that aren't defined in UML. ... Today ADFDs have been replaced by abstract action languages using the UML action semantics meta model. ... The real point here is the level of abstraction of the models. ...
    (comp.object)
  • Tcl and Types (long)
    ... Tcl abstracts over pointers and memory layout and the fact that I can't break that abstraction means that I am safe from dangling pointers. ... Where Tcl differs from most other languages is that it only provides a single unbreakable data type: ... All other data types are layered on top of strings, just as data types in other languages are built in terms of ints, chars, doubles, etc. ...
    (comp.lang.tcl)
  • Re: object system...
    ... But the price of abstraction is performance. ... C isn't even as fast as other systems programming languages. ... never have an interface to access not doing something. ...
    (comp.object)
  • Re: CORBA IDL versioning, evolution, backward compatibility
    ... I don't think this is an accurate definition of abstraction. ... Actually, the yacc grammar only describes the syntax, not the ... domain-specific modeling languages is very similar to ... Define static semantics ...
    (comp.object.corba)
  • Re: Whats the name for this?
    ... These views above would be an abstraction(*) over patterns .. ... (I'm not counting "types" in "dynamically typed languages", as Lisp, ... So, 'treeOfChars' has type 'BTree Char', and treeOfStrings has type ... Anyway, I guess the question is whether this qualifies as a subprogram, ...
    (comp.programming)
Loading