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 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
New 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.
New *Snork* beat me to it :)
New 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
New "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..."
New Your "solution" to such bloat was HQL, yes or no?
________________
oop.ismad.com
New It was a solution, yes.
Regards,

-scott anderson

"Welcome to Rivendell, Mr. Anderson..."
New 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)
New I did NOT "lose". His solution was variation on SQL
and NOT OOP
________________
oop.ismad.com
Expand Edited by tablizer Nov. 5, 2004, 05:00:11 PM EST
New 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)
New 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
Expand Edited by tablizer Nov. 5, 2004, 05:16:02 PM EST
New 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)
New 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
Expand Edited by tablizer Nov. 5, 2004, 07:15:01 PM EST
New 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.
New 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
New 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]
New Usually people don't question those much
If you have some better ones, then please describe them.
________________
oop.ismad.com
New 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..."
New 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
New "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
New 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.
New "[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."
New 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
Expand Edited by tablizer Nov. 4, 2004, 10:46:13 PM EST
     Time for good anti-OO battle to take minds off of election - (tablizer) - (77)
         Sorry cant go there - (daemon) - (32)
             How is being locked to a DB more evil than being locked to - (tablizer) - (31)
                 It's best to fit the tool to the job - (FuManChu) - (30)
                     Thanks for that ... +5 insightful - (drewk) - (6)
                         For various definitions of "start" ;) - (FuManChu)
                         On writing the "little language thing ..." - (systems) - (4)
                             Suggestion - (ben_tilly)
                             "Little Language" definition, components - (FuManChu) - (2)
                                 On what makes it easy to do little languages. - (JimWeirich) - (1)
                                     Good point. - (FuManChu)
                     Orthogonal to DB usage - (tablizer) - (22)
                         That's actually a good idea - (drewk) - (17)
                             *Snork* beat me to it :) -NT - (FuManChu)
                             Cure worse than the medicine. - (tablizer) - (15)
                                 "tends to bloat up code" - (admin) - (14)
                                     Your "solution" to such bloat was HQL, yes or no? -NT - (tablizer) - (13)
                                         It was a solution, yes. -NT - (admin)
                                         Since you seem to be slow... - (ben_tilly) - (11)
                                             I did NOT "lose". His solution was variation on SQL - (tablizer) - (10)
                                                 In your universe, perhaps - (ben_tilly) - (9)
                                                     The mapper did not reduce his code size - (tablizer) - (8)
                                                         Bryce, you lost this one already. - (ben_tilly) - (7)
                                                             I did NOT fscken lose. He gave no code-size proof. Zilch. - (tablizer) - (6)
                                                                 Why is code size your (apparently) sole criterion? - (drewk) - (5)
                                                                     You are welcome to present ANY metric you can justify - (tablizer) - (4)
                                                                         Thank you - (drewk) - (1)
                                                                             Usually people don't question those much - (tablizer)
                                                                         We've already been over change scenarios - (admin) - (1)
                                                                             re: We've already been over change scenarios - (tablizer)
                         "Orthogonal" in exactly the same sense as differential gears - (FuManChu) - (3)
                             You just shortened this thread by 200 posts. Cut & Paste. - (Another Scott) - (1)
                                 "[Nobody] ...points out that the cut-and-paste method... - (FuManChu)
                             No, you got me all wrong, dude - (tablizer)
         Repeat after me: - (admin) - (1)
             I never said OO was JUST about inheritance. - (tablizer)
         Amusing to note... - (JimWeirich) - (41)
             re: nouns and noun grouping - (tablizer) - (40)
                 Bryce: control tables are bad - (admin) - (37)
                     Time will erase performance differences - (tablizer) - (36)
                         That's not the main reason why they're bad. - (admin) - (35)
                             Because VC tools are hierarchy-biased. - (tablizer) - (34)
                                 Go read the thread. - (admin) - (33)
                                     You always talk as if I push a grand conspiracy - (tablizer) - (32)
                                         Relational has its place. - (admin) - (31)
                                             Math and Boolean expressions - (tablizer) - (30)
                                                 Ever use Zachary? - (admin) - (29)
                                                     I will believe it only when I see it with my own eyes - (tablizer) - (28)
                                                         - said the blind man (ducks and runs) -NT - (Arkadiy)
                                                         NO. - (admin) - (26)
                                                             You never identified an in-born fault of tables. -NT - (tablizer) - (25)
                                                                 Tables don't make good chairs. - (Another Scott) - (24)
                                                                     Vacuum Tubes - (tablizer) - (23)
                                                                         You can pry my tube guitar amp outta my cold, dead fingers. - (Steve Lowe) - (22)
                                                                             Digital precision can be boring - (tablizer) - (18)
                                                                                 Yes - tubes are IT man - (tuberculosis) - (17)
                                                                                     Heh! That was my first bass amp! - (jb4) - (16)
                                                                                         I don't know whether to be amused or appalled - (tuberculosis) - (15)
                                                                                             Both actually - (jb4) - (14)
                                                                                                 In negotiations - (jake123) - (13)
                                                                                                     Drooooooooool - (Steve Lowe) - (12)
                                                                                                         Didn't get it - (jake123) - (11)
                                                                                                             Bum R! -NT - (jb4) - (10)
                                                                                                                 Oh well. - (jake123) - (9)
                                                                                                                     Talk to your amp tech - (Steve Lowe) - (8)
                                                                                                                         Oh yeah - (jake123) - (1)
                                                                                                                             Had a teacher who did that - (drewk)
                                                                                                                         Re: Talk to your amp tech - (Ashton) - (5)
                                                                                                                             What I'm gaining - (jake123) - (4)
                                                                                                                                 Have you considered an attenuator? - (Steve Lowe) - (3)
                                                                                                                                     Yes I have - (jake123) - (2)
                                                                                                                                         New thread time, maybe...? -NT - (admin)
                                                                                                                                         This might not cost a bundle.. (new thread) - (Ashton)
                                                                             Mesa Boogie Forever -NT - (tuberculosis) - (2)
                                                                                 That'll prolly be my second choice - (jake123)
                                                                                 Feh! The Ultimate was... - (jb4)
                 re: nouns and noun grouping - (JimWeirich) - (1)
                     Can't do a whole lot with your hidden anecdotes - (tablizer)

I have a horse!
241 ms