Joshua Marinacci's Blog

Strong vs Weak Typing: Can't we have the best of both worlds?

I've seen lots of arguments on the merits of weak typing. It encourages flexiblity. It lets me write code faster. I don't worry about the details until later. I can do cool runtime tricks.

I don't buy it. I use a strongly typed language because the code it produces is more robust. Typing solves a slew of common programming errors all at once. It ensures that my code will always do exactly what I mean, no more and no less.

And yet... I can see the advantages of weak typing too. Java is a better prototyping language than C++ but it's no where near the speed of Perl for whipping up something quick.

Why do we have strong typing anyway? I can only think of two things. First is performance. If you better specify what you want then the compiler can make faster code. The second is for people. The computer doesn't really care if this string really contains a number. It's all just bits in the end. The typing is for you, the programmer. To help you avoid mistakes. To express what you want the code to do to another programmer. It could be someone using your API, or someone modifying your code, or even yourself hacking on your own code in the future. Typing is a more detailed expression of what you want. But creating that expression can be time consuming and constraining.

But what if we could have the best of both worlds. A language that was both strongly and weakly typed, but at different times. What if I could declare at the top of each module (class, file, or package level?) how much syntatic sugar should be applied.

At it's loosest level you would have:

• no required variable declaration
• foreach, other loop constructs
• dynamic casting
• no required exception handling
• inline regex
• any indentation you want.

At stronger levels (less sugar) you have to declare everything:

• must declare all variables, and at the right location
• only standard looping constructs
• explicit casting
• required exception declaration
• all other syntatic sugar turned off
• Maybe bad indentation and no javadocs would be a compile error too.

Imagine if the forthcoming generics allowed anything to be stuffed in and out of a List in the weak mode and required you to declare the type of List in a stronger mode. Bingo! The ease of Perl with the robustness of Java.

I think such a system would help with three scenarios:

For managing long lived code. We have a pattern of sugar going down as the module stability goes up. Newer code is in flux and tested constantly so it's okay to have the compiler make assumptions. As the code is used more, and more components are dependent on it, we clamp down and explicitly define everything.

It's good for dealing with developers at different skill levels. Developers who's expertise lies in other areas (say graphic designers) do the prototype using sugar mode, not having to worry about the ins and outs of casting and exceptions. Then the real developers refactor it to be more solid if the prototype ends up being used.

You get the benefits of strong typing when you open up old 'hardened' code. Then if you break something you know right away because the compiler is very unforgiving.

The language would scale from prototype stage, through development, and on to deployment and maintenance. As the risk of breakage increases so does the strength of the typing to hold it all together.

Comments

• Static vs. Dynamic Typing
  For static typing that's done right, try MLs and Haskell.

  The combination of Jython plus java gets the best of both worlds, and it's smooth enough to be practical and useful.

  Perl? Why bother?

  Posted by: bzhou on August 15, 2003 at 08:35 PM

• Perl can do that.
  Perl will let you do that, it is all things to all people. You get out of it what you want.

  P.S. Perl is faster than Java in many ways when dynamic typing is used (and not used). So the only reason to discuss this is preference. So doesn't that make the whole discussion moot? :)

  Posted by: jflowers on August 15, 2003 at 08:59 PM

• Wither Unit Tests?
  " Typing solves a slew of common programming errors all at once. It ensures that my code will always do exactly what I mean, no more and no less."

  Really? If you're not doing unit tests then you're just kidding yourself.

  If you *are* doing unit tests then you needn't rely on static typing.

  Compile-time type checks are just a form of low-level unit tests, except you have to use them even when they aren't helping you.

  Posted by: jamesbritt on August 16, 2003 at 02:42 PM

• Only difference
  As far as I see it, the typing is not the problem.

  The real reason it seems easier to use a scripting language like perl is because you don't have to compile it - you can just bang out some code and hit 'run'.

  Compiling may not seem like much but it's a huge mental stumbling block. Taking 2 steps instead of 1 to do something is always going to be annoying.

  As an analogy consider multifunction printers that can photocopy versus having a printer and a scanner. With the first you can just turn it on and hit photocopy. With the latter you have to turn on your computer, scan the page in and then print. When you've experienced the former, you'll never go back to using the latter - it's just too much of a pain. It's like going from broadband back to a modem - painful.

  Consider for a minute how it would change things if you could just run .java files.

  Ie, there's still a compilation step but it happens automatically - you still get told if there are errors - just like you get told of errors in your perl.

  Would you be more inclined to just whip things up and do more of your coding in java?

  Posted by: nevster on August 17, 2003 at 07:28 PM

• Only difference
  I would not be. There is a larger difference between Perl and Java.

  I have a co-worker that is learning Perl, he prefers Java or C++. He says Perl makes his head hurt. He complains about the very reasons I like Perl. Two of which are, Perl will let you dynamicly handle non-existant method calls in effect dynamicly creating methods, gives you easy access to the symbol table to quickly manipulate name spaces.

  The point I am trying to make is that Perl is not restrictive in more ways than it's typing. I prefer to have enough rope to hang myself, this allows me to be more productive. When I have had to write in other languages I am constantly pissy because so many of the concepts I depend on in Perl are missing from other languages.

  The compiler step is not a real barier for me and I would bet it is not for most people.

  Posted by: jflowers on August 18, 2003 at 04:15 AM

• Re: Only difference
  Perhaps I should expand the scope of my suggestion to be more than just typing. What I really want is the ability to turn on and off all forms (or at least most) of explicit instruction to the compiler. If I could do it differently in different modules then I can ensure that older more used code is held to stricter requirements than new, in-development code. I really like Perl while developing, but I hate to maintain it. It just seems to fragile for long lived code. That's why I want a language that shifts as the code moves through the development process.

  Posted by: joshy on August 18, 2003 at 10:32 AM

• Static vs. Dynamic Typing
  I chose Perl because it was the dynamic language that Java programmers are most likely to be familiar with. I'm sure there are languages with better typing than Java and Perl. But I want to see a single language with different levels of typing. Perhaps even beyond just typing issues. Perhaps we should call them 'faces' or 'roles'. The language could move from a prototyping, to development, to deployment, to maintenance role.

  BTW, thanks for reading!

  Posted by: joshy on August 18, 2003 at 10:35 AM

• Re: Only difference
  That would be nice no matter what language. I be that could easily be implamented as a pragma in Perl much like strict.

  Posted by: jflowers on August 18, 2003 at 03:48 PM

• Dynamic not weak!!
  Hate to nitpick but...

  Weak typing is almost never good.
  You incorrectly refer to dynamic typing as weak typing. There is nothing weak about dynamic typing. Languajes such as Lisp and Smalltalk are very strongly typed (stronger than C or C++ for example) and yet have no compile time type checking.

  But your point is good. I think that static typing is often overrated and produces ackward code.

  That being said, I'm a great fan of Java's checked exceptions (maybe the only fan?). Because it allows me to easily enforce an error handling policy.

  Posted by: dog on August 22, 2003 at 11:09 AM

• Dynamic not weak!!
  Perhaps I'm not using the right terminology. What I want is a phrase that means 'How much I have to tell the compiler exactly what I mean". Sometimes I want to tell it very little because I'm working quicking to build a prototype, sometimes I want to be very explicit because this is important code that must work well in production.

  I love exceptions too. But sometimes I wish I could turn it off and then go back later and turn it on when I'm ready to do clean up.

  Posted by: joshy on August 26, 2003 at 04:44 AM

• wrong terminology
  I don't know who started referring to dynamic typing as "weak typing", but it's a fairly recent phenomenon and it's wrong.

  * weak typing: the language does not detect type errors reliably; examples: C, Perl, Tcl
  * strong typing: type errors are detected reliably (whether at runtime or at compile time); examples: Java, Python, Scheme, many others
  * static typing: type errors are detected at compile time; examples: C, Java, ML
  * dynamic typing: type errors are detected at runtime; examples: Smalltalk, Python, Scheme, Java (limited functionality)
  

  Posted by: 984243 on August 26, 2003 at 11:43 PM

• Languages that do this now
  Here are some languages that do this kind of thing now:

  Groovy is a dynamically typed language for the JVM, but you can also specify the types of variables when you want.

  Common Lisp is usually written without typing its variables, but types can be declared when needed for performance reasons. All compilers have to parse the typing declarations, but actually supporting them is optional (I believe). With good compilers, such as CMUCL or SBCL under Linux, a typed and optimized Common Lisp program can be as fast as a an equivalent C application.

  Object CAML is a statically typed language, but has type inference so no variables need to have their types declared; the compiler determines the type of each variable automatically.
  

  Posted by: ralphc on May 13, 2004 at 07:56 AM

This work is licensed under a Creative Commons License.