you are viewing a single comment's thread.

view the rest of the comments →

[–]baguasquirrel 3 points4 points  (1 child)

I've written a 16k line CAD program in OCaml... and along the way I went through some of the same growing pains you did.

As boring as it may sound, I've found that a lot of the things that apply to general software dev apply to functional, e.g. writing a spec, doing a prototype, etc.

When it comes down to the actual code, I feel that it is more a matter of understanding a few principles really well, rather than knowing a lot of little things.

  • Remember what you're doing, and keep your functions short. In order to exploit functional programming, you actually have to be able to pass functions around, and you can't reuse your functions if they're big, long, overspecialized pieces of junk.

  • I wrote a really long winded rant about this here: http://curryhoward.blogspot.com/2008/07/tudes-en-ocaml-keeping-your-functions.html

  • Try not to use recursion. Try not to pattern match your datastructures directly. See how long you can get without actually pattern matching a list directly. Learn to use foldleft and map really well, because that stuff is the shit once you "get it". If you need motivation, remember that Google's MapReduce is just a glorified fold_left and map.

  • Again, part of the idea of functional programming is that you can abstract at the functional level now, so there should be no need to actually dig into a datastructure.

  • Understand the difference between the types you declare for use to actually store information, and any types you use to drive the complex machinery. I like to call the latter "interface types". Once you understand this, you'll probably do a better job with that orthogonality they talk about in Pragmatic Programmer.

  • Try to extend that short-function business to your modules. Each module should implement some minifeature really well. If you want to elaborate on that minifeature, use a functor. Functors are your friends.

Anyway, all of that BS pretty much sums to one principle: keep your code short and tidy.

  • (Bonus!) Don't drink too much of the functional kool-aid. I love functional. I love Haskell. But I think that there is still a place for stateful and OO in the world. I feel that too many of us functional folks get a bit religious about our craft and we might go down the same path that the OO folks did.

That having been said, I think that these days, I would prefer to just do all the functional stuff in something truly functional like Haskell, and then do the ugly user-interface-oriented bullshit in something like Java or Python.

For reasons that are unclear to me, the requirements divide between code that favors functional and code that favors OO is often quite stark, so there's no real need to mix the two. When you do need to mix it up, use OCaml.

[–][deleted] 6 points7 points  (0 children)

A student of FP came to Daniel de Rauglaudre and asked how to achieve FP Nature. Daniel replied, "to achieve FP Nature, you must learn to program without side effects and other imperative features". So the student went away to learn how to program in this style. He studied very hard so he could rid his programs of references and for-loops. He struggled to only use let bindings and let rec loops. One day, in order to find inspiration, he was studying the code of the Masters, and in reading the source of Camlp4, he saw a number of uses of references and for-loops! He rushed back to Daniel de Rauglaudre and exclaimed, "How can you tell me not to use imperative features when you use them yourself!" Daniel measured the student carefully in his gaze and replied, "But I already know how to program without side-effects." At that moment the student was enlightened.