Troubles Overcome

Notes on Web Development

Static types in javascript you say?

Microsoft: I’ve got brilliant news, old boy! We’ve got static types in javascript—it’s a new day!

Developer: Why that’s fantastic, I must say. I’m curious how you managed it, since all the existing libraries, core APIs, and browser APIs are dynamic…

MS: My good man, listen closely now: the types are described in separate libraries called typings, you see. Once described, the APIs become statically typed—there and then, my boy! Hax pax max Deus adimax!

D: Wait, how?—

MS: And you can make the switch with no slogging at all—one file at a time—I swear to you, chap! Your code will be looking the last word, fitted with type annotations and all the latest ESnext todo. You’ll be thanking me with a tear in your eye before the month is out. You have my word on it.

D: It does sound very nice, sir, and I do appreciate the effort you’ll have made in exhaustively describing the APIs, especially seeing how it will be necessary to keep it all so very perfectly up to date. Lest all this statically typed code should suffer recurrent fits of dynamism.

MS: Oh my dear boy, you have got it wrong I’m afriad. You will take care to describe and update the types for us. But don’t worry too much about any of that. The time spent would serve you very well, I should think. It’ll be marvelous. Sure as can be. But first things first, my man; I wouldn’t want you to find yourself in the soup, as they say, so it would be right savvy of you to phone the missus and put her on notice you’ll be home late the next little stretch.

Static types my man! Our day is come.

Javascript Type Checking with TypeScript 2.3+

At last, TypeScript 2.3 offers the power of the compiler to those who regard massive toolchains, now so much in vogue, as a repository of technical debt to be serviced each time a project needs significant (dev-)dependency updates. We may now help ourselves to file-by-file type safety while writing vanilla javascript.

You do not need TypeScript (or Flow).

#

Update: with TypeScript 2.3, you can keep Javascript as it is, and check types using the compiler. It’s awesome.

We all recognize that as javascript applications grow larger, implicit casting and a variety of type-related gotchas begin to make things difficult. In my experience, a line is crossed somewhere north of 25KSLOC. The question is what we do about it. Facebook and Microsoft chose to build new languages. I’m not convinced it was a shrewd move.

If you’re thinking the only alternative is grotesque manual type checks, take a moment to consider what a nice type checking tool might be like. It would make type checks concise and readable, and it would protect users from gotchas.

So then, consider a tool like TYPEOF:


function example(name, age, isTall) {

  TYPEOF
    (...arguments)
    (String, Number, Boolean)
   
  // ...
}

Methods are usually better than flags.

#

One of the best things we can do to make APIs easier for client code to interact with is good naming. Notice that standard advice in favor of polymorphism has the opposite effect; alternate behavior provided by an API via polymorphism is necessarily un-named. It is hidden until we read the API’s documentation (assuming the docs are up to date, that is). Just compare these two ways of achieving the same thing:


// Polymorphic:
USD(5.4543) // $5.45
USD(5.4543, true) // $5

// Non-polymorphic:
USD(5.4543) // $5.45 (same as above)
USD.round(5.4543) // $5

AI is always less impressive than is claimed.

I’ve spent a fair bit of time thinking about general intelligence, mostly while trying to better understand how utterances come to have their meanings in context. Here’s a trivial case:

(1) There’s a beer in the fridge.

If true, we agree that there is at least one beer b, and b is in the fridge. But (1) does not strictly mean that there is only one beer in the fridge. If the speaker knows there are two beers in the fridge, would (1) be false? No, but it would be misleading. Or at best true but very oddly put.

Odd how? As best we can tell, the addressee assumes a certain relationship between the strength of the speaker’s claim and the nature, or extent, of the speaker’s knowledge of the world underpinning her statement: the speaker will prefer to make a stronger as opposed to a weaker claim if she has contextually relevant information which backs the stronger claim.

This means that if the speaker makes a weaker claim, the addressee can assume that the speaker doesn’t have useful, contextually relevant information beyond what was uttered. So, when hearing (1), the addressee figures that it represents the strongest reasonably brief statement of relevant knowledge of the beer-fridge situation. If it doesn’t, we get a strange feeling – the speaker misled the addressee.

I think that when people start worrying about how to get machine learners to master language, they figure this kind of thing will be really difficult. And I suppose it will be pretty difficult. But it’s probably not impossible. There are lower-level problems that seem well beyond the grasp of software.