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

81–90 of 172 posts

Re: A Year of Functional Programming

#81

Post by ww520 »

jacquesm wrote: post #2

" Recently I looked at some code I wrote 8 months ago and was shocked! I looked at one file written in “good OO-style”, lots of inheritance and code reuse, and just thought “this is just a monoid and a bunch of crap because I didn't realise this is a monoid” so I rewrote the entire thing to about a third of the code size and ended up with double the flexibility. Shortly after I saw another file and this time thought…

Second design is the better design most of the times. It's not something special about functional programming. The first version is mostly just getting it working and released. Revisiting the code always gives opportunity to refactor, simplify, and re-design, which leads to reduction in complexity, reduction in size, and increase in reuse.

Re: A Year of Functional Programming

#82

Post by dllthomas »

IvarTJ wrote: post #73

How well does deploying Haskell web applications to a low-memory VPS work? My experience with the Play framework tells me that Scala is out of the question. Presumably using Haskell involves cross-compilation, considering the memory usage of GHC compilation.

I've been deploying Haskell web applications to a 1G and a 512M VPS, and both have been working fine. Initially I was able to build on the boxen, but more recent libraries/compiler runs out of memory building some dependencies. Obviously that wasn't ideal anyway since it was taking up resources the live site could be using, although none of the relevant sites are supporting a ton of traffic. Building on my local machine and pushing up the executables has been working just fine, though.

Re: A Year of Functional Programming

#83

Post by dminor »

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…

For a non-FP quicksort in Clojure, see: http://stackoverflow.com/questions/12176832/quicksort-in-clo...

Re: A Year of Functional Programming

#84

Post by pron »

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…

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).

Re: A Year of Functional Programming

#85

Post by ww520 »

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…

What I found FP good for is writing small, self contained, and util-like library, which usually has no requirement on maintaining state, and can be highly reusable.

Re: A Year of Functional Programming

#86

Post by doktrin »

mark_l_watson wrote: post #43
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…

Here is a good example of a complex Haskell app: the Haskell web based IDE at fpcomplete.com. They wrote the back end in Haskell and the client side with Haskell compiled to JavaScript. Really impressive.

> Here is a good example of a complex Haskell app: the Haskell web based IDE at fpcomplete.com.

Technical merits aside, I think this actually re-enforces the parents point.

I mean, you're basically saying that one of the best examples of production-ready Haskell is a Haskell IDE, developed by a company a good >80% of HN readers may never even have heard of.

Re: A Year of Functional Programming

#87

Post by pron »

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

Re: A Year of Functional Programming

#89

Post by findjashua »

dkersten wrote: post #39
piokoch wrote: post #5

Earlier quoted context omitted.

Exactly, 2/3 code reduction sounds so great that I would like to be able to see that.

I, too, would like to see examples. Though I will note that I recently saw some OO code written by a colleague that takes in a set of data names, runs a set of processes on them (translating the names to process-specific ids, fetching the data, turning it back into generic names) and then outputs it to one or more places. It was a pretty standard class hierarchy for reusing common code, selecting optional processing…

"there really isn't a need for crazy class hierarchies at all, because they're really just a dispatch mechanism for code reuse, but higher order functions acting on pure data structures handle 90% of this just fine with very little work"

You did a better job of putting my thoughts to words than I could.

Re: A Year of Functional Programming

#90

Post by VLM »

platz wrote: post #32
VLM wrote: post #11

Earlier quoted context omitted.

And yet that complex JVM interaction makes one possible way to "get toes wet" is to wrap existing lower level java processes (and libraries and things) in a larger functional wrapper. Top down. Assuming you have some experience, confidence, or sample code in java that you can use or understand in the problem domain. So rather than trying to find a way to use recursive functional definition of a factorial in your code…

Because Scala is a hybrid language, I feel it doesn't really try to teach FP, but some amalgamation of the two. So you'll end up thinking about case classes, traits, companion objects, unapply, etc... it's a way to solve problems in a unique way, but in comparison with the other more traditional FP languages, it doesn't present the same feel and can obscure which features are the ones necessary for FP - which is impo…

You are technically correct in your observations, but I think we're both stuck in a classic "glass is half empty" "glass is half full" observational trap. Both the good news and the bad news simultaneously about a hybrid language is you can implement the same solution two different ways.

If you did both intentionally for educational purposes, it might be fun. I like the many "koan projects" and a side fork that focuses intentionally on doing something two ways might be interesting, if its not already been added while I wasn't looking.

Post reply on HN