Over a million developers have joined DZone.

Dynamic, Static, Optional, Structural Typing, and Engineering Challenges

DZone's Guide to

Dynamic, Static, Optional, Structural Typing, and Engineering Challenges

Dynamic vs. static typing has been much debated. It's necessary to understand why static and dynamic might both be beneficial. Here's a look at dynamic vs. static typing, optional and structural typing, and associated engineering challenges to help you further understand.

· Java Zone ·
Free Resource

Get the Edge with a Professional Java IDE. 30-day free trial.

Dynamic versus static typing is one of those confrontations that seams to attracts zealots. It really saddens me to see how people tend to defend vehemently their side simply because they are not able to understand the other position. In my opinion, if you do not get why both static and dynamic typing are great in certain situations you are an incomplete software developer. You have chosen to look at just a portion of the picture.

An engineer should be open-minded: it is ok to have your opinions but when you keep bashing ideas that made millions of developers very productive, chances are that you are missing something. Try being humble, you could end up learning something.

Ok, So What?

I had very good experiences using Java or Haskell (from the static side) or Python and Ruby (from the dynamic field). There is no way you can obtain the succinctness of Ruby code, the amazing possibilities given by its metaprogramming features with statically typed languages. On the other end, I really end up missing static typing when I have to refactor large chunks of code. Tests help (when they are there) but it is often not enough.

Now, there are approaches to try getting the best of whole worlds. One solution is to combine languages for different parts of the system: perhaps you could write the infrastructure of your platform using Java and the business logic using JRuby. Why not?

However, that means that you have still some challenges at the language boundaries. You need to master several tools and learn the best practices for the different languages and so on. Therefore, it would be interesting to get the advantages of both worlds in one single language.

A Compromise?

A very partial solution is to use static typing with type inference: it does not give you the same power you get with dynamically typed languages but you get some of the succinctness. Not a giant leap but it helps to close the gap. Types are still calculated at compile time, and that means that you could have to streamline your solution so that also the compiler can understand it. However, you would not have to type yourself all the types. Also, when refactoring, you have to change types in fewer places.

Type inference sounds like a great idea but it has its drawbacks: try writing some Haskell code, pretty soon you will start being puzzled about the type derived from the compiler for a value. In practice, I need to add some annotations to make some of the types explicit otherwise I get lost pretty soon.

Another approach to combining static and dynamic typing is to start from a dynamic language and try to make it more static-like. There are two options for that: optional typing and structural typing.

Basically optional typing means that you can add some type annotations in certain parts of your dynamic language so that a part of it can be statically checked while the rest will keep being dynamic. This can be helpful both to catch errors and to improve performances because it enables the compiler to optimize some calls. Look at Typed Clojure and PEP -0484: Type hints for python.

Structural typing means to have duck-types: your type is the list of the operations that it supports. Basically, you can look at the code of your method and look which operations perform on the parameters. Does it invoke the method foo on the parameter bar? Cool, that means that when this method is invoked I should ensure that bar has some type that has the method foo. It does not matter the name of the class, what it matters is its structure (i.e., the fields and methods it has). In principle a good idea but IMHO it can get confusing quite soon.

It is supported in Scala, where you can write this:

def test(f: { def getName(): String }) {

However it seems verbose, doesn’t it? With structural type inference perhaps we could avoid the verbose type declaration and have some safety at compilation time. At this time, I am not aware of any language that gets this exactly right. Any suggestion?

Can’t I Just Have Ruby With a Super Smart Compiler Catching My Stupid Errors?

No, so far you can’t.

People tried to do that: think about the Crystal language, which aims to be a statically typed version of Ruby or Mirah which tried to be a statically typed version of JRuby. It is tempting to think that you can have a nice language as Ruby, just add a little bit of static-typing and get the best of both worlds. The problem is that it does not just work in that way, like the authors of Crystal figured out. Eventually, that particular feature ends up having an impact on other aspects of the language and forces you to rethink it globally.

I think this is often the case in engineering project: a customer think you can just squeeze another feature in and he does not get the impact on other aspects such security or architectural integrity. We as engineers have to juggle many balls and take decisions considering all of them. Adding one other ball could force us to rethink our strategy or cause all the balls to fall on the ground.

Get the Java IDE that understands code & makes developing enjoyable. Level up your code with IntelliJ IDEA. Download the free trial.

java ,ruby ,static typed languages ,dynamic type ,haskell ,python ,scala

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}