I disagree

Post #26,929 by tablizer 2/1/02 10:04:19 PM Reply	I disagree >> I think your beef with OO is mostly syntax. << If it was that simple and minor, then why all the pressure to get away from p/r to begin with? >> As long as you see that there is a bunch of functions related to invoice, << I only see one here. Besides, totals may be able to be calculated by only looping thru the detail entity (invoice line items) and may never even have to touch the Invoice entity. Tying operations tightly to entities is generally poor design IMO anyway. The entities that may be involved in a given calculation can vary widely. IOW, different nouns may be used in formulas over time. >> If you do not notice that there is such thing as "total" that can be computed over any "rs", you're not a good procedural programmer either. << Conceptual only. In many cases it might take nothing more than SELECT SUM(Amt) FROM InvcDetail". In fact, one normally does not re-calculate the line-items and totals if they want to sum them: they have already been done at the point of sale. Recalculating them may give a different answer than what the customer saw and actually paid. For example, some of the coupons may have expired before the time of re-calc. Thus, SELECT SUM... may be sufficient for the vast majority of cases. Reality keeps barfing on the clean view of polymorphism. I don't know why, it just does. (It is John's example, not mine.) ________________ oop.ismad.com
Post #27,026 by Arkadiy 2/2/02 9:24:21 PM Reply	May be. >>>>>>>>>>>>> If it was that simple and minor, then why all the pressure to get away from p/r to begin with? <<<<<<<<<<<<< I don't think there is pressure to get away from p/r. A good OO aproach has to be good procedural approach before it becomes any good at all. And anyone who uses databases has to be good with the "r" component. >>>>>>>>>>>> >> As long as you see that there is a bunch of functions related to invoice, << I only see one here. Besides, totals may be able to be calculated by only looping thru the detail entity (invoice line items) and may never even have to touch the Invoice entity. <<<<<<<<<<<< The exact details are not relevant. It is a good procedural practice to break up long functions into many calls to smaller functions. And often you end up with a bunch of functions taking some struct pointer as first parameter. That's where OO begins. If your problem domain is simple eniugh to have "SELECT SUM(Amt) FROM InvcDetail" - more power to you. You don't need OO. You don't even need terribly good procedural programming. You only need both when things get hairy, when you end up with single function that takes 1500 lines of code. That's when you break it up (into subroutines, or into methods) >>>>>>>>>>>>>>> Reality keeps barfing on the clean view of polymorphism. I don't know why, it just does. (It is John's example, not mine.) <<<<<<<<<<<<<<< Did I mention polymorphism anywhere yet? Polymorphism comes after incapsulation. We are trying to establish the merits of encapsulation here. When and if I'll convince you that incapsulation is simply a tiny syntactical extension of good procedural programming approach, we'll move on to debate polymorphism.
Post #27,037 by tablizer 2/2/02 11:14:00 PM Reply	the calculation complexity may not even matter here >> I don't think there is pressure to get away from p/r. A good OO aproach has to be good procedural approach before it becomes any good at all. << I am not sure what you mean. >> If your problem domain is simple eniugh to have "SELECT SUM(Amt) FROM InvcDetail" - more power to you. << I did not assume the whole thing was simple. I am suggesting that even if the orginal price calculations require a trillion lines of code, the summary process may still be a relatively simple operation. Well-designed systems are often like that. I have worked on systems with relatively complex discounting rules, yet the end result was still a simple number (price) in a table. >> You only need both when things get hairy, when you end up with single function that takes 1500 lines of code. That's when you break it up (into subroutines, or into methods) << For the sake of argument, and to get things moving along, assume that we do break things into routines to your satisfaction. ________________ oop.ismad.com
Post #27,043 by Arkadiy 2/2/02 11:49:41 PM 2/2/02 11:52:14 PM Reply	It does not matter indeed. I am trying to get at ease of understanding and modification. But we are a long way off yet. >>>>>>>>>>>>>>>>>> >> I don't think there is pressure to get away from p/r. A good OO aproach has to be good procedural approach before it becomes any good at all. << I am not sure what you mean. <<<<<<<<<<<<<<< I meant that you have to be a good procedural programmer before you become a good OO programmer. OO does not replace good p/r programming, it is built on it. >>>>>>>>>>>>>>>>> For the sake of argument, and to get things moving along, assume that we do break things into routines to your satisfaction. <<<<<<<<<<<<<<<<< "To my satisfaction" in this context would mean that we end up having some data structures that are passed as poiners or handles (or using names and table lookup) to functions that modify/use those data structures. Do you agree that it's a common occurance in well-structured procedural programs? Edited by Arkadiy Feb. 2, 2002, 11:52:14 PM EST Expand All History
Post #27,079 by tablizer 2/3/02 1:05:55 PM Reply	Regional Scope to the Rescue >> "To my satisfaction" in this context would mean that we end up having some data structures that are passed as pointers or handles (or using names and table lookup) to functions that modify/use those data structures. Do you agree that it's a common occurance in well-structured procedural programs? << Relatively common, but not pivotable. At times I make them "regional" (module) scoped variables so that I don't have to keep passing them around as params. Keeps the code cleaner and simpler that way IMO. It is a form of "repetition factoring". If there is only one "main query" in a module, then passing it around intra-module generally does not buy you anything. In languages like PHP that don't have regional scope, this is not possible. >> I am trying to get at ease of understanding and modification. But we are a long way off yet. << "Ease of modification" should be fairly easy to demonstrate: simply offer a set of (allegedly) typical change-scenarios that you think your version fairs better at and apply them using numerical change-point counts or whatever metric you like. However, "ease of understanding" is relative and subjective. ________________ oop.ismad.com
Post #27,175 by Arkadiy 2/4/02 10:40:53 AM Reply	Regional Scope - ok. I don't know what the word "pivotable" meansd to you. For me, if it happens often, it's worth consideration. Your "regional scope" is rather good idea. So good in fact that OO provides 2 levels of it. You can have class-scoped variables, or instance-scoped variables. All that to save parameter passing. Here is how you can look at encapsulation through "scope" lenses. Suppose you have a module that parses a string for you (substitute some sort of DB access and use if you prefer): ====================================== ParseString.h void setStringToParse(const char str); void setParseMode(/some crap describing parsing /) const char getFirstToken(); const char getNextToken(); ====================================== ParseString.cpp static const char parsedString; /* that's you regional scope, isn't it? / static const char currParsingPoint; /* and so on / / implement the functions from .h here */ ======================================= Now, before we go any further, is that a good example of "regional scoping"?
Post #27,221 by tablizer 2/4/02 1:31:55 PM Reply	I think so but my C++ is extremely rusty. May I suggest Java or Python examples instead. Java probably has the widest audience here. I agree that classes can have a very module feel. The differences are usually when it comes to "instances" (AKA "state"). ________________ oop.ismad.com
Post #27,256 by Arkadiy 2/4/02 4:38:07 PM Reply	It was really C, not C++ I'd have hard time expressing it in Java w/o using classes. And I don't know Python enough to write (barely enough to read). But, now that we established how regional scoping looks in a non-oo language, I'll proceed to use Java examples for the rest of encapsulation discussion. You say: "I agree that classes can have a very module feel. The differences are usually when it comes to "instances" (AKA "state")." Well, don't you have a need sometimes to "clone" a module? For example, suppose you need to keep track of parsing more than one string at a time. What you do in a procedural language is take your static, module-scoped variables and make a structure out of them. Something like struct StringParseContext { const char parseString; const char currParsePoint; }; (that was my last C example, I promise) And then you initialize and use the structure. And that "clones" your regionally-scoped vars. They became instance-scoped vars. (BTW, unless I am wrong, Ada, which is not really an OO language, has an explicit concept of cloning modules, much as I explain above but with extra syntax support) So, the very basic level of OO is to come up with ideal "module" for doing something to a piece of data. And then to be able to clone it as needed to work with more than one piece of data at a time.
Post #27,279 by tablizer 2/4/02 6:37:26 PM Reply	Welcome to Table Land >> It was really C, not C++ << My C is rusty too :-) I havn't written a C program that needed header files since about 1993. >> Well, don't you have a need sometimes to "clone" a module? For example, suppose you need to keep track of parsing more than one string at a time.... << This usually is where I enter Table Land. Granted, the "standard" RDBMS approach is a bit bulky for this kind of thing. However, XBase has taught me that tables can dance like a butterfly and sting like....... If the number of "clones" can be open-ended, such as based on user input, then given a preference I turn to tables. The standard reply from OO fans is something like, "But wouldn't you like to group the parsing operations with the structure that they operation on?". I then reply something like: If the structure is determined in code, then place the structure next to the code. However, as the application scales, often multiple modules or tasks need access to the same data structure. Building a one-interface-fits-all to such a structure can turn into a can of worms. Further, tables are already an interface as far as I am concerned. If you want some kind of "global protection", then use triggers or referential integrity or something. ________________ oop.ismad.com
Post #27,295 by Arkadiy 2/4/02 7:49:55 PM Reply	So, each clone's data is a row? Fine with me. But you still need to act on row number, or primary key, or something. Please understand, I don't care how you store your data, as long as you agree that you need instances (clones) of data stored somehow. For example, when you use dBase (forgive me if my syntax is crap, I've been out of dBase longer than you've been out of C): SELECT InvoiceLines SCAN FOR InvoiceNo = Invoice.invoiceId Invoice.shippingCost = Invoice.shippingCost + computeShippingCost() ENDSCAN you may not think about it, but computeShippingCost() can be thought of as a method on InvoiceLine instance. The fact that the object has no name and its pointer is passed implicitly by setting workspace row pointer to the proper row is not that important. It's all about how you think about stuff, not about syntax. You have to say to yourself: "How do I find the shipping cost for _one_line_of_invoice_?" Once you used a noun, you have an object, whether your syntax looks that way or not.
Post #27,305 by tablizer 2/4/02 9:13:21 PM Reply	Multiple Entity Association Candidates >> as long as you agree that you need instances (clones) of data stored somehow. << This has been going on since at least punched cards. This seems like a trivial statement, unless you meant something I missed. >> you may not think about it, but computeShippingCost() can be thought of as a method on InvoiceLine instance. << I suppose. But, what does that get me? And...... >> You have to say to yourself: "How do I find the shipping cost for _one_line_of_invoice_?" Once you used a noun, you have an object, whether your syntax looks that way or not. << Well, that is one way to look at it, but again, I don't see what it buys me. The calculation of shipping costs could involve multiple entities (nouns), you should notice. For example, it might be stored at the Invoice level, not at the line-item level (but that is not the only choice). It may also reference a weight table for the various shipping services. It is like a human neuron: multiple input sources with one output (value). Thus, there are 3 candidate entities to associate it with. Association with entities is more or less continuous and multiple and dynamic in my observation. Further, it may change. For example, we may originally store shipping costs at the Invoice level (one slot per invoice). However, we may later decide to make it another line item (invoice detail), along with other options such as Tax, Fee(s), Discount, etc. Using the You-Must-Associate-Every-Action-With-One-And-Only-One-Entity view of OOP, we have two problems: 1. There are multiple candidate entities (nouns) to associated it with. 2. We may change which entity/noun it should be associated with. This change would be less disruptive under typical p/r because we don't have to move any code. OOP would have to move it from one class (entity) to another. (Your XBase is marginally better than my C :-) ________________ oop.ismad.com
Post #27,361 by Arkadiy 2/5/02 10:15:25 AM Reply	Re: Multiple Entity Association Candidates >>>>>>>>>>>>>>>>>>>>> >> as long as you agree that you need instances (clones) of data stored somehow. << This has been going on since at least punched cards. This seems like a trivial statement, unless you meant something I missed. <<<<<<<<<<<<<<<<<<<<< I am talking about cloning API's static data. And yes, this is an ancient idea. But not quite trivial. Now, as far as multiple candidates for association... I don't know about you, but for me at any given moment there is only one proper association. Any other seems arbitrary or wrong (at the moment). If you can think of shipping cost computation for a line as something that belongs to whole invoice - fine. But then, at least in my mind, this method can not belong to a single line. Distribution of methods among classes is one of the finest point of OO. What does it buy you? Your code structure reflects the way you think of your problem domain. If you say: let's compute shipping cost for invoice, then your code will say so, explicitly. If you say: invoice's shipping cost is computed by summing up shipping costs of lines, your code can say that. Explicitly. By having both Invoice.computeShippingCost() and InvoiceLine.computeShippingCost(). If the invoice's shipping cost is the function of shipping method, which is the same for all lines, and total cost of invoice - you can say so, again. In your code, not in comments. Encapsulation allows for more direct translation of problem domain statements into code. You say that moving code around is a hassle. But it's a small price to pay for keeping your code in sync with business model. If, all of a sudden, you learn that each invoice line can have its own shipping method, moving the shipping cost computation to InvoiceLine class is a small price to pay for writing down your new understanding of problem domain.
Post #27,386 by tablizer 2/5/02 11:55:43 AM Reply	Genericness >> but for me at any given moment there is only one proper association. << To me, this appears to be a doctrine-induced habit on the part of OO followers. Or perhaps some peoples' minds are simply more comfortable with "master associations" taking precedence. Relation to a "single master entity" is a rather weak and relatively useless concept in my mind. It is too restricting and change-unfriendly IMO. Besides, one can physically group all invoice-related code together, if there is such a thing. What if the function is designed such that the scope is open ended? Example: criteria = "InvcID=32 and DestinationID in (85, 87, 92)" sc = shippingCosts(criteria) The ShippingCost function belongs to nobody! It is more or less "generic" WRT the scope it operates on. True, it probably uses invoice detail records, but the scope is not necessarily per detail record. It could cover a single detail line in some circumstances, a group of line items going to the same destination (similar to above example), the entire invoice, or a complex combination or subset. It is achieving generic-ness that OOP often brags about, but cannot seem deliver when it over-couples operations to single, narrow entity instance. >> Your code structure reflects the way you think of your problem domain. << Do you mean: 1. The way one should think about the problem domain? 2. The way you think about the problem domain? 3. The way most people actually think about the problem domain? 4. ? >> If you say: let's compute shipping cost for invoice, then your code will say so, explicitly. << Yes, as a query or scope criteria. That is explicit. >> Explicitly. By having both Invoice.computeShippingCost() and InvoiceLine.computeShippingCost(). << Why? >> Encapsulation allows for more direct translation of problem domain statements into code. << I am sorry, but I am not seeing it. Requests often come in the form of, "if this and that, then do such and such". >> If, all of a sudden, you learn that each invoice line can have its own shipping method, moving the shipping cost computation to InvoiceLine class is a small price to pay for writing down your new understanding of problem domain. << At least you are admitting to some "shuffling costs" of moving (and possible duplication of code). That is a start. My approach seems more change-friendly. As far as being "self documenting", I prefer Coddlets over physical positioning to indicate what is going on. Coddlets are more multi-aspect-able. I don't want to be locked into picking one dimension at the expense of or dethroning of other perfectly valid dimensions. It is classic OO IS-A mentality taken too far again IMO. The IS-A-ness of OO keeps bothering me in various incarnations. (A list of annoying IS-A-isms is at my website.) It is a theme that OO fans keep locking onto or are attracted to for some reason. They find some grokability comfort in it somehow, while I find it constricting and rather arbitrary. It is like a bad single parent is better for OO fans than multiple parents of varying and dynamic importance. Both the like of it and the distaste of it seem to be an inborn head-wiring thing. If you are going to completely rewire my head, it may just take a good while. ________________ oop.ismad.com
Post #27,413 by Arkadiy 2/5/02 2:13:09 PM Reply	Expressing problem domain I don't think associating functions with data is a habit induced by OO. I had it long before I came across OO. All well-structured APIs are built around that habit. As to your example implementation, I find it highly ugly. What the hell does it do? Compute total of shipping cost of lines in invoice 32 that go to Zip codes 85, 87 and 82? I had to think a lot before I formed that guess. I want _my_own_ code to reflect, as straightforwardly as possible, _my_own_ current understanding of problem domain. I _do_not_ want my code to reflect my understanding, knowlege and mastery of programming language. Your latest object-independent code is good enough for an ad-hoc query, where all you care about is to get results quickly. If you need something more long term, you'll need to do something like: invoice = GetInvoice(32); properDestinations = SelectInvoiceSubset(invoice, "DestinationID in (85, 87, 92)"); sc = CalculateShippingCost(properDestinations); I'll leave it as an exersice to the reader to demonstrate how those lines are closer to OO. I am not using physical positions for self-documenting. I am using function names and variable names. Your coddlets may actually have another name: functions. Yes, it may take a long time. But I hope to demonstrate that style that does not keep track of the relationship between functions and data they operate on is not good in the long run. The reason is - it tends to express your mastery of coding rather than your understanding of problem domain. And it's the second, not the first that matters in the long run.
Post #27,445 by tablizer 2/5/02 8:03:45 PM Reply	Misunderstanding I should have made it clear that those were only sample destination numbers. I did not mean that such were hard-wired into production code. Let's say that the numbers are gathered from another operation that dynamically groups shipping costs based on available carriers if the customer approves of mixed shippers. If not, then one shipper is used. >> I had [been doing] it long before I came across OO. << Perhaps you were born with an OO mind. OO fans often say that OO simply formalized the way they always saw programming when it came along. >> But I hope to demonstrate that style that does not keep track of the relationship between functions and data they operate on is not good in the long run. << And I hope to demonstration that artificial, exaggerated, and/or forced coupling (associations) is not good in the long run. ________________ oop.ismad.com
Post #27,500 by Arkadiy 2/6/02 10:47:48 AM Reply	Actual numbers don't matter much. It could have been a value of variable - my objection still stands. My code reflects my understanding of problem domain. Your code does not reflect your understanding of problem domain, or at least I can't deduce your understanding from it. Nothing "artificial, exaggerated, and/or forced" is good in any run - long or short. My contention is that in addition to all artificial and forced couplings one can come up with there _always_ is at least one that is natural and proper. It is always worth the effort to find that coupling, because, when found, it has deep roots in problem domain, allowing your code ... (you heard that already). Why do I think there always is a natural coupling? Because of the structure of our language (and, therefore, our thought process). Whenever we use a verb, there is a noun somewhere, the actor, the doer, explicit or implied. That is the natural and proper connection I struggle to make obvious in my code.
Post #27,558 by tablizer 2/6/02 6:43:02 PM Reply	Spoken Language? >> Your code does not reflect your understanding of problem domain, or at least I can't deduce your understanding from it. << Are you suggesting that it is random? Perhaps we are optimizing for different things. One of my ultimate goals is to make the system change-friendly. Mirroring the current problem statement as strong as possible is not at the top of my priority list, for it will drift away from that. Using a Coddlet I can relatively easily change what the "input tenticles" tap into. IOW, I see no benefit and some drawbacks (moving around methods that even you agreed a bit with) to putting a strong bond between the operation and an entity. >> Why do I think there always is a natural coupling? Because of the structure of our language (and, therefore, our thought process). << It is a bit premature to assume that language reflects the way our individual heads actually work. English is not optimized for my head, as you can tell by reading this. You are also implying that Swaheelly speakers think different than English speakers. That may indeed be the case, but this just underlines the relativism nature of my claims. >> Whenever we use a verb, there is a noun somewhere, the actor, the doer, explicit or implied. << Again, my main goal is to maximize change-friendliness, and not necessarily mirror English sentences. I suppose you could claim that something is easier to change if it is easier to grok (by matching verbal languages), but I would probably reply, "then learn to think in Coddlets" and grow beyond human language. (Mirroring the "take your medicine" suggestions of some of youses.) In some ways I think my approach models business behavior: a bunch of people or resources temporarily come together to work on some designated task or goal. When the task is done, the team splits up to work on other things in other combinations using other roles. Note that sentences can have multiple nouns: "Bob, Rita, Miki, Arther-Anderson consultants, and Todd all got together to plan the new Spring advertizing compaign." (Hmmmmm, this kinda reflects what NKING said.) Yet, there is only one verb. ________________ oop.ismad.com
Post #27,599 by Arkadiy 2/6/02 10:46:35 PM Reply	Re: Spoken Language? >>>Are you suggesting that it is random? No, randomized :). You intentionally changed rather good piece of code you had before to demonstrate different approach. And that took you to shorter code, but less obvious meaning. >>>>>>>>>>>>>>>> Mirroring the current problem statement as strong as possible is not at the top of my priority list, for it will drift away from that. <<<<<<<<<<<<<<<< The thing is, we have nothing else to "mirror". If the code does not reflect our current understanding of what it's supposed to do, then what does it reflect? And if the code is a self-sufficient object not reflecting anything, how is another person to understand what it's doing? >>>>>>>>>>>>> It is a bit premature to assume that language reflects the way our individual heads actually work. English is not optimized for my head, as you can tell by reading this. You are also implying that Swaheelly speakers think different than English speakers. That may indeed be the case, but this just underlines the relativism nature of my claims. <<<<<<<<<<<<< I have to agree, it was my basic assumption. _I_ can only think in words, therefore I can't think outside forms provided by natural language. I assumed it's a general human property. Are you saying I was wrong? As to Swaheely (sp?), I suspect it's structure is similar to English. I am yet to hear about a language that has no nouns or no verbs. I do indeed claim that before you change you need to understand. How do you know what part to change whe you are tols that each line in invoice is now allowed its own shipping method? You need to realize how the shipping cost calculation was set up before. I am still not sure what "codlets" are. I have a strong suspicion that they are rather closely related to functions. Care to show an example of coddlet? >>>>>>>>>>>>> Note that sentences can have multiple nouns: "Bob, Rita, Miki, Arther-Anderson consultants, and Todd all got together to plan the new Spring advertizing compaign." (Hmmmmm, this kinda reflects what NKING said.) Yet, there is only one verb. <<<<<<<<<<<< Yes. And that's called aggregation. Those guys and gals formed something known as Working Group. And, by the way, if you continue the story, you'll find out that Rita presided over meeting, new advertizing ideas were generated by Miki, consultants formed a unified front to shoot those ideas down, and Todd was simple there for head count and drunk lots of coffee. See where I am going? The code would be rather like: WorkingGroup group = new WorkingGroup(); group.setPresident(rita); group.addConsultanta(consultantA); group.addConsultanta(consultantB); group.setBallast(todd); void WorkingGroup::conductMeeting() { while (president.getNewIdea(miki)) { if (consultants.ideaIsAcceptable(president.getCurrentIdea())) president.recordActionItems(); else president.dropCurrentIdea(); ballast.anotherCuppaCoffee(); } }
Post #27,608 by tablizer 2/7/02 12:51:58 AM Reply	Hmmmm. Verbal thinkers versus visual thinkers >> And that took you to shorter code, but less obvious meaning. << If one gets used to such, then it is obvious. >> If the code does not reflect our current understanding of what it's supposed to do, then what does it reflect? << It does reflect it, just not the way you prefer. >> I have to agree, it was my basic assumption. _I_ can only think in words, therefore I can't think outside forms provided by natural language. I assumed it's a general human property. Are you saying I was wrong? << I tend to think visually. Images and actions appear in my mind first, and then I translate them into words (if required). I come from a lineage of artists. I wonder if other artists are also table fans? I have heard others state that OO fans tend to be "verbal thinkers". I don't remember where I heard this. >> I am still not sure what "codlets" are. I have a strong suspicion that they are rather closely related to functions. Care to show an example of coddlet? << In general they are expressions that tell how to structure and relate something. The idea is to have a formula for the relationships and patterns rather than physically structure things in the desired way. I find it easier to change a formula than to change a physical structure of the building blocks. It is also easier for multiple things to participate in different views this way IMO. It is all about creating "virtual views" of structures and relationships. "Coddlets" usually take the form of Boolean and set-based expressions. SQL is probably the most popular example. >> if (consultants.ideaIsAcceptable(president.getCurrentIdea())) president.recordActionItems(); << Hmmmm. The president only listens to the consultants. BTW, I forgot to add the copy machine, photo-lab, and corporate library to the mix. ________________ oop.ismad.com
Post #27,646 by Arkadiy 2/7/02 10:34:38 AM Reply	Seems like end of conversation, then. OO is for those who think in words. TOP (I still don't quite get it, but so be it - I guess I think differently) is for those that think in images. Next time, before you start talking to somebody about OO, ask which way he/she thinks. If in pictures - you'll find a thankful listener. If in words - you'll find an intersting but purposeless fight. If you were asking my opinion (which you aren't) I'd say that words are better suited for computers. But it's just me. To all: next time you are tempted to argue with Bryce - remember this thread. At least for me, the temptation comes from very basic difference in thinking process. Such differences cannot be settled by an argument.
Post #27,662 by CRConrad 2/7/02 12:47:29 PM Reply	See also Stephenson, In The Beginning Was The Command Line..
Post #27,880 by tablizer 2/8/02 11:10:58 PM Reply	Actually, I like command lines ....if they are well-designed. It is generally easier to type in a substring ("contains") and get a short list of numbered matches than to browse thru a huge picklist of titles. My fingers are faster than my eyes, it seems. However, I have never seen such implemented like I envision it. Some systems "fill in" from the right side, but that is not good enough. It must be a "contains" to work effectively (for me). ________________ oop.ismad.com
Post #27,726 by static 2/7/02 8:07:43 PM Reply	Noted. He often seems to come so close and then something twists and he won't go any further. I recall much the same sort of discussion way back on IWE about lexical analysis. Wade. "All around me are nothing but fakes Come with me on the biggest fake of all!"
Post #27,735 by tablizer 2/7/02 9:40:32 PM 2/7/02 9:46:35 PM Reply	Can our differences really be all that simple? >> If you were asking my opinion (which you aren't) I'd say that words are better suited for computers. But it's just me. << But they seem to do tables pretty well. ________________ oop.ismad.com Edited by tablizer Feb. 7, 2002, 09:46:35 PM EST Expand All History
Post #27,782 by Arkadiy 2/8/02 9:37:57 AM Reply	Simple? You call fundamental difference in how people think "simple"? I disagree. My beef is not with tables. OO can meake good use of SQL, lookup tables, even tables containing code, although that's stretching it. My problem is that you don't see the relationship between action and actor. Apparently, for you, actions just happen, without any acting entity, or at least without a single main acting entity. That goes contrary to the way my brain works.
Post #27,827 by tablizer 2/8/02 1:00:37 PM Reply	Compared to others, yes. >> You call fundamental difference in how people think "simple"? I disagree. << It is a much "cleaner" explanation than most others floated, especially those floated at the end of heated debates :-) >> My problem is that you don't see the relationship between action and actor. Apparently, for you, actions just happen, without any acting entity, or at least without a single main acting entity. << I see the relationship as open-ended and dynamic and multiple. I see the relationship to actors like local variables: created, used, then tossed away. IOW, the relationships are "encapsulated" within a given operation more or less. If you make it global, then you have more dependencies to change if the relationships change IMO. ________________ oop.ismad.com
Post #27,783 by Another Scott 2/8/02 9:38:14 AM Reply	On visual thinking. If you haven't read it, you might enjoy [link\|http://www.amazon.com/exec/obidos/ASIN/0679772898/qid=1013179102/sr=8-1/ref=sr_8_3_1/103-9334142-8588622\|Thinking in Pictures] by Temple Grandin. She's an autistic woman who is a professor and [link\|http://www.grandin.com/\|designer of cattle handling facilities]. She thinks visually. It's a very interesting book. Cheers, Scott.
Post #27,861 by tablizer 2/8/02 8:06:47 PM Reply	mooooo >> If you haven't read it, you might enjoy Thinking in Pictures by Temple Grandin << A visual thinker with less-than-perfect social skills and who likes to hang around cows? I donno. My wife thinks I need more exposure to normal people. Movies and books that glorify wacked-out geniuses put too many "risky thoughts" into my head, her theory goes. Thanks for the tip, however. ________________ oop.ismad.com
Post #28,780 by Ashton 2/17/02 10:44:11 PM Reply	I've heard her speak.. And on the level of this discussion - I second Scott's recommendation. And don't at all get why you'd dismiss with such disinterest -?- a title almost the same as your self-description! Or is that a feigned obtuseness - to keep your rep intact? ;-) I don't do code, but still found some of the above examples intelligible enough to imagine I see something of.. (??) different kinds of gears whirling in the old neural networks. The comments re the 'view' of an end-user VS the methodology - I deemed a nice vindication of the idea that, even in complex symbolic logic - good (English or other) language usage can produce near-enough comprehension.. I only got this far because - for once - it seemed there was a mutual desire to actually get to the Sticking point(s). And that's as good as the NY Times Crossword :=\ufffd Think you ought to check out Temple Grandin -- there can't be Too many out there, constructed 'zackly like You, y'know? [/book review] Ashton Who congrats Arkadiy and Bryce for 'keeping it in the pants' and producing an intelligible sequence.. if not quite the definitive Omega (!?) of it all.
Post #27,622 by CRConrad 2/7/02 5:58:53 AM Reply	Sp: "Swahili". Kwaheri, Jambo! (Which means "Hello, Friend!", IIRC. :-) Oh, and if you see Bryce talking about "speghetti" or "relevent", he probably means "spaghetti" and "relevant"... HTH! Christian R. Conrad The Man Who Knows Fucking Everything
Post #27,736 by tablizer 2/7/02 9:43:56 PM Reply	I've had enuf of your irrelevent, speghetti insolts :-) ________________ oop.ismad.com
Post #27,775 by CRConrad 2/8/02 8:55:34 AM Reply	Hey Bryce, I was just over on /. and revisited an old... ...post of mine that you'd replied to in the meantime: No, I didn't do any "scoretrolling". (And AFAICR I hadn't read the other posts you referred to; that's why I didn't reply to your points about them.) Speaking for myself, I couldn't have "scoretrolled" (AFAIK), since I'd posted in the thread... But I don't think anyone else from here would have done that either. Christian R. Conrad The Man Who Knows Fucking Everything
Post #27,863 by tablizer 2/8/02 8:11:29 PM Reply	Okay, you are off the hook >> No, I didn't do any "scoretrolling". << Okay, I apologize for jumping to conclusions. The relative sudden drop in ratings and you coming around could have very well been purely cooncidental. >> I couldn't have "scoretrolled" (AFAIK), since I'd posted in the thread... << Some people have multiple logins. ________________ oop.ismad.com
Post #27,632 by pwhysall 2/7/02 7:54:21 AM Reply	Re: Spoken Language? I am still not sure what "codlets" are. Baby cod, of course. They grow up into big cod, destined to end up on my plate alongside chips and mushy peas. Damn. Now I'm hungry. Peter Shill For Hire [link\|http://www.kuro5hin.org\|There is no K5 Cabal]
Post #27,503 by CRConrad 2/6/02 11:05:49 AM Reply	Nothing else is possible with you. Bryce: Perhaps you were born with an OO mind. OO fans often say that OO simply formalized the way they always saw programming when it came along. Naah, he was probably born with a mind that was ggod for programming. That's what OOP is; a codification of "best practices" from pre-OO programming. And I hope to demonstration that artificial, exaggerated, and/or forced coupling (associations) is not good in the long run. How about you (at least try to) demonstrate [sic] what's good about non-OO programming, in stead of going off on yet another silly rant on what's "bad" about OOP? We'll never be able to understand what you claim is so good about your "p/r"[] style of programming, until you* give us an example of your reasoning[+] -- a full-fledged example, from basic requirements to (at least an outline of) working code. That's what this thread was supposed to be about (or perhaps rather, lead up to), you know... But as usual, you've diverted the conversation from the original tack taken by someone else, by your obstinate refusal to answer the question asked of you. Why[#] do you persist in doing that?!? Christian R. Conrad The Man Who Knows Fucking Everything []: Still a misnomer -- OOP is not the opposite of "p/r", it's the opposite of "just p". The opposite of "p/r" would be "OOP/R". [+]: If there actually is* any, which I kind of doubt... [#]: Unless you start to play ball, we'll have no other choice than to assume it's because you know you'd disprove yourself by disclosing it.
Post #27,510 by Arkadiy 2/6/02 12:20:44 PM Reply	Did you notice... ...I am trying to show some respect here? Calling someone's mind "no ggod for programming" is not going to acomplish much, except starting a flame war.
Post #27,517 by CRConrad 2/6/02 12:53:07 PM Reply	What're you talking about?!? I called a mind (yours) "good"!
Post #27,522 by Arkadiy 2/6/02 1:43:04 PM Reply	Thank you. But you did it through calling my opponent's mind "not good". I will not be the one to flame you, you see? But the flames will fly anyway, and whatever small possibilioty of understanding we currently have would be lost.
Post #27,529 by CRConrad 2/6/02 2:14:26 PM Reply	More like the other way around... I sez: What're you talking about?!? I called a mind (yours) "good"! To which Arkadiy replies: But you did it through calling my opponent's mind "not good". Naah. It's vicey-versy; Through calling your mind "good for programming", I left a door open for someone to take away the impression that I don't think Bryce's is as good... But one doesn't have to. So, if one does, perhaps that tells more about the one who does so than about what I actually said, eh? That's called the Fine Art of Implication. (Or was it tFAoInnuendo?) I will not be the one to flame you, you see? But the flames will fly anyway, and whatever small possibilioty of understanding we currently have would be lost. Lissen, Ark, when you've been around Bryce for as long as I have -- which is five years, now -- maybe you'll realise that there IS NO, however small, possibility of understanding with Bryce. And by then you'll certainly know in your bones that most people some times, and some people most of the time -- no prizes for guessing which category I think Bryce belongs to -- DESERVE to be flamed. Christian R. Conrad The Man Who Knows Fucking Everything
Post #27,540 by Arkadiy 2/6/02 3:16:12 PM Reply	Right you are. You did not say anything about his mind. I was wrong. I guess it does say something about me. As for Bryce, I've been around him as long as you, if not longer. I've seen hin appear at IWE. I guess his long sabbatical from these fora (yeah, yeah, I remember how it came about) made me hopeful again. And I have to admit it made him more civil.
Post #27,556 by CRConrad 2/6/02 6:30:26 PM Reply	Actually, you are right too... ...about that last point: And I have to admit it made him more civil. Too bad he hasn't become any less stubborn, or more open-minded! Hey, no, sorry: You have made some progress, Bryce. As for Bryce, I've been around him as long as you, if not longer. I've seen hin appear at IWE. As long, then, but not longer. Dang, really? Sorry, I must have plain forgotten you'd been around for that long. (I think I had, somehow, the impression you were too young for that.) Christian R. Conrad The Man Who Knows Fucking Everything
Post #27,563 by tablizer 2/6/02 6:54:59 PM Reply	not think like me == bad mind ? >> Lissen, Ark, when you've been around Bryce for as long as I have -- which is five years, now -- maybe you'll realise that there IS NO, however small, possibility of understanding with Bryce. << Other table fans who send me email seem to "click" with what I have to say. People who tended to hire me for contracts also liked tablizing things in many ways. It is a common human fault to conclude that: ! think like me == bad mind I am trying to overcome this built-in human bias by NOT suggesting that my approach is objectively better. It fits my head better, that is all I objectively claim (if that is not a contradiction). The examples on my website are simply bonus information where I try to communicate my dissatisfaction with OOP. I don't seeing you trying to overcome this bias in any way. (By the way, he may not have directly said it, but the implication is rather strong.) ________________ oop.ismad.com
Post #27,561 by tablizer 2/6/02 6:48:43 PM Reply	Walk Before Run >> Naah, he was probably born with a mind that was [good] for programming. That's what OOP is; a codification of "best practices" from pre-OO programming. << Then why do you CRC have a preference for Delphi over Smalltalk? Sure, I could probably buck up and go with the OOP flow to get by (I'll never be a star perhaps), but that still doesn't answer the question of why X is allegedly better than Y. BTW, if it is truely "best practices" then it should be relatively easy to show how these practices improve maintenance over the other practices by showing the keystrokes/mousestrokes, typing, etc, that programmers go thru. I know this is a rather crude metric, but in the end that is what it always boils down to from an objective standpoint. Grokability is generally not measurable in individuals, only in aggregate. Thus, what we have left is human body movements to perform various software maintanence tasks. Now, you may claim most people fit OOP better and the "left handers" just have to go along, but this is probably not true, and another topic. >> How about you (at least try to) demonstrate [sic] what's good about non-OO programming, in stead of going off on yet another silly rant on what's "bad" about OOP? << I have a whole website with small examples. True, small examples are of limited value, but when we do get into the nitty gritty, the differences often appear to subjective. Things like, "if you do it that way, then you risk busting this stuff over here." Reply: "Yeah, but that rarely happens to me practice, so why should I worry about preventing that?" IOW, what F's person A up may not F person B up. I have coined the term "mental ergonomics" for this. (Yeah yeah, I know, you don't like my coinages.) >> a full-fledged example, from basic requirements to (at least an outline of) working code. << IMO, we should walk before running. The Reports example is a relatively good starting place. After we beat that one to death, then we can work up to something bigger. Such a system could grow quite large anyhow as one tacks on one-off changes that the main framework cannot handle directly. Such one-off-ism is a primary complicator of biz software IME. You are also welcome to present a King Delphi example also. ________________ oop.ismad.com
Post #27,684 by a6l6e6x 2/7/02 2:43:16 PM Reply	A classic real world example: Brooklyn Union Gas The re-work to an OO design was done in PL/I ( a language that is a marriage of FORTRAN and COBOL from the 1960's), so it is no OO language. I remember reading a report on the project some 10 years or more ago. One of their objects, I still remember, was a gas meter. Talk about the problem domain. Everything to do with the gas meter was grouped in the new code. Perhaps the oldest and best-known case of the large-scale, beneficial application of object technology is the one at Brooklyn Union Gas, where a customer management system consisting of l.5 million lines of PL/l was replaced by a system written using an object-oriented preprocessor. The new system is very large, with 850 on-line users, a 100-gigabyte database and 10000 code modules. The benefits reported include a 40% reduction in code size due mainly to reuse, low maintenance costs (12 people in the team), trouble-free installation and above all great flexibility and extensibility. These benefits were not free. The developers had to invent their own object-oriented development methods and standards as these were not available in the development period from 1987 to 1990; traditional methods were found seriously wanting. [link\|http://osiris.sunderland.ac.uk/rif/com327/handouts/graham/graham.html\|Link.] Look in sectios 2.3 Case Studies. Arkadiy, you are "right on"! Alex "Of course, you realize this means war." -B. Bunny
Post #27,733 by tablizer 2/7/02 9:31:22 PM 2/7/02 9:35:34 PM Reply	One case proves nothing Large OOP systems have also had huge catastrophies. Unfortunately, companies rarely brag and publish failures (and even sue if consultants mention it). In such a lawyer-friendly environment, anecdotal information is not a very representative sampling technique. Edward Yourden, an IT writer, has surveyed companies to see which technologies IT managers thought were helpful. OO scored no better than average. In fact, it scored better than average early in its odoption, but pettered out to the average line. He speculated that "OO enthusiasts" were deluted over time by "regular" programmers coming into the mix who did not have the same zeal as the initial OO fans. Further, that page borrowed some of the drivel from Bertrand Meyer it appears. (I have a whole webpage critiquing his book.) ________________ oop.ismad.com Edited by tablizer Feb. 7, 2002, 09:35:34 PM EST Expand All History
Post #27,825 by a6l6e6x 2/8/02 12:57:32 PM Reply	Re: One case proves nothing There is an old Hebrew saying that says "A thousand examples doesn't constitute proof". Or, words to that effect. So in that sense you are right. But, on the other hand, I did not claim this was some kind of proof. It only an example where an OO design (actually re-design) approach worked well. I mentioned the gas meter object. One of the things that happened was the application users, in reporting a problem, would say "The gas meter is broken. It does...". The communication between the users and developers was enhanced. And, the developers could zoom in on the relevant code quickly. Can you imagine a user saying "You've got this table, and it..."? Not likely. Alex "Of course, you realize this means war." -B. Bunny
Post #27,865 by tablizer 2/8/02 8:21:27 PM Reply	ad-hoc >> There is an old Hebrew saying that says "A thousand examples doesn't constitute proof". << You only presented one, not 1000. I am not saying that all OOP applications are crap. That is not my stance. I am only saying that OOP is overhyped and the hype is ruining progress and tools for the alternatives. >> Can you imagine a user saying "You've got this table, and it..."? Not likely. << Are you saying that tables are less trace-able than objects? Let's see you do an ad-hoc query on a bunch of objects? For example, "Show me all meters west-side that have reported leakage or cracking problems since last month and serviced by Bob". ________________ oop.ismad.com
Post #27,875 by a6l6e6x 2/8/02 9:29:58 PM Reply	Re: ad-hoc >> There is an old Hebrew saying that says "A thousand examples doesn't constitute proof". << You only presented one, not 1000. I am amused that you don't recognize that I'm agreeing with you on that point. What I am saying here is that even if I did give you a thousand examples, it would still not be a proof. I am not saying that all OOP applications are crap. That is not my stance. I am only saying that OOP is overhyped and the hype is ruining progress and tools for the alternatives. >> Can you imagine a user saying "You've got this table, and it..."? Not likely. << Are you saying that tables are less trace-able than objects? Let's see you do an ad-hoc query on a bunch of objects? For example, "Show me all meters west-side that have reported leakage or cracking problems since last month and serviced by Bob". My point here is that users do not think in terms of tables, but developers do. Users think in terms of things in their problem domain, otherwise known as objects. Tables are things in the solution domain. When the objects in the problem domain match the objects in the solution domain, communication between developers and users is easier. Ad hoc queries are a separate issue. You either design for them or not depending on user requirements. OO does not exclude use of relational databases. Alex "Of course, you realize this means war." -B. Bunny
Post #27,878 by tablizer 2/8/02 11:05:54 PM Reply	English Oriented Programming >> My point here is that users do not think in terms of tables, but developers do. Users think in terms of things in their problem domain, otherwise known as objects. << Yeah, like they are really gonna relate to things like class TransitionStateManager. Programmers rarely man the customer phones anyhow (except in really small shops). Even under the longshot that I agreed with you that OOP was closer to English, it is mostly moot. I don't really see how OOP is close to English anyhow. Like I said, English sentences are based on one verb and potentally many nouns. "Bob and Dora rode a snowmobile to Grandma's house." This better maps to functions if you ask me. Verbs are more pivotable to English than nouns. >> OO does not exclude use of relational databases. << Yes, but does not get along with them very well. OOP and relational thinking tend to fight over territory. Either one gives in, or you duplicate (mirror) stuff. ________________ oop.ismad.com

Welcome to IWETHEY!