Explicit vs. Clever(raganwald.com)
raganwald.com
Explicit vs. Clever
http://raganwald.com/2013/04/02/explicit-versus-clever.html
103 comments
I remember when I would've agreed with you that your version is easier to understand and better, but now I don't.
I think it's javascript's fault. If you were working on a lisp codebase (suspend your disbelief for a second for me, please), you might see something like:
If you were working in Java and saw
The argument you guys are having arises because some people think of javascript as a dynamic sort of java with lots of weird stuff thrown in, and some people, ragenwald included, think of it as a lisp in a java costume. I don't think either view is entirely correct, but both are reasonable and you can write your javascript either way.
When it comes to "clever" vs "explicit", I'd say it comes down to the opinions of all the people who have to maintain your code: are they expecting lisp or java?
I think it's javascript's fault. If you were working on a lisp codebase (suspend your disbelief for a second for me, please), you might see something like:
((splat (get 'title')) orders)
If you were working in Java and saw
int totals[] = splat(get("title")).call(orders);
The argument you guys are having arises because some people think of javascript as a dynamic sort of java with lots of weird stuff thrown in, and some people, ragenwald included, think of it as a lisp in a java costume. I don't think either view is entirely correct, but both are reasonable and you can write your javascript either way.
When it comes to "clever" vs "explicit", I'd say it comes down to the opinions of all the people who have to maintain your code: are they expecting lisp or java?
Clojure maps generally have keywords as keys and keywords are callable as getters:
(map :title orders)
(map #(get % :title) orders)
(map (fn [order] (get order :title)) orders)Can I upvote you twice?
More than once I have found about a new technique in language A and thought: "Wow, this is clever". Then sometime later I learnt language B where that technique is not only common place, but has some nice syntax sugar and is used throughout the whole standard library. And that makes a huge difference in the perceived cleverness of the code.
More than once I have found about a new technique in language A and thought: "Wow, this is clever". Then sometime later I learnt language B where that technique is not only common place, but has some nice syntax sugar and is used throughout the whole standard library. And that makes a huge difference in the perceived cleverness of the code.
I remember this exact argument when Ruby first became popular and the PickAxe book was telling people how to write .each and .map instead of loops.
Come to think of it, I remember this exact argument when SmallTalk was introduced.
My elders probably remember having this argument when discussing LISP vs. Fortran.
I'm not sure what I can tell you that hasn't already been said in the sixty years that programmers have been having the whole "It's easier to understand when you're directly manipulating the metal" argument.
Come to think of it, I remember this exact argument when SmallTalk was introduced.
My elders probably remember having this argument when discussing LISP vs. Fortran.
I'm not sure what I can tell you that hasn't already been said in the sixty years that programmers have been having the whole "It's easier to understand when you're directly manipulating the metal" argument.
If you're sick of having the argument, then why did you troll it? :)
I mean, I'm perfectly willing to be your imperative curmudgeon strawman if you really want. But honestly, if you're going to blog about the spectrum of "explicit" programming, you're sort of morally bound to accept arguments on sides of the spectrum you'd rather not talk about.
I mean, I'm perfectly willing to be your imperative curmudgeon strawman if you really want. But honestly, if you're going to blog about the spectrum of "explicit" programming, you're sort of morally bound to accept arguments on sides of the spectrum you'd rather not talk about.
If you want that argument, let's start with the fact that I can make Raganwald's version work, unchanged, with the data structure changed to be the values of a hash, the keys of a hash, a tree data structure, and a streamed data set that you do not entirely possess at any single time. Your version requires it to be an array, and nothing else. You may retort that it almost always is an array. My experience in languages that support the abstraction disagrees with you.
Secondly with your version I find that I require significantly more typing, and get it wrong significantly more wrong simply because I had a trivial typo.
Thirdly with your version on a double loop I find myself periodically messing up because I slip in the wrong counter variable in the wrong place. Stupid error, but the code compiles and does the wrong thing, then I have to track it down. With the functional version I pretty much never make that mistake on that use case.
And finally my experience, with my background, says that it is easier to fix mistakes in the functional version than the explicit one.
The result is that separating the concept of iteration from the implementation is a good thing. Even C++ realized this fact (badly) with iterators.
Secondly with your version I find that I require significantly more typing, and get it wrong significantly more wrong simply because I had a trivial typo.
Thirdly with your version on a double loop I find myself periodically messing up because I slip in the wrong counter variable in the wrong place. Stupid error, but the code compiles and does the wrong thing, then I have to track it down. With the functional version I pretty much never make that mistake on that use case.
And finally my experience, with my background, says that it is easier to fix mistakes in the functional version than the explicit one.
The result is that separating the concept of iteration from the implementation is a good thing. Even C++ realized this fact (badly) with iterators.
> Even C++ realized this fact (badly) with iterators.
would you mind clarifying that a bit (or a bunch) ? afaik, STL cleanly separates the notion of structures and algorithms that operate on those structures via iterators.
thanks !
would you mind clarifying that a bit (or a bunch) ? afaik, STL cleanly separates the notion of structures and algorithms that operate on those structures via iterators.
thanks !
I'm not the grandparent poster, but one classic problem with STL iterators is that they always have to come in pairs. If you think about it, most STL algorithms don't really work on iterators, they work on ranges that happen to be defined by pairs of iterators. That makes it hard to compose operations, makes it hard to work with infinite streams, and makes it possible to screw up and write something like std::transform(v1.begin(), v2.end()).
Have a look at Alexandrescu's work on ranges in D for a more modern exploration of the same concept.
Have a look at Alexandrescu's work on ranges in D for a more modern exploration of the same concept.
[deleted]
What is wrong with STL iterators? To see the shortcomings, let's dream up a better one and then compare.
Our hypothetical interface to iterators will have the following methods:
bool not_done(); // Is the iterator done?
void next(); // Move to the next value. Throws exception if done.
Foo value(); // What value do we have? Throws exception if done.
Our data structures will support the method iterator() that is the moral equivalent of begin().
We already have the equivalent of STL iterators. You just change:
for (data_structure::iterator it = foo.begin(); it != foo.end(); ++it) { /* do stuff with it / }
to
for (iterator< fooish > it = foo.iterator(); it.not_done(); it.next()) { /* do stuff with it.value() */ }
So far uninteresting. But with this new interface we can add four interesting templates in a straightforward matter.
1. Take an iterator< fooish > and a function that maps things of type fooish to type barish, then produce an iterator< barish >.
2. Take an iterator< fooish >, and a function that maps fooish to bool, then produces an iterator that gives you just the ones that mapped to true.
3. (Generalization of the first two.) Take an iterator that produces things of type fooish, and a function that maps fooish to iterator< barish >, and returns an iterator< barish > that just maps each value from the first to all of the bars that it produces.
4. Take an object with a method that produces things of type fooish, and produce an iterator< fooish >.
These are all simple to define given this interface. What do they allow us to do? Well the article that introduced me to the idea of iterators was http://perl.plover.com/Stream/stream.html - absolutely everything in that article is straightforward with the interface that I described and absolutely none of it is easy with STL iterators. (It is all still actually possible, but tricky. Proving that fact is left as an exercise to the reader, at which point you'll know why people don't tend to think about problems that way in C++.)
Our hypothetical interface to iterators will have the following methods:
bool not_done(); // Is the iterator done?
void next(); // Move to the next value. Throws exception if done.
Foo value(); // What value do we have? Throws exception if done.
Our data structures will support the method iterator() that is the moral equivalent of begin().
We already have the equivalent of STL iterators. You just change:
for (data_structure::iterator it = foo.begin(); it != foo.end(); ++it) { /* do stuff with it / }
to
for (iterator< fooish > it = foo.iterator(); it.not_done(); it.next()) { /* do stuff with it.value() */ }
So far uninteresting. But with this new interface we can add four interesting templates in a straightforward matter.
1. Take an iterator< fooish > and a function that maps things of type fooish to type barish, then produce an iterator< barish >.
2. Take an iterator< fooish >, and a function that maps fooish to bool, then produces an iterator that gives you just the ones that mapped to true.
3. (Generalization of the first two.) Take an iterator that produces things of type fooish, and a function that maps fooish to iterator< barish >, and returns an iterator< barish > that just maps each value from the first to all of the bars that it produces.
4. Take an object with a method that produces things of type fooish, and produce an iterator< fooish >.
These are all simple to define given this interface. What do they allow us to do? Well the article that introduced me to the idea of iterators was http://perl.plover.com/Stream/stream.html - absolutely everything in that article is straightforward with the interface that I described and absolutely none of it is easy with STL iterators. (It is all still actually possible, but tricky. Proving that fact is left as an exercise to the reader, at which point you'll know why people don't tend to think about problems that way in C++.)
1. I'm not sick of it, I just can't tell you anything you haven't already heard and rejected.
2. I'm not trolling, just pointing out that this has been going on for a while, which implies that there are reasonable people on both sides of the discussion.
3. I never argued that explicit is bad or that jargon is good, I just explained that sometimes, jargon accomplishes a purpose.
4. I have written for loops and liked them.
So, 5. Don't assume enmity where there is none.
2. I'm not trolling, just pointing out that this has been going on for a while, which implies that there are reasonable people on both sides of the discussion.
3. I never argued that explicit is bad or that jargon is good, I just explained that sometimes, jargon accomplishes a purpose.
4. I have written for loops and liked them.
So, 5. Don't assume enmity where there is none.
Thank you for this. I didn't see your article as trolling.
You articulate a very valid point - The degree of perceived "cleverness" in code is dependent on the reader's level of familiarity of the language's basic and advanced concepts.
Your example really highlights this.
You articulate a very valid point - The degree of perceived "cleverness" in code is dependent on the reader's level of familiarity of the language's basic and advanced concepts.
Your example really highlights this.
The code suggested by ajross seems more readable not just because it's closer to the metal, but also because reading it doesn't require memorizing many ad-hoc names like "splat" and "pluck", you just apply a few logical rules that you learned once. But there's no reason why code written with advanced abstractions couldn't be "locally readable" in the same way...
The problem is that you have to run the code in your head to understand what it means. It obfuscates the intent. Just read it aloud and you'll see what I mean,
"Once upon a time there was a variable named, totals that was initialized to an empty array. Next, a for loop happened and some var, i appeared (his name doesn't really matter.) i was initialized to 0. Enter stage right, totals's buddy, orders. orders has a property named length. i was told that it shall be incremented by 1 so long as i was less than order's length property. Sadly, the for loop was just using i. i didn't know it would be disregarded once for loop was finished.
Not surprisingly, what happened next was quite remarkable. The total property of orders index i lept onto totals. i was incremented. Then the total property at index i lept onto totals... i was incremented... Finally i was greater than or equal to orders.length, so the for loop ended. totals lived on, changed by its journey while i was never seen or heard from again.
Study guide question: how did totals's character change by the end of the story and what did this mean?" "
The following code snippet means the same thing, but it's also self-documenting. Plus there's less accidental complexity:
"Once upon a time, there was a var named, totals. It was a list of order totals. Fin."
"Once upon a time there was a variable named, totals that was initialized to an empty array. Next, a for loop happened and some var, i appeared (his name doesn't really matter.) i was initialized to 0. Enter stage right, totals's buddy, orders. orders has a property named length. i was told that it shall be incremented by 1 so long as i was less than order's length property. Sadly, the for loop was just using i. i didn't know it would be disregarded once for loop was finished.
Not surprisingly, what happened next was quite remarkable. The total property of orders index i lept onto totals. i was incremented. Then the total property at index i lept onto totals... i was incremented... Finally i was greater than or equal to orders.length, so the for loop ended. totals lived on, changed by its journey while i was never seen or heard from again.
Study guide question: how did totals's character change by the end of the story and what did this mean?" "
The following code snippet means the same thing, but it's also self-documenting. Plus there's less accidental complexity:
var totals = orders.map(function(order){
return order.total;
});
"Once upon a time, there was a var named, totals. It was a list of order totals. Fin."
I think the argument is that:
> It was a list of order totals.
You can only say this knowing (basically):
> map is a function which, for each item in a list, in order, executes a function on that item and populates a new list with the returned value of that function.
(I'm sure that description is technically wrong or misstated on some level.)
And that goes back to the original post. map is jargon, meaning basically what I posted above. If you don't know the jargon, it looks a lot like obfuscating cleverness.
> It was a list of order totals.
You can only say this knowing (basically):
> map is a function which, for each item in a list, in order, executes a function on that item and populates a new list with the returned value of that function.
(I'm sure that description is technically wrong or misstated on some level.)
And that goes back to the original post. map is jargon, meaning basically what I posted above. If you don't know the jargon, it looks a lot like obfuscating cleverness.
Your example is great, but it would be even more convincing if it used list comprehension syntax such as
totals = [order.total for order in orders]
(like some other poster in this thread did)
Then you don't even need to know what "map" means, you only need to know "for" (well, maybe you would need an insight that "order" is defined after its use, but I digress)
totals = [order.total for order in orders]
(like some other poster in this thread did)
Then you don't even need to know what "map" means, you only need to know "for" (well, maybe you would need an insight that "order" is defined after its use, but I digress)
One of the nice things about Python is that it has syntactic sugar for this. I find
[order.total for order in orders]
map (^.total) ordersAre we having a code example party? I like Clojure:
(map :total orders)Frankly, I would like to have more code example parties.
Too often, differences between programming languages are treated as strictly philosophical arguments. Comparing and contrasting actual code is far more interesting, in my opinion.
Too often, differences between programming languages are treated as strictly philosophical arguments. Comparing and contrasting actual code is far more interesting, in my opinion.
I'm partial to
select total from orders
(defmacro select [total _ coll]
(let [total (keyword total)]
`(map ~total ~coll)))
(select total from orders)
Nice.
Here are some interesting non-macro variants, first in Rebol:
Here are some interesting non-macro variants, first in Rebol:
select: func [block] [
totals: []
parse block [
set this word!
'from
set coll word!
(totals: map-each n (get coll) [get in n this])
]
totals
]
; then later...
select [total from orders]
;; nb. `select` is a core function provided by Rebol
;; so remember this example overwrites that
;; (in this scope/context) :)
;;
;; Alternative `dialect` to strive for would be..
;;
;; doMap [select total from orders]
select := method(
msg := call argAt(0)
this := msg name
coll := msg next next name
newMsg := message(COLL map) // COLL just a placeholder message
newMsg setName(coll) // Now been changed to correct var provided
newMsg next appendArg(this asMessage)
call sender doMessage(newMsg)
)
# then later...
select(total from orders)
There's a GHC (Haskell) extension which lets you use list comprehensions which read like SQL: http://www.haskell.org/ghc/docs/7.2.1/html/users_guide/synta...
I agree, but I think that `map` is already a declarative interface (albeit to an implementation that is presumably functional).
Party time with Ruby:
More detail: http://stackoverflow.com/a/1217114/3528
orders.map(&:total)
More detail: http://stackoverflow.com/a/1217114/3528
Yeah you're welcome to bring Clojure to my party. I've never met him/her before but he/she looks like other languages I get on well with.
These are also nice and would like to join in the party :)
map *.total, @orders; # perl6
@orders.map: *.total; # perl6 OO
map {$_->total} @orders; # perl5
orders map(total) # Io
map-each n orders [n/total] ; RebolNo need to go that far, CoffeeScript can do both:
totals = (order.total for order in orders)
totals = orders.map (o) -> o.totalThe c# syntax, myNewList = (from i in myList where i > 3 && i != 7 select i * 4).toList(), is nice too. Similar to using LINQ, myList.Where(i => i > 3), but I don't believe that form allows an easy use of the i * 4 part. One annoyance I have with .NET is there are too many types that are similar-but-not-quite a List<>, making me do conversions often. At least it's usually not much more than a .ToList(), except in the case of the controls in a Windows Form, which are their own weird list-type structure that doesn't support that.
For older .Net collections you can use Cast<T>() to get LINQ goodness. Something like this would work:
var values = from x in combobox.Items.Cast<ComboBoxItem>() where x.Value > 5 select x.Value;That's like saying that using "malloc" and "free" will allow you to fix your memory management bugs faster than using "new" in Java.
No, it's not like that at all.
[deleted]
I completely understand your example, and don't really follow RW's example.
Thank you for clarifying.
Thank you for clarifying.
It's all dependent on what you are familiar and comfortable with. You, apparently, are familiar with and feel comfortable using C style for loops over collections to sum an attribute. In Perl I would write your example as:
What we are really doing, is mapping a concept to the language. The concept in this case can be expressed in a few ways, but I would express it as:
The key point is the environment. If I'm programming in perl, I expect others that will add or modify my code to be familiar with perl. If I'm also using Mojolicious, I expect others that are tasked to work on that code to be familiar with Mojolicious as well, or at least willing to look up resources to try to figure it out. In short, I expect familiarity with the chosen tools. If that's not a valid assumption, then those tools should not be in use.
Similarly, I don't feel the need to dumb down my vocabulary or concepts for HN, but I might for a different audience.
my @totals = map { $_->{total} } @orders;
What we are really doing, is mapping a concept to the language. The concept in this case can be expressed in a few ways, but I would express it as:
Collect the total for each order.
The key point is the environment. If I'm programming in perl, I expect others that will add or modify my code to be familiar with perl. If I'm also using Mojolicious, I expect others that are tasked to work on that code to be familiar with Mojolicious as well, or at least willing to look up resources to try to figure it out. In short, I expect familiarity with the chosen tools. If that's not a valid assumption, then those tools should not be in use.
Similarly, I don't feel the need to dumb down my vocabulary or concepts for HN, but I might for a different audience.
The problem with loops in javascript is that, once you start doing more complicated things than accessing array indices, you run the risk of introducing bugs that don't exist when using a more functional style.
Once you're using closures in your for-loop to prevent everything referring to the last index in the array, you might as well be using map and reduce and all that. Otherwise you end up wasting a lot of time to come up with stuff roughly like this:
Once you're using closures in your for-loop to prevent everything referring to the last index in the array, you might as well be using map and reduce and all that. Otherwise you end up wasting a lot of time to come up with stuff roughly like this:
(function(order) {
// do something
})(orders[i])... and also get introduced faster?
Code needs to read like good copywriting: obvious to the reader as if they were the author. Good copywriting needs to be aware of the target audience and the idioms they use.
Abstractions and jargon come along with the audience. It's critical to write for your target audience.
If you work with people who think computers are proof verifiers, splat is probably best for you. Then again, you should probably be writing it in Haskell/Fay/ML/...
If you work with people who think computers are shufflers of bits, then maybe a for loop is best.
And if you work with people who think computers are consumers of over-specified utility libraries, perhaps there's a iterator subclass implementation to be made.
Abstractions and jargon come along with the audience. It's critical to write for your target audience.
If you work with people who think computers are proof verifiers, splat is probably best for you. Then again, you should probably be writing it in Haskell/Fay/ML/...
If you work with people who think computers are shufflers of bits, then maybe a for loop is best.
And if you work with people who think computers are consumers of over-specified utility libraries, perhaps there's a iterator subclass implementation to be made.
> Code needs to read like good copywriting
Yes.
> write for your target audience [and the rest of your comment]
No.
Good writers write good copies that are good for (almost) any target audience.
This applies to code too.
For me archetypal "good python code" examples can be found in http://norvig.com/, eg http://norvig.com/lispy.html and it doesn't care about abstractions, jargon, splat, and other things.
Yes.
> write for your target audience [and the rest of your comment]
No.
Good writers write good copies that are good for (almost) any target audience.
This applies to code too.
For me archetypal "good python code" examples can be found in http://norvig.com/, eg http://norvig.com/lispy.html and it doesn't care about abstractions, jargon, splat, and other things.
Obscure jargon and custom methods are always going to be perceived as clever.
Personally I don't think this
We've had the exact same discussion over Promises: people favor a slightly less convenient syntax over too many layers of abstraction. If you have a large codebase where the functional methods are really going to help, great, go on and put a note on the readme to guide other developers before they encounter it; but unless a specific implementation/library becomes hugely popular it's not going to fare well in public or small projects, and will be seen as clever, opaque code.
edit: sorry, I misread the 'is a small incremental improvement' as referring to the underscore method. Keeping the post for discussion anyway.
Personally I don't think this
var totals = splat(get('total'))(orders);
var totals = _.pluck(orders, 'total');
We've had the exact same discussion over Promises: people favor a slightly less convenient syntax over too many layers of abstraction. If you have a large codebase where the functional methods are really going to help, great, go on and put a note on the readme to guide other developers before they encounter it; but unless a specific implementation/library becomes hugely popular it's not going to fare well in public or small projects, and will be seen as clever, opaque code.
edit: sorry, I misread the 'is a small incremental improvement' as referring to the underscore method. Keeping the post for discussion anyway.
The post doesn't say it is an improvement, it says that Underscore is deservedly popular and also that both are jargon.
UPDATE: I will probably clarify that in the code. But if you want to open the door into my madness, the use case for "splat" is that it's a combinator, a function that takes a function and returns a function. So if you like "pluck" as I do, you write:
Having building blocks that are combinators rather than general-purpose functions is itself a family of jargon. It's a win if you do a lot of method decoration and function composition, otherwise it's...
Clever.
UPDATE: I will probably clarify that in the code. But if you want to open the door into my madness, the use case for "splat" is that it's a combinator, a function that takes a function and returns a function. So if you like "pluck" as I do, you write:
var pluck = compose(splat, get);
// ...
var totals = pluck('total')(orders);
Having building blocks that are combinators rather than general-purpose functions is itself a family of jargon. It's a win if you do a lot of method decoration and function composition, otherwise it's...
Clever.
[deleted]
Re: Promises: According to the last article that was posted here, the point of Promises is to provide greater semantic information that assists in organizing the dependencies and prevents subtle race conditions, it is not simply syntactic sugar on callbacks. I'm not prepared to defend that position, but the article made a compelling case.
Yes, that was a great read. What I mean is that the overhead of understanding and keeping the abstractions in your head (promise object, resolve/defer/reject, returned promises, chaining) almost nullifies the advantages it offers. I think promises are great in some circumstances, but unless they catch on as a standard way of working with async calls, they will remain just a 'clever' thing you can use, but most developers won't understand, and will make your code incompatible with everyone else's. It's a chicken and egg problem.
I feel like more than anything, this example demonstrates the value of lightweight lambdas.
var totals = splat(get('total'))(orders);
var totals = orders.map(function(o){return o.total;});
totals = splat(get('total'))(orders);
totals = orders.map (o)->o.totalI find
cheers!
var totals = orders.map(function(o){return o.total;});
var totals = splat(get('total'))(orders);
var totals = orders.map(function(o){
return o.total
})
cheers!
I was deliberately avoiding the map method to keep everything functional.
How is map not functional?
Do you mean you wanted to emphasize HOFs?
Do you mean you wanted to emphasize HOFs?
Yes. The map method is not functional in the sense that the map function is functional. In actual code, I'd use the method too.
I don't really see the method as being any less functional than the function version (ie, they're both without side effects, the method version just has 'this' as an implicit parameter).
Though I guess that's just a difference in perspective.
Edit: Having stumbled upon something else you wrote[1](Viz. "WHy the crazy idea of using a splatter instead of a mapping method or function?"), I now understand the reason you're making the distinction. Though (speaking as someone who certainly doesn't have the level of expertise to be making this semantic argument) I really don't think it's the distinction between "functional" and "not functional" so much as... "composability"?
[1] https://github.com/raganwald/homoiconic/blob/master/2013/01/...
Though I guess that's just a difference in perspective.
Edit: Having stumbled upon something else you wrote[1](Viz. "WHy the crazy idea of using a splatter instead of a mapping method or function?"), I now understand the reason you're making the distinction. Though (speaking as someone who certainly doesn't have the level of expertise to be making this semantic argument) I really don't think it's the distinction between "functional" and "not functional" so much as... "composability"?
[1] https://github.com/raganwald/homoiconic/blob/master/2013/01/...
I think a lot of people would argue that composability is what "functional" code is really interested and many of the other things that are normally associated with it are actually side-effects of the emphasis on composition.
Exactly. There's no point being "functional" for the sake of functions. It's for the benefits this style brings, an important one being composability.
LiveScript allows partially applied operators, including property access. You can do:
totals = map (.total), orders
> I feel like more than anything, this example demonstrates the value of lightweight lambdas.
Meh.
Meh.
totals = map (! "total") ordersThere is a JS library that implements `orders.map('total')`, can't remember it's name.
The allong.es library quoted actually allows:
splat('.total')
[deleted]
It seems like there's a learning spectrum that defines what's explicit and what's clever. If you're not familiar with HOF, then functional programming is always going to appear clever. But as you learn, things lose a bit of magic.
I think the key to a team being explicit vs clever together is that everyone has about the same understanding of explicit vs clever.
I think the key to a team being explicit vs clever together is that everyone has about the same understanding of explicit vs clever.
Cleverness for it's own sake may be a bad thing, but cleverness in general isn't bad.
The really important thing is that when you do something clever, you ensure that people who use your clever function/module/library/webservice don't have to also understand your cleverness.
Leaky abstractions can be worse than no abstraction.
This is a bit of a tangent though. With respect to the micro level cleverness mentioned in the article:
Simply naming the output of those helper functions would go a long way...
The really important thing is that when you do something clever, you ensure that people who use your clever function/module/library/webservice don't have to also understand your cleverness.
Leaky abstractions can be worse than no abstraction.
This is a bit of a tangent though. With respect to the micro level cleverness mentioned in the article:
Simply naming the output of those helper functions would go a long way...
The ActiveRecord example, to me, is an example of "clever". Any code that exhibits "spooky action at a distance" is too clever, in my opinion. When I can't hand trace a method or function and see what's going on, it is too "clever" - or at least it isn't "explicit".
Spring in the Java world does this with it's XML configuration and code injection based on annotations. You can't decipher what's going on by code examination. To code in Spring you have to fully understand the Spring framework. Rails (to me at least) is similar. The steep learning curve makes them less hackable.
With Clojure, by contrast, you can always look at a function or macro and (eventually) grok what's happening.
Spring in the Java world does this with it's XML configuration and code injection based on annotations. You can't decipher what's going on by code examination. To code in Spring you have to fully understand the Spring framework. Rails (to me at least) is similar. The steep learning curve makes them less hackable.
With Clojure, by contrast, you can always look at a function or macro and (eventually) grok what's happening.
Hah. I was with you up until the last line. Macros do exactly the same thing as spring-aop - they transform your function into some different code, so that when it's called it does something different to what was written.
/scala guy, very worried by the introduction of macros, despite (perhaps even because of) all the cool things they can do
/scala guy, very worried by the introduction of macros, despite (perhaps even because of) all the cool things they can do
Certainly macros can be hard to decipher, however they don't set up this spooky action at a distance, for example a annotation signaling bytecode injection. There's no way to hand-trace through that; the only solution is to learn the library / framework in-depth.
Honestly I don't see the difference. If you're stepping through in a debugger, you see the "real" code. If you're just reading the code, you read something that looks like a function and then have to jump far away to the annotation or macro to find out what actually happens. Assuming IDE integration it's really no easier or harder to jump to a spring aspect than it is to a macro.
Many annotations in Spring are merely markers used during startup to wire things up or generate bytecode on the fly. There is no way to jump to the actual code.
It's a bit confusing that splat is being used in an atypical manner - I've usually seen it used to designate an argument aggregator.
[1] http://stackoverflow.com/questions/6201657/what-does-splats-mean-in-the-coffeescript-tutorial
[2] http://endofline.wordpress.com/2011/01/21/the-strange-ruby-splat/
[3] http://stackoverflow.com/questions/5917522/unzipping-and-the-operatorBased on feedback, expect a major naming revision to the allong.es library soon.
Is is just me, or has JavaScript got really fucking weird lately?
It's not the language, it's the reverse-eternal-september caused by people who are actual programmers with an actual background in computer science writing node applications on the server and client applications in the browser.
As long as it was just DHTML for doing some form validation or whatever, it was treated like a "scripting" language.
Either that, or the fumes of smugness are getting to people.
As long as it was just DHTML for doing some form validation or whatever, it was treated like a "scripting" language.
Either that, or the fumes of smugness are getting to people.
I think that lots of confusion is brought by strangeness of jargon names
makeMapper(makeGetter('total'))(orders)
splat(get('total'))('orders')Clever is fine as long as things are somewhat self-explanatory. At least in this example, the get() method name is confusing. Get is a customary well known method name to extract a property of a map or object, and making the call now. The usage context in the example is that it is a parameterizes getter function that's passed in to splat to be called later. Perhaps it would be clearer if it's called getter('total') or accessor('total'). That shows it's building a parameterized actor function, and it can be passed around and called later.
In working with functional code, I prefer naming high order functions with an actor connotation.
In working with functional code, I prefer naming high order functions with an actor connotation.
That's really interesting. It's especially interesting if you think of this:
function get (object, propertyName) {
return object[propertyName];
};
Good question. Let's re-arrange the get method a bit to make it easier for currying demonstration.
For languages (e.g. Haskell) that implicitly curry everything, it's understood that any missing parameter means a curried function has been created and the actual call is deferred. Javascript is not such language. Mixing in the naming convention for implicit curry just causes confusion for the readers.
Javascript's currying is explicit with pattern such as, getter(get, 'age'), which would wrap a function around the get function with a closure {propertyName: 'age'}.
I think it's best to consider the audience and the convention of a language when naming things.
function get (propertyName, object) {
return object[propertyName];
}
For languages (e.g. Haskell) that implicitly curry everything, it's understood that any missing parameter means a curried function has been created and the actual call is deferred. Javascript is not such language. Mixing in the naming convention for implicit curry just causes confusion for the readers.
Javascript's currying is explicit with pattern such as, getter(get, 'age'), which would wrap a function around the get function with a closure {propertyName: 'age'}.
I think it's best to consider the audience and the convention of a language when naming things.
Do you know any notation that makes
I wrote implementations of applyFirst and applyLast as I thought they should work and then merged them according to applyFirst(applyLast, map) and I really got the splat function as described in the next code block. My problem is I still don't get why applyFirst(applyLast, map) works. I'm feeling that all this return function(param1, param2) notation obscures actual flow.
Is there a notation for this that could make me understand it intuitively?
var splat = applyFirst(applyLast, map);
I wrote implementations of applyFirst and applyLast as I thought they should work and then merged them according to applyFirst(applyLast, map) and I really got the splat function as described in the next code block. My problem is I still don't get why applyFirst(applyLast, map) works. I'm feeling that all this return function(param1, param2) notation obscures actual flow.
Is there a notation for this that could make me understand it intuitively?
I'm not aware of specific notation, but let's first see the difference between map and splat:
map is a function that takes a list and a function and returns a list
map is a function that takes a list and a function and returns a list
map :: (function, list) -> list
splat :: (function)->((list)->list)
applyFirst(applyLast, map)(fn)(list)
applyLast(map, fn)(list) -- here applyFirst has supplied the map param to applyLast and fn is the given param
map(list, fn) -- and here applyLast as supplied the fn param to map, putting list first
applyFirst(applyLast, map)(a, b)(c, d)
...
map(c, d, a, b)
After your excelent suggestions for names
(makeMapper and makeGetter, they make everything easier, thank you),
I'll try answering this, with a F#-like syntax using redundant parentheses
around arguments to make them more explicit
to those who don't know F#
Let's suppose map is defined as:
> let map (aList) (aFunction) = ...something here...
(this is according to https://github.com/raganwald/allong.es/blob/master/README.md which seems to have the parameters reversed when compared to F#'s Seq.map, Lis.map, etc.)
And let's suppose applyLast is defined as:
> let applyLast (aFunction) (anArgument) = (fun (x) -> aFunction (x) (anArgument))
So makeMapper is:
> let makeMapper = applyLast (map)
Read the above as: makeMapper is a function just like applyLast, but the first argument (to applyLast) is already provided, being "map". The functionality of applyFirst is implicit when the remanining parameters are missing, so we only need applyLast.
So makeMapper is called as
> let mapperWithAGetter = makeMapper (aGetter)
This completes the call to applyLast, so now we have a (fun (x) -> map (x) (aGetter))
Now we only need to bind x. The result is called like this
> mapperWithAGetter (aList)
IMO, all of this could've been written as:
> let makeMapper (aGetter) = fun (aList) -> map (aList) (aGetter)
Or:
> let makeMapper (aGetter) (aList) = map (aList) (aGetter)
Read both as: makeMapper takes aGetter and returns a function which takes aList
Notice that everything would be much easiear if map took aFunction as its first parameter:
> let map (aFunction) (aList) = ...
> let makeMapper = map // duh
Remember that partial application is implicit!
It would also be easier if applyLast had better syntax, using _ for the missing parameter (the first), as in this Scala-like snippet:
> def makeMapper(aGetter: Any => Any): List[Any] => List[Any] = { _.map(aGetter) }
(I guess Haskell has some nice syntax for this too, but I don't think F# has anything like this)
All of this was not easy to get right, I hope I didn't make any mistake regarding the position and number of parameters.
Let's suppose map is defined as:
> let map (aList) (aFunction) = ...something here...
(this is according to https://github.com/raganwald/allong.es/blob/master/README.md which seems to have the parameters reversed when compared to F#'s Seq.map, Lis.map, etc.)
And let's suppose applyLast is defined as:
> let applyLast (aFunction) (anArgument) = (fun (x) -> aFunction (x) (anArgument))
So makeMapper is:
> let makeMapper = applyLast (map)
Read the above as: makeMapper is a function just like applyLast, but the first argument (to applyLast) is already provided, being "map". The functionality of applyFirst is implicit when the remanining parameters are missing, so we only need applyLast.
So makeMapper is called as
> let mapperWithAGetter = makeMapper (aGetter)
This completes the call to applyLast, so now we have a (fun (x) -> map (x) (aGetter))
Now we only need to bind x. The result is called like this
> mapperWithAGetter (aList)
IMO, all of this could've been written as:
> let makeMapper (aGetter) = fun (aList) -> map (aList) (aGetter)
Or:
> let makeMapper (aGetter) (aList) = map (aList) (aGetter)
Read both as: makeMapper takes aGetter and returns a function which takes aList
Notice that everything would be much easiear if map took aFunction as its first parameter:
> let map (aFunction) (aList) = ...
> let makeMapper = map // duh
Remember that partial application is implicit!
It would also be easier if applyLast had better syntax, using _ for the missing parameter (the first), as in this Scala-like snippet:
> def makeMapper(aGetter: Any => Any): List[Any] => List[Any] = { _.map(aGetter) }
(I guess Haskell has some nice syntax for this too, but I don't think F# has anything like this)
All of this was not easy to get right, I hope I didn't make any mistake regarding the position and number of parameters.
How 'explicit' something is has more to do with the social structures around a new technology. Does rails make it easy to understand how its conventions are applied? Does it assume that all rails programmers understand implementation details? It does not, and so it is fair to criticize it for magic. In principle you could solve the 'magic' problem without changing a line of code, purely by changing how the mechanisms provided are packaged to new programmers.
I spent some time last year trying to distinguish between abstractions and services. According to me, abstractions are things that you are expected to understand the workings of, and services are things you are not. By my definitions, rails is a service, but the lisp programming model is an abstraction, because it is impossible to gain a few months of experience with lisp without understanding in great detail how macros are expanded and so on. Many programming libraries are services because in practice nobody bothers to learn how they work, and we as a field, as a species, tolerate this cargo culting.
Unfortunately I had trouble articulating this distinction. Perhaps I still do. Here, take a look: http://akkartik.name/blog/libraries.
I spent some time last year trying to distinguish between abstractions and services. According to me, abstractions are things that you are expected to understand the workings of, and services are things you are not. By my definitions, rails is a service, but the lisp programming model is an abstraction, because it is impossible to gain a few months of experience with lisp without understanding in great detail how macros are expanded and so on. Many programming libraries are services because in practice nobody bothers to learn how they work, and we as a field, as a species, tolerate this cargo culting.
Unfortunately I had trouble articulating this distinction. Perhaps I still do. Here, take a look: http://akkartik.name/blog/libraries.
This is an interesting perspective if I'm understanding you correctly.
Are you saying that Rails is "magical" because it is often presented to new people that way, but if it were more often presented as "a bunch of Ruby code that does a bunch of stuff, please do go look and see how it does that stuff", it would not be "magical" without being implemented or documented at all differently?
Are you saying that Rails is "magical" because it is often presented to new people that way, but if it were more often presented as "a bunch of Ruby code that does a bunch of stuff, please do go look and see how it does that stuff", it would not be "magical" without being implemented or documented at all differently?
Kinda, if I'm making sense of your question :) Did my article make sense? I'd love to hear what you thought of it. There's basically two halves:
1. Under-promising. I'll quibble with the word 'documented'. Part of the problem is that frameworks market and position themselves with their prose to be hermetically sealed containers offering wondrous features. That's part of their documentation. That we do need to change, IMO.
2. Over-delivering. It's not enough to be open source, and it's not enough to just say, "please do go look and see how it does that stuff." Software is in the stone ages because we aren't able to actively help newcomers get quickly up to speed on our code. We need to think about the big picture of a codebase, and how it's presented to others.
1. Under-promising. I'll quibble with the word 'documented'. Part of the problem is that frameworks market and position themselves with their prose to be hermetically sealed containers offering wondrous features. That's part of their documentation. That we do need to change, IMO.
2. Over-delivering. It's not enough to be open source, and it's not enough to just say, "please do go look and see how it does that stuff." Software is in the stone ages because we aren't able to actively help newcomers get quickly up to speed on our code. We need to think about the big picture of a codebase, and how it's presented to others.
You have an unnecessary lambda^W anonymous function expression in 'mapWith':
function mapWith (fn) {
return function (list) {
return map(list, function (something) {
return fn(something)
});
};
};
function mapWith (fn) {
return function (list) {
return map(list, fn);
};
};hey Scott, I just saw this. It depends on whether your map implementation expects a unary function or whether it injects optional additional arguments like the index, and whether your function is unary or accepts optional other arguments.
If I'm understanding get() correctly here, why not just use:
var totals = orders.map(get("total"));
That's fine, as is _.map(orders, get('total')) or just plain map(orders, get('total')). As I explained in another comment, splat is a combinator, which makes it particularly easy to compose. Compare:
Other folks have introduced the idea that splat is really nothing more than flip(curry(map)). There's a good argument for better naming once you realize the underlying symmetry.
function pluck (list, propertyName) {
return _.map(list, get(propertyName));
};
var pluck = compose(splat, get);
Other folks have introduced the idea that splat is really nothing more than flip(curry(map)). There's a good argument for better naming once you realize the underlying symmetry.
This article touches on it but I do find that there are different kinds of programmers. Generally, I find that an individual either likes to solve problems, i.e. write code that as obviously as possible gets the result they need OR they like to solve puzzles, i.e. write code that is the "best" way to do something and may not be obvious at all.
They generally have two different definitions of readability as well. The former thinks code is readable if it is obvious how it works and how to change it, that latter thinks it is readable if it happens to match how you would talk about it in english with no regard as to whether or not it is editable. Often the inability to edit (or even debug) stems from implicit magic vs explicit code.
They generally have two different definitions of readability as well. The former thinks code is readable if it is obvious how it works and how to change it, that latter thinks it is readable if it happens to match how you would talk about it in english with no regard as to whether or not it is editable. Often the inability to edit (or even debug) stems from implicit magic vs explicit code.
I happen to agree with you, but I have probably interpreted your comment in exactly the opposite way to which it was intended!
I find explicit "do this to that element, then do the other, then put it here" style very hard to read and change.
I find explicit "do this to that element, then do the other, then put it here" style very hard to read and change.
That isn't really what I mean. I'm definitely OK with functional style collections and futures and the like. I'm annoyed with implicits, macros and other action at a distance language features that it make it hard to reason about something locally.
It's all relative. One persons old-hat jargon is another person's "needlessly clever" is another person's "too explicit". Reminds me of when I was dating, when girls were telling me they wanted someone who was "nice, but not TOO nice." Ok thanks lady, you apparently feel like you just communicated something to me, but you didn't really at all.
splat does not seem to be a function that produces a flatMap. In the contexts google is familiar with, a flatMap is either something like this
flatMap fn xs = foldr (++) [] (map fn xs)
That was a typo, I started out writing about "soak," which is to flatMap as "splat" is to map. Thanks.
Every time I have to choose between "clever" and "explicit", I just choose "consistent".
> You have correctly predicted in advance that the implementation will need to change and can do so without breaking the rest of the application.
Some abstractions allow you to avoid predicting things. 'map' is less restrictive than a for-loop if you don't need the powers of a for loop (store state between iterations etc..). So with some abstractions you can postpone restrictions that you don't need and get code that is easier to change.
This is probably all obvious but I thought it was important. It can probably be stated more succinctly.
Some abstractions allow you to avoid predicting things. 'map' is less restrictive than a for-loop if you don't need the powers of a for loop (store state between iterations etc..). So with some abstractions you can postpone restrictions that you don't need and get code that is easier to change.
This is probably all obvious but I thought it was important. It can probably be stated more succinctly.
> mapWith is the self-curried right partial application of the map function. If that seems like gobbledegook to you, it's because I'm using jargon.
Reginald say "jargon" as if he's proud of it, but for this example, the more pejorative meaning seems appropriate. Why not just say "curried map"? I was under the impression that's why the lambda is the first argument.
Reginald say "jargon" as if he's proud of it, but for this example, the more pejorative meaning seems appropriate. Why not just say "curried map"? I was under the impression that's why the lambda is the first argument.
Random piece of code cannot be explicit or implicit. You have to specify exact thing you are talking about, like creating a function. You do create functions explicitly if you use map() and implicitly if you use splat(). But please don't describe the whole piece of code as explicit or implicit because of that.
[deleted]
I will think that code has an audience and it's audience should be explicit. As long as the expectations are correct, it will just be 'sufficiently analyzed magic' and not only sorcery.
How about:
orders.collect(&:total)
With names like pluck and splat... enough said haha
I'm afraid you did not, in fact, say enough.
Care to elaborate?
Care to elaborate?
Now... maybe "splat" and "get" are "jargon", or maybe they're "abstractions" or even "explicit" (frankly I didn't understand that stuff)... But I'll bet good money that bugs in or near this version get fixed faster in the real world. And I'll even bet that truth holds for people who happen to know what "splat" and "get" are supposed to mean.