> You'll run into a set of requirements that no one has run into before.
Inevitably. Which means you'll have to resort to "real programming" (as opposed to component assembly) for /that part/ of your project. I don't see this as a fundamental reason why component-assembly can never become viable. As we get better at creating flexible components, these situations will get less common, but they will never go away.
> you'll run into a requirement that's simpler to implement directly than it is to write the glue code for all the components you could use to solve it
100% this. For me this pretty much sums up why component-assembly isn't viable today. For all but the simplest components this turns out to be the case. (e.g. date-picker, file-uploader, or maybe something a bit bigger with /very/ fixed requirements, like a disqus comment trail). But jumping from this to "I don't think it's every going to happen" is overly pessimistic. The glue code is too hard to write? We need a better way to write glue code. That could be a fundamentally different type of language, or a fundamentally different conception of what we mean by "component".
(Aside: In my foolishness I am working on such things).
> Inevitably. Which means you'll have to resort to "real programming" (as opposed to component assembly) for /that part/ of your project.
It's not just that you'll run into one unique requirement; you might run into a unique combination of requirements, each of which already has proven solutions, but with no good way to glue it all together. That's the reason C programmers still sometimes write their own string handling or memory allocation code despite that stuff being literally in the standard library.
Writing general purpose software components is hard. If you're creating a product, you know what kind of component you need, and you don't really care about anyone else. If you're making a general purpose component, you have almost literally no possible way of even comprehending, much less fulfilling, all the requirements of every product that could potentially use your component.
You're always going to notice a difference between something that's been cobbled together out of spare parts and something that's been designed to fit an integral product vision. There's a reason we've been hearing about reusing program components for literally decades. I'm sure some chunk of the problem will be broken off and solved, some kind of standard solution to the CRUD app or something, but there are still going to be products out there that need real engineering, not just component assembly.
Inevitably. Which means you'll have to resort to "real programming" (as opposed to component assembly) for /that part/ of your project. I don't see this as a fundamental reason why component-assembly can never become viable. As we get better at creating flexible components, these situations will get less common, but they will never go away.
> you'll run into a requirement that's simpler to implement directly than it is to write the glue code for all the components you could use to solve it
100% this. For me this pretty much sums up why component-assembly isn't viable today. For all but the simplest components this turns out to be the case. (e.g. date-picker, file-uploader, or maybe something a bit bigger with /very/ fixed requirements, like a disqus comment trail). But jumping from this to "I don't think it's every going to happen" is overly pessimistic. The glue code is too hard to write? We need a better way to write glue code. That could be a fundamentally different type of language, or a fundamentally different conception of what we mean by "component".
(Aside: In my foolishness I am working on such things).