I think it's worth trying to imagine what it would mean to not screw up.
That's an interesting question! And to be honest, I don't really know the answer. I guess by "screw up" I meant "the restrictions you enforce condemn the language to an excessively narrow niche, and make things that ought to be easy hard". So yeah, you could argue (as Duncan does, in fact) that Fortran is a great domain language for very fast numeric algorithms that don't need dynamic memory, and that we should only use it as an embedded DSL in some general-purpose language. But that's not how it actually gets used, most of the time. My comments about regexps are a bit dodgy, in that the only proof I know that Perl regexps have been extended is that you can embed arbitrary Perl code into a regexp :-) Do lookahead/lookbehind assertions fit the framework? The case I really wanted to talk about is Prolog, where you spend half your time second-guessing the optimizer and the other half the time writing Yet Another meta-interpreter (from my admittedly limited experience). Or think about SQL - surely you've had that experience where, no matter how far round you twist your brain, you can't write the query you're thinking of, but you can describe it in a simple sentence, and could write it straightforwardly in a more conventional language?
I certainly think that there's a huge number of problems which can be more elegantly solved in haskell (using the wonderful guarantees it gives us) than in any other common current language... Quite possibly - I'm still trying to decide that :-) It seems that in many cases (Laziness? Referential transparency?) "guarantees over expressivity" gives the right (or at least a good) choice - the leverage you get outweighs the restrictions. But I'm really just trying to isolate the general design principle. Because I'm not convinced that it's such a great idea as a general principle, if your goal is to design a usable language. In the limit case, of course, it leads you to prefer the guarantee of program termination to the expressiveness of Turing-equivalence :-)
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
no subject
That's an interesting question! And to be honest, I don't really know the answer. I guess by "screw up" I meant "the restrictions you enforce condemn the language to an excessively narrow niche, and make things that ought to be easy hard". So yeah, you could argue (as Duncan does, in fact) that Fortran is a great domain language for very fast numeric algorithms that don't need dynamic memory, and that we should only use it as an embedded DSL in some general-purpose language. But that's not how it actually gets used, most of the time. My comments about regexps are a bit dodgy, in that the only proof I know that Perl regexps have been extended is that you can embed arbitrary Perl code into a regexp :-) Do lookahead/lookbehind assertions fit the framework? The case I really wanted to talk about is Prolog, where you spend half your time second-guessing the optimizer and the other half the time writing Yet Another meta-interpreter (from my admittedly limited experience). Or think about SQL - surely you've had that experience where, no matter how far round you twist your brain, you can't write the query you're thinking of, but you can describe it in a simple sentence, and could write it straightforwardly in a more conventional language?
I certainly think that there's a huge number of problems which can be more elegantly solved in haskell (using the wonderful guarantees it gives us) than in any other common current language...
Quite possibly - I'm still trying to decide that :-) It seems that in many cases (Laziness? Referential transparency?) "guarantees over expressivity" gives the right (or at least a good) choice - the leverage you get outweighs the restrictions. But I'm really just trying to isolate the general design principle. Because I'm not convinced that it's such a great idea as a general principle, if your goal is to design a usable language. In the limit case, of course, it leads you to prefer the guarantee of program termination to the expressiveness of Turing-equivalence :-)