Elm is heavily focused on user-friendliness and offers a sort of full framework for developing frontend applications, whereas PureScript is focused on producing readable, easily interopable javascript (and javascript only). That is by no means a comprehensive comparison, but those are the main differentiating factors I can see as someone who has been watching both projects for a long time.
Not sure if this is related to the Hawthorne effect, but I could easily see more traffic with liking just due to the fact that it's new and fancy. Maybe a significant number of people noticed the change and clicked the heart a few times just for fun.
I did something similar for about two weeks, where I'd choose an article every day and write my own notes about it: http://kovach.me/notes.html
They were all about a single topic though, and I skim through several articles a day now on various topics. I might start doing this again; I _did_ learn a lot from transcribing notes and I think it could work with a variety of topics.
Well, sort of. One of the big focuses of functional programming is _minimizing_ state; in other words, only what must be passed around should be. Sure, you'll end up having a large context that the entire program operates in, but having to pass around a context incentivizes passing around the minimal amount of context to sub-parts (functions) in the program. You don't need the whole global state? Great; only pass around a small part of it to that part of the program. You don't need the whole context all the time so you don't pass the whole thing around all the time.
I'm not saying side-effecting IO is the _only_ thing that motivates the idea behind Monads, it's just one of the big ones. I mentioned more than just that, and the use cases you mentioned are also big motivators.
The big problem with monad tutorials is that you can't talk about them without understanding the motivation behind them, and that comes from purely functional languages (i.e. Haskell). When you're not allowed to touch IO, use `null`, exceptions don't exist, there is no global state, and all of these things have a common pattern to them, then you can motivate their use and talk about them. In my opinion, there isn't much of a point in talking about them without those things. There are some neat tricks (`flatMap` etc...) but without proper motivation, it's not likely to stick, and the idea seems relatively useless.
On the main project I'm working on, the reason we have develop/master is mainly for hotfixes.
We deploy once a week, but if we need to get something out the door quickly, we make a hotfix branch off of master, then merge it into both develop and master. This way, if we find something that needs to be fixed before the next release, but don't want to push half-done updates, we can seamlessly do it.
Category Theory is all about composing things and being able to reason about them mathematically. In programs, we compose lots of things (functions, types, objects, systems...), and being able to abstract that away is valuable. Bartosz Milewski has been putting together a nice series ("Category Theory for Programmers") for a little while now, that seems to be pretty well-received and may give you the answer you're looking for: http://bartoszmilewski.com/2014/10/28/category-theory-for-pr...
Why is the most common job title "Software Engineer" at the top, but "Software Developer" is listed as the first job analyzed? Were they grouped together?