I read it as if your function contains a lot and you'd like to reuse part of this functionality in another place you don't have to figure it out how to abstract this. It's easy to just split your function in two parts and call the part you are interested in far away as is.
I assume they mean to call the function from two (or more) parts of the code (i.e locations). It's not immediately apparent why this is meaningfully different than what would be possible in Java though, since ostensibly a function is the same as a method by just moving the callee to the list of parameters. (There are some things in a Java method that you can do that don't translate to most functional languages, like invoking the version of the method from a superclass, but there's nothing forcing you to do any of those from the language perspective, so it seems a bit strange to claim that the language itself is the issue rather than maybe the specific patterns that were chosen, maybe by their coworkers or just not common in the ecosystem).
I assume to split the overall behaviour (loop through all elements, transform some value, etc) and the specific one (apply this function to all elements, transform it in this way, etc) into multiple functions and combine those to achieve the actual intended behaviour.
Mostly just function calling to reduce duplicate code. Dependency injection does start to get abstraction costs again. I use it when necessary but it is annoying and costly when I do.
I read it as if your function contains a lot and you'd like to reuse part of this functionality in another place you don't have to figure it out how to abstract this. It's easy to just split your function in two parts and call the part you are interested in far away as is.
But I'm probably overthinking it.
I assume they mean to call the function from two (or more) parts of the code (i.e locations). It's not immediately apparent why this is meaningfully different than what would be possible in Java though, since ostensibly a function is the same as a method by just moving the callee to the list of parameters. (There are some things in a Java method that you can do that don't translate to most functional languages, like invoking the version of the method from a superclass, but there's nothing forcing you to do any of those from the language perspective, so it seems a bit strange to claim that the language itself is the issue rather than maybe the specific patterns that were chosen, maybe by their coworkers or just not common in the ecosystem).
You can do functional in any language. I haven’t designed a new class in years in TypeScript and I’ve been more productive as a result.
I read it as „calling it from two places“
I assume to split the overall behaviour (loop through all elements, transform some value, etc) and the specific one (apply this function to all elements, transform it in this way, etc) into multiple functions and combine those to achieve the actual intended behaviour.
At least that's my interpretation
apparently it is not what the author meant but:
using projection you can "call a function in two parts"
this is a useful pattern that you can use to first 'fix' data or behaviour to produce another functionhttps://en.wikipedia.org/wiki/Partial_application
Calling a function from two locations is what I meant.
Basically since moving to a functional approach in typescript I find I do not fight abstractions as I used to when I used classes and inheritance.
I believe they’re referring to callbacks / dependency injection / higher order functions to customize the behavior of a function?
Mostly just function calling to reduce duplicate code. Dependency injection does start to get abstraction costs again. I use it when necessary but it is annoying and costly when I do.