Comment by vlovich123 10 hours ago
> we want code that's expressive enough to do what we want, while being constrained enough to not do what we don't.
Have you somehow solved the halting problem? AFAIK, all Turing complete languages are perfectly capable of expressing the exact same programs.
DSLs serve an important purpose but the entire thread is about general purpose Turing complete languages. DSLs fail very quickly as soon as you need to leave the domain which can easily result in needing many many DSLs for a given project which has other forms of complexity and sources of bugs that easily arise from such an approach (and that’s assuming you can just cobble together DSLs), not the least of which that proprietary DSLs and languages quickly become difficult to hire for and maintain long term. And DSLs more specifically suffer from the domains they can solve. WUFFs is a notable exception that proves the rule just because format parsing is very well studied and has very sharp edges on the things you need to support / accomplish.
There's a difference 'theoretically possible' and 'practically feasible'. Assume I'm talking about the latter.
The price for not making a Turing Complete language is that you can't solve all possible problems. But, you probably didn't want to solve all possible problems.
That's one of the insights in WUFFS. Yes, most problems cannot be solved with WUFFS, but, we often don't want to solve those problems so that's fine. WUFFS code, even written by an incompetent noob, categorically does not have most of the notorious problems from systems languages, yet in the hands of an expert it's as fast or faster. It has a very limited purpose, but... why aren't we making more of these special purpose languages with their excellent safety and performance, rather than building so many Swiss Army Chainsaw languages which are more dangerous but slower ?