On 16 June 2012 02:23, Mark Haniford <[email protected]> wrote: > Paul, > > I found your post interesting in that it might reflect a fundamental > problem that I have with "normal, average" OO, and that is that > methods belong with data. I have never bought that idea....ever. I > remember feeling stupid because I could never grok that idea and then > felt better when the chief scientist at Franz (who of course produce > Franz Lisp) said that functions don't belong with data. So of course > in Common Lisp we have generic functions. >
I also thought that so called OO is just a mere coupling of data and functions.. but after learning smalltalk and especially an image-based development, i came to conclusion, that it is often not necessary to separate those two, it's all just data or, if you like another word, - an information. Information describing some numbers or connections between multiple entities, or their groups, and information which describes how computer system operates with those entities. And that's IMO fairly easy to get. > There's this continuous mental dilenma with me about what belongs in a > class. It's just a big bowl of wrong (TM Jeff Garlin) where we have > everything that can ever be done to a class belong to that class. So > that's why I subscribe to anemic classes, despite what Fowler and > others say. The exception I have is valid state (factories), but even > then I find that I want to bring extension methods (in c#) back into > the proper class. > > We're doing something wrong, but I'm just a joe-average programmer and > like subscribing to newsgroups like this to hear what the big brains > are saying :) > > On Fri, Jun 15, 2012 at 11:45 AM, Paul Homer <[email protected]> wrote: >> I see something deeper in what Zed is saying. >> >> My first really strong experiences with programming came from the >> data-structures world in the late 80s at the University of Waterloo. There >> was an implicit view that one could decompose all problems into >> data-structures (and a few algorithms and a little bit of glue). My sense at >> the time was that the newly emerging concepts of OO were a way of >> entrenching this philosophy directly into the programming languages. >> >> When applied to tasks like building window systems, OO is an incredibly >> powerful approach. If one matches what they are seeing on the screen with >> the objects they are building in the back, there is a strong one-to-one >> mapping that allows the programmer to rapidly diagnose problems at a speed >> that just wasn't possible before. >> >> But for many of the things that I've built in the back-end I find that OO >> causes me to jump through what I think are artificial hoops. Over the years >> I've spent a lot of time pondering why. My underlying sense is that there >> are some fundamental dualities in computational machines. Static vs. >> dynamic. Data vs. code. Nouns vs. verbs. Location vs. time. It is possible, >> of course, to 'cast' one onto the other, there are plenty of examples of >> 'jumping' particularly in languages wrt. nouns and verbs. But I think that >> decompositions become 'easier' for us to understand when we partition them >> along the 'natural' lines of what they are underneath. >> >> My thinking some time ago as it applies to OO is that the fundamental >> primitive, an object, essentially mixes its metaphors (sort of). That is, it >> contains both code and data. I think it's this relatively simple point that >> underlies the problems that people have in grokking OO. What I've also found >> is that that wasn't there in that earlier philosophy at Waterloo. Sure there >> were atomic primitives attached to each data-structure, but the way we build >> heavy-duty mechanics was more often to push the 'actions' to something like >> an intermediary data-structure and then do a clean simple traversal to >> actuate it (like lisp), so fundamentally the static/dynamic duality was >> daintily skipped over. >> >> It is far more than obvious that OO opened the door to allow massive >> systems. Theoretically they were possible before, but it gave us a way to >> manage the complexity of these beasts. Still, like all technologies, it >> comes with a built-in 'threshold' that imposes a limit on what we can build. >> If we are too exceed that, then I think we are in the hunt for the next >> philosophy and as Zed points out the ramification of finding it will cause >> yet another technological wave to overtake the last one. >> >> Just my thoughts. >> >> >> Paul. >> >> >> _______________________________________________ >> fonc mailing list >> [email protected] >> http://vpri.org/mailman/listinfo/fonc >> > _______________________________________________ > fonc mailing list > [email protected] > http://vpri.org/mailman/listinfo/fonc -- Best regards, Igor Stasenko. _______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
