Where is functional programming language in this triangle? It seems to me that if we can have smart implementations of the map/reduce/... etc in SML, then it will be the perfect language since it is both productive and can be used to write many programs.
jrgallag
For a programming language like SML, implementations of map/reduce/etc will still need to be sufficiently general to be able to process with arbitrary data and functions. I imagine it would be impossible to intelligently schedule processing on arbitrary data without programmer intervention. Although perhaps this control could be passed onto the programmer in a more transparent way.
totofufu
@jrgallag Can you expand more about that? Could we not build some kind of framework that allows user-defined types and provides some commonly used operations (would have to be generic) for those types?
jrgallag
@totofufu I think the problem would be that the system doesn't know the best way to parallelize these operations if it doesn't know the structure of the data. For example because Liszt knows it is operating on a mesh, or because Halide knows it's operating on an image, they can make optimizations specific to those use cases. If you had map, you could use it on a tree, graph, grid, etc, which might need different types of analysis and planning to schedule efficiently.
@pavelkang: Being a functional language doesn't really help us here. We still run into Rice's theorem regardless. The real win is from restricting the language to somewhere where interesting analysis is no longer undecidable. Once the language has restricted enough capabilities that the compiler/library can start making sense of the semantics and intent of the programmer, only then can we start seeing interesting optimizations and tooling.
Having a library implementing map/reduce/filter gives us enough semantics such that we can have the library handle scheduling for us, but not much else. Pushing this down into the compiler won't give us much beyond integration with existing static analysis and optimization passes, but with a language like SML or C, there are very limited gains there. To get better static analysis and optimization, we need to remove capability.
Where is functional programming language in this triangle? It seems to me that if we can have smart implementations of the map/reduce/... etc in SML, then it will be the perfect language since it is both productive and can be used to write many programs.
For a programming language like SML, implementations of map/reduce/etc will still need to be sufficiently general to be able to process with arbitrary data and functions. I imagine it would be impossible to intelligently schedule processing on arbitrary data without programmer intervention. Although perhaps this control could be passed onto the programmer in a more transparent way.
@jrgallag Can you expand more about that? Could we not build some kind of framework that allows user-defined types and provides some commonly used operations (would have to be generic) for those types?
@totofufu I think the problem would be that the system doesn't know the best way to parallelize these operations if it doesn't know the structure of the data. For example because Liszt knows it is operating on a mesh, or because Halide knows it's operating on an image, they can make optimizations specific to those use cases. If you had map, you could use it on a tree, graph, grid, etc, which might need different types of analysis and planning to schedule efficiently.
Here's a link about what some programmers look for for programming languages http://c2.com/cgi/wiki?IdealProgrammingLanguage
@pavelkang: Being a functional language doesn't really help us here. We still run into Rice's theorem regardless. The real win is from restricting the language to somewhere where interesting analysis is no longer undecidable. Once the language has restricted enough capabilities that the compiler/library can start making sense of the semantics and intent of the programmer, only then can we start seeing interesting optimizations and tooling.
Having a library implementing map/reduce/filter gives us enough semantics such that we can have the library handle scheduling for us, but not much else. Pushing this down into the compiler won't give us much beyond integration with existing static analysis and optimization passes, but with a language like SML or C, there are very limited gains there. To get better static analysis and optimization, we need to remove capability.