Post #182,231
11/2/04 11:54:53 AM
|
Orthogonal to DB usage
I agree about the "little language". However, I have not seen OOP do that better than procedural, and second SQL is generally a pretty compact language. It is hard to beat it on code-size (even though SQL stinks in many ways). Jones' study hilighted that pretty well. Sometimes one can use a combination of SQL and "custom language" routines. Example: \n func displayEmployees(criteria) {\n sql = "SELECT * FROM emp,other_tables WHERE "\n sql .= " [join stuff] and (" . criteria . ") ORDER BY foo"\n rs = query(sql)\n while (row = getNextRow(rs)) {\n do_stuff_with_row(row)\n }\n }\n Now we can pass it a boolean criteria expression to filter our rows. It is tough to do these kinds of things with "flat" API's. Plus, one can develop and test it as SQL first, and then paste it into the routine.
________________ oop.ismad.com
|
Post #182,247
11/2/04 12:46:40 PM
|
That's actually a good idea
Then all you'd have to do is put the dynamic query building into a method of your DB object so you don't have to re-write the [join stuff] and (" . criteria . ") piece for every function. Ooh, and you could also handle escaping user-input values in one location instead of re-creating it everywhere.
Oh wait, that's what I do with my -- as I said above -- DB object. Or did you think OO proponents had never thought of dynamically building their SQL?
===
Implicitly condoning stupidity since 2001.
|
Post #182,257
11/2/04 1:24:08 PM
|
*Snork* beat me to it :)
|
Post #182,958
11/4/04 9:58:12 PM
|
Cure worse than the medicine.
Then all you'd have to do is put the dynamic query building into a method of your DB object so you don't have to re-write the [join stuff] and (" . criteria . ") piece for every function.
Don't need OOP to do that. However, putting wrappers (OO or procedural) around SQL tends to bloat up code so that you have no net savings in code size.
Or did you think OO proponents had never thought of dynamically building their SQL?
Doing and making life easier can be two very different things.
________________ oop.ismad.com
|
Post #182,967
11/4/04 11:03:11 PM
|
"tends to bloat up code"
[link|/forums/render/content/show?contentid=156638|Post #156638] I withdrawl the "bloated" claim for now. [link|/forums/render/content/show?contentid=156690|Post #156690] might be of interest to you, as well: I have no doubt that you'll sit on this for a while and then trot out, "youses never proved it wasn't bloated!" at some point in the future, so I'm calling pre-foul now so it doesn't happen. Backtracking again, Bryce...?
Regards,
-scott anderson
"Welcome to Rivendell, Mr. Anderson..."
|
Post #182,983
11/4/04 11:49:05 PM
|
Your "solution" to such bloat was HQL, yes or no?
________________ oop.ismad.com
|
Post #182,987
11/5/04 12:06:32 AM
|
It was a solution, yes.
Regards,
-scott anderson
"Welcome to Rivendell, Mr. Anderson..."
|
Post #183,074
11/5/04 11:45:07 AM
|
Since you seem to be slow...
Scott's point is that you had this battle. Many times. You've lost. You've even admitted defeat.
Unless you have something truly novel to say, please save everyone time and energy by letting it drop this time.
Ben
I have come to believe that idealism without discipline is a quick road to disaster, while discipline without idealism is pointless. -- Aaron Ward (my brother)
|
Post #183,130
11/5/04 4:59:55 PM
11/5/04 5:00:11 PM
|
I did NOT "lose". His solution was variation on SQL
and NOT OOP
________________ oop.ismad.com
Edited by tablizer
Nov. 5, 2004, 05:00:11 PM EST
|
Post #183,133
11/5/04 5:11:07 PM
|
In your universe, perhaps
His solution was variation on SQL and NOT OOP
Let me go back to [link|http://z.iwethey.org/forums/render/content/show?contentid=156638|http://z.iwethey.org...?contentid=156638] and see.
Ah yes. Right. Scott was talking about an object-relational mapper. Which means that the overall example is going to involve a lot of OOP.
Once again you're talking out of your ass and hoping that none of us will catch where you're fudging the truth. Once again your hopes are misplaced. Please go away and try this elsewhere.
Thanks, Ben
I have come to believe that idealism without discipline is a quick road to disaster, while discipline without idealism is pointless. -- Aaron Ward (my brother)
|
Post #183,136
11/5/04 5:14:31 PM
11/5/04 5:16:02 PM
|
The mapper did not reduce his code size
Ah yes. Right. Scott was talking about an object-relational mapper. Which means that the overall example is going to involve a lot of OOP.
It was not the mapper that allowed him to shorten his queries. Again, just because something exists does not necessarily mean it is better.
Plus, how come you cannot use your techniques to shorten challenge #6?
________________ oop.ismad.com
Edited by tablizer
Nov. 5, 2004, 05:16:02 PM EST
|
Post #183,137
11/5/04 5:20:03 PM
|
Bryce, you lost this one already.
I'm not going to continue this discussion. I have a job, and I have work that needs to get done. This conversation has happened before, and you've lost. Repeatedly and decisively.
If you wish to read this as, "Bryce has more free time than Ben" you'd be perfectly correct. I'll let you waste someone else's time if anyone is interested.
Regards, Ben
I have come to believe that idealism without discipline is a quick road to disaster, while discipline without idealism is pointless. -- Aaron Ward (my brother)
|
Post #183,156
11/5/04 7:12:13 PM
11/5/04 7:15:01 PM
|
I did NOT fscken lose. He gave no code-size proof. Zilch.
You guys have a warped sense of evidence. Did you flunk science class?
________________ oop.ismad.com
Edited by tablizer
Nov. 5, 2004, 07:15:01 PM EST
|
Post #183,195
11/6/04 12:23:25 AM
|
Why is code size your (apparently) sole criterion?
Is it because that's the "best" metric? Please show your proof.
===
Implicitly condoning stupidity since 2001.
|
Post #183,424
11/8/04 2:43:37 AM
|
You are welcome to present ANY metric you can justify
The common common metrics that people more or less agree on are:
* Once and only once - ridding duplication
* Easier to change - change scenarios are given and the impact on code is analyzed
* Code size - less code is generally better
I am not saying these are necessarily the best or most complete, but they are the easiest to analyze and communicate about up to this point.
________________ oop.ismad.com
|
Post #183,436
11/8/04 9:05:55 AM
|
Thank you
I asked for proof of the value of your metric.
You replied that it's common and people more or less agree.
So popularity is your criterion.
OOP is popular.
Therefore, OOP is good.
Thank you for this admission of defeat.
===
Purveyor of Doc Hope's [link|http://DocHope.com|fresh-baked dog biscuits and pet treats]. [link|http://DocHope.com|http://DocHope.com]
|
Post #183,668
11/8/04 11:47:03 PM
|
Usually people don't question those much
If you have some better ones, then please describe them.
________________ oop.ismad.com
|
Post #183,447
11/8/04 9:25:46 AM
|
We've already been over change scenarios
Re-read the thread. You gave up on the change metric because of the branching and source code control issues.
Regards,
-scott anderson
"Welcome to Rivendell, Mr. Anderson..."
|
Post #183,671
11/8/04 11:52:31 PM
|
re: We've already been over change scenarios
You gave up on the change metric because of the branching and source code control issues.
"Branching"? I am not sure what you are refering to. Version branching or flow logic branching?
As far as version management, the existing tools are biased toward files. I agreed to that fact. However, that is not an inborn inherent fault of tables, which was my point above.
________________ oop.ismad.com
|
Post #182,255
11/2/04 1:23:35 PM
|
"Orthogonal" in exactly the same sense as differential gears
I agree about the "little language". However, I have not seen OOP do that better than procedural... I have. When requirements change, they apply force on design asymetrically. OO allows the design to slip differentially with a minimum of effort; procedural grinds gears and breaks teeth. ...and second SQL is generally a pretty compact language. It is hard to beat it on code-size (even though SQL stinks in many ways). Jones' study hilighted [sic] that pretty well. SQL is compact because you need further code to process its results, translating those results into usable structures--this is the "do_stuff_with_row" which you conveniently left out. By mixing SQL directly into your application language (whether "procedural" style or "object-oriented"), you force the developer to manage two languages at once, manually handling the translation step between the two every time they make a choice about development. A good ORM hides that, freeing the developer to focus on the problem domain. Sometimes one can use a combination of SQL and "custom language" routines. Example:
func displayEmployees(criteria) { sql = "SELECT * FROM emp,other_tables WHERE " sql .= " [join stuff] and (" . criteria . ") ORDER BY foo" rs = query(sql) while (row = getNextRow(rs)) { do_stuff_with_row(row) } }
Now we can pass it a boolean criteria expression to filter our rows. OOP: Great! You've just introduced a security hole by manually interpolating strings. TOP: Oh, but we'll never pass it unsafe criteria. OOP: And that's documented/enforced where, exactly? TOP: Fine, we'll add a comment in the procedure, documenting exactly what is considered "safe" criteria. OOP: Good. But you've got a staff of 10 developers. Who's got time to read each others' embedded comments in a library call? TOP: Fine (adding a line or two of code), we'll enforce it within the procedure. OOP: Wonderful! You missed a spot. TOP: Fine (another 10 lines of code). OOP: OK. Now do that in *every* procedure with embedded SQL. TOP: Fine, we'll abstract that into an "SQL checker" tool (adding 1000 lines of code). OOP: Nice! You've just written an SQL parser/validator. But you slowed down your DB I/O by a factor of ten (or more). TOP: Fine, we can speed that up greatly by validating each component *before* we construct the SQL string. We just need a little extra structure to say "this atom is the tablename" and "this atom is a boolean criteria string" and "this atom is the ORDER BY clause". OOP: Hmmm. It works, but you've got this huge bottleneck procedure with 38 arguments. TOP: No, I reworked it last night. Now I have 74 different procedures with slightly different argument lists for every occasion. OOP: Oog. That's really confusing. Can't we build our list of SQL atoms incrementally? Maybe there's some way to collect all those components into a single structure and then just pass that. TOP: Fine. I worked 20 hours a day for 2 weeks, but it's done: a module which builds safe SQL strings out of potentially unsafe components, and it's developer-friendly. Happy now? OOP: Congratulations. You've just written your first ORM. It is tough to do these kinds of things with "flat" API's. It's tough regardless. Why not let a team of experts do the tough parts once and let everyone benefit? Plus, one can develop and test it as SQL first, and then paste it into the routine. I'd rather have a complete test suite. Did you test the corner cases? Did you test malformed data? Did you test code coverage? Unless you've found (or written) a complete testing framework/harness within your database as well... in which case, my hat's off to you. But I haven't seen one yet. TOP may be fine for developers who have never worked on anything other than a small project, who care nothing for portability, maintainability, or software engineering (as opposed to software construction). Which is fine--lots of code is of the home construction type, where you build a small one-story edifice, live in it for life, and patch as you go. It's an asset on the books, and depreciates. Just don't expect it to give your corp a competitive advantage--that requires engineering, design, and risk management. Embedding SQL in procedural code is two-by-fours and drywall, and lots of paint. A good ORM and good OO design is pre-stressed steel, trusses, sunken piles, shear walls, and an interior designer.
The Sig: "Despite the seemingly endless necessity for doing so, it's actually not possible to reverse-engineer intended invariants from staring at thousands of lines of code (not in C, and not in Python code either)." Tim Peters on python-dev
|
Post #182,261
11/2/04 2:03:26 PM
|
You just shortened this thread by 200 posts. Cut & Paste.
Congratulations! :-D We'll have to come up with another non-election related topic. Hmmm.... How about: [link|http://discuss.joelonsoftware.com/default.asp?design.4.20066.21|Is Cut and paste a Bad Design] at Joel on Software. That [Jef Raskin] is a crackpot out of touch with reality is clear from the above article where he complains that features like cut and paste don't work, are useless, and contribute to code bloat. His argument is that if you walk away from your computer for an hour after cutting, you might forget you had cut and planned to paste and your work that was cut would be lost forever. I do believe that this has happened to him frequently because he is losing his mind. Like, whatever. Cut and paste to be working for everybody else on the planet. I think it works OK and taking it out would not improve things much. Cut and paste isn't something I think about much any more. Every editor I've used has had it. Having more access to the clipboard where things are held transiently is a good idea and would solve his problem of losing track of things. [link|http://hobbes.nmsu.edu/pub/os2/util/clipbrd/mgclip02.zip|MegaClip] was such a tool on OS/2 (from the readme.txt): MegaClip is a utility to manage multiple OS/2 PM clipboards. It is inspired in part by the IBM EWS program "ManyClip", as well as by a Windows 3.1 program I used Looong ago (but have forgotten the name of now). MegaClip's key feature over ManyClip is its ability to handle bitmaps and metafiles in addition to text. Other benefits include the ability to view more than one clipboard at a time (multiple windows), to view details about the clip (date, time, size, etc), and to 'hold' one clip in the system clipboard -- even while copying other clips. Clips may be stored within the main program window or placed directly on the desktop and it is possible to turn off 'Auto-Retrieve' so that only desired clips are retained. These features are briefly explained below. I don't think Cut & Paste is the issue. You? Cheers, Scott.
|
Post #182,267
11/2/04 2:26:58 PM
|
"[Nobody] ...points out that the cut-and-paste method...
...of moving text is inherently faulty."
Nobody, that is, except Microsoft. Jef might be forgiven for only using Macs, and never experiencing Explorer's default cut-and-paste behavior, wherein, if you never paste a "cut" file, it never gets completely "cut". Or Excel, wherein, if you never paste a "cut" row, the original is never deleted.
Meh. Mr. Raskin is a smart guy, and I greatly enjoyed Humane Interface, and learned a lot. Everyone's entitled to bad ideas. "...test the spirits to see whether they are from God, because many false prophets have gone out into the world."
|
Post #182,962
11/4/04 10:44:56 PM
11/4/04 10:46:13 PM
|
No, you got me all wrong, dude
When requirements change, they apply force on design asymetrically. OO allows the design to slip differentially with a minimum of effort; procedural grinds gears and breaks teeth.I have heard this claim from many other OO proponents. I have asked for code examples, and rarely get them. The few that did produce something proved they were either using a lame language (such as C), were lame procedural programmers, and/or did not know how to use a database right. I won't take your word for it without seeing code where OO wipes procedural's ass because you may fit into one or more of those three categories (without knowing it). SQL is compact because you need further code to process its results No, I mean for what it does, it is usually compact. By mixing SQL directly into your application language (whether "procedural" style or "object-oriented"), you force the developer to manage two languages at once So far attempts to include relational algebra into a language library using imperative API's has stunk. The problem is that relational algebra is not imperative, creating a paradigm mismatch, or at least ugly bloat. Remember this joke code?: \nNORMAL\n\nprint(a + b)\n\nBLOATED\n\nam = new math.ArithmeticManager()\nopA = new math.Operand((float) a)\nopB = new math.Operand((float) b)\nam.addOperand(opA)\nam.addOperand(opB)\nam.operator = new math.operators.Addition()\nam.executeMathOperation()\nsystem.io.output.print(am.mathOperationResult())\n Scott suggested Hybernate's query language (HQL) to avoid this kind of API bloat. Hybernate is a bastardization of SQL. One problem with it is that it only works with Java. The second problem is that it is close enough to SQL that it is not worth introducing yet another standard. Rather than make SQL++, we might as well come up with a better relational language with more meta abilities and replace SQL altogether. However, if they make HQL work with any language and it is a reasonably well-supported standard, I probably would not complain much. As far as security holes, one can create procedural cleaning and/or validation functions. Example: \nsql .= "foo = 'A' and ID = " . sqlNum(myID);\n\nOr perhaps:\n\nandChar(sql, "foo", "A");\nandNum(sql, "ID", myID);\n Small and simple. (There are other variations on this theme that get fancier.)
________________ oop.ismad.com
Edited by tablizer
Nov. 4, 2004, 10:46:13 PM EST
|