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" 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 didn't tell you that it was good! I told you that it was interesting.
247 ms