polymorphism
in [OOP]
|
From: Davor on 9 Jul 2006 12:56 topmind wrote: > Davor wrote: > > topmind wrote: > > > > > In this twisted analogy, what is my counterpart to VIM and reg-ex? > > > > VIM = (let's say) Microsoft Access > > > > (both very complex systems) > > Perhaps unnecessarily so :-) > > > > > reg-ex = SQL > > > > (both very nice domain specific declarative languages based on solid > > mathematical theory) > > This implies that if you have relational tools, you don't need OO. Is > this what you are implying or agreeing to? No, I was not implying anything - I was just trying to understand what problem you'd like us to work on... It appears that you are implying something along these lines... > How many others would consider relational a "domain specific" tool? I have said domain specific *declarative languages* - not tools... Regex and SQL are not general purpose programing languages... They are domain specific, where domain for regex - simple(?) text data pattern matching sql - data that is a subset of the Cartesian product of finite number of sets and it's manipulation So, if anything you should be happy since I have constructed another clear example where OOP and what can be done using typical OOP langs clearly sucks as compared to what we can do with already built applications and domain specific languages for manipulation of well defined data... So in summary your challenge and my challenge to this community is: DATA -------- your problem - relational data my problem - unstructured text APPLICATIONS ----------------------- your problem - RDBMS with SQL support my problem - text editors with regex support LANGUAGES -------------------- your problem - SQL my problem - regex Also, what Dmitry was pointing out is the limitations of regex, in my example, and how you'd have to go back to building full blown parsers for some of the problem, and implied that you'd throw back at him the issue that in day-to-day work you don't need to build a parser (ie. you wouldn't use VIMs regex capabilities to parse Linux kernel for example - since parsing Linux kernel is not your day-to-day activity)... So, we have two problem areas where they won't beat us with general OOP solution, but I'm also not sure how fair it is to throw these examples at them - unless you let them build from scratch another RDBMS and text editor with SQL and regex compilers, what two of us are taking for granted in our solutions ;-)) Davor
From: Davor on 9 Jul 2006 15:32 OK, here is an integrated OO/relational model http://www.djangoproject.com/documentation/model_api/ so, as you can see OO is not a substitute for relational processing... Davor
From: topmind on 10 Jul 2006 12:34 Davor wrote: > topmind wrote: > > Davor wrote: > > > topmind wrote: > So in summary your challenge and my challenge to this community is: > > DATA > -------- > your problem - relational data > my problem - unstructured text > > APPLICATIONS > ----------------------- > your problem - RDBMS with SQL support > my problem - text editors with regex support > > LANGUAGES > -------------------- > your problem - SQL > my problem - regex > > > Also, what Dmitry was pointing out is the limitations of regex, in my > example, and how you'd have to go back to building full blown parsers > for some of the problem, That may not necessarily be the case. It may be that regex could do some of the work, and regular looping code do the rest. Regex might provide the candidates and imperative then processes those for final determination, or visa-versa. SQL is often like this: it takes you 80% of the way to a solution, but imperative diddling is required for the final 20%, for example. Thus, it may not be an all-or-nothing thing. One may not have to completely abandon reg-ex to make say a language parser. (Although I am not a reg-ex or lang parse whiz at this point, so take it only as a suggestion to look into.) > Davor -T-
From: Davor on 10 Jul 2006 13:31 topmind wrote: > That may not necessarily be the case. It may be that regex could do > some of the work, and regular looping code do the rest. Regex might > provide the candidates and imperative then processes those for final > determination, or visa-versa. SQL is often like this: it takes you 80% > of the way to a solution, but imperative diddling is required for the > final 20%, for example. Thus, it may not be an all-or-nothing thing. Well, that's exactly what I'm talking about too - if you want a comparison, I think it's appropriate to ask only for the comparison if procedural part is compared, so given an example that a good solution requires 20% of requirements to be handled using *procedural* processing 80% of requirements to be handled using *relational* processing how would a solution look like if we require 20% of procedural part to be handled OO style... i.e., preserve exactly same tables and SQL statements in both solutions and compare only the rest... This is what I see as a meaningful challenge. I've never seen OO as a substitute for *relational* processing *since* the underlying type of processing supported by mainstream OO languages is *imperative* processing! And this is exactly what is done in practice as you can see with the example system I linked to in my previous post. Davor
From: topmind on 11 Jul 2006 15:57
Dmitry A. Kazakov wrote: > On 8 Jul 2006 18:06:05 -0700, topmind wrote: > > > Dmitry A. Kazakov wrote: > >> On 8 Jul 2006 12:46:09 -0700, Davor wrote: > >> > >>> topmind wrote: > >>>> Besides my criticisms are about OO, not imperative. I thus don't > >>>> understand your complaint. > >>> > >>> OK, maybe this will help, my feeling is that you are throwing at > >>> comp.object community a challenge that follows following pattern: > >>> > >>> In *my* application area people write text. That text is data that > >>> people constantly manipulate. I think OOP solution to this type of data > >>> manipulation sucks. In particular in my application area, I use text > >>> editor with advanced text processing capabilities, including regex, and > >>> so on, that completely satisfies all my needs. If your OOP is so good, > >>> show me a better way of doing what I do regularly using my VIM editor. > >>> > >>> Here is a concrete example that everyone who has went to a college has > >>> accounted: > >>> > >>> In the following text replace all occurrences of "bla" with "alb": > >>> > >>> aaaa bla aaaa bla aaaa bla aaaa bla aaaa bla aaaa bla aaaa bla aaaa bla > >>> aaaa bla aaaa bla aaaa bla aaaa bla aaaa bla aaaa bla aaaa bla aaaa bla > >>> aaaa bla aaaa bla aaaa bla aaaa bla aaaa bla aaaa bla aaaa bla aaaa bla > >>> > >>> My solution is > >>> > >>>:%s/bla/alb/g > >>> > >>> Let me see your OOP solution to this problem if OOP is so good! > > > > In this twisted analogy, what is my counterpart to VIM and reg-ex? > > > >> And if somebody pointed out that this solution won't work if bla shouldn't > >> be replaced in quoted strings and comments, because standard regular > >> expressions fundamentally cannot match nested things. He would answer that > >> it is academic and out of biz. > > > > Are you accusing me of intentionally misrepresenting what my domain > > requires? Where have I done such? Your analogies make no sense. > > No, it is merely a refutation of your argumentation. You voluntarily vary > the borders of what you call your domain to elude uncomfortable questions > about applicability of the methods you propose. I deny intentionally doing such. If you have a clear-cut example of it happening, I would like to inspect it. > If you want to convince > other people, show how your methods work in their domains! That is not my goal. If OOP works better in systems software, so be it. I am just protecting domains I care about from being oversold or force-fed OO. > > -- > Regards, > Dmitry A. Kazakov -T- |