back to article It's Friday – and that means one thing: Yup, Microsoft's TypeScript 2.0 is out

Microsoft has released TypeScript 2.0, a major update to its typed version of JavaScript. TypeScript first appeared in October 2012, and is a project backed by Microsoft’s Anders Heljsberg – the inventor of C# and before that Borland’s Delphi. The thinking behind the open-source project, which is a superset of JavaScript, is …

  1. Anonymous Coward
    Anonymous Coward

    >>The thinking behind the open-source project, which is a superset of JavaScript, is that large, complex applications are easier to code and to maintain in a language which supports static typing, rather than the dynamic typing used by JavaScript.<<

    I hear that a lot. But whenever I work on reasonably large systems that are based on strongly typed languages I find they're fragile and brittle, often with many fail routes and only a single success path for any function. The strongly typed nature doesn't seem to make them more robust, the fact something builds (and passes tests) often means very little.

    I also notice that Javascript apps that are sensibly architected, with a promise based MVC framework at the front end and a straightforward set of restful javascript APIs providing the back end seem much more resilient to failure. They seldom crash completely, that's for sure.

    So are there any studies or metrics that back up this assertion that strongly typed languages produce better apps, or is it just "common sense"?

    1. Robert Grant

      Strong vs static

      Your wording mixes up strong and static typing. Languages fall along two axes: strongly or weakly typed, and dynamically or statically typed. Static vs dynamic is whether or not the type of a variable is known at compile time. Strong or weak is whether or not types can be used interchangeably without throwing an error but the language may do something you don't expect.

      For example, Javascript is weakly typed. I can say "1" + 1 and I get "11" - it boxes the numeric 1 into a string. This is a source of runtime errors, say if I thought the first string was actually a number as well and wanted to get the number 2 out.

      Strong typing is just another way of testing your code. It can be very, very powerful (and often is), but it's not always applicable. Dynamic vs static typing is a more complex issue, as they both have very strong cases for them.

      I like the brevity of dynamic typing and the extra enforced correctness of strong typing.

      1. Anonymous Coward
        Anonymous Coward

        Re: Strong vs static

        Thanks for that, a bit of clarity always helps. Not sure what "Extra enforced correctness" means though? If it's surplus to requirements that I don't like it, however "correct" it may be.

        I know loads of people love strong typing, I hear about it all the time from people criticising javascript. However, I was asking if there were metrics that supported the idea behind this change, that changing javascript typing would lead to better apps.

        Is there any evidence?

      2. SecretSonOfHG

        Re: Strong vs static

        Robert, it could be the time and day of the week (Friday afternoon), but why one would want to have static typing and weak typing in the same bag? Seems to me that if you take the extra work of telling your compiler about your types and then allowing to freely mash them would be a waste of the extra information that the type provides about what you can or can't do with an object.

        Of course, all languages I know that are strongly typed have the ability to cast one type to other, but this is usually a conscious decision from the user, not something done automatically.

    2. Anonymous Coward
      Anonymous Coward

      I don't understand why they should be "fragile and brittle".

      Fragility and brittleness comes from feeding objects of the type A to functions means to process objects of type B, with A and B in separate domains and the compiler/interpreter executing the nonsense with not a single complaint. Basically, you are running another program than you should. Debugging this is a nightmare.

      > often with many fail routes and only a single success path for any function.

      Unless you are basically programming in an "un(i)typed" way and then type-casting madly (i.e. doing it wrong) that's exactly what a program should be about. Additionally, the compiler will warn you when you are doing nonsense ... it's pure win.

      Did I mention that typing is basically the in-line version of enforced documentation?

      Sure, typing systems vary a lot in power and convenience (check the literalture, it's a fascinating subject, totally left unmentioned in uni course, like the dark matter of coding and strongly linked to automated theorem proving).

      Currently reading the MEAP for the Idris language, btw. In there, types are first-class citizens, so you can actually maninpulate them.

    3. Destroy All Monsters Silver badge
      Windows

      So are there any studies or metrics that back up this assertion that strongly typed languages produce better apps, or is it just "common sense"?

      There must be tons.

      A quick shufti to the IEEE Xplore Library shows this beyond the Dread Big Paywall:

      ▶ "A controlled experiment to assess the benefits of procedure argument type checking"

      Published in: IEEE Transactions on Software Engineering ( Volume: 24, Issue: 4, Apr 1998 )

      Abstract: Type checking is considered an important mechanism for detecting programming errors, especially interface errors. This report describes an experiment to assess the defect-detection capabilities of static, intermodule type checking. The experiment uses ANSI C and Kernighan & Ritchie (K&R) C. The relevant difference is that the ANSI C compiler checks module interfaces (i.e., the parameter lists calls to external functions), whereas K&R C does not. The experiment employs a counterbalanced design in which each of the 40 subjects, most of them CS PhD students, writes two nontrivial programs that interface with a complex library (Motif). Each subject writes one program in ANSI C and one in K&R C. The input to each compiler run is saved and manually analyzed for defects. Results indicate that delivered ANSI C programs contain significantly fewer interface defects than delivered K&R C programs. Furthermore, after subjects have gained some familiarity with the interface they are using, ANSI C programmers remove defects faster and are more productive (measured in both delivery time and functionality implemented).

      I will see if my search-fu is good enough to find more before the 10 minutes are up.

      1. Anonymous Coward
        Anonymous Coward

        Ok, sorry to shift the goalposts, but are there any real word studies? The fact that it works well in a lab doesn't mean a lot to me, I'm talking about systems I've worked on when I suggest strong typing doesn't seem to add much value.

        Just found this: http://macbeth.cs.ucdavis.edu/lang_study.pdf

        Doesn't look like it makes a lot of difference.

        1. Destroy All Monsters Silver badge
          Windows

          This link works: A Large Scale Study of Programming Languages and Code Quality in Github

          Nice study, though as the authors say, it's difficult to conclude much.

          OTOH, would you eschew static type checking if there is a certain risk of missing a devastating security or safety bug? In some domains, you may not care. In some domains, you may care very much. Saying that "typing doesn't seem to add much value" may be true. But it depends on the application domain. Remember the Ariane 5 failure? To me that sounds like a costly typing problem. Bertrand Meyer considered it a problem solvable by "contracts" but these are just types in disguise, really.

          Insurers are not going to give you the green light if you want to develop a safety-relevant system using a language where the compiler can't ascertain basic constraints on program correctness (today sometimes going so far as to prove that requirements are indeed being fulfilled using a theorem prover, there was an article on this at Quanta Magazine).

          So there is that.

          This brings us far away from the fun of writing JavaScript interfaces though. Anyway, I like my types as well as my runtime "asserts", they make me feel lees like doing a balancing act without a safety net.

          1. Ken Moorhouse Silver badge

            Destroy All Monsters

            +1 for the useful links.

      2. Destroy All Monsters Silver badge

        Well, IEEE Xplore is bit on the fritz right now. "Something went wrong in getting results, please try again later."

  2. kmac499

    Strong typing at the poit of use is vital, Loose typing when passing things around is sometimes very useful for making generic code. Particularly with classes. So a function could generate a data handling object of say type objCustomer or objSale or objProduct which inherit from a general type clsTable.

    This enables you to pass objTables around the system at will using the generic clsTable:methods but the precise 'table' used by that object only becomes important and visible at the point of use.

    Might not suit the computer scientists amongst us but it works for me...

    1. sabroni Silver badge

      Strong typing at the poit of use is vital

      Why?

      1. Destroy All Monsters Silver badge

        Re: Strong typing at the poit of use is vital

        This is called message-passing with type-casting at point-of-use (which may or may not fail)

        Why not.

        Actually, you could dynamically select the function able to process your object based on the type of the object, aka "polymorphism".

        But this is not what typing is entirely about.

  3. Fred M

    "The TypeScript team also had to set non-nullable types off by default because it is a change that breaks existing code"

    Indeed. I suspect the most common use of Typescript 2 will be for the recently RTM'd Angular 2... which doesn't compile with strictNullChecks on.

  4. Ken Moorhouse Silver badge

    Strongly typed

    Used correctly, strong typing can help document code and prevent accidental erroneous usage. For instance I can have a variable that holds a count of "apples", and another which counts "bananas". Both of them are integers but they are incompatible if you started adding apples and bananas together to work out how many apples you had. If you wanted to count how many items of "fruit" you had then the idea is that you create a variable of that type. Casting types from one to another is, as already mentioned in this thread, a very conscious decision on the part of the coder.

    I've come across languages where a variable is derived, not from explicit declaration, but implicit usage. Take "1" for example: am I referring to an integer, a floating point number, a string, a boolean, or a date even? Classic example is Excel which goes ahead and assumes all sorts of wrong things about data you are entering: phone numbers, invoice numbers with leading zeroes, etc. aaargh.

    I work with Delphi which engenders strong typing. Yes you can force everything as "variant" if you wanted to, but you wouldn't be getting the best out of the language if you did. I've also worked with languages such as Clipper where there are variable scoping problems too. From what I remember a variable can be used as a string one minute and an integer the next, depending on where it was called from. Delphi on the other hand has a very robust structure.

    1. Anonymous Coward
      Anonymous Coward

      Re: Strongly typed

      Beware, AFAIK they're going to make types nullable in Delphi, in a new attempt to make it more alike C# or whatever language has nullables or any other feature they believe is fashionable today.

      Anders is very missed in Delphi language evolution... which now is in the hands of apprentices with very little knowledge, and too much envy for anything greener. Oh well, today they can't design a "service pack" that doesn't require a full manual unistall/reinstall, difficult to believe they can design a language.

      PS: whoever worked with SQL and its procedural expansion for long enough. knows well how NULLable types can bite you without warning...

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Biting the hand that feeds IT © 1998–2019