

You, Too, Can Be on the Cutting Edge of Functional Programming Research - tl
http://prog21.dadgum.com/138.html

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

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

~~~
eru
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
    

vs

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

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

~~~
jerf
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
What about going onto, say, Linux and making your own graphical toolkit from
the ground up?

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

~~~
Peaker
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...](https://github.com/Peaker/bottle/tree/master/bottlelib/Graphics/UI/Bottle)

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

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

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

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

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

He asks about software WRITTEN in a FL.

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

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

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

