For Haskell, when doing:

    $("foo").stuff().bar().res() 

jQuery feels like the list monad, if you see chaining as similar to bind and $() not so far from return.

And for Lisp, jquery provided error handlers instead of relying on native try/except.

Of course, it's more inspired from it than the real thing, but it's far from any JS paradigm of the time. Remember that JS didn't even have map() and the only place you used your first class functions was to setInterval. Plus the joke is funnier that way :)

Method chaining (aka. fluent syntax) is not really comparable to bind. Bind is nested lambdas, which means an operation might be executed zero or multiple times depending on the bind. In method chaining, each call will be executed exactly once, unless an exception is thrown.

The use of method chaining in jQuery is cool, but it is not very similar to Haskell.

> which means an operation might be executed zero or multiple times depending on the bind.

That's what the jQuery API does behind the scene of the chained calls. That's one of the key reasons of its success actually.

$(".foo").foo().bar() will execute n times, for each of the n DOM elements you matched with ".foo", including one or zero.

No, foo() and bar() will each execute once, but the methods performs some underlying operation on each item in the underlying collection.

Yes this is a cool and useful pattern, but it is not bind. It is just a different thing.

In JS speech, I said "==", and you said "!==".

You didn't even need first class functions for setInterval. setInterval also accepted a string!

Wow, I just tried:

    setInterval('console.log(1 + 1)', 1000);

And it works. It's a big eval().

Stealing this for my next JS training, beginners always have a hard time with callbacks, so it's a good first step to actually explain the benefits of callbacks.

I suggest that, if possible, try to set up a cheap server on a DO droplet or somewhere with a built in amount of latency and use that in your presentation.

When I was learning callbacks I saw people use the "setInterval" example and while it did help to an extent, the real world implementation still left a good deal to be desired.

Why would you direct new comers attention to eval'esque functionality? They should stay far far away from it. Come to think of it, everyone should stay away from eval functionality!

Because students can understand "code being run every x seconds" easier than "reference to function being resolved then called every x seconds".

Once they do, you show the problems with it and show why callbacks are better.

When it comes to pedagogy, I'll use every trick I can.

And I always win.

Agreed. In my class I always start with the hard/wrong way. Point out why it's hard/wrong. Let them hate it. Then show the easy/correct way. You can't just point them at something and say, "Do it this way or else." That's not teaching. That's directing.

What do you do when they decide that they prefer the wrong way? Eval is pretty compelling to beginners!

I feel like you could start with manually calling the function, and then introduce callbacks as a way to get your code to run in response to some event. A callback is no different to a regular function after all.

If your way works, then it works though I suppose.