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

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

#41

Post by tel » Wed, Jan 30, 2013, 1:21 AM UTC

Chris_Newton wrote: post #37

tel wrote: post #32

Earlier quoted context omitted.

Runtime constant values as IO is a long-standing concern. The existence of withArgs cements the issue (definitely allows for non referentially transparent code to be written with getArgs) but there's more to be said about why withArgs exist and why getArgs is in the IO monad. http://www.haskell.org/pipermail/haskell/2005-October/016574... The argument usually seems to play out as "their denotation is uncertain" and t…

IO's general status as the "Unsafe Pandora's Box" is a wart in Haskell. Isn’t that rather like saying mutable variables are a wart in C? :-)

Sure. Haskell's wart is automatically verified to be context constrained by the type system, though. There are also lots of tools to mitigate that wart that are also verified.

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

#42

Post by jeffdavis » Wed, Jan 30, 2013, 1:27 AM UTC

discreteevent wrote: post #2

The thing is that any imperative programmers who have composed SQL subqueries have have been doing this kind of thinking for years whether they realise it or not. The only substantial difference is that the data is in the process' memory as maps and lists as opposed to relational tables in the db. You end up with exactly the same kind of patterns of composition in the code.

In many ways, SQL is the case that proves how important and practical some functional language ideas are. SQL is, by many measures, one of the most successful programming languages of all time.

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

#43

Post by jeffdavis » Wed, Jan 30, 2013, 1:35 AM UTC

pestaa wrote: post #10

discreteevent wrote: post #2

The thing is that any imperative programmers who have composed SQL subqueries have have been doing this kind of thinking for years whether they realise it or not. The only substantial difference is that the data is in the process' memory as maps and lists as opposed to relational tables in the db. You end up with exactly the same kind of patterns of composition in the code.

Completely disagree. Composing SQL queries even on multiple levels (as in subqueries) might involve a way of thinking that remotely resembles to functional programming, it is way too simplistic for comparison with real world functional programs, at least in my experience. I know I grasped SQL really quickly, and still get puzzled by Haskell after 6 months of trying.

"[SQL] is way too simplistic for comparison with real world functional programs"

Another way of interpreting that is that the ideas behind SQL are so powerful that it's able to be one of the most successful programming languages of all time without all the bells and whistles of a language like haskell.

It's so successful that it can get by with horrid syntax, a ton of special cases built in, and the mess of SQL NULL semantics.

Sometimes it boggles my mind that more functional programmers don't get involved in databases, where all of their ideas are already proven to be useful.

I don't necessarily disagree with you, depending on what you mean by "real world" programs. I just think that if there is already an area where the concepts are useful (whether you call that a "real world program" or not), it makes a lot of sense to keep trying to build from that. Trying to convince someone to learn haskell to build a website when they already know and like ruby is an uphill battle.

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

#44

Post by eru » Wed, Jan 30, 2013, 1:39 AM UTC

jarrett wrote: post #30

Chris_Newton wrote: post #3

Some ideas that are ubiquitous within functional programming are certainly on the rise, for example: - functions as first-class entities in programming languages, and consequences like higher-order functions and partial evaluation; - a common set of basic data structures (set, sequence, dictionary, tree, etc.) and generalised operations for manipulating and combining them (map, filter, reduce, intersection, union, zi…

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…

> Well, every time you add a new type of entity (or a new data structure to index existing entities), you could add another parameter to the main game loop. But that gets crazy pretty fast. So then you have the clever idea to maintain one massive game state hash, and just pass that around. But wait, now you've lost something key to functional programming: You can no longer tell exactly what aspects of the game state a function is updating, because it just receives and returns the big game state hash. You don't really know what data your functions depend on our modify. Effectively, it's almost like you're using global variables.

You have to explain how that works. By "hash", do you mean a finite map (or dict, in Python terms)?

In Haskell you can use a state monad for these game loops. Some game industry insiders (see http://lambda-the-ultimate.org/node/1277) argue explicitly for this style.

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

#45

Post by Chris_Newton » Wed, Jan 30, 2013, 1:43 AM UTC

tikhonj wrote: post #38

Chris_Newton wrote: post #35

Earlier quoted context omitted.

What you describe in your 3rd paragraph is precisely the ST monad. Not exactly. The ST monad supports local mutable state, essentially turning a computation that uses state internally into something that looks pure from the outside. I’m looking for something more general where, for example, a function could modify state outside its own scope, but only if it advertised explicitly which stateful resources it would read…

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 and made the idea special and provided dedicated tools to support it. Then it becomes accessible enough for new programmers to experiment with the idea, and the code becomes readable enough to use the idea in production, and over time it starts to change how we think about programming. We push the envelope, probably developing some ingenious and useful but horrible abuses of the idea along the way, until we figure out how to make those new ideas available in a cleaner and more widely accessible way and the cycle begins again.

I suspect that people simply don't care enough.

Most people are programming in languages that don’t have the problem in the first place, so they don’t need to care.

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

#46

Post by eru » Wed, Jan 30, 2013, 1:47 AM UTC

Chris_Newton wrote: post #35

jberryman wrote: post #25

Earlier quoted context omitted.

You should really take a look at Haskell. What you describe in your 3rd paragraph is precisely the ST monad. It's true we're still pretty limited in how effects are typed (most effectful stuff still ends up in the "IO sin-bin"), but this is an area of active research and experimentation. This is the way haskell's going, and no one else is even close (afaict).

What you describe in your 3rd paragraph is precisely the ST monad. Not exactly. The ST monad supports local mutable state, essentially turning a computation that uses state internally into something that looks pure from the outside. I’m looking for something more general where, for example, a function could modify state outside its own scope, but only if it advertised explicitly which stateful resources it would read…

For something as simple as fibonacci, you wouldn't use the state monad machinery, but go directly:

    fib' :: Integer -> Integer
    fib' n = iterate (\(x,y) -> (y,x+y)) (0,1) !! n

The state monad helps you keep more complicated code composable. But it does have some syntactic overhead, that makes it lose out in simple examples. (Though with a bit of golfing, you could get syntactically closer to the Python example. For example putting the tuple (x,y) into an STRef instead of having two of them, employing Applicative Functor style in some places, and using a loop-combinator from the monad-loops package.)

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

#47

Post by Chris_Newton » Wed, Jan 30, 2013, 2:03 AM UTC

tel wrote: post #39

Chris_Newton wrote: post #35

Earlier quoted context omitted.

What you describe in your 3rd paragraph is precisely the ST monad. Not exactly. The ST monad supports local mutable state, essentially turning a computation that uses state internally into something that looks pure from the outside. I’m looking for something more general where, for example, a function could modify state outside its own scope, but only if it advertised explicitly which stateful resources it would read…

Concepts like your file state machine can be achieved using indexed monads and dependent types, though that's still fairly black magic. There's no doubt that the IO monad should have more structure, though, and ST is just one way to achieve that. There isn't a globally recognized standard for providing more structure, but there are a lot of fairly common practices (see IOSpec or free monads). The syntactic convenienc…

The syntactic convenience is unbeatable, of course.

Exactly.

I’m not in any way criticising all the research and ideas coming out of the functional programming community. Playing with Haskell is driving all sorts of interesting ideas.

I’m just saying I don’t think the mainstream is going to give up a whole bunch of readily accessible and useful programming techniques any time soon, just to gain the benefits of a radically different programming style that sound rather theoretical to Bob the Developer. This is true even if the reality might be that in time Bob’s bug rate would drop dramatically and he would develop new features in a fraction of the time.

I think it’s far more likely that the more accessible and obviously useful parts of that radically different programming style will get picked up over time, and that the underlying general/theoretical foundations will be more useful to the people building the specific/practical tools than to the people using them.

Today, we’ve been discussing how to implement even quite simple effect-related concepts in a functional programming context in terms of (borrowing from a few of your posts in this thread) products and compositions of applicative types, free monads, monad transformers, indexed monads, dependent types, and the problems of uncertain denotation. Poor Bob just wants to get an error message if he forgets to commit his transaction and leaves the DB locked or if he might be dereferencing a null pointer in his network stack. :-)

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

#48

Post by martinced » Wed, Jan 30, 2013, 2:30 AM UTC

jarrett wrote: post #30

Chris_Newton wrote: post #3

Some ideas that are ubiquitous within functional programming are certainly on the rise, for example: - functions as first-class entities in programming languages, and consequences like higher-order functions and partial evaluation; - a common set of basic data structures (set, sequence, dictionary, tree, etc.) and generalised operations for manipulating and combining them (map, filter, reduce, intersection, union, zi…

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 problem is that it feels "weird" to non-FP people.

The state monad is definitely what you're looking for. If you use a state monad approx. 95% of what you just wrote is utter rubbish.

But the state monad (and the maybe monad) sadly aren't that trivial to understand.

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

#49

Post by slyv » Wed, Jan 30, 2013, 2:43 AM UTC

I have been meaning to dig deeper into functional programming, specifically Clojure, but as a newbie to functional programming, I am finding it hard to find a detailed tutorial that I can start to get started with the concepts and programming used in Clojure. Would anyone have any recommendations for a guide?

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

#50

Post by martinced » Wed, Jan 30, 2013, 2:46 AM UTC

jeffdavis wrote: post #43

pestaa wrote: post #10

Earlier quoted context omitted.

Completely disagree. Composing SQL queries even on multiple levels (as in subqueries) might involve a way of thinking that remotely resembles to functional programming, it is way too simplistic for comparison with real world functional programs, at least in my experience. I know I grasped SQL really quickly, and still get puzzled by Haskell after 6 months of trying.

"[SQL] is way too simplistic for comparison with real world functional programs" Another way of interpreting that is that the ideas behind SQL are so powerful that it's able to be one of the most successful programming languages of all time without all the bells and whistles of a language like haskell. It's so successful that it can get by with horrid syntax, a ton of special cases built in, and the mess of SQL NULL…

"Sometimes it boggles my mind that more functional programmers don't get involved in databases, where all of their ideas are already proven to be useful."

But some do. For example Rich Hickey used Clojure (which both users and encourages FP but still allows to bend the rules when needed) to create Datomic.

It's a DB but it's CRA instead of CRUD. Making it just so much easier to reason about. The DB is ever-growing and any query becomes "query at time t". And later on, when you query again "query at time t", you CANNOT get a different answer.

Typical CRUD DBs are place-oriented mutability mess and, honestly, reading about MySQL fanbois vs PostgreSQL fanbois arguing about which one is the best looks, from a CRA point of view, as a blind man arguing with a one-eyed about who has the best eye vision.

Datomic is ACID, has infinite read scalability and can use SQL DBs (and many others) as their persistence stores.

It is as Real-World as one can get since that Rich Hickey as seen exactly what we're all witnessing daily in the real-IT-world: a gigantic ball of mutability mess.

To me the revolution is on and there's no going back for those who switched.

From there it's just a matter of time.