addressalign-toparrow-leftarrow-rightbackbellblockcalendarcameraccwcheckchevron-downchevron-leftchevron-rightchevron-small-downchevron-small-leftchevron-small-rightchevron-small-upchevron-upcircle-with-checkcircle-with-crosscircle-with-pluscontroller-playcrossdots-three-verticaleditemptyheartexporteye-with-lineeyefacebookfolderfullheartglobegmailgooglegroupshelp-with-circleimageimagesinstagramFill 1light-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: Matt P.
Sent on: Friday, October 4, 2013 7:04 PM

Hi Kevin,


You can disrespectfully disagree too if you like; shan’t be offended! Thanks for taking the time to respond. Your comments are stimulating, and I’ve responded inline. Couldn’t emulate your neat tabulation, so replied in orange. Apologies to any reader who is colour-blind, or reading their mail in monochrome.


From: [address removed] [mailto:[address removed]] On Behalf Of Kevin Wright
Sent: 03 October[masked]:29
To: [address removed]
Subject: Re: [ljc] How to think as "functional language programer"


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.


Kevin, that’s not what I meant. I’m not suggesting it’s necessary to unlearn imperative or OO paradigms. I simply meant put them aside (temporarily) in order to focus on functional programming.


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.


Kevin, you’re right to pick me up on this; I didn’t express myself carefully enough. Perhaps to clarify, Scala is strongly OO, and fully FP, because those two paradigms have been cleverly combined. However, to say code should be functional and object-oriented at the same time, doesn’t help the learner distinguish between the two. That was my point. Please don’t take that as a criticism of the design of Scala; quite the reverse, the “fusion” is intellectually really interesting, especially as its designer has gone right to the bottom of these concepts.

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


Took a while for the penny to drop, as to why you picked me up on this. I appreciate now that it’s the “which means that” connective. I’ll try to rephrase for more accuracy, that Scala is strongly OO, and more strongly so than Java, because no statics, and no primitives. And interestingly, given Martin O.’s prodigious contribution to Java 1, I think it’s fair also to point out the statics vs singletons argument, where statics in Java could arguably be seen as a concession to the mainstream of C++ developers. I’m guessing that Martin would have seen that as an atavism, and would not have wanted to propagate that into Scala. I think he is on record somewhere as saying that he created Scala as a clean sheet.


In the same vein, Scala’s emphasis on genericity seems also to be a continuation to his (Martin’s) contribution to Java. I personally find the history of generics in OO programming languages a topic that’s a little complicated to disentangle. Would be interested if you, or others, would care to discuss that on this list, especially from C++, through Java, to Scala.


- 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.


The original question didn’t say so, and I haven’t taken the Coursera course, so didn’t make the inference. Certainly, if one wants the “certificate”, it is wise to submit the homework. I thought it was Sivaji’s own idea, and was just suggesting some alternative problems. I’ve participated in training where very experienced developers are introduced to declarative, functional, and heavily recursive capabilities (not in Scala, but in Netkernel), and noticed that the early attempts at very similar exercises were side-tracked in three ways: reliance on the old paradigms, tendency to focus disproportionately about less significant aspects like API calls, and I should probably add a lack of formative knowledge of the mathematics, and history of mathematics and computing, a la Russell, Church, Rossing, Haskell, Curry, Turing, Gandy and many others.


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



Please Note: If you hit "REPLY", your message will be sent to everyone on this mailing list ([address removed])
This message was sent by Kevin Wright ([address removed]) from LJC - London Java Community.
To learn more about Kevin Wright, visit his/her member profile
To report abuse or block this person, please click here
Set my mailing list to email me As they are sent | In one daily email | Don't send me mailing list messages

Meetup, POB 4668 #37895 NY NY USA 10163 | [address removed]

This e-mail and any files transmitted with it are for the sole use of the intended recipient(s) and may contain confidential and privileged information. If you are not the intended recipient(s), please reply to the sender and destroy all copies of the original message. Any unauthorized review, use, disclosure, dissemination, forwarding, printing or copying of this email, and/or any action taken in reliance on the contents of this e-mail is strictly prohibited and may be unlawful.

Our Sponsors

  • Our Blog

    Read the latest news from the LJC

  • RecWorks Ltd

    Fixing Tech Recruitment using the Power of Community

  • jClarity

    Java/JVM Performance Analysis Tools & mentoring for Java related matters

  • LJC Aggrity

    Our LJC Aggrity site contains blog posts from our members

  • LJC Book Club

    Our Book club with book reviews from our members

  • Devoxx UK

    Java Community Conference in collaboration with the LJC, 8-10th June 16

  • SkillsMatter

    "Host, help organise, promote, film many of our meetings."

  • IBM

    Build Enterprise-grade apps at start-up speed.

  • New Relic

    New Relic makes sense of billions of metrics a day in real time.

  • Hazelcast

    Hazelcast is the leader in operating in-memory computing.

  • Java.Net

    We are an official Java User Group recognised by Oracle's JUG program

  • JRebel

    Free 3 month J-Rebel license.

  • O'Reilly

    40% discount on printed books and 50% on e-books.

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