Re: The solution is to toss OO to begin with, not Python

Post #155,305 by admin 5/15/04 10:25:01 AM Reply	Re: The solution is to toss OO to begin with, not Python You spend all your code translating back and forth between two discordant paradigms. Care to back that up? Regards, -scott anderson "Welcome to Rivendell, Mr. Anderson..."
Post #155,319 by tablizer 5/15/04 2:23:14 PM Reply	not today ________________ oop.ismad.com
Post #155,646 by pwhysall 5/18/04 1:48:41 AM Reply	BLAM BLAM VROOOOOooooommm..... Peter [link\|http://www.debian.org\|Shill For Hire] [link\|http://www.kuro5hin.org\|There is no K5 Cabal] [link\|http://guildenstern.dyndns.org\|Blog]
Post #155,650 by tablizer 5/18/04 2:11:02 AM Reply	and when you do the same? ________________ oop.ismad.com
Post #156,083 by tablizer 5/20/04 2:16:42 PM Reply	Bloat explanation Part of the reason for the OR mapper bloat is that schemas tend to be echoed in code. There will (roughly) be a class for every table that mirrors the table structure. This is a violation of Once-And-Only-Once. Second, there will often be wrappers for SQL statements that create more indirection. Whether one agrees such indirection is good or not (probably a huge debate in itself), it increases the code size. And there are other little doodads in OR mappers that add to code size and complexity. For example, the issue of when to "save" to the database and when to cache often becomes something that a developer has to worry about that they otherwise would not. If you read and write directly to the DB, you generally don't have to worry about those kinds of things nearly as much. The DBMS handles disk/RAM caching. Note that code being auto-generated is still more code. Machine-generated bloat is still bloat. It hangs around and clutters up your view of the code and business logic. ________________ oop.ismad.com
Post #156,090 by admin 5/20/04 2:42:07 PM Reply	Not what I meant. You spend all your code translating back and forth between two discordant paradigms. Emphasis mine. Care to back that up? Regards, -scott anderson "Welcome to Rivendell, Mr. Anderson..."
Post #156,107 by FuManChu 5/20/04 4:01:01 PM Reply	That's a very table-centric point of view Part of the reason for the OR mapper bloat is that schemas tend to be echoed in code. There will (roughly) be a class for every table that mirrors the table structure... Note that code being auto-generated is still more code. Machine-generated bloat is still bloat. It hangs around and clutters up your view of the code and business logic. My approach has been to auto-generate the DB, rather than the code. This takes 55 lines of code for my ADO store, including comments. That kind of bloat I can live with. :) Doing it directly in the DB without an intermediate layer locks you into a specific DB (and vendor). It harms deployers by reducing their market choices. It harms developers by reducing their market (e.g. "your app works with MySQL, we only use Oracle for religious reasons; therefore, we're not buying your app"). Using an OR mapper allows the DB to take its rightful place as a commodity. A good OR mapper can make the DB nearly hot-swappable.
Post #156,177 by tablizer 5/20/04 11:51:39 PM Reply	Of course. Tables rock. Code is ugly. My approach has been to auto-generate the DB, rather than the code. I hope it is good relational normalization. Some OO'ers prefer a bunch of "skinny" tables, and that is uuuuugly and hard to use. Doing it directly in the DB without an intermediate layer locks you into a specific DB (and vendor). I am not sure this can be avoided without complicating the code by taking your queries down to the lowest-common denominator and adding a bunch of cluttery wrappers. Plus using an OR-mapper locks you into the OR-mapper tool/vendor. You seem to be trading one lockage for another. ________________ oop.ismad.com
Post #156,190 by FuManChu 5/21/04 3:09:32 AM Reply	Snort. Next you'll be claiming SQL is a "full-featured" programming language. > You seem to be trading one lockage for another. If you want to look at it that way. But there are some significant differences between the two: Database: 1. Should be a commodity, but isn't due to vendor stubbornness. 2. Difficult to write (I don't mean the SQL, I mean the DB engine). 3. Extremely performance-critical code. 4. Monolithic in design. 5. Done to death, and yet 6. Significant differences between the implementations. App framework: 1. Written in a high-level-language, so it's easier to maintain. 2. Open source--tweak to your heart's content. 3. Any given subsystem is easily wrappable if swapped out. 4. Open to experimentation, as different apps have different needs, and yet 5. Not an awful lot of difference between implementations. I've considered swapping out templating engines, SQL mappers, object caches and indexers. None of those tasks seems particularly difficult. Have you noticed the core of Dejavu is only 1700 lines including inline documentation? Seems I've got a good glue, not a lock.
Post #156,308 by tablizer 5/22/04 1:24:08 AM Reply	Re: Snort (* Database: Should be a commodity, but isn't due to vendor stubbornness. ) You can always write your own or use an open-source one. You don't have to worry about using SQL if you don't like it and just want small code. ( Difficult to write (I don't mean the SQL, I mean the DB engine). ) Perhaps if you didn't use SQL it would be smaller. ( Extremely performance-critical code. ) OR-mappers are not known to add speed to systems. ( Monolithic in design. ) Please explain this word. You keep using it. ( app framework: Written in a high-level-language, so it's easier to maintain. ) There are small RDBMS written in Java. I can't think of the name right now. ( Open source--tweak to your heart's content. ) There are multiple open source RDBMS. For example, MySQL, PostgreSQL, SQLite. Most are written in C I believe. ( Any given subsystem is easily wrappable if swapped out. *) I am not sure what you mean here. ________________ oop.ismad.com
Post #156,225 by ben_tilly 5/21/04 1:46:09 PM Reply	So now you're down on "skinny" tables? What would make a table skinny? Properly normalizing it? Just wondering, Ben To deny the indirect purchaser, who in this case is the ultimate purchaser, the right to seek relief from unlawful conduct, would essentially remove the word consumer from the Consumer Protection Act - [link\|http://www.techworld.com/opsys/news/index.cfm?NewsID=1246&Page=1&pagePos=20\|Nebraska Supreme Court]
Post #156,309 by tablizer 5/22/04 1:27:18 AM Reply	Re: So now you're down on "skinny" tables? From c2.com under DatabaseBestPractices: I am bothered by (1:1)-to-(0:1) relationships. It creates lots of skinny tables, more joins, and creates change-problems. For example, if managers have certain fields only for managers, but later all employees get some of the same perks, then moving those fields back into Employees instead of Managers creates headaches. Thus, I suggest keeping it all together. ________________ oop.ismad.com

Welcome to IWETHEY!