Jared Richardson works at Logos Technologies As a recognized expert in the software industry, Jared has worked with both start-ups and software giants. He's been involved with various open source projects, with roles from contributor to founder. Jared co-authored the best selling book Ship It! and Career 2.0, and founded the Agile RTP user group as a local outlet for the agile community in North Carolina. His personal blog is Agile Artisans

Jared has posted 52 posts at DZone. You can read more from them at their website. View Full User Profile

The Rise and Fall of Dynamic Languages

02.25.2009
| 11695 views |
  • submit to reddit

In this interview, Ruby programmer and consultant Rick DeNatale provides his perspective on the fall and rise of dynamic languages, including Smalltalk and Ruby. Rick's work through the years has given him a unique and low-level perspective of what works and why.

Editor's Note - This interview was recorded prior to the RubyRX Conference that recently took place in Raleigh, N.C.

Published at DZone with permission of its author, Jared Richardson.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

phil swenson replied on Thu, 2009/02/26 - 10:24am

I love Ruby.  But when some guy says that dynamically typed languages are "safer" than statically typed languages with a bunch of mumbo jumbo to back it up, he loses all credibility.

 

I don't make spelling mistakes in Java.  I do in Ruby.  I don't call illegal methods in Java, I do in Ruby.  

The compiler does catch a lot of stuff.  It's not a substitute for testing, but it gets a lot of the obvious crap out of the way for you.

Type declarations are also a very useful form of documentation.  In ruby all you have are docs (if someone writes them), variable names (which usually dosn't cut it), inspecting the implementaiton, and trial and error.

 There are huge advantages to dynamic typing of course, but saying it's "safer" is just ludicrous.  Everything has a trade off.

murphee murpheeLast replied on Thu, 2009/02/26 - 11:17am

@ the previous commenters:

Please upgrade your set of ears and listen to what Rick actually said:  when he says dynamic typing offers more safety, he was comparing it to languages like C++ and friends. In that case, there's really no argument - a dynamic language like Ruby (or Smalltalk he's referring to as the language he used in the 90s), is definitely safer than the static typing in C++. Why? Because you might get static typing in C or C++, but it's trivial to get around _all_ typing in these languages, be it with a simple cast or with a bit of pointer arithmetic. 

With a dynamically typed language, you can't circumvent the type system at runtime - if you try calling method "foo" on an object that doesn't have one, you'll get an exception (or the method_missing or DoesNotUnderstand system kicks in). You also can't take an int and treat it as a float because every type retains type information at runtime; in C there's not difference between an int and a float, it's just 4 bytes, and C will take your word when it chooses operations on these bytes (ie. casting). In any case - type safety is retained, ie. you can only do things that the type system allows (as compared to weakly typed languages as C, or C++ that's used as C with classes). 

 

phil swenson replied on Thu, 2009/02/26 - 1:36pm in response to: murphee murpheeLast

he was also referring to "static typing" in general.

Raging Infernoz replied on Thu, 2009/03/05 - 2:57am

The type errors argument doesn't apply to Java, it has dynamic typing checking, so lumping it in with C++ seems disingenuous e.g. if you do a bad cast in Java you get a casting error. 

The inheritance argument is bogus too, because Java supports interfaces, and provides reflection proxy support.

Ruby fails for not have static typing, because lot of type mistakes are not caught before runtime, it is also less safe, because methods could be called which are the wrong methods.

Test driven development is much worse at spotting type errors, because you have to remember to test everything, static typing removes much of the need to remember to check types.

Static typing, in Java, can also make it much easier to do refactoring, and to identify polymorphic method signature bugs, it also makes it easy for IDEs to provide narrowing method drop-down lists, to pick methods from, while you are typing.

There is a standard rule of projects that the later you discover a problem, in a project, the more costly it becomes to fix, thus because Java can identify type issues immediately, by type-checking in the IDE, and complier, it can be a lot less costly than Ruby, because unit test generally occur later, and the test/edit cycle can be much slower!

 

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.