Wherein Javascript borrows a language feature from Arc

[youngnh]

http://twoguysarguing.wordpress.com/2009/11/04/placeholders-and-currying/

[WilliamLP]

> geolocator.getLatLng("Forest Park, St. Louis, MO", function(center) {

> displayMapAt(center, 14);

> });

To my eyes, that solution is just fine. I don't think I'll ever be swayed to believe that adding on layers of indirection to JavaScript code for the sake of "syntactic goodness" is rationally motivated by leading to more practical power for actually solving problems.

[ynniv → WilliamLP]

Agreed. If you're writing something in a web browser, use sane JavaScript. Every time I have done something "fancy" with a language, there has been a large hidden cost later on, be that complicated debugging sessions, new hire training, or unintended side effects. Terrible syntax/rewriting hacks in Rails are probably what convinced me that I do not like ruby. If you truly care about programmer efficiency, you probably want to look into cross compilers like Objective-J or parenscript.

[cabalamat → ynniv]

I agree. The beauty of software systems is they can be made as complex as the programmer can imagine; this is also the horror of software systems.

All software should be as complex as it needs to be to do the job, and no more so (where complex means the cognitive load necessary to understand it). Unfortunately 99% of programmers and 100% of programmers' managers don't understand this (both numbers are probably correct to the nearest integer, in my experience).

[cwp → ynniv]

See also Clamato. http://clamato.net/

[mikeryan → WilliamLP]

agree - imagine inheriting this code and then having to figure out what the underscore is doing. ugh.

Sometimes brevity isn't the right solution.

[tlrobinson]

You should probably assign an object to the underscore, otherwise any argument which is undefined will match:

    js> var _
    js> _ == undefined
    true

Just doing "var _ = {}" should be sufficient.

edit: however, this conflicts with Underscore.js (http://documentcloud.github.com/underscore/), but if you put an "if (typeof _ === "undefined")" around the assignment you should be ok

[youngnh → tlrobinson]

I actually did a === check for just that reason, since if you define _ = {}, then passing in a real object that is {} will also return true for _ == {}

[tlrobinson → youngnh]

Nope:

    js> a = {}
    [object Object]
    js> b = {}
    [object Object]
    js> a == b
    false

== only casts between certain primitive types, it doesn't do a deep comparison:

    js> x = null
    null
    js> y = undefined
    js> x == y
    true
    js> x === y
    false

Also undefined comparisons are still true with ===:

    js> var _
    js> _ === undefined
    true

But you're right, === should be the default choice, and only use == if you have a good reason.

[ubernostrum → tlrobinson]

It also conflicts with gettext libraries. The name '_' should be considered reserved for that purpose.

[adamc → ubernostrum]

Not to be a jerk, but why? What if gettext isn't important to your current application? (I don't know a lot about gettext; I went and read the blurb.)

[ubernostrum → adamc]

In pretty much any language which has a gettext implementation, "_" is the name used for the function/method/whatever which marks a string for translation. This is just as true in JavaScript (at least two JS gettext implementations that I know of use "_"). It's one of the few truly cross-language naming conventions I know of.

But libraries which expect to be able to use "_" for something other than gettext break this convention, and not only run the risk of screwing interoperability but also cause confusion for the (large number of) developers who are accustomed to "_" having a particular meaning.

[tlrobinson → ubernostrum]

True, but as long as _ is defined as a non-primitive type (namely an object or function) it can be used for both gettext (or underscore.js) and this currying function. All that's required for the currying is that comparison with anything other than itself is false.

[scott_s]

Can someone explain why this:

  geolocator.getLatLng("Forest Park, St. Louis, MO", displayMapAt);

Is better than this?

  displayMapAt(geolocator.getLatLng("Forest Park, St. Louis, MO"));

That is, why is it more sensible for getLatLng to accept a callback function that will accept its result, when one can just pass its result to a function?

[abecedarius → scott_s]

I expect the call to geolocator requires a network round-trip, with displayMapAt getting scheduled to be called when the result appears; meanwhile your code can do other things. (I'm not familiar with this API, though; I could be wrong.)

Another way to do this sort of thing, that might feel more composable: have geolocator.getLatLng() return a 'promise' object that will be asynchronously resolved.

[mdemare]

Clojure has #(+ % 10) for Arc's [+ _ 10]. Does anyone know if Arc inspired Clojure, or whether there's prior art for this syntax?

[scott_s → mdemare]

I think the convention predates both. boost::bind for C++ does something similar: http://www.boost.org/doc/libs/1_40_0/libs/bind/bind.html

[jimbokun → mdemare]

I think Clojure copied Arc on this.

[richhickey → jimbokun]

Actually it was inspired by Mathematica:

http://reference.wolfram.com/mathematica/ref/Slot.html

[Zak → mdemare]

Goo appears to have something similar in its op (partial evaluation) function.

[tomjen2 → mdemare]

At least the _ part is used in both Haskell and Prolog.