4 ms·

" It sounds like no one knows what such a programming language would look like." Actually, they do. The answer is "a mess" See things like "high performance

" It sounds like no one knows what such a programming language would look like." Actually, they do. The answer is "a mess" See things like "high performance fortran" (Led by the now-sadly-passed Ken Kennedy, who was doing compiler optimizations since well before most people here were born - 1971) http://dl.acm.org/citation.cfm?id=1238844.1238851 http://dl.acm.org/citation.cfm?id=1238844.1238851 And more recently, things like fortress: http://en.wikipedia.org/wiki/Fortress_%28programming_language%29 http://en.wikipedia.org/wiki/Fortress_%28programming_languag...

jacobolus 12y ago
How do you feel about the Halide language/project, which seems to me like a fairly promising application of these ideas. http://halide-lang.org http://halide-lang.org http://people.csail.mit.edu/jrk/halide12/halide12.pdf http://people.csail.mit.edu/jrk/halide12/halide12.pdf http://people.csail.mit.edu/jrk/halide-pldi13.pdf http://people.csail.mit.edu/jrk/halide-pldi13.pdf
- DannyBee 12y ago
  Halide is a domain specific language. I think Halide is wonderful, and i think if you have a domain, it's entirely possible to make great things for that domain. But if your domain is "general purpose", i haven't seen anything that has come out well. IE i think it is exactly the restriction to given domains or choices that enable you to do the kinds of things halide does.
  - jacobolus 12y ago
    Doesn’t most performance-critical code involve some sort of similar “domain”? The examples people have been talking about in this thread, like media codecs, cryptography, matrix solvers, databases, etc. all seem to.
    - DannyBee 12y ago
      Yes, but these domains are all very different, and would require different languages, which would defeat the point.
      - jacobolus 12y ago
        Why? Why, if I care about performance, should I write my database, my kernel scheduler, my TCP stack, my JPEG codec, my cryptographic hash function, my physics engine, and my 3d-rendering pipeline in the same language? If we assume (obviously this isn’t quite true today) the domain specific languages existed which would let me write more readable and modifiable source, in a highly portable way, with explicit control over optimization strategies so that I could get orders of magnitude better performance than the naive C++ version, why wouldn’t I use those whenever possible? Then all the cold “glue” code that isn’t any kind of performance bottleneck can be written in whatever language, and doesn’t need to be optimized at all.
        wmf 12y ago
        That shifts a lot of cost to defining and implementing many DSLs. (For an extreme case, consider the VPRI STEPS project where it looked like some of the DSLs were only used for one program.)
        loup-vaillant 12y ago
        That extreme case may still be worth it, if the result (program + DSL implementation) is easier to maintain than the mainstream alternative (program in a general purpose language). Besides, it wouldn't be that many DSLs. There are relatively few domains where performance is really critical. Cryptography, rendering, encoding/decoding… that's a few dozens at most, with global impact for each. If those DSL have any positive impact at all, they will be worth the cost a million times over.
        philwelch 12y ago
        So instead of writing a database, a kernel scheduler, a TCP stack, a JPEG codec, a cryptographic hash function, a physics engine, and a 3D rendering pipeline, we have to write a DSL for most/all of these programs and then the program itself. And this is less work than just writing them in hand-optimized C in the first place?
  - bandrami 12y ago
    We have some very good tools for writing DSLs (Forth and Lisp come to mind). And since in both of those you in principle have access to an assembler (Lisps are less good about that nowadays, sadly) they seem like a decent option.
EdwardCoffin 12y ago
I read a couple of the Fortress specs as they were developing it, and quite liked the language. It was complicated, but (to me) the complexity was warranted. What about the language do you consider a mess? Or is it more that you believe that any language with similar goals would inevitably be a mess?

jacobolus 12y ago

How do you feel about the Halide language/project, which seems to me like a fairly promising application of these ideas. http://halide-lang.org http://halide-lang.org http://people.csail.mit.edu/jrk/halide12/halide12.pdf http://people.csail.mit.edu/jrk/halide12/halide12.pdf http://people.csail.mit.edu/jrk/halide-pldi13.pdf http://people.csail.mit.edu/jrk/halide-pldi13.pdf

DannyBee 12y ago
Halide is a domain specific language. I think Halide is wonderful, and i think if you have a domain, it's entirely possible to make great things for that domain. But if your domain is "general purpose", i haven't seen anything that has come out well. IE i think it is exactly the restriction to given domains or choices that enable you to do the kinds of things halide does.
- jacobolus 12y ago
  Doesn’t most performance-critical code involve some sort of similar “domain”? The examples people have been talking about in this thread, like media codecs, cryptography, matrix solvers, databases, etc. all seem to.
  - DannyBee 12y ago
    Yes, but these domains are all very different, and would require different languages, which would defeat the point.
    - jacobolus 12y ago
      Why? Why, if I care about performance, should I write my database, my kernel scheduler, my TCP stack, my JPEG codec, my cryptographic hash function, my physics engine, and my 3d-rendering pipeline in the same language? If we assume (obviously this isn’t quite true today) the domain specific languages existed which would let me write more readable and modifiable source, in a highly portable way, with explicit control over optimization strategies so that I could get orders of magnitude better performance than the naive C++ version, why wouldn’t I use those whenever possible? Then all the cold “glue” code that isn’t any kind of performance bottleneck can be written in whatever language, and doesn’t need to be optimized at all.
      - wmf 12y ago
        That shifts a lot of cost to defining and implementing many DSLs. (For an extreme case, consider the VPRI STEPS project where it looked like some of the DSLs were only used for one program.)
        loup-vaillant 12y ago
        That extreme case may still be worth it, if the result (program + DSL implementation) is easier to maintain than the mainstream alternative (program in a general purpose language). Besides, it wouldn't be that many DSLs. There are relatively few domains where performance is really critical. Cryptography, rendering, encoding/decoding… that's a few dozens at most, with global impact for each. If those DSL have any positive impact at all, they will be worth the cost a million times over.
      - philwelch 12y ago
        So instead of writing a database, a kernel scheduler, a TCP stack, a JPEG codec, a cryptographic hash function, a physics engine, and a 3D rendering pipeline, we have to write a DSL for most/all of these programs and then the program itself. And this is less work than just writing them in hand-optimized C in the first place?
- bandrami 12y ago
  We have some very good tools for writing DSLs (Forth and Lisp come to mind). And since in both of those you in principle have access to an assembler (Lisps are less good about that nowadays, sadly) they seem like a decent option.

EdwardCoffin 12y ago

I read a couple of the Fortress specs as they were developing it, and quite liked the language. It was complicated, but (to me) the complexity was warranted. What about the language do you consider a mess? Or is it more that you believe that any language with similar goals would inevitably be a mess?