I took his point in general to be a rant about the unwillingness to give priority and effort to things that are schleppy, but doable. An unwillingness to address the devil in the details.
The main idea being that an unwillingness to solve these problems once, generally and completely is dooming "us" to solve it partly, inefficiently and repeatedly.
I would take the detail he gives for the specific cases as incomplete. Specifically this one.
I would NOT say that the article as a whole is "clearly "we could just parse C header files and do it all automatically""
All of these should be doable. Each of these obviously has significant schleppy or technical difficulties/constraints.
For none of these does he address the actual reasons they haven't been done or suggest plans for overcoming them.
I kinda agree with him at a high-level in this case FFI _should_ be solvable.
I think for this case he's just saying "there should be _some_ way to automatically generate FFI glue code (and we should be reusing it)"
I respect you for generously steelmanning the OP's argument here but it is very clear the OP's intent is "just parse C header files and do it all automatically":
> not only could you technically parse .h files and turn them into JNI
The OP didn't have much leg to really stand on for this point and glosses over any of the actual difficult work that would need to be done to make this utopia from the 70/80/90s materialize.
It's not a great post, and its ideas are not that clearly worked out. He could seriously work on his tone.
It could be parsed minimally as a just a grumpy rant with a bit of "get off the lawn" and a few wrong ideas.
Mostly a waste of time.
I'm steelmanning it because personally I'd prefer to get as much as possible from what I've read. Even if it wasn't necessarily put it in the first place (maximizing my utility from it, for my purposes). I'm not debating the OP.
If you're acting from a position of keeping him honest. Kudos.
So I don't really need to engage you on the point then.
I'm agreeing that you'd probably be able to take down the OP in an argument. Or at least would force him to up his game considerable to be able to actually make his points clearly.
BTW, I really like your use of "steelmanning" here.
Actually looking at his other points after this exchange:
(2) I think modern VMs have amazing engineering - is he asking for hacks? Or what?
(3) Cloud offerings could be more coherent. But there are real market and organisational constraints.
(4) Drag and drop UI designers would be nice, and I miss them, but even the good ones used to produce terrible code when used innocently.
(5) I think modern compilers are pretty awesome. Not sure what he wants done.
(6) Yeah. We could build better more compact systems.
His unhappiness at the state of the world.
Hmm. Moaning about it like that doesn't really do much to solve it...
The main idea being that an unwillingness to solve these problems once, generally and completely is dooming "us" to solve it partly, inefficiently and repeatedly.
I would take the detail he gives for the specific cases as incomplete. Specifically this one.
I would NOT say that the article as a whole is "clearly "we could just parse C header files and do it all automatically""
All of these should be doable. Each of these obviously has significant schleppy or technical difficulties/constraints.
For none of these does he address the actual reasons they haven't been done or suggest plans for overcoming them.
I kinda agree with him at a high-level in this case FFI _should_ be solvable.
I think for this case he's just saying "there should be _some_ way to automatically generate FFI glue code (and we should be reusing it)"