Main | Beyond Java (by Bruce A Tate, O'Reilly) »

Weak versus strong languages, who wins the fight?

Static vs. Dynamic

Languages where the type of references can change are usually called dynamic (weak), languages where the type of a reference is fixed are called static (strong).

Static vs. Dynamic

Languages where the type of references can change are usually called dynamic (weak), languages where the type of a reference is fixed are called static (strong).

Typing Dimesions

There are at least two dimensions for typing, reference typing and data structure typing. In programming languages both references and data structures can be typed.

Scripting Languages

Sometimes people use the terms dynamic and static, but mean scripting and compiled. Traditionally scripting languages were interpreted languages. No compilation is needed and after changing. This way turn around times are minimized and development is speed up. Scripting languages get virtual machines and are compiled to byte code for better performance.

Functional Style

Functional style development can easier to write, understand and maintain. Especially in applications which have to deal with lots of lists functional programming makes code considerably shorter. Web applications often use lists and so profit from languages which support functional style programming.


First thing that can to mind while reading this article/post was that I have been fortunate to work with a Bertrand Meyer / Eiffel admirer and have found that incorporating in his priciples of "Design by Contract" has improved the quality of the software my team can produce. Like Test Driven Development the preconditions help me focus on understanding the software I'm developing as I create it. Like all successfull languages if a dynamic language grows and thrives and its use becomes widespread and varied. Certain circumstances and business contracts will come to bare on the software, regaurdless of langauge. The implementation will likely differ but the concept will still need to be dealt with.

Can I develop software without using "Design by Contract" concepts? "yes", can I build software with out unit tests? "yes". Will I ever, now that I know the benefits of doing so? "not likely"

"Design by Contract" Wikipedia:Design_by_contract

Programming by contract is a methodology for designing computer software. It prescribes that software designers should define precise checkable interface specifications for software components based upon the theory of abstract data types and the conceptual metaphor of a business contract.

The Problem of Invariants

Most of the issues that arrise are about object invariance, which is an object-oriented programming construct consisting of a set of invariant properties that remain uncompromised regardless of the state of the object. This ensures that the object will always meet predefined conditions, and that methods may, therefore, always reference the object without the risk of making inaccurate presumptions.

Spec #

If anything in the effort to produce better quality software and retain the reflexsive nature of a language like Java or C# the researches over at microsoft are looking at fortifying the area of the C# langauge. In Spec# which integrates into the Microsoft Visual Studio development environment for the .NET platform, the compiler statically enforces non-null types, emits run-time checks for method contracts and invariants, and records the contracts as metadata for consumption by downstream tools. I don't expect Spec# to take off as a language, but rather to have the concepts they are working on be folded into C# over time. .Net 3 might even already have some of these features.

Lists, Collections and Containers

Looking at these "dynamic" languages, I find myself thinking of them more as tools than as languages. Like the new Excel or Powerpoint. These really feel like the are at a different level of abstraction. When I look at Ruby on Rails, I see "you just have to keep the naming right" coupled with a baked in Model View Controller pattern. It makes me marvel at the power of a well implemented design pattern rather than thinking I have to toss out what I've been doing in Java or C#. In a very odd way I see Ruby on Rails, replacing the need for things like Sharepoint Services from Microsoft, which is largely just a list/collection tool all dressed up, with a CAML back end. This is the exact opposite direction of Ruby on Rails however. There is nothing lightwieght or simple about CAML, man Microsoft can truely get the right idea wrong in grand fashion on regular basis. Now I don't see your typical office worker jumping into Ruby, and whoops, there's an app! But I think a whole host of developers who have grown up on ColdFusion, Classic ASP, PHP will be really excited to see the great productivity and simple database accessability that these dynamic languages and lightwieght frameworks provide.