3 ms·

Can't talk about closures without mentioning this excellent piece http://mrale.ph/blog/2012/09/23/grokking-v8-closures-for-fun.html http://mrale.ph/blog/2012/09

• agumonkey 11y ago
  Funny how all these articles make me think that lambda/closures are a very very nice syntax to create linguistic friendly structure. Automatically embedding of lexical scope avoid unnecessary names, assignments and side effects. Similarly to this talk https://news.ycombinator.com/item?id=3717715 https://news.ycombinator.com/item?id=3717715 where the author demonstrates how often we write classes with a bit of state, a constructor, and a single method [1].. which is a what a function does for us. Some programming classes takes some time to describe this habit of unnecessary wrapping[2]. From ``` if bool_var then true else false ``` , to theses functions-written-as-classes, or even, depending on the language you use, function that wraps other functions disguised as operators ``` map(function add(x, y) { return x + y }, list) // aka `map + list` in deeply functional languages ``` [1] Java had many single method interfaces that can now be replaced by lambdas [2] see Dan Grossman proglang on Coursera (taken from his original classes at UoWashington)
  • tel 11y ago
    There is technically a pretty significant difference between + function add(x, y) { return x + y; } in general in strict, effectful languages. The transformation is called "eta expansion" (technically, I performed two eta expansions and an un-currying) and we really would like it to be valid—it implies conceptual freedom to introduce and eliminate abstractions, but it rarely is. The issue being that it introduces thunks where computation or effects can hide.