Functional thinking: Why functional programming is on the rise • Hacker News Board

Re: Functional thinking: Why functional programming is on the rise

#81

Post by spikels » Wed, Jan 30, 2013, 9:13 PM UTC

PeterisP wrote: post #75

goggles99 wrote: post #74

Earlier quoted context omitted.

Parallelism currently is just a nice bonus - say, I lose 3x performance by not detailing a great execution path manually in C++; but I gain 3x performance since most of the code is trivially parallelizable to run on 4 cores. Parallel extensions have been (and are being) added to OOP languages to make it's use not only simpler, but even as a preferred general design.

In order for such extensions to work on most of my code well, my code needs to written in an FP-inspired style that many new additions to OOP languages do - like C++11, python, etc. As a crude example - there is a big conceptual difference between a for-loop that processes all the elements in a list or array, and a map operation to all the elements in it. The for-loop specifies that the execution will be sequential a…

Thanks for the explanation. Popular "modern" languages like Javascript, Ruby or Python already have many of the "FP" features mentioned in the OP and comments: first class functions (though not so simple Ruby) and high level data processing functions (e.g. map, filter, select).

As best I can tell the big new benefit of FP is the potential, generally not currently realized, for automatic parallelization. The cost is having to think in a new way that is, at least initially, somewhat confusing.

Alternatively non-FP languages could simply import ideas from FP and gain the benefits in an evolutionary way. For example if Mads wanted to he could rewrite the Ruby interpreter to have map, filter and many other methods automatically use multiple cores. Eventually programmers using the new multi-core version would learn which structures were, such as map, or weren't, suc as for loops, going to be parallelized.

There would be many language specific details to work out. For example determining if there are truly no side effects in a particular situation. This is not always so simple in non-FP languages but still not as complex as analyzing every possible for..end loop.

As 4, 8, 16, 32 and more core processors become more and more common the pressure to either change to FP languages, incorporate FP feature in non-FP languages or find some other parallelization methodology (?) will become irresistible.

Re: Functional thinking: Why functional programming is on the rise

#82

Post by axilmar » Thu, Jan 31, 2013, 4:40 PM UTC

muraiki wrote: post #78

jarrett wrote: post #68

Earlier quoted context omitted.

Now that is really cool. You've convinced me that this could be a viable and practical approach to handling highly stageful programs in an FP context. One question though: Does memory/storage become an issue if you're keeping track of values "over time?" If I understand it correctly, you'd have a constantly growing picture of your data as it has evolved, with a complete history of prior values. (Maybe I'm wrong about…

For an example of making Pong using FRP, check out this: http://elm-lang.org/blog/games-in-elm/part-0/Making-Pong.htm... It's not a very long read, and it will help make FRP more concrete with a practical example.

Well, if the game state is so small, then it's quite easy to combine all these functions together in FRP style.

How about big games though? for example, World Of Warcraft or Eve Online. The game states of these are humongous, and the game state's data constructor would be huge.

Re: Functional thinking: Why functional programming is on the rise

#83

Post by Zak » Thu, Jan 31, 2013, 9:54 PM UTC

martinced wrote: post #48

jarrett wrote: post #30

Earlier quoted context omitted.

To me, the future will most likely be languages that allows both functional and OO styles to interoperate. Programmers will pick the style or mix of styles most appropriate to the particular sub-problem they're solving. We already do this with some of our high-level languages like Ruby and JavaScript. With these, we have higher-order functions, map and friends, closures, etc.. But we also have our familiar OO constru…

If you mix FP and OO you'll often end up with terrible FP which simply reproduces the "old" approach: lots of mutable stuff everywhere. Many Clojure toy games are like that: they start with a lot of "variables" in mutable refs. But it doesn't need to be that bad: you can create a game that is fully deterministic. A game which is purely a function of its inputs. And it can of course be applied to more than games. The…

The maybe monad has a counterpart from the OO world: the null object pattern. They're not implemented the same way, but they serve the same purpose.

Re: Functional thinking: Why functional programming is on the rise

#84

Post by dllthomas » Fri, Feb 01, 2013, 2:41 AM UTC

eru wrote: post #58

dllthomas wrote: post #54

Earlier quoted context omitted.

A state monad is a decoration of functions that take and return the state. It's certainly prettier, and there are respects in which the parent's complaints are overblown (certainly, it's no worse than imperative languages), but the parent is entirely accurate that a function like frobnicateTurboencabulator :: GameState -> GameState doesn't have a type that tells you anything about what it actually does. Compare that…

> Of course, the solution is is some combination of: And as always in Haskell: more type trickery. Like lenses, which help with the splitting. Applicative functors might help with "Have functions return a description of updates to the world-state [...]" for free in a sense similar to http://gergo.erdi.hu/blog/2012-12-01-static_analysis_with_ap...

Lenses are awesome, and can help with pulling data out of a WorldState object and updating it thereafter. They do not do a thing about loss of information in the function signature.

Re: Functional thinking: Why functional programming is on the rise

#85

Post by flyinRyan » Fri, Feb 01, 2013, 1:17 PM UTC

lightblade wrote: post #80

tikhonj wrote: post #69

Earlier quoted context omitted.

You're not necessarily keeping track of all the old values over time. Rather, the core idea is that you program in terms of abstractions that are explicit about time. That is, you write your program in terms of streams of events or signals. You have signals and events, but you never ask about the value right now ; instead, you take these two abstractions and combine them in different ways to get a reactive network. I…

I'm pretty new to FRP, but I tend to visualize FRP like an Excel spreadsheet where one value change leads to a chain reaction of many values in the spreadsheet. Would this paint the right picture?

Very well. In fact, one of very first implementations I've ever heard of was done in Lisp and it was described exactly in this way. I think the library is even called "Cells".

Re: Functional thinking: Why functional programming is on the rise

#86

Post by flyinRyan » Fri, Feb 01, 2013, 1:23 PM UTC

Chris_Newton wrote: post #45

tikhonj wrote: post #38

Earlier quoted context omitted.

Your last complaint is not fundamental to the language: it's just a matter of library design. I guess Haskellers don't like state very much in any guise, so having awkward syntax for it is only natural. Both programs are fundamentally ugly, so having it be superficially ugly as well is no big loss. However, if you really wanted to, you could have almost C-like syntax[1]. The demo in that particular blog post has its…

Both programs are fundamentally ugly, so having it be superficially ugly as well is no big loss. Perhaps we’ll just have to amicably disagree on that point. I think making code superficially ugly is a huge barrier to adoption that has held back otherwise good ideas throughout the history of programming. Many an innovative programming style or technique has languished in obscurity until some new language came along an…

> I think making code superficially ugly is a huge barrier to adoption that has held back otherwise good ideas throughout the history of programming.

Haskell tries to make elegant code look nice and inelegant code look ugly. When you see something ugly like the example above this is a sign that there would be some more elegant way of writing it. That certainly holds in this case as you don't need an mutation to do the fib sequence.