Post #107,036
6/23/03 4:18:57 PM
|
bottom bread
is a surprising RAM-centric suggestion from the Tablizer.
Note that often I read stuff into a table(s), and then process it further. If I did a lot of that, I might do something like:
fileToTable(fileName, tableName, errorTable)
Further, many apps *do* work with small enough files to load into RAM for processing. You could argue that since it limits the size, it is less general purpose. However, the flip side is that one can do random access on RAM copies. Files don't guarentee random access. Thus, we are perhaps trading one limitation for another.
So it looks like all the standard libraries probably meet the stated 5% criteria.
For one, you appeared to assume that every block would need to have a closing portion (a "bottom bread") if closures were not used. That may not be the case. The number of blocks may also vary widely depending on programming style and language.
Further, lines of code is not the ideal metric for code density IMO. Some lines are long, and others are short. Closing things tends to be short lines. Plus, they have the added benefit of being more descriptive than "}". It explicitly ignores the problems of exceptions thrown in the process_file.
We don't need blocks to handle exceptions. But, that is another topic.
________________ oop.ismad.com
|
Post #107,709
6/28/03 3:38:35 PM
6/28/03 3:40:27 PM
|
Still waiting for examples
Hi! I'm back. I had a great week (thanks for asking). Back to the fray...
Tablizer: [comments on RAM-centric issues]
Absolutely irrelevent issues. I think we can agree that any solution that requires the file to be read completely into memory is a less general solution than one that does not.
Tablizer: We don't need blocks to handle exceptions.
Never said they were required. However, any correct solution must ensure that the file is closed, even in the presense of exceptions. Several of your examples did not do that.
(edit: changed title) Tablizer: [numerical calculations assume complex bottom bread]
No such assumption was made. The only assumption was that an the example of a three line savings was typical. Even if the savings were only 2 lines of code, both site libraries would still meet that criteria. Given that you only ask for roughly 5 percent, and these are very rough measurements, the evidence certainly meets your criteria.
Just to be clear, your 5% criteria is completely vague and hard to realisitically measure. I'm not convinced that it is even a good criteria. All I'm claiming is that by one simple-minded measurement with some "back of the envelope" assumptions puts us in the ballpark range of your stated goal. This is just to demonstrate to you that closures really are used much more often than you would expect (far more than "eval" statements ... in fact, I'm not sure a "eval" statement would meet your criteria). If these numbers are not enough to convince you we're in the ballpark, just say so and we will continue with the understanding that the "5%" criteria is an impossible test that was never meant to be meet.
Just so we don't get too far adrift, here is your original statement.
Tablizer: I have yet to see a good case of where closures reduced the code complexity by more than roughly 5 percent. Every example I have seen had a simpler non-closure alternative that was better than the non-closure example that the closure pusher used to compare.
Just to recap: I'm still waiting for a non-closure example that is simpler (e.g. less code), and is better (e.g. has to work, does not introduce arbitrary restrictions).
(edit: Changed subject line)
-- -- 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)
Edited by JimWeirich
June 28, 2003, 03:40:27 PM EDT
|
Post #107,719
6/28/03 4:56:33 PM
6/28/03 4:58:06 PM
|
misunderstanding?
[comments on RAM-centric issues] Absolutely irrelevent issues. I think we can agree that any solution that requires the file to be read completely into memory is a less general solution than one that does not.
Well, that is probably debatable because forward-only reading is not "general purpose", but I will give that one to you for now because it smells like a long and winding debate.
However, any correct solution must ensure that the file is closed, even in the presense of exceptions. Several of your examples did not do that.
We are talking code complexity, not enforcing the bottom bread. An approach that requires the developer to explicitly issue a "bottom bread" command is not "wrong", just less automatic. Besides I already listed multiple non-closure solutions to auto-closing. I don't remember making any claims about them being equally automatic.
Just to recap: I'm still waiting for a non-closure example that is simpler (e.g. less code), and is better
I think you misread my statement. I was comparing NON-closure example A to NON-closure example B. (For those of you who often complain about my grammar, I am curious as to how you would reword it.)
Oh, BTW, how was your vacation (or trip away)? Go smoothly?
________________ oop.ismad.com
Edited by tablizer
June 28, 2003, 04:58:06 PM EDT
|
Post #107,726
6/28/03 7:15:40 PM
|
misunderstanding? ... Now I'm Confused
I'm going to skip the "forward-only" comments and the "less-automatic" comments to get the this surprizing claim.
Tablizer: [...] I think you misread my statement. I was comparing NON-closure example A to NON-closure example B.
Wow. I re-read your original statement and see that you are absolutely correct. You didn't claim that your solutions were better than the closure versions. You only claimed they were better that the original non-closure example.
Does this mean that you agree that the closure versions are better than your "improved" versions?
Addressing your much weaker claim, I am not convinced that you have made your cause even there. To refresh your memory, in your examples
[1] was limited to "in-memory" applications [2] didn't properly handle exceptions [3] didn't properly handle exceptions and didn't work with all algorithms [4] depended upon memory management implementation details to ensure correct behavior.
In what ways are any of your examples "better" than the original code?
Tablizer: Oh, BTW, how was your vacation (or trip away)? Go smoothly?
My wife and I took our church youth group (6 teenagers) to a CIY conference ([link|http://www.ciy.com/Library/SiteBuilder.aspx/82|http://www.ciy.com/L...teBuilder.aspx/82]). It was a very refreshing time.
-- -- 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 #107,737
6/28/03 8:45:24 PM
|
long blocks
Although I could possibly take exception to "didn't properly handle exceptions" (pun), because you seem to define "proper" to fit your coding preferences, and some of the others, but the bottom line is that I just don't see closures a significant improvement over code I deal with.
For one, I don't like wide-reaching blocks. That is an anti-pattern IMO. I would rather see a CloseFoo command rather than an lonely little "}" sitting far from its parents and deepening the nesting. It is better "self documentation" IMO because I know where the range ends and I know WHAT is ending. "}" is too bland. Most of my close's are at the end of the routine, I would note. The "ideal" auto-end-bread is situational. One possibility is to have it automatically close at the end of the routine if not done explicitly, but you seemed bothered by this for some reason. (Perhaps because existing languages don't support it well?). I just don't see the big deal about closures. I don't. Their benefits seem rather minor. Again, I see no reason to move them to the top of my wishlist and it appears that enough others agree because mainstream languages keep omitting them (or at least downplaying them). They have the reputation for being mental masturbation, and part of that *is* deserved IMO.
________________ oop.ismad.com
|
Post #107,758
6/29/03 2:14:36 AM
|
Back to the Example ...
Tablizer: Although I could possibly take exception to "didn't properly handle exceptions" (pun), because you seem to define "proper" to fit your coding preferences, [...]
You make it sound arbitary. It is not. In the example code, if an exception thrown during the processing of the file, the file is still properly closed. This is not the case is several of your examples.
So, if it is a "coding preference" to write exception safe code, then so be it.
As for the rest (long blocks, personal preferences, reputation jab), they are side issues; and I won't address them at this time.
The main point is back to your claim of closure advocates providing "lame" non-closure examples. I don't expect to convince you that closures are the coolest thing since sliced bread. I just wanted to make sure you saw a non-lame example.
Can we agree that this is such an example?
-- -- 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 #107,786
6/29/03 1:03:49 PM
|
auto-close
if an exception thrown during the processing of the file, the file is still properly closed. This is not the case is several of your examples.
I don't quite know how they do it (probably destructor-like mechanisms[1]), but in some languages (or OS's), files and DB connections are automatically closed when the EXE or script ends. Thus, if we terminate the execution based on an error, those things are closed automatically.
Maybe languages and tools that you use behave differently. I only call the shots based on my experience. If I don't see something causing problems, I don't focus on looking for language techniques to manage problems that are not there. Something has been spoiling me perhaps......and I like it :-)
[1] Destructors are not limited to OO
________________ oop.ismad.com
|
Post #107,791
6/29/03 3:37:50 PM
|
Exceptions
Tablizer: I don't quite know how they do it (probably destructor-like mechanisms[1]), but in some languages (or OS's), files and DB connections are automatically closed when the EXE or script ends. Thus, if we terminate the execution based on an error, those things are closed automatically.
From your comments, it seems that you are not familiar with the behavior of exceptions. Exceptions (generally) don't terminate the program, so depending on the OS to do your cleanup is pointless. It would also explain why your examples ignored exception safety.
I suppose now we can enter a discussion on exceptions and if they are needed for custom biz apps and if they can provide a roughly 5% overall decrease in complexity.
Or not.
Our last conversation on closures broke down on understanding synchronization issues and I don't want to repeat that here with exceptions. So I'm willing to drop the issue.
Perhaps you need to modify your claim to include the phrase "they present a lame non-closure version that depends upon advanced programming techniques (such as exceptions) to compare to".
-- -- 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 #107,803
6/29/03 10:03:31 PM
|
Warning: Discussing exceptions with me is a loooong topic
________________ oop.ismad.com
|