6 ms·
The examples are 40% and 20% longer. That is significant. The trouble with small examples is that their problems don't seem like a big deal because their entir
by gruseom 13y ago
The examples are 40% and 20% longer. That is significant.
The trouble with small examples is that their problems don't seem like a big deal because their entire codebase isn't a big deal. You have to apply them many times over to get any sense of their compounding effect, which is what really matters. But by definition, that's out of scope of a discussion whose examples are small. The only way out of this paradox is to pay close attention to apparently small effects.
- mattmanser 13y agoOne of the things that really annoys me about modern JavaScript programmers is that they seem to have forgotten the basics. Functions are good. Short methods are good. Reusability is good. Properly naming your functions is good. Separation of concerns is good. Complaining about a couple of extra carriage returns and a few extra characters to properly name the method is insanity.
- andreypopp 13y agoThe problem with callbacks is they are not about reusability — they force you to organise your code around I/O and not around your app logic... hence the names like wtfFriendAction.
- Skinney 13y agoThere is a difference between callbacks and lambdas. Nothing forces you to provide a lambda as a callback. If that lambda will only ever be used once, then it's ok as long as it's short and easy to understand what it does. If that function is required multiple places, you make a proper function out of it, and pass that function instead of a lambda. Callbacks allow for abstractions like map, filter, reduce... Used properly, they can actually increase reusability instead of prohibiting it.
- andreypopp 13y agoIt's like you didn't read my comment — how functions like wtfFriendAction help reusability?
- Skinney 13y agoIn this small example it doesn't, getFriendsById however, does. I would imagine that wtfFriendAction could be used multiple places though. wtfFriendAction is additionally a very, very poor name. It should be called "addFriendToFriendList" or something. Another thing is that the author himself states that the function doesn't actually makes sence, hence the ugly name.
- deleted 13y ago[deleted]
- andreypopp 13y ago> Another thing is that the author himself states that the function doesn't actually makes sence, hence the ugly name. That's the point — using callbacks you end up with functions which do not make sense... Edit: spelling
- gruseom 13y agoHow many functions are good? If I add a dozen, is that better? Short methods are good—have any evidence for that? I don't think you do, because such evidence as there is points in the opposite direction (look it up in Code Complete). It's proper to name functions properly? I agree! What's "properly"? Hammering these dogmas harder doesn't make them any truer, it just creates a feeling that you know what you're doing in a "If the English language was good enough for Jesus Christ then it's good enough for the state of Texas" kind of way. We have almost no empirically verified knowledge about software development. One of the few things we do know (sort of—the studies are old and shaky) is that code size is a predictor of error rates. Think that's relevant?
- Skinney 13y agoShort methods/functions are good in that they do very little and thus are easier to read and grasp than a function spanning 50-100 or more lines. Short methods/functions are also easier to name properly. As Clojure, F#, Haskell and friends show, it's better to have 100 functions working on one datastructure, then having ten functions for ten datastructures.
- cousin_it 13y agogruseom's comment raised the bar for evidence in this discussion, and gave some examples of evidence. "As Clojure, F#, Haskell and friends show" - can you point to a study? Relevant link: http://www.slideshare.net/gvwilson/bits-of-evidence-2338367 http://www.slideshare.net/gvwilson/bits-of-evidence-2338367