You have touched on what is both the best and the worst thing about programming languages in 2021.
On the one hand, most modern languages are powerful enough that you can build whatever you want on them. DSLs, constraint solving, pure FP, CPS, logic programming, whatever you like.
On the other hand, languages are subject to network effects. If you build an FP system on top of Python and I build one on top of Ruby, the resulting “FP frameworks” will be almost entirely incompatible. That makes it hard for people coming to either of our projects to “pick it up."
It’s great fun to implement your own library or framework that in turn implements something interesting, but everyone doing that leads to applications that are built on top of in-house home-grown greenspunned code bases.
In most production situations, it’s better to find the language and framework that already cater to the idiom you like, and come with a community of like-minded programmers who are familiar with how things work.
Network effects matter at scale, even if they’re irrelevant for a passion project.
The notion that any language can be coerced into supporting any programming idiom is true in theory, “But the difference between theory and practice is narrower in theory, than it is in practice.”
So I suggest there is still a lot of value in selecting the language/framework/library that was built to do the thing we want, right off the bat, and comes trailing a community and ecosystem around it.
When we use a system built around programming model X to implement programming model Y, and then write our program Z using model Y on top of model X, we are deliberately implementing the “Inner Platform Effect.”
On the one hand, most modern languages are powerful enough that you can build whatever you want on them. DSLs, constraint solving, pure FP, CPS, logic programming, whatever you like.
On the other hand, languages are subject to network effects. If you build an FP system on top of Python and I build one on top of Ruby, the resulting “FP frameworks” will be almost entirely incompatible. That makes it hard for people coming to either of our projects to “pick it up."
It’s great fun to implement your own library or framework that in turn implements something interesting, but everyone doing that leads to applications that are built on top of in-house home-grown greenspunned code bases.
In most production situations, it’s better to find the language and framework that already cater to the idiom you like, and come with a community of like-minded programmers who are familiar with how things work.
Network effects matter at scale, even if they’re irrelevant for a passion project.
The notion that any language can be coerced into supporting any programming idiom is true in theory, “But the difference between theory and practice is narrower in theory, than it is in practice.”
So I suggest there is still a lot of value in selecting the language/framework/library that was built to do the thing we want, right off the bat, and comes trailing a community and ecosystem around it.