5 ms·

You, Too, Can Be on the Cutting Edge of Functional Programming Research

112 points by tl 14y ago

noelwelsh 14y ago
If this was true, it would be true. But it's not, except in the facetious way that the author (presumably) intended it. You're not going to get a publication on the research track of ICFP just by writing a computer game in Haskell. You might well get on the experience report track, but that isn't for original research.
- jerf 14y ago
  It sounds to me like you're deliberately choosing definitions of terms that make the post false so you can then complain about it, rather than trying to find what the author was saying and extending him the benefit of the doubt. Research in a more general sense of things nobody has done before, and not just publication track research, is a valid use of the term, and as you say yourself makes perfect sense and is well defended. Heck, there's room even in the web framework field to do something innovative and not just write MVC-in-Haskell again. (Though even Yesod, the most MVC-in-Haskell framework, has some interesting stuff built around the typing system. I can attest that it is as easy to write an app in Yesod with no cross-site-scripting attacks as it is easy to write an app with one in a more traditional framework.) There's already some interesting work going on there and the projects in progress are clearly not fully exploring the space of possibilities.
  - Peaker 14y ago
    Becoming a layman's authority/source on a subject is not really the same as being on the "cutting edge of research" of the topic.
    - batista 14y ago
      >Becoming a layman's authority/source on a subject is not really the same as being on the "cutting edge of research" of the topic No, but doing something nobody else has done is not "Becoming a layman's authority/source on a subject" it's being on the "cutting edge of research" even if it's not academic research.
      - noelwelsh 14y ago
        I'm sitting in a chair as I write this. Nobody else has sat in this chair today. Am I on the cutting edge of research? Similarly, writing a game in Haskell does not make you on the cutting edge of research.
        batista 14y ago
        >I'm sitting in a chair as I write this. Nobody else has sat in this chair today. Am I on the cutting edge of research? No, but you're on the cutting edge of straw-man argumentation trivializing. Doing something that has been done very few times, or not ever, in a whole programming paradigm (building a game functionally) is qualitatively and quantitatively different than: doing something that has been done trivially for centuries just not in this particular day && by somebody else than you && in one piece of furniture you own (you sitting on a chair). If you cannot understand this, I guess it makes no sense further arguing about it.
        noelwelsh 14y ago
        > No, but you're on the cutting edge of straw-man argumentation trivializing. If only I was that good! Research contributions generally have be novel AND significant. We have seen that novelty alone is not sufficient (sitting in the chair). Significant generally means applicable to a broad range of problems. Monads are significant, as one abstraction can encode a huge range of structures (containers, control flow, etc.) Building a game in Haskell is not a priori novel OR significant. People have done this before (e.g. http://www.haskell.org/haskellwiki/Frag http://www.haskell.org/haskellwiki/Frag). Haskell has good facilities for managing concurrency and state. It's not obvious to me that one would need to go beyond these to build a game. A game would probably need to bind to some C libraries but I don't see this as a significant contribution. The original post made the following points: - Writing a game in Haskell in novel (No. See above.) - Writing a game in Haskell will generate significant contributions to the wider community. I don't see this. Furthermore, it trivialised the accomplishments of both the functional programming community and those who really are on the cutting edge of research.
- stonemetal 14y ago
  It might be publication track for ICSE or one of the other software engineering conferences. Obviously you couldn't just write a game, you would have to actually do some research.
Joe-Z 14y ago
I recently wrote my bachelor thesis about functional reactive programming. In the course of it I implemented a very simple scene with Yampa and an OpenGL binding for Haskell. The reason I chose Haskell was mainly because I never had a functional programming course in university and decided that I want to give it a try. (The code is at https://github.com/Joe-Z/yampa-programming https://github.com/Joe-Z/yampa-programming if you are interested). The problem, in my opinion, of so much of functional programming research is that the presented applications are most often developed only for the sake of one or two research papers and then stopped pursuing. This leads to various papers, scattered across the internet, which all hold some precious information, but are incredibly hard to put together and make real world things out of them (I remember, when I just recently had to search through 7 years of Yampa mailing list, to maybe find some information on a problem I had). Which is why I decided to add some Yampa “Hello world”-like programs to the aforementioned repository, so lone wanderers through the field of FRP are not so lost after all. [edit: should me more readable with paragraphs...]
- jerf 14y ago
  For what's worth, from my perspective as someone fairly evenly split between theory and practice, FRP should still be seen as experimental and not ready for prime time. There are still some fundamental unresolved problems in theory, and I'm not seeing huge evidence that the practice is worked out either. I'm interested and it's worth keeping an eye on, but I do fear it's one of the better examples of some people on the academic side declaring they've got the One True Way to program when their One True Way can barely hold together in toy programs. I hope to see more good work come out of this field, though. I'm cautiously optimistic there's something there. (On the other hand, I do also think that one of the problems FRP faces is in trying to bind to a very not-functional world. UI toolkits in particular are deeply, fundamentally imperative, and such massive endeavors that the idea of replacing one with a functional equivalent is laughable, because the resources aren't there, even though there aren't any fundamental blockers. Needing to hook up your FRP to such toolkits to get them to do anything is a huge up-front penalty to pay to even get one started.)
  - danssig 14y ago
stewbrew 14y ago
I guess it's a matter of what counts as "Cutting Edge of Functional Programming Research".
- jlouis 14y ago
  This kind of research is a bit further down the chain in the sense that it addresses how to actually use functional programming in the real world to solve practical problems. But it is not less important and at that level it really is the cutting edge. One very big mistake we have made over the last years in Academia is to only value "new" ideas rather than revisiting old ones. To a certain extent we are blind to research and work that came before.
discreteevent 14y ago
One way of reading what he is saying is that if you are thinking of using pure FP for your application and it is not primarily a calculator (e.g. Jane Street) then be careful - nobody has proved that it will be quick to prototype, iterable, maintainable, understandable, flexible etc. Surely the academic community should feel more obliged to test their theories and follow things up further than toy examples or examples that match the paradigm exactly? What are they being paid for? In the meantime if someone does want to be at the cutting edge what would be interesting to see would be a word processor, a CAD program or a photoshop developed using a functional language (not a hybrid like Scala but something like Haskell where state is completely isolated using monads or whatever).
- tikhonj 14y ago
  I don't know, there are some other pretty compelling examples out there already. The application I like most is programming languages--not just compilers and interpreters but also various tools and analysis. I think quite a lot of software related to languages gets written in functional languages, and in my experience Haskell is much better for that sort of thing than Python or JavaScript. I've actually written very similar interpreters in all three languages so I think I have a particularly useful perspective here. Another field is web development. There was an article recently about Yesod's being as productive as Rails; I think a functional language would be a safe choice for your next web app. I think there has even been some 3D modelling software written in a functional language--Wings3D is written in Erlang unless I'm much mistaken. I haven't really been paying much attention to other fields--all my time recently has been spent almost equally between language stuff and web stuff--but I think there are other cases where functional programming is a fairly safe choice that are not just calculations. Coincidentally, I doubt that we will see Photoshop or a word processor in a functional language any time soon. Not because functional languages are particularly unsuitable but because word and image processing software is rather big, boring and requires a lot of specialized knowledge; I imagine the intersection between "functional programming enthusiasts" and "word processor enthusiasts" is not very big. In fact, most of the people I know who like functional programming use something like LaTeX rather than a word processor and don't do much image manipulation either.
atdt 14y ago
So the biggest benefit Hague derived from functional programming, by his own account, is that the headache it gave him crippled his zeal for clever tricks. It's a bit like making friends in a new language: when your tongue is tied, your interactions with others are sometime marked by this naive, disarming honesty that is charming and uncomplicated and utterly impossible to reproduce in your native tongue. It's sometime tempting to ascribe that to language itself, but it's not inherent to the language -- it's circumstantial. As you become fluent, shades of irony and evasion creep back into your speech. Functional programming comes with its own bag of clever-clever tricks, and lack of familiarity will only stay your hand from them for as long as you lack familiarity. Ignorance is ephemeral. Contending with arbitrary handicaps may be formative, but it can't (and shouldn't) drive adoption.
- look_lookatme 14y ago
  Nothing to contribute, just want to say this is a wonderful comment.
  - mbrock 14y ago
    Yes, quite perfect!
- silentbicycle 14y ago
  He's said something pretty similar about J: "I highly recommend that all programmers learn J. I doubt most will end up using it for daily work, but the process of learning it will stick with you. J is so completely different from everything else out there, and all your knowledge of C++ and Python and Scheme goes right out the window, leaving you an abject, confused beginner. In short, J will make you cry." (http://prog21.dadgum.com/48.html http://prog21.dadgum.com/48.html) While I think multiparadigms are very practical, the easy availability of familiar approaches is a weakness when using them for studying programming.
- Peaker 14y ago
  In the article "Why Functional Programming Matters"[1] John Hughes explains the benefits of the "no destructive assignments" handicap. Basically, having no assignments yields new ways to glue code together. It is somewhat similar to the benefits of structured programming as opposed to goto's. Also, functional languages such as Haskell don't forbid mutability/effects, they just make them explicit. This is only a handicap in the sense that it makes some types of changes more difficult (e.g: Adding an effect to code that previously did not have one). But this has enormous advantages, because there are so many interesting things we can do when we have the guarantee that things have no effects when they actually don't. [1] http://www.cs.kent.ac.uk/people/staff/dat/miranda/whyfp90.pdf http://www.cs.kent.ac.uk/people/staff/dat/miranda/whyfp90.pd...

112 points by tl 14y ago

If this was true, it would be true. But it's not, except in the facetious way that the author (presumably) intended it. You're not going to get a publication on the research track of ICFP just by writing a computer game in Haskell. You might well get on the experience report track, but that isn't for original research.

jerf 14y ago
It sounds to me like you're deliberately choosing definitions of terms that make the post false so you can then complain about it, rather than trying to find what the author was saying and extending him the benefit of the doubt. Research in a more general sense of things nobody has done before, and not just publication track research, is a valid use of the term, and as you say yourself makes perfect sense and is well defended. Heck, there's room even in the web framework field to do something innovative and not just write MVC-in-Haskell again. (Though even Yesod, the most MVC-in-Haskell framework, has some interesting stuff built around the typing system. I can attest that it is as easy to write an app in Yesod with no cross-site-scripting attacks as it is easy to write an app with one in a more traditional framework.) There's already some interesting work going on there and the projects in progress are clearly not fully exploring the space of possibilities.
- Peaker 14y ago
  Becoming a layman's authority/source on a subject is not really the same as being on the "cutting edge of research" of the topic.
  - batista 14y ago
    >Becoming a layman's authority/source on a subject is not really the same as being on the "cutting edge of research" of the topic No, but doing something nobody else has done is not "Becoming a layman's authority/source on a subject" it's being on the "cutting edge of research" even if it's not academic research.
    - noelwelsh 14y ago
      I'm sitting in a chair as I write this. Nobody else has sat in this chair today. Am I on the cutting edge of research? Similarly, writing a game in Haskell does not make you on the cutting edge of research.
      - batista 14y ago
        >I'm sitting in a chair as I write this. Nobody else has sat in this chair today. Am I on the cutting edge of research? No, but you're on the cutting edge of straw-man argumentation trivializing. Doing something that has been done very few times, or not ever, in a whole programming paradigm (building a game functionally) is qualitatively and quantitatively different than: doing something that has been done trivially for centuries just not in this particular day && by somebody else than you && in one piece of furniture you own (you sitting on a chair). If you cannot understand this, I guess it makes no sense further arguing about it.
        noelwelsh 14y ago
        > No, but you're on the cutting edge of straw-man argumentation trivializing. If only I was that good! Research contributions generally have be novel AND significant. We have seen that novelty alone is not sufficient (sitting in the chair). Significant generally means applicable to a broad range of problems. Monads are significant, as one abstraction can encode a huge range of structures (containers, control flow, etc.) Building a game in Haskell is not a priori novel OR significant. People have done this before (e.g. http://www.haskell.org/haskellwiki/Frag http://www.haskell.org/haskellwiki/Frag). Haskell has good facilities for managing concurrency and state. It's not obvious to me that one would need to go beyond these to build a game. A game would probably need to bind to some C libraries but I don't see this as a significant contribution. The original post made the following points: - Writing a game in Haskell in novel (No. See above.) - Writing a game in Haskell will generate significant contributions to the wider community. I don't see this. Furthermore, it trivialised the accomplishments of both the functional programming community and those who really are on the cutting edge of research.
stonemetal 14y ago
It might be publication track for ICSE or one of the other software engineering conferences. Obviously you couldn't just write a game, you would have to actually do some research.

Joe-Z 14y ago

I recently wrote my bachelor thesis about functional reactive programming. In the course of it I implemented a very simple scene with Yampa and an OpenGL binding for Haskell. The reason I chose Haskell was mainly because I never had a functional programming course in university and decided that I want to give it a try. (The code is at https://github.com/Joe-Z/yampa-programming https://github.com/Joe-Z/yampa-programming if you are interested). The problem, in my opinion, of so much of functional programming research is that the presented applications are most often developed only for the sake of one or two research papers and then stopped pursuing. This leads to various papers, scattered across the internet, which all hold some precious information, but are incredibly hard to put together and make real world things out of them (I remember, when I just recently had to search through 7 years of Yampa mailing list, to maybe find some information on a problem I had). Which is why I decided to add some Yampa “Hello world”-like programs to the aforementioned repository, so lone wanderers through the field of FRP are not so lost after all. [edit: should me more readable with paragraphs...]

jerf 14y ago
For what's worth, from my perspective as someone fairly evenly split between theory and practice, FRP should still be seen as experimental and not ready for prime time. There are still some fundamental unresolved problems in theory, and I'm not seeing huge evidence that the practice is worked out either. I'm interested and it's worth keeping an eye on, but I do fear it's one of the better examples of some people on the academic side declaring they've got the One True Way to program when their One True Way can barely hold together in toy programs. I hope to see more good work come out of this field, though. I'm cautiously optimistic there's something there. (On the other hand, I do also think that one of the problems FRP faces is in trying to bind to a very not-functional world. UI toolkits in particular are deeply, fundamentally imperative, and such massive endeavors that the idea of replacing one with a functional equivalent is laughable, because the resources aren't there, even though there aren't any fundamental blockers. Needing to hook up your FRP to such toolkits to get them to do anything is a huge up-front penalty to pay to even get one started.)
- danssig 14y ago

stewbrew 14y ago

I guess it's a matter of what counts as "Cutting Edge of Functional Programming Research".

jlouis 14y ago
This kind of research is a bit further down the chain in the sense that it addresses how to actually use functional programming in the real world to solve practical problems. But it is not less important and at that level it really is the cutting edge. One very big mistake we have made over the last years in Academia is to only value "new" ideas rather than revisiting old ones. To a certain extent we are blind to research and work that came before.

discreteevent 14y ago

One way of reading what he is saying is that if you are thinking of using pure FP for your application and it is not primarily a calculator (e.g. Jane Street) then be careful - nobody has proved that it will be quick to prototype, iterable, maintainable, understandable, flexible etc. Surely the academic community should feel more obliged to test their theories and follow things up further than toy examples or examples that match the paradigm exactly? What are they being paid for? In the meantime if someone does want to be at the cutting edge what would be interesting to see would be a word processor, a CAD program or a photoshop developed using a functional language (not a hybrid like Scala but something like Haskell where state is completely isolated using monads or whatever).

tikhonj 14y ago
I don't know, there are some other pretty compelling examples out there already. The application I like most is programming languages--not just compilers and interpreters but also various tools and analysis. I think quite a lot of software related to languages gets written in functional languages, and in my experience Haskell is much better for that sort of thing than Python or JavaScript. I've actually written very similar interpreters in all three languages so I think I have a particularly useful perspective here. Another field is web development. There was an article recently about Yesod's being as productive as Rails; I think a functional language would be a safe choice for your next web app. I think there has even been some 3D modelling software written in a functional language--Wings3D is written in Erlang unless I'm much mistaken. I haven't really been paying much attention to other fields--all my time recently has been spent almost equally between language stuff and web stuff--but I think there are other cases where functional programming is a fairly safe choice that are not just calculations. Coincidentally, I doubt that we will see Photoshop or a word processor in a functional language any time soon. Not because functional languages are particularly unsuitable but because word and image processing software is rather big, boring and requires a lot of specialized knowledge; I imagine the intersection between "functional programming enthusiasts" and "word processor enthusiasts" is not very big. In fact, most of the people I know who like functional programming use something like LaTeX rather than a word processor and don't do much image manipulation either.

atdt 14y ago

So the biggest benefit Hague derived from functional programming, by his own account, is that the headache it gave him crippled his zeal for clever tricks. It's a bit like making friends in a new language: when your tongue is tied, your interactions with others are sometime marked by this naive, disarming honesty that is charming and uncomplicated and utterly impossible to reproduce in your native tongue. It's sometime tempting to ascribe that to language itself, but it's not inherent to the language -- it's circumstantial. As you become fluent, shades of irony and evasion creep back into your speech. Functional programming comes with its own bag of clever-clever tricks, and lack of familiarity will only stay your hand from them for as long as you lack familiarity. Ignorance is ephemeral. Contending with arbitrary handicaps may be formative, but it can't (and shouldn't) drive adoption.

look_lookatme 14y ago
Nothing to contribute, just want to say this is a wonderful comment.
- mbrock 14y ago
  Yes, quite perfect!
silentbicycle 14y ago
He's said something pretty similar about J: "I highly recommend that all programmers learn J. I doubt most will end up using it for daily work, but the process of learning it will stick with you. J is so completely different from everything else out there, and all your knowledge of C++ and Python and Scheme goes right out the window, leaving you an abject, confused beginner. In short, J will make you cry." (http://prog21.dadgum.com/48.html http://prog21.dadgum.com/48.html) While I think multiparadigms are very practical, the easy availability of familiar approaches is a weakness when using them for studying programming.
Peaker 14y ago
In the article "Why Functional Programming Matters"[1] John Hughes explains the benefits of the "no destructive assignments" handicap. Basically, having no assignments yields new ways to glue code together. It is somewhat similar to the benefits of structured programming as opposed to goto's. Also, functional languages such as Haskell don't forbid mutability/effects, they just make them explicit. This is only a handicap in the sense that it makes some types of changes more difficult (e.g: Adding an effect to code that previously did not have one). But this has enormous advantages, because there are so many interesting things we can do when we have the guarantee that things have no effects when they actually don't. [1] http://www.cs.kent.ac.uk/people/staff/dat/miranda/whyfp90.pdf http://www.cs.kent.ac.uk/people/staff/dat/miranda/whyfp90.pd...