Home
  Latest posts
  My Writings
  My Code
  My Gallery
  About me
 
  rssfeed Syndication
 
Bloggtoppen.se
 
 
Links
  Cornerstone
  SweNug
 
Post categories
  misc (48)
  Architecture (21)
  C# (19)
  Asp.Net (2)
  Vb.Net (2)
  Training (7)
  Data (19)
  Events (40)
  Platform (2)
  Orcas (4)
  Updates (3)
  Methods (10)
  Tools (6)
  Announcements (14)
  Languages (1)
  Patterns (6)
  Opinions (11)
  Fun (3)
  Ineta (1)
  Opinion (0)
  Practices (2)
  WCF (5)
 
 
 
Languages (1)
Languages and the next big thing Wednesday, January 17, 2007
It has been a long day in Arosa, I'm feeling really beaten and while part of it is because of the thin air most of it is probably because my head is filled to the limit. I've been writing down notes for the last hour or so which all hopefully will be blog posts some time in the future.

 

One thing that has been touched upon repeatedly during the day is dynamic languages.

 

It?s no secret that most of the guys here have some kind of love relationship with ruby or want to have one. The topic was brought up twice today and it was really interesting to hear the pro?s and con?s. The main take was that dynamic languages like ruby don?t suffer from the same kind of deterministic restrictions that most static type languages do.

 

It seems to me that this discussion is surfacing every time a new dynamic language / platform gain popularity.  It floats around a bit, many talk about the problems with the static typed languages which the dynamic doesn?t have. But so far, we?ve always ended up back in ?static type? ? land. With some more experience and more tools in our toolbox. As it turned out, the dynamic language or platform was not the ?be all ? end all? type of paradigm, but just another tool to add to the toolbox. It?s my firm believe that this follow the same 4-step pattern as the most other technology; it gains hype and you love it, you get insight, you hate it, you use it more maturely and is now part of your everyday work, and ruby will probably walk down that path as well.

 

While there is places where dynamic languages excel in solving problems, just like LISP or Fortran excel in solving problems they are designed for, static type languages will still be necessary for our systems to be more manageable and easily understood. The apparent API documentation you get from defining types before compile time, is much easier for a new developer on the team to see and handle and they will make less mistakes, then using a dynamic language where types are created for you at runtime from some arbitrary meta model parsed or created while executing the code. On the other hand relying on a meta model and querying of that model creates some opportunities to have less restrictions when creating your applications or services.

 

So, is the dynamic grass really greener or will you have to cut it and care for it exactly as much as for your current static grass? I don?t know. What?s obvious though is that developers want some more flexibility and more dynamic capabilities in the tools they use today. Maybe the way to do that is to create a fully implemented and supported dynamic language for .NET (which is the obvious one since it?s designed to facilitate many different languages). Using that approach; we can resort to that language as needed and let it implement domains where dynamic languages really are the best way to solve a given problem.

 

Instead of being deterministic in what kind of meta model (or even syntax grammar) to use, we should have a runtime and platform where you can apply the best solution (language) to each and every problem at hand.

 

That said, I'm looking forward to getting that love relation with ruby I mentioned earlier in this post ;)

Leave a comment Comments (1)