Safety is freedom?

; Date: Wed Dec 21 2005

Tags: Java

Berin Loritsch riffs off one of James Goslings claims: ( James Gosling Asserts that Safety is Freedom and heads into type safety in strongly typed versus loosely typed programming language.

It seems the basis for Berin's argument (loosely typed languages are safer/easier) is to take an analogy from Ben Franklin that "Any society that would give up a little liberty to gain a little security will deserve neither and lose both." While old Ben was a wise man and there's a lot of wisdom in that statement, computer programs are not people nor are they societies.

What computer programs are depends on the specific type of program you're writing in the moment. In general software is highly rigid, containing millions of lines of rigidly specified precise instructions. Writing software is like telling a baby to walk by directly firing electrical impulses down the babies nervous system. You get one thing wrong and the baby flops on the floor and starts crying.

People and societies on the other hand are made of processing units that have a huge degree of self intelligence, awareness, and autonomy. You can tell someone to "go over there", and they'll figure out all the steps. But if you tell a computer to do it, you'll look as silly as Scotty talking into the mouse on a Mac in the Star Trek movie where they saved the whales.

Okay, so, he used a bad analogy.

He's right -- there's a kind of software where you want quick scripting language type of experience. But, I say, there's also a kind of software where you want high rigidness.

Strong type safety is useful in the latter case, while in the former you want loose typing. It's really that simple.

I've programmed in dozens of languages and I value both language approaches. Hence, Java has its place with its strong typing, and other languages have their place with their loose typing.

In Mustang we're starting to offer scripting support. I haven't tried it yet, but the general concept is a good idea. That allows a kind of hybrid approach where you have a scripting language with its loose rapid style, accessing modules built in Java and presumably those modules are the ones needing a stricter style.

Source: (


Sounds like you're talking about static versus dynamic instead of strong versus weak... I already tried to educate James' comment providers, in his blog entry RADlab, scripting and scale. where i go in (slight) deeper depth in the difference between the two... other than that, i do agree :)

Posted by: wfvoogd on December 22, 2005 at 04:37 AM

It amazes me how many people get this wrong.. See ( for example. Nobody argues for "weak" typing (a la C) anymore! The argument is dynamic vs. static.

Posted by: dog on December 22, 2005 at 08:09 AM

Please understand the distinction that I am driving at. Statically bound types introduce straight jackets and provide a false sense of security. Instead of thinking about the solution, you end up thinking about the implementation. Out of all the cool new features in Java, most of them would not be necessary if types weren't harshly bound at compile time. No one is arguing for weak type safety, we are arguing for dynamic typing. I shouldn't care what kind of object someone is giving me, I just care that I can use it in a standard way. The contrived argument about a nuclear bomb trigger being passed into a method that calls "doIt()" is contrived and not representative of real world applications.

I know Java pretty darn well, but I've also been able to see where it is limiting me as opposed to protecting me. I'd like to see Java improved--but it is unlikely to happen. Too many people are afraid to let go of the 20+ year old compiler bound type checking. Instead of actually trying new things and getting practical experience, they invent artificial reasons why it won't work.

Posted by: bloritsch on December 22, 2005 at 10:59 AM

Bloritsch's blog page current generates a FileNotFoundException. Is this some kind of dynamic joke? ;-)

Posted by: mthornton on December 22, 2005 at 11:38 AM

:) Hmmm, it's running on JRoller.... Maybe the JVM got hosed.... Seriously though, they had some problems earlier, but it should be OK now.

Posted by: bloritsch on December 22, 2005 at 01:07 PM

Ok, the link used in this post needs to be updated--not sure what's going on with JRoller. Use this instead

Posted by: bloritsch on December 22, 2005 at 01:09 PM

dynamic languages can actually have just as many checks as strong typed languages it is just when that happens. both types have identifiers(some may be implied) strong makes the assumption that all object types should be known and know when and where what goes by both parties in communication prior to run-time; this is fine for inside of one program, but is illogical for complex interactions. dynamic typing can be thought of more easily as case scenarios. You determine what it is that you have by looking at it, either through explicit or implicit identification. The benefits of strong typed languages are based on these assumptions that can be made by in the program that cannot be taken for granted in dynamic languages; when phrased this way which one sounds weaker. both strong and dynamic have their places, and can't be compromised by declaring a language strong or dynamic. Strong belongs for inner/local workings whereas dynamic is for any cross anything interaction. To say that a language is strong or dynamic is inane due to the impossibility to seperate the two without making major compromises on both sides. What I'm trying to say is that both sides should give up some ground and stop fighting. Strong belongs in inner language stuff, and dynamic should deal with identification of abstract things like objects. It is counter intuitive to try and make an open source language out of strong typing mechanisms, it just doesn't fit.

Posted by: sirian98 on December 22, 2005 at 09:50 PM

About the Author(s)

David Herron : David Herron is a writer and software engineer focusing on the wise use of technology. He is especially interested in clean energy technologies like solar power, wind power, and electric cars. David worked for nearly 30 years in Silicon Valley on software ranging from electronic mail systems, to video streaming, to the Java programming language, and has published several books on Node.js programming and electric vehicles.