Which is better - cake or CAKE?

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 !!

Here is another crazy scenario for those developers adhering to compiled languages. Are you aware of a C/C++ "Interpreter"? Go through this, reference [4]. Thats okay.. are you aware of an emerging Ruby "Compiler"? Go through this, [5]. And thats why I suggest (not insist), don't say any language as Interpreted or Compiled. Rather, that should have the general label "Programming language" using which you communicate with the underlying machine.

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 [1] and [2]. 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 [3]

Java runs at 1.8 times the speed of compiled C; Lua (using a JIT compiler), at 3 times; Python, at 6.7 times; PHP, at 7 times; Perl, at 9.8 times; and Ruby, at 16 times. So, where performance is critical, Java or a compiled language will fare far better than any dynamic language.

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:
1. http://sapnaidu.net/blog/?p=67
2. http://www.artima.com/forums/flat.jsp?forum=123....
3. http://www.infoworld.com/infoworld/...
4. http://www.ddj.com/cpp/184402054
5. http://www.eweek.com/article2/0,1759,1996960,00.asp
6. http://www.devx.com/RubySpecialReport/Article/34497
7. http://www.reybango.com/index.cfm/2007/...
8. http://www.radicalbehavior.com/5-question-...
9. http://rubyhacker.com/ruby37.html
10. http://www.activestate.com/Products/komodo_ide/?_x=1

Here are some important excerpts from these links, and the last one is important:

Ruby is 16 times slower than JVM"

Ruby is slow.

Ruby is notoriously slow, but we have lots of ideas for speeding it up.

I would say Ruby is Relatively Slow. Ruby does offer a significant amount of power and dynamicity. These Core and Much

Beloved features of the language and the Rails framework contribute to its Relative Slowness.

Fact is, when you make the machine do it, instead of the programmer, there is some expense to pay. These arguments are the same arguments used for and against ColdFusion.

Sure, the Twitter people could have implemented the whole site in Hardware, if they wanted pure On Metal speed. They chose to use technology that got them off the ground much faster than a Hardware/ Assembly/ C/ C++/ etc based platform would have gotten them.

You don't get both sides. Reference: [7]

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

My Experiments with Ruby

Old ways will always remain unless some one invents a new way and then lives and dies for it -Elbert Hubbard

Somedays ago, in my college days, I involved into a discussion with my pals about the level of heights reached by programming languages, frameworks and design tools these days. That was the time when we were introduced to Rational Rose and were fascinated the way it creates the skeleton code of our design. One of my friends, out of his fantasy, said, "You see Prem, some or other day, there will arrive a tool out of the cloud nine, which can simply translate the requirement specifications into chunks of codes. The Engineers' job would be just to wrap it and ship it out to the customer." We laughed with the typical dreams of full-time graduate student-engineers. Although that was a fantasy, I fear that Geekory is in His way to deliver such a tool to his fellows. Going through the language Ruby, without any surprise, reminded me of this discussion!!

As I was already saying, I started to look into Ruby. I was not used to any languages like SmallTalk, Scala, Perl, Python or PHP more than an extent, just had stints. The documentations and tutorials claim that Ruby is, atleast at its granular level, similar to the languages mentioned above. I don't know about it. But involving into thousands of lines of coding in .Net, when I suddenly looked into Ruby, it seemed to be a simple yet powerful language. The words mean it!

Better than speaking lots of words, I would explain you with an example. I used a typical example used in the tutorial for Ruby, from the book Programming Ruby.

To simply put, we will be simulating a song collection, with provisions to append, and delete, in both Ruby and C#. We shall then compare the lines of codes for both and the time spent on them. The result is the words of the authors of the book in its preface:

Our job is to solve problems, not spoonfeed compilers, so we like dynamic languages that adapt to us, without arbitrary, rigid rules. We need clarity so we can communicate using our code. We value conciseness and the ability to express a requirement in code accurately and efficiently. The less code we write, the less that can go wrong. (And our wrists and fingers are thankful, too.)

It happens in Ruby really, and here they in turn say:

These are bold claims, but we think that after reading this book you'll agree with them. And we have the experience to back up this belief.

Coming back to our song collection example, here is the small list of what we are gonna do:
1. A primitive object for the need, Song, with Track-name, artist, and duration as its members
2. A collection class which contains a list of songs, SongList, with methods to add a song, delete a song, and list a subset of the songs.

Simple!! But, what it takes to implement in a language like C#, which is backed by a "Spoon-feed compiler", is not that simple.

Here is the implementation of that in C#:

class Song
{
private string _name;
private string _artist;
private int _duration;

public Song(string name, string artist, int duration)
{
_name = name;
_artist = artist;
_duration = duration;
}

public string Name
{
get{ return (_name == null) ? string.Empty : _name; }
}

public string Artist
{
get{ return (_artist == null) ? string.Empty : _artist; }
}

public int Duration
{
get{ return _duration; }
}

public override string ToString()
{
return _name + " " +
_artist + " "+
_duration.ToString();
}
}


class SongList
{
private ArrayList _songs = new ArrayList();
public ArrayList Songs
{
get{ return _songs; }
}

public Song this[int index]
{
get{ return _songs[index] as Song; }
}

public SongList Append(Song aSong)
{
_songs.Add(aSong);
return this;
}

public void deleteFirst()
{
if(_songs.Count != 0)
_songs.RemoveAt(0);
}

public void deleteLast()
{
if(_songs.Count != 0)
_songs.RemoveAt(_songs.Count - 1);
}
}


class Test
{
[STAThread]
static void Main(string[] args)
{
SongList testSongs = new SongList();
testSongs.Append(new Song("Song1", "Artist1", 234))
.Append(new Song("Song2", "Artist2", 123))
.Append(new Song("Song3", "Artist3", 456))
.Append(new Song("Song4", "Artist4", 908));
for(int i = 0; i < testSongs.Songs.Count; i++)
Console.WriteLine(testSongs[i]);
}

Here are the facts of implementing this:

1. It took me nearly 30 minutes


2. Two trivial compiler hurdles


3. One trivial run-time hurdle


4. 80+ lines of code


5. Most of the lines getting out of the developer's window


6. The most important, am experienced for 2 years in C# and for nearly 7 years in C++

And I felt shy for these figures, because when I tried the same in Ruby, the following code resulted:

class Song

attr_reader :name, :artist, :duration

def initialize(name, artist, duration)
@name = name
@artist = artist
@duration = duration
end

def to_s
"Song: #{@name}--#{@artist} (#{@duration})"
end

end

class SongList

attr_reader :songs

def initialize
@songs = Array.new
end

def append(aSong)
@songs.push(aSong)
self
end

def deleteFirst
@songs.shift
end

def deleteLast
@songs.pop
end

end

list = SongList.new
list.
append(Song.new('title1', 'artist1', 1)).
append(Song.new('title2', 'artist2', 2)).
append(Song.new('title3', 'artist3', 3)).
append(Song.new('title4', 'artist4', 4))

puts list.songs[0...3]

See how readable Ruby is.
Here are the figures for this implementation:

1. Took just 10 minutes


2. No compiler hurdles


3. No run-time hurdles


4. Just 40+ lines of code


5. Each line having not more than a few words typically 2 or 3


6. The most important than any other, I just started to practise Ruby yesterday !!

Stunning!! Frankly and truly, these figures are real. And most of the Ruby programmers could agree with it easily.

Now you can see that the implementation time has decreased one-third (C#:Ruby) and LOC decreased by half, and my experience is negligibly small with Ruby. Smile out :)

With increasing complexity, the implementation in C# turns to be a bottleneck, but hopefully not in Ruby, as the authors of the book claim. Here are the words for you again:

Our job is to solve problems .... The less code we write, the less that can go wrong ...

Heartfelt thanks to Thoughtworks for throwing lights on Ruby!!

There maybe pitfalls in Ruby too, but they are probably shadowed. If you come across any pitfalls of Ruby, I welcome you to post it here.

The words of a Creator

I do not have much patience with a thing of beauty that must be explained to be understood. If it does need additional interpretation by someone other than the creator, then I question whether it has fulfilled its purpose- Charlie Chaplin

Hope you have gone through the writings of any masters in any technology. I have also gone through one such. Those are the words of the creator of a language - very famous in futuristic developers' community - Ruby.

Yukihiro Matsumoto also called as "Matz" is the creator of the language Ruby. I don't want to go in detail about Matz or Ruby as you may find the resources by following the links above, if you are interested. I shall just reproduce the delighted words of Matz about his brain-child Ruby, from the foreword of the book "Programming Ruby The Pragmatic Programmer's Guide"

Man is driven to create; I know I really love to create things. And while I'm not good at painting, drawing, or music, I can write software.

Shortly after I was introduced to computers, I became interested in programming languages. I believed that an ideal programming language must be attainable, and I wanted to be the designer of it. Later, after gaining some experience, I realized that this kind of ideal, all-purpose language might be more difficult than I had thought. But I was still hoping to design a language that would work for most of the jobs I did everyday. That was my dream as a student.

Years later I talked with colleagues about scripting languages, about their power and possibility. As an object-oriented fan for more than fifteen years, it seemed to me that OO programming was very suitable for scripting too. I did some research on the 'net for a while, but the candidates I found, Perl and Python, were not exactly what I was looking for. I wanted a language more powerful than Perl, and more object-oriented than Python.

Then, I remembered my old dream, and decided to design my own language. At first I was just toying around with it at work. But gradually it grew to be a tool good enough to replace Perl. I named it Ruby---after the precious red stone---and released it to the public in 1995.

Since then a lot of people have become interested in Ruby. Believe it or not, Ruby is actually more popular than Python in Japan right now. I hope that eventually it will be just as well received all over the world.

I believe that the purpose of life is, at least in part, to be happy. Based on this belief, Ruby is designed to make programming not only easy, but also fun. It allows you to concentrate on the creative side of programming, with less stress. If you don't believe me, read this book and try Ruby. I'm sure you'll find out for yourself.

I'm very thankful to the people who have joined the Ruby community; they have helped me a lot. I almost feel like Ruby is one of my children, but in fact, it is the result of the combined efforts of many people. Without their help, Ruby could never have become what it is.

Is he the Geekory am searching for??

Inbound Revolution

There are two mistakes one can make along the road to truth...not going all the way, and not starting - Lord Buddha

Am stunned!! Really stunned!!

If you are a person who is in Software Industry and if you are a person looking for a job that respects you in the first place and if you are a person looking for a good pay for that too and if you are a person who deserve it really, then you are ought to be in Thoughtworks

Yes. Thinking that am a person as described above, I went through the interview process of ThoughtWorks. Fortunately, I was given the opportunity to reach their dynasty at least upto the 4th round in the process. [As you may have gone through in the site, the process has 8 rounds, if am right]. Unfortunately, kicked off in the logical assessment round. Eventhough I highly doubt the reliability of such kind of tests, over the coding assessment, I really enjoyed the process.

Before doing the groundwork for attending their interview, I was not very much interested in blogging, nor in developer community activities, nor in OSS, nor in designs and patterns, nor in a revolutionary software development methodology-Agile, nor in many things that are not listed here. Simply to put in the words of one of my friends (Abishake Subramanian) "I was under real bull-shit" and now Thoughtworks has revolutionized my inner-sense. I now feel that I have to pay respect to the global surname I hold "Engineer." Thanks to Thoughtworkers for revolutionizing the developer society.

I have now started to work on these fields:
1) Designs and Patterns
2) Updates in newer versions of .Net and C#
3) Downloaded a OSS source-code, BlogNet, and analyzing it
4) Downloaded Ruby, installed it and going through the know-hows
5) Restarted (!!) this blog
6) Forget my office while am not there(supposed not to reveal.. sucks)

and last but not the least, research works on Agile and planning to conduct a seminar on that in the college where I graduated.

So, just the entry point of this company has pulled me out the "real" bull-shit and truly revolutionized my thoughts. If I would get chance to get into their office as an employee, I suppose I'll be near to God of Softwares (can we name as Geekory, a random name perhaps)

And this blog will turn active from this day and discuss about all the things mentioned above. I welcome you all to respond to my posts.