2 ms·

This is really a good way of approaching computer science theory of programming language. For example, i remembered there was something really nasty with javasc

by bsaul 12y ago

This is really a good way of approaching computer science theory of programming language. For example, i remembered there was something really nasty with javascript closures, and was surprised he didn't mention it. Then i went and look at what it was really that sometimes bugged me, and just realized it was just a combination of heavy closure use together with function-level variable scope (rather than block based), that sometimes made you need to wrap the content of a for loop in an a anonymous function, just to capture the current state of the loop increment. Really interesting talk.

vorg 12y ago
There's problems not just with Javascript closures but also with Groovy closures. According to the Groovy devcon 2 report at http://javanicus.com/blog2/items/191-index.html http://javanicus.com/blog2/items/191-index.html "no agreement was reached on [...] whether we should have any syntax denoting the difference between a true lexical Closure and one of these Builder blocks. The historical reasons go back to Builder blocks looking just like Closures, and I'm afraid this long standing mistake must be removed from the language before any true progress can be made, as no sensible specification rules can be applied while the dichotomy exists. I headed back to London with a very disappointed James Strachan" In Groovy language creator Strachan's last ever email on its mailing list 2 days later at http://groovy.329449.n5.nabble.com/Paris-write-up-tt395560.html#a395569 http://groovy.329449.n5.nabble.com/Paris-write-up-tt395560.h... "Note that no other dynamic language I'm aware of has any concept of dynamic name resolution in the way you suggest; names are always statically bound to objects in a sensible way in all dynamic languages I'm aware of (lisp, smalltalk, python, ruby etc). I see no argument yet for why we have to throw away decades of language research and development with respect to name resolution across the language as a whole"

by bsaul 12y ago

vorg 12y ago

There's problems not just with Javascript closures but also with Groovy closures. According to the Groovy devcon 2 report at http://javanicus.com/blog2/items/191-index.html http://javanicus.com/blog2/items/191-index.html "no agreement was reached on [...] whether we should have any syntax denoting the difference between a true lexical Closure and one of these Builder blocks. The historical reasons go back to Builder blocks looking just like Closures, and I'm afraid this long standing mistake must be removed from the language before any true progress can be made, as no sensible specification rules can be applied while the dichotomy exists. I headed back to London with a very disappointed James Strachan" In Groovy language creator Strachan's last ever email on its mailing list 2 days later at http://groovy.329449.n5.nabble.com/Paris-write-up-tt395560.html#a395569 http://groovy.329449.n5.nabble.com/Paris-write-up-tt395560.h... "Note that no other dynamic language I'm aware of has any concept of dynamic name resolution in the way you suggest; names are always statically bound to objects in a sensible way in all dynamic languages I'm aware of (lisp, smalltalk, python, ruby etc). I see no argument yet for why we have to throw away decades of language research and development with respect to name resolution across the language as a whole"