Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A Year of Functional Programming

japgolly.blogspot.com.au

Post reply on HN
Print view View original

101–110 of 172 posts

Re: A Year of Functional Programming

#101

Post by tel »

pron wrote: post #84
chiurox wrote: post #74

Earlier quoted context omitted.

How about WhatsApp's backend being extremely scalable because it was written in Erlang from the start? Or even Twitter that rewrote much of their backend in Scala to deal with scaling issues (I'm not saying that Rails isn't scalable, I don't want to start a war over this issue; the important thing is they saw a problem and solved it) while contributing many many open sourced libraries for our use? Foursquare uses Sca…

Well, when people say FP they mean different things. The Erlang/Clojure kind bears little resemblance to the Haskell/scalaz sort discussed in the article. Neither does most of the Scala code written at Twitter (which is mostly OO with a sprinkling of functional).

That's hardly true. Erlang's event loops are based on a very similar kind of state encapsulation as Haskell's state monad. Really Erlang is littered with explicit monadic patterns but lacks a good system for abstracting over those patterns so you just call them "OTP" instead of a monad.

Re: A Year of Functional Programming

#102

Post by mightybyte »

codygman wrote: post #92
mightybyte wrote: post #47

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…

Is there a video of that presentation anywhere?

https://www.youtube.com/watch?v=BveDrw9CwEg

Re: A Year of Functional Programming

#103

Post by kasey_junk »

seanmcdirmid wrote: post #62
kasey_junk wrote: post #48

Earlier quoted context omitted.

That is sort of the worst case scenario for a FP program (though I'm sure you could write it in FP). It is almost entirely side-effects. I agree with the sentiment that for a paradigm that has been advocated for 60 years it is really odd how little non-academia code is written in it. In my experience you find functional code shines (and is therefore common) in places where prove-ability is of the utmost importance or…

There are plenty of side effect free ways of dealing with change...you can make the effects you know...explicit. Anyways, for a game like SMB, FRP should work relatively well. Just be careful with collections.

But there are no side effect free ways of changing the pixels on a screen or the sounds coming out of a speaker as those are precisely side effects.

Of course there are ways of abstracting those side effects and acting like they are the same as pure functions. Or conversely instead of hiding them, you could point them out and make them "exceptional", which is what I assume you mean by making them explicit. These machinations (of which FRP is a clear example) to deal with side effects have a price, and in a game like SMB it is entirely possible that the vast majority of the work would be this overhead.

Again, of course you can do it, but it is a problem domain not particularly suited to FP in and of itself. I've written short running, fast starting, memory constrained applications in Java, but it was a fight to do it. If the fight is worth the other advantages, it can be worth it.

Re: A Year of Functional Programming

#104

Post by seanmcdirmid »

tel wrote: post #96
seanmcdirmid wrote: post #56

Earlier quoted context omitted.

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.

Type classes work strictly over values, with none of the naming machinery to give these values names and identities. Type classes only resemble classes in their unfortunate label; subtyping and polymorphism isn't really exclusive to OOP (with the exception of name-oriented nominal subtyping). The only way to create an object in Haskell is through giving it a GUID of some kind.

Re: A Year of Functional Programming

#105

Post by brudgers »

pron wrote: post #87
brudgers wrote: post #67

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

Clojure's syntax for transients is deliberately more cumbersome. A Scheme like 'loop! would flag the decision to employ mutation. Instead, Clojure steps outside the conventions of dynamic typing and expressions and requires something that looks like a static type specification and another thing that looks a lot like a 'return statement.

To put it another way, the language complects mutation instead of simplifying it and it's reasons for doing are...well, what's the difference between an ideology and an enforced opinion?

Clojure is rarely introduced with, ok here's how you can do exactly what you were doing before in Clojure, and now here are some ways that you might think about doing it differently. Instead, Quincy autopsying the corpse before the opening credits are even finished.

None of which is to say that I don't like Clojure. It's just that the really important question is part of the theology rather than evangelical outreach. Java in Clojure probably isn't good Clojure, but it might often be better Java. 20% less imperative code is probably an improvement.

Re: A Year of Functional Programming

#106

Post by virtualwhys »

chiurox wrote: post #74
cageface wrote: post #28

Earlier quoted context omitted.

The lack of magically bug-free, FP OSs, drivers, control software, and large applications, shows that even the biggest supposed benefits of languages like Haskell, are yet to be demonstrated in the real world. I've been reading religious advocacy of FP for almost 15 years now and yet there still don't seem to be many non-trivial apps written in any of these languages. Certainly many individual features of FP have bee…

How about WhatsApp's backend being extremely scalable because it was written in Erlang from the start? Or even Twitter that rewrote much of their backend in Scala to deal with scaling issues (I'm not saying that Rails isn't scalable, I don't want to start a war over this issue; the important thing is they saw a problem and solved it) while contributing many many open sourced libraries for our use? Foursquare uses Sca…

It says a lot about the scale of adoption the big language players have that despite the aforementioned inroads into the enterprise that Scala has made, it is still very much a niche language; Haskell at this point in time, even more so.

Am curious to see how Scala 3/Dotty backed Scala works out. Enabling better tooling and faster build times via a generally less kitchen sink-y/more regular language should bring Scala adoption to new levels. Dotty is under active development, even saw a Github issue talking about the migration tool[1]. It's going to happen, just a matter of when.

[1] https://github.com/lampepfl/dotty/issues/129

Re: A Year of Functional Programming

#107

Post by mncolinlee »

The one question I wish this article answered is: what specific, quantifiable benefits could I get from using a real functional language RATHER THAN merely reactive extension libraries to an imperative language.

The point many programmers are at is far removed from diving into Haskell and hard math in functional languages. Many of us are still learning why to compose observables for multithreading. From a application programmer perspective, what could we gain by diving into FRP completely?

If Scala is the gateway drug, then the dealers need to do a better job explaining what the hard stuff actually does for us.

Re: A Year of Functional Programming

#108

Post by seanmcdirmid »

takeoutweight wrote: post #94
brudgers wrote: post #67

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 askin…

One can achieve commutativity and idempotency in a side effect based language as well...but one has to redo the programming model to achieve it:

http://research.microsoft.com/pubs/211297/managedtime.pdf

Re: A Year of Functional Programming

#109

Post by runT1ME »

pron wrote: 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…

>I can understand some of the things FP gets you

I really don't think you do understand, as an example in the last thread we ran into each other you completely missed the fact that Futures allow concurrency for free since you're already in a monadic context 90% of the time.

https://news.ycombinator.com/item?id=7751605

> The problem is that the kind of code it enables reuse of more than OO is very small, simple loops. This is never a big issue.

This is called a straw man argument. People aren't claiming that FP helps you write four line loops in one line. This article and others talk about orders of magnitude improvement in LOC on a large scale.

>"transactional" mutable state is simpler than the pure FP one, and just as safe.

You clearly don't know what these words mean. Mutable and purity are not mutually exclusive. Purity is a slang term for referential transparency. You can have mutable, referentially transparent functions. You can also have transactional memory in pure languages.

>Finally (and I've said this before on HN), a language like Haskell discounts the very useful choice of reasoning about your code after it runs, favoring, instead, all-upfront reasoning, often at the expense of facilitating the former.

Citation needed. You’re making things up.

The bottom line is you’ve created a product that solves many of the same problems functional programming solves. Your product looks very nice and advanced, but your unfamiliarity with functional programming makes you fear it, so you’ve decided to spread FUD across HN to the detriment of the community.

Re: A Year of Functional Programming

#110

Post by seanmcdirmid »

Dewie wrote: post #93
pron wrote: 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…

State can be local, but you need an escape analysis to verify that it doesn't leak the context if your language supports aliases, which I believe Haskell doesn't (or to say, aliases don't make sense in Haskell).
Post reply on HN