Perfect Python, Groovier Groovy, Remarkable Ruby and Sexier Smalltalk…

February 10, 2010

The foursome of the dynamic programming languages/platforms deserve a deep and thorough review and possibly cross polinate ideas, features and even the spurt, growth and the enthusiastic community, as has already happened from the latter to the others but not so much the other direction.

Ruby and Groovy are a pick of the lot from the community build-up standpoint. There is so much happening on both of these worlds that it is surprising that the Smalltalk world can pick a lot from but is really not taking off. The mother platform of all that is the basis of the computing paradigm is still insular in very many ways. Pharo and Gnu Smalltalk though seem the step in the right direction but can there be any means of avoiding this confusion of profusion of options that are all fractured in their attempt to give one credible base for the entire smalltalk community to push their efforts into and consolidate the feature sets in.

Let us first take a step up and review the foursome in some detail one by one…with as much of the references to existing material in the internet world to avoid repetition of content:

* Look at the distinguishing language features that makes it cooler/ different and in that manner better…

* Frameworks that make common and/or complicated tasks easier

* Interfaces to the outside world viz: the SOA/Web Services capability, Native interface ( C/C++), COM, Active-X, RMI, IIOP, Java/.Net bridge anything else that helps it play easily with the existing major platforms in the enterprise world

* The start to enterprise grade use curve and capability including: IDE tooling and capabilities for complete Smalltalk or Eclipse like features.

* The short-medium and long term costs and upgrades ( even of paid ) for the capability increments, ROI to the extent subjectively or objectively projectable

* Support community and corporate backing

* Enterprise grade support for Agile and SDLC practices of: Unit Testing, Documentation, Build and deploy tools/strategies etc..

The challenge is to look and review this objectively without bias and bring in as much of the factual information and links to substantiate the information. I will endeavour to leave judgements/conclusions to the reader and only draw the line at highlighting the cause of dynamic languages-platform in general.

Eventually attempt to provide the readers with a comprehensive Ubuntu iso package that has all these foursome completely bundled with their required dependencies and tooling that can be simply accessed from get-go on the machine run either as live USB or as installed if intrigued enough. Enough bundled demo’s to make it appealing right from the start in matter of 4 hours.. or half a working day..

More on this will follow…


Dynamic Languages in the Enterprise Application Development World

February 8, 2010

The rise of Python, Ruby and now Groovy with their counterparts in the .Net , JVM world of IronPython, IronRuby and JPython, Jruby is a slow yet steady revolution in the programming paradigm for the computing world.

Since the early days of Smalltalk, which probably was about 3 decades ahead of its time, a slew of languages have adopted the tenets of a programming platform that is based on:

  • Object Oriented Programming and specifically single inheritance structure
  • Memory Management through garbage control
  • The Virtual Memory under the control of the programming platform
  • Bytecode based compilation that targets the specific OS platform through an Object Engine
  • A Mature Collection Class Hierarchy
  • Frameworks and Patterns as in MVC, Design Patterns in general
  • Basic Metaprogramming

This adaptation to the evolving world of programming, includes the most prevalent platforms of Java and .Net. The old but newly visible languages of Python , Ruby and now Groovy are propogating additional features integrated of:

  • Dynamic Typing
  • Closures
  • More deeper metaprogramming
  • No inherent limits or constraints in programming constructs as in interfaces, finalized base classes

And many other syntactical or conceptual adaptations from the past. They have also effected a enhanced integration of regular expresssion, string manipulation and functions/ features that are invoked on plain strings.

To regress and quickly define Dynamic Typing: The unspecified datatype of variables at compile time that is discovered at runtime and assigned as a pointer to the specific data in memory. This implies that inherently there is no allocation of memory space for the variable at compile time or runtime, it is just a pointer. At runtime it is assigned as the pointer to the address of the returned object/ data instance, potentially allowing to change its type through as many assignment statements that may occur in its lifetime/scope. Thereby within a method the same variable can be of totally different datatype and the method can also end up returning any type without restrictions binding its return type. Commonly referred to as “duck typing” or “loosely typed” it is certainly apt to call it dynamic typed.

Closures, from the lambda’s of the Lisp days are a very powerful construct, not so successfully modelled as inner classes in Java but now widely adopted in the dynamic languages is akin to the anonymous functions or the delegates in the .Net world but a lot more capable. The simplest application of closures in the iterations of collections for plain for-each, select, collect, inject, reject capabilities are to be experienced first hand than just read about as a definition. Refer Groovy iterations:

Metaprogramming, through introspection as from a java.lang.reflect to deeper more powerful method interception, delegates or expando’s , have enabled a raft of capability that is probably the underlying strength in the hands of the experienced and weakness when used by inexperienced hands. From Groovy’s , Ruby’s and Smalltalk’s metaprogramming capability are an ascending order of capability that is to be experienced to be deeply imbued. go to the Advanced Smalltalk section.

To the purpose of the article, growth and eventual widespread use of dynamic typed languages, in what can be considered as the mass or popular realm of the programming world. Google in its adoption of python in the early days and ruby on rails adoption by the hordes of small to medium size business as well as Sun, IBM, MSer’s and at ThoughtWorks in its various avatars have baselined the significant impact they have in the business agility and ability to surmount some of the barriers the conventional paradigm offers.

This article is not a diatribe or argument over an oft heard pro’s and cons of typing ( [6] and [7] below) but to emphasize the changing nature of technology development, evolving population of programmers and their ability that will probably see the veritable need of a gradual shift from the imposed restrictions of the current world.

In the decade past it was perhaps the norm to have a 100+ member team to build the next generation product or application that is now fast shrinking to orders of 10 or just a little more for just the core development and unit testing task. This in turn demands higher efficiency from each of the team members in turning around more function points per day than before, higher agility and need to turnaround intial product and its maintenance projects in quicker time.

The dynamic typing by itself is an argument that only the developer himself (or the dev team)  can feel and argue one way or the other effectively for his perception of its efficiency [7]. But it has led the current revolution through the space of frameworks for the web application development world that makes its case presentation near indisputable. Ruby on Rails, Django in Python, Grails from Groovy and ofcourse Springs integration of dynamic languages in its fold and last not the least potent of the rising stars in Seaside from Smalltalk shall be defining the need for enterprise architects and CTO’s to take a deep look through the potential benefits they shall have in adopting these languages, one or more, in the roadmap of their respective enterprises. Comprehensive integration through Web Services/ SOA and other native connections, also helps the cause for multiple systems to co-exist, properly implemented with least pain.

Another major force that should evolve is the changing world of project management with Agility as the key word within even the major long term projects. Break up projects into smaller containable phases and have them driven with all the technical tenets of Extreme Programming. The Unit test driven development paradigm demands higher rigor from the team but at the same begets the reasons to drop the verbose syntax of typed world for the easier , flexible and inherently powerful dynamic world.

It is perhaps not too late for nearly all technology companies to wake up to the call for the change to consider multiple paradigms to exist within the arsenal they deploy for product developments. There is no need to be totalitarian and drive the entire development through the proverbial “ square peg does not fit a round hole” syndrome. It is essential for the enterprise architecture teams, the technology heads ( The CTOs or the tech teams) to infuse the spirit of inclusion of well tested dynamic languages into their development toolset. The toolchain required will need to be rigorously researched and fitment assessed before acceptance, is perhaps essential to mitigate the risks of cowboy programming of the yore.

The newer breed of frameworks of RubyOnRails, Grails from Groovy, Seaside from Smalltalk and the raft of others do inspire a sense of confidence of the stable place in the enterprise toolset for the dynamic programming platforms. Couple this with the rise of base platform and IDE support for Ruby/ JRuby, Groovy , Python and now Pharo Smalltalk/ GnuSmalltalk with a more than minimal required support for an enterprise team support systems, the transition or adoption curve can be easier ( perhaps not easy even now for free smalltalk for more reasons, but seems like now on a path to change that too in very near future)

The question whether it is Smalltalk, Python, Ruby , Newspeak, Groovy or any other can be left to the totality of requirement demands, the available talent pool and the future maintainability. But to move dynamic should not be anymore left to lowest denominator of available capability of developers.

What I would recommend for the uninitiated is to dip through the following links and make up their mind on the way forward.

[1] Groovy: and

[2] Ruby: , and

[3] Python: and

If you are not averse to the break from anything of the past in files, syntax and totally new paradigm that has influenced the world of programming even till now:

[4] Smalltalk: and

Other Links:


Quiet dated but very nice discussion list and especially note from Jim S. in the middle:


Oliver Steele: Chief Architect Lazlo ( then.. )



For the academically inclined a lot of theoretical discussions and references:

[9] On the Revival of Dynamic Languages.pdf