too much OOP ?
in [OOP]
|
Prev: Should class code access private members or public wrappers for those private members?
Next: Should class code access private members or public wrappers forthose private members?
From: Dmitry A. Kazakov on 2 Jan 2008 09:03 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
From: frebe on 2 Jan 2008 09:26 On Jan 2, 3:03 pm, "Dmitry A. Kazakov" <mail...(a)dmitry-kazakov.de> 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 > > 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. There was also a number of 3G languages sold as 4GL, in the 80's. > 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? 3G is considered by most programmers to be higher level than 2GL. The same applies to 4GL. I don't have any experience from 5GL, so I can't comment on that. > > 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? I entered this discussion then you claimed SQL to be low-level. So for me "abstraction" apply to the language. My claim is that SQL could be considered more high-leven than C++ or Java. > 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? > 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. //frebe
From: Dmitry A. Kazakov on 2 Jan 2008 10:36 On Wed, 2 Jan 2008 06:26:11 -0800 (PST), frebe wrote: > On Jan 2, 3:03 pm, "Dmitry A. Kazakov" <mail...(a)dmitry-kazakov.de> > 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
From: frebe on 2 Jan 2008 11:28 > > 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
From: Dmitry A. Kazakov on 2 Jan 2008 12:13
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 |