{"action":"created","issue":{"url":"https://api.github.com/repos/keean/zenscript/issues/33","repository_url":"https://api.github.com/repos/keean/zenscript","labels_url":"https://api.github.com/repos/keean/zenscript/issues/33/labels{/name}","comments_url":"https://api.github.com/repos/keean/zenscript/issues/33/comments","events_url":"https://api.github.com/repos/keean/zenscript/issues/33/events","html_url":"https://github.com/keean/zenscript/issues/33","id":229593189,"number":33,"title":"Closures are bad?","user":{"login":"keean","id":508384,"avatar_url":"https://avatars2.githubusercontent.com/u/508384?v=4","gravatar_id":"","url":"https://api.github.com/users/keean","html_url":"https://github.com/keean","followers_url":"https://api.github.com/users/keean/followers","following_url":"https://api.github.com/users/keean/following{/other_user}","gists_url":"https://api.github.com/users/keean/gists{/gist_id}","starred_url":"https://api.github.com/users/keean/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/keean/subscriptions","organizations_url":"https://api.github.com/users/keean/orgs","repos_url":"https://api.github.com/users/keean/repos","events_url":"https://api.github.com/users/keean/events{/privacy}","received_events_url":"https://api.github.com/users/keean/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":47,"created_at":"2017-05-18T08:31:32Z","updated_at":"2018-02-19T17:45:08Z","closed_at":null,"author_association":"OWNER","body":"I have been writing some application code in JavaScript and TypeScript recently, and one of the things that I have started to realise is that using closures results in lots of garbage for the collector to clean up. It is becoming apparent to me that the convenience of closures costs you in performance. The easy solution is to refactor the captured variables as object properties, and the closure as an object property. A lot of the time we do not need the 'queued state' that is provided by closures, and when we do, creating a new object to encapsulate that state is not a big problem, especially when you have anonymous objects. This reminds me that 'runnable' objects in Java or 'function objects' in C++ serve the same purpose as closures.\r\n\r\nI guess my thoughts are should the syntax make closures harder to use (by forcing you to create a function object) which then makes the programming effort align with the execution efficiency. To put this another way closures make it easy for developers to write inefficient code, by removing them from the language syntax developers would fall back to creating object properties and methods for the callbacks which is more efficient, and would only create a new object to hold the values where it was really necessary. This is approach could be described as \"make the easy way the correct/efficient way\". I don't know if this is something I really want to do yet, its here more as an observation, and an idea about how syntax can support the programmer doing the right thing."},"comment":{"url":"https://api.github.com/repos/keean/zenscript/issues/comments/366762661","html_url":"https://github.com/keean/zenscript/issues/33#issuecomment-366762661","issue_url":"https://api.github.com/repos/keean/zenscript/issues/33","id":366762661,"user":{"login":"shelby3","id":247731,"avatar_url":"https://avatars3.githubusercontent.com/u/247731?v=4","gravatar_id":"","url":"https://api.github.com/users/shelby3","html_url":"https://github.com/shelby3","followers_url":"https://api.github.com/users/shelby3/followers","following_url":"https://api.github.com/users/shelby3/following{/other_user}","gists_url":"https://api.github.com/users/shelby3/gists{/gist_id}","starred_url":"https://api.github.com/users/shelby3/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/shelby3/subscriptions","organizations_url":"https://api.github.com/users/shelby3/orgs","repos_url":"https://api.github.com/users/shelby3/repos","events_url":"https://api.github.com/users/shelby3/events{/privacy}","received_events_url":"https://api.github.com/users/shelby3/received_events","type":"User","site_admin":false},"created_at":"2018-02-19T17:45:08Z","updated_at":"2018-02-19T17:45:08Z","author_association":"NONE","body":"I’m going to try to incorporate the following in an [ongoing discussion](https://github.com/keean/zenscript/issues/17#issuecomment-366597944) about effects systems.\r\n\r\nErik Meijer [wrote](https://www.infoq.com/interviews/erik-meijer-programming-language-design-effects-purity):\r\n\r\n> Q: **But is it a problem if I have some language which has functions, which uses functions but it still does a lot of, for instance IO or whatever other non-pure operations interleaved with functional code?**\r\n> \r\n> A: I think that’s a huge problem actually and the problem is that once you’ve introduced closures, let’s call them closures because I don’t want to call them functions if I’m really kind of a purist, because they are not functions, they are kind of higher order things, they are like objects, special objects that capture variables in their context. And that’s exactly the problem because when you use a closure the evaluation of that body of the closure gets delayed, it doesn’t happen at that point but it might capture all kind of state or context and it’s not only local variables, it can be other things that it captures, then you pass that closure happily around and at some point you call it, but now when you call it it’s out of the lexical context where it was created and then really bad things can happen. So I think it’s a very powerful tool but you’re giving people an enormous gun and they can shoot their legs off, their heads off, bad things can happen if you don’t know what you’re doing."}}
{"actor":{"display_login":"shelby3"}}