Sunday, March 29, 2009

Java's bedevilled take on Strings

"A world without String is Chaos"
(remember this from Mouse Hunt?)

My turn: "A language with befuddling support for String is annoying" :)

Java is not a pure object-oriented language, mostly the impurity comes from the primitive type support. Although primitive types provide fast access and readability, however mixing them with their OOP counterparts is always frustrating. Same goes with C#.

The most annoying bit is the support for String. String is not a primitive type in Java nor was it supported in C++, you would have to create your own char array or use the STL's std::string. Yet there is special support in the language to give it the primitive feel. You can write:

String str = "String object";
String str2 = "this is not a String object but converted to one by the language" + str;
String str3 = "most annoying of all, you could use String's methods on this".toUpperCase();

As the last statement demonstrates, you could even call methods upon this non-standard object while you cannot do the same with other primitive types. Same thing could have been done with an integer literal (int) by providing Integer's methods upon it.

These dual standards are evil and confusing creating doubts about the authenticity of the language.
I'm loving Scala these days, it's stance on these dissimilarities created by Java and C# by providing us the all new and improved data types in the scala package.
Uptill now I have only but one grudge with Scala and that is the Scala's Strings refer to the one in java.lang.String package rather than providing us an improved version of it in the scala package.
Martin Odersky, please do something about it!

Saturday, March 28, 2009

story online: castle and the juice

Check out my brother's post story online: castle and the juice
Marvelous piece of work. I don't know why he was hiding it from me.

Wednesday, March 25, 2009

First hand experience with FP

Three years ago, yes i think it's been 3-4 years since dipping my fingers in the world of Functional Programming. Although XSLT is not a functional language but it strives to follow the FP guidelines and it is the weapon that I hold responsible for my First (FP) Blood.

I started using XSLT in .net, producing result sets in XML and writing XSLs for the visually appealing transformations. First it was simple if-else, for-each, using XQuery etc. but as soon as I stumbled upon variable assignment, I thought I caught a bug in XSLT, "I cannot reassign a variable, what's the use of the VARYiable then?"

Then I tried writing a for loop from a to b, I was troubled again. Soon I realized there was something different going on here and I would have to learn it properly before calling XSLT my preferred transformation language. At that time I read about functional language, which uptil then I thought was another name for procedural language. Satisfied, I went ahead with XSLT using recursion, template calling etc. techniques that were already taught to me but as an alternative to normal programming construct and not as a measure to make out of reassignment restrictions.

After that I forgot about FP and went on with life, rejoicing references, reassignments, reflection and then I heard about closures (around a year and a half ago) and people talking about forcing it somehow in the beautiful, simple, verbose Java language. At that time, I could not get a hang of it and went on with life. Then came the Scala buzz, I was always a great advocate of static typing and Scala being termed as the 'statically typed dynamic language' attracted me. After some days of learning I came to know about the FP fundamentals, side-effects, currying, closures etc. aside from being refreshing, these concepts enabled me to realize the modularization of functional behavior, an essential requirement in a good design that no OOP design pattern has been able to solve in a concise manner.

Sunday, March 8, 2009


Web 2.0 complemented with Social networking has been responsible for a plethora of web applications of unique nature in the near past. Various frameworks, technologies and protocols have emerged to support this trend. Even the server technologies are emerging to support the movement (e.g. by solving the scalability issue with cloud computing).

Some applications are so dense in terms of user base and features that they didn't care about collaborating with others. On the other hand, the small ones (web applications) emerge with some unique idea needing the larger apps to support them and share their user base. However recently the larger apps are becoming less self-centered in providing this connectivity (loose coupling :)).

Open standards like OAuth, OpenID etc. have paved way in this direction by enabling inter-operation among web applications an established technology rather than an idea pursued differently by different apps. Still the implementations vary depending on the nature of apps.

All of this comes down to USER POWER, where the user is given precedence over the applications. User's profile, image, credibility is carried over from application to application spanning a network of user-app with a two-way directed graph. Combine this user-app set with your browser and you are ready to get a smooth experience resulting in YOU seamlessly using applications throughout the world connected via internet, be it services, social networks, email, forums, blogs, business apps or your own creation.

My proposal is for the already-too-powerful browsers to become more powerful and play a central role in this connectivity business. Like tabbed browsing was an automatic step in aiding this experience by sharing/saving the session throughout the tabs (I'm not sure about Chrome's processes though). If the browsers are responsible for implementing the open standards then all the web apps need to do is suppor the standard. What browsers have been doing for CSS, HTML, AJAX, Javascript, SVG etc. they can do the same for this central connectivity concept, after all they have been termed as the modern OS.

Sunday, March 1, 2009

Design patterns via AOP

Object oriented programming has given this industry numerous gifts and is continuing to prosper. It has been responsible for new methodologies, languages, frameworks etc. As for AOP (Aspect-Oriented Programming) which is a different programming paradigm, never seen as a competitor/substitute to OOP but rather a complement to enhance SOC (Separation of Concerns) experience.

Design patterns have benefited most from OOP and are continuing to grow as new paradigms arise and programming methodologies are born. Advent of AOP has also worked in this direction, even a few patterns can be implemented by directly using AOP constructs and implementation/design of others can vary greatly from their OOP counterparts. And of course there are new ones which lie in this category only.

I did not get a chance to work much in this direction but have come across some good articles which inspired me to appreciate the beauty of a new paradigm/methodology. One of them is a good article by Nicholas Lesiecki.
Dynamic languages come with their own designs and I once went through a very elegant decorator implemented via Ruby. Similarly Functional languages that complement OOP will surely enhance the pattern experience. There is too much ground to cover in this regard, too many directions too go and the catch here is elegance through novelty (atleast for me).