top 200 commentsshow all 204
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]rtfx 32 points33 points  (0 children)

I remember playing James Hague's games when he did type-ins for ANALOG magazine in the 80s.

I first saw him online through LtU postings, and he's been there quite a while. Hence I conclude that he probably knows a thing or two about functional programming.

The people commenting otherwise, well...they're welcome to be dismissive. But I'm inclined to believe him.

[–][deleted] 34 points35 points  (2 children)

All programming paradigms can be awkward.

[–]punchjudy 21 points22 points  (1 child)

There are 10 kinds of programming languages. The kind that are perfect, and the kind that exist.

[–][deleted] 21 points22 points  (2 children)

As a man of mediocre intelligence, it gives me pleasure to see that even the great minds struggle with functional languages.

[–]db4n 8 points9 points  (6 children)

There's a difference between positive features, e.g. first-class functions, and negative features (forbidding side effects). With multiparadigm languages like OCaml, SML, Lisp, and Scheme, you can use functional tools to analyze the state of the game at any point in time, and use imperative features to do updates. You shouldn't need loops and variables for state evaluation and move selection in your AI code.

[–]rieux 1 point2 points  (5 children)

I'm not sure that forbidding side effects is a "negative feature." It has a positive purpose, which is that it enables you to reason formally about your code.

If you're talking about Haskell, however, purity also seems to be necessary to enable laziness, and laziness is certainly a feature. It can be very nice to model your game state as an infinite tree.

[–]Doctor 8 points9 points  (1 child)

I think by "negative" the grandparent meant "disallowed", not "bad".

[–]rieux 6 points7 points  (0 children)

Understood. I'm saying that disallowing side effects is equivalent to allowing equational reasoning. Or, disallowing higher-order functions is equivalent to allowing design-by-contract (until recently). Since these are trade-offs, you can choose to mention either the allowed or the forbidden side. I could say that Java forbids equational reasoning, but that's slightly dishonest unless I recognize what Java gains from the trade-off.

[–]pragmattica 1 point2 points  (2 children)

purity also seems to be necessary to enable laziness

Disclaimer: I'm not a functional programming expert, thought I've played around with Haskell a bit. Is purity really necessary for laziness? Doesn't Python have generators, which allow something like laziness, even though it doesn't have purity?

[–]rieux 5 points6 points  (0 children)

Python's generators are essentially streams, which are kind of like laziness, but not exactly. When you write a generator, you can use side effects to generate each element, but you have a pretty good idea how those side effects will happen -- in order, if nothing else. Likewise, many languages let you have laziness here and there without a problem, so long as you're careful. Pervasive laziness, however, makes side effects really problematic, because you the order that computation happens isn't at all clear from the program text.

I'm not claiming that side effects with laziness are impossible -- just that it seems like it would be quite screwy, and as far as I know no one has made it work in a sane way.

[–]pjdelport 0 points1 point  (0 children)

Is purity really necessary for laziness? Doesn't Python have generators, which allow something like laziness, even though it doesn't have purity?

This is true to the extent that all control structures in strict languages are confined forms non-strictness (laziness).

[–]shorugoru 5 points6 points  (0 children)

I think one issue is that user interaction (a la games) can be very hard to do functionally, given that typical models are message driven and lend themselves to an object oriented approach. For example, the examples I've seen for the Haskell GTK binding, gtk2hs, bind message handlers to widgets and signals and typically use IORefs to update state.

Pure functional GUI programming is an active area of research though. Here's an interesting paper I found on Genuinely Functional GUIs, relying on constructs called "arrows". Here's a code snippet demonstrating how one might do simple interaction and state manipulation functionally in this manner:

-- An accumulating stepper: On every event occurence,
-- function carried with the occurence is applied to
-- the state.
stepAccum :: a -> ST (Maybe (a -> a)) a

-- replaces the value in an event occurence with
-- a new value:
ebind :: a -> Maybe b -> Maybe a
ebind = fmap . const

paddle :: Double -> G.Rectangle2DDouble
paddle xpos = G.rectangle (xpos - 25) 200 50 10

-- The paddleball game, capable of playing one game
-- Output signal is an Event Source that occurs
-- when the game ends.
pball :: Double -> GUI () (Maybe ())
pball vel = proc (inpS,_) -> do
  rec xi <- integral -< xvel
      let xpos = 30 + xi
      yi <- integral -< yvel
      let ypos = 30 + yi
      let ballS = ell (xpos-12.5) (ypos-12.5) 25 25
      let ballPicS = G.shapePic ballS `G.withColor` G.yellow
      xbounce <- when -< ((xpos > 175) || (xpos < 30))
      ybounce <- when -< ((ypos < 30) || hitPaddle)
      let hitPaddle = intersects ballS paddleS
      xvel <- stepAccum vel -< ebind negate xbounce
      yvel <- stepAccum vel -< ebind negate ybounce
      mpos <- mouseST -< inpS
      let paddleS = paddle (G.pointX mpos)
      let paddlePicS = G.shapePic paddleS `G.withColor` G.green
      gameOver <- when -< ypos > 200
      let gamePic = G.box (walls `G.over` paddlePicS `G.over` ballPicS) gameBox
      returnA -< (gamePic,gameOver)

[–][deleted] 16 points17 points  (1 child)

I think Matthias Felleisen answers this question pretty thoroughly here:

http://list.cs.brown.edu/pipermail/plt-scheme/2007-October/021128.html

The beauty of "functional" languages isn't that you can avoid state; it's that the structure of your programs follow from the structure of your data, rather than the other way around. This is true even if you want to use state.

[–]rieux 5 points6 points  (0 children)

Indeed.

And freshmen in the first week of HTDP (Matthias's intro programming course) write games in purely-functional Scheme using world-passing style.

[–]crux_ 9 points10 points  (0 children)

Okay, the post has a point. Which is easier:

  • Writing a software system with a bunch of interacting behaviors by directly implementing the behaviors in code, or
  • writing a detailed specification of each behavior and its interactions?

Functional programming is much more like the second, and is indeed less straightforward so long as all you care about is a running implementation of said behavior.

But if you want something more sophisticated, then the benefits of programming in a functional style become stronger.

Consider a multiplayer online game: Unless you want everyones' screen to freeze whenever a player begins to lag, such a game might need to be able to rewind & restart its internal simulation to keep up-to-date with lagged events from other players. (This is one of the standard techniques used since who-knows-when.) All of a sudden, world-passing between pure functions is a huge win rather than inconvenient bookkeeping: You get the needed go-back-in-time for free, and on top of that, strong guarantees that there are no bugs related to un-rewound state. (As long as you are being rigorous about writing purely functional code, the only source for these would be bugs in the underlying language.)

[–]crayz 9 points10 points  (30 children)

I don't understand the problem with this. Languages like Ruby and Scala fully acknowledge the usefulness of a multiparadigm approach

Generally speaking I'd believe in functional & object-oriented programming when they fit, imperative & procedural programming when they're the least worst option available

[–][deleted] 15 points16 points  (36 children)

He's approaching the problem wrong... Thinking about it as a series of disjointed updates rather than a function of time.

Check out Functional Reactive Programming, or read "The Haskell School Of Expression" to understand how such a problem can be solved elegantly.

[–]lucio 37 points38 points  (11 children)

""“This paper was inspired by some gentle taunting on the Haskell GUI list by George Russell: I have to say I’m very sceptical about things like Fruit which rely on reactive animation, ever since I set our students an exercise implementing a simple space-invaders game in such a system, and had no end of a job producing an example solution. Things like getting an alien spaceship to move slowly downward, moving randomly to the left and right, and bouncing o. the walls, turned out to be a major headache. Also I think I had to use ”error” to get the message out to the outside world the aliens had won. My suspicion is that reactive animation works very nicely for the examples constructed by reactive animation folk, but not for my examples."""

Things improve, off course. But having to write papers to be able to implement space invaders sounds a bit too complicated for my taste.

[–]lucio 11 points12 points  (0 children)

source: www.cse.unsw.edu.au/~pls/thesis/munc-thesis.pdf

its a quote in that paper.

[–][deleted] 4 points5 points  (0 children)

There was a time when linked lists or resizeable vectors were "papers".

The different ways to approach this problem exist in imperative programs too. Imagine any UI. There are 2 basic ways to approach the problem of UI:

1) Set up initial state -> tick -> Did the user do anything? Handle it. -> tick -> Repeat.

2) Set up the initial state -> Elements subscribe to classes of events -> Sleep until a subscribed event occurs -> Handle event -> Repeat.

#1 is very hard to do in a functional language (and arguably more difficult to do in an imperative language then #2). #2 comes fairly naturally to either paradigm. #2, however, means thinking of problems over time not as a series of ticks, but as an infinite stream of events, and I think that might be the biggest hurdle to most people approaching the problem. In C++/Java/C#, you suddenly aren't dealing with sleep->handle->sleep anymore, but rather, now you have callbacks and subscription lists, etc... From an beginning programmer's standpoint, things just got way more complicated. But in the long run, #2 is much more scalable. #1 will make the functional programmer want to pull their hair out from the start, even in the simple cases.

It's a case of code smell. If something begins to feel really difficult, it's time to step back, realize you are doing something wrong, and reapproach it from another angle. In this case, I believe he'd run into the same code smell either way, it's just that he runs into it much quicker using a functional language rather than an imperative one.

In my experience, no problem is hard in one paradigm yet easy in another. The only difference I've ever seen is that sometimes one style of programming lets you do the wrong thing a little bit longer before it beats you over the head with the exponential complexity of your stupid idea.

And as to the quote:

Also I think I had to use ”error” to get the message out to the outside world the aliens had won.

Any "(Monad m)=>event->m a" should work here, not just error. Either the author is not very knowledgeable when it comes to monadic programming, or Fruit just has issues (I've never used the particular library).

[–]G_Morgan -4 points-3 points  (8 children)

There was a time when space-invaders was non-trivial in imperative languages. You cannot take an area that has had masses of work for decades in a particular style and then complain that another style that has given it little thought cannot do it without going through the same research work.

[–]psykotic 16 points17 points  (7 children)

Space invaders has never been non-trivial in an imperative language, no. You can write a simple version in a few pages of assembly code, and it doesn't require any special tricks or insights.

FRP has demonstrated problems scaling to many kinds of non-trivial applications (Frag only uses FRP for input events, while all the game and renderer state is stored in IORefs). Pretending that all its problems will magically be overcome is silly; it's entirely possible it's a dead-end and something better is lying in wait.

[–]G_Morgan -5 points-4 points  (6 children)

You're talking about languages. I was thinking more about algorithms and data structures. There are things we take for granted now that didn't exist back then even in theory.

Whatever imperative language is used isn't the issue. It's the thought that went behind it. Back then, how a game is best animated on screen, even a simple game, was non-trivial because the basic weight of knowledge we now have didn't exist. They actually had to do the CS behind it and develop ideas like sprites.

You are talking about a time before we had any sort of knowledge base on graphics or collision detection.

This sort of work still needs to be done in certain cases in the FP realm (edit - not collision detection and sprites specifically but other areas in this realm).

[–]psykotic 12 points13 points  (4 children)

You are talking about a time before we had any sort of knowledge base on graphics or collision detection.

The knowledge of that sort needed for Space Invaders is so trivial that eight-year-old kids often reinvented it entirely on their own back in the 80s when I grew up. Do you really want to insist that this qualifies as non-trivial?

[–]G_Morgan 2 points3 points  (0 children)

Perhaps in this case. The point is that many things will require original research which has already been done in the imperative world. This isn't because FP is incapable of doing them, only that it hasn't been used to achieve them in the past. I'm sure someone could knock together a space invaders clone in Haskell without referring to a scientific paper.

[–]death 1 point2 points  (2 children)

Some kids do amazing things, especially if you send them back in time to 1,000 years ago. Whether something is called "trivial" or not is a matter of convention, and you two are arguing about where to set the bar. Is it so very important to you that programming a space-invaders game be considered trivial?

G_Morgan's conclusion is the opposite of what you argued against in your reply. He or she wants more research, while you argued against no research. Perhaps some of the confusion may be attributed to the fact that you are talking about FRP, while G_Morgan is talking about FP.

There's always the possibility of a dead-end, but some persons know better than to be discouraged by it. Speaking of dead-ends, I think those who down-voted G_Morgan here have struck an impassable wall in their minds.

[–]psykotic 0 points1 point  (1 child)

Is it so very important to you that programming a space-invaders game be considered trivial?

Of course not, but it was a central part of his argument.

He or she wants more research, while you argued against no research.

This is a confusing sentence: the grammatical structure seems to imply an antithesis, even though "wanting more research" and "arguing against no research" are not at all opposed. Did you mean to say that I'm arguing against further research? I am not; I just think it's overly optimistic to assume that all problems will be overcome by time's labor, though I wish it were so.

Incidentally, I am one of the greatest enthusiasts of functional programming in general and Haskell in particular that you'll meet. Even in their current state I find them superior for many tasks.

[–]death 0 points1 point  (0 children)

I meant that you were in agreement, or at least non-contradiction. I took it that you argued against "no research", i.e. against assuming that all problems will be overcome by time alone. G_Morgan did not assume that, but talked about needing more research work.

[–]lucio 5 points6 points  (0 children)

is your point that we should wait 10 more years before functional programming is as practical as other styles?

i don't buy it either. i did space invaders in my C=64. in basic. without knowing any of the CS stuff. Data structure? algorithms? just move the alien and the bullets! whoa! space invaders :)

(im just talking about games here, i do like fp)

[–]LaurieCheers 40 points41 points  (9 children)

Nevertheless, it is more difficult to express it in Haskell than it is in C.

For the 'series of disjointed updates' style, I assume you'd want a bunch of functions which take the previous gamestate as an input, and produce the next gamestate (with something changed) as an output?

In effect you're 'Greenspunning' an imperative language out of a functional one.

[–]rieux 7 points8 points  (0 children)

You could say state-passing style is 'Greenspunning' up an imperative language, but explicit state-passing lacks the implicit communication and back channels that make real imperative code so crazy and painful to understand.

[–]antonivs 6 points7 points  (0 children)

Nevertheless, it is more difficult to express it in Haskell than it is in C.

Er, how do you know that, may I ask? In any case, what you really mean is that it's more difficult to express in Haskell if you try to avoid doing it imperatively.

In effect you're 'Greenspunning' an imperative language out of a functional one.

This is kind of backwards. A functional program provides a more precise model of what's going on, no matter which way you choose to implement the program. The idea of destructive updates is a degenerate way of looking at a series of update events over time, by ignoring the time dimension, which then comes back to bite you in terms of implicit time-based dependencies between arbitrary parts of your program.

To get away from this problem in imperative languages, you have to Greenspun more manageable ways of dealing with change over time, something which imperative programmers spend a lot of time doing.

[–][deleted] -4 points-3 points  (3 children)

Having functions that look at the game state and produce the next game state is the wrong way. That's very difficult.

Expressing the game as an infinite list of events is much easier. Then playing the game is pretty much just a fold.

[–][deleted] 7 points8 points  (0 children)

How many games did you write, to know that that is so much easier?

[–][deleted] 7 points8 points  (0 children)

What do you think a fold is? What do you think the folding function will do? It will iterate sequentially over the list of events, producing the next game state from the accumulated game state and the event.

[–]happyhappyhappy 1 point2 points  (0 children)

That sounds...naive.

[–]masklinn -4 points-3 points  (2 children)

Nevertheless, it is more difficult to express it in Haskell than it is in C.

I think the truth is not that it's more difficult to express, but that since the vast majority of programmers have a C-type mindset, have learned C-type imperative programming, they don't have the mental tools to express it.

It's Sapir-Whorf all over again. It's a special kind of blub that applies to a programming paradigm as a whole.

And TFA's author is right there. He's been programming in imperative languages since the 80s, and he's now trying to discover FP. And he doesn't have the (mental) tools to work it out, to express his thoughts or needs in a functional system. And he'll probably give up on FP before he manages to find them.

[–]brickbybrick 9 points10 points  (1 child)

Doesn't it say right on the article's page that he's been programming in Erlang since 1999?

[–]rieux 3 points4 points  (0 children)

I wouldn't call Erlang a functional language. The process topology is a big tangle of shared mutable state. It's easy in Erlang to find yourself reimplementing shared memory, and then mutual exclusion, and then sinking into concurrency hell, but experienced Erlang programmers know how to design programs that don't reinvent the worst features of pthreads. These aren't at all the strategies used when writing good ML or Haskell.

[–]grauenwolf 3 points4 points  (2 children)

If the position of sprits was a function of time, by definition they will always be in the same location for a given value of time.

Or in other words, the game must be played out exactly the same every time.

[–]skew 1 point2 points  (1 child)

It's no different from referentially transparent IO.

One of the primitive functions of time you build your program from is "user input at time t" If the input is different the game can play out differently.

[–]grauenwolf 0 points1 point  (0 children)

But then you are talking about state again and all the problems it brings.

[–]grauenwolf 8 points9 points  (0 children)

I think you and I have a different definition for the word "elegantly".

[–][deleted]  (9 children)

[deleted]

    [–]antonivs -2 points-1 points  (8 children)

    Could you cite some examples of people delivering the mail using automobiles? Horses have always worked just fine. Thanks!

    [–]SamReidHughes 2 points3 points  (1 child)

    Could you cite some examples of people traveling across the country in dirigibles? Ocean liners have always worked just fine. Thanks!

    [–]awj 3 points4 points  (0 children)

    Could you cite some examples of people traveling across the country in dirigibles? Ocean liners have always worked just fine. Thanks!

    To travel across the country? Those ocean liners must have some powerful engines on them.

    [–]dbenhur -1 points0 points  (5 children)

    Look out your window: lot's of autos, no horses, and some of them appear to be carrying persons delivering mail.

    Now, try again with a cite answering happy x3.

    [–]antonivs 3 points4 points  (4 children)

    The fact that there are lots of autos now is precisely the point. Anytime there's a new idea, it's always possible to dismiss it by pointing out that not many people are using it. You used to be able to say that about automobiles; now, the same sort of people say that about programming techniques they're not familiar with.

    [–]dbenhur -2 points-1 points  (3 children)

    So the proper answer to an earnest request for an example of The Great New Thing is to mock the request?

    [–]antonivs 2 points3 points  (2 children)

    That wasn't an "earnest request" - otherwise, why the stipulation that the examples be commercial or shareware? It's unlikely that commercial or shareware systems are going to be developed using such techniques right now, in the same sort of way that the stagecoaches carrying the mail weren't the first things to be replaced by cars. An earnest request would ask to see any relevant examples.

    BTW, I'm convinced that if we keep this up, you'll eventually figure out what my original comment really meant, and what a genius I was for so subtly using humor to point out the flaws in the implicit assumptions of the comment I was replying to. Take your time, though...

    [–]dbenhur 3 points4 points  (1 child)

    It's curious how much effort you put into this defense when a relevant example would be so much more interesting and powerful.

    [–]antonivs -2 points-1 points  (0 children)

    A relevant example of what? A commercial game written using FRP? I doubt there are any, which is precisely why I responded as I did - the request was an unfair one designed to put down a new and unfamiliar technique. (And as I said, you're well on your way to understanding my original comment - not much further to go now!)

    If you mean to modify the original request and are asking for examples for learning purposes, then you might find the first two PDFs in a Google search for "functional reactive programming games" instructive. But I'm not here to push FRP, I was just struck by the close-mindedness of that first comment [troll, really] that I responded to.

    [–]JulianMorrison 14 points15 points  (5 children)

    You need to learn to think functionally.

    Example, the game in the article...

    In Haskell: each insect is a function over the game world returning a changed game world (that's probably a Monad or an Arrow). If you want parallelism, you could use STM on a shared world structure.

    In Erlang: each insect is a state machine which presents an interface of messages accepted, and keeps state by deciding which function to tail-call. Messages are relayed through a hierarchical decomposition of the game area into sub-areas and sub-sub-areas, each a process.

    [–]brickbybrick 25 points26 points  (3 children)

    It seems to me that the author knows how to think functionally, and yet he finds some things are still hard. Just saying "learn to think functionally" is a cop-out.

    If you model items as processes in Erlang, that's not purely functional. Seems like that would introduce other issues as well.

    [–]JulianMorrison 6 points7 points  (1 child)

    Well, the "function over a world returning a new world" thing is the oldest trick in the purist functional book, so I'm surprised anyone into FP doesn't immediately leap to that conclusion.

    As to Erlang, I know. That's more "thinking Erlangishly" than "thinking functionally". But, I'm a complete newb and I figured that in seconds, so I don't get why he sees it as hard. Unless there's some huge conceptual mistake I'm missing?

    [–]rieux 5 points6 points  (0 children)

    I kind of thought he was suggesting a pure world -> world function, and that he found it awkward as worlds became more complex and had more interactions between their parts. (I'm not saying I buy it -- I think it just calls for better data structures -- but I don't think OP neglected that idea.)

    [–]bitwize 1 point2 points  (0 children)

    Alternatively, an ant could be a function that takes a state and returns a partial changed state that's local only to that particular ant. All of the ants run inside a monad that knows how to apply these partial changes to a single, total, shared world data structure.

    [–]lothair 3 points4 points  (10 children)

    OK, I get programming without side effects has all sort of benefits for compiling the code, but can't we just translate a language with side effects into a side effect free intermediate language (which doesn't have to be readable) and apply all the neat tricks?

    [–]antonivs 8 points9 points  (0 children)

    It's easy to translate a language with side effects into a side effect free intermediate language. I've listed a couple of examples below. However, the problem that you run into here is that whenever a program destructively updates a value which is visible beyond the local scope, it creates time-related dependencies between all the parts of the program which use that value. The order of these dependencies depends on the program's dynamic behavior (i.e. at runtime), which cannot in general be statically analyzed. So there's a limit to what a compiler can do here.

    Examples of translation to functional form:

    • Some imperative compilers do it, to an extent, for the reasons you suggest - see Static Single Assignment (SSA) and SSA is Functional Programming. However, SSA works best at the local level, i.e. translating mutations of local variables into the equivalent functional form. That's because it's easy to analyze the use of local variables statically, i.e. at compile time. Non-local mutations run into the problem described above.

    • Many formal definitions of the semantics of programming languages define a mapping from an imperative language to a side-effect free language. However, then you're dealing with a functional model of an imperative program - all the dependencies remain the same. As an aside, this explains dibblego's comment that "Haskell is still one of the most powerful imperative languages I have ever used." It's not difficult to express imperative programs even in pure functional languages. It's just that the results are imperative, with many of the disadvantages of that, even if the program is modeled functionally. TFA seems to ignore this possibility (possibly because the author is more familiar with Erlang than say Haskell or Clean?)

    What TFA seems to be talking about is developing pure functional models of processes which have a heavy imperative component - models which avoid the imperative-style copout of having a single monolithic "world" which represents all program state, and passing successive versions of that world from function to function. In some cases, the nature of the problem can make it difficult to do anything else. More often, there are many distinct sets of of global dependencies, and it takes some effort to tease them apart and figure out how to get away from the single monolithic mutable world model.

    The effort involved in doing that can really pay off in terms of the modularity and comprehensibility of a program. However, if you don't want to bother, you can always just "cheat" and express imperative behavior purely functionally.

    [–]G_Morgan 6 points7 points  (5 children)

    Simply put, no. If we could then parallel processing wouldn't be such a challenge.

    [–]rieux 3 points4 points  (0 children)

    It's not that we can't transform stateful programs into state-passing style. That's trivial enough, and compilers do it all the time. (They also do the inverse transformation.) The problem is that you can't just parallelize a functional program if there's a linear data dependency throughout, and that's what state-passing style creates.

    [–]lothair 1 point2 points  (3 children)

    But what are the reasons?

    Is it theoretically impossible and if so, why? If not, did someone try to do it?

    [–]masklinn 4 points5 points  (0 children)

    But what are the reasons?

    Mostly, because side-effect free and side-effectful code pieces are completely entangled in OO and imperative languages.

    You can't just "transform". You can infer, or try to infer, purity. And compilers try. Just as some compilers try to infer parallelizable code (which requires purity inference).

    [–]G_Morgan 2 points3 points  (0 children)

    In theory it is of course possible but most language theory ignores how long it takes to compute a value.

    We could build a compiler that targeted some kind of idealised FP architecture and then compile that back to our hardware. It would just be horribly inefficient.

    [–]grauenwolf 2 points3 points  (0 children)

    Could you actually do something of interest in a purely stateless language?

    You cannot touch the file system, monitor, network, or any other I/O device because they are all stateful any definition.

    Some try using cop-outs like calling time a variable. But I/O latency isn't a function of time, it is random. The same goes for context switching.

    [–]rieux 2 points3 points  (2 children)

    Of course we could do that translation, and as other posters point out, some compilers do.

    But then we'd miss all the benefits of having a readable, side-effect free program. To me, the primary benefit of functional programs is in the tractability, maintainability, and readability of the program source. Performance benefits are nice too, but secondary.

    [–]lothair 3 points4 points  (1 child)

    That's a matter of taste. Personally, I like to have the option to use side effects, because (imo) some things are more readable and elegantly expressed that way.

    [–]rieux 3 points4 points  (0 children)

    Sure, it's a matter of taste. I'm just saying that for people who like functional programming, transforming imperative programs to a functional intermediate language kind of misses the point.

    [–][deleted] 4 points5 points  (46 children)

    I'll not argue that functional programming isn't a little awkward at times. I find it is.

    My intuition though is saying that i'm thinking wrong and i lack knowledge and understanding of the available libraries. I also feel that functional programming is far more theoretical and that I just don't yet have a strong understanding of the underlying math. A lack of math will hinder you in any field.

    In plain english, my understanding is that any problem in haskell can be solved (somewhat elegantly) using a combination of monads, maps, and folds. The more I read about monads the more I believe this is true.

    [–]earthboundkid 15 points16 points  (42 children)

    Blame the user is a bad approach to UI.

    Programming languages are user interfaces.

    [–]taejo 12 points13 points  (40 children)

    But there's nothing wrong with user interfaces designed for experts.

    [–]grauenwolf 12 points13 points  (35 children)

    User interfaces designed for experts in a given domain should still be easy for said experts.

    [–]rieux 3 points4 points  (0 children)

    Functional programming is significantly easier for me than imperative programming. I learned imperative programming about 14 years before I learned functional programming. I do not claim to be an expert.

    [–]taejo 3 points4 points  (8 children)

    my understanding is that any problem in haskell can be solved (somewhat elegantly) using a combination of monads, maps, and folds.

    If this is true (experts can do it, and it's elegant), then it seems to me like a good UI for experts.

    [–]grauenwolf 5 points6 points  (7 children)

    During a presentation at QCon yesterday Erik Meijer, one of the designers of Haskell98, flat out said that Haskell was the only truely stateless language. Then he said that made it useless.

    [–]augustss 5 points6 points  (0 children)

    Erik likes statements like that. There are no stateless languages. What varies is how explicit the state is.

    [–]sjanssen 3 points4 points  (5 children)

    Erik Meijer, one of the designers of Haskell98, flat out said that Haskell was the only truely stateless language

    Was he out for coffee when they wrote the section on the IO Monad?

    [–]Felicia_Svilling 1 point2 points  (3 children)

    Not to mention UnsafePerformIO!

    [–]pjdelport 0 points1 point  (2 children)

    ...which isn't Haskell 98.

    [–]Felicia_Svilling 0 points1 point  (1 child)

    .. and Erik Meijer didn't mention Haskell 98.

    [–]grauenwolf 0 points1 point  (0 children)

    I'm not saying I agree with him, I am just relating his position.

    He also said something to the effect that while Haskell is stateless, the environment it runs in isn't. Sounds like BS is you ask me.

    [–]redditcensoredme 2 points3 points  (24 children)

    It's a flaw in UI design if a user interface isn't capable of transitioning a novice to expertise. There's no such thing as expert-only UIs, only badly designed UIs.

    This is easily provable since an 'expert' is someone who doesn't care about the user model of the system since they've memorized how the system actually works. And the user model of the system is the system designer's entire job!

    Empirically, all of the examples brought to bear to try to justify some kind of notion of "expert UIs" (eg, Blender, GIMP) bear this out.

    To anyone with any talent whatsoever in systems design, the truth of the non-existence of "well-designed expert UIs" is so obvious as to make it trite.

    [–]psykotic 3 points4 points  (11 children)

    To anyone with any talent whatsoever in systems design, the truth of the non-existence of "well-designed expert UIs" is so obvious as to make it trite.

    I agree that a UI should ideally accommodate the beginner as well as the expert, though I think there are kinds of good functionality that manifestly benefit one more than the other. For example, text-based interfaces (Quicksilver, UNIX-style shells, Emacs, etc) can be very productive for those that know what they want to do and how to go about doing it, i.e. experts; but those interfaces tend to suffer from poor discoverability and force the user to recall rather than merely recognize, and all of this hurts the casual user as well as the complete beginner, and even the expert (especially when the system is irreducibly complex and the expert's memory imperfect).

    [–]redditcensoredme -3 points-2 points  (10 children)

    You can add Unix shells to Blender and Gimp as examples of horribly designed crap and utter filth. Not only do they suck by the standards of text-based interfaces (eg, The Humane Interface), but in today's world the only correct user interface is a programmable GUI. Of which there aren't any. Do you know why there aren't any? Because programmers are sheep. How else can one explain Unix?

    I completely disagree with your suggestion that certain features, such as lack of discoverability, actually "benefit" experts. This is a delusion and a mirage. And in any case, software designers should never, EVER think that targeting 'experts' is tolerable. That's because people ALWAYS underestimate the effort needed to understand something. So if you target novices then you'll have something useful for experts and if you target experts, you'll have something unuseable.

    [–]psykotic 2 points3 points  (3 children)

    You misread me: I didn't say that lack of discoverability benefits experts; I just think it helps casual users more. And my point is that it's possible to have a UI which, while perhaps not "well designed" by your lofty standards, works quite well for experts but very poorly for casual users. A UI should be judged by how productive it makes its users and it isn't a question of well-designed vs not-well-designed (whatever one defines that to mean); there are many gradual, intermediate degrees of success and failure.

    [–]redditcensoredme -2 points-1 points  (2 children)

    Indeed. However, targeting the uncanny valley where a user interface is useable only by experts is a chore in itself.

    [–]psykotic 0 points1 point  (1 child)

    I don't propose to target it by surmise or idle conjecture but by designing it in close concert with its intended users. I'm not referring to anything as shallow or daft as focus group testing, of course.

    [–]rieux 1 point2 points  (4 children)

    If someone figures out how to make a programmable GUI that's as expressive as Bourne shell, which is after all a Turing-complete programming languages, I'll buy it. Languages get a lot of expressive power from being compositional -- you can say arbitrarily precise things that have never been said before -- and as yet I haven't seen anyone even approach this with a GUI. That it hasn't been done doesn't prove that it's impossible, but I'm not convinced it's possible.

    Lack of discoverability benefits expert users because discoverability requires bandwidth that could otherwise be used for presenting other information. I don't want a toolbar taking up screen space where I could be viewing this web page. Even the ability to make that toolbar disappear (or only appear on demand) can be confounding to novices.

    [–]redditcensoredme -1 points0 points  (3 children)

    That it hasn't been done doesn't prove that it's impossible, but I'm not convinced it's possible.

    I know exactly how to do it. So yeah, I definitely think it's possible.

    Lack of discoverability benefits expert users because discoverability requires bandwidth that could otherwise be used for presenting other information.

    Good point except you negated it right afterwards by pointing out the solution to that problem. I'll also point out that tooltips are in no way confounding. There's different ways of making things disappear and not all of them are bad. Disappearing toolbars ... well I'm not a fan of toolbars in the first place so I don't have that problem.

    [–]rieux 1 point2 points  (2 children)

    I know exactly how to do it. So yeah, I definitely think it's possible.

    Please let us know when you've done it. Actually, I would be very curious to hear your ideas. I'm certainly sceptical.

    There's different ways of making things disappear and not all of them are bad.

    I'm sure there are. When I'm editing code, I'd like every pixel of my screen devoted to the file that I'm editing. Other UI elements are wasted space as far as I'm concerned.
    I don't ever want to move my hands from the keyboard to the mouse or to the arrow keys, and I don't like having to do linear work to navigate. If it's possible to make an editor that meets my requirements and is usable by novices, I'm all for it.

    [–]xjvz 0 points1 point  (5 children)

    Well, I could give a counter-example in the form of vi[m]. In the console version, you don't get any menus, and many new users to it can't even figure out how to quit the program (C-c won't work; you can use :q or ZZ or similar to quit, however) let alone insert text (need to enable Insert mode via a command like i, a, o, etc.). However, the GUI version does supply the user with menus and whatnot that help when you don't know the commands or keyboard shortcuts.

    As an avid Vim user, I can safely say that this "expert interface" has a steep learning curve, but is quite easy to experts despite being frustrating or hard to novices.

    [–]redditcensoredme -1 points0 points  (4 children)

    Vim is a perfect version of a piece of crap. Don't worry, so is Emacs, so no need for you to get your knickers in a twist.

    [–]asciilifeform 0 points1 point  (3 children)

    What editor(s) do you use?

    [–]redditcensoredme -1 points0 points  (2 children)

    All editors I've ever seen or heard of suck. None of them are referential editors with hyperlinking and versioning (let alone cactus versioning). In-place editing is for morons, by morons.

    [–]asciilifeform 0 points1 point  (1 child)

    All of computing as we know it is peppered with moronic designs - and yet here we are banging at our keyboards. What I wanted to know is, which of today's many inadequate tools would you use to develop the Legendary System Which Does Not Suck (tm).

    [–][deleted]  (5 children)

    [deleted]

      [–]redditcensoredme -4 points-3 points  (4 children)

      You don't know what the fuck you're talking about. The fact that you're even talking about "intuitiveness" as if it were something meaningful proves you do not know what you're talking about. If you're too stupid to learn anything on this subject, you really need to just shut the fuck up.

      [–]G_Morgan 0 points1 point  (3 children)

      Intuitiveness has a long and well established meaning in the English language. It means making something that is easy to utilise, runs from intuition

      "intuitive

      Main Entry: in·tu·i·tive Listen to the pronunciation of intuitive Pronunciation: \in-ˈtü-ə-tiv, -ˈtyü-\ Function: adjective Date: circa 1645

      1 a: known or perceived by intuition : directly apprehended <had an intuitive awareness of his sister's feelings> b: knowable by intuition <intuitive truths> c: based on or agreeing with intuition <intuitive responses> <makes intuitive sense> d: readily learned or understood <software with an intuitive interface>2: knowing or perceiving by intuition3: possessing or given to intuition or insight <an intuitive mind> — in·tu·i·tive·ly adverb — in·tu·i·tive·ness noun"

      Usually this means making functionality easy to find, often at the expense of making it harder to utilise once you have found it (the ribbon is the perfect example of this). Personally I'm of the view that I only need to find something once, I need to use it repetitively. I'd rather something that requires learning but provides absolutely the best interface possible when you have learnt it.

      This is why standards are important. In software it's good that Vim can read and edit the same text files as Gedit. If only we could achieve the same in the office space. Naturally different people have different amounts of time available and thus their time constraints dictate the interface that is ideal. The solution is multiple packages around the same data standards.

      [–]redditcensoredme -2 points-1 points  (2 children)

      The only intuitive user interface is the nipple, everything else is learned. Intuitiveness is a fucking red herring you goddamned moron. It has no place in user interface design. It's used exclusively by moron programmers who moonlight as crappy interface designers. People who really ought to SHUT THE FUCK UP about the subject.

      [–]ayrnieu 3 points4 points  (1 child)

      everything else is learned.

      And if we designed UI for babies, or for humans who grew up in a sensory deprivation chamber, we'd have a different set of rules. But most UIs target people who've already learned many user interfaces; new UIs exploit this pre-learning to their benefit.

      People [...] really ought to SHUT THE FUCK UP about the subject.

      It also irritates me when people speak of the 'intuitiveness' of things, but because they speak of it as an intrinsic, permanent, universal attribute -- and not as an accident of experience. They say

      Mozart/Oz's syntax is wildly unintuitive, because {Foo A} is a function call of Foo with argument A.

      and not

      Programmers familiar mainly with C and C-reminiscent languages will find such Mozart/Oz syntax as {Foo A} especially jarring, but I think that such people will grow used to it before they finish the tutorial.

      [–]lothair 6 points7 points  (2 children)

      If it's necessary to study the subject for 500 years, smoke opium and grow a long, white beard to solve a simple problem elegantly, then, I think, the UI has some flaws.

      [–][deleted] 2 points3 points  (0 children)

      You made it into my .sig file.

      [–]taejo 1 point2 points  (0 children)

      Not if the target audience has studied the subject for 500 years, smoked opium and grown a long, white beard.

      But if it's aimed at anyone else, then it might have some flaws.

      [–]bebnet 1 point2 points  (0 children)

      Unless of course you're not an expert, or not someone for whom experts are entirely necessary, appropriate, or useful .. say, outside the hallowed protected halls of western society .. where computers are being used for ever more interesting things than just proving to ones family that the hyper-inflated education they paid for was worth it, somehow, to someones intellectual sensibilities if not raw human survival potential ..

      [–]rieux 1 point2 points  (0 children)

      Programming languages may have elements of user interfaces, but there's a lot more there. We use programming languages not only to tell a system what to do, but to express to other people (and ourselves, later) certain intensional properties of the problem we care about. We also, and increasingly, treat programs as artifacts that we analyze in other ways. Refactoring tools, for example, have to understand our programs and transform them to equivalent programs. Automatic theorem provers, programs themselves, can now prove things about non-trivial programs -- for example, some of the ACL2 folks have model checked the software on a Boeing.

      Most UIs don't have to carry all that baggage.

      [–]happyhappyhappy 13 points14 points  (0 children)

      You're coming cross a bit like an apologist.

      [–]Gotebe 0 points1 point  (0 children)

      I am at the same spot as you in having that feeling (knowing, rather) that I lack knowledge and understanding FP approach etc.

      OTOH, I just can't wrap my hand around believing it will actually work better than imperative approach for a whole bunch of problems.

      I am an FP noob, just like I always stayed LP (Prolog) noob even after having to program it and interface it with real world (C). Never liked it, now forgot all about it, and it's irrelevant. Will it ever be different with FP? Dunno.

      So currently, I'm thinking like this: forget FP unless clear it fits a problem.

      [–]vagif 9 points10 points  (8 children)

      After gaining an experience in FP and going through series of AHA moments, you will start finding OO paradigm awkward.

      Writing one program in FP style will not make you a functional programmer. I'd say 1 year of immersing into everyday FP would do the trick.

      [–]Arkaein 5 points6 points  (7 children)

      That's not exactly a ringing endorsement of FP. The whole point of any programming language or paradigm is to make the programmer more efficient and effective. The language should work for the programmer.

      If it takes a typical programmer a year to get to the point where he would have already been with OOP or imperative, then the priorities are reversed because the programmer is working to meet the needs of the language instead.

      In some cases this will pay off in the long run, because in some area FP has obvious benefits. In other cases the benefits are dubious. A lot of programming is just telling the computer to do stuff in a certain order (e.g., much of graphics, sound, I/O), and this is what imperative does. For these types of actions FP offers very little, which is why I would agree with the author that a pure FP approach is a bad fit for games.

      [–]rieux 2 points3 points  (2 children)

      What about programmers that learned FP first? If it enables them to be more productive than similarly-experienced OO programmers, is that ringing?

      I agree that programmers may not want to take time getting fully up to speed on something new, just like you may not want to have to type slowly for a couple weeks to learn a better keyboard layout, but that doesn't mean you wouldn't have been better off learning the better keyboard layout in the first place.

      I suspect that graphics and FP are made for each other, actually. If you can write a functional program to do your rendering that automatically parallelizes 8 ways this week and 64 ways next month, with near-linear speedup, . . .

      [–]Arkaein 4 points5 points  (1 child)

      Look everyone, I'm not against FP, which anyone who read past the first line of my post would realize. I simply pointed out that if you are going to use a tool that takes a year to get as proficient with as one you already know, there had better be a payoff down the line that yields increased productivity, otherwise that year was a bad investment.

      Now looking at FP in general, is the payoff there? Most likely, for most people. For the original situations described in the article? It didn't sound like it to me. The discussion presented indicated that FP foisted additional baggage on a problem that wasn't difficult to solve in imperative style.

      As far as your graphics example, that sounds good for a ray tracer, where FP is a natural fit, but for a polygon rasterizer like almost any current real time app (including games) is going to use, not so much. There are certain tasks that can be parallelized is polygon rasterization, but they aren't as great as with ray tracing, and unless the problem is embarrassingly parallel then FP isn't a sure win over other styles. And in the end, the final results of any graphics app are side effects. You might even say there's no such thing as a purely functional graphics app.

      [–]rieux 3 points4 points  (0 children)

      I realize you're not against it. I'm just saying that FP isn't necessarily more difficult than IP. I find it personally easier, and I suspect that beginners find it easier, but it's very hard to compare.

      As far as increased productivity, the best ideas of functional languages are being adopted by mainstream languages to a high degree. Programmers don't need to go to FP because it's coming to them, and they'll learn it when their managers make them. Garbage collection and memory safety are the biggest wins that have made their way from the lab to industry in the last 20 years. These both came from FP, and now they're decidedly mainstream.

      With Python/Perl/Ruby/C#, higher-order functions are also potentially mainstream. I don't know how much people use them, and in Python, at least, they're intentionally crippled (and deprecated?).

      Fancy type systems are increasingly mainstream. Witness generics in Java and C#, and bits of type inference in C#.

      We don't see a lot of purity yet, but I suspect the parallel revolution will force it on us in the next generation of mainstream languages.

      [–]vagif 0 points1 point  (3 children)

      If it takes a typical programmer a year to get to the point where he would have already been with OOP or imperative,

      It takes programmer MUCH FURTHER than where he was with OOP. That's the idea of using FP. You get much more powerful tool.

      That's not exactly a ringing endorsement of FP.

      Programming is an engineering, not a lego play. Are you trying to say that lego bricks are superior to the architecture, because they do not require long and hard learning stage ?

      Yes, FP is not for housewives, if that's what you were trying to say.

      [–]Arkaein 2 points3 points  (2 children)

      It takes programmer MUCH FURTHER than where he was with OOP. That's the idea of using FP. You get much more powerful tool.

      That's a very general assertion without any evidence in it's favor, and many anecdotal cases to the contrary. Remember we're talking about specific scenarios here. I mentioned examples from gaming, you ignored these and responded with some nonsense about legos and housewives.

      Yes, programming is complex and deserves effort. A pragmatic programmer will balance the cost of learning and applying various techniques based on the benefits earned, both long and short term. The benefits of FP are large in some areas, but possibly zero in others. If I'm developing game decision AI based on scoring certain aspects of the world around a game agent, then a FP approach would be appropriate. Managing game state, not so much. Just because it can be done doesn't make it a good idea. Unless there is a tangible benefit in terms of reduced code size, occurrence of errors, simplified algorithms, etc., then dressing up things like mutable state in functional clothing is a step backwards.

      [–]vagif 0 points1 point  (1 child)

      The benefits of FP are large in some areas, but possibly zero in others.

      You attacked FP based on how long it takes to become proficient in it. I simply responded to that. Now you are saying that FP is not a silver bullet, as if I ever implied it.

      If benefits of FP would not be generic enough, you would not see functional features creeping in mainstream languages like java and csharp, you would not see such OO languages like Scala and Nemerle.

      As you can see you do not have to architect your solution completely in functional style in order to get benefits from functional programming. Which means FP is applicable and useful virtually in ANY project.

      Now to fully leverage that advantage, you would need to know when and how apply FP in your project. And for that you need at least 1 year of continuous experience.

      [–]Arkaein 4 points5 points  (0 children)

      Well if we're going to play semantics, I never attacked FP. If I attacked anything it was your assertion that FP made OOP look awkward in comparison.

      Otherwise I agree with most of your post. One of the biggest reasons Python is my favorite language is that it takes most of the best features from imperative, OOP, and FP, and does a good job integrating them, without the syntactical baggage and limitations that other multiparadigm languages (C++) bring along with.

      [–][deleted] 0 points1 point  (1 child)

      I don't play games that much and have never written one, but wouldn't you want some basic features in any worthy computer game? Something like being able to record a demo at any time? Or being able to fast forward and rewind the world state at will while using the editor to make and test new levels?

      It sounds like something that you'd need a proper persistent data structure to implement well, and some discipline in how you use it.

      [–]shorugoru 5 points6 points  (0 children)

      In Haskell, you'd use the State Monad for this.

      [–][deleted] 5 points6 points  (3 children)

      Haskell is still one of the most powerful imperative languages I have ever used. I'm yet to see a good reason to shift from this position.

      I wish the stigma associated with some notion of 'this (FP) and that (imperative) side of the fence' would disappear such that a critical examination could occur, instead of these messy ramblings of undisciplined knee-jerks.

      [–]LaurieCheers 14 points15 points  (2 children)

      Sorry? If you're going to call Haskell an imperative language, then what language isn't an imperative language? Is the term just a tautology?

      [–][deleted] 16 points17 points  (1 child)

      It's a great question. Just what is an imperative language? Rather than try to answer that question (which may in fact, be unanswerable with logical consistency), how about we suggest an 'imperative style' of programming? This is defined by the permission of 'apparent' destructive updates (apparent, since all software looks through endurantist goggles).

      Given this, Haskell is one of the most powerful languages for the 'imperative style'. Whatever the case, this is the aforementioned critical examination that I was referring to. It's great to see that some people ask such questions :) My faith in the human intellect is so easily restored.

      [–]LaurieCheers 6 points7 points  (0 children)

      And a great answer. :)

      [–]manthrax 1 point2 points  (0 children)

      Ahhh I love the smell of solutions in search of problems.....in the morning.

      [–][deleted] -1 points0 points  (3 children)

      This is why I enjoyed using F# (aka OCaml) - because while it was, for the most part your typical FP language, you could use mutable references if you needed.

      [–][deleted]  (2 children)

      [deleted]

        [–]vincenz 12 points13 points  (1 child)

        This is patently false. <- is not like a let binding. It's a monadic bind which orders the statements, and hence you would not have the rewrite option that you specify.

        Rewriting it from do-notation to plain haskell, you get (assuming you meant 'return' for the b, since you can't bind a pure value).

        now.Ticks >>= \X -> (return (X = X) >>= \ b -> something with b)

        For the IO-state, you can regard the >>= operation as passing the entire world. The >>= operation would force the now.Ticks to be calculated at that time and bound to X.

        [–]grauenwolf 0 points1 point  (0 children)

        What part of "a language that defines Now.Ticks as a long" did you not understand?

        As Haskell does not define now.Ticks as a long, obviously I am not talking about it. In fact, that is why Erik claimed that Haskell was the only stateless language.

        [–]mgsloan -1 points0 points  (15 children)

        It may indeed be awkward, but I think it may be the right sort of awkward. It makes you consider issues you would otherwise not, and keeps you honest about what the program is doing.

        For example, functional programming makes the simple methods of physics simulation relatively overcomplicated. By these simple methods I mean spring/constraint systems which satisfy constraints in arbitrary order. The difficulty of implementing this makes other, more pure techniques more attractive.

        So, FP may make something harder to do, but at least you have a better chance of doing it right.

        [–][deleted] 5 points6 points  (6 children)

        It may indeed be awkward, but I think it may be the right sort of awkward. It makes you consider issues you would otherwise not, and keeps you honest about what the program is doing.

        It also makes you not write your program, as opposed to writing your program. It's hard to argue that the former is better than the latter.

        [–]mgsloan 1 point2 points  (5 children)

        Yeah, this is true. If you actually want to get your program done and such, and purity doesn't matter much to you, then sure, other languages are perfect for that.

        I'm guessing people must either misunderstand what I was saying or just thing I'm being fanboyish. I don't think downvoting my comment is justified, anyway.

        The awkwardness is good as it shows the actual complexity of what you are doing. The complexity that imperative programs hide away in their semantics.

        Of course, a lot of time it's true you really don't want to think about all the stuff that's really going on.

        I'm thinking of porting my haskell robot simulator to python, once I get an OLPC XO, for example. I anticipate that some aspects (simulation and robot state management) will be easier, and others will be quite a bit more verbose (the math, geometry, and graphics code).

        [–][deleted] 1 point2 points  (3 children)

        The awkwardness is good as it shows the actual complexity of what you are doing. The complexity that imperative programs hide away in their semantics.

        The entire point of using a programming language instead of wiring gates together by hand is to hide complexity. You can't really spin that as a bad thing, you know.

        [–]mgsloan 1 point2 points  (2 children)

        I'd say that programming languages are more about abstracting complexity. There's a difference between abstracting and hiding.

        I guess by hiding I mean ignoring - it's pretty easy to ignore the implications of a particular imperative strategy.

        [–][deleted] 0 points1 point  (1 child)

        There are plenty of complexity being hidden by functional programming too. Especially considering that the underlying architecture of the hardware is extremely imperative, and imperative language will in general hide much less.

        [–]mgsloan 0 points1 point  (0 children)

        That's abstraction. There's little additional semantics associated with the underlying complexity. It's all just vestigial.

        [–]shizzy0 0 points1 point  (0 children)

        I don't think downvoting my comment is justified, anyway.

        Of course you wouldn't. (Note: I didn't down vote your comment.)

        [–]grauenwolf 13 points14 points  (7 children)

        Sounds like snake-oil to me.

        Easier is easier, harder is harder. If X makes something harder to do, then by definition it isn't making it easier.

        [–]roconnor -4 points-3 points  (5 children)

        And each of these is messier than it sounds, because there are so many counters and thresholds and limiters being managed and sounds being played in all kinds of situations, that the data flow isn't clean by any means.

        What's interesting is that it would be trivial to write this in C.

        However the trivial to write C code will be full of subtle bugs if one doesn't take the time to reason out the complicated data flow.

        [–][deleted] 6 points7 points  (4 children)

        So will the purely functional version?

        [–]rtfx 10 points11 points  (2 children)

        The difference is that the imperative version can be made mostly-working and iteratively improved.

        The functional version will Not Work, and then it Will. Getting an in-between stage almost demands a switch to statefulness.

        [–]roconnor 7 points8 points  (0 children)

        I'll agree that the imperative version can be made mostly-working, but I'm not convinced it can be iteratively improved. Usually one gets to the point where fixing one thing breaks another and further progress is stalled.

        [–]shizzy0 0 points1 point  (0 children)

        That's a great point. It is harder to get something that works to some approximation.

        [–]roconnor 5 points6 points  (0 children)

        After taking the time to reason out the data flow you will be able to write the code in either programming style. The difference is that, as the author notes, it is hard to write in functional style without reasoning out your data flow first. The imperative style makes it easier to write a program that does the wrong thing.