You, Too, Can Be on the Cutting Edge of Functional Programming Research | Hacker News Reader

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

prog21.dadgum.com

112 pointstl31 comments

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.

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)

While I think multiparadigms are very practical, the easy availability of familiar approaches is a weakness when using them for studying programming.

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.pd...

I just read through most of O'Reilly's new Clojure book and implemented a simple Clojure app (a web-based tic-tac-toe game). The analogy to making friends in a new language is really good -- it was full of moments like "I'm sure somewhere in this dictionary is the perfect word for what I'm thinking" and "you have a word for that?!" and "I never would have thought of putting things that way!"

The primary consequence was to improve my use of my native language, Python -- I'm much more likely to use all() and any() and map() and reduce() and set() where they make sense, to think of my functions in terms of composability, etc. I'm not sure that I'll ever put in the time to be fluent in Clojure, but I'm glad I spent some time stumbling through it.

Slightly off-topic: In Python you will also benefit from using the sorted and reverse functions to avoid mutability. Generator functions are a nice way to build collections without using explicit append:

  def collection ():
    list = []
    while someLoopCondition ():
      while someOtherLoopCondition ():
        list.append (someStuff ())
    return list

  def collection2():
    while someCondition ():
      while someOtherLoopCondition ():
        yield someStuff ()

Nothing to contribute, just want to say this is a wonderful comment.

Yes, quite perfect!

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 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...]

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.)

What about going onto, say, Linux and making your own graphical toolkit from the ground up?

As I said, it's a massive undertaking. The minimal acceptable toolkit (to say nothing of competing with GTK or QT, just getting the minimal toolkit that users will tolerate) is an immense amount of work. Quite a lot of it is essential complexity, the things that textboxes do that are simply expected and are true representations of complexity, not accidental artifacts of the paradigm used. Functional programming may or may not help with accidental complexity but nothing can duck the essential complexity. I'd estimate that even a minimal toolkit would be on par with the time invested into GHC itself, and to seriously compete, tack a couple of orders of magnitude on there.

In a world where everybody implements MVC web framework in their favorite language, reimplements window managers in their favorite language, and reimplements all manner of other software simply because it wasn't in their favorite language... there's a reason all the communities just bind to GTK, QT, and wxWidgets and don't reimplement widget frameworks from scratch in their favorite language, even for languages much better funded and bigger than all the functional programming communities put together. Just the bindings can be major and in some cases unsustainable efforts for smaller communities.

Perhaps if you need a comprehensive toolkit that supports the various widgets and gestures in contemporary toolkits, it is a big undertaking (probably not that massive, IMO).

A minimal toolkit that can do interesting things is a few weeks of work in Haskell. Here's an implementation of one: https://github.com/Peaker/bottle/tree/master/bottlelib/Graph...

It is incomplete and non-comprehensive, but adding the nuances needed to make it more complete and comprehensive wouldn't be too much work (it's simply not our focus in the project).

I was citing the amount of work to create a minimal acceptable toolkit to a programmer on the street, the sort of toolkit you'd point a hostile Python programmer to to say "Yes, we have a native toolkit", not the toolkit that you'd use to convince an already-converted Haskell user. Bear in mind that Tk prior to their relatively recent theme work was not that toolkit either! And that was actually a pretty decent kit, with layout managers, a nice text widget, tabs, all the basic stuff you'd need, if not the fanciest ever.

* It is incomplete and non-comprehensive, but adding the nuances needed to make it more complete and comprehensive wouldn't be too much work*

So it's minimal AND incomplete. Not even minimal and complete. That's what the parent was saying. And it will likely stay that way (as it's not even your focus in the project), and be forgotten.

There are tons of toolkits like that.

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).

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.

Writing a word processor may indeed be boring but a lot of very cutting edge tech goes into something like Photoshop. I doubt you could write an acceptably fast Photoshop in Haskell but I'd be happy to be wrong.

I thought GIMP came with a Scheme interpreter built in? And of course AutoCAD has AutoLisp.

those are just for customization, invoking pre-determined functionality endpoints...

He asks about software WRITTEN in a FL.

I'm honestly surprised to see people make this claim still. I only pay substantial attention to the Haskell community and there are a lot of high quality non trival projects built in Haskell. As another comment mentioned, Yesod is one, but there are also Happstack and Snap for web frameworks. Leksah is a functional but still very early IDE, Gloss is a great data visualization toolkit, Threadscope is a nice tool for postmortem program analysis, Yi is a Alpha/Beta stage Emacs/Vi clone. The list goes on, there are also (literally) 100's of libraries for doing all sorts of things that have nothing to do with glorified calculators.

And that's just Haskell, I know that the Clojure folks are doing lots of interesting stuff, and the Erlang folks too. I honestly have no idea what is being done in F# but I assume it's being supported for a reason.

I don't think anyone has _proven_ that FP strictly better than imperative style (though I think it is). However, I think it's been amply proven that it's at least _as good as_ imperative programming. The argument that no one has ever built more than a glorified calculator hasn't been true for a long long time.

> (literally) 100's of libraries

We passed 4000 libraries last month :)

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

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.

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.

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.

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.

>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.

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.

>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.

> 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). 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.

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.

Reply on news.ycombinator.com