Mutable data does not give you any ability to analyse actions over a period of time. For example: "How many people were active during the month of the Indian Elections?" Can't tell you today, because all the data has been mutated away.
Secondly, mutable data also means that you have less scope of drawing new insights from historic data. (Primarily because you never have historic data)
`The golden rule is: rebase your own stuff all day long, as much as you want. Don't rebase once you've published.`
This is a great rule of thumb, which I have had to repeatedly drill into my team-mates. The crux of the problem, I've come to realise, is that people can't differentiate between a "local" commit and a "published" commit.
Git tutorials need to focus a bit more on the nature of git than on simply showing the basic operations.
>it sounds like either machine is a huge time sink for you
No, it doesn't sound like that. There are many things I like to tweak that make me more productive. Tweaking those things is time-consuming, but once it's done, I never have to waste time on it again. This default window manager sucks? Let me spend a day to throw it out and install awesome. I find myself doing the same things over and over again in Emacs? Let me write and store a macro for it. And you know what the really cool part is? _I can do these things!_. And I usually end up learning something useful about the system.
Now you may find Apple OS X perfect and that's great for you. But what if Apple makes some change tomorrow that bugs the crap out of you? Everytime you encounter that "shitty" detail, a little part of you will get irritated and want to take a hammer to your laptop. Or maybe these things don't bother you. I, however, won't live with something like that.
I don't have an opinion about erlang or scala, but I agree with the poster that it is important to do something practical with a language. How will you learn the concepts that a language tries to teach you without actually building something non-trivial in it?
