In all intellectual debates, both sides tend to be correct in what they affirm, and wrong in what they deny. - John Stuart Mill
Big letters don't make differences for a cake. The taste matters. Isn't it?
I was not aware of the debates going around in the industry about Ruby. Thats basically about comparing Ruby with other programming languages. Before proceeding further, I would like to insist that am passionate about C# and deep into the language's ability. And I write this article because for my previous post, I ended up with debates floating around with invalid (atleast to some extent) questions like that above.
Here is the famous Q&A model of writing an article which paves way to debates, but I need it in the form of a healthy discussion without hitting any individuals.
1. Should we compare Programming Languages?
Not all the questions need to be ended up in a single Yes or No answer.
Not much surprising, developers who are involved deep into technology never hesitate to compare languages. But those developers who are working as end users of any specific compiler for years, stick to that particular language, never get out of it and start to advocate on its behalf (some kinda addiction and possessiveness). The latter's stand is always that their pet language is the best in this world and the creator of that language is their God.
There is no point in sticking to any lanuage. Take the case of Microsoft. They started with BASIC, added 'Visual' to its name. Later they jumped into the so-called powerful VC++, and then with frustration created their own language C#, again with the same prefix "V." If nobody is there to compare programming languages in Microsoft, could Visual Studio be in the market, or could C# be? Please don't start any out-of-scope debates here whether am a proponent for Microsoft, or C# is better than Java/C++, or so with endless concerns.. and thats not the intention of this post. They are already under hot debate.
2. Can we compare an Interpreted Language with a Compiled Language?
This is a question which I faced indirectly for the previous post in my blog. The question I faced was, "Hey joker!! How dumb are you to compare C++ with JUST a scripting language, Ruby!!" I felt sorry for that friend. I have rephrased it to the question above?
In this ever-developing world of OSS, there is no difference between a compiled language and an interpreted language. Hot under the collar?? You should "not" get into academic text books to see the difference between the both. Rather, you must look around the industry altogether.
VB was an interpreted language, and now its getting compiled into IL (Intermediate Language) in .Net. (FYI, C# Java are all semi-compiled languages i.e., semi-interpreted languages) After all, a question raises here that "What do you mean by a compiler?" Root back. Get into books. It does not mean thats a conversion of a high-level language to Machine-understandable words. It CAN also mean the conversion of a very high level language into an intermediate level language. If you cannot go with this point, then you should not work in .Net or Java !!
There are setbacks for any Interpreted language. One of them importantly is - Interpreted languages are slower than Compiler Languages. The reason is that the code is validated against the syntax at run-time (parsed), dynamically linked, converted to the native language or an intermediate language. Whuf!! It really takes time.
The pros of the same family mostly revolve around easing the job of a developer. What he sees in the code is what he gets. They are easy to read, elegant to read (thats the only point I advocated in my previous post
The pros and cons doesn't end here. There are many. But, the general opinion is that Interpreted languages eats CPU cycle to make the developer's life simple.
I would like to throw lights at this point on well-biased comparative studies from both the ends  and . Again, please don't debate about Mr.Naidu or Mr.Vincent here:) Take their words. Leave comments about them and their article there.
3. So, Interpreted languages should not be used in projects targeting at scalability?
If you have interpreted like the way, then it shows that you are stuck to a compiler. Increasing your hardware cost would fix it. As I already said, many (and not all) scripting languages are easy to read and hence easily maintainable (though the learning curve is not pleasing). This leads to an increase in productivity of the developers.
In simple cases, increasing the developer head-count is not better than increasing two servers, from the perspective of a CFO. Spending $40000 for 2 developers and $100 for a server is not better than spending $25000 for one developer and $300 on 3 servers. But kinda win-win between the CFO and fellow developer!! Again, please don't debate on CFO's profits over Developer's profit. This is not the context. Thoughtworks is an example for the above scenario. They are pioneers in increasing developers' productivity dramatically and they are into many Ruby projects. (FYI, not JUST Ruby projects, but many others)
4. This could be a valid point for projects involved with big (comparably ;) servers. So, what happens in the case of small hardware equipments? Can we use Scripting/Interpreted languages there?
There is a general misconception that Interpreted languages cannot be used in hardwares altogether. Popularity of a language has nothing to do with its ability. If C++ or C is used in most of the hardwares, that does not mean they are the only languages fit for hardwares. If you are looking for pucca scalability in hardwares, then you must end up doing it in machine language or in worse case, using 0000001010101010... :) and not using C/C++.
Am not aware of hardware programming, but at least have went through some articles to justify my stand. Interpreted languages can be used in hardwares. Then, what about the CPU cycles ate by those villainous Interpreters? World is moving towards compressing GBs into millimeters. Hardwares are getting better to withstand any load and sorry for those who work in legacy hardwares (You have the privilege to stick to Bjarne Stroustroup). Am speaking here about present and future, not history. And as of I know, there are hardwares which run on Ruby.
And again from a CFO's perspective, if you need 10 promising, experienced developers for developing a "scalable" hardware using C/C++ or any compiled language, then you need 2 hardware engineering architects and 3 software developers (or even 5 or 6 is also scalable for the pockets) to do it in ever-pleasing and easily maintainable interpreted languages.
I stress, am not even a novice developer for hardwares. But the above points could be validated against any resources available.
To make the counter-part happy, here is an excerpt from the reference 
And I believe that CFOs and their company's clients will never give up feasibility in terms of Money over feasibility in terms of programming languages.
5. So, what is your conclusion?
Conclusions are upto you. But, here is mine:
It depends upon the situations. If you are targeting towards productivity of developers, then many (not all) of scripting languages are there to help you. If you are targeting towards a legacy hardware system and largely available developer community of Compiled languages (lazy enough HR department to catch a few scripting language developers), then go with the compilers. This is my opinion.
A word of caution: don't believe in any other's suggestions (here or in the comments that may follow). Research for yourself and end up with the truth, not even the fact!!
Here are the references I have used as a ground-work for writing this post:
Here are some important excerpts from these links, and the last one is important:
This post is available in printable format. Click here to view or print
This post is available also in pdf format. Click here to View or Download