Well, about a year ago I started programming in dynamic languages like python and Ruby. I did very little of python and a lot in Ruby. At first I thought "Hm, it must be really hard to program without autocompletion, static type verification, etc.". Soon I found out I was wrong.
First, in Ruby it's very easy to test the code. And you can do crazy things like what I mention in here ( http://weblogs.manas.com.ar/ary/2010/04/15/quick-way-to-test-many-values-in-ruby/ ) [[1, 1], [4, 2], [9, 3]].each do |input, output| test "sqrt #{input}" assert_equal output, sqrt(input) end end and the good thing is that if it fails for a specific input/output pair it is treated as a different test, so you can clearly see which input/output pair failed. I can see you can do the same in D with string mixins, probably putting all the code between do/end in a string... :-( Second, I found out I have to type a lot less. And names are very consistent and intuitive in Ruby and specially in Ruby on Rails, so I don't need that autocompletion anymore, I can just type what my mind think is correct and it works. And I do use some autocompletion, I switched to use gedit first, then vim, and it seems to be enough to autocomplete things based on the words on the open documents. And autocompletion might show you the list of methods of a class, but that's not useful if you don't know how to use those methods in combination. For that, you need to read the class' documentation about it's usage. And that, you can find it *a lot* in Ruby libraries. After all, what's important is how to use a class for what you want to do, not what methods it provides. This concept is so strong in Ruby that sometimes you just see things documented like "To use this, do 'basic_auth :user => x, :pass => b' without even caring about the signature of the method". Third, go to declaration, I can do that in vim with ctrl+], using ctags. Fourth, rename refactoring. That is the thing that is likely less to happen in a project. The most common refactoring are logical, not just names. And after refactoring by hand I just run the tests and fix whatever is there to fix. It completely changed my mind about how to develop software (previously I also did tests, but in Ruby I can test more things and much more easily... for instance, I can mock a static method or even a top level function, which I cannot do in D or Java... so in those languages I have to do dependency injection and change a lot the way I should be programming... making my code harder to understand and to follow. In Ruby I can program directly what I want and still test it, always). What do you mean by "compiler checked documentation"? And Ruby might be slow(er than X), but when you program a website or something where the database time or http request time is orders of magnitude higher, you don't care the language to be a little slower. In the end you can never blame the language for your app being slow, you might to do load balancing, optimize your queries, etc. BUT. D is a systems programming language, so the above paragraph doesn't apply. But I still think some things in D could be improved.
