On Tuesday, 18 February 2014 20:41:37 UTC+1, Stefan Karpinski wrote: > > Domain-specific languages (DSLs) are in vogue these days, but personally I > believe that we need a few very powerful, general-purpose languages, not a > lot of weak, special-purpose ones. I suspect that what drives the DSL > school of thought is the idea that we've already pushed linguistic > expressiveness and power as far as it can go and it hasn't solved our > problems. This appears to suggest that we need to go in the other direction > and make more limited and specialized languages. But I believe, instead, > that the premise that we've taken programming language expressiveness and > power as far as it can go is incorrect. We need to be pushing linguistic > power even further, rather than restricting it. >
I don't think I completely agree with this paragraph (although I don't exactly disagree with it either). Yes, we need better general purpose languages. But I believe one road to finding the needed innovations for that goes through domain specific languages. By trying to solve domain specific problems you stumble upon solutions that can be applied more generally than the specific problem domain. After all, isn't that part of what happened with Julia? Take the numeric work example. Yes, Julia's innovations would be great to have in other general purpose languages, but didn't the motivation for coming up with it arise from that particular problem being more relevant to the specific domain of technical computing? And to give an example of another innovation motivated by a domain specific problem, take a look at Halide (which I admittely have never used but find conceptually very interesting) Using existing programming tools, writing high-performance image processing > code requires sacrificing readability, portability, and modularity. We > argue that this is a consequence of conflating what computations define the > algorithm, with decisions about storage and the order of computation. We > refer to these latter two concerns as the schedule, including choices of > tiling, fusion, recomputation vs. storage, vectorization, and parallelism. > > We propose a representation for feed-forward imaging pipelines that > separates the algorithm from its schedule, enabling high-performance > without sacrificing code clarity. This decoupling simplifies the algorithm > specification: images and intermediate buffers become functions over an > infinite integer domain, with no explicit storage or boundary conditions. > Imaging pipelines are compositions of functions. Programmers separately > specify scheduling strategies for the various functions composing the > algorithm, which allows them to efficiently explore different optimizations > without changing the algorithmic code. > http://people.csail.mit.edu/jrk/halide12/ http://halide-lang.org/ Now, I admit that I'm not that educated about programming languages and their history, but this idea of decoupling of the algorithm and the schedule is very novel to me, and it makes me wonder if that can be used in other areas than image pipelines.
