IWETHEY v. 0.3.0 | TODO
1,095 registered users | 0 active users | 0 LpH | Statistics
Login | Create New User
IWETHEY Banner

Welcome to IWETHEY!

New The Love Bloat - Scary OOP Mess
[link|http://simon.incutio.com/archive/2003/12/05/dataDriven|http://simon.incutio.../12/05/dataDriven]

OOP has invented very creative ways to write bloated verbose code that procedural would have a very hard time competing against. OOP seems like the ultimate job security tool: 3 guys to write Hello World (insert your own lightbulb joke). I know, "OOP does not force you to write that way", but with the help of Java API's as guides for the masses, the habit spreads unchecked.
________________
oop.ismad.com
New You're being religious, again
That example is contrived to be as a bloated as possible. The purpose of OOP is maintainability of complex behaviour. I wouldn't do this just to work out what string to print for values fixed at compile time. The problem does not suggest a need for frequent changes of operating systems, so no one would engineer it to accomodate frequent changes. I guess I ought to do what one of the bloggers suggested and run around the room shouting "DANGER! DANGER! WILL ROBINSON!" like a robot.

If the changes to OS strings were frequent enough to warrant a lookup table, the data would be in a database, so I'd get the database to be my lookup table. Still wouldn't bother with a Factory design pattern.
Matthew Greet


Choose Life. Choose a job. Choose a career. Choose a family. Choose a fucking big television, choose washing machines, cars, compact disc players and electrical tin openers. Choose good health, low cholesterol, and dental insurance. Choose fixed interest mortgage repayments. Choose a starter home. Choose your friends. Choose leisurewear and matching luggage. Choose DIY and wondering who the fuck you are on a Sunday morning. Choose sitting on that couch watching mind-numbing, spirit-crushing game shows, stuffing fucking junk food into your mouth. Choose rotting away at the end of it all, pishing your last in a miserable home, nothing more than an embarrassment to the selfish, fucked up brats you spawned to replace yourself. Choose your future. Choose life... But why would I want to do a thing like that? I chose not to choose life. I chose somethin' else. And the reasons? There are no reasons. Who needs reasons when you've got heroin?
- Mark Renton, Trainspotting.
New You proved my point
But that is the major problem with OO in general, not just the example. If complex interrelationships are needed, it is better to manage them via a database, not intertangled navigational classes.

For simple problems, OO is overkill. For complex ones, RDBMS do it better.

RDBMS are simply standardized, well-understood, and consistent "attribute managers". OOP is not. Some argue that OO does the "behavior part" better, but often much of the app can be converted to be attribute-driven if one knows how. And if not, I haven't seen concrete examples of OO doing the behavior side better.
________________
oop.ismad.com
New Had to use OOP, not attribute driven, for one of my apps
I've written an application that moderates what customers do on social networking websites and each type of event, such as uploading a picture, sending a message or editing a profile, and each source site, had various rules for auto approval/auto disapproval/human moderation, which depended on sender and recipient ages, use of swear and safe words, customer tag status and the like. Profiles are particularly annoying as each site had a different set of fields, including free text ones that had to be moderated.

Attribute driven would have been a non-starter and procedural would have created wonderful switch statements. As each event type had their own remote approval/disapproval functions (with the URL for the source site held in DB), this said the Factory, Strategy and Adapter design patterns. It meant the code peculiar to each event type / site combination could be separated into its own appropriately named, polymorphic class file. And when the web sites allowed customers to write testimonials about their friends, that became another event type with moderation rules and approval/disapproval adaption in new class files, one for each site. Separating specific code meant I could leave the core, event collector loop code untouched.
Matthew Greet


Choose Life. Choose a job. Choose a career. Choose a family. Choose a fucking big television, choose washing machines, cars, compact disc players and electrical tin openers. Choose good health, low cholesterol, and dental insurance. Choose fixed interest mortgage repayments. Choose a starter home. Choose your friends. Choose leisurewear and matching luggage. Choose DIY and wondering who the fuck you are on a Sunday morning. Choose sitting on that couch watching mind-numbing, spirit-crushing game shows, stuffing fucking junk food into your mouth. Choose rotting away at the end of it all, pishing your last in a miserable home, nothing more than an embarrassment to the selfish, fucked up brats you spawned to replace yourself. Choose your future. Choose life... But why would I want to do a thing like that? I chose not to choose life. I chose somethin' else. And the reasons? There are no reasons. Who needs reasons when you've got heroin?
- Mark Renton, Trainspotting.
New Polymorphism is limited
Attribute driven would have been a non-starter and procedural would have created wonderful switch statements.

Use a combination. Plus, lots of case statements often means you are doing something wrong, but I cannot check without looking at your code. OO'ers often assume you can manage differences using polymorphic sub-type hierarchies. However, hierarchies are not powerful enough for the real world. Primarily because they cannot handle orthogonality well, forcing one into either-or choices and time-consuming to remake into AND-able.

Set theory is more powerful, and better organized than the navigational pointer-like graph-hell that OOP gives you with GOF pasta. In other words, sets are a superior modeling technique to trees; and better organization than graphs (navigational).

And case statements are not necessarily evil. C just makes them ugly with its stupid "break" conventions. This is the fault of C languages, not procedural.

Related:

[link|http://www.c2.com/cgi/wiki?VariationsTendTowardCartesianProduct|http://www.c2.com/cg...dCartesianProduct]
________________
oop.ismad.com
Expand Edited by tablizer Nov. 26, 2006, 04:26:27 AM EST
New I'm not a religious zealot
I do not believe one methodology fits all and am mindful of how a technique can affect development and maintainability. In this case, the rules Strategies were handling completely different data types, so inheritence was meaningless. There was common code and such subroutines had no inherent state, so such subroutines became a procedural, library function, not messages to an object.

Attribute driven, even in combination with other techniques, was a non starter as it would need a rules engine interpeting multiple boolean expressions. That would be heavy overengineering compared to 'if-elseif-elseif-else'.

And the 'evil' of the switch statements, in this case, would be that adding a new event type requires changing switch statements scattered around various places in the core event loop file. I'd rather not do that when core behaviour has not changed and a single interface definition ensures no function can be forgotten.

Overall, I used polymorphism to place site/event type specific code in one class file where it was more easily written and maintained. It was decided it was the best technique for the situation, not because I'm religious. Data modelling is not relevant here.
Matthew Greet


Choose Life. Choose a job. Choose a career. Choose a family. Choose a fucking big television, choose washing machines, cars, compact disc players and electrical tin openers. Choose good health, low cholesterol, and dental insurance. Choose fixed interest mortgage repayments. Choose a starter home. Choose your friends. Choose leisurewear and matching luggage. Choose DIY and wondering who the fuck you are on a Sunday morning. Choose sitting on that couch watching mind-numbing, spirit-crushing game shows, stuffing fucking junk food into your mouth. Choose rotting away at the end of it all, pishing your last in a miserable home, nothing more than an embarrassment to the selfish, fucked up brats you spawned to replace yourself. Choose your future. Choose life... But why would I want to do a thing like that? I chose not to choose life. I chose somethin' else. And the reasons? There are no reasons. Who needs reasons when you've got heroin?
- Mark Renton, Trainspotting.
New Domain things rarely divide nicely into "types"
If you found the one case in 50 where sub-typing actually works cleanly, then congratulations.
________________
oop.ismad.com
Expand Edited by tablizer Nov. 26, 2006, 05:16:36 PM EST
New They divide about as neatly into types as the do into tables



[link|http://www.blackbagops.net|Black Bag Operations Log]

[link|http://www.objectiveclips.com|Artificial Intelligence]

[link|http://www.badpage.info/seaside/html|Scrutinizer]
New Bull, hierarchies cannot do sets without duplication
________________
oop.ismad.com
New I have no idea what you are talking about
but then I don't think you do either.

Apologies to Dave Letterman



[link|http://www.blackbagops.net|Black Bag Operations Log]

[link|http://www.objectiveclips.com|Artificial Intelligence]

[link|http://www.badpage.info/seaside/html|Scrutinizer]
New Take sample sets and try to turn them into trees
....You will then see. (I know, polymorphism does not require hierarchies, but in practice usually ends up that way.)
________________
oop.ismad.com
New Why would I do that?
isSystemGood: sys

| goodSystems badSystems |

goodSystems := #( SunOS Linux)
badSystems := #('Windows NT' 'Windows 95')

(goodSystems includes: sys) ifTrue: [^true].
(badSystems includes: sys) ifTrue: [^false].
self error: 'Unknown System'.



[link|http://www.blackbagops.net|Black Bag Operations Log]

[link|http://www.objectiveclips.com|Artificial Intelligence]

[link|http://www.badpage.info/seaside/html|Scrutinizer]
Expand Edited by tuberculosis Nov. 28, 2006, 12:43:09 AM EST
New Reinventing query languages in Smalltalk again?
\nSELECT OS_Name, IIF(osBase='UNIX','Good','Bad') AS Jugdement\nFROM OperatingSystems\n

(Some dialects use WHEN...ELSE...END instead of IIF)
________________
oop.ismad.com
New Smalltalk queries/collection operations predate SQL
by about 5 years I think.

Smalltalk collections respond to:

select: - provide filtered version of collection ie

#( 1 2 3 4 5 6 ) select: [:each | each isEven].
#(2 4 6)

detect: - first found

#( 1 2 3 4 5 6 ) detect: [:each | each > 3 and: [each isOdd]].
5

reject: - inverted select
#( 1 2 3 4 5 6 ) select: [:each | each isEven].
#(1 3 5)

collect: - used to derive a new collection from an existing one
#( 1 2 3 4 5 6 ) collect: [:each | each * 5].
#(5 10 15 20 25 30)

Nothing to reinvent, really. We were here first.



[link|http://www.blackbagops.net|Black Bag Operations Log]

[link|http://www.objectiveclips.com|Artificial Intelligence]

[link|http://www.badpage.info/seaside/html|Scrutinizer]
New It does not predate OTHER relational languages
________________
oop.ismad.com
New What are you NUTS?
Smalltalk?

seriously any of the *talk languages...

You are on Drugs.
--
[link|mailto:greg@gregfolkert.net|greg],
[link|http://www.iwethey.org/ed_curry|REMEMBER ED CURRY!] @ iwethey
Freedom is not FREE.
Yeah, but 10s of Trillions of US Dollars?
SELECT * FROM scog WHERE ethics > 0;

0 rows returned.
New First relational languages appeared in the early 70's
and earlier if you count Codd's math notation.
________________
oop.ismad.com
New Smalltalk was 71
[link|http://www.levenez.com/lang/history.html#03|http://www.levenez.c...g/history.html#03]

Don't bother quoting Codd's math notation. Not implemented == not exists.

You may now put your pipe down.
New Some context...
Map, Filter, and Reduce are morphisms arising from mathematics. Likely that if you want to find the first use in programming languages, you'd probably find them in Lisp. But then Smalltalk was heavily influenced by Lisp (and Algol), so that wouldn't be surprising.

Map applies a function over a collection. Filter applies a predicate to a collection and returns a subset where the predicate is true. Reduce is a fold of a collection.

Guess I should also reuse my explanation of [link|http://z.iwethey.org/forums/render/content/show?contentid=247589|Higher Order Functions] in an earlier thread.
Expand Edited by ChrisR Dec. 3, 2006, 07:28:35 PM EST
New Java is not OO.
And, BTW, smart OO beats over engineered data driven programming too.

Perhaps smart beats over engineered and the rest is superfluous.




[link|http://www.blackbagops.net|Black Bag Operations Log]

[link|http://www.objectiveclips.com|Artificial Intelligence]

[link|http://www.badpage.info/seaside/html|Scrutinizer]
New Can't tell because there are too many definitions of OO
[link|http://www.c2.com/cgi/wiki?DefinitionsForOo|http://www.c2.com/cg...?DefinitionsForOo]
________________
oop.ismad.com
New We've had this argument before.
And you've not convinced anyone.

Objects can make code do some amazing things and often through economy of scale. So it's 'bloated' for a small solution? With 60 lines and 10 minutes, I can leverage over 500 lines and I have a brand-new database-backed object that has late-loading, automatic caching, intelligent saving and a very easy to use collection. Another 60 lines and I get it all for another object. With ten objects, my core code is now 50 per object. With twenty, it's 25 per object. And the object notation means I can re-factor some part of the core object and everything automatically and invisibly benefits. This is much harder to do with procedures.

Wade.
"Don't give up!"
New Prove it by showing me "difficult" procedural code
OO'ers are often bad procedural/DB programmers such that I might be able to offer you tips if you show me procedural being "bad".
________________
oop.ismad.com
New You don't pay me well enough to code that.
"Don't give up!"
New I didn't pay you to make unsubstantiated claims either
But you did it for free.
________________
oop.ismad.com
     The Love Bloat - Scary OOP Mess - (tablizer) - (24)
         You're being religious, again - (warmachine) - (17)
             You proved my point - (tablizer) - (16)
                 Had to use OOP, not attribute driven, for one of my apps - (warmachine) - (15)
                     Polymorphism is limited - (tablizer) - (14)
                         I'm not a religious zealot - (warmachine) - (13)
                             Domain things rarely divide nicely into "types" - (tablizer) - (12)
                                 They divide about as neatly into types as the do into tables -NT - (tuberculosis) - (11)
                                     Bull, hierarchies cannot do sets without duplication -NT - (tablizer) - (10)
                                         I have no idea what you are talking about - (tuberculosis) - (9)
                                             Take sample sets and try to turn them into trees - (tablizer) - (8)
                                                 Why would I do that? - (tuberculosis) - (7)
                                                     Reinventing query languages in Smalltalk again? - (tablizer) - (6)
                                                         Smalltalk queries/collection operations predate SQL - (tuberculosis) - (5)
                                                             It does not predate OTHER relational languages -NT - (tablizer) - (4)
                                                                 What are you NUTS? - (folkert) - (3)
                                                                     First relational languages appeared in the early 70's - (tablizer) - (2)
                                                                         Smalltalk was 71 - (crazy) - (1)
                                                                             Some context... - (ChrisR)
         Java is not OO. - (tuberculosis) - (1)
             Can't tell because there are too many definitions of OO - (tablizer)
         We've had this argument before. - (static) - (3)
             Prove it by showing me "difficult" procedural code - (tablizer) - (2)
                 You don't pay me well enough to code that. -NT - (static) - (1)
                     I didn't pay you to make unsubstantiated claims either - (tablizer)

Not such a bad thing, to be farmed by rats...
194 ms