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: frebe on 2 Jan 2008 12:49 > > 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. I agree that record is a low-level construct, such as an struct in C or class in C++. That is why the relational model doesn't has records, like pre-relational databases. > 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. So a relation named customer is a high-level construct? > 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. Sorry, you lost me again... I think both Java and SQL are able to directly describe customer as a term. > >> 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... So if any primitive in the language has complexity 1, how can different languages ever have different complexity? > 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. I agree with you to some extent. You need to consider physical indexes when writing SQL queries operating on large amounts on data. But having a query optimizer calculating the best execution plan is much better than hard-code the execution plan in your application code. Having to think of only some things in the implementation of the constructs, is much better than actually having to implement the constructs by yourself. > 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. I can imagine the same discussion in the 60's, when 3GL was introduced. > For 5GL it became just > catastrophic. We cannot go this way. I think that when we get some sound theory backing up more 4GL or even 5GL, we will go this way. Currently one of the few sound theories to backing up 4GL is relational algebra. I have to ask you another question. In your first post, you claimed SQL being low level. Now you seem to agree that SQL is high level language. Instead you argue that too high level languages shouldn't be used. Is this observation correct? Do you think that all developers using SQL database are making a mistake? Would it be better if they implemented the data management logic in their applications instead? Or should they use some other kind of database? > > I might add that SQL also have constructs for adding new bigger black > > boxes. One is called views. > > The OP meant UPDATE, not views. Ever heard about updatable views? > Views is a step in right direction, away from climbing up the ladder to > hell. Some things we could agree on anyway. //frebe
From: Dmitry A. Kazakov on 3 Jan 2008 05:24 On Wed, 2 Jan 2008 09:49:38 -0800 (PST), frebe wrote: >> 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. > > So a relation named customer is a high-level construct? Yes, if that fully implemented all relevant aspects of customer. In philosophy relations do. In programming it could be very tricky to describe abstractions in terms of their relations. >> 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. > > Sorry, you lost me again... I think both Java and SQL are able to > directly describe customer as a term. Term was meant as "terminal symbol." >>> 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... > > So if any primitive in the language has complexity 1, how can > different languages ever have different complexity? They don't have in this sense. That's why people wanted to nGL in order to do things complex in nGL,simple in n+1GL. But we still talking about different complexities. > Having to think of only some things in the implementation of the > constructs, is much better than actually having to implement the > constructs by yourself. There are two issues: 1. When reused, then from the complexity point of view it makes no difference whether you have to analyse built-in constructs or ones designed. 2. When designed new, programming is like an exploding universe. There is no chance keep pace with by mounting 5326GL on 5325GL. >> 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. > > I can imagine the same discussion in the 60's, when 3GL was > introduced. It is not same. That time there were no abstract data types. The dominating ideas were extensible and specialized programming languages. Extensible languages died first. Specialized lingered a while. >> For 5GL it became just >> catastrophic. We cannot go this way. > > I think that when we get some sound theory backing up more 4GL or even > 5GL, we will go this way. OK, foundations is an important issue, though I see it differently. Note that some 4GL languages survived not only because they reduced complexity. Another important thing was correctness. A specialized language is much weaker and limiting than a universal one, so some of them, quite unintentionally I guess, appeared relatively easy to analyse for some aspects of correctness. So we have a lot of modeling 4GL languages used for code generation. Differently to you I believe that sound foundations will sweep them out by making reasonable correctness analysis possible at the 3GL level. > Currently one of the few sound theories to > backing up 4GL is relational algebra. Huh, it was very unfortunate to all of us that RA was first used in 4GL. If "relational people" did it in a 3GL with an elaborated types system then it would have became just a decent part of mainstream OO. There is nothing in RA that limits it to databases only. Databases will die sooner or later, RA will not. > I have to ask you another question. In your first post, you claimed > SQL being low level. Now you seem to agree that SQL is high level > language. I didn't say that. I only said that when C and SQL were compiled into, say, x86 machine code, then likely SQL-code would look more complex. But, if we took a LISP-machine as the target, then it could turn otherwise. Again, it makes no sense to talk about absolute level height. > Instead you argue that too high level languages shouldn't be > used. Is this observation correct? Yes, if they do not fit exactly. > Do you think that all developers > using SQL database are making a mistake? Would it be better if they > implemented the data management logic in their applications instead? > Or should they use some other kind of database? They should not consider the target platform, unless absolutely necessary. Already the mindset "we use SQL database" is as wrong as "we use AMD processor." Database is a part of hardware platform. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de
From: frebe on 3 Jan 2008 06:09 > > Currently one of the few sound theories to > > backing up 4GL is relational algebra. > > Huh, it was very unfortunate to all of us that RA was first used in 4GL. If > "relational people" did it in a 3GL with an elaborated types system then it > would have became just a decent part of mainstream OO. I agree that mainstream SQL databases has a rather poor implementation of RA. An open type system is very important for relational databases. Unfortunately very few databases have it. But what stops "OO people" from using RA in mainstream OO? If the "relational people" didn't do it correct, we "OO people" still can. > There is nothing in RA that limits it to databases only. Did somebody claim this? It is a pity that it is only store procedure languages that has some form of RA built-in. Every decent programming language should have native support for RA. > Databases will die sooner or later, RA will not. I think we all hope for RA implementations (databases) that makes a better implementation than current SQL databases? > > Do you think that all developers > > using SQL database are making a mistake? Would it be better if they > > implemented the data management logic in their applications instead? > > Or should they use some other kind of database? > > They should not consider the target platform, unless absolutely necessary. > Already the mindset "we use SQL database" is as wrong as "we use AMD > processor." Database is a part of hardware platform. Who's mindset are you talking about, mine? Regardless the mindset, do you think it is a mistake to use SQL databases in applications for accounting, invoicing, inventory management, etc? Would it be better to use some other kind of database instead or implement the data management logic in the application instead? (AMD is a vendor, SQL is a name of a family of databases or a standard. It would be more correct to compare AMD to Oracle or DB/2.) //frebe
From: Dmitry A. Kazakov on 3 Jan 2008 10:06 On Thu, 3 Jan 2008 03:09:22 -0800 (PST), frebe wrote: >>> Currently one of the few sound theories to >>> backing up 4GL is relational algebra. >> >> Huh, it was very unfortunate to all of us that RA was first used in 4GL. If >> "relational people" did it in a 3GL with an elaborated types system then it >> would have became just a decent part of mainstream OO. > > I agree that mainstream SQL databases has a rather poor implementation > of RA. An open type system is very important for relational databases. > Unfortunately very few databases have it. But what stops "OO people" > from using RA in mainstream OO? If the "relational people" didn't do > it correct, we "OO people" still can. Yes, but there is no urgent need in that. Within a types system RA of objects is just an algebra, there are other algebras, neither better nor worse. The application domain will tell. Another case is when RA were a part of the algebra of types. That might turn very interesting. Unfortunately types system issues are far beyond the horizon of the practitioners. Also don't forget that there is no market of languages. "Modern" languages are targeted merely as a tool for locking customers in... (:-() > Every decent programming > language should have native support for RA. Depends on the case. 1. RA of objects is a poor candidate to be native. I would leave that up to the programmer. Especially because there could be different implementations of RA meeting mutually contradicting requirements. Think of concurrency, distribution, safety, real-time, run-time constraints etc aspects. 2. RA of types certainly deserves attention. There are difficult problems with parallel types hierarchies and multiple dispatch. Maybe they could be handled relationally. >>> Do you think that all developers >>> using SQL database are making a mistake? Would it be better if they >>> implemented the data management logic in their applications instead? >>> Or should they use some other kind of database? >> >> They should not consider the target platform, unless absolutely necessary. >> Already the mindset "we use SQL database" is as wrong as "we use AMD >> processor." Database is a part of hardware platform. > > Who's mindset are you talking about, mine? Regardless the mindset, do > you think it is a mistake to use SQL databases in applications for > accounting, invoicing, inventory management, etc? That depends on the functional and non-functional requirements of each concrete system. The two basic ideas - of separation of data from semantics (meaning) and of client-server architecture are ugly remnants of deep past. > Would it be better > to use some other kind of database instead or implement the data > management logic in the application instead? If you can factor out these accounting etc as an abstraction, then do it. I just don't see why it should be "database." Call it "accounting subsystem." There is no "data management logic," there is only logic of "accounting." This logic is implemented by the program. Who runs the program is of no interest. Nobody would ever propose a 4GL language for control (Simulink), or for 3D simulation (OpenGL), or for 2D rendering (Postscript) as a paradigm. It is only database- and maybe UML-people who have such strange idea. Others quietly create their *libraries*. They might call them "engine", "middleware", "framework", but show nothing alike that manic disorder the former suffer... (:-)) > (AMD is a vendor, SQL is a name of a family of databases or a > standard. It would be more correct to compare AMD to Oracle or DB/2.) I meant AMD as a processor family. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de
From: frebe on 4 Jan 2008 00:17
> > Who's mindset are you talking about, mine? Regardless the mindset, do > > you think it is a mistake to use SQL databases in applications for > > accounting, invoicing, inventory management, etc? > > That depends on the functional and non-functional requirements of each > concrete system. The two basic ideas - of separation of data from semantics > (meaning) and of client-server architecture are ugly remnants of deep past. So building an application for inventory management without an relational database is actually an option for you? I don't think I will go deeper in the discussion regarding the benefits of relational databases. Anyone with solid experience from developing business applications, appreciates the features in relational databases and realizes that no other kind of current database or library can do the same job. (I don't now what client-server architecture has to do with our discussion. There are plenty of embedded SQL databases availible.) > > Would it be better > > to use some other kind of database instead or implement the data > > management logic in the application instead? > > If you can factor out these accounting etc as an abstraction, then do it. I > just don't see why it should be "database." Call it "accounting subsystem." > There is no "data management logic," there is only logic of "accounting." > This logic is implemented by the program. Who runs the program is of no > interest. Don't you realize that by abstracting "data management" logic, one can create components (database engines) that handles this logic in a generic way. At least you would use some low-level data management components like arrays and maps? Relations are a more high-level way of doing it. It sound like you want to write all logic from scratch? Wouldn't you benefit from pre-made reusable components? > Others > quietly create their *libraries*. They might call them "engine", > "middleware", "framework", but show nothing alike that manic disorder the > former suffer... (:-)) What libraries are you suggesting instead of a SQL database? Please show me some example. > > (AMD is a vendor, SQL is a name of a family of databases or a > > standard. It would be more correct to compare AMD to Oracle or DB/2.) > > I meant AMD as a processor family. I meant Oracle as a database family. //frebe |