Live data from Hacker News

A Year of Functional Programming

japgolly.blogspot.com.au

91–100 of 172 posts

Re: A Year of Functional Programming

#91

It's not that I don't think that programming in a functional style isn't a good idea , it's just that the discussions about functional programming and the languages people use to implement its style so often suggest: If you use language 'x', then using mutation is wrong. and recently, I've been thinking about the practically important but socially awkward question: What language is best for implementing mutable state…

> What language is best for implementing mutable state?

I would say a language that is pure and has a strong static type system. And I say that because those languages allow you to track exactly where mutation is happening (you're using dynamite) and deal with it appropriately.

Re: A Year of Functional Programming

#92
post #7

I used to like functional programming. Now I think that it's -- more often than not -- a solution in search of a problem. I can understand some of the things FP gets you (although those come at a cost, which I'll get to later); I'm just not so sure these are the things we need, or that FP is the best solution for them. One is code reuse: yes FP code is definitely more reusable. The problem is that the kind of code it…

> One is code reuse: yes FP code is definitely more reusable. The problem is that the kind of code it enables reuse of more than OO is very small, simple loops. It sounds like you just haven't used Haskell enough to have the full extent of the reusability become apparent. I agree that on the surface it seems like you're right. But that particular example of reuse is just the tip of the iceberg. It's actually a very p…

Is there a video of that presentation anywhere?

Re: A Year of Functional Programming

#93
post #87

It's not that I don't think that programming in a functional style isn't a good idea , it's just that the discussions about functional programming and the languages people use to implement its style so often suggest: If you use language 'x', then using mutation is wrong. and recently, I've been thinking about the practically important but socially awkward question: What language is best for implementing mutable state…

Actually, because Clojure is not ideological (though it is very opinionated) -- and certainly not pure -- but rather very pragmatic, it includes a very interesting feature called transients[1]. Transients temporarily turn a persistent collection into a mutable (in place) one in O(1), specifically to allow efficient in-place algorithms like quicksort. [1]: http://clojure.org/transients

I'm pretty sure that it is possible to make a function in Haskell which, while it mutates variables, these variables are all local, so you are still able to offer up a purely functional interface to the world outside of that function.

Whether this is simple and straightforward or even demands some "magic" which isn't usually part of the language semantics - that I don't know. Imperative code seems very doable and maybe even pleasant in Haskell, but I don't know how simple it is to actually write imperative code that is efficient - e.g. destructive updates and all that, rather than making a new value for each "update" and programming in an imperative style though you are really just using immutable values all the time.

Re: A Year of Functional Programming

#94

It's not that I don't think that programming in a functional style isn't a good idea , it's just that the discussions about functional programming and the languages people use to implement its style so often suggest: If you use language 'x', then using mutation is wrong. and recently, I've been thinking about the practically important but socially awkward question: What language is best for implementing mutable state…

I suppose I can only speak for myself, but as a functional programmer I would never ask you to give up mutation completely.

I do think it's nice that most FP languages give us pure functions and persistent data structures that are easy to use and relatively performant, so we don't have to go out of our way to provide a pure (by construction) abstraction when we want to.

The key idea is to be honest when you are asking for mutation. Haskell would likely be far on the "left wing" (or right wing?) on your political spectrum but you can do mutation whenever you please as long as you're honest and mark it in the types with something like IO, State, or ST (Clojure does something similar in spirit with 'transient'). There is even unsafePerformIO if you are absolutely sure that you are wrapping an impure computation in a way that you know looks pure from the outside.

Purity isn't promoted because it's a virtue. It's that pure expressions generally come with nice commutativity and idempotency laws which give you the ability to refactor code while remaining confident you won't change its meaning or alter the behaviour of distance subsystems. It's worth preserving those properties when you can.

Re: A Year of Functional Programming

#95

It's not that I don't think that programming in a functional style isn't a good idea , it's just that the discussions about functional programming and the languages people use to implement its style so often suggest: If you use language 'x', then using mutation is wrong. and recently, I've been thinking about the practically important but socially awkward question: What language is best for implementing mutable state…

What do you think, in terms like this, of the ST monad work in Haskell?

Re: A Year of Functional Programming

#96

Earlier quoted context omitted.

I don't agree with your definition of FP then. Erlang is broadly the same as Clojure: pure in the small but stateful in the large (mailboxes in Erlang store state). Your basic argument seems to come down to Haskell (the only pure statically typed language with any widespread adoption) vs any other language. That's not an argument I'm particularly interested in. As for OO vs FP in combinator libraries -- the same patt…

All Erlang, Clojure, Scheme sport pretty nifty object systems, even if they don't resemble the Java kind. I find it funny when someone espouses the benefits of functional programming with...objects? On the other hand, these languages are quite pragmatic and I believe such blending is the future. The only language that is purely FP is Haskell. It doesn't have anything that we could mistake for an object system, its fu…

Haskell completely has something you can mistake as an object system! The entire typeclass machinery works that way less classes and inheritance. There's even a highly functional subtyping relation.

Re: A Year of Functional Programming

#97
post #93
post #87

Earlier quoted context omitted.

Actually, because Clojure is not ideological (though it is very opinionated) -- and certainly not pure -- but rather very pragmatic, it includes a very interesting feature called transients[1]. Transients temporarily turn a persistent collection into a mutable (in place) one in O(1), specifically to allow efficient in-place algorithms like quicksort. [1]: http://clojure.org/transients

I'm pretty sure that it is possible to make a function in Haskell which, while it mutates variables, these variables are all local, so you are still able to offer up a purely functional interface to the world outside of that function. Whether this is simple and straightforward or even demands some "magic" which isn't usually part of the language semantics - that I don't know. Imperative code seems very doable and may…

This is actually very simple and straightforward to do using the ST monad[0]. See the paper Lazy Functional State Threads[1] for details.

[0] http://hackage.haskell.org/package/base-4.7.0.0/docs/Control...

[1] http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.144...

Re: A Year of Functional Programming

#98
post #63

Earlier quoted context omitted.

> One is code reuse: yes FP code is definitely more reusable. The problem is that the kind of code it enables reuse of more than OO is very small, simple loops. It sounds like you just haven't used Haskell enough to have the full extent of the reusability become apparent. I agree that on the surface it seems like you're right. But that particular example of reuse is just the tip of the iceberg. It's actually a very p…

> With Haskell their reuse was an order of magnitude higher as measured by the number of external library dependencies! If we're talking real world -- as we should -- then this should be contrasted with the tradeoffs and alternatives. The most important kind of code reuse, IMO, actually happens at a larger scale, and in the past few years has worked remarkably well, since the advent of open-source. I'm talking about…

"The most important kind of code reuse, IMO, actually happens at a larger scale,"

There's a hidden instance of begging the question here, which is that the reason why "large-scale" code reuse is "more important" in the real world is that OO has largely been a failure for mid-scale code reuse. You can build enormous frameworks in OO that serve a need (at some cost in constraining your options, but one that can be worth paying), and it can do certain fairly small-scale reuse like 'a generic red-black tree' or other data structures, but it has not done well in the middle. Therefore, since OO has been the dominant paradigm for decades now, we do not see any middle-scale reuse in the "real world". However, it is difficult to disentangle whether that is a fundamental characteristic of "reuse" or whether it's a fundamental characteristic of OO. (I can argue in favor of both, and I don't mean "both are true", I mean I could argue in favor of either one.)

Re: A Year of Functional Programming

#99
post #78

It's not that I don't think that programming in a functional style isn't a good idea , it's just that the discussions about functional programming and the languages people use to implement its style so often suggest: If you use language 'x', then using mutation is wrong. and recently, I've been thinking about the practically important but socially awkward question: What language is best for implementing mutable state…

You could look at Rust? It has mutable state but strict ownership which is enforced at compile time.

My irrational preferences fall along the lines of Lisp, and I think Scheme has the right syntactic approach to mutation: Put a '!' on the end so that it's explicit, but don't make it syntactically a mess like Racket does where mutable lists have to be 'mcons-ed up step by step rather than made in one pass (not that there's anything wrong with writing a macro, it just means that there's an additional layer of misdirection when using mutation, and that's exactly the place where you don't want it.

Ordersky's Scala takes an approach similar to Racket in regard to type casting - purposely making the syntax a bit more cumbersome as a flag rather than...well flagging the action explicitly. That said, I like Scala's ML like features, and Ordersky opens Scala by Example [1] by illustrating the transition from imperative to functional style in a Scala implementation of quickSort.

Rust looks interesting. One of the big things though that I look for is an over-abundance of documentation and resources. I'm learning Scala because Ordersky teaches a course on Coursera and the decade of people writing about it in general and the fact that one could write about Scala and potentially make money doing it due to the size of the JVM market, means that the literature about the language isn't so much some necessary evil for people who like writing languages more than documenting them.

[1] http://www.scala-lang.org/docu/files/ScalaByExample.pdf

Re: A Year of Functional Programming

#100
post #93
post #87

Earlier quoted context omitted.

Actually, because Clojure is not ideological (though it is very opinionated) -- and certainly not pure -- but rather very pragmatic, it includes a very interesting feature called transients[1]. Transients temporarily turn a persistent collection into a mutable (in place) one in O(1), specifically to allow efficient in-place algorithms like quicksort. [1]: http://clojure.org/transients

I'm pretty sure that it is possible to make a function in Haskell which, while it mutates variables, these variables are all local, so you are still able to offer up a purely functional interface to the world outside of that function. Whether this is simple and straightforward or even demands some "magic" which isn't usually part of the language semantics - that I don't know. Imperative code seems very doable and may…

> I'm pretty sure that it is possible to make a function in Haskell which, while it mutates variables, these variables are all local, so you are still able to offer up a purely functional interface to the world outside of that function.

Indeed, it's called the ST monad. The internals aren't that magical, behind the scenes GHC does some state passing like IO but nothing too fancy. The real trick is using -XRankNTypes for the runST function[1] to track "state threads" at the type-level.

        example1 :: Int
	example1 = runST $ do
	  x  do
	    writeSTRef x j

	  readSTRef x
[1]: http://research.microsoft.com/en-us/um/people/simonpj/Papers...
Post reply on HN