Question

As a newbie in functional languages (I started touching Erlang a couple of weeks ago — the first functional language I could get my hands on).

I started to writing some small algorithms (such as left_rotate_list, bubble_sort, merge_sort etc.). I found myself often getting lost in decisions such as “should I use a helper List for intermediate result storage?” and “should I create a helper function to do this?”

After a while, I found that functional programming (bear with me if what I am talking does not make sense at all) encourages a “top down” design: i.e., when I do merge_sort, you first write down all the merge sort steps, and name them as individual helper functions; and then you implement those helper functions one by one (and if you need to further dividing those helper functions, do it in the same approach).

This seems to contradict OO design a little, in which you can start from the bottom to build the basic data structure, and then assemble the data structure and algorithms into what you want.

Thanks for comments. Yes, I want to get advice about how to “think in functional language” (just like “thinking in Java”, “thinking in C++”).

Answer 1

After a while, I found that functional programming […] encourages a “top down” design.

I’m not sure this is an accurate statement. I’ve been recently trying to teach myself functional programming, and I’ve found that a sort “bottom-up” style of programming really helps me. To use your example of merge sort:

• First look at the base case. How do you sort an array of 0/1 elements?
• Next, look at the base + 1, base + 2, … cases. Eventually, you should see a pattern (splitting into subproblems, solving subproblems, combining subsolutions) that allows you to write a general recursive case than eventually reaches the base case.
• Splitting into subproblems is easy, but combining the subsolutions is a bit harder. You need a way to merge two sorted arrays into one sorted array.
• Now put everything together. Congratulations, you’ve just written merge sort. :)

I could be misusing the term, but this feels like bottom-up design to me. Functional programming is different than object-oriented programming, but you shouldn’t need to totally abandon existing design techniques when switched between the two.