A Year of Functional Programming

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 (bottom up) it Might be possible to work top down and make the "main loop" or whatever of your java program a functional construct of some sort.

I am in no way claiming this is the best way, only way, or even a good way to learn FP concepts but it is a possible way to at least get feet wet, plus or minus your personal characteristics. It is merely an alternative to the extremely popular nearly universally pushed educational strategy of bottom up introduction of FP.

Ask HN: As somewhat of an old timer, I have a couple of questions about FP, not really worthy of creating their own thread:

1. I learned a rule (in my Pascal textbook), "avoid globals." Is FP just an embodiment of that principle?

2. I do a lot of programming involving hardware, often homemade. Hardware has state, such as whether a lamp is turned on or off. Does this just mean FP is inappropriate, or are there techniques out there that accrue the benefits of FP in systems that necessarily have state?

> Combinator libraries sure are pretty useful, and they're more than small simple loops.

Useful -- yes. Useful enough to pay the price -- IMO, no. OO is decent at code reuse, and the most effective, most important code reuse, is that of big libraries with rich functionality, which is done rather well in many programming paradigms (i.e. pure, statically typed FP has little to no advantage here).

> Very puzzled how you're using monads if they only appear 10 times in 50KLOC.

I'm not. But OO code that refactoring with monads would have saved me does not amount to much.

> I think you're referring to STM here.

I was talking about more limited transactional (or "concurrently mutable") data structures like Clojure atoms and agents, or restricted STM like Clojure's refs and in-memory DBs (general purpose STM is pretty much dead). I know Haskell explores STM. I'm just saying you can enjoy the same benefits in Clojure or even Java.

I'm not a specialist of FP, so please take what I say with a grain of salt. Before answering your questions, here's a preliminary point:

0) The problem is that FP is not really defined anywhere, or rather, everyone has its own definition. I was wondering about the definition of FP about a month ago, and discussed it with my roommate who's a phd student in programming languages. The conclusion of this 2-hour long conversation was: well FP is kind of a fuzzy concept. The concepts of FP languages, typed languages, static languages, etc.. all tend to conflate. Some people will consider that Scheme, Python, Ruby, Scala, Haskell, OCaml, R are all FP languages. Some will say that only Haskell and OCaml really are. Whatever..

Keeping that in mind, here some attempts at answers:

1) In a very loose sense, I guess that you can say that, and to make it possible, you need some constructs in your language, the minimum requirements being higher order functions, and maybe closures. I'd say that's the minimum, but again I'm no specialist. But then if you want to push this "no globals" moto to its logical extreme, you get to a point where you can't even use a "print" function, since it has some side effects. Haskell does, and solves the problem with monads. But to have monads you need a very particular type system, which leads to the question of wether you need a type system to go FP all the way? I don't know. Someone more knowledgeable should answer that

2) I don't know about hardware. But like I said, FP can deal with state. In fact, even hardcore FP as embodied by Haskell can deal with state. It's not trivial to wrap your head around the concept, but it's worth giving it a shot.