"This is outstanding -- although in lieu of Yet Another New Programming Language (YANPL), I would suggest simply having developers learn the concepts and apply them no matter what environment they're in."
One of the recurring themes I've been banging on on HN for the last couple of months is that there's actually a lot of room for new languages to come out that aren't just respellings of the current languages we have, and this is one of the opportunities that exist. I say this because the vast bulk of our current languages will just fight you so much if you try to work this way. What most languages are designed to do and designed to make easy are precisely the things that will blow your foot off. Trying to make this work in current languages is tapdancing through a minefield. It can certainly be done, but it's not something I think we can ever reasonably expect to be done at scale.
As you suggest, Haskell is pretty much the only semi-popular language that could implement this with a library, and it would be correct. And even then it probably would be a not-entirely-optimal experience, just because it's not really optimized for this.
I don't think we disagree. I'm a big fan of DSLs/languages over further app complexity. To clarify my point, Another Language (tm) is not the problem. The problem is a lack of understanding of the fundamentals.
I keep seeing people sell tech/languages/frameworks as some sort of replacement for deep understanding. Hey, that's cool -- as long as you don't spend all your time honking around with the tool instead of the problem. It's when these promises fail that devs and teams end up on a dark, lonely path with unhappy customers.
Overall I am quite fascinated by the concept of new environments for programmers -- and I believe it's not just new languages, but the tools, the industry background, the workflow, and a lot of other things come together to make tools and frameworks rock. (Many times we all want to geek out on language details when the problem with the language is lack of a community or tooling that makes you want to jump out a window. But I digress.)
Something I'm working on is coming up with guidelines of when and how to create good DSLs in order to create that kind of environment.
We do not. I meant more as elaboration, not outright disagreement. It is a great idea to apply these ideas today, but it's really hard, and I'd still love to see someone fix that. And maybe some other things as they go. But in the meantime, programmers of today really can't afford to wait to apply these principles.
I guess my point is that I agree that YAPL that just has this in it and is basically thrown out as a hack for writing a couple of papers is not very useful, but I'd love to see someone set out to create the Next Big Programming Language that incorporates this idea, as well as other things, but isn't just a demonstration project.
One of the recurring themes I've been banging on on HN for the last couple of months is that there's actually a lot of room for new languages to come out that aren't just respellings of the current languages we have, and this is one of the opportunities that exist. I say this because the vast bulk of our current languages will just fight you so much if you try to work this way. What most languages are designed to do and designed to make easy are precisely the things that will blow your foot off. Trying to make this work in current languages is tapdancing through a minefield. It can certainly be done, but it's not something I think we can ever reasonably expect to be done at scale.
As you suggest, Haskell is pretty much the only semi-popular language that could implement this with a library, and it would be correct. And even then it probably would be a not-entirely-optimal experience, just because it's not really optimized for this.