I took the course last year, and really enjoyed it a lot. It's a very good introduction to functional programming.
For anyone unsure about taking the course, I wrote about my experience on my blog [1], maybe that will be of use. I posted more technical details of the course contents on google+ (links in the blog post).
"a lot of material was explained by Professor Ordesky during the videos, so you’d have a hard time trying to do the course without watching the videos"
The Stanford Databases class (http://class2go.stanford.edu/db/) did that part very well (well it did everything very well): Everything that the professor typed in during video demonstrations, was also provided as text files in the course downloadables.
Can't recommend this course enough. Martin Odersky is a great lecturer and very passionate about functional programming. Learning Scala was a useful bonus too.
Agreed. This course (my first into to functional programming) makes it hard to go back to working in Java. Things that can take a lot of code, such as grouping, filtering and aggregating data, can usually be achieved very naturally and concisely in Scala.
I had the opposite experience: while the lectures were quite good, the exercises were many times confusing and frustrating - they kept refusing my solution because there were hidden assumptions, not stated clearly in the problem definition.
From my experience with the first iteration of this course and with the problems experienced by people on the course forum ... 99.99% of problems came from NOT reading the assignment.
I went through all the homework and passed the course with the maximum grade. Except for the last homework where I too was guilty of the above, all submissions took the maximum grade from the first try. I don't remember encountering any confusing problem definition and even if a problem is confusing to you, there were plenty of people available on the forum and all you had to do was to ask for clarifications.
Also, in regards to solutions, there were really helpful advices in the assignments' source-code. Sometimes all you had to do was to translate English to Scala.
That's strange - I did not have any difficulty with the exercises and found them to be clearly specified! All the exercise problems were neatly broken down into small functions - you simply had to fill up the body of the functions!
The exercises were not all that difficult (especially given that there were unit tests for almost all of them), but they did have issues. Some of the tests required you to use functions that didn't appear until one or two lectures later.
Most likely the GP is complaining about the fact that the server-side tests were on bigger datasets than the ones that shipped with the code; but that wasn't a big issue as you could keep resubmitting up to the deadline.
I found it useful to remember that almost all of the solution functions were very short; most were one line, some up to five; if you were writing long functions you're most likely doing it wrong. Similarly, the local tests should finish almost instantaneously. If they take 30s with the local dataset, they'll time out with the larger dataset on the server.
However, he tends to talk slooooowly and methodically (him being German/Swiss is probably related), which makes watching his videos kind of unfun, and there are no slides.
There's an hour of lectures, and I'm pretty sure I could say the same stuff in a 10 minute video at most.
I mean, this kind of way of teaching is really ancient and outdated; why would you subject yourself to 7 weeks of watching boring videos, when you could just read his whole book RIGHT NOW in 1-2 days, and then read other books, tutorials on websites, etc.?
Yes, I found the class somewhat slow going, and the programming environment fairly unpleasant (I’m not used to working in Eclipse). I ended up dropping the class somewhere in the middle.
Generally, I learn better from books than from lectures, but I found that some of the lecturers in online courses are truly outstanding (Prof Agarwal in Circuits and Electronics at MITx, Profs Ng (Stanford, Machine Learning), Egerstedt (Georgia Tech, Control of Mobile Robots), Pattison (Berklee, Songwriting)), so listening to their lectures was worth it. I did not quite find Odersky as strong as a lecturer.
`mplayer -af scaletempo` and then pressing ] to increase the speed of the video, without altering the pitch of the sound, was my solution. (And I hear also the Coursera player lets you to change the video speed.)
I'll politely offer some dissenting opinion regarding Scala for the Impatient. I found that it really doesn't live up to its name if you have done any FP before, ever, even in Scheme or Lisp, because Horstmann treats functional programming like a somewhat advanced topic, and doesn't really address it in the first dozen chapters, instead covering file IO, regular expressions, and packages before higher order functions and pattern matching. When he gets to it, FP is covered at an introductory level at first. Instead I think it would have been better titled "Scala for the Impatient Java developer", because it doesn't really get to the meat of what makes Scala different from ML and Haskell very quickly.
Even as a beginner text, I think it's a bit lacking due to hurried presentation. This Coursera class is a far, far better presentation of intro FP, and a much better intro to Scala IMHO.
Anyone who's done some Haskell care to comment on whether scala is worth learning?
I read the scala book a few years ago, then I decided to go to the source first and learn Haskell. However, I don't see many Haskell employment opportunities available in my area or industry (London, Hedge funds/algorithmic trading). I have however seen an up tick in FP jobs in general, mainly scala or F#.
So, those in the know: What should I learn if I want to land a decent FP job? Scala, F#, something else? Or should I continue to wait for Haskell's inevitable word domination?
I don't work in finance, and I can't tell you if anyone is looking for FP developers in your particular speciality. However I do know that finance in general has growing demand for FP. Some pointers:
Lennart Augustsson has been spreading the gospel of Haskell at Standard Chartered, and Credit Suisse prior to that. I'm not sure which area he works in, but you might find Haskell jobs there.
Most of the major banks are recruiting for Scala developers. For example, Morgan Stanley were/are looking for Scala developers for their core technology team.
Scala is also growing in popularity in media companies: the Guardian, Mind Candy, etc.
> Most of the major banks are recruiting for Scala developers. For example, Morgan Stanley were/are looking for Scala developers for their core technology team.
Would you mind sharing links to Scala jobs?
I see these claims a lot but whenever I try to search for actual jobs, I find none. I'd love to switch to Scala but after searching for more than a year, I'm very close to moving on.
Thanks for the comment, I think I've seen your blog before actually! I know a few FP specific recruiters in London, and my feeling is that FP is not quite widespread enough that you could jump directly from one contract to the next without being in Java/C# land at least a little bit.
Almost all of the FP jobs I've seen are <an imperative language>, F#/Scala/clojure experience considered beneficial. Are you working more with greenfield projects or transitions from Java would you say?
Definitely having Java helps. I'm of the belief that any competent dev should be able to pick up Java in a few weeks. Not everyone shares this opinion, and more importantly HR types rely on keyword scanning and will probably throw away a CV that doesn't mention it.
As for projects, it's a mix. As I'm not heavily involved in the finance side I can't really say what the mix is. On the media side I'd say it's perhaps 50/50.
Java the language, definitely. But Java the language + Spring or Android or whatever framework your project is based on? Not sure that "a few weeks" would be enough for that.
You'll definitely catch a job sooner with knowledge of F#/Erlang/OCaml or Scala. Though knowing haskell isn't a con! If haskell is on your CV, they know you've got the right mindset. Learn scala wouldn't be difficult for you except from a few quirks : In scala, you explicitly define the order of evaluation, whilst haskell is lazy (we don't care). But the scala course last year on coursera covered that in the first lecture.
I come from a java background, but moved to haskell last year. I like both worlds, so scala was lovely to experiment with.
If you come from a functional and also an OO background, you can get the gist of scala in a matter of days.
If you want a decent FP job, one shouldn't learn a specific language, but adapt the FP mindset. from there, it shouldn't be difficult to switch languages and adapt to the technology that they use at the company you want to work for.
In your spare time, just try experimenting with as many languages as possible.
Yes I've definitely seen evidence that Haskell has become a marker language on one's CV of the right attitude (somewhat taking over from python a few years ago). In fact one recruiter reported back that a client said "He's done some Haskell, we'll definitely interview him" (that ended up being the job I landed too).
I have to disagree there. Haskell usage outpaced ocaml's nearly a decade ago now. And ocaml has been sitting at a virtual standstill since then, while haskell is moving at warp speed. Look at how many financial institutions use haskell, look at all the talks at conferences that are about haskell. Ocaml and erlang don't even come close to that level of usage or discussion.
F# and scala certainly have big leads over haskell, largely due to their platforms.
tl;dr. For job in London, Scala (unless you need to use .NET libs). To get good at FP, Haskell.
In my limited viewpoint, I've seen much more Scala than F#, but that could just be my circles. Though I have also seen some cunning people advertising Scala positions as a crude heuristic to get better Java programmers to apply.
For learning FP though, Haskell is the way to go. Specifically, with Learn You a Haskell For Great Good. I came at Scala after having learnt a reasonable amount of Haskell, but I think if I were learning FP with Scala it would be far too easy to mix up imperative and functional and find it harder to learn the functional style.
I'm in London and I've had more unsolicited contact from recruiters looking for Scala devs than anything else since I put my scala experience on my linkedin profile.
Drop me an e-mail (address in my profile) if you'd like their details.
Haskell is for native application, it can use C libraries. Scala runs on java VM and can use any java library. It is slightly less concise than haskell. Like haskell, it has very clean theoretic foundations. It benefits also from a good framework (Play) and from a good eclipse integration.
In the context of Finance, I have read about Haskell and other functional programming languages several times before, so I was wondering what were the specific benefits of doing financial stuff in functional languages? Is it because complex solutions are easier to prove to be correct? And how does the (more or less purely) functional approach there work out with the fact that they basically do I/O all the time, meaning (I guess) high frequency input of financial data, computing and then output from and to standardized existing interfaces?
Edit: What I mean by that is - everytime I read FP books, IO is basically what everybody tries to explain on the last few pages and is rather ashamed to do at all. That makes it hard to imagine how those languages come to use in real world scenarios, that's why I'm asking ;-)
not much help here as I didn't really learn Haskell, but from my experience I saw more scala job postings than F#. another fun language you could consider is clojure
I too suggest that Scala is worth learning, coming from Haskell. The integration of OO with FP that Scala achieves is magnificent, and any future mainstream language will be measured against it. I would also argue that Scala, which has been influenced heavily by Haskell, improves on Haskell in some domains, in particular, modularisation and generic programming facilities.
Yes, Scala's worth learning. If you've used a JVM language (e.g. Clojure) and know Haskell, it should be a snap. I liked the "stairway book", of which Odersky himself is an author.
Scala the language is great. There are wide variations in Scala code, given that it's a meeting point between about 4 languages (Java, Ocaml, Erlang with its actor model, and now Lisp with macros). Some Scala code is very good, some is bad. But yes, I would say that it's absolutely worth it to learn the language itself. No question.
That was very much the experience at a previous place I worked: they tried scala, but didn't really embrace it. They ended up with somewhat more concise Java code :-)
Scala will easily dominate the JVM largely due to web use cases.
When you have companies like Twitter, LinkedIn, FourSquare behind it there is that air of credibility and longevity which companies look for when committing to a new technology. Plus the popularity of frameworks like Play doesn't hurt.
> Scala will easily dominate the JVM largely due to web use cases.
Not sure what you mean by that. The web situation on Scala is murky at best.
First, it looked like Lift was becoming the de-facto standard web framework on Scala (which doesn't mean much in comparison to web frameworks on other platforms such as Java).
Then Play switched to Scala and Typesafe decided to adopt it instead of Lift. Play 2 was (and still is) quite controversial because a lot of Play 1 users see the move to Scala as a step backward because templates take so long to compile right now.
The result is that the web landscape on Scala is heavily fragmented and while Play 2 seems to be the standard on it today, this does very little to support your point that "Scala will dominate the JVM largely due to web use cases".
Either way, Scala has been around for ten years and it still has a less than 5% mindshare on the JVM.
Clojure is more popular than Scala for web stuff, especially among the startup set. Clojure is increasingly popular for analytics and data-driven use-cases, partly due to Marz.
If you want to get a job doing FP, F# is a better bet. Most scala jobs are places that treat scala as java++, and using anything beyond the most basic FP concepts will be off-limits. I found my haskell job by making it. They were doing stuff in PHP that had no business being in PHP. I did it in haskell instead.
Who's we if you don't mind me asking? How's your experience of snap been? I'm thinking of building a little SaaS effort on the side and would want to use Haskell for at least the backend, and maybe even the front end with fay.
I can't say. But nobody you would have heard of, just a small marketing/web dev type place.
>How's your experience of snap been
In 15 years of web development, this is the closest I have come to being happy with the results of my work. I'm sure part of that is just my experience letting me do things better as time goes on, but a good portion of it is that haskell and snap are less irritating that the other options I've used.
I found frameworks in the java/RoR style to be more of a hindrance than a help, so snap suits me well personally. It is more like a library than a framework, it basically just takes care of the "what kind of monad stack do I need here and how do I nest components" problem for you, and then gives you some components you can choose to use or not as you see fit.
I took this course the first time through and really really enjoyed it. This time I got a bunch of my Coworkers to sign up by promising them I could TA the course for them. It should be a good time had by all. Especially since we can then deep dive into parts of it to show how it applies to real world problems.
I would like to add one thing to this discussion: Martin Odersky's class (I took it last year) is also very useful if you use other functional languages rather than Scala. I have been using Clojure for about 2/3 of my development in the last year and I found this course to be useful. The lectures are also fun to watch.
You're highlighting one of the most positive things about the course: it's functional programming with Scala, in that order. The Scala part is less important than the ideas behind FP.
(And I, too, found the course very useful. It's certainly changed how I think about and develop Java code).
Wish it had a Google sign-in button. Don't get me wrong, I hate it when sites force you into signing with one of these sign-on services (or worse - Facebook-only sign-in, like Spotify was for a while), but I also appreciate being able to use that quickly when I don't care that much about the site, and I wouldn't waste my time creating a "full account" to see what's about.
For those who have taken it already, what's the time commitment like? I would hate to sign up to find myself swamped with more hours than I can feasibly handle on top of an already full schedule.
It really depends on how quickly you can wrap around your head around FP; I had done a little bit of Scala before the course and usually could code the assignments in an evening. The assignments are really fun, by the way.
I cannot recommend this course enough. The lectures and assignments are very well organized. It was worth every minute, and I look forward to a "level 2" FP course from this instructor.
I have been trying to play with Scala for the past year, and I have made some strides, but I keep falling back to language with which I am comfortable to just get things done. This is largely in part to my lack of familiarity with Scala, but I have really wanted to tackle a large project with it. I have read the book that Martin Odersky wrote, but this will be an awesome addition that will, hopefully, push me over that final hurdle to becoming productive. Thank you for posting this! I signed up today.
Functional programming is the most important CS topic if you want to become a great (1.5+) engineer. No, you aren't going to be doing pure functional programming very often. In the real world, eliminating mutable state is neither possible nor desirable. It's extremely worthwhile to learn how to manage state, though. Hell, even the Unix philosophy (do one thing, do it well) was directly inspired by functional programming, though it couldn't be purely functional (infeasible at the time, plus semantic mutability).
TL;DR: If you don't know what "flatMap that shit" means, then it's worthwhile to learn it.
As a strong Haskell programmer I'm curious about the statement that "eliminating mutable state is neither possible nor desirable". My first response is to say that I find it both possible and desirable. My second is to note that "elimination of mutable state" isn't really the goal.
The real goal is to give mutable state a very composable, repeatable, clear, and restricted semantics. This is what occurs in the State monad in Haskell, for instance. You retain mutability (observable w.r.t. the stored state over applications) but can slice up the mutation and the intermediate, immutable values and recompose them in various forms with impunity.
That kind of state model is incredible to learn. Monads might be scary because they're unfamiliar, but in a functional context they can do some beautiful things.
The State Monad isn't really mutating state though, it's really a monad for composition of incremental operations upon immutable data structures. The ST monad is for 'hiding' mutable variables and ensuring their state doesn't violate referential transparency.
Monads are a way of reifying and manipulating context. If that context includes a background mutable state model, then yes. Monads are more useful than just for providing mutable state.
That said, your example is just a constant function, not a monad at all.
The point of monads wrt. mutable state is not that they hide it—indeed they uncover it and make it more explicit. I have to exactly specify where my code makes mutable or world-observable changes. Furthermore, through explicitness I can now manipulate, compose, adjust these abilities very flexibly.
As a strong Haskell programmer I'm curious about the statement that "eliminating mutable state is neither possible nor desirable". My first response is to say that I find it both possible and desirable.
It depends on your tools and your performance requirements. I guess I should say that "eliminating mutable state from your repertoire is neither possible or desirable". There are certainly many problems where you can.
Oh! Agreed completely now—there are times and algorithms that are definitely best done mutably. (Another plug for the ST monad, I suppose, since it can make it clear when you're doing such a thing.)
You should know it, but don't get all ideological and neglect your advanced object or imperative programming training. You might even want to look at gasp other paradigms like rule based coding to broaden your toolbox a bit.
tl;dr scala is the best object-oriented imperative programming language I've ever used.
This is something I think Martin Odersky did really well in this class... he spent a decent amount of time discussing tradeoffs between FP and OOP and how one might arrive at choosing the different features of Scala, even going so far as to cover the "expression problem" in Scala. I think it was a superbly tasteful presentation of Scala and FP.
I prefer the pure OO trait-based solution to the expression problem that isn't supposed to exist; pattern matching is not the only way to do it. Scala is just that good.
Sure, being ideological and closed-minded is never a good thing.
But one of the takeaways is that lambda expressions/anonymous functions, first-class functions, and function closures, are very powerful tools that should be provided in any modern, high-level programming language.
The fact that they're working on adding these features to Java 1.8 is testament.
Would be nice if they could also add polymorphic function/method declarations and Hindley–Milner type inference, but oh well, you have to start somewhere...
Right. Scala is functional like C# is; yes, the functional abstractions are more powerful than C#, but like C#, its not forced down your throat. I'm still waiting for people to discover how Scala is the best OO language we have so far, traits are incredibly powerful and case matching on top of that is just icing.
Heh. When I first checked out Scala, what I liked about it was that it dealt with a lot of the stuff that annoyed me when going from Smalltalk to Java :)
This is very well said. I kind of think of it like learning calculus - if you aren't an engineer of very particular types you likely aren't using it directly, but the thinking patterns influence your analytical thinking tremendously.
Essentially he rates programmers on (IIRR) a 0-3 scale of impact - so a 1.0 developer neither adds nor subtracts to the overall quality of the code base, and a 3.0 invents C and Unix.
This quote is something we should all measure ourselves against - honestly and painfully at times.
1.4 to 1.6: Solid adder: well above-average (top 10%) by
software-industry standards, but average (at 5-10 years’
experience) in the context of the best companies (e.g.
elite startups, Google, and research divisions of IBM).
Can be trusted to independently solve most problems in an
elegant and maintainable way. Engineer can make reasonable
time estimates and communicate in both business and
technical terms with management as well as other
engineers. Can handle small levels of deadline/delivery
responsibility and should be encouraged to participate in
architectural decisions (“multiplier” concerns). Technical
leadership non-urgent projects is a serious possibility.
That's average base level in my book. And sometimes I mess up on those too. (Communication being a big bug bear for me)
You are on HN so it's a good guess its productive. You know enough to know PhP and w3schools indicates there is more to learn and so I would guess you are on the right path
As for everything else - I don't know till I read your code
No idea, but there are certain semi-discrete barriers that I've noticed:
0.8: difficulty with fundamentals. There are people out there who just can't get code to compile, or struggle with core concepts like pointers and recursion.
1.2: corporate work frontier. Large "commodity programmer" teams tend to focus more on creating a home (slight, reliable, adder status) for a large number of mediocre players than on developing talent. Most jobs won't take you far beyond 1.1-1.2; even the team leads in most corporate shops tend to be only 1.3-1.4.
1.8: escalating difficulty of getting appropriate projects. You can get to 1.5, 1.6 through side projects, book reading, and exploration in your spare hours. It's quite rare, however, that people get to 2.0 without having the (very uncommon) opportunity to do 2.0+ level work full-time. To push beyond 1.8, you need to get more autonomy in your job than most programmers ever have.
What about things like data structures, general understanding of programming language semantics, basic problem decomposition for data hiding and abstraction, ... ?
>No, you aren't going to be doing pure functional programming very often
I do every single day.
>In the real world, eliminating mutable state is neither possible nor desirable.
Eliminating state is not what functional programming is about.
>If you don't know what "flatMap that shit" means, then it's worthwhile to learn it.
Scala is a pretty terrible language to be learning it though. Subtyping makes things far more complex and difficult to learn, just for the benefit of java compatibility (which doesn't matter if you are just learning for the sake of learning).
Subtyping isn't just for the benefit of Java compatibility. What makes you think that?
Such arguments are in general hand-wavy and born out of folklore or personal biases and I hate to appeal to the popularity argument, but in the presence of overwhelming popularity of languages that do have type-systems with subtyping, you do need at least some sort of proof that subtyping is bad in one way or another. Even GHC has extensions for subtyping, without being burdened with Java compatibility.
And what are you comparing Scala with exactly?
If you're comparing it with Clojure or other LISPs, well that's like comparing apples to oranges, because there's a world of difference between techniques used in static languages like Haskell/ML and Scala on one hand and LISPs on the other. "flatMap" in particular is not something that you see often in Clojure. You don't quite see many instances of monadic types in languages like Clojure either. Scala's Option[T] or Haskell's Maybe are impractical in Clojure so you'll never see it in Clojure unless you're looking at code that was written by a Haskell developer. Etc...
Compared to Haskell, Scala does have some disadvantages, however even if you're learning it for learning's sake, it's easier to get started in Scala because of the ecosystem ... you've got everything, including capable IDEs like IntelliJ IDEA and people that complain about SBT never tried Cabal, plus with the JVM you can always use Maven or just plain Jars manually copied in a directory.
>Subtyping isn't just for the benefit of Java compatibility. What makes you think that?
No objects = no subtyping.
>you do need at least some sort of proof that subtyping is bad in one way or another.
Why do I need proof of something I didn't say?
>Even GHC has extensions for subtyping,
What?
>however even if you're learning it for learning's sake, it's easier to get started in Scala because of the ecosystem
The ecosystem matters the least when learning for learning sake. The complexity and difficulty of the language matter, and scala is a poor choice for that reason. You can't just learn FP with scala, you also have to learn all the hairy OO/FP integration and the ensuing problems around it.
On my remark about Haskell/GHC with extensions, I'm talking about things like the Dynamic type, existential types, HList and about experiments like OOHaskell.
> The ecosystem matters the least when learning for learning sake.
Actually it matters the most, as good learning can only happen if you go forth and experiment on your own. That's why some languages like Python are popular, because as soon as you read a couple of chapters from a book, it's usually easy to let your imagination loose and build something. In comparison to learning math where proofs are like puzzles, in software engineering the real joy comes from building stuff.
> On my remark about Haskell/GHC with extensions, I'm talking about things like the Dynamic type, existential types, HList and about experiments like OOHaskell.
The point of subtyping is implicit coercions: using a type T1 when T2 is expected, without extra conversion. Dynamic and existentials are not subtypes (you need fromDyn or the data constructor introducing the existential). OOHaskell is as far as I know a failed and abandoned experiment. Who uses it? I don't know HList enough to comment, but it's based on GHC's constraint system and very much unlike subtyping in Scala. I agree with you that OOP is not the same as subtyping.
>> The ecosystem matters the least when learning for learning sake.
> Actually it matters the most, as good learning can only happen if you go forth and experiment on your own. That's why some languages like Python are popular [...]
No, the comparison with Python is not fair. Python is a polar opposite of Haskell.
People learn Python as a scripting language. You can learn the basics of the language extremely fast. There's little didactic value in Python the language once you know imperative programming. Then real work comes by learning libraries, frameworks, APIs etc.
People learn Haskell as a way to broaden horizons, see a different paradigm. GHC, with standard library only (covering a lot less than Python's batteries) gives enough material to experiment for months if not years. It takes a while to understand GADTs, type classes, kinds, higher-order types, type families etc.
Learning Haskell is much closer to learning proofs/doing puzzles than software engineering. The fact that you made your program compile after two hours is rewarding like solving a puzzle.
I have seen people attempting to build a concurrent web server in Haskell in first week, not knowing how laziness or class instances work and blaming Haskell for making things weird and unintuitive. The practical mindset of Python does not pay off in Haskell. So I agree with OP - the ecosystem is least concern when learning FP for learning sake.
No, I am not. OOP can certainly exist without subtyping, but scala has subtyping for objects. Haskell does not have subtyping.
>I'm talking about things like the Dynamic type, existential types, HList
None of those add subtyping. What would even be subtyped?
>experiments like OOHaskell
An abandoned experiment that is not a GHC extension.
>Actually it matters the most
You are free to think that, but nothing you said after that support that notion at all. We're talking about learning functional programming for the sake of learning functional programming. Haskell is better for that than scala is. Ecosystem is entirely irrelevant.
I have a question if you care to answer. I was watching "Overview and Introduction to Lisp" (link below.) I was struck by the idea of a function taking a function as input and transforming it to another function as output. My only experience with something similar is JavaScript, but the idea of a function doing function transforms is new to me. Is this the fundamental thing to understand about Functional Programming?
"I was struck by the idea of a function taking a function as input and transforming it to another function as output."
That's a higher-order function (HoF). I'd say it's not the fundamental thing to understand about FP: you can even program in a functional way without using them.
And also you can have languages which aren't putting the emphasis on FP at all and yet who have higher-order functions: elisp, for example (anyone calling elisp functional is automatically setq'ed to crazy ; )
IMHO Lisp dialects aren't inherently functionals. Some are, some aren't. Even Clojure, which definitely puts the emphasis on FP, isn't purely functional, far from it. But you can use it in a functional way (and Java too, in a way -- I used to do "OO over immutable objects" and use "functional Java").
However you'll probably find that when using Lisps in a functional way, you can use higher-order function often. For example if you have, say, a referentially transparent function and want to add memoization for free then it's very convenient to simply (memoize myfunc).
Or if you want to "carry the state" of your program through monads (or to use other kind of monads): then you'll need higher-order functions.
To me if there is one thing about FP it is simply idempotent / referentially transparent functions which make it easier to reason about the program.
I'm simply beginning to "grok" FP, HoFs and Clojure so take this with a grain of salt : )
>you can even program in a functional way without using them.
For a very tiny limited subset of programs. Anything beyond the most trivial of toy apps will use them.
>And also you can have languages which aren't putting the emphasis on FP at all and yet who have higher-order functions
Where their usefulness is seriously hampered by the language not being functional. This is the primary reason people think HoFs are no big deal. They've never gotten to actually use them in an environment designed to make good use of them.
I don't know if I would say it is the fundamental thing, but it is certainly an important fundamental thing. I think if I had to pick a single most important fundamental thing I would say it is composability. That is the underlying reason behind things like monads and lenses for example.
Thanks. I'm liking what I'm hearing. I hear functional programmers say state is evil, but it seems like a necessary evil. What I agree with more -- and they say this a lot it seems -- is that complexity is evil. I like the focus on building something large from smaller, easily understood parts.
State isn't evil, having everything implicitly being able to mutate state is evil. If you keep mutable state, side-effects, etc locked up in their little boxes, then you limit how much they can cause problems.
"Scala is a pretty terrible language to be learning it though. Subtyping makes things far more complex and difficult to learn, just for the benefit of java compatibility (which doesn't matter if you are just learning for the sake of learning)."
Functional and OO programming are complementary and is the point of Scala. The class explains their relationship.
The class is called "functional programming principles". As I said, if you want to learn functional programming principles, scala is a poor language to do so, as you can not focus on that subject and have to learn a ton of extra stuff as well.
"Scala is a pretty terrible language to be learning it though."
Pretty good course though. If you want something like that, maybe because you find it helpful to have exercises with deadlines and things, then I'd reccomend the course. But if you have some alternatives you wanna recommend, that'd be awesome.
For Haskell, the only similar thing I know of is the Channel 9 stuff with Erik Meijer. And that's cool stuff. But you're much more on your own there than in a Coursera course. So if you want that kind of thing it might not be a good match.
Even Benjamin "SML, SML uber alles" Pierce spends a portion of his Types and Programming Languages text contrasting objects with existentially-typed abstract data types, and finding that, IIRC, objects are often the more practical and convenient approach.
> No, you aren't going to be doing pure functional programming very often.
Some people claim that one is often able to make programs with a mostly functional core; in which case most of the code is purely functional. Do you not think that is the case?
For anyone unsure about taking the course, I wrote about my experience on my blog [1], maybe that will be of use. I posted more technical details of the course contents on google+ (links in the blog post).
[1] http://www.avparker.com/2012/11/25/functional-programming-pr... .