Weak, Strong, Static And DynamicAn Introduction To Programming Type Systems

Advertisement

.toc {
width: 100%;
margin: 1em 0;
border: 1px solid rgba(0,0,0,0.1); }

.toc td, .toc th {
padding: 4px 10px;
border-bottom: 1px solid #eee;
border-right: 1px solid #eee;
border-collapse: collapse;
text-align: left; }

.toc th { background-color: #ECECEC; }

Static typing is great because it keeps you out of trouble. Dynamic typing is great because it gets out of your way and lets you get your work done faster. The debate between strongly and dynamically typed languages rages on, but understanding the issue starts with weak typing and languages such as C.

C treats everything like a number. A character like a or 7 or % is the number of the ASCII symbol representing it; “true” and “false” are just 1 and 0.

C defines variables with types such as int for integer and char for character, but that just defines how much memory to use. To access the variable and print it out, I need to know the type.

int a = 1;
printf("The number is %in", a);

char z = 'z';
printf("The character is %cn", z);

When I run this program, it shows this:

The number is 1
The character is z

The printf function needs a hint from us to know how to format the variable. If I give the wrong hint…

char z = 'z';
printf("The character is %in", z);

… then I get this:

The character is 122

C doesn’t know whether z is a character or an integer; it has a weak type.

Weak typing is fast because there’s no overhead of remembering the different types, but it leads to some nasty bugs. There’s no way to format the z if you don’t know its type ahead of time. Imagine accessing a variable and getting the number 1229799107. The number could be the result of a mathematical calculation (1,229,799,107), the cost of a government program ($1.2 billion) or a date (Saturday, 20 December 2008). When all you have is the number, there’s no way to know that it’s really the code for the letters in my name: zack.

So far, we’ve just covered weak typing. “Weak versus strong” and “static versus dynamic” are often spoken of synonymously, but they each describe a different phase of the same problem. They’re also politicized, with the words carrying an implied value judgment. “Weak versus strong” makes one of them sound a lot better than the other, while “static vs. dynamic” makes one sound stodgy and the other exciting.


(Image: Cris)

These two terms are used interchangeably, but they describe the difference between the way a language defines types and how it figures them out when the program runs. For example:

Weak with no typing Assembly languages don’t provide any way of specifying or checking types at all. Everything is just a number.
Weak static typing C lets you define object types as structures, but it doesn’t do much to enforce or remember them. C automatically convert between many types. C++ and Objective-C go further with the definitions but still don’t enforce the resulting types.
Strong static typing Java forces you to define all types and checks them with a virtual machine.
Strong dynamic typing Python, JavaScript and Ruby dynamically infer the types of objects, instead of forcing you to define them, and then enforce those types when the program runs in the interpreter. All dynamically typed languages need a strong typing system at runtime or else they won’t be able to resolve the object types.
Weak dynamic typing Dynamically inferred types don’t work in a weakly typed language because there aren’t any types to infer.

No programming language fits any of these definitions 100%. Java is considered one of the most static languages, but it implemented a comprehensive reflection API that lets you change classes at runtime, thus resembling more dynamic languages. This feature allows the Java Virtual Machine to support very dynamic languages such as Groovy.

Functional programming languages such as Lisp, Erlang and Haskell blur the lines even more.

Usually when people argue about the merits of strong versus weak programming languages, they really mean the varying degrees of weak, strong, static and dynamic philosophies in every language.

Weak Static Languages: C, C++ And Objective-C

These next programming languages use a subset of C’s functionality and strict guidelines to improve the loose nature of the language. C++ and Objective-C compile into the same bytes as C, but they use the compiler to restrict the code you can write.

In C++ and Objective-C, our number (1229799107) has a meaning. I can define it as a string of characters and make sure that no one uses it as a currency or a date. The compiler enforces its proper use.

Static typing supports objects with sets of functionality that always work in a well-defined way. Now I can create a Person object and make sure the getName function always returns the string of someone’s name.

class Person {
    public:
        string getName() {
            return "zack";
        }
};

Now I can call my object like this:

Person p;
printf("The name is %sn", p.getName().c_str());

Static typing goes a long way to avoid the bugs of weakly typed languages by adding more constraints in the compiler, but it can’t check anything when the program is running because a C++ or Objective-C program is just like C code when it runs. Both languages also leave the option of mixing weakly typed C code with static typed C++ or Objective-C to bypass all of the type checking.

Java goes a step beyond that, adding type checking when the code runs in a virtual machine.

Strong Static Languages: Java

C++ offers some stricter ways of using C; Java makes sure you use them. Java needs everything to be defined so that you know at all times what type of object you have, which functions that object has and whether you’re calling them properly.

Java also stopped supporting C code and other ways of getting out of static typing.

The Person object looks almost the same in Java:

public class Person {
    public String getName() {
        return "zack";
    }
}

I get the name by creating a new object and calling the getName function, like this:

public class Main {
    public static void main (String args[]) {
        Person person = new Person();
        System.out.println("The name is " + person.getName());
    }
}

This code creates a new Person object, assigns it to a variable named person, calls the getName function and prints out the value.

If I try to assign my person variable to a different type, such as a character or integer, then the Java compiler will show an error that these types are incompatible. If I was calling a separate API that had changed since I compiled, then the Java runtime would still find the type error.

Java doesn’t allow code outside of a class. It’s a major reason why people complain that Java forces you to write too much boilerplate.

The popularity of Java and its strong adherence to strong typing made a huge impact on the programming landscape. Strong typing advocates lauded Java for fixing the cracks in C++. But many programmers found Java overly prescriptive and rigid. They wanted a fast way to write code without all of the extra definition of Java.

Strong Dynamic Languages: JavaScript, Python, Ruby And Many More

In JavaScript, I define a variable with the keyword var, instead of a type like int or char. I don’t know the type of this variable and I don’t need to until I actually want to access it.

I can define an object in JavaScript with the getName function.

var person = {
    getName: function() {
        return 'zack';
    }
};

alert('The name is ' + person.getName());

Now I have an object named person, and it has a function named getName. If I call person.getName(), it will result in zack.

I declared person as a var, and I can reassign it to anything.

var person = {
    getName: function() {
        return 'zack';
    }
};

person = 5;

alert('The name is ' + person.getName());

This code creates a variable named person and assigns it to an object with a getPerson function, but then it reassigns that variable to the number 5. When this code runs, the result is TypeError: Object 5 has no method 'getName'. JavaScript says that the object 5 doesn’t have a function named getName. In Java, this error would come up during compilation, but JavaScript makes you wait for runtime.

I can also change the type of the object based on the conditions of the program.

var person = {
    getName: function() {
        return 'zack';
    }
};

if (new Date().getMinutes() > 29) {
    person = 5;
}

alert('The name is ' + person.getName());

Now this code will work at 9:15 but will fail at 9:30. Java would call this a type error, but it’s fine in JavaScript.

The most popular form of dynamic typing is called “duck typing” because the code looks at the object during runtime to determine the type — and if it walks like a duck and quacks like a duck, then it must be a duck.

Duck typing enables you to redefine any object in the middle of the program. It can start as a duck and turn into a swan or goose.

var person = {
    getName: function() {
        return 'zack';
    }
};

person['getBirthday'] = function() {
    return 'July 18th';
};

alert('The name is ' + person.getName() + ' ' +
      'and the birthday is ' + person.getBirthday());

At any point, I can change the nature of my Person object to add the new getBirthday function or to remove existing functionality. Java won’t allow that because you can’t check object types when they’re always changing. Dynamically redefining objects gives you a lot of power, for good and bad.

C shows errors when the program runs. C++, Objective-C and Java use the compiler to catch errors at compile time. JavaScript pushes those errors back to the runtime of the application. That’s why supporters of strong typing hate JavaScript so much: it seems like a big step backward. They’re always looking for JavaScript alternatives.

Which Is Better?

I’m looking for a program to parse XML, find a particular element, make a change and save the file. On a team of Java programmers, I wrote the code in the dynamic language Python.

import sys
import string
from xml.dom.minidom import parse

dom = parse(sys.argv[1])

for node in dom.getElementsByTagName('property'):
    attr = node.attributes['name'];
    if attr.value == 'my value':
        node.childNodes[0] = dom.createTextNode('my new value');

file = open(sys.argv[1], 'w');
file.write(dom.toxml('UTF-8'));
file.close();

This program finds every property node with the name my value and sets the contents to my new value. I define the variables dom for my XML document, node for each node of XML that I find, and attr for the attribute. Python doesn’t even require the keyword var, and it doesn’t know that node has childNodes or that attr has value until I call it.

To change an XML file in Java, I would write a new class, open an input stream, call the DOM parser, traverse the tree, call the right methods on the right elements, and write the file out to an output stream. I could simplify some of those calls with a library, but I’d still have the overhead of defining my static types. All of the extra definition of objects and variables could easily take a hundred lines. Python takes 14.

Dynamic code is generally shorter than static code because it needs less description of what the code is going to do. This program would be shorter in Python than in C++ and shorter in Ruby than in Objective-C.

So, which is better?

The static programmer says: The dynamic programmer says:
“Static typing catches bugs with the compiler and keeps you out of trouble.” “Static typing only catches some bugs, and you can’t trust the compiler to do your testing.”
“Static languages are easier to read because they’re more explicit about what the code does.” “Dynamic languages are easier to read because you write less code.”
“At least I know that the code compiles.” “Just because the code compiles doesn’t mean it runs.”
“I trust the static typing to make sure my team writes good code.” “The compiler doesn’t stop you from writing bad code.”
“Debugging an unknown object is impossible.” “Debugging overly complex object hierarchies is unbearable.”
“Compiler bugs happen at midmorning in my office; runtime bugs happen at midnight for my customers.” “There’s no replacement for testing, and unit tests find more issues than the compiler ever could.”

Static typing made our Person object easier to understand. We defined a Person with a name and agreed about which fields mattered ahead of time. Establishing everything clearly makes our Person easier to debug but harder to change.

What happens when someone in our application needs a second email address? In a static language, we’d need to redefine the object so that everyone has two email addresses, even though most people don’t. Add in a birthday, favorite color and a few more items and every Person will have twice as many fields as they need.

Dynamic languages make this problem much easier. We can add a second email field to one Person without adding it to everyone. Now, each object has only the fields it needs. A static language could handle this with a generic map of values, but then you’re fighting the static environment to write dynamic code. C programmers spent years tearing their hair out over errors in type conversions, corrupt values, and the terrible bugs that come from small typos. They’ve been burnt by weak typing, and dynamic typing looks weak.

Dynamic programmers spent years banging their heads over the rigidity of static languages, and they crave the freedom to make the languages do what they want.

I’ve seen static code get overly complex and become impossible to follow. Try debugging an enterprise JavaBean or understanding all of the details of generics in Java. I’ve seen dynamic code turn into a giant mound of unmaintainable spaghetti. Look at the myriad of terrible JavaScript programs before jQuery. Node.js does some amazing things, but I can’t look at it without traumatic flashbacks of horrible JavaScript that I’ve debugged.

Conclusion

There’s no clear conclusion. Dynamically typed languages are popular now. The pendulum will swing back and forth many times in the coming years. The only solution is flexibility. Learn to work in each environment and you’ll work well with any team.

Image credits of image on front page: Alexflx54

(al) (ea)

↑ Back to top

Zack Grossbart is an engineer, designer, and author. He's a founding member of the Spiffy UI project, the architect of the WordPress Editorial Calendar, and a Consulting Engineer with NetIQ. Zack began loading DOS from a floppy disk when he was five years old. He first worked professionally with computers when he was 15 and started his first software company when he was 16. Zack lives in Cambridge, Massachusetts with his wife and daughter.

  1. 1

    Static languages give you safety at the cost of flexibility. Dynamic languages give you flexibility at the cost of safety. It has been hot debate for many years about dynamic vs static. Infact both have their own strengths and weakness.

    A perfect language would be that gives mixture of both safety and flexibility.

    Erik Meijer has written very interesting paper on it: “Static Typing Where Possible, Dynamic Typing When Needed: The End of the Cold War Between Programming Languages”. http://research.microsoft.com/en-us/um/people/emeijer/Papers/RDL04Meijer.pdf

    Gilad Bracha also introduced interesting idea of “Pluggable Type Systems” and it’s being implemented in Google Dart. http://bracha.org/pluggableTypesPosition.pdf

    I don’t think pendulum will swing back and forth again in coming years. Rather both languages will borrow from each other and we will get closer to perfection.

    1
    • 2

      Thanks for the link. This seems to be happening with languages like Kotlin (http://kotlin.jetbrains.org/) or Xtend (http://www.eclipse.org/xtend/). They’re less verbose and have features like closures, type inference, implicit returns etc. It will be interesting to see how they go.

      Another thing I feel is ofter overlooked is the usability that static typing brings to your IDE. Modern java IDEs can do some pretty amazing things with code completion, refactoring, null safety etc.

      This is something I really missed when moving from Java to Ruby. It was a bit like going back to the 90′s of the Java IDEs. Having said that, my Ruby IDE is pretty clever, it’s just not a patch on it’s Java cousin.

      0
    • 3

      @Faisal

      Excellent comments. This article is rubbish clearly written by someone with no formal computer science training.

      thanks, Willy

      0
  2. 5

    Jørn E. Angeltveit

    April 18, 2013 2:50 am

    Yup. The conclusion is clear:

    Strong static typing is better … ;-)

    0
  3. 6

    Good article, by the way I like strong typing…

    0
  4. 7

    So the difference between dynamic and static is clear. For static, you define types in code and can’t change them.
    The difference between strong and weak is a little harder to grasp: With strong typing, the compiler or runtime knows at all times what the type of the variable actually is. In weak typed C you can just cast between types however you like.

    What I kind of missed is the difference between type coercing languages. You mentioned that in C *some constructs* treat everything as a number.
    So you can write
    “`
    if (obj) …
    a = obj && obj.prop || default;
    while (obj = obj.next) …
    “`
    while in a non type coercing language you would have to write
    “`
    if (obj != null) …
    a = obj.prop != null ? obj.prop : default;
    while (obj.hasNext()) obj = obj.getNext()
    “`
    Sure, there are a lot of pitfalls with type coercion, as with everything else, but *if you know what you are doing* its really great.

    And thats the whole conclusion: The programmer still needs to know what he is doing. Compilers and type systems can try hard, but the stupidity of the average programmer would still win.

    0
  5. 9

    I have an follow up question to your article: Why did you define JavaScript as strongly-typed? For me JavaScript is one of the best examples for a loosely-typed language (see also http://www.crockford.com/javascript/inheritance.html).

    Could you please clarify that for me?

    0
    • 10

      I went back and forth on this, but in the end I concluded that JavaScript is strongly typed and dynamic. JavaScript identifies real types and maintains them at runtime. When I have an object I know what type of object it is. That makes it strongly typed. JavaScript does not enforce types and I can manipulate objects while my program is running. That makes it’s typing system dynamic.

      All of that said, most programming languages are in a gray area. Java is a language that almost everyone would describe as statically typed, but it supports reflection and you can make many changes at runtime. The real question is the dominant philosophy of the language.

      0
      • 11

        I actually never thought about the runtime of JavaScript. Did some googling and found this: http://blogs.adobe.com/webplatform/2012/08/27/javascript-types/
        I see your point know and it actually makes sense that someone would (and could) call JavaScript strongly-typed. On the other hand that behavior of trying to guess what the variable’s type is, I would call loosely-typed.

        Would love to read more about what Javascript does at runtime! Any links or book suggestions? :-)

        0
      • 12

        probably a lot will disagree with me,

        the huge problem of javascript u can not truly define an object with specific properties and methods.

        When u need to work with sub-object without redefining them continuously it’s a disaster. U need to create all kind of work arounds and at that moment u can say goodbye to less work. It’s so much more work then a true OOP language like Objective C/Objective Pascal. These language do prove that OOP is and should be the way of programming.

        I think it is terrible that it is possible to redefine half a way of the code any objects, properties or methods. It’s also bad for debugging.

        Hopefully Javascript will support complete OOP in the future.

        0
        • 13

          But wait… Smalltalk is the most pure object oriented language and you can (you must) redefine properties and methods at runtime!! (in fact classes are objects at runtime)
          Javascript support complete OOP. Javascript is not “Class Object Oriented” like other ugly Strong typed languajes. JavaScript is “Prototype Object Oriented”!!

          0
  6. 14

    I would like to correct one misunderstanding regarding JavaScript. JavaScript is “weakly typed” dynamic language – in a sense that it supports implicit type coercion like C. You can confirm from Wikipedia. I wonder how it could be “strongly typed” dynamic language?

    0
  7. 15

    It has been over a decade since I wrote a C program but I programmed almost exclusively in C for almost 15 years. If I remember correctly 0 is false and everything else is true.

    0
  8. 16

    I was looking for some easy to understand article on type system and this is the best I have ever read!
    It solved all my pending doubts. Hope to see some more articles on programming type systems. Thanks!!

    0
  9. 17

    It is good to see these perspectives laid out side-by-side. I’m glad that I can use a variety of type systems depending on what I’m comfortable with. Best of all, languages that have previously been firmly in one camp have the ability to move outside of their type system. For example, the support of dynamics in C# and TypeScript for declaring static types in JavaScript.

    0
  10. 18

    It isn’t really accurate to say that “Weak typing is fast because there’s no overhead of remembering the different types”. In strongly typed, static languages like OCaml, or Haskell, all typing information is thrown away after compilation, and the runtime makes no type checks, since that all happened at compile time!

    Along those lines, this makes Java harder to peg. The fact that the JVM is verifying types at runtime has nothing to do with Java being a strong, statically typed language, but rather the fact that the JVM itself (or rather Java byte code) is essentially strongly typed and dynamic.

    0
  11. 19

    Couldn’t get past the Jelly Beans :’)

    0
    • 20

      It’s really difficult to find an image that goes with programming typing systems.

      0
      • 21

        You did great, just unlucky that I was hungry at the time. I did manage to finish the article after having lunch ;)

        Cheers!

        0
  12. 22

    This is the worst, most misinformed, misrepresentation of comparison of computer languages I have ever seen.

    JavaScript is a weakly-typed language, just as Basic is (was).

    Weakly typed languages are not, as Matt Freels points out above, inherently any faster: in fact, generally, they are much slower. A strongly typed compiled language “theoretically” will always be orders of magnitude faster at run-time than a dynamic, or interpreted, language that must infer, or coerce types at run-time.

    The distinction between compiled and interpreted languages should have been made clear here from the beginning.

    The distinction between languages that are inherently “late-bound,” and those which are not should have been used as a critical differentiation.

    The absence of intelligent commentary on the world’s most popularly used languages, like C++, and C#, (and the now more “ancient”) Objective C, modern programming languages which are designed to support OOP, and how the implementation of inheritance allows you to sub-class objects, interfaces, etc.: is a stunning omission,

    If this were a first-years student’s exam reply (at a school like MIT, or Carnegie-Mellon), in a computer science course, in response to the question: “How would you briefly define a taxonomy of programming languages ?” … it would be lucky to receive a “D”.

    For those of you reading this: may I suggest you use Wikipedia, and Google, to examine sources on the programming categories described here with such vagueness (strong and weak typing, static and dynamic), and certainly read Faisal’s response above, and read the writings of people like Erik Meijer (Microsoft, cited by Faisal), Anders Hejlsberg (genius behind both Delphi and C#, now at Microsoft working on TypeScript).

    To grok what JavaScript is (a misnamed kind-of-half-a-language … it never had anything to do with Java, and was originally named ECMAScript … which in its original form, imho, should have been called a domain-specific (HTML) scripting interpreter), there’s no better way to understand its weaknesses than by understanding how jQuery transformed it into an (awkwardly) usable tool: to understand that, I suggest you search for, and read, articles by John Resig, the creator of jQuery.

    Willy Woo

    1
    • 23

      Eddie Sheffield

      April 23, 2013 6:57 am

      “To grok what JavaScript is (a misnamed kind-of-half-a-language … it never had anything to do with Java, and was originally named ECMAScript”

      You lose a LOT of credibility when, just after demanding the author use Wikipedia and Google, you fail to do so yourself and mess this up. JavaScript was NOT originally named ECMAScript – it’s the other way around. If *you* were to check Wikipedia, you find:

      “Developed under the name Mocha, LiveScript was the official name for the language when it first shipped in beta releases of Netscape Navigator 2.0 in September 1995, but it was renamed JavaScript[10] when it was deployed in the Netscape browser version 2.0B3.[11]”

      and later

      “In November 1996, Netscape announced that it had submitted JavaScript to Ecma International for consideration as an industry standard, and subsequent work resulted in the standardized version named ECMAScript. In June 1997 Ecma International published the first edition of the ECMA-262 specification. A year later, in June 1998 some modifications were made to adapt it to the ISO/IEC-16262 standard and the second edition was released. The third edition of ECMA-262 (published on December 1999) is the version most browsers use actually.[19]
      Nowadays, the fourth edition is under development and it would include new features like packages, namespaces, explicit definition of classes and much more.”

      Please, practice what you preach and your opinions will carry more weight.

      0
    • 24

      You are confusing the distinctions of weak vs. strong typing and dynamic vs. static typing. This is especially shameful since the article spelled out the differences for you and pointed out that they’re not the same thing!

      0
  13. 25

    Talk about misrepresentation. When I programmed, I used Delphi for the most part which as a Pascal derivative was strongly typed.

    I NEVER, EVER said the following:-

    “I trust the static typing to make sure my team writes good code.”

    I only trust regular code reviews to make sure my team writes good code.

    I also said things like “Because I use a strongly typed language, my IDE can know before runtime what the type is and can present me with intelligent suggestions and help. If I declare a variable as a particular object then invoke autocomplete (intellisense in Visual Studio) only methods that return objects compatible with that type will be suggested…

    Also, by putting the only reference to unit testing in the weakly typed side you imply that it is unique to weakly typoed languages. They started with JUnit for Java. There was a Delphi port called DUnit.

    0
    • 26

      Jørn E. Angeltveit

      April 19, 2013 7:24 am

      Yeah.

      Delphi is a great tool, and Pascal is a great language. I find it a bit strange that this language hasn’t been mentioned in the article. I think Pascal is the ultimate strong, static language.

      There are a few tools out there that compiles Object Pascal (Smart Pascal) into JavaScript. The initial codename for one of these projects was “LetsPutSomeLipstickOnThatPig dot com” ;-)

      (Disclaimer: I’m running the company behind this tool.)

      0
    • 28

      > I NEVER, EVER said the following:-
      > “I trust the static typing to make sure my team writes good code.”

      AGREED !

      No one in me team would say this either. For me the table with what static programmer says contradicted with what dynamic programmer says should be rather described as “What poor static programmer says” and “What poor dynamic programmer says”.

      Howgh.

      0
  14. 29

    You’ve helped me solve my problems about the relationships among static, dynamic, strong and weak typing systems :)

    0
  15. 30

    From the long gone past I remember using IMPLICIT LOGICAL (A-Z) to force some strict typing …. oh well :-)

    0
  16. 31

    Great article Zack, spot on.
    I’ve been developing mostly in ‘strongly typed’ OO languages such as C# and Java. And lately trying to wrap my head around functional programming (Haskell, F#) and dynamic languages (JavaScript and before that Ruby).
    I enjoy exploring different programming languages and paradigms (OO and functtional). But to be honest as a developer today being exposed to quite a variety of environments, languages, frameworks/libraries (especially in JavaScript), etc. can be ovewhelming at times.
    Thanks for putting things in perspective and I agree with your conclusion and if I may add when it comes to software development there is no silver bullet or that ‘one ring to rule them all’.
    Just like in nature hybrid and cross-pollination rule!

    0
  17. 32

    Big difference between static and dynamic typing: with dynamic, you can have a good laugh ;)

    https://www.destroyallsoftware.com/talks/wat

    It’s a good article, thanks.
    I would say that using one or another depends on your environment. To be successful as a programmer, be ready to use whatever the team you’ll join is using.
    I tend to prefer static typing, mostly because I’ve worked a lot in multi-languages and multi-team environment, with sometimes developers who weren’t as good as you can expect. When they deliver to you a static library, even if there are bugs, at least you know that a function return the type it should be returning. With dynamic/loose typing you can have really strange things… and you find yourself forced to write more code, because you start manually type-checking to find the bad bugs that are biting you :/ Less boilerplate, more defensive code ^^’
    Plus, I see a lot of benefits in certain static code analysis tools and productivity helpers that can’t be as effective when using dynamic languages (of course, that doesn’t prevent from doing proper unit tests, but unit tests can’t catch everything. Each tool has it’s proper area, and they complement each other).
    But I also like and use some dynamic languages. It fully depends on what I’m doing, and who I work with.

    0
  18. 33

    You can’t really have this discussion without bringing up contract based languages (like Eiffel) which represent an even stronger level of static typing. Modern compilers for contract based languages also come with theorem provers to ensure that the contracts cannot be broken at runtime.

    0
    • 34

      Contracts are not a form of static typing, they are checked at runtime. They are a representation of dependent types without the associated proofs.

      0
  19. 35

    This article has a naive view of type systems and spreads alot of misinformation. I suggest that all of what “The static programmer says” in the table at the end is either incorrect or misses the point. I suggest you read Types and Programming Langauges (http://www.amazon.com/Types-Programming-Languages-Benjamin-Pierce/dp/0262162091) or Practical Foundations for Programming Languages (
    http://www.cs.cmu.edu/~rwh/plbook/book.pdf) for a more informed view of type systems.

    Be careful to separate type inference and composability from the type system. Many static languages do not compose very well and their limited type inference can make them quite verbose. This is not related to having a static type system. For example read, Computer Code as a Medium for Human Communication: Are Programming Languages Improving? (http://infoscience.epfl.ch/record/138586/files/dubochet2009coco.pdf).

    I’d also like to point out something I first learned from Robert Harper, that dynamic languages are a subset of static languages (http://existentialtype.wordpress.com/2011/03/19/dynamic-languages-are-static-languages/). It is easy to embed a dynamic type into a statically typed language (http://www.cis.upenn.edu/~bcpierce/papers/dynamic.ps) if you need dynamic typing. Scala and Haskell both have this.

    There are uses for dynamic types, you may need them when the types are not known at compile time, e.g. input or output of data.

    0
    • 36

      Sure these articles/links are good. But I still thank Zack for starting this off. What remains now is someone to compile ALL these information with cearly stated objectives in order for the world to get it. It is a big job – probably a thesis will.

      0
  20. 37

    That was a nice article.

    Sometime I wish I had Java with ducks. I guess that they won’t make Java duck in a near future.

    However, “strong-ducks” are better I think.

    0
  21. 38

    Since when is C/C++ weak typed language???
    C/C++ is anything but.
    Don’t mislead people by confusing static casting with weak type.

    0
    • 39

      C/C++ has properties that are opposed to strong typing:
      - runtime errors
      - lack of type safety
      - ways to workaround the type system
      - explicit and implicit type conversion

      0
  22. 40

    I think Eric Lippert’s article on C# type system provides a sophisticated opinion:
    blogs.msdn.com/b/ericlippert/archive/2012/10/15/is-c-a-strongly-typed-or-a-weakly-typed-language.aspx

    0
  23. 41

    Chris Calloway

    May 3, 2013 2:06 pm

    “Dynamically inferred types don’t work in a weakly typed language because there aren’t any types to infer.”

    Thanks for explaining why Visual Basic doesn’t work.

    0
  24. 42

    Best language should allow types and be good for fast prototyping: strongly typed with optional type annotations (Typed Clojure, Google Dart for ex.).
    Types for ex. in Haskell are plain boilerplate. You must write unit tests for a not trivial code anyway. So if you need tests what is the point of using types?

    0
  25. 43

    “Static typing is great because it keeps you out of trouble.”

    Yup. Thanks to C/C++ static types software never crashes. Thanks to static types in Java you never see .NullPointerException or other less popular errors.

    All this static typing is FUD and I have never seen or cannot remember when last time Python app crashed, or PHP one, Smalltalk, Ruby…
    Do you know why? Because thanks to REPL (real ones, not crippled like in Scala or Haskell) and compilation on page refresh, code is tested enough before putting it to file and hitting ‘Save&Compile’ button. In case of using C++ different compiler on different system can make your code crash on execution (not immediately, but days/months later).

    Another thing. Static typings won’t help you in refactoring except some trivial cases, in most cases you will have to rewrite your library from bottom to the top. If you dont have IDE to help you, you’re screwed. You will compile-edit-save-compile yourself to death.

    I dont like academic talks like that. In my practice static typing slows down development, clipples unit tests and makes refactoring a living hell. Someone said that static typing is a placebo for weak minded people with immature tools. Cannot agree more.

    0
  26. 44

    You completely missed the point of duck typing:

    —–
    The most popular form of dynamic typing is called “duck typing” because the code looks at the object during runtime to determine the type — and if it walks like a duck and quacks like a duck, then it must be a duck.

    Duck typing enables you to redefine any object in the middle of the program. It can start as a duck and turn into a swan or goose.
    —–

    Wrong! What you’re describing is dynamic typing, not duck typing. From wikipedia http://en.wikipedia.org/wiki/Type_system#Dynamic_typing: “In dynamic typing values have types, but variables do not; that is, a variable can refer to a value of any type.”

    Duck typing is specific to object-oriented programming. It’s also a programming style rather than an inherent feature of a language. In static typed languages, a function foo(Duck d) accepts arguments that have a type inherited from a particular class / interface / trait. If you pass it something that has the same methods of Duck but is not descended from Duck, then your program will yield an error (if the language was designed well, this will be at compile-time or parse-time rather than run time). In dynamic typed languages, duck typing comes from two things: (1) the fact that methods are looked up by name, not by type hierarchy, (2) your program calls methods or checks for the existence of methods, and does not use “instanceof” to check for inheritance. If I have a Car object, but it has a walk() and quack() method that are compatible with the same methods of a Duck object, it looks the same to consumers of Ducks which only care that an object can be *used* like a Duck, and not that an object has any inherent membership to a Duck class hierarchy.

    0
  27. 45

    I recommend fully OOP languages above a language like javascript.
    The paste years I have developed a lot of components in a true OOP environment.
    With this experience I am 100% sure that a none-OOP language is a lot more work even when you need to type less.

    Typewriting is chaotic, duck-typing u should not want as a programmer. Objects in Javascript completely make no sense. keywords like ‘new’ or Object.create(TBaseObject) are totally wrong implemented, they do not create new inherited objects. They just refer to the previous one.

    When I want to create a huge library of typed objects like menu’s, listbox, tab sheets, page controllers ect. ect. Javascript is in my opinion a nightmare.

    0
  28. 46

    Hello.
    This good information. Among the issues that remain to be tackled is: which is better between compilation errors and run-time errors? That is, as a programmer which should I consider “better” ?
    And which leads to more advantages to the user of an applications – less errors on developed systems – is it when you take compilations more serious than run-time?

    Nice time

    0
  29. 47

    Erlang not only blur the lines as a functional language, but also has out-of-the-compilation strong and _static_ type checking facility called dialyzer, which brings new flexibilty to the concept of type systems.

    With dialyzer, you can perform static checks as detailed as you really need. With some thought, you can maintain safety before run-time, but avoid java-style microtyping garbage.

    0
  30. 48

    First,congratulations,this is the best article about this subjective.
    SInce I started in 1985 I have worked with Cobol,Clipper,Delphi .
    although static typying is of course a time saving it really does not prevent bad programming .I have seem much more bugs in Delphi a strong static typing language than I have seen in CLipper,just because the Delphi programmers used to trust too much in the compiler,things like memory leaks,memory overrading and so on.
    If you follow best practcies and test your software static type checking is just a time saver not a Show stopper at all.
    Of course Dynamic type checking will allways be a little bit less fast(not use the word slow) sice there is much more things to be done at runtime,but at least to the software I use to create(ERP and CRM) and to the speed of new hardware this is not a real concern(at least for me).
    I have not been programming in the last six year since I am now a CEO ,but I am planning to study a new language because In Brazil we die before we retire.I am planning to give Pithon a try.
    In traditional DElphi win32 applications I didnt felt any problems about static type checking,but When I programmed in Intraweb a KInd of DElhpi for the Web(to fix a system that retrieved data for a COBOL mainframe) I really wished Delphi was a Dynamic typing language.JUst my 1,25 cents(due to the Brazilian exchange).

    0
  31. 49

    Guys,no need to fight anymore.GOogle Dart has both of them.

    0
  32. 50

    First of all great article, it definitely helped me understand typing a lot better. One thing I’m still unsure about is weak statically typed languages. I believe that the main point the article makes about weak static languages is that they have strict typing at compile time, but no way to check types at run time. If this is the case, and Objective-C is a weak static language, then the isKindOfClass: method would seem to contradict this, as it allows run time type checking. Could someone please help clarify this for me? Thanks!

    0

Leave a Comment

Yay! You've decided to leave a comment. That's fantastic! Please keep in mind that comments are moderated and rel="nofollow" is in use. So, please do not use a spammy keyword or a domain as your name, or else it will be deleted. Let's have a personal and meaningful conversation instead. Thanks for dropping by!

↑ Back to top