So far I'm liking the way the course material is structured. In the first week Martin is guiding you through call-by-name and call-by-value in the lamda calculus, but without its syntactic peculiarities and without really mentioning lamda calculus more than once in passing. I think this is a good idea, because lambda seems to raise defense mechanisms in students who are seeing it for the first time. Sneaky.
Edit: I found a place where the web-based quiz mechanism used by Coursera gave me some troubles. In lecture 1.4 there is an exercise to implement functions and(x,y) and or(x,y) but using neither || nor &&. While I was able to compile and run functions that produce correct truth-tables in my Eclipse environment, the web-based form appears to be fairly tempermental with what it will accept. (Equivalent functions modulo only formatting differences made the difference between "incorrect" and "correct".) I managed to proceed by asking myself whether my function was as simple as possible: no newlines, simplest possible expression, no superfluous characters such as {}
The "Scala Worksheet" feature of the Scala IDE plugin sounds pretty nice. Apparently it's a multi-line REPL, where changes automatically get compiled & evaluated upon save.
I'm having some trouble figuring out how to get it installed in my Eclipse, though. I already had an older version of Scala IDE installed, and apparently this is a fairly new feature. I tried the latest milestone, which is supposed to have it, but I don't see New --> Scala Worksheet when I try to create one.
Has anybody fought this dragon and won?
Edit: I have found my own answer. The trick was to use the following URL as the "update site" when installing ScalaIDE. When you do, the "Scala Worksheet" plugin will appear under the list of available software.
Unfortunately the Scala IDE doesn't yet work with Eclipse Juno. Eclipse made a breaking API change. It's a shame they can't provide better backward compatibility; every new Eclipse release seems to break a lot of plugins.
https://github.com/scala-ide/scala-ide/pull/145
Curious about something - if you had to do a new project from scratch today on top of the JVM, which language would you choose: clojure, scala, jruby (or anything else).
I ask because my brain really cant absorb too many languages, and I want to make some kind of pseudo-optimal choice. I'm not just talking about some shootout here, but about the the next 5 years outlook.
>>I ask because my brain really cant absorb too many languages, and I want to make some kind of pseudo-optimal choice
Am in the same boat. I moved to SF permanently 2 months back, after 15+ years in the east coast. Decided to pick 1 language, immerse myself in it deeply, & then start the interview circuit. The opposite approach would be to pick a bunch of languages ( ruby, python, jquery/coffeescript etc. ) and get a smattering of best practices in everything without knowing anything too deeply. Both approaches have their merit. In SF, I recommend the latter approach - you will find jobs almost instantly if you do that. But still, given my proclivity ( I would rather know everything about 1 thing than something about everything) I chose the former approach. I picked Scala, read every single chapter of Odersky's book, & subjected myself to 19 total interviews at 2 multibillion$ companies using Scala exclusively for a "new project built from scratch".
I got offers at both. Now am debating which one to join.
tl;dr Scala is that pseudo-optimal choice you are looking to make. In SF there are a few very-nice Scala jobs with 6-figure salaries & tons of RSU's thrown in...but only if you can hack it. The questions you will be asked in the interview are definitely esoteric & very academic ( difference between reader monad and writer monad, reverse a list without mutation using a foldLeft, kruskal's algorithm in scala, merging graphs with common edges where each edge is a tuple, etc. ) Its not web apps, its not "software engineering", and its not everybody's cup of tea. But if you like academic CS, Scala will not disappoint you.
I wonder why you did not choose to go the Clojure or Jruby (assuming you are not a Ruby guy) route ?
I am not in the valley, but it may be that you picked up on some buzz/conversations in general that lean towards scala. It is quite puzzling since Indeed.com's trends shows a massive lean towards Clojure vs Scala.
> reverse a list without mutation using a foldLeft
This is maybe a little too obvious if you understand left folding at all. A less trivial exercise in the same vein is to implement right folding via left folding. It's just a one-liner, but if you haven't tried it before, it's enlightening and worth giving a shot.
We moved node.js to Scala and play for our startup. I've programmed in grails (groovy) professionally and don't recommend it. I've heard good this about clojure but you either are a lisp fan or you aren't. As such, I don't think closure is the next big thing.
I am not a fan of the required cognitive overhead that scala takes to get started -- reading someone else's code reminds me a lot of C++ and the tooling still needs to catch up. If any of the JVM languages are going to break out, I'd put my money on scala. JRuby has its place as well, and I know of a few high profile projects done in it, so it wouldn't be a bad choice for consumer apps. For enterprise, I think static typing has some major wins.
I want it to be Scala so much as well, I don't want to start learning Go. (Although I heard great things about it, just after learning Scala, I don't want to learn a new language for a few years now)
Outside of the JVM, and for consumer apps, I am starting to think node.js is going to be the winner. It's not there yet. However, as more and more pages go to client-side apps and significant mobile presences, node is building a good enough ecosystem. Working in a single language is nice, though I think the callback system is clumsy. (That's what async or q is for. though I prefer Scala's actor model)
It wasn't right for us on this project, but I can definitely see going back to it for other projects.
I think writing one language both server and client is a big yes for node.js, but looking at my client-side code vs my server code (and I'm writing Javascript since 2001, way before I learned Java) I come to the understanding why Google are investing so much in Dart / GWT (which I think are not there yet)
If Scala/Haskell/Go would become more mainstream, and had a very straight forward / magic-free 1:1 conversion to javascript, then node.js will have much less appeal to me.
If you haven't done JVM stuff before, it's probably best to start with the terribly unfashionable Java 1.6. All of the other JVM languages tend to use its library to large extent and are using a VM which was developed for Java first, so it's good to be familiar with the underlying landscape before exploring the different riffs on it.
After that, if you want to switch to another JVM language, do it, but you should have a much clearer reason than "I want to use an alternative JVM language". Something about that language should grab you. Personally, I think Groovy's great for perl-type work where you'd like to just clack something out in a terminal rather than starting up a new project in eclipse. Clojure is an actual LISP for real functional programming. Scala (IMO, no offense) is a pile of academic features that sound great in theory. Jruby is ruby.
I will choose Play and Scala. Although JRuby/Rails comes as a very, very close second option (simply because all the cool things have a gem, not many have a Play module) But I want to have some sort of static typing to protect me, and as a Java developer, it's where I feel a bit more at home. Clojure is what I'd LIKE to use (with Noir) but I don't have the guts to be honest.
If Play had all the community and gems that RoR has, it would be a very, very strong framework, and something that the enterprise world would (years from now) adopt more likely than RoR (for all the wrong reasons, but such is life)
"I ask because my brain really cant absorb too many languages,... the next 5 years outlook."
Well, the early days of computing had domain specific languages, and I'm afraid we are getting back to that. The days of a one-size-fits-all language are over. Your best bet is to learn the principles and then the syntax differences just aren't that troublesome. The problem is that when you are new to programming, you learn only a small subset of those principles, and then are stumped when it is time to pick up a new language because it may rely on new concepts.
In education, Scheme once occupied the role of being the language in which you could learn and investigate a broad range of principles of computation. However, the perceived need for vocational training seems to have pushed Scheme out of the curriculum.
I enrolled and have watched the first few videos. So far, I really like Martin's tidy scientific approach to functional programming.
To be transparent I had intended to just take part of the course to get a taste because I am in one other class now and I have a total of three starting in the next few weeks. A combination of Clojure, Ruby, and Java more than suffice to get my work done, but I will probably stick with this class and drop other classes instead.
I have a backlog of courses on Coursera. Right now it's this one, the NLP course and Andrew Ng's ML course. I have a project in mind that would benefit greatly from all three.
I've started putting it together in small pieces but ML and NLP are tough topics to learn without some sort of instruction.
I have a pretty good grasp of Scala but I learned in sort of an ad-hoc fashion and I'm looking forward to learning what I imagine will be idiomatic Scala.
Andrew Ng's course ideally excellent, he's a very good lecturer.
I'm liking this course too, it's really about functional programming more than Scala. He says in the first lecture that the curriculum is mostly from a well known book on scheme, just with the languages swapped out.
The NLP course needs some improvement in particular the Chris Manning sections. It was allow over the internal discussion forums. Dan Jurafsky was very good, can't say the same about Chris Manning.
Don't be. He's basically thinking out loud about two languages he knows very little about. It's an entirely content-free post, but because he's famous there's evidently a danger that people might take it seriously.
The fact that he clearly knows so little of Haskell is what's most telling - you shouldn't be taken seriously as a language critic if you don't realize that Haskell also has all of those scary things he lists from the Scala table of contents, with the exception of variance annotations (since it's not OO).
That was interesting, thank you for linking to it.
At first he seemed to be reacting more to Odersky's book than to the language. I wonder if he had first opened "Scala For The Impatient" how his reaction would be different.
Then he takes the odd tack of complaining about arcana in the Scala typesystem, and then suggests Haskell as a solution.
I get the impression that his love of dynamic typing had his mind made up before he even approached it.
"Then he takes the odd tack of complaining about arcana in the Scala typesystem, and then suggests Haskell as a solution."
What's odd about it? He seems to be straightforwardly claiming that Haskell has a less confusing type system than Scala. I don't know whether that's true or false, but certainly don't see anything odd about it.
What does Haskell have to do with dynamic typing? It's about as statically typed as they come. He's saying that if we really want a static typing system, maybe Haskell's flexible and powerful type system is the right approach.
It doesn't have anything to do with it. I probably phrased it badly because I was responding to two different paragraphs where Guido was talking about different things. You would be better served following the link to what he wrote and reading that directly.
I did read it, actually. :) That is why I was puzzled; he suggests Haskell as an alternative, and I thought that was a classy response, all things considered.
I expect it's just luck. I submitted the same story and it also sank. Sometimes the gods of HN are kind to you, and sometimes they're cruel. Don't sweat it!
Perhaps he is interested in spreading knowledge. His post is basically identical to this one, but this one got selected. It's natural to want to understand why, rather than simply giving up. Indeed, if he comes to understand why, then knowledge has spread.
I don't really care about Karma on this site (mine or other people's). If I did I certainly would have checked this comment earlier ;)
If people post for Karma instead of for content, IMHO it is their problem. It won't make the site much better, but it won't make it much worse, either.
It is perfectly possible for both of the following to be true: (1) The community gets what it deserves. (2) Some of the people giving it what it deserves are behaving shamefully.
(At least, it is if "gets what it deserves" means "gets something it's got no right to anything better than" rather than "gets exactly what, in some kind of best possible world, it would get".)
Having said which, I don't think it's all that shameful to write what you think will get the most votes. But I'd rather you didn't.
Because the algorithms determining the content we consume are incredibly important in understanding the systematic biases of the information we internalize?
Edit: I found a place where the web-based quiz mechanism used by Coursera gave me some troubles. In lecture 1.4 there is an exercise to implement functions and(x,y) and or(x,y) but using neither || nor &&. While I was able to compile and run functions that produce correct truth-tables in my Eclipse environment, the web-based form appears to be fairly tempermental with what it will accept. (Equivalent functions modulo only formatting differences made the difference between "incorrect" and "correct".) I managed to proceed by asking myself whether my function was as simple as possible: no newlines, simplest possible expression, no superfluous characters such as {}