SQL
in [OOP]
|
From: topmind on 1 Feb 2006 21:58 Patrick May wrote: > "topmind" <topmind(a)technologist.com> writes: > > > > > > > On the other hand, there are some delightfully > > > > > > > complex software systems that consist of only a few > > > > > > > hundred lines of code. Functional languages seem > > > > > > > especially good for this. See one of Peter Norvig's books > > > > > > > for a few examples. > > > > > > > > > > > > Most FP demonstrations of such are "toy" or "lab" examples. > > > > > > > > > > Dismissing out of hand systems of which you know nothing. > > > > > That's a bad habit of yours. > > > > > > > > I gave them a chance to strut their stuff. If they can't strut > > > > right, it ain't my fault. > > > > > > Yeah, I can see how systems like Macsyma, RAX (controlling > > > Deep Space 1), Orbitz, the scheduling system for Gulf War 1, > > > countless expert systems, [.....] > > > > The challenge was *not* mere implementation. > > The question from you was whether I knew of any complex systems > that didn't involve large amounts of code relative to less complex > systems. I provided such examples. > > > Even assembler has a lot of implementations. They claimed > > "significantly less code". I gave them a sample application and they > > made up every (lame) excuse under the sun. But that is another > > matter. FP is not the topic. > > I ask this question for the same reason and much the same feeling > as when I take a good look at a serious accident encountered on the > highway, but could you please point me to the location of this > discussion? > > Sincerely, > > Patrick Sure. You will fit right in with the "We don't need no stinkin' public evidence" crowd there. What is yet one more anecdite. http://c2.com/cgi/wiki?ChallengeSixVersusFpDiscussion Background info: http://c2.com/cgi/wiki? HowCanSomethingBeSuperGreatWithoutProducingExternalEvidence (2nd URL split to 2 lines to fit. Paste back together to link.) > > ------------------------------------------------------------------------ > S P Engineering, Inc. | The experts in large scale distributed OO > | systems design and implementation. > pjm(a)spe.com | (C++, Java, Common Lisp, Jini, CORBA, UML)
From: topmind on 1 Feb 2006 22:14 Dmitry A. Kazakov wrote: > On 31 Jan 2006 19:36:38 -0800, topmind wrote: > > > Dmitry A. Kazakov wrote: > > >> There are many clean and consistent things, which lead to a total mess when > >> used inappropriately. DB applications represent an excellent example. > > > > True, but OO has no consistent "right way". > > As well as programming in general. Well, I find a lot more consistency between schemas than between code of different shops. I'll usually take messy schemas over messy code. > > > Relational normalization is > > driven pretty much by avoiding duplication (at least the first 3 > > "laws"). OO tends to duplicate interface patterns such as add, change, > > delete, sort, etc. for each class. It does not factor similar "database > > verbs" into one spot, replicating them per class (with "creative" > > twists for each personality). And many-to-many in OO often results in > > two-way pointers. > > The difference is between one type and multiple types. Relational model > deals with *one* class: table. OO tries to handle more than one class. > Consider tables of types instead of tables of objects, and we'll see if > that will be any simpler. I don't believe in "types" as a useful model, at least not for my domain. If I was forced to be an OO'er, I would probably take Smalltalk or Python over Java or Eiffle. > > >>> Yes, mass repetative verbose static Set/Get's. > >> > >> There are bad languages, which don't fully implement ADT. So? > > > > Converting attribute-driven interfaces into ADT's is still pretty much > > Set/Get. > > They implement attribute access. It is up to the language to provide > X.Attribute notation rather than nasty X.Get_Attribute. I don't see any > problem here. For simple stuff it might be okay, but for more complicated stuff it turns into a Bachmanian navigational mess. For example, specifying many-to-many relationships. > > >> What about inserting when no > >> row exists and updating otherwise? > > > > MySql has a command just for this. > > The advantage of ADT is that you can define that command and provide an > implementation for. SQL does not have proper ADT, otherwise people would do > higher-level programming directly in SQL. The methodology of higher-level > programming is OO. I can write a function to do the same thing. However, function interfaces to such are often not as flexible as query-based interfaces. And, not sharable across languages. Ideally the query language would be extendable if a DBA etc. wanted to add an operation to it. However, SQL's excessively complex syntax makes such very difficult. SQL has some weak spots, I will agree. However, no standard is perfect and the current alternatives are net uglier. > > >>>>>> Similarly, just because different object-oriented programming languages > >>>>>> may have problemsinteroperating with each other's objects, isn't a failing > >>>>>> of object-orientation. > >>>>> > >>>>> Non-OOP protocols are usually easier to share. > >>>> > >>>> True, when they are low-level. > >>> > >>> I disagree. Please justify. > >> > >> Consider machine code as a protocol. Why would you like to have any > >> programming language instead? > > > > I don't know what you are implying. Perhaps an example would help. > > Isn't machine code a simple communication protocol to CPU? You send the > code of MOV and CPU does that. Simple? Can you handle it without a > compiler? Protocol must match the complexity of what you want to tell to > the receiver. Simplicity alone isn't an advantage. I still don't see how this relates to the topic at hand. > > -- > Regards, > Dmitry A. Kazakov -T-
From: Dmitry A. Kazakov on 2 Feb 2006 05:23 On 1 Feb 2006 19:14:42 -0800, topmind wrote: > Dmitry A. Kazakov wrote: >> On 31 Jan 2006 19:36:38 -0800, topmind wrote: >> >>> Relational normalization is >>> driven pretty much by avoiding duplication (at least the first 3 >>> "laws"). OO tends to duplicate interface patterns such as add, change, >>> delete, sort, etc. for each class. It does not factor similar "database >>> verbs" into one spot, replicating them per class (with "creative" >>> twists for each personality). And many-to-many in OO often results in >>> two-way pointers. >> >> The difference is between one type and multiple types. Relational model >> deals with *one* class: table. OO tries to handle more than one class. >> Consider tables of types instead of tables of objects, and we'll see if >> that will be any simpler. > > I don't believe in "types" as a useful model, at least not for my > domain. That's up to you, but there is no any viable alternative. The point is that the relational model is a particular case of more general typed model. Then you aren't sincere. In SQL you are using types like integers, strings and some others. If you didn't believe in them, then you should have replaced them all with relations. Note that mathematically it is quite possible. Now the question, why didn't you? > If I was forced to be an OO'er, I would probably take Smalltalk > or Python over Java or Eiffle. They all are typed, as well as SQL. It is impossible to have a truly untyped language. You might reduce it to a very narrow or singleton set of types, but not further. There could only be well and poorly typed languages. >>>>> Yes, mass repetative verbose static Set/Get's. >>>> >>>> There are bad languages, which don't fully implement ADT. So? >>> >>> Converting attribute-driven interfaces into ADT's is still pretty much >>> Set/Get. >> >> They implement attribute access. It is up to the language to provide >> X.Attribute notation rather than nasty X.Get_Attribute. I don't see any >> problem here. > > For simple stuff it might be okay, but for more complicated stuff it > turns into a Bachmanian navigational mess. For example, specifying > many-to-many relationships. Between what an what? Again, with one table type you have X."Attribute" or (X."A1" and X."A2" and X."A3" ...) instead of X.Attribute or (X.A1 and X.A2 and X,A3 ...) See what is different? It is up to you to map things to types or to objects. There is no best choice. In each concrete case the software designer shall reconsider it anew. >>>> What about inserting when no >>>> row exists and updating otherwise? >>> >>> MySql has a command just for this. >> >> The advantage of ADT is that you can define that command and provide an >> implementation for. SQL does not have proper ADT, otherwise people would do >> higher-level programming directly in SQL. The methodology of higher-level >> programming is OO. > > I can write a function to do the same thing. However, function > interfaces to such are often not as flexible as query-based interfaces. How INSERT is different from user function? Why is it more flexible? > Ideally the query language would be extendable if a DBA etc. wanted to > add an operation to it. However, SQL's excessively complex syntax makes > such very difficult. SQL has some weak spots, I will agree. However, no > standard is perfect and the current alternatives are net uglier. And the only good way to extend languages is by letting user to define ADTs! [ In 60-70s there was a lot of extendable languages in the sense of syntax-extensible. They all are gone, because programs were unreadable and unmaintainable. ] -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de
From: Daniel Parker on 2 Feb 2006 11:20 Dmitry A. Kazakov wrote: > On 31 Jan 2006 19:36:38 -0800, topmind wrote: > > The difference is between one type and multiple types. Relational model > deals with *one* class: table. Note that Chris Date and Hugh Darwin have written about this subject at length, and show that the types of attributes ("columns") may be ADT's with specializations without breaking the relational calculus in any way. > OO tries to handle more than one class. > Consider tables of types instead of tables of objects, and we'll see if > that will be any simpler. Keep in mind the goal of relational theory, and more generally, the theory of monoids, which is to define algrebras that are closed over types, e.g., an operation over a set of values of type T always returns a value of type T. In your table of typed objects, how would you define an algebra? Over what would it be closed? These aren't questions that OO normally addresses, OO is usually used in an ad hoc way, but you have to address them if you want to say that the OO way is more general. Regards, Daniel
From: Oliver Wong on 2 Feb 2006 14:51
"Alfredo Novoa" <alfredo_novoa(a)hotmail.com> wrote in message news:1138628868.179388.319630(a)g43g2000cwa.googlegroups.com... > >I highly doubt this claim, especially since "any program" is extremely >>general. What about the Linux kernel? Or Doom 3? What about the programs >>that powers my mp3 player, cellphone or digital camera? > > We could develop all that with a SQL compiler and the apropriate APIs. > > It would be perfectly possible to generate executable files from > procedural SQL code. A programming language is a programming language > :-) Yes, but "a query language plus appropriate APIs" is not the same thing as "a query language". Certainly, you could write a compiler that compiled "SELECT 1" into a call to "doom3.exe", and then call the binaries for the Doom 3 game your "API", but that would not be in the spirit of the original claim. - Oliver |