It's Friday – and that means one thing: Yup, Microsoft's TypeScript 2.0 is out • The Register Forums

Friday 23rd September 2016 07:33 GMT 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"?

5 9 Reply
1. Friday 23rd September 2016 08:49 GMT 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.
  
  7 0 Reply
  1. Friday 23rd September 2016 09:02 GMT 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?
    
    0 0 Reply
  2. Friday 23rd September 2016 15:32 GMT 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.
    
    0 0 Reply
2. Friday 23rd September 2016 09:11 GMT 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 0 Reply
3. Friday 23rd September 2016 09:35 GMT Destroy All Monsters
  
  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 0 Reply
  1. Friday 23rd September 2016 09:49 GMT 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.
    
    0 2 Reply
    1. Friday 23rd September 2016 10:11 GMT Destroy All Monsters
      
      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 0 Reply
      1. Friday 23rd September 2016 19:05 GMT Ken Moorhouse
        
        Destroy All Monsters
        
        +1 for the useful links.
        
        0 0 Reply
  2. Friday 23rd September 2016 09:50 GMT Destroy All Monsters
    
    Well, IEEE Xplore is bit on the fritz right now. "Something went wrong in getting results, please try again later."
    
    1 0 Reply
Friday 23rd September 2016 07:48 GMT 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...

2 0 Reply
1. Friday 23rd September 2016 09:09 GMT sabroni
  
  Strong typing at the poit of use is vital
  
  Why?
  
  0 0 Reply
  1. Friday 23rd September 2016 09:42 GMT Destroy All Monsters
    
    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.
    
    0 0 Reply
Friday 23rd September 2016 09:45 GMT 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.

1 0 Reply
Friday 23rd September 2016 17:00 GMT Ken Moorhouse

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 0 Reply
1. Friday 23rd September 2016 20:30 GMT 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...
  
  1 0 Reply