Type Checking in JavaScript (techblog.badoo.com)

One could use this system for asserts though:

    assert(type.isObject({})));
    assert(type.isNumber(NaN)); // fails
    assert(type.isElement(document.createElement('div')));
    assert(type.isRegExp(/abc/);

Secondly I completely agree about wanting a program to crash noisily and detectably in development, but in production I would prefer that the error is handled and the user can continue to use the app.

Finally I also agree that if type checking is really important to you, a compile to JS language like TypeScript or Dart are the best options. The techniques / approach I am discussing in this article are really for people who already have a large vanilla JS code base or want to learn a bit more about types in JavaScript.

  interface IA { }
  interface IB { foo(): void; }
   
  function fn(passedFn: (a: IA) => void) {
    passedFn({}); 
  }
 
  // compiles but throws TypeError at runtime!
  fn((b: IB) => b.foo());

So you can do stuff like this:

  callToRemoteApi().then(processData)
    .then(makeAnotherCallToAnotherApi)
    .then(processAllTheData)

In basic ruby ,unless you mess with classes, [1,2]+1 WILL fail , though ruby is not staticaly typed. Ruby is STRONGLY typed, and that's a great thing.

Javascript will do everything it can not to fail:

    String([1,2]) => "1,2"

    + 1 => "1,21"

That's madness,because Javascript is basically making a decision for you.That was acceptable in 1995, that is not in 2013.

And that's its biggest flaw.Writing javascript means working against the language.

But there is a reason for that. Javascript is not good at throwing errors or handling them, at all.

So it's not about static vs dynamic typing.

There is no good solution for that problem unless TC39 decides to fix it. Enforcing dependency injection concepts and duck typing might work, but not always. For instance, you could check if a string is a string with

    function(x){
        x=x.substr(); // will throw a TypeError if I pass an Array. 
    }

The big one for me is inheriting other people's code bases, in dynamic languages they're a complete and utter nightmare, especially when written by incompetent programmers, which seems to make up a worryingly large number of programmers. Or someone just learning and not aware of conventions.

You just can't assume a method or function actually does what it says it does. Or returns what it says it does. And you can't even see what it's expecting or what things are being passed to it. You have to fine-toothcomb the method, it slows you down massively.

I have worked on a fair few bad code bases now and luckily for me the majority of that's been in static languages. It makes it so much easier.

Some of the other advantages of static typing include:

1. having incredibly good auto code completion

2. never having to remember or look up a method signature

3. to refactor massive chunks of code almost completely fearlessly

4. to fix crap code without any fear of breaking anything else

5. as long as you name your methods well, never having to annotate anything mundane (depending on your audience ofc)

There are also other things like that tend to go hand-in-hand because they're usually explicit, like not worrying about implicit conversion (apart from VB with option explicit off).

I've used both quite a lot over the last 10 odd years professionally programming and I've recently been thinking that I would actually prefer a mix, static typing on boundaries like method entry and new object declartion and dynamic everywhere else. I know little about compiler or language design, so I'm not sure it's even possible. C# kinda gets close with the var keyword, but the various disadvantages of static typing still rear their head quite a lot.

As a slight aside, People on HN always seem to talk as if they only write new programs, not maintain old ones. Am I the weird one for frequently having to pick up code that was written by someone else? Who often had coded themselves into a corner and then made up some excuse as to why they couldn't keep the client anymore?

He's doing this because he wants type safety in his functions. If you have that, you eliminate one source of bugs.

>I really just can't stand all the type checking all over the place, it makes the code feel like all your reading is type checking and not the real logic of what is going on in this function.

That's a big problem with his approach. It's not scalable, and you can't rely on it (inevitably, developers will take shortcuts and you're going to have a hodgepodge of type checks littering your code). He might as well use TypeScript or Dart or Google Closure Compiler.

>I would have to actually go into the code now to figure out why an empty string came back instead of processing as I thought it should.

Problem number two with his approach. He doesn't actually have compile-time checks which is where you want your type-checks to be. Instead it's all run-time (and he ignores the errors), which raises the question, what the heck is he actually gaining from all this?

Again, he should just use TypeScript or Dart or Google Closure Compiler.