4 ms·

The thing is, and the article correctly mentions it, that defunctionalization sacrifices composability. This is not just a technical matter, mind you. If you de

The thing is, and the article correctly mentions it, that defunctionalization sacrifices composability. This is not just a technical matter, mind you. If you design your distributed system around defunctionalized higher-order functions, you have to ensure that client and server have the same understanding of valid parameters. That's a non-trivial problem. So while this might be a cool technique for whole-program compilers, I think it doesn't really fit into anything that has an API boundary.

cratermoon 5y ago
So you don't think that a website would not benefit this? Imagine a design where the user selects options in the browser front end for how to filter product search results, and the system has contract whereby the front end can call the search API with a set of valid filters and get the results back. Yes, I know that typically the front end would ask the back end, for example, all things in a category, then do the filtering within the search results at the browser. I'm speaking to a hypothetical system that wouldn't be dependent on the user providing some classifying condition at first. Imagine, say, a library. You could require the user to pick an LC catalog classification first, but how many non-librarians know that Class D is World History and History of Europe, Asia, Africa, Australia, New Zealand, Etc?
- BobbyJo 5y ago
  > Yes, I know that typically the front end would ask the back end, for example, all things in a category, then do the filtering within the search results at the browser Please no.
  - cratermoon 5y ago
    This is fairly common when the data involved are relatively small. It's much faster and a much better user experience to query the server once for a couple of hundred items and allow the user to view it with different criteria than it is to do a round trip to the server every time the user wants to change or refine the selected data. What's your objection to it?
    - BobbyJo 5y ago
      I've just never seen a scenario where the amount of data wasn't too large for the browser to be responsive while doing things this way.
- choeger 5y ago
  You would use higher-order functions particularly when you cannot determine the scope of your input ahead of time. For instance when you provide something that searches an unstructured database of documents (e.g., mongo). In such a scenario, you could apply defunctionalization. But you'd need to re-apply this technique whenever a new filter comes up or one becomes obsolete. Then you would have to make sure that both your client and server have the same version of the API. If you design a functional system instead, say by allowing filters in a domain-specific language, ala jq, you write your filter function once and never need to touch the API, because it is "complete". Which alternative do you prefer?
  - cratermoon 5y ago
    > Which alternative do you prefer? It depends. How hard it is to write the generalized functional system and how many filters do I need to support initially? How much do filters really change? The "but what if you need to change something" objection comes up quite a lot. In practice it is often better to apply the knowledge and requirements I have and evolve the system as my understanding changes than to try to anticipate all possible scenarios up front. In the latter case, if I put a lot of effort into something and I make the wrong call I either don't have as many changes as I thought, so it's wasted effort, or changes happen in ways I didn't anticipate, so my solution activity works against me.

cratermoon 5y ago

So you don't think that a website would not benefit this? Imagine a design where the user selects options in the browser front end for how to filter product search results, and the system has contract whereby the front end can call the search API with a set of valid filters and get the results back. Yes, I know that typically the front end would ask the back end, for example, all things in a category, then do the filtering within the search results at the browser. I'm speaking to a hypothetical system that wouldn't be dependent on the user providing some classifying condition at first. Imagine, say, a library. You could require the user to pick an LC catalog classification first, but how many non-librarians know that Class D is World History and History of Europe, Asia, Africa, Australia, New Zealand, Etc?

BobbyJo 5y ago
> Yes, I know that typically the front end would ask the back end, for example, all things in a category, then do the filtering within the search results at the browser Please no.
- cratermoon 5y ago
  This is fairly common when the data involved are relatively small. It's much faster and a much better user experience to query the server once for a couple of hundred items and allow the user to view it with different criteria than it is to do a round trip to the server every time the user wants to change or refine the selected data. What's your objection to it?
  - BobbyJo 5y ago
    I've just never seen a scenario where the amount of data wasn't too large for the browser to be responsive while doing things this way.
choeger 5y ago
You would use higher-order functions particularly when you cannot determine the scope of your input ahead of time. For instance when you provide something that searches an unstructured database of documents (e.g., mongo). In such a scenario, you could apply defunctionalization. But you'd need to re-apply this technique whenever a new filter comes up or one becomes obsolete. Then you would have to make sure that both your client and server have the same version of the API. If you design a functional system instead, say by allowing filters in a domain-specific language, ala jq, you write your filter function once and never need to touch the API, because it is "complete". Which alternative do you prefer?
- cratermoon 5y ago
  > Which alternative do you prefer? It depends. How hard it is to write the generalized functional system and how many filters do I need to support initially? How much do filters really change? The "but what if you need to change something" objection comes up quite a lot. In practice it is often better to apply the knowledge and requirements I have and evolve the system as my understanding changes than to try to anticipate all possible scenarios up front. In the latter case, if I put a lot of effort into something and I make the wrong call I either don't have as many changes as I thought, so it's wasted effort, or changes happen in ways I didn't anticipate, so my solution activity works against me.