8 ms·

Which leads to the well known callback hell, no?

by WA 8y ago

chriswarbo 8y ago
I think "callback hell" in this case would be caused by "boolean blindness" and/or lack of abstraction. General-purpose programming languages, by their very nature, cannot provide us with constructs that are specially suited to our domain; they can only provide us with generally-useful building blocks, like booleans, integers, functions, etc. We could try to solve our problems using only those languge-provided constructs directly, e.g. using maps-of-lists-of-booleans-of-whatever. In that case, we get "callback hell", pyramids/triangles of doom, etc. because the same code needs to implement our solution and encode information about our domain. Alternatively, we can use those language-provided constructs to write our own domain-specific constructs; then use those domain-specific constructs to solve our problem. I've worked with people who avoid this second approach because understanding the solution requires learning those domain-specific constructs, whereas in the first approach we already know how built-in constructs like booleans work. The nice thing about Smalltalk in this example is that if/then/else, loops, etc. are not built-in; they're library code. This takes them off the pedestal that they occupy in other languages, and makes it easier to think about replacing them with our own tailor-made alternatives. (Note that this isn't specific to message-passing style OOP; we can also do this with e.g. recursive functions for loops, induction schemes (e.g. Church encoding) for control flow, etc.)
- projektfu 8y ago
  To be pedantic, ifTrue/ifFalse is actually compiled into the method in Smalltalk 80 and not sent as a message, as an optimization.
scroot 8y ago
In practice, Smalltalk methods tend to be very short. Having too many "callbacks" (really it's just asking Block objects for their value; the "lambdas" here are just objects too) is an issue of how you are designing things. A lot of if/else stuff is avoided simply by taking advantage of the kinds of polymorphism Smalltalk allows in the first place.

Which leads to the well known callback hell, no?

by WA 8y ago

Which leads to the well known callback hell, no?

I think "callback hell" in this case would be caused by "boolean blindness" and/or lack of abstraction. General-purpose programming languages, by their very nature, cannot provide us with constructs that are specially suited to our domain; they can only provide us with generally-useful building blocks, like booleans, integers, functions, etc. We could try to solve our problems using only those languge-provided constructs directly, e.g. using maps-of-lists-of-booleans-of-whatever. In that case, we get "callback hell", pyramids/triangles of doom, etc. because the same code needs to implement our solution and encode information about our domain. Alternatively, we can use those language-provided constructs to write our own domain-specific constructs; then use those domain-specific constructs to solve our problem. I've worked with people who avoid this second approach because understanding the solution requires learning those domain-specific constructs, whereas in the first approach we already know how built-in constructs like booleans work. The nice thing about Smalltalk in this example is that if/then/else, loops, etc. are not built-in; they're library code. This takes them off the pedestal that they occupy in other languages, and makes it easier to think about replacing them with our own tailor-made alternatives. (Note that this isn't specific to message-passing style OOP; we can also do this with e.g. recursive functions for loops, induction schemes (e.g. Church encoding) for control flow, etc.)

projektfu 8y ago
To be pedantic, ifTrue/ifFalse is actually compiled into the method in Smalltalk 80 and not sent as a message, as an optimization.

scroot 8y ago

In practice, Smalltalk methods tend to be very short. Having too many "callbacks" (really it's just asking Block objects for their value; the "lambdas" here are just objects too) is an issue of how you are designing things. A lot of if/else stuff is avoided simply by taking advantage of the kinds of polymorphism Smalltalk allows in the first place.