2 ms·

Would I be correct in guessing that you are more likely to write an abstract class in the next month than to write a higher order function? Part of the problem

Would I be correct in guessing that you are more likely to write an abstract class in the next month than to write a higher order function? Part of the problem in these discussions is that there are at least 2 populations with vastly different work flows. Which would be less of an issue if I were part of the majority enjoying “mob rule”

karatestomp 6y ago
> Would I be correct in guessing that you are more likely to write an abstract class in the next month than to write a higher order function? I doubt it, because HOFs are hip in React-land right now and I don't really give a shit, personally, so I usually do whatever my team-mates find idiomatic in their current coding style and preferences, which means implementing and using HOFs, for now. Plus React picked "awkwardly add state and object-like functionality to functions by partially re-implementing objects" over "use built-in object system better, but tie react more strongly to OO-style programming" when they realized they had to pick one or the other to fix some problems, so React's even more functional now than it was before and is only heading farther that way as their chosen way forward continues to accrue functionality that OO-style React doesn't have. Regardless, I haven't found TS to impede the writing of HOFs, and certainly not the use of them. I've been favoring them for a while even server-side just because it's "the thing to do" and other JS devs are familiar and comfortable with them these days and, again, I don't really care one way or the other. If I find myself on a team that prefers classes and objects, I'll use those instead in places where either would do. Anyway, I'm more of a composition than inheritance guy when writing OO code. And I'd be more likely to define an interface than an abstract class. Not that I'd never, ever use the latter, it's just not something I reach for very often, especially in TypeScript. [EDIT] actually, TS is part of why I no longer have significant preferences for how I write Javascript. Before, the only Javascript style I found not to be hair-pulling-out stressful and unproductive was about as C-like as possible, favoring a procedural style and aiming for zero indirection or "cuteness". Of course this was a popular JS style approximately no-where so this translated to my hating Javascript. TypeScript saves me from having to care. I'll write whatever, just give me types so I don't have to go read (or, god forbid, execute and poke around in) your code to figure out WTF you're doing even at the most fundamental level.

karatestomp 6y ago

> Would I be correct in guessing that you are more likely to write an abstract class in the next month than to write a higher order function? I doubt it, because HOFs are hip in React-land right now and I don't really give a shit, personally, so I usually do whatever my team-mates find idiomatic in their current coding style and preferences, which means implementing and using HOFs, for now. Plus React picked "awkwardly add state and object-like functionality to functions by partially re-implementing objects" over "use built-in object system better, but tie react more strongly to OO-style programming" when they realized they had to pick one or the other to fix some problems, so React's even more functional now than it was before and is only heading farther that way as their chosen way forward continues to accrue functionality that OO-style React doesn't have. Regardless, I haven't found TS to impede the writing of HOFs, and certainly not the use of them. I've been favoring them for a while even server-side just because it's "the thing to do" and other JS devs are familiar and comfortable with them these days and, again, I don't really care one way or the other. If I find myself on a team that prefers classes and objects, I'll use those instead in places where either would do. Anyway, I'm more of a composition than inheritance guy when writing OO code. And I'd be more likely to define an interface than an abstract class. Not that I'd never, ever use the latter, it's just not something I reach for very often, especially in TypeScript. [EDIT] actually, TS is part of why I no longer have significant preferences for how I write Javascript. Before, the only Javascript style I found not to be hair-pulling-out stressful and unproductive was about as C-like as possible, favoring a procedural style and aiming for zero indirection or "cuteness". Of course this was a popular JS style approximately no-where so this translated to my hating Javascript. TypeScript saves me from having to care. I'll write whatever, just give me types so I don't have to go read (or, god forbid, execute and poke around in) your code to figure out WTF you're doing even at the most fundamental level.