Saturday, March 29, 2008

BCB6 - A try to gather people with a common interest on DSL

Hi Folks,

I have planned to discuss/present about my ideas on Domain Specific Languages at BCB6.

Please comment on this post / mail to me, if you have any idea of presenting something in BCB6 about:

1. Domain Specific Languages
2. Meta programming
3. UNIX little languages
4. Software Factories
5. XML
6. MDA (Model Driven Architecture)
7. LISP
8. COBOL
9. APIs
10. Internal DSLs in Ruby (!!)

All these topics converge towards the broad concept, DSL.

Here are some links that can help you to start with:
http://martinfowler.com/articles/languageWorkbench.html
http://martinfowler.com/bliki/DomainSpecificLanguage.html
http://en.wikipedia.org/wiki/Domain-specific_programming_language
http://web.cecs.pdx.edu/~timm/dm/dsl.html

I think more people from ThoughtWorks will be interested in this stuff. We could turn it into a small-scale collective.

I doubt that I'm i over-enthusiastic as this is my first Barcamp to attend. Please let me know, if so :)

Tuesday, March 25, 2008

Accident between Me and a Sweet Corn

Months ago, I went through an accident while riding a bike. It shattered one of my foretooth, which was then treated to have an artificial tooth (Crown, as they call). Doctors warned me that the tooth should not be used to bite anything hard and it was just for cosmetic purposes. Calculations told me that I have spent more than Rs.15,000 just for cosmetics!!

I maintained my new, so-called aesthetic, tooth well until yesterday when I tried biting a sweet corn. Heck, I heard a cracking sound and a little bit of pain. I rushed to my dentist, and after taking an x-ray, he said, that the internal support of the tooth is fractured. Well, I thought it may cost a few hundreds, but my caring dentist said that the tooth must be removed and be supported by the adjacent teeth. Ultimately, 3 teeth will be treated and crowned. The estimated bill was for around Rs.12,000 !! Accidents happen both in large and small scales. Life is mystically designed !!

Dr.Martin Luther King Jr. once said in a speech: "The ultimate measure of a man is not where he stands in moments of comfort and convenience, but where he stands at times of challenge and controversy." So true. What we are as human beings presents itself more fully in times of adversity than at times of ease. Anyone can be positive, polite and kind when things are going well. What distinguishes people with an extraordinary character from the rest of us is how they respond when life sends one of its inevitable curves. They don't crumble or surrender. They reach deeply into themselves and present even more of their highest nature to the world.

Just a couple of weeks ago, I was on the highway, ready to travel to Chennai from my home-town. The bus had been delayed by a few hours so it felt good to be close to start. I had my walkman in place, a new book to read and my magazine. Then, the driver's voice came over: "We had found a puncture in one of the tires. We regret that we must cancel this bus." The reactions that statement provoked were fascinating.

One man close to me became belligerent to the driver. A couple in another row grumbled loudly. A gentleman actually kicked the seat in front of him. Yet some passengers responded differently, with a quiet humanity. An elderly gentleman smiled as he helped others take their bags down from the overhead compartments. A teenager, rather than trying to rush off like most of the other passengers, stopped to help a woman with a disability. The lady sitting next to me laugh and said, "Hey, it's not the end of the world," before calling her kids and sharing her adventure with them. The wisest among us have a remarkable ability to maintain grounded when times get tough.

No life is perfect; mine certainly isn't. We all must face challenges, both large and small. This very minute, somewhere in the world, there are parents dealing with the death of a child. This very minute, someone has suffered an accident that will devastate their loved ones. This very minute, there are human beings dealing with illness in a hospital bed. Sickness, loss, disappointment. No one gets through life without experiencing this stuff. But you and I have the power to choose to rise above our external circumstances. We always have the choice to be strong and positive when things fall apart. We have the right to use our stumbling blocks as stepping stones to our greatest life. This isn't motivational sloganeering. I believe this is truth.

I feel really great to stay cool, positive, and kind, even after my brand-new accident with a Sweet Corn.

Wednesday, March 12, 2008

Why's Poignant Guide to Ruby

Hmm.. frustrations are born with us.. they keep us away from what we aspire or what we dream. I was too far away from practising Ruby.. but never forgot it. And for the second time, I have started looking for good materials on RoR. There are plenty of manuals, books, and documentations. One that I recently went through and very much impressed was: Why's (Poignant) Guide to Ruby

Interesting Name.. huh?? That impressed me in the first few pages but am not sure whether it's pace and quality are consistent throughout. Let me know if you find it interesting.

Tuesday, February 26, 2008

Barcamp Bangalore 6

I don't think necessity is the mother of invention. Invention, in my opinion, arises directly from idleness, possibly also from laziness - to save oneself trouble.-Agatha Christie


After a long long time, am back to this blog as most of the bloggers do. I was quite busy with a couple of exams and busy days in office.

This time, I would like to recommend you all to attend the Barcamp Bangalore 6 to be conducted by this March. The date, venue and sessions are not yet confirmed.

Starring at the new word, BarCamp? In one word, they call it an unconference. Merely, like Wikipedia, where anybody conduct a session on any technical topic. The only qualification for registration is "You must be techno-savvy."

Most of the Barcamp enthusiats are budding entrepreneurs and some of them research-savvy. Anyhow, that would be a great time for me at the least.

Follow these links to know about the event and Barcamp:

BarcampBangalore
What is BarCamp?
Last Barcamp Blog - BCB5

Just google out "Barcamp Bangalore" and try to be there at the feast.

Saturday, December 1, 2007

Ride on Rails !!

You may be disappointed if you fail, but you are doomed if you don't try. -Beverly Sills


Ha.. after a long debate with my friends and a detailed study on various programming languages, I finally ended with an intention to try Ruby On Rails (RoR). Though many have suggested TextMate as a better IDE for Ruby, I had an eye on NetBeans. The interest actually roots back to my college days where I was in the evaluation of NetBeans Beta version. I lost the touch perhaps.

Just today, just now, I have installed all the gizmos for landing on Rails!! A big list of downloads including JDK, NetBeans(Ruby), Apache, and MySQL. Hmm.. so am also absorbed into the community of nextgen devs, hopefully.

Still, my love towards .Net, C#, code-behind model etc.. has not vanished and it will not. But, the catch is I have started to try various other ways of exploring the domain of web development. More posts will be here with a blend of both the perspectives of Design and Development of Enterprise Solutions !!

Friday, November 23, 2007

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

Tuesday, November 20, 2007

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.