I used to use them. You have to set up an account with a client certificate, which is a pain, then be manually approved. The free certs are for personal use only so they will deny you if they think you will be using it for business of any sort.
Caveat Emptor: I used Vim for a long time, but switched to Emacs about 7 years ago. I still miss Vim, but would not give up Emacs for it.
Many consider Emacs' extension language, Emacs Lisp, to be significantly better than Vim's extension language, VimL. This makes it easier to develop better packages, and also to develop personal extensions/modifications.
This problem has lead to a number of attempts at fixing this:
1. "Evil" is an attempt to port Vim to Emacs, sans VimL. You should see it here: http://www.emacswiki.org/emacs/Evil. Note: there have been a number of these in the past, and Evil is the latest project successor.
TBQH I think most of the instances of ruby metaprogramming are bad, increasing complexity dramatically without real benefit. Ruby "rediscovered" metaprogramming without learning the lessons of the Lisp community.
Macros are great, though. It makes some things very simple that are otherwise unreasonable. They just need to be handled with care.
No, on this occasion I specifically intended not to link. If people want to they can look it up. In the past I've always provided links, and reactions have always been mixed. I'm now weaning myself off doing anything about the endless repeats, consciously taking the point of view that no one really cares, and it's not that big a problem. I've written about this at length in the past.
Personally I don't get contracts when they aren't used for static verification.
It's much easier to use defensive coding techniques at runtime without having yet another framework in there that anyone who wants to read the code has to learn. Typing a few lines less is not really a benefit when it basically increases code complexity.
The Contracts gem is very easy to use. I introduced it at work recently, and everyone got the hang of it in about 20 minutes.
A lot of languages (Java, C#, Go, etc.) have very inexpressive type systems, and that tends to make many dynamic language developers wary of them. Contracts has a very expressive type system though. It understands duck typing, adhoc union types, and a bunch of other stuff that makes it a great fit for a dynamic language.
Plus, we've disabled it in production, so we get coverage in test/development mode, but no performance penalty in prod. I look at it as an extended form of testing. Type contracts are very quick and easy to add, and they help tests catch additional errors. They're also useful in code reviews. Sometimes I'll have to search for 5 or 10 minutes to figure out what kind of thing is getting passed in, where the contract makes it perfectly clear.
The best part is that the contracts are optional. If some method takes wildly differing arguments and it's going to be a pain to give it a contract, then don't.
This is the best tool I've added to my Ruby arsenal in some time. I strongly recommend taking it for a spin.
What I meant was that contracts in a language like C# give me the ability to statically verify the program at compile time. It is not a "nicer way to add conditional testing logic" but a way to formally prove correctness in my programs.