|Sent on:||Thursday, October 3, 2013 12:12 PM|
I wouldn’t be discouraged. This is perfectly normal, and to be expected. To some extent, the more experienced you are in OOAD or imperative programming, the more you’ll have to put aside to pick up functional programming. I haven’t taken Martin’s course, so I just had a look through the course description. I see you are on week 3 of 7; you are early days yet.
Martin clearly states in the course advert that he “created Scala to prove that a combination of object-oriented and functional programming was not only possible but practical and fun to work with”. I guess that flexibility can be a barrier to someone starting out, because the decision about when to use OO and when to use functional programming is at your discretion.
And as a further abstraction, it was Martin’s design decision to make Scala strongly OO, which means that in Scala, functions are objects. I take that as pragmatic (most Java programmers are from an OOAD background), rather than necessary, to elevate the OO aspects over the functional aspects.
There is no reason, that I am aware of, why a functional language could not be designed along the opposite lines; namely to be strongly functional, and that objects are functions.
When learning a new paradigm, I’d say it’s more important to focus on learning the essence of the paradigm, rather than the bridge into the paradigm that you already understand. However from what you describe, the constructs and syntax are not your main issue. If you are required to solve all exercises without mutation, then that is forcing you to think in the new paradigm, which is good.
It’s interesting that you say that thinking about recursion and abstraction is a nightmare to you now. Could you expand on that? Is it at design or runtime that you are struggling most? Is it perhaps because you are thinking about the program from the front (the output) face rather than from the root information, or are you diving into the middle and thinking about programming logic. Please tell us. Recursion is simpler to understand if you worry less about how each function is nested, and think of each function as a discrete information transform (step A to B, step B to C etc). Composition of functions comes as a later step in the design process, I would say.
I would suggest that a tweeter application is not an ideal sample program; because what can this tweeter program do? Firstly, if you are just creating tweets, your information structure is just an input list and an output list. Secondly, the program’s functionality is likely to be restricted to the set of functions provided by the Twitter API. It will teach you little more than a greater understanding of Twitter’s API, which is not your objective.
There two ways I can suggest going about this:
1) Simplify. Make this problem really simple. There is a growing list of tweets on the input side, and a representation of those tweets on the output side. What do you need to do, to transform those tweets from input to output. How will you add markup; how will you ensure boundaries…. For example:
a. Will your input list contain the same number of tweets as the output list?
b. Will the output be restricted to a maximum of 20 rolling tweets)?
c. Is there some contextual information you need to add to the output list: timestamp, other metadata?
d. Solve the issues first, by mocking out Twitter’s API.
2) Experiment. A more edifying sample program might be a program that allows you to tweet, and simultaneously post to Facebook, G+ and LinkedIn. Because of the difference in the data constructs, you ‘ll need to consider how to transform the root list of tweets to fit into a set of different data representations. Each piece of this new problem can be broken down into individually simple information transforms. Make it more interesting for yourself by filtering some of the input tweets, so that only a subset of those tweets appear on other channels. For example, only tweets with a certain hashtag will be posted to a certain G+ circle. You will still be restricted by those pesky APIs, but you will find ways to be creative and to achieve much better value-add, and will distinguish yourself from the average programmer. It’s not surprising that social networks like Twitter and LinkedIn use functional programming, because their information is naturally stored in trees. Experiment with programming examples that store data in trees, and you will feel more comfortable with this new ‘abstraction’, as you call it. You should actually find this quite liberating!!
One thing I would also suggest when working in a functional programming paradigm, is to start at the edges of the program context. This is often alien to OOAD programmers because if you analyse OO programs, the complexity bunches together in the middle of the program context. Start by thinking about all the resources you’ll need for the tweeter application. Start thinking about the information itself, and think about how you can derive some of those bits of information from other bits of information. As you analyse the connections implicit in the information, you can model that very efficiently and elegantly with functional transformations.
The following free open source product has a visualizer which supports Scala and Clojure; it helps programmers step back from thinking about the functional flow. http://www.1060research.com/products/
I hope this is helpful to you, and I commend you for investing your time in this. You’ve got me interested in taking this Scala course too, if only I had the hours to spend!! I hope to read some more posts from you, as you proceed. It is encouraging to hear about your experience!