‘Functional Programming Principles in Scala’ starts today
class.coursera.org
class.coursera.org
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... .
"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.
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.
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.
On the other hand, I don't know if you use Javascript much, but you'll see it in a very different (much better) light after taking a FP course.
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.?
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.)
* the blog of Daniel Westheide (http://danielwestheide.com/) has a series of posts (starting at http://danielwestheide.com/blog/2012/11/21/the-neophytes-gui... and currently at lesson 15) which may be worth reading to complement/expand on the course lectures. Probably not useful for the course itself until you’ve finished week 2 or 3, but relevant anyway.
* the book “Scala for the impatient”, probably the best book out there about Scala from beginner to advanced level
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.
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 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.
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.
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.
You can learn FP and OOP everywhere, but which language combines FP and OOP in such a seamless a way Scala does?
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.
Drop me an e-mail (address in my profile) if you'd like their details.
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.
How come none of these companies list a single Scala job on their web site?
Twitter and Foursquare seem to list many scala jobs. Have you looked?
https://twitter.com/jobs/positions?jvi=oUebXfw0,Job
https://twitter.com/jobs/positions?jvi=o2nHWfwM,Job
https://www.jobscore.com/jobs/foursquare/software-engineer/a...
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.
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.
[I'm part of a London based Scala specialist called Underscore (http://underscoreconsulting.com/).]
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?
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.
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.
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.
And then there's the JVM.
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 ;-)
(And I, too, found the course very useful. It's certainly changed how I think about and develop Java code).
Check it out, they have a very nice setup for grading homework and the videos are very informative.
TL;DR: If you don't know what "flatMap that shit" means, then it's worthwhile to learn it.
tl;dr scala is the best object-oriented imperative programming language I've ever used.
Both are great languages, IMO.
Scala can look like Java or it can look like ML, depending on the author's style. It's very multi-paradigm.
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...
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.
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
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.
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 ST monad has the same game but a different interpreter.
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.
I agree strongly with everything else you said.
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?
Actually, I think that is the best way to do most things. Mutable state should be documented and sequestered.
Perhaps what I consider "pure functional programming" (i.e. a project with all-functional code, except perhaps an I/O layer) is unreasonably purist.
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).
http://ocw.mit.edu/courses/electrical-engineering-and-comput...
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 : )
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.
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.
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.
You are confusing OOP with subtyping.
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.
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.
Here's how variance complicates stuff in Scala: http://www.reddit.com/r/haskell/comments/zxcks/haskell_vs_f_...
>> 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.
That statement is patently false.
Functional and OO programming are complementary and is the point of Scala. The class explains their relationship.
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.