Explicit vs. Clever

http://raganwald.com/2013/04/02/explicit-versus-clever.html

by raganwald • 13 years ago

196 97 13 years ago

ante_annum• 13 years ago

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.

akavi3• 13 years ago

I feel like more than anything, this example demonstrates the value of lightweight lambdas.

    var totals = splat(get('total'))(orders);

is definitely nicer than

    var totals = orders.map(function(o){return o.total;});

But there really is not much difference between the coffeescript versions (actually, I'd argue the 'map' version is much clearer in intent):

    totals = splat(get('total'))(orders);

    totals = orders.map (o)->o.total

masklinn• 13 years ago

> I feel like more than anything, this example demonstrates the value of lightweight lambdas.

Meh.

    totals = map (! "total") orders

ricardobeat4• 13 years ago

There is a JS library that implements `orders.map('total')`, can't remember it's name.

raganwald13• 13 years ago

I was deliberately avoiding the map method to keep everything functional.

akavi3• 13 years ago

How is map not functional?

Do you mean you wanted to emphasize HOFs?

GeZe• 13 years ago

LiveScript allows partially applied operators, including property access. You can do:

    totals = map (.total), orders

http://livescript.net/

aurelianito• 13 years ago

I find

    var totals = orders.map(function(o){return o.total;});

far easier to understand than

    var totals = splat(get('total'))(orders);

And, I would had written

    var totals = orders.map(function(o){ 
        return o.total 
    })

(note the lack of semicolons and indentation)

cheers!

jiaaro• 13 years ago

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...

ricardobeat4• 13 years ago

Obscure jargon and custom methods are always going to be perceived as clever.

Personally I don't think this

    var totals = splat(get('total'))(orders);

is an improvement over

    var totals = _.pluck(orders, 'total');

Why? Because the latter has a single layer of abstraction - what does `pluck` do? - while for the former you have to learn about `splat`, `get` and their internal behaviour/return values, specially if my jargon is not exactly the same as this library's jargon.

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.

raganwald13• 13 years ago

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:

    var pluck = compose(splat, get);
    
    // ...
    
    var totals = pluck('total')(orders);

And you wouldn't really write `splat(get('total'))` either.

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.

dasil003• 13 years ago

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.

ricardobeat4• 13 years ago

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.

leke• 13 years ago

Is is just me, or has JavaScript got really fucking weird lately?

raganwald13• 13 years ago

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.

anonymoushn• 13 years ago

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)

or a map of the earth or a map in Minecraft.

raganwald13• 13 years ago

That was a typo, I started out writing about "soak," which is to flatMap as "splat" is to map. Thanks.

ajross2• 13 years ago

And yet:

    var totals = []
    for(var i=0; i<orders.length; i++)
        totals.push(orders[i].total);

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.

raganwald13• 13 years ago

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.

ajross2• 13 years ago

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.

cousin_it• 13 years ago

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...

tomrod• 13 years ago

I completely understand your example, and don't really follow RW's example.

Thank you for clarifying.

Garoof• 13 years ago

... and also get introduced faster?

pilgrim689• 13 years ago

That's like saying that using "malloc" and "free" will allow you to fix your memory management bugs faster than using "new" in Java.

laureny• 13 years ago

No, it's not like that at all.

tome5• 13 years ago

One of the nice things about Python is that it has syntactic sugar for this. I find

    [order.total for order in orders]

very easy to understand in terms of natural language. Still, now I've learned Haskell I'd prefer to write

    map (^.total) orders

adambard3• 13 years ago

Are we having a code example party? I like Clojure:

   (map :total orders)

ricardobeat4• 13 years ago

No need to go that far, CoffeeScript can do both:

    totals = (order.total for order in orders)

    totals = orders.map (o) -> o.total

jimmaswell• 13 years ago

The 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.

adambard3• 13 years ago

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:

    ((splat (get 'title')) orders)

You might consider it perfectly appropriate in context, especially since you probably already have a good idea what splat and get do.

If you were working in Java and saw

    int totals[] = splat(get("title")).call(orders);

You'd probably be upset at whoever wrote it, and with good reason. The difference between legitimate jargon and cleverness is contextual.

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?

snprbob86• 13 years ago

Clojure maps generally have keywords as keys and keywords are callable as getters:

    (map :title orders)

Is analogous to:

    (map #(get % :title) orders)

Which is shorthand for:

    (map (fn [order] (get order :title)) orders)

PySlice3• 13 years ago

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.

FuzzyDunlop• 13 years ago

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:

    (function(order) { 
      // do something 
    })(orders[i])

ivquatch4• 13 years ago

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:

    var totals = orders.map(function(order){ 
        return order.total;
    });

Read it aloud and you'll see what I mean,

"Once upon a time, there was a var named, totals. It was a list of order totals. Fin."

jdmichal• 13 years ago

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.

PySlice3• 13 years ago

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)

thezilch• 13 years ago

I find it easier -- clearer -- to get rid of the enumerable early.

  var i, order, totals = [];
  for(; order=orders[i]; i++) totals.push(order.total);

jwmerrill• 13 years ago

Incrementing undefined gives NaN. You're going to want to initialize that i to 0.

kbenson• 13 years ago

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:

  my @totals = map { $_->{total} } @orders;

Does that make Perl better or worse in any way because of that? No, it's simple the idiomatic way to achieve that result given the current environment.

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.

I don't expect programmers to try to match the structure of how that was expressed in English perfectly in their language/environment, but I DO expect them to map it into the idiomatic way to do it in that environment.

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.

ww5202• 13 years ago

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.

raganwald13• 13 years ago

That's really interesting. It's especially interesting if you think of this:

    function get (object, propertyName) {
      return object[propertyName];
    };

So now, what is: rcurry(get)?

ww5202• 13 years ago

Good question. Let's re-arrange the get method a bit to make it easier for currying demonstration.

    function get (propertyName, object) {
        return object[propertyName];
    }

The method 'get' does what it's named, to get the property now in the call. Curry(get('age')) creates a separate entity that parameterizes get with the 'age' property. It's a new function object different from get. But at least the term curry(get('age')) gives some visual cue to the code readers as what it does vs just get('age').

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.

sufian_rhazi• 13 years ago

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.

gbog• 13 years ago

> 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.

walrus• 13 years ago

How pointless! ;)

raganwald13• 13 years ago

BEST COMMENT EVAR.

spullara2• 13 years ago

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.

tome5• 13 years ago

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.

spullara2• 13 years ago

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.

akkartik2• 13 years ago

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.

sanderjd• 13 years ago

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?

akkartik2• 13 years ago

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.

AnIrishDuck• 13 years ago

If I'm understanding get() correctly here, why not just use:

    var totals = orders.map(get("total"));

Why needlessly use specialized jargon when common terms work just fine?

raganwald13• 13 years ago

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:

    function pluck (list, propertyName) {
      return _.map(list, get(propertyName));
    };

to:

    var pluck = compose(splat, get);

So yes, for that one line you should use map, but when making things out of the mapping construct, it is sometimes handy to use splat.

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.

tunesmith• 13 years ago

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.

klochner• 13 years ago

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-operator

raganwald13• 13 years ago

Based on feedback, expect a major naming revision to the allong.es library soon.

scotty792• 13 years ago

Do you know any notation that makes

  var splat = applyFirst(applyLast, map);

understandable?

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?

anonymous• 13 years ago

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 :: (function, list) -> list

splat is a function that takes a function and returns a function that takes a list and returns a list

  splat :: (function)->((list)->list)

That is sort of effectively the reverse order of parameters for map. What applyFirst does is, it takes a function and a parameter and returns a function that takes more params and prepends the given one. applyLast is similar, but appends the given one. Let's walk through the application of applyFirst(applyLast, map)(fn)(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

If you supply more parameters, you'd get:

  applyFirst(applyLast, map)(a, b)(c, d)
  ...
  map(c, d, a, b)

Which wouldn't work with map per se, but shows how the applyFirst(applyLast, map) construction works.

PySlice3• 13 years ago

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.

sly010• 13 years ago

Every time I have to choose between "clever" and "explicit", I just choose "consistent".

scotty792• 13 years ago

I think that lots of confusion is brought by strangeness of jargon names

  makeMapper(makeGetter('total'))(orders)

is much more readable for me than

  splat(get('total'))('orders')

zzzcpan• 13 years ago

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.

worldsayshi• 13 years ago

> 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.

carlosantelo• 13 years ago

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.

tjholowaychuk• 13 years ago

With names like pluck and splat... enough said haha

qu4z-2• 13 years ago

I'm afraid you did not, in fact, say enough.

Care to elaborate?

rickmode3• 13 years ago

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.

lmm2• 13 years ago

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

rickmode3• 13 years ago

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.

ioquatix• 13 years ago

How about:

    orders.collect(&:total)

Isn't this all a bit of a storm in a teacup? It seems to me that we should minimise the amount of code because #(code) ~= #(bugs).

ScottBurson• 13 years ago

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) 
      });
    };
  };

could be simplified to:

  function mapWith (fn) {
    return function (list) {
      return map(list, fn);
    };
  };

raganwald13• 13 years ago

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.

andreyf• 13 years ago

> 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.

Explicit vs. Clever

Related Stories