addressalign-toparrow-leftarrow-rightbackbellblockcalendarcameraccwcheckchevron-downchevron-leftchevron-rightchevron-small-downchevron-small-leftchevron-small-rightchevron-small-upchevron-upcircle-with-checkcircle-with-crosscircle-with-pluscontroller-playcredit-cardcrossdots-three-verticaleditemptyheartexporteye-with-lineeyefacebookfolderfullheartglobe--smallglobegmailgooglegroupshelp-with-circleimageimagesinstagramFill 1launch-new-window--smalllight-bulblinklocation-pinm-swarmSearchmailmessagesminusmoremuplabelShape 3 + Rectangle 1ShapeoutlookpersonJoin Group on CardStartprice-ribbonprintShapeShapeShapeShapeImported LayersImported LayersImported Layersshieldstartickettrashtriangle-downtriangle-uptwitteruserwarningyahoo

Re: [ljc] How to think as "functional language programer"

From: Kevin W.
Sent on: Thursday, October 3, 2013 12:12 PM
I must respectfully disagree with much of your reasoning here.

On 3 October[masked]:44, Matt Pearce <[address removed]> wrote:

Hi Sivaji


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.

Being deeply indoctrinated in imperative programming will definitely hurt - you have a lot to unlearn, but not object-oriented programming.  OO as it's understood these days is just about encapsulating values and methods in a single entity, plus polymorphism.  There is *nothing* in this paradigm that's antithetical to the ideas of immutability and pure functions.

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.

The whole point of fusing OO and FP is that you *don't* have to pick and choose.  You code should be both functional and object oriented... at the same time.

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.

No, it means that:
- There are no statics; Statics don't participate in polymorphism, the can't be overridden, they're not OO
- There are no primitives; Even `1` is an object, `1.toString` is valid Scala syntax
- There are no operators; If numbers are objects, then every operation on them is a method. `2 + 2` is just infix method notation, it's syntactic sugar for `2.+(2)`. `+` is a method, it could just as easily have been named `plus`, it can be overridden and defined on any class (is it is with BigInt)
- Methods can be lifted to functions on demand (and thus converted into objects). This is *very* similar in concept to the autoboxing of primitives in Java.

And yes... Functions are objects, but only because *all* values are Objects and functions *must* be assignable to values or capable of being passed as arguments - an essential requirement for functional programming.

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.

Any object in Scala already can be a function, it just needs to inherit one of the FunctionN traits.  In addition, any object that defines an apply method can be used as though it were a function.

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.

The objective is already defined as part of the coursera course. I don't imagine that any student here could just choose to solve and submit a different problem.


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.


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!


Best regards




People in this
Meetup are also in:

Sign up

Meetup members, Log in

By clicking "Sign up" or "Sign up using Facebook", you confirm that you accept our Terms of Service & Privacy Policy