3 ms·

Most rank-and-file development doesn't need async and HOF. If your framework does, it's either screwed up or for a special/rare niche. I've been in these debate

by tabtab 6y ago

Most rank-and-file development doesn't need async and HOF. If your framework does, it's either screwed up or for a special/rare niche. I've been in these debates many times, and when examples are given I can usually trace the "fault" down to the framework or limits of the language. I stand behind this claim.

littlecranky67 6y ago
At least in browser-world, most APIs (i mean the ones defined by the web standards) are built around async/Promise/callbacks/HOF, like it or not. There is no switching to other languages/framework when targeting the browser as a runtime.
- tabtab 6y ago
  This is largely because JavaScript has weak areas.
andybak 6y ago
Crikey. Higher order functions are rare or niche? To my mind they are oftentimes magic pixie dust that can turn a hideous, verbose and inflexible API into something humane and readable.
- tabtab 6y ago
  Not quite what I said. I said they are not needed for rank and file application (domain-centric) development, IF the tooling and programming language are decent. If you bring up a scenario, I can probably poke holes in it. Done it many times in many debates. I don't mean to sound arrogant, but I keep winning THIS one for whatever reason.
tonyarkles 6y ago
> I've been in these debates many times, and when examples are given I can usually trace the "fault" down to the framework or limits of the language. I don't disagree, but my follow-up question with that statement is "ok, now what?" If you've got a weak/inexperienced developer who's stuck in a framework where they have have to start grokking async/HOF/whatever to solve the problem they've encountered, where do they go from there? It's fine and good to blame the framework they're operating in to be shitty, but they a) didn't have the skills initially to make a solid decision about the framework to use, and b) are now likely stuck with it (unless they're going to do a rewrite with something else).
- tabtab 6y ago
  I agree that our current tooling requires more "rocket science" than it should to do ordinary things. I'm not sure how to fix the entire industry, but the first step to solving a problem is admit there is one. Early cars were hard to learn, drive, and maintain. Over time they got better via trial and error by manufacturers. The desktop IDE's of the early 90's were like this, but got better over time (until web ruined their market). However, the web is still stuck in 1903: simple things are esoteric. Perhaps because too many other things about "cars" keep changing? Something is wrong. CRUD web dev is a mess.

by tabtab 6y ago

littlecranky67 6y ago

At least in browser-world, most APIs (i mean the ones defined by the web standards) are built around async/Promise/callbacks/HOF, like it or not. There is no switching to other languages/framework when targeting the browser as a runtime.

tabtab 6y ago
This is largely because JavaScript has weak areas.

andybak 6y ago

Crikey. Higher order functions are rare or niche? To my mind they are oftentimes magic pixie dust that can turn a hideous, verbose and inflexible API into something humane and readable.

tabtab 6y ago
Not quite what I said. I said they are not needed for rank and file application (domain-centric) development, IF the tooling and programming language are decent. If you bring up a scenario, I can probably poke holes in it. Done it many times in many debates. I don't mean to sound arrogant, but I keep winning THIS one for whatever reason.

tonyarkles 6y ago

> I've been in these debates many times, and when examples are given I can usually trace the "fault" down to the framework or limits of the language. I don't disagree, but my follow-up question with that statement is "ok, now what?" If you've got a weak/inexperienced developer who's stuck in a framework where they have have to start grokking async/HOF/whatever to solve the problem they've encountered, where do they go from there? It's fine and good to blame the framework they're operating in to be shitty, but they a) didn't have the skills initially to make a solid decision about the framework to use, and b) are now likely stuck with it (unless they're going to do a rewrite with something else).

tabtab 6y ago
I agree that our current tooling requires more "rocket science" than it should to do ordinary things. I'm not sure how to fix the entire industry, but the first step to solving a problem is admit there is one. Early cars were hard to learn, drive, and maintain. Over time they got better via trial and error by manufacturers. The desktop IDE's of the early 90's were like this, but got better over time (until web ruined their market). However, the web is still stuck in 1903: simple things are esoteric. Perhaps because too many other things about "cars" keep changing? Something is wrong. CRUD web dev is a mess.