After we carried a few quick articles on why you should learn more about Ruby and Ruby on Rails (take 1, take 2) last month, we decided that we wanted to give people a much deeper article on why these new languages (Ruby, Python, PHP) and frameworks (Rails, Django) are setting the web world on fire. We invited Dhananjay Nene to write an article with an in depth discussion of the technical reasons how these new languages differ from the older ones and when to choose one over the other. He responded with this article which, as an added bonus, also includes the business reasons for your decisions. At the request of the community, Dhananjay is also giving a talk on the relative strengths and weaknesses of different programming languages on Saturday, 28th March, 4pm, at SICSR. All those who found this article interesting should definitely attend.
Introduction
Programing language selection is often a topic that elicits a lot of excitement, debate and often a bit of acrimony as well. There is no universally superior programming language that one can recommend, so I tend to generally disregard most language opinions which say ‘X language is the best’, without specifying the context under which it is superior. Finally most language debates often deal with the technical issues and not the ROI issues. Hopefully I shall be able to address this topic without being guilty of any of these problems.
So what languages are we referring to here ?
- Image via Wikipedia
The range of languages that fall under Dynamic Programming Languages category is rather extensive. My experience is primarily limited to Python and to a lesser extent PHP, Ruby, Javascript, and Groovy. For the rest of this article, I shall be primarily referring to Python or Ruby when I use the word dynamic languages, though many of the references may continue to be applicable and relevant for a number of other dynamic programming languages.
As I describe the technical characteristics, I shall also continue to attempt to address the business aspects as well, so you might find this article at a little techno-business level. Assuming I am able to excite their interest, the tech guys would not find sufficient technical details and would be hungry to hunt for more, and while the business guys would get a little teased with the possibilities, they will not quite get the ROI served in the traditionally formatted excel spreadsheets. Being aware of that, I continue down this path with a feeling that this perhaps will be the most appropriate level for me to abstract this article to.
Characteristics of Dynamic Programming Languages.
Let us quickly review some of the characteristics :
- Image via Wikipedia
Object Oriented : Many dynamic languages support full object orientation. There are many who don’t necessarily buy the benefits of Object Orientation, but it is my strong belief, that once a piece of software grows beyond a certain threshold of complexity and / or size, Object Orientation starts delivering very strong dividends. There are a few areas such as highly complex, algorithmic processing which might be better suited for functional programming. However a majority of the medium-to-large sized web applications are better served by OO. The empirical evidence at least bears out the fact that most of the most popular languages today (except C) are Object Oriented. However this still is a very very large class of languages which in them include C++, Java, PHP, Python, Ruby etc. The one area where some dynamic languages separate themselves from the others is in the notion of “everything is an object”, ie. primitives such as numbers, functions are all objects by themselves.
Business implications: OO code well designed and implemented allows for a substantial reduction in maintenance costs. When working with a team which is up the curve on OO, it is likely to lead to lower costs and time on inital coding as well. On the other hand, both training costs and skill requirements are higher for fully OO languages. If you are already using partialy OO / hybrid languages such as PHP, C++ or Java, and are convinced about OO, using fully OO languages such as Python or Ruby will help you leverage the OO capabilities even further.
Duck Typing : In very loose terms, duck typed languages do not require you to declare an explicit interface. You send an object a message (ie. invoke a function or access an attribute) and if it can respond to it, it will, and if it can’t it will result in an error. Duck typing is a specific typing system which is a subset of a broader system called Dynamic Typing, which often makes for an interesting debate with its counterpart – Static typing : Static and Dynamic Type checking in practice. For people well grounded in static typing alone, this can sometimes seem to be sacrilegious. I am convinced that duck typing makes writing code much much faster for two reasons – a) You now require to write fewer lines of code and b) You often don’t have to keep on regularly waiting for the compiler to do its work. There is also a substantial capability enhancement that dynamic typing makes to the language type system, which allow the frameworks to build dynamic types on the fly. This in turn offers the framework users many more capabilities than frameworks written in other languages. That is why it is nearly impossible to write frameworks like Rails or Django in Java (You can modify the class loaders and use byte code generation to generate the new types, but the compiler can’t see them so you cant use them). That is also why there is a lot of anticipation of using JRuby, Jython and Grails on the JVM since the languages underlying them (Ruby, Python and Groovy respectively) bring the dynamic typing capabilities to the JVM platform.
Business Implications :Writing code is much much faster. Maintenance depending upon the situation can sometimes be more or less difficult in case of dynamic typed languages. Refactoring is usually a lot more difficult in case of dynamically typed languages since the underlying type system is not able to infer sufficiently about the code to help the refactoring tools, as is possible in case of statically typed languages. It is my opinion that a skilled and trained development team using dynamic languages can generally substantially outperform another equally capable team using static languages. Insufficiently or poorly skilled development teams however can lead to very very different kind of pitfalls in these class of languages. In both cases the code becomes difficult to change or maintain due to a) cryptic code in case of dynamically typed languages and b) extremely large code bases in case of statically typed languages. Both are undesirable situations to be in but if I had to choose between one of the two, I would go for being in the cryptic mess since it is at least manageable by bringing in external skilled help.
Metaprogramming : Metaprogramming is in loose terms the ability of programs to write programs. A large proportion of developers may not use this capability too frequently. Specifically in web application development it gets used as a mechanism to transform one set of datastructures which a programmer specifies into code at runtime. As I point out later in this article, it in fact is a very important element in designing common frameworks and libraries which in turn offer substantial capabilities including small code and easier maintenance. A quick note to state that metaprogramming is not code generation. In case of code generation, one uses the generator to generate code which is then compiled. A big limitation with this is the fact that often people modify the generated code leading to really tough maintenance nightmares and the fact that it is a two stage process which is prone to more errors. Metaprogramming results in new code “coming to life” so to speak while your program is running.
Business Implications : Read on, they will get covered in the final roundup. They are large and they are positive.
Function blocks/objects, iterators, closures, continuations, generators: I will not go into any substantial details of this issue except to say that small pieces of code logic can be handled in a much much more concise way than if these weren’t supported. While many situations may not need closures support, you will be glad to have them on your side when needed.
Business Implications : Helps having shorter, cleaner code leading to lesser development and maintenance costs. Another significant positive is that your developers are just likely to be so much happier since they get some truly nice building blocks for concise and elegant expression of their logic. Can’t think of any significant negatives.
There are a full range of other capabilities, but none come to mind immediately as something that have strong business implications as well.
The role of frameworks
- Image via Wikipedia
When did these languages say Ruby and Python originate ? Most people are likely to be a little surprised if the answer is in the last millenium. Yet Guido von Rossum started working on Python in 1986 and Ruby was released in 1992. Python has been rather well known within the scientific community and perhaps a bit within the systems / OS utility programming communities for quite some time. However both languages grabbed a large mindshare only post 2005. A big reason for their popularity (especially in case of Ruby’s case) came from the popularity the frameworks which used them. Ruby on Rails for ruby and Django (to the best of my knowledge) for python. These frameworks combined the language capabilities with the learnings of good design practices for internet applications (eg MVC, declarative validations, simple ORM etc) into a simple usable package, which developers could take and build web applications quickly. There are examples of people having built simple web apps within a day and medium complexity apps in 1-3 weeks using these frameworks. The languages are the ingredients, the frameworks are the cooks – a great combination for serving great meals. Now you will find many such frameworks in these languages, including some which have better capabilities for building more sophisticated / complex applications eg. Merb and Pylons.
I am not too sure of how many people are exactly aware of the role of metaprogramming in the frameworks’ successes. I am willing to believe that but for metaprogramming, these frameworks simply would not have achieved anywhere close to the success they achieved. It is metaprogramming which takes the datastructures as defined by a developer and converts it into runtime code implicitly, saving the developer lots of time and effort. So even if most developers don’t actively write metaprograms, their lives are so much easier. Metaprogramming capabilities are also the reason why it is virtually impossible to write similar frameworks in Java. However if you are on the .NET or JVM environments, things are definitely looking encouraging with the possibilities to use IronPython or IronRuby on .NET or JRuby or Jython or Groovy+Grails on the JVM.
Business implications : If you are focused on scientific or desktop or highly algorithmic applications, where python especially is used extensively, you are likely to get benefits from these languages on their own merit alone. For web applications you will see the maximum benefits by using the web MVC frameworks along with the languages. I submit that on the whole you are likely to see very substantial reduction in development, enhancement and maintenance times – sweet music for any end user, investor or project manager.
Increased Business Agility
There is one more reason why I believe these languages are especially helpful. They help by increasing development agility to an extent where it now allows for the business to be more agile. You can get a first prototype version up in weeks, take it around to potential users, and gather feedback on the same. Incorporate elements of this feedback into the next release of working code quickly. The business benefits of such a scenario are tremendous. You might wonder that this is a process issue, so what does it have to do with a language selection. I would submit, that languages which allow changes to be made faster, help support this process in a far superior way. Another equally important facet is the superior risk management. Since you are able to build features with lower investments, you are able to get a series of customer feedbacks into your decision making process much faster. This helps being able to come up with a product that really meets the customer expectations much earlier. This happens by allowing the better features to come in earlier and also by allowing the lesser important or lesser relevant features to be decided to be deferred earlier. That’s precisely the reason why the dynamic languages have found a strong acceptance in the startup world. I believe the increasing agility which is often required in the startup world, is and will continue to be increasingly required of established enterprises. Precisely the reason why I believe these languages will continue to do better in the enterprise space as well. Finally, these languages make it relatively easier to tell your business sponsor – We will work with you on imprecise requirements rather than spending months on nailing down requirements which anyways are likely to change later. This has both a pro and a con especially for outsourcing situations. It is likely to allow for tremendous customer delight in terms of a vendor that works with him in such a flexible manner, yet it does introduce challenges in terms of how the commercials and management of the project are handled.
The reason I would like to especially point out increased business agility is because programmers don’t often visualise or evangelise it much, but when I wear a manager’s hat, it is perhaps the most compelling benefit of these languages.
Concluding
As I said earlier, there is no single universal language which is the best for all scenarios. There are some scenarios where using dynamic languages will not be helpful
When not to use these languages
- You are building a simple / small application and don’t have the available skill sets. One exception to this is where you decide to use it in a simple application to allow yourself a non risky mechanism of building these skillsets.
- Extremely High performance requirements. However please make sure that you really need the high performance capabilities of say a C, C++ or Java. In my experience 80% of developers like to believe that they are building highly performant applications where the maximum speed is a must have. Yet the top 10% of them are facing far far more critical performance requirements than the remainder. Unless you are convinced you are in the top 10%, you should certainly consider dynamic languages as an option. Moreover in case of most high performance requirements, these can sometimes be boiled down to a few inner loops / algorithms. Consider implementing the same in C, / Java or other .NET languages (depending upon the choice of your dynamic language interpreter implementation)
- You have an architecture standard in place which does not allow using these languages. If you are convinced your applications are better served by using dynamic languages both from your individual application and an overall enterprise perspective, consider taking the feedback to your standards setting body to see if you can pilot a different approach. Also evaluate if the .NET or JVM versions can help you comply with the architecture guidelines.
- You are unable to commit to the retraining requirements. While these languages are easy and powerful to use, leveraging that power can require some amount of retraining. If that does not fit your business plans, since the retraining effort could impact immediate and urgent requirements, that could be a reason to not use these languages. However in such situations do consider investing in building this skill sets before you get to another similar decision point.
- You need a very high levels of multithreadinging as opposed to multi processing support. While this is not a typical situation for web applications, you should be aware that most dynamic languages have some limitations in terms of multi threading support. This actually is not necessarily an issue with the language as with the implementation eg. the C implementation of python has the notorious Global Interpreter Lock which constrains you from being able to use more than a handful of threads per processes efficiently. However the same restriction is not present in Jython (the jvm implementation of python). This is likely to be an issue for a miniscule percentage of the web applications market for the primary reason that multi process / shared nothing architecture styles often work quite well for many web applications and they don’t really need multi threading.
So where’s my return on investment ?
First of all lets talk of the investment part. If you get into it in a paced approach, the investment may not be that great. Start with a team size of anywhere between 2-6 people (depending upon your organisation and project size). Think of 15 days of intensive training followed by a 2-6 months coming up the curve effort (more likely 2 than 6). Make sure your first project is not a critical one under tremendous business pressure. This can be subsequently followed by more people getting retrained as necessary. In the longer term it might actually help reduce your incremental investment, since it might be much easier to ramp up new programmers in Ruby or Python than say Java or C#.
Secondly lets look at the incrementally higher costs. You are likely to need people who are a little bit more capable in terms of understanding and debugging the same logic expressed in fewer lines of code (that sometimes can be a challenge) and then be able to modify and enhance the same. This may increase your testing and fixing costs in the earlier days. Finally while the fewer lines of code can make refactoring easier, you could find that your total refactoring costs are a little higher.
Now the returns part. I am convinced that the increased business agility is the strongest return in business terms. Immediately after that is the substantial reduction in development, enhancement and maintenance times. If neither of these benefits are appealing, when contrasted with some other issues that you might perceive, maybe considering dynamic languages in your context is not such a great idea.
One more factor that I would of course encourage you to evaluate from a business perspective are the implications for you if your competition (assuming it is not already using them) started using these languages. The implications would vary from case to case, but it could also help you decide how important this issue is for you.
About the author – Dhananjay Nene
Dhananjay is a Software Engineer with around 17 years of experience in the field. He is passionate about software engineering, programming, design and architecture. He did his post graduation from Indian Institute of Management, Ahmedabad, and has been involved in Senior Management positions and has managed team sizes in excess of 120 persons. His tech blog, and twitter stream are a must read for anybody interested in programming languages or development methodologies. Those interested in the person behind the tech can check out his general blog, and personal twitter stream. For more details, check out Dhananjay’s PuneTech wiki profile.
Related articles by Zemanta
- Really Deep Dynamics (mykakotopia.blogspot.com)
- Functional Programming in .NET – Adding Extensibility (codebetter.com)
- Coding in Objective-C 2.0, Mastering Rails Forms (pragprog.com)
- Why PHP won (startuplessonslearned.blogspot.com)
- Python and Django Links Jan 6, 2009 (dorai.wordpress.com)
- Why you need to learn Ruby and Rails (punetech.com)
- If Programming Languages Were Religions and What is Up with Ruby on Rails? (gabriellacoleman.org)
![Reblog this post [with Zemanta]](http://img.zemanta.com/reblog_b.png?x-id=b7ed0643-f578-4076-8dd2-03de3e329a10)
You may also want to check out the TIOBE index which tracks several programming languages (popularity) every month.
http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html
@Dorai
One of the reasons why I was so immediately keen to take up the offer to write this article was that popularity does not often easily reveal the underlying growth trends so easily. Even the TIOBE index in the section called “March Newsflash – Brought to you by Paul Jansen” down below show Ruby and Python having the fastest relative growth over last 5 years. A similar message comes out of these two graphs showing job growth http://www.indeed.com/jobtrends?q=python%2C+ruby%2C+java%2C+php%2C+c%23&l=&relative=1 and books growth http://radar.oreilly.com/languages_all_5yrs.png as well. All three trends show the dynamic programming languages doing rather well in growth terms though still being far away from being market leaders (a position Java was in say in 97-98).
What this article actually attempts to bring out is that there is competitive advantage to be had by exploring the usage of these languages (in many but not all contexts), while increasing the fun quotient of programming as well.
The programming language you choose should most importantly be a function of the context that you operate in. All that the growth and popularity indicators and this article can help you in is to continuously reevaluate these decisions to ensure that such decisions stay continuously appropriate and that one retains competetive advantage and doesn’t suffer from competitive disadvantage – much like reevaluating your investment portfolio every year with the performance of the various funds that are a part of it and outside it.
Very nice article. I started learning Groovy sometime back. It feels far less verbose than Java. Not having too much code stare at you from the editor makes it easier to read (and I am thinking to maintain) software.
Regarding Python, I had read somewhere that I18N support in Python is not as good as it is in Java. Is that true?
Parag,
Python has separate classes unicode and string, only the former handling unicode. So a string needs to be explicitly specified as a unicode string eg. as u’Parag Shah’ instead of ‘Parag Shah’ (the difference being the leading u). I have found similar facilities in Python as those in Java.
You might find the following useful readings :
http://wiki.laptop.org/go/Python_i18n
http://www.amk.ca/python/howto/unicode
http://docs.djangoproject.com/en/dev/topics/i18n
I was not sure whether responding to this post so late makes sense, but I nonetheless thought I would argue from the ‘other angle’ than having it go unsaid. I appreciate Dhananjay’s effort for making the article as unbiased as he could; and also feel sorry for missing out on his presentation.
While having less code and metaprogramming are great, we should also keep an eye on whether we are missing out on something important.
We all know that any amount of testing is never foolproof. So if a language gives us a better chance of catching a good %age of errors automatically, there is wisdom in using that language, even if it’s not so sexy.
With release 1.5, Java went a step further in its strong typing system to embrace Generics. The idea of Generics is that you are no more content by declaring an object type to be a List, but you now want to mention additionally that all its elements would be of a given type instead of some other. (C++ folks would remember templates here.)
Do generics make code more verbose? Yes.
Do they make your application more robust? Yes again!
The lines are clearly drawn then. Java is meant to be a business language, meant to solve serious business problems. It was never cool or sexy. (I wish Java did something about this aspect quickly.)
One fact of life is that static typing goes a long way in making your programs highly maintainable. This is because when you look at a method, you instantly know what are the types of the arguments that are coming in and what you can do with them. That makes the understanding better and also avoids incorrect edits by compile time checking.
Secondly, although the code ‘weighs’ more, some of it can be auto-generated (like the getters-setters). Also, powerful editors can do a much better job of suggestiions or auto-completion based on the types of arguments, which improves productivity and avoids stupid spelling mistakes. As a result, the speed of development is not necessarily slow. (Developer productivity is more associated with the framework one uses than the language.) Also, the code is now easier to understand and hence easier to maintain (contrary to the simple-minded expectation of less code to look at should be easier to maintain.)
The static type info of method arguments is so useful that if the language I use did not allow it, I would mention the type of each argument in method comments. A better alternative is to use a language (like Java, C#, C++) which supports strong type system and take advantage of the compile-time error catching. As an added bonus, your application will also be fast. 🙂
Finally, as Dhananjay said, there is no ‘one size fits all’. I prefer the dynamic languages for smaller programs, or for giving some dynamic scripting ability on top of existing apps. But I prefer to bet on the proven solid workhorses for life-size apps.
/Ashish
Ashish,
One of the things I’ve attempted to do through this article is to not make statements which sound “universally true”. There’s a reason for that. We are a function of our experiences since our experiences are the universe for us. So what at times may seem to be universally true statements are actually so only contextually so, and any reasonable discussion requires a explanation of the context we operate in. While I do challenge many of your assertions in terms of universality, I do so with the full knowledge that its a much easier job since to challenge the universality of a statement requires only one or more experiences which contradict the assertion.
Having said that I am not coming at it from another angle – the primary angle I come from is the ROI angle. Horses for courses. If one doesn’t know the course and the horses, one can’t pick a horse.
I wonder if the argument is narrowly made. The wisdom is in applying a variety of criteria not just compile time error checking alone in static vs. dynamic typing. Not looking at the matter in a composite way is a reminder of the elephant and seven blind men fable. I believe that except for a clearly defined context, it is completely unwise to get into a debate about which is superior. The argument you make has been made hundreds of times and has been contested hundreds of times (and vice-versa) in tens (if not hundreds) of pages over the net. I don’t recall any one of them reaching any degree of closure. What I can most certainly assert is that in my opinion there are contexts where one is appropriate and there are contexts where another is. Any discussion on ROI for a software project / product will require taking into cognisance that particular project / product contexts and its ROI influencers.
They reduce not increase verbosity. You no longer have to do a type check after extracting an object out of a list. Secondly they eliminate the necessity of writing otherwise duplicate code for ensuring type safety.
Only in certain contexts. I would argue that in certain contexts, some of the metaprogramming and functional programming constructs are able to boil down a very complex logic into a fairly small code. Also the defect density per line of code doesn’t vary as sharply across languages as does function points per line of code. So smaller code leads to lesser errors. So what would you choose ? A large code base with all static errors resolved by the compiler but a larger number of other defects per function point or a smaller code base with fewer defects per function point ? Is this comparison of mine even valid ? The context decides. I assert that application robustness is too comprehensive and nuanced a topic to be closed so quickly.
I have emphatically stated in other writings that often refactoring is tougher in dynamic languages than static ones. Many have challenged me on that. Assuming I am right on that count, I still believe refactorability is only one aspect of maintainability, and to that extent reduces the maintainability of dynamic typed applications. However there are other reasons why dynamic languages are much easier to maintain. If one goes by the assumption that the static typing makes code more maintainable as you state and also believe the other equally credible statement that dynamic typing makes code more maintainable, the interesting question is why do we have unmaintainable code ? Clearly theres far more to maintainability than static or dynamic typing. Also it needs to be understood both typing systems move maintainability in different directions as measured by different criteria of measuring maintainability – neither of them make the language more maintainabile on all criteria.
Java was designed to be a cable set top box language. It was extraordinarily cool and sexy at one time (latter half of nineties). I remember clearly since I was one of the relatively early adopters and enthusiastic proponents of the same. Java is certainly used quite extensively in business. What is a business language meant to solve a serious business problem ? I could attempt to answer that if I could understand the question.
In 1997 I took a pro Java call as an architect in face of exactly the same argument (Java was on the other side of the fence during 1996-2002). End of the day it was based on a composite assessment of a variety of factors influencing the ROI. Its a call I look back at with lots of pleasure and no regret. I would always bet on whatever delivers me the best ROI under the context and circumstances.
Dhananjay
An interesting addition in the context of the earlier comment is some of my thoughts on Java (the comments on the post and those on reddit may make interesting reading for a few) http://www.reddit.com/goto?id=7is4z
Dhananjay,
Thank you for your replies. As both of us agree, the context of an application would always play a role in determining the right technology.
My only point is that the safety net provided by the static typing is a good thing to have, although it increases the code and forces one to leave out some cool things. This point usually does not come about clearly when we keep talking about all those cool things. (That was the ‘other angle’).
The link you gave is interesting, where you talk about the business benefits of Java which I had left out. Thank you for pointing those out.
Here are the individual points:
(a) No, my argument about testing is not narrowly made. It helps to have as much safety net as possible, in defense of innumerable possible breaking points of one’s code. This can be said without getting into any long debate.
(b) Generics of course make the code more verbose where they are declared. Sure they save the trouble of typecasting the object when it’s taken out of the collection, but that’s relatively minor. Again, the point is that the important thing here is the added type-safety, which is good even at the cost of more typing while declaring.
(c) I agree there is more to code maintainability than just static typing. However, given a choice where the types of method arguments are clearly mentioned (and hence the operations that can be performed on them), versus another where they are not, what would one choose? The former would be clearly easier to understand and to prevent errors as your program starts growing bigger.
From time and again, this is exactly something that we have seen happen. Programs start small, and then start growing one feature at a time. Initially, a discipline like static typing sounds burdonsome; but if we do not do that then the programs start becoming unmaintainable. So much so that the ROI starts sinking below acceptable limits.
Again, languages with static typing are not necessarily going to solve all problems in the world; but they are clearly better off than the others in dealing with this aging process. Combined with the promise of backward compatibility like you mentioned in the other article, the advantage jumps even higher, and that’s what serious businesses look for: stability and maintainability over time, a long life of their programs and thus a high ROI in the long run.
On the final point, we anyways agree… we choose the tool/ language that gives the best ROI, and the choices keep changing from application to application and from time to time.
/Ashish
Para 1. Points a/b/c : Interestingly, the points you make here, I’ve already responded to in my earlier comment. Either I made some weak arguments or you couldn’t understand my perspective.
The argument of backward compatibility actually went to the fact that Sun like Microsoft had constraints that they have to work with. If Sun maintained say PHP and Java was open sourced, theres a likelihood my entire argument could’ve been pro PHP than pro Java. These statements were not in the context of why Java will thrive – they were in the context of why Java will not die. And finally arguments simply were orthogonal to static vs. dynamic typing.
I can realise carefully worded statements made to twist an author’s intent. And I don’t like it – especially when I am the author.
Okaaaay, now we have dynamic typing being offered as the sacrificial lamb at the altar of maintainability and what I assume you to be referring to as code decay. I should really look back and revisit my experiences since I had perhaps mistakenly come to a belief that a number of other factors which ended resulting in code decay. One of them I thought was my observation that longer code typically decayed faster. And if I look really hard every static typing project which did result in a code decay should be treated as an aberration since its dynamic typing which results in code decay. And maybe I should look at Struts and Django code bases – probably django should be becoming unmaintainable much faster because it is dynamically typed. If the statement above had not been so tragic, in my opinion it would have bordered on the irresponsible.
Lets just agree to disagree. Its usually a smell when arguments get rehashed, words get twisted out of context, and some rather unsubstantiated opinions turn facets of debate into sacrificial lambs. Thats fair in a public relations campaign. This is a technology argument and I will not disrespect the spirit of such an argument.
All the best,
Dhananjay
Dear Dhananjay,
Pardon me if I have hurt your sentiments in any way, because that was never the intention. I started off with an appreciation of your work, and I would like you to know that the appreciation remains throughout this exchange and beyond.
I agree that let’s stop this discussion here. We have started to repeat ourselves, and I would not like a technology debate to turn into a heated discussion. It’s common to have technologists differ in their opinions, yet maintain a mutual respect for each other’s viewpoints.
End note: I did learn a couple of useful points through your article and also our discussion. I thank you for the same.
All the best,
/Ashish