Note that the installation instructions on that site are completely out of date. You don't need a C compiler anymore, just clone the repo and enable the extension, as described in the README: https://bitbucket.org/durin42/hg-git
I disagree with labeling work on less-imporant tasks as procrastination. I think it's often (but not always) more effective to breeze through less important tasks that you're itching to do instead of slowly trudging along the highest priority task that you detest. The unpleasant topmost task becomes much less daunting once you've built momentum with a few easy wins and can see yourself as a producer instead of a procrastinator.
There's also the idea of structured procrastination, [1] which turns procrastination into a productivity tool. It's based on the insight that an unpleasant task may become attractive when seen as a way to procrastinate on something even more unpleasant. For a true procrastinator it means working productively on tasks #2..n instead of reading Hacker News thinking "one last article and then I'll start working on task #1". It's an excellent way to avoid getting stuck in a vicious cycle of procrastination, and calling it "hidden procrastination" is unnecessarily negative.
> I do a lot of research and learn about programming in my spare time, but have hardly any personal programming projects to show.
I think this point is not stressed enough whenever this subject comes up. A person who spends all his free time reading CS research papers and experimenting with different solutions to problems he encounters in his field is not passionate by this standard if he doesn't have a pet _project_ to show at the interview.
I think generally object validation should remain separate from construction. The documentation for Python's FormEncode library explain this well:
> Validation is contextual; what validation you apply is dependent on the source of the data.
> Often in an API we are more restrictive than we may be in a user interface, demanding that everything be specified explicitly. In a UI we may assist the user by filling in values on their behalf. The specifics of this depend on the UI and the objects in question.
> At the same time, we are often more restrictive in a UI. For instance, we may demand that the user enter something that appears to be a valid phone number. But for historical reasons, we may not make that demand for objects that already exist, or we may put in a tight restriction on the UI keeping in mind that it can more easily be relaxed and refined than a restriction in the domain objects or underlying database. Also, we may trust the programmer to use the API in a reasonable way, but we seldom trust user data in the same way.
Lately I've even played with the idea that maybe Clojure style strict separation of data and functions is just taking the single responsibility principle of OO design to it's ultimate conclusion as the responsibilities of storing a piece of data in memory and the responsibility of deriving new data from it are separated...
If your code uses a lot of new utilities, some readers may complain
that it is hard to understand. People who are not yet very fluent in
Lisp will only be used to reading raw Lisp. In fact, they may not be
used to the idea of an extensible language at all. When they look at a
program which depends heavily on utilities, it may seem to them that
the author has, out of pure eccentricity, decided to write the program
in some sort of private language.
All these new operators, it might be argued, make the program harder
to read. One has to understand them all before being able to read the
program. To see why this kind of statement is mistaken, consider the
case described on page 41, in which we want to find the nearest
bookshops. If you wrote the program using find2, someone could
complain that they had to understand the definition of this new
utility before they could read your program. Well, suppose you hadn’t
used find2. Then, instead of having to understand the definition of
find2, the reader would have had to understand the definition of
find-books, in which the function of find2 is mixed up with the
specific task of finding bookshops. It is no more difficult to
understand find2 than find-books. And here we have only used the new
utility once. Utilities are meant to be used repeatedly. In a real
program, it might be a choice between having to understand find2, and
having to understand three or four specialized search routines. Surely
the former is easier.
So yes, reading a bottom-up program requires one to understand all the new
operators defined by the author. But this will nearly always be less work than
having to understand all the code that would have been required without them.
If people complain that using utilities makes your code hard to read,
they probably don’t realize what the code would look like if you
hadn’t used them. Bottom-up programming makes what would otherwise be
a large program look like a small, simple one. This can give the
impression that the program doesn’t do much, and should therefore be
easy to read. When inexperienced readers look closer and find that
this isn’t so, they react with dismay.
We find the same phenomenon in other fields: a well-designed machine
may have fewer parts, and yet look more complicated, because it is
packed into a smaller space. Bottom-up programs are conceptually
denser. It may take an effort to read them, but not as much as it
would take if they hadn’t been written that way.
Thanks for the links! It's nice to see shyness and intro/extroversion addressed as separate things. I've always had a really hard time identifying with descriptions of both introverts and extroverts. I'd really like to read about shy extroverts, if that's not an oxymoron, since I suspect that that description might fit me.
My personal point of view is that I do not want to cause any suffering when I can avoid doing so (i.e. when my survival does not depend on it). Only a conscious being can suffer, and, as far as I know, plants are not conscious. There are organisms of all levels of complexity between single-cell organisms and homo sapiens, and no-one knows for sure where true consciousness begins, but the line between things and beings needs to be drawn somewhere. I have personally drawn the line between plants and animals, just to be on the safe side. It may be too far, and there's a risk that I'm not using some things for fear of causing suffering to a conscious being, but I'm OK with that.
Thanks for the thoughtful reply. Don't worry, I'm clearly out of my depth here, so I'm not going to debate you on this particular point any further -- you win. :-) (I still stand by my original statement, but I'm unable to put my point to words as well as you can yours.)
What bothered me about the article, and prompted my original, poorly worded, reply was the fact that dogs are treated with more empathy and respect than other kinds of animals (even to the extent of harming other animals to bring them joy). To me this humane attitude seems so intuitive that I feel like it is not so much consciously learned to be felt for dogs as suppressed for all other beings. I don't think there's anything special about dogs in particular since they are not given the same status in all cultures. It's not about their utility either (anymore): most people get dogs because they feel sympathy for them, and not the other way around.
As you seem to be knowledgeable about ethics, do you happen to know of any books that deal with this tendency of humans to strongly empathize with some animals while having no trouble harming others? I'd like to read more about the issue from any viewpoint, be it ethical, psychological, or cultural. I'd like to better understand my own, intuitive worldview, which departed from mainstream when I started thinking about these issues, as well as that of people who do not share it.
Thanks, I didn't think about the viewpoint of "the sheep are going to be herded anyway, it might as well be my dog that has a bit of fun doing it".
I don't think the problem is imaginary, though. I still think it's schizophrenic to cause harm (in this case stress) to one kind of animal not out of necessity, but to bring happiness to another kind of animal -- even if the amount of harm is relatively minor compared to what could have been done. I have nothing against empathizing with dogs and trying to bring them happiness. On the contrary, I think it's illogical to restrict this attitude to dogs instead of extending it to all sentient beings, including sheep.
Here's an upvote for taking the time to answer instead of just clicking on an arrow.
Re: Somewhat sympathetic answer: I thought the reason sheep can be herded by a dog at all is that they are timid and easily frightened, and think of the dog as a predator. If they weren't afraid, they wouldn't defend themselves by flocking.
Re: Sympathy-trumping counter-answer, economic argument: In my opinion moral concerns outweigh economic concerns. Your mileage may vary.
Re: Sympathy-trumping counter-answer, factory farm argument: Harming animals is not justified by the fact that they could have been harmed even more. (Replace "animals" with "people" for plenty of potential analogies. I resist the temptation to write any of them out for the fear of sounding like a troll.)
To the downvoters: Do the sheep find being herded by dogs a pleasant experience as well? If not (as I assume), how can you morally justify increasing their suffering in order to reduce that of a dog?
How about sharing a bit of the empathy reserved for the bored dog with the sheep, which are essentially reduced from living, thinking, feeling beings to just toys for the dog? This kind of speciesism sickens me.
This is a minor nit to pick, but why is the link to their twitter account on their website a button? Maybe I'm not representative of the common user, but I subconciously expect buttons to do something (e.g. tweet the address of their site on my behalf), as opposed to taking me somewhere (like a hyperlink). Like I said, this is a very small thing, but it stuck out to me on the website of a company focused on user experience and interaction design.
>> I've learned how to use git not so much from intuition but memorization of what all the commands do and how they interact.
>Yeah that's what grates me about Git: apparently, unless you're willing to learn all of it from the implementation details up (which I am not as I have absolutely no interest in implementing my own DVCS) you will forever be limited to rote-learned "recipes" because the command-line interface makes no sense in and of itself, it only makes sense if you understand how it relates to Git's implementation details.
That's what I thought, too. After I had typed in one meaningless magic incantation too many, I bit the bullet and dug into the source to understand _why_ the same command was used for three completely unrelated goals (I can't remember what the actual command was, probably reset or checkout).
To my dismay the goals were completely unrelated even in the source code. The command parsed its command line and took different code paths -- not even working on the same data structures -- depending on its arguments.
It's of course possible that I didn't read the code well enough, but even at the source code level it is not always _obvious_ why Git's commands have multiple roles, and why different commands can be used to reach the same goal. My first thought was that at some point it just must have been slightly easier to add a new switch to an existing command than to add a new command.
Needless to say, I'm now a happy user of Mercurial (and its wonderful pbranch extension, among others). My mental model of Mercurial's workings might not be completely accurate, but so far it's been consistent enough to never surprise me, and the commands that I use make intuitive sense within that model.