5 ms·

One problem I've noticed with a very closure-heavy style is that debugging is a pain — you have a closure with a bunch of local state and no way to print or oth

by basman 17y ago

One problem I've noticed with a very closure-heavy style is that debugging is a pain — you have a closure with a bunch of local state and no way to print or otherwise access it (from the repl, say). So then you end up writing special cases of the function for when the first argument is :debug... any better ways to do this?

oconnore 17y ago
You could use a built in object system instead of trying to roll your own? Closures are wonderful, but when you have access to a high quality piece of software designed to make holding state easy, why not use it?
tumult 17y ago
Don't mutate data structures from within a closure :)
- blueag 17y ago
  Why shouldn't I mutate local data structure?
- tedunangst 17y ago
  Even if you're not mutating the state, you may be interested in knowing what it is.
  - loup-vaillant 17y ago
    Just look at the definition of your closure. If you didn't mutate the state since then, well, it hasn't changed. Some debuggers even allow you to "travel back in time", so you can easily "debug" the definition of that closure.
wingo 17y ago
Fix your language implementation: a debugger should have access to a closure's captured state.
- tjic 17y ago
  I hate this sort of rebuttal. A: If you drive your car backwards you get better mileage. B: Well, I tried that, but my field of view is pretty crappy in the mirror, and the controls are non intuitive. A: Well, your shitty car design isn't my problem. Look, whenever you're trying to change someone's behavior, you are engage in marketing. This is an important skill in the startup world. If you told your customer "our solution is better" and he responds "your solution sets my house on fire", you DO NOT WIN POINTS by telling him that he should get a better house. You just lost the sale. Not only that, you made yourself look like an ass. If you want to sell closures, and the fact that pretty much all debuggers don't make using closures easy, this is not the rest of the world's problem - it is a legitimate reason for folks NOT TO USE CLOSURES. You either have to solve it, work around it, or realize that you're not going to sell the "use closures" meme.
  - biotech 17y ago
    > Fix your language implementation.... This is a perfectly valid response if this was LTU or comp.compilers, but here on hacker news only a small percentage of us are actually in a position to "fix our language implementation". Know your audience! If you are talking to language users (not makers), this comment just... well, >> made yourself look like an ass.
    - loup-vaillant 17y ago
      > If you are talking to language users (not makers)[…] In a sense, each time we write a function or an object, we are language makers. Too bad we don't considers ourselves as such, because makers actually bend the languages to their needs, rather than the other way around. Users limit themselves to a limited, defined, approved set of techniques (like function and object definitions). I think any programmer worth it's salt should try and consider himself a bit of a maker. Not to play the Sorcerer's Apprentice, but at the very least to have the idea to call an actual Sorcerer for help.
  - brehaut 17y ago
    That is a straw man argument with a splash of FUD. Point the first: You are making the implication (intentional or otherwise) that closures are backward and that objects are the correct way to structure a program. In any language I have used that has supported closures, they are not backwards. Indeed, the languages that support both closures and objects, closures are a well supported and idiomatic tool that is often used (for reference: C# 3+, Python, JavaScript, F#) Point the second: "...the fact that pretty much all debuggers don't make using closures easy...". Every language I have used that supports closures supports debugging closures with the exact same ease as any other function. If you can pause your program and introspect a function, you can also introspect a closure. If your are claiming that you can't introspect it from a repl, well you can't introspect any other function from the repl without additional debugging tools or instrumenting the code either.

by basman 17y ago

oconnore 17y ago

You could use a built in object system instead of trying to roll your own? Closures are wonderful, but when you have access to a high quality piece of software designed to make holding state easy, why not use it?

tumult 17y ago

Don't mutate data structures from within a closure :)

blueag 17y ago
Why shouldn't I mutate local data structure?
tedunangst 17y ago
Even if you're not mutating the state, you may be interested in knowing what it is.
- loup-vaillant 17y ago
  Just look at the definition of your closure. If you didn't mutate the state since then, well, it hasn't changed. Some debuggers even allow you to "travel back in time", so you can easily "debug" the definition of that closure.

wingo 17y ago

Fix your language implementation: a debugger should have access to a closure's captured state.

tjic 17y ago
I hate this sort of rebuttal. A: If you drive your car backwards you get better mileage. B: Well, I tried that, but my field of view is pretty crappy in the mirror, and the controls are non intuitive. A: Well, your shitty car design isn't my problem. Look, whenever you're trying to change someone's behavior, you are engage in marketing. This is an important skill in the startup world. If you told your customer "our solution is better" and he responds "your solution sets my house on fire", you DO NOT WIN POINTS by telling him that he should get a better house. You just lost the sale. Not only that, you made yourself look like an ass. If you want to sell closures, and the fact that pretty much all debuggers don't make using closures easy, this is not the rest of the world's problem - it is a legitimate reason for folks NOT TO USE CLOSURES. You either have to solve it, work around it, or realize that you're not going to sell the "use closures" meme.
- biotech 17y ago
  > Fix your language implementation.... This is a perfectly valid response if this was LTU or comp.compilers, but here on hacker news only a small percentage of us are actually in a position to "fix our language implementation". Know your audience! If you are talking to language users (not makers), this comment just... well, >> made yourself look like an ass.
  - loup-vaillant 17y ago
    > If you are talking to language users (not makers)[…] In a sense, each time we write a function or an object, we are language makers. Too bad we don't considers ourselves as such, because makers actually bend the languages to their needs, rather than the other way around. Users limit themselves to a limited, defined, approved set of techniques (like function and object definitions). I think any programmer worth it's salt should try and consider himself a bit of a maker. Not to play the Sorcerer's Apprentice, but at the very least to have the idea to call an actual Sorcerer for help.
- brehaut 17y ago
  That is a straw man argument with a splash of FUD. Point the first: You are making the implication (intentional or otherwise) that closures are backward and that objects are the correct way to structure a program. In any language I have used that has supported closures, they are not backwards. Indeed, the languages that support both closures and objects, closures are a well supported and idiomatic tool that is often used (for reference: C# 3+, Python, JavaScript, F#) Point the second: "...the fact that pretty much all debuggers don't make using closures easy...". Every language I have used that supports closures supports debugging closures with the exact same ease as any other function. If you can pause your program and introspect a function, you can also introspect a closure. If your are claiming that you can't introspect it from a repl, well you can't introspect any other function from the repl without additional debugging tools or instrumenting the code either.