Don't guess, measure!

Post #45,241 by neelk 7/11/02 9:10:14 PM Reply	Don't guess, measure! Look at your programs and count the number of times you use higher-order functions. I just looked at the code I wrote today in Ocaml. There's about 450 lines of code, in 29 functions.[] 20 of those 29 use higher-order functions (ie, functions as values) in some way. 15 of the 20 that use higher-order functions explicitly construct closures. The other 5 simply take functions as arguments. That's way* more than 2-5%. One of the reasons the percentage is so high is because I tend to use folds (like `map` or `reduce` in Python) instead of explicit recursion or looping. Eliminating explicit loops means I can't get the pattern of iteration wrong -- which makes a whole class of bugs impossible. Anyway, I think Paul Graham is wrong about the usefullness of OO. But when you write the language, you get to decide what goes in it. That's why I'm writing my own language instead of complaining about Arc. :) [*] Yeah, I know I should refactor -- 15 lines/function is on the high side. But this is pure throwaway exploratory code. Once I figure out how to do it at all, I'll make the code good.
Post #45,326 by tablizer 7/12/02 4:14:05 PM Reply	Simplify (* Eliminating explicit loops means I can't get the pattern of iteration wrong -- which makes a whole class of bugs impossible. *) Yes, but messing up loops may only be a small portion of total errors. Good API designs can reduce loop complexity. For example, looping thru a DB result set (or cursor) can be as simple as: rs = openRS([criteria]) while getNext(rs) { [loop contents] } What is there to screw up here? Again, I am not hellbent against closures, but I think they are overrated. They confuse newbies and complicate the language, adding only a marginal improvement. If you have a "killer example" of closures doing something realistic far better than traditional approaches, I would like to see it. (Perhaps one could argue that closures help clean up or wrap bad API's.) ________________ oop.ismad.com
Post #45,381 by neelk 7/12/02 8:19:18 PM Reply	Re: Simplify You wrote: > Good API designs can reduce loop complexity. For example, looping thru a > DB result set (or cursor) can be as simple as: > > rs = openRS([criteria]) > while getNext(rs) { > [loop contents] > } > > What is there to screw up here? For one thing, you haven't closed the cursor. :) This is a perfect example of why abstracting common patterns of iteration into a higher-level API is a good idea. Namely, you need to get the fold function correct once, and then every future use of it will be correct. In this case, if you had an iteration function available you would not have accidentally created a resource leak. People -- all people -- are bad at repetition and detail work. If we have to repeat even a trivial task, then we will screw it up. For a simple example, try quickly counting from 1 to 300 out loud without screwing up. I just tried it, and got up to 114 before stumbling over my words. Now consider that this task is much easier than writing even the simplest computer program. This is why I am so hell-bent on abstracting the common patterns in my code. I know that I suck at detail work. Closures are a good thing because they let me build my program out of tested, interchangeable parts.
Post #45,428 by ben_tilly 7/13/02 12:43:23 AM Reply	Depends on the language In many languages, when the database handle goes out of scope, it closes the cursor for you and cleans up. No leak. OTOH when you get used to that and then need to work in an environment that doesn't have it, the adjustment is painful. I am even worse at detail work I have gotten out of the habit of doing... :-/ Cheers, Ben "... I couldn't see how anyone could be educated by this self-propagating system in which people pass exams, teach others to pass exams, but nobody knows anything." --Richard Feynman
Post #45,584 by static 7/15/02 12:01:18 AM Reply	This is why I prefer PHP to C... :-) "Ah. One of the difficult questions."

Welcome to IWETHEY!