Post #116,538
9/4/03 7:17:27 AM
|
Question about programming with functions.
I got challenged today about the way we program our application at work. You probably remember it's in PHP. One of PHP's attractions is that each .php file functions like an individual CGI script. Another attraction is that it's easy to inline PHP code and HTML.
Due to the way our application has ah developed, the pages post back to themselves. Quite a number of them have JavaScript triggers to refresh to achieve a re-filter or some other change. There's also save code.
Also due to the way the application has been developed, the code is extremely inline: there's an include to fetch the API, then initialization and checks for various key variables, mostly selectors. Action code like saving is next, usually inside an if. Then display logic follows. In the rare case the page has a function, it will generally be at the end of the file.
I got challenged as to why this was so, why there were not more functions and less inline code. Cited were "major projects" that functionalized processing. Even the Linux kernel...
Myself, I can't see the use of using a function to isolate a few dozen lines of code that is called *once*. If 600 lines of code will execute from top to bottom, what's wrong with putting it all in order? Am I missing something?
Note that this has nothing to do with our API: the API itself is largely objects and is turning more so day-by-day. Many of the remaining standalone functions are becoming class methods.
Wade.
Is it enough to love
Is it enough to breathe
Somebody rip my heart out
And leave me here to bleed
| |
Is it enough to die
Somebody save my life
I'd rather be Anything but Ordinary
Please
| -- "Anything but Ordinary" by Avril Lavigne. |
|
Post #116,539
9/4/03 7:43:01 AM
|
Code that's called once...
... might not always be. That's minor, however, compared to the readability gains. We have a good deal of similar code here -- 4000 line long CGI pages, etc. Putting stuff in functions makes the code easier to wade through (so to speak...) for people who aren't as familiar with it; I am speaking from first-hand experience here. Some of this stuff is amazingly difficult to understand mainly from sheer length.
Regards,
-scott anderson
"Welcome to Rivendell, Mr. Anderson..."
|
Post #116,549
9/4/03 9:31:15 AM
|
What he said, with more detail
Ever since I took a Pascal class in the early 80's I've liked the idea of a "main" loop that says what's happening in human-readable form: $updates = handle_updates();\nif( $updates["forward_url"] ){\n header( "Location: ".$updates["forward_url"] );\n exit;\n} elseif( $updates["error"] ){\n show_header();\n show_error( $updates["error"] );\n show_footer();\n exit;\n}\n\nshow_header();\nshow_page();\nshow_footer();\n\nfunction handle_updates(){\n...There's no question what's happening. ===
Implicitly condoning stupidity since 2001.
|
Post #116,553
9/4/03 9:53:20 AM
|
Re: What he said, with more detail
Isn't it true that the whole HTML-based web thing has basically set development methodology back 20 years? It's worse than pages of LOCATE 10,20s and GOTOs..
What's needed is a better page definition language with some real structure to it.
-drl
|
Post #116,556
9/4/03 10:04:59 AM
|
Uhh, HTML *is* structured
The problem is that for five generations of browsers now (and working on the sixth) the browsers are forgiving of poorly written html. Look at the source for this page and tell me it's not structured.
===
Implicitly condoning stupidity since 2001.
|
Post #116,558
9/4/03 10:15:29 AM
|
HTML not a page definition language
And Scott could make a bag of hammers look smart.
-drl
|
Post #116,557
9/4/03 10:14:02 AM
|
What he said, and what he before him said ...
drewk: Ever since I took a Pascal class in the early 80's I've liked the idea of a "main" loop that says what's happening in human-readable form
(emphasis mine)
The key is readability. Over the years I've found my functions getting smaller and smaller and at the same time getting easier to understand. Breaking a large program into functions is not about reusability, but readability.
Rule of thumb: If you feel you need to add a comment for a block of code, then you probably should turn that chunk of code into an appropriately named function.
--
-- Jim Weirich jweirich@one.net [link|http://onestepback.org|http://onestepback.org]
---------------------------------------------------------------------
"Beware of bugs in the above code; I have only proved it correct,
not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas)
|
Post #116,564
9/4/03 11:07:16 AM
|
Someone confirm/deny what I was told
Rule of thumb: If you feel you need to add a comment for a block of code, then you probably should turn that chunk of code into an appropriately named function. A developer I used to work with disagreed with this on the grounds that calling a function, and potentially passing the necessary data, incurred enough overhead to become significant to execution time. In a hypothetical 500-line file, how much difference might there actually be between doing it in a single 500-line pass, and doing it in 50 10-line functions? Does the answer differ if you're using a compiled vs. an interpreted language? Are there just too many variables for there to be a general answer to this? In any case, my experience says that the readability/maintainability gain of breaking it up more than makes up for possible efficiency gains. If you can make one developer 10% more effective, you can add a fairly decent box to your cluster every year to improve execution speed. ===
Implicitly condoning stupidity since 2001.
|
Post #116,565
9/4/03 11:10:36 AM
|
Depends on the language
PL/SQL function calls, for example, are relatively slow. This makes a noticeable difference on a box that already runs its CPUs near maximum. :-P
If you do have the CPU to burn, however, the maintenance benefits are well worth it. There are those, however, who cannot be convinced of this no matter what. "But, it's all right in one place! And all the variable declarations are right at the top! How would functions be better?" (actual response, by the way, to a suggestion that we use more functions instead of 4000-line long procedures with 300 variables at the top...)
Regards,
-scott anderson
"Welcome to Rivendell, Mr. Anderson..."
|
Post #116,568
9/4/03 11:17:50 AM
|
Re: Depends on the language
(actual response, by the way, to a suggestion that we use more functions instead of 4000-line long procedures with 300 variables at the top...)
GAH! Cobol!
-drl
|
Post #116,570
9/4/03 11:21:45 AM
|
Sounds more like FORTRAN
Cobol has copy (you know - like include) files.
Smalltalk is dangerous. It is a drug. My advice to you would be don't try it; it could ruin your life. Once you take the time to learn it (to REALLY learn it) you will see that there is nothing out there (yet) to touch it. Of course, like all drugs, how dangerous it is depends on your character. It may be that once you've got to this stage you'll find it difficult (if not impossible) to "go back" to other languages and, if you are forced to, you might become an embittered character constantly muttering ascerbic comments under your breath. Who knows, you may even have to quit the software industry altogether because nothing else lives up to your new expectations.
--AndyBower
|
Post #116,571
9/4/03 11:29:09 AM
|
Yes, very FORTRANish
I worked with a guy at Coopers & Lybrand once who was an economist by education. He taught himself how to program C.
So, in this program he wrote, main() called proc(), which was about 5000 lines long with numbered variable names instead of structs. Gah.
Regards,
-scott anderson
"Welcome to Rivendell, Mr. Anderson..."
|
Post #116,577
9/4/03 12:05:31 PM
|
Different reason for that, I believe
When I was learning PL/SQL I read that one of the disadvantages was that the PostgreSQL optimizer couldn't read into the functions. So putting all the logic into a larger query gave the optimizer more chances to build a query plan, whereas using a function removed the options.
===
Implicitly condoning stupidity since 2001.
|
Post #116,589
9/4/03 1:28:51 PM
|
We did testing...
Multiple function calls in loops, etc.
While there may have been a query plan issue at some point with packages, I doubt that's the case any longer. Everyone, but everyone, says to put your DML in a function.
BTW, did you mean the Oracle optimizer...? ;-)
Regards,
-scott anderson
"Welcome to Rivendell, Mr. Anderson..."
|
Post #116,601
9/4/03 2:42:49 PM
|
D'oh!
Oh yeah, real PL/SQL. I was just using those books because they were better than the online docs for PL/pgSQL.
===
Implicitly condoning stupidity since 2001.
|
Post #116,602
9/4/03 2:49:28 PM
|
ROFL.
Regards,
-scott anderson
"Welcome to Rivendell, Mr. Anderson..."
|
Post #116,572
9/4/03 11:30:59 AM
|
I have a 1GHz laptop
My first computer was an 8MHz Mac II.
Tell me the cost of calling a function still matters 99.99999999999999999% of the time.
If it does - you can still usually make it *look* like a function with a macro or something.
Scott's SQL example is a degenrative case. Realtime systems in tiny machines might be another one.
A good quote I've seen is "The number of programmers who think their software has high performance requirements is at least two orders of magnitude greater than the number of programmers that actually have high performance requirements".
Call the freakin function - if the system runs too slowly, profile and inline appropriately.
Smalltalk is dangerous. It is a drug. My advice to you would be don't try it; it could ruin your life. Once you take the time to learn it (to REALLY learn it) you will see that there is nothing out there (yet) to touch it. Of course, like all drugs, how dangerous it is depends on your character. It may be that once you've got to this stage you'll find it difficult (if not impossible) to "go back" to other languages and, if you are forced to, you might become an embittered character constantly muttering ascerbic comments under your breath. Who knows, you may even have to quit the software industry altogether because nothing else lives up to your new expectations.
--AndyBower
|
Post #116,611
9/4/03 3:49:58 PM
|
Or better yet
The number of programmers who think that they have achieved high performance by scrificing readabilty is two orders of magnitude higher than the number of programmers who actually achieved high performance
I had a piece of code with 3 functions, each with 3000-5000 lines. Turned out, it was dog slow. When rewritten with proper modularization and data structures, it became order of magnitude faster, function calls or not.
--
Less Is More. In my book, About Face, I introduce over 50 powerful design axioms. This is one of them.
--Alan Cooper. The Inmates Are Running the Asylum
|
Post #116,583
9/4/03 12:41:13 PM
|
Re: Someone confirm/deny what I was told
A developer I used to work with disagreed with this on the grounds that calling a function, and potentially passing the necessary data, incurred enough overhead to become significant to execution time.
Hey, I think I used to work with the same guy. He also wanted to do everything in assembly for efficiency. Seriously! I remember him saying, "Jim, do you realize how many instructions are needed for a single FORTRAN CALL statement?" Gaaah.
Another rule of thumb: Make it right, then make it fast. If excessive function overhead is a performance problem, then the "inline method" refactoring is only a menu pick and an OK button away.
Lots of languages will inline automatically for you as well. C++ lets you manually specify inlining. The SmartEiffel compiler will automatically inline methods where it makes sense, and it will even handle inline "virtual" methods.
--
-- Jim Weirich jweirich@one.net [link|http://onestepback.org|http://onestepback.org]
---------------------------------------------------------------------
"Beware of bugs in the above code; I have only proved it correct,
not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas)
|
Post #116,619
9/4/03 4:12:07 PM
|
Yeah that guy gets around!
Because I know I worked with him too. ;-)
Java is a joke, only it's not funny.
--Alan Lovejoy
|
Post #118,608
9/23/03 2:36:42 PM
|
Puh-LEEEEZE!
A developer I used to work with disagreed with this on the grounds that calling a function, and potentially passing the necessary data, incurred enough overhead to become significant to execution time. My rationalization alarm triggered on this one! Scott is, as usual, right in that various interpreted languages (PL/SQL, and I'd add VB in all its incarnations) can certainly load the overhead onto a resource-starved application. However, I work primarily in the real-time embedded space, where we are always starved for resources, with not enough process, not enough ROM and not enough RAM. In over 27 years, I cannot think of a single instance where modularizing the code resulted in a missed or overtime event, clobbered interrupt, or anything else that would indicate that "overhead be[came] significant to execution time." Basically, the guy is spounting bullshit jb4
Boy I'd like to see those words on a PR banner behind [Treasury Secretary John] Snow at the podium:
Jobs and Growth: Just Wait.
John J. Andrew, unemployed programmer; see jobforjohn.com
|
Post #116,677
9/4/03 9:56:40 PM
|
How big a block?
I suspect that might have a bearing on how often to function, as it were. Based on current code, 1 commented block become 1 function would result in many 4 and 5 line functions.
Wade.
Is it enough to love
Is it enough to breathe
Somebody rip my heart out
And leave me here to bleed
| |
Is it enough to die
Somebody save my life
I'd rather be Anything but Ordinary
Please
| -- "Anything but Ordinary" by Avril Lavigne. |
|
Post #117,724
9/13/03 1:01:32 PM
|
Pascal has one up on PHP
Ever since I took a Pascal class in the early 80's I've liked the idea of a "main" loop that says what's happening in human-readable form:
But Pascal has "nested functions", somemthing that PHP lacks. Thus, you end up passing a bunch of parameters up, down, and all around. It often creates more change-points upon maintenance. Nested functions makes refactoring into routines easier because you don't have to keep making and managing parameter or "global" lists (they are really Regional, not Global, BTW.) The down-side to Pascal is that it requires physical nesting instead of referenced nesting or dynamic nesting, and is picky about the sequence of function definition.
But, form-centric web programming is inherantly messy and sucks because businesses keep wanting GUI-like functionality (Dephi,VB,PB) from brochure-oriented HTML browsers. Thus, either you try to emulate a GUI ([link|http://geocities.com/tablizer/webstif.htm|http://geocities.com...lizer/webstif.htm]), wait for a biz-form oriented protocol to catch on (like SCGUI), or live with the clunkiness of web apps.
________________
oop.ismad.com
|
Post #116,569
9/4/03 11:19:45 AM
|
Re: inline PHP code and HTML
While I understand the initial atttraction of this capability - it turns out that mixing presentation and processing logic turns into a maintenance nightmare down the road.
That said - there are two critical things to look at when evaluating the "goodness" of your system.
First is multiple instances of similar chunks of code - ie "copy & paste reuse". How you minimize this (whether via copy files/file inclusion or formal functions) doesn't matter - only that you do minimize it - lest you need to change the behavior of one of these little multi-nuggets and find yourself making a dozen identical changes in various places.
Second is understandability - 1 function == one thought. As Jim said - if you feel like you need a comment - you really need a well named function instead. So you use functions to reduce clutter and give you the ability to view your software at various layers of abstraction easily. Like Drew's example - at the coarsest level his main function neatly describes the processing logic of the program at a high level - but if you want more detail you dig into the definitions of the functions - like using a zoom lens.
Smalltalk is dangerous. It is a drug. My advice to you would be don't try it; it could ruin your life. Once you take the time to learn it (to REALLY learn it) you will see that there is nothing out there (yet) to touch it. Of course, like all drugs, how dangerous it is depends on your character. It may be that once you've got to this stage you'll find it difficult (if not impossible) to "go back" to other languages and, if you are forced to, you might become an embittered character constantly muttering ascerbic comments under your breath. Who knows, you may even have to quit the software industry altogether because nothing else lives up to your new expectations.
--AndyBower
|
Post #116,675
9/4/03 9:49:32 PM
|
Copy and Paste vs Functions.
We have a strong culture against copy-and-paste. Of over 300 files, we have two extant examples of copy-and-paste. Both are the To Be Fixed list: one just happened as one page's capabilities began approaching what another page did (no, they don't do the same thing, but they do it in the same way, if that makes sense). The other is basically a hack to support differing clients requirements. We don't like it but no-one will give us time to do it properly for everyone.
Re: Need to Comment = Should make a Function. I have a problem with this, especially when the commented code is only 4 or 5 lines, because you end up with a dozen or so functions that get called once. I guess this is a problem of where the abstractions occur. We're gradually sorting out these abstractions, though doing it within the page hasn't been a visible priority yet.
The guy challenging us on this also cited readability and maintainability. Unfortunately, he's not been here very long and is making his opinions known quite strongly. I admit I have a problem with his "This is just so wrong!" approach... the phrase about flys, honey and vinegar springs to mind. :-)
Wade.
Is it enough to love
Is it enough to breathe
Somebody rip my heart out
And leave me here to bleed
| |
Is it enough to die
Somebody save my life
I'd rather be Anything but Ordinary
Please
| -- "Anything but Ordinary" by Avril Lavigne. |
|
Post #116,683
9/4/03 10:14:18 PM
|
Nothing wrong with 12 4-5 line functions
Just about right, I'd say.
Regards,
-scott anderson
"Welcome to Rivendell, Mr. Anderson..."
|
Post #116,698
9/4/03 11:47:55 PM
|
Typical size of a method in Smalltalk is probably 4-5 lines
Anything over 10 is generally considered huge.
Java is a joke, only it's not funny.
--Alan Lovejoy
|
Post #116,706
9/5/03 2:46:46 AM
|
Um. Yabut.
We are basically comparing nice OO technique (and environments) to a glorified templating language. OO is naturally going to be more distributed in its processing (think: 4 objects to achieve one process versus 4 objects within a single process). Given the PHP environment I'm not sure it's "better" to shoot for more modularity. Apples and oranges.
"There's a set of rules that anything that was in the world when you were born is normal and natural. Anything invented between when you were 15 and 35 is new and revolutionary and exciting, and you'll probably get a career in it. Anything invented after you're 35 is against the natural order of things." Douglas Adams
|
Post #116,832
9/5/03 10:57:35 PM
|
I was wondering how to say that. :-)
I've found that PHP doesn't immediately lend itself to creating multiple levels of abstraction. You have to build your own framework to do that. Unfortunately, it become obvious when you have a large enough project that it's a PITA to retrofit. Except you need it. :-/
I have to repeat here that there is still a lot of code and design in our application lying around from the very first PHP version. Every page still requires register globals enabled, for example! It would be great if we could fix all that, but time is horribly against us. PHP was a great choice in the beginning, but we are about to seriously begin looking at what to rewrite the thing in. PHP may be retained for the HTML generation, though I have my doubts.
Wade.
Is it enough to love
Is it enough to breathe
Somebody rip my heart out
And leave me here to bleed
| |
Is it enough to die
Somebody save my life
I'd rather be Anything but Ordinary
Please
| -- "Anything but Ordinary" by Avril Lavigne. |
|
Post #116,843
9/6/03 12:22:53 AM
|
I'm going for fairly strict layout/form/content separation
...which I do a poor job of describing here: [link|http://www.endue.org/endue/design/interfacelayer.htm#chunking|http://www.endue.org...ayer.htm#chunking] Basically, the .html files get as small as: <tr valign='top'>\n <td><nobr><select name='ContactType'>%(TypeOptions)s</select></nobr></td>\n <td><input type='text' name='ContactNum' value='%(Number)s' size='20' /></td>\n</tr> ...and a Python script uses an "assembler" class to interpolate values. Working very well so far. "There's a set of rules that anything that was in the world when you were born is normal and natural. Anything invented between when you were 15 and 35 is new and revolutionary and exciting, and you'll probably get a career in it. Anything invented after you're 35 is against the natural order of things." Douglas Adams
|
Post #117,725
9/13/03 1:14:42 PM
|
Do I smell another "OO is better abstraction" war brewing?
I've found that PHP doesn't immediately lend itself to creating multiple levels of abstraction.
"Abstraction" is a rather misused and/or subjective buzzword these days. Can you identify a specific fault of PHP? (Other than lack of named parameters and lack of function nesting?)
there is still a lot of code and design in our application lying around from the very first PHP version. Every page still requires register globals enabled, for example!
That is a fault of history, not the current language. How is rewriting your PHP for better session management an inferior solution to say moving to JSP or EJB? Java for web is anti-productivity bloat.
________________
oop.ismad.com
|
Post #117,727
9/13/03 2:17:15 PM
|
That is a fault of history OF the current language.
But I AM Napoleon!!!!! --Napoleon, in "Napoleon Bunny-Part", 1956 "There's a set of rules that anything that was in the world when you were born is normal and natural. Anything invented between when you were 15 and 35 is new and revolutionary and exciting, and you'll probably get a career in it. Anything invented after you're 35 is against the natural order of things." Douglas Adams
|
Post #117,765
9/14/03 1:49:36 AM
|
So you reject a language because
...they made a bad decision in the past which was later corrected?
________________
oop.ismad.com
|
Post #117,782
9/14/03 4:37:02 PM
|
Not at all.
So you reject a language because...they made a bad decision in the past which was later corrected? Nope. I'm not in the business of rejecting languages. But Wade seemed to imply that the "bad decisions" were exacerbated by the structure of PHP itself. In domains where I don't have direct analytical experience, I have to trust someone else's analysis; the world's too big to decide everything on my own from square one. I don't use PHP, but I have experienced similar environmental issues in my own life. Wade's description fits patterns I have observed; I trust his analysis and conclusions more often than yours as a rule. You want a more detailed discussion, you'd have to talk to Wade. "There's a set of rules that anything that was in the world when you were born is normal and natural. Anything invented between when you were 15 and 35 is new and revolutionary and exciting, and you'll probably get a career in it. Anything invented after you're 35 is against the natural order of things." Douglas Adams
|
Post #118,175
9/19/03 2:04:09 AM
|
not very nice wording, if you ask me
but I have experienced similar environmental issues in my own life. Wade's description fits patterns I have observed; I trust his analysis and conclusions more often than yours as a rule.
A more diplomatic way to say such may be something like, "His thinking style and experience seem to better match my own than yours".
My techniques work (at least if you think like I do). Tables are objectively more compact information-wise because they use context instead of localized attribute labels/methods to specify what an attribute is. And, I think most would agree that one can see more row-wise and column-wise patterns in attributes as a table than as a bunch of linearized class attributes or XML. I am simply applying these universal truths to software development. Plus, one can do relational algebra and other table-browser tricks on tables to customize your view of the attributes. You are not stuck with Bill Gates' or Gozling's view of the friggen code. TOP gives me the freedom to see bunches of attributes as *I* want to see them, filtered row-wise, column-wise, and join-wise how I want. I become the master of my working domain, not Gozling. It seems so obvious to me. Why most of you want that tangled, static, linearized, 60's navigational-DB-style mess, I have no friggen idea. You people have weird brains. I better clone myself 100 times before more OO and array heads reproduce and kill off the last table fans.
________________
oop.ismad.com
|
Post #118,181
9/19/03 2:42:37 AM
|
Then you might have guessed I wasn't trying to be diplomatic
|
Post #117,828
9/15/03 7:49:09 AM
|
Not unless you're spoiling for a fight.
Is it enough to love
Is it enough to breathe
Somebody rip my heart out
And leave me here to bleed
| |
Is it enough to die
Somebody save my life
I'd rather be Anything but Ordinary
Please
| -- "Anything but Ordinary" by Avril Lavigne. |
|
Post #118,176
9/19/03 2:07:43 AM
|
No, fighting the spOOilings
________________
oop.ismad.com
|
Post #117,868
9/15/03 2:52:16 PM
|
Hey Bryce...
...don't know if you keep up with such things but I did run across your name and a pointer to your website in a footnote on page 871 of the [link|http://www.oreilly.com/catalog/oraclep3/|PL/SQL Programming] book.
|
Post #118,174
9/19/03 1:42:59 AM
|
Perhaps
...don't know if you keep up with such things but I did run across your name and a pointer to your website in a footnote on page 871 of the PL/SQL Programming book.
I remember about 1.5 years ago some guy emailed me asking for permission to use my link in the citation section of his book. Perhaps this is the one. I assume it says something like, "For some possible criticism of OOP, see.....". Some university also wanted to cite my site in a published study of theirs, but wanted to know if I also had some published articles with similar content since websites alone were not acceptable to their publishers, they said.
My website is #4 under "OOP" in Google. Companies would pay zillions to be #4. You can attribute its "popularity" to its worthiness as content, or my shear persistence in spamming all the discussion boards :-) Take your pick.
________________
oop.ismad.com
|
Post #118,203
9/19/03 10:44:14 AM
|
I've read way too many Oracle books lately
The exact footnote is: * See "Object Oriented Programming Oversold!" by B. Jacobs, [link|http://www.geocities.com/tablizer/oopbad.htm|http://www.geocities...blizer/oopbad.htm] The longer context is as follows: [link|http://www.oreilly.com/catalog/oraclep3/|Pontifications]
I have to confess that I started programming before object approaches made any kind of inroads into business application development. I think I'm still waiting for that to happen.
Over the years, I've seen no compelling evidence that any particular programming style has a monopoly on the fundamental things we care about - fidelity to requirements, performance efficiency, developer effectiveness, and system reliability. I have seen a lot of fads, bandwagons, hand-waving, and unsupported assumptions (OK, I'm probably not entirely innocent myself), and object-oriented programming seems to attract quite a lot of it. That isn't to say that OOP fails to help you solve problems; it's just that OOP is not the magic bullet that many would have you believe.
Take, for example, the principle of object-based decomposition, particularly as it tends to generate inheritance hierarchies. By accurately modeling objects as they exist in the real world, software artifacts should be easier to comprehend, faster to assemble, and more amenable to large-scale system development. Sounds fabulous, doesn't it? Well, there are a lot of different ways to decompose something drawn from the real world.* It is a rare taxonomy that can exist in a simple hierarchy. My library catalog hierarchy could have been decomposed according to, say, media (print versus audio tape versus digital format....). And although Oracle provides wonderful tools for type evolution, it may still be so painful to make sweeping changes in a tyoe hierarchy that it will never happen. This isn't really the tool's fault; reality has a way of circumventing even the best-laid plans.
Nor is it clear that co-locating the programming logic (methods) with the data (attributes) in an abstract datatype yields any measurable benefits. It looks reasonable and makes for some great sound bites, but how exactly will coupling data and behavior be better than keeping data structures (logical and physical table design) seperate from processes (procedures, functions, packages)? Many development methods acknowledge that an organization's business data structures have a much slower rate of change than do the algorithms that manipulate them. It is a design truism (even for OOP) that the more volatile elements of a a system should be kept seperate from the more stable elements.
There is considerable inconsistency on this last point. Rich and famous object evangelists, while emphasizing the value of bundling data with behaviors, simultaneously promote a "model-view-controller" approach that "seperates business logic from data." Are these emperors wearing clothes or not?
Many OOP proponents have argued for years that its greatest benefit is the reuse of software. It has been said so many times that it must be true! Unfortunately, few observers have hard evidence for this, in part because there is no consensus on what constitutes "reuse". Even object apologists began promoting higher-level "components" (whatever those may be) as a preferred unit of reuse precisely because objects proved very difficult to fit into situations beyond those for which they were designed. My sense is that OOP results in no more code reuse than well-designed subroutines.
|
Post #118,298
9/20/03 12:38:50 AM
|
thanks for the quote
________________
oop.ismad.com
|
Post #116,598
9/4/03 2:24:13 PM
|
Re: Question about programming with functions.
Bringing the Linux kernel or any non-web development project into it is comparing apples to oranges.
The Linux kernel is particularly misleading because large parts of it are structured to maximize performance at the expense of everything else. When you are looking at OS level code that is called hundreds or thousands of times per second, every processor cycle counts. The primary limitation of a web application tends to be either the pipe or the database, not CPU usage.
This means that the primary concern for inline vs functional code should be one of readability and maintenance. My experience has been that inline code is better for simple pages. But once you reach a moderate level of complexity, function oriented code is better.
As long as your code contains few conditional lines then the inline code style is often easier to read because it puts everyting in front of you in order. But once you get a few conditional chunks of code in there, particularly ones that span HTML chunks, a functional design will be easier to follow.
Jay
|
Post #116,600
9/4/03 2:33:16 PM
|
Code as a Communications Tool
We had a contractor get fired at a prior job because he had a single function, that, when printed, stretched from the ceiling to the floor (9 ft high) and across a 10 ft deep cubicle. I counted over 20 pages, if I remember correctly.
His argument was that it was the "core processing" loop of the system, it did everything once, and that he didn't need to break out the code from the "case" statements.
Remember, code is as much about communicating between you and your peers as it is for the machine to execute. If you were creating the "best thing" for the machine, you would probably be writing in machine language now.
So, I would say that if a function gets much over 3-4 pages printed, it needs to be split out.
Also, I'm a "fewest lines of code possible" kind of guy. I believe in using meta-data, tables, etc. to write systems, and avoid millions of lines of code that have to be maintained. If done right, $18 an hour systems analyst can maintain configuration tables, using a GUI or something.
This approach allows me to get a lot done in a short amount of time, and most of the time, I can move on to other things and leave an admin/analyst to maintain the tables. I only have to get involved when some functionality can't be done with the existing system.
Glen Austin
|
Post #116,828
9/5/03 10:24:10 PM
|
Code for readability
Megadittos.
What he said, etc.
My 2 cents:
I have an AWFUL habit of doing a large loop to start off with,
because I would think the code was "throw-away". But I throw away
NOTHING!
So I typically have a rule that if I have to page down more than once,
ie: about 50 lines, it has crossed the threshhold of "stateful"
information that I can hold in my head. I will then attempt to
isolate and construct functions to be called.
There are some things that I construct as functions on
auto-pilot. Like reading in specialized control information,
etc.
I pretend that I an a performance focused programmer. After all,
the files I deal with are very large and I am very impatient.
Yet I code in Perl, so I KNOW I've made the trade-off between
execution speed and programmer productivity.
So I will code for my 2 screen limit, and then benchmark.
Speed usually comes from such a small part of the code
being optimized that it does not make sense to go through
the effort of optimizing everything.
|
Post #116,830
9/5/03 10:51:02 PM
|
Profiling and optimizing.
I tend to optimize the algorithms... :-) For instance, one of our pages some months ago was coded to put a huge amount of data into a PHP session variable. I changed the algorithm so that it stores a list of numbers instead. Made a palpable difference.
Your comment reminds me of a dicussion on Linux Kernel some months back where ESR tried to warn Linus about the genius programmer problem. I know my colleagues and I are good programmers, so perhaps we're susceptible to that kind of problem, too.
Wade.
Is it enough to love
Is it enough to breathe
Somebody rip my heart out
And leave me here to bleed
| |
Is it enough to die
Somebody save my life
I'd rather be Anything but Ordinary
Please
| -- "Anything but Ordinary" by Avril Lavigne. |
|
Post #116,876
9/6/03 11:42:37 AM
|
Difficult to optimize the algorithm after the fact
unless you isolate the various function points as functions. Then you
can plug in new algorithms and test without fear of breaking
things.
|
Post #116,957
9/7/03 2:46:59 AM
|
Yes, I know.
The page I mentioned has had two almost complete re-writes. :-)
Wade.
Is it enough to love
Is it enough to breathe
Somebody rip my heart out
And leave me here to bleed
| |
Is it enough to die
Somebody save my life
I'd rather be Anything but Ordinary
Please
| -- "Anything but Ordinary" by Avril Lavigne. |
|
