The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Interactive functional programming

I got a job recently where I have an opportunity to code in a functional programming language.  Unlike previous jobs where I worked more on interactive user interfaces (web and native-UI, in addition to multi-phase client-server protocols), this one has my day to day coding involved in data processing tasks.

My programs are started with all of the input parameters present, state well-described and easy to find and runs quietly until it happens upon a solution, which is then kicked out into the world in one blast to a text file or standard output or to a co-process.  No user-interaction whatsoever.  I find these programs written in such an FP style are quite elegant and border on sheer joy to write.

The other shoe will have to drop eventually though.  Pure FP is dealt a crippling blow when one introduces user-interaction.  If f(x) returns a one time and b another time, that means side-effects, mutable data, and ultimately: game over.  The fantasy is destroyed.  Can I cope?  Is FP really cut out for "the real world"?
Michael B
Friday, November 21, 2008
 
 
Excel spredsheets are functional programming, and people have been using them for years... so what's the problem?
quant dev Send private email
Saturday, November 22, 2008
 
 
"Excel spredsheets are functional programming"

Really?

Pure functional programming doesn't support state or "variables" in the normal sense - which is arguably what spreadsheets are all about.
Arethuza
Saturday, November 22, 2008
 
 
Functional programming has input, doesn't it?

Cells with data are input.

Cells with functions are parts of a functional program which is run when you recalculate your spreadsheet.

Sure, Excel breaks this model somewhat by allowing you to recalculate just the part of your cells -- but that's analogous to having a debugger attached to your functional program.

The crucial similarity is that when designing an Excel spreadsheet, you try to avoid imposing the order of recalculation on the user. Ditto FP.
quant dev Send private email
Saturday, November 22, 2008
 
 
I may be misunderstanding your Excel scenario, but aren't you effectively re-running the entire calculation each time you change a cell?  Isn't that a) merely moving the FP-impure elements to the top-level (in this case, the user), and b) inefficient since many identical expressions are needlessly re-evaluated?

Is this where someone says "monads"?
Michael B
Saturday, November 22, 2008
 
 
Actually, when one changes a cell in Excel, it's excel job to figure out which cells need to be recalculated, and in what order.

The result is logically equivalent to recalculating everything, but that doesn't mean that Excel really does that.
Walter Mitty Send private email
Sunday, November 23, 2008
 
 
"Pure FP is dealt a crippling blow when one introduces user-interaction.  If f(x) returns a one time and b another time, that means side-effects"

But why would f(x) suddenly return b?  If the user input is the same, then the user will obviously expect the same result and so f(x) should return a as usual.  If the user input is different, then you're calling f(y), not f(x).

Now, in practice it is indeed true that user interfaces can be easier to write with state.  So what you do is have state in the user interface, then do all the behind-the-scenes work in your pure FP style.  End result: easy to write the user interface, easy to parallelise the behind-the-scenes work.  That's what people are excited about.  FP doesn't have to be a be-all-and-end-all, it just has to be useful enough to make it into your toolbox.
Iago
Sunday, November 23, 2008
 
 
"I may be misunderstanding your Excel scenario, but aren't you effectively re-running the entire calculation each time you change a cell?  Isn't that a) merely moving the FP-impure elements to the top-level (in this case, the user), and b) inefficient since many identical expressions are needlessly re-evaluated?"

Well the same problem occurs in a Haskell interpreter, if you define a complicated algorithm as an FP problem, you may find yourself computing some expensive f(x) more then you want. Without some imperative driver doing the caching, this can be slow. But does it mean it' not pure FP? It depends -- after all, all FP languages are finally implemented in imperative machine code, aren't they?

My point is that Excel makes the user think in a functional way ("tax is calculated from net profit which is calculated from the sum of cash inflows minus cash outflows"-sort of thing), not in an imperative way ("first add cash outflows, store them in X, then add inflows, store them in Y, store the difference in Z and multiply by 0.19"-like). That is, I believe, the essence of FP, isn't it?
quant dev Send private email
Monday, November 24, 2008
 
 
"Now, in practice it is indeed true that user interfaces can be easier to write with state."

Whenever a program operation takes more than a few seconds, you can't really make it stateless, you must have a distinction between running/idle, progress report, logging, alarms, etc.
quant dev Send private email
Monday, November 24, 2008
 
 
I should have been more careful with my terminology, because of course even a functional program has state.  The issue is _mutable_ state.  And while it's possible to write a user interface without mutable state, it's a hard problem.  (Who here understands monads?  Not I, for sure!)

Therefore the most practical approach is to use mutable state in the UI, even if the calculations are being performed in a purely functional manner.  I'm under the impression that you basically agree with this, and we're merely phrasing things differently.

"Well the same problem occurs in a Haskell interpreter, if you define a complicated algorithm as an FP problem, you may find yourself computing some expensive f(x) more then you want. Without some imperative driver doing the caching, this can be slow."

I'm not sure I fully understand what you intend to say here.  Yes, there's imperative code at the heart of any functional language, because it's not possible to store the result of a calculation in memory without mutating that memory.  But that line of argument doesn't really lead anywhere.

Once you accept that it's possible to get the result of f(x) in a purely functional way, then you don't need an imperative driver to reuse that result anywhere else you see f(x).  Indeed, this is the advantage of FP over imperative code -- in FP, you _can_ simply reuse that result wherever you see f(x), whereas in an imperative program you would have to worry about side effects, and essentially the programmer is required to implement caching if it's safe to do so.  In FP, you get that caching automatically for free.
Iago
Monday, November 24, 2008
 
 
You should use the IO Monad for interaction.

The IO Monad is a set of type and functions which wrap a data type into a 'sequencer', which forces sequential evaluation, and therefore allows a variable to be 'updated'.

The value is not really updated, a new instance of the value is created which happens to take the place of the old value. But it is a nice trick, although it's boring to have to read 'IO' all over the program.
Achilleas Margaritis Send private email
Tuesday, November 25, 2008
 
 
>My point is that Excel makes the user think in a functional way ("tax is calculated from net profit which is calculated from the sum of cash inflows minus cash outflows"-sort of thing), not in an imperative way ("first add cash outflows, store them in X, then add inflows, store them in Y, store the difference in Z and multiply by 0.19"-like). That is, I believe, the essence of FP, isn't it?

These seem effectively the same to me:
You have a cell for net profit: =cashInflows-cashOutflows
Then a cell for tax: =netProfit*0.19

How is this different to the imperative way?
not the nonno
Tuesday, November 25, 2008
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz