4 ms·

Is that true though? You can pass the function itself. If your interface is a function that takes no parameters and returns an int, just wrap this function with

by orisho 6y ago

Is that true though? You can pass the function itself. If your interface is a function that takes no parameters and returns an int, just wrap this function with another function that takes no arguments and moves the arguments into a closure. Doing it in a class is forcing these assumptions on your user - that they need this added complexity in all of their uses, and will make for unwieldy code when they don't, or even more unwieldy code when they use a facility that doesn't satisfy the interface you decided on. Let your user be responsible for deciding that and wrapping your code for whatever use they want to do with it - if you write library code (library and not framework), it should be as simple as possible to allow flexibility for the user.

moron4hire 6y ago
If I'm writing a library for public consumption that performs a non-trivial operation (the only time I would write a library for public consumption), I absolutely do assume I know better than the calling code. I feel like most of these threads boil down creating stawmen of different situations in which FP or OOP fall down, and then declare that case the most essential problem in programming. Programming is hard. Full stop. The most essential problem is programming is that most of the people engaging in it are not adept at it enough to avoid painting themselves into one of many, very hairy corners, regardless of what programming paradigm they are using. Excel users, coding boot camp graduates, PhD candidate scientists, mechanical engineers, computer scientists who never learned how much Dijkstra liked to troll people and took him way too seriously. You write the code that does the job. That's not "does the job" in the sense that people who say things like "good results can be made in any programming language, including PHP" mean. That's "does the job" in the sense that it also doesn't blow up when you drive two motorcycles over it after having only tested it with trucks. Bad results can be written in any programming language, even Rust. And the only operative difference between those situations is there experience and study of the programmer. You don't get great programs by choosing particular languages or programming paradigms. You get them by hiring great programmers. Who then have specific languages and paradigms that they use for different situations.
- orisho 6y ago
  If you know better than the calling code, you're probably writing a framework and not a library :) A library should not be limiting, and should be easy to adapt for use with other code. Frameworks are highly opinionated so it's ok for them to only work in specific use cases (in exchange, they offer increased ease of use for those cases). For example, the Golang Echo HTTP framework supports generating Let's Encrypt certificates using AutoTLS mode. It's not very configurable (and for my use case, that was a limiting factor), but because it was built on top of the autocert library, I was able to use the library directly and make it work with Echo in my use case. If the library was too opinionated, I would've had to fork it to use it in my use case, which was not anticipated by Echo's author.
cessor 6y ago
This circles back to my original argument. Here: def adder(x): def add(y): return x + y return add add_five = adder(5) add_five(10) How is that different from: class adder: def __init__(self, x): self._x = x def __call__(self, y): return self._x + y add_five = adder(5) add_five(10) Did you have something like that in mind? Do I understand your idea correctly? They both allow you to achive the same thing. The syntax doesn't matter, they both produce the same result (in Python, that is, which is a bit unfair, because there, functions are objects to start with -- but even if this was not the case, then the object would require namespacing which is negligible). It depends on whether you want to `think` with a closure or not. I propose that differences in OOP and FP on this level are irrelevant, but that the magic lies in the naming chosen here. An "adder" is something that has continuity and identity, and the calculation is performed later. I don't care about how it is constructed. There is nothing wrong with just calling add(1, 2) -> 3, but objects give you this deferred stuff for free (sorry, not free, for the price of some memory).
- orisho 6y ago
  The difference I was aiming at is that you (a library author, whether public or internal) shouldn't implement adder, you should implement add. And let your caller implement adder using add, if they require it. If you only expose adder, you limit possible uses for your library.

by orisho 6y ago

moron4hire 6y ago

If I'm writing a library for public consumption that performs a non-trivial operation (the only time I would write a library for public consumption), I absolutely do assume I know better than the calling code. I feel like most of these threads boil down creating stawmen of different situations in which FP or OOP fall down, and then declare that case the most essential problem in programming. Programming is hard. Full stop. The most essential problem is programming is that most of the people engaging in it are not adept at it enough to avoid painting themselves into one of many, very hairy corners, regardless of what programming paradigm they are using. Excel users, coding boot camp graduates, PhD candidate scientists, mechanical engineers, computer scientists who never learned how much Dijkstra liked to troll people and took him way too seriously. You write the code that does the job. That's not "does the job" in the sense that people who say things like "good results can be made in any programming language, including PHP" mean. That's "does the job" in the sense that it also doesn't blow up when you drive two motorcycles over it after having only tested it with trucks. Bad results can be written in any programming language, even Rust. And the only operative difference between those situations is there experience and study of the programmer. You don't get great programs by choosing particular languages or programming paradigms. You get them by hiring great programmers. Who then have specific languages and paradigms that they use for different situations.

orisho 6y ago
If you know better than the calling code, you're probably writing a framework and not a library :) A library should not be limiting, and should be easy to adapt for use with other code. Frameworks are highly opinionated so it's ok for them to only work in specific use cases (in exchange, they offer increased ease of use for those cases). For example, the Golang Echo HTTP framework supports generating Let's Encrypt certificates using AutoTLS mode. It's not very configurable (and for my use case, that was a limiting factor), but because it was built on top of the autocert library, I was able to use the library directly and make it work with Echo in my use case. If the library was too opinionated, I would've had to fork it to use it in my use case, which was not anticipated by Echo's author.

cessor 6y ago

This circles back to my original argument. Here: def adder(x): def add(y): return x + y return add add_five = adder(5) add_five(10) How is that different from: class adder: def __init__(self, x): self._x = x def __call__(self, y): return self._x + y add_five = adder(5) add_five(10) Did you have something like that in mind? Do I understand your idea correctly? They both allow you to achive the same thing. The syntax doesn't matter, they both produce the same result (in Python, that is, which is a bit unfair, because there, functions are objects to start with -- but even if this was not the case, then the object would require namespacing which is negligible). It depends on whether you want to `think` with a closure or not. I propose that differences in OOP and FP on this level are irrelevant, but that the magic lies in the naming chosen here. An "adder" is something that has continuity and identity, and the calculation is performed later. I don't care about how it is constructed. There is nothing wrong with just calling add(1, 2) -> 3, but objects give you this deferred stuff for free (sorry, not free, for the price of some memory).

orisho 6y ago
The difference I was aiming at is that you (a library author, whether public or internal) shouldn't implement adder, you should implement add. And let your caller implement adder using add, if they require it. If you only expose adder, you limit possible uses for your library.