It's good to see languages like these showing up. Would love to code something complicated before I have a detailed opinion. With my experience in Typescript (another typed language claiming to make code better with some heavy React, Angular 4 projects); more than occasionally you have to escape into JS world (the dreaded <any> cast); thing that could have been done simpler with modern ES6 syntax needs some heavy lifting and rope jumping.
Since it's all JS under the hood, the type system is an illusion that language plays tricks on you. This makes it hard for people to understand how JS works or functions; without prior knowledge. Just to quote example one of my team mate had an interface in Typescript, and he was not able to understand why cant he do `x instanceof Foo`. Long story short is you can't have good "Typescript" programmer without being good JS developer. Which I believe will be the case here too. Yes it makes auto-complete better and documents really well; but improves code is debatable.
Don't get me wrong; I am not against it. All I am mentioning is the flip side that nobody will mention. OCaml is really powerful and cool kids are going to experience it with this effort, may be bring in new features/inspiration for next ES. But IMHO just a transpiled language can give you better constructs to express code; but it can't prevent a dumb programmer from making errors. I will for sure give this a shot and blog about it.
Hmm, I'd argue that since any language is effectively compiled to zeroes and ones under the hood, by that logic no type system can protect you. A good type system is there to guide you, and verify that your code is going to be ok even once types are erased.
Transpiled/compiled/whatever you want to call it, the type system can prevent dumb and smart programmers from making a whole class of errors. In my experience OCaml has prevented so many errors I would have made in JavaScript, including but not limited to:
- Non-exhaustive select/case statements - missing one of the possibilities causes undefined behaviour. It might not even be a case of carelessness or forgetting - just that a new option gets added by someone unfamiliar with the codebase and doesn't realize they need to update a bunch of select statements.
- Changing the name of a field on an object across the codebase, and forgetting to update every single instance. OCaml won't even compile until you've fixed them all.
- Null and undefined weirdness. Just search any large JS github repo for "null"/"undefined" and see how many issues are related. With OCaml, you'll almost never see them because you're forced the deal with the possibility before your code will even compile.
I believe that a type checker isn't necessary until you can no longer hold the entire codebase in your head. For me, that means once my program goes over about 150 LOC, I need the compiler to help me out.
The problems you mention aren't related
to transpilation or even JavaScript. They're due to TypeScript being a backwards-compatible superset of JS.
TS is, among other things, JS plus type annotations, but it also relies on the same underlying type system as JS, and TS types, as I understand it, are completely erased at runtime. For example, interfaces don't exist in JS, and classes are prototype-based. So it inherits those flaws, and doesn't patch over them with some kind of runtime, and you end up with a leaky abstraction.
I don't know anything about Reason's JS interaction to say if it's similarly leaky.
Reason is not transpiled language, it’s frontend replacement to ocaml compiler pipeline. Bucklescript, a different project, is backend replacement that emits Javascript instead of binaries. They can be used together, but don’t have to.
It should be possible to implement the instanceof operator for arbitrary types using essentially the same logic as the type checker. (Caveat: I don't know whether any TypeScript-specific properties make this impossible, since I have never used it.)
For each object, there is some function that takes no input and returns that object, by simply constructing the recursion-free parts of the object graph and then filling in any cycles. (TypeScript allows mutation, right?)
Then the question of `x instanceof Foo` becomes "is the function returning x typeable as () -> Foo". Of course that check is going to be much much more expensive than the simple comparison of the class tag other languages use, so I can understand why it's not part of the language.
The type checker has access to the source code (and any type annotations). That information isn't available at runtime, so I'm not sure how you'd be able to run the type checker at runtime.
You don't need the original source code, any code producing the object you want to check will do. If the object has a field "field" with value "value", then the code
function () { return {field: "value"}; }
produces a value of type Foo precisely when the original object was of type Foo, even if the code producing it was much more complex.
I don't see why that wouldn't work. If you have a specific example where that approach fails, I'd like to know about it.
But I don't know where you'd get that source code from at runtime though? I'm sure there are languages that contain enough runtime information, but, as an pertinent example, there isn't a way to tell that you have an object with certain fields in OCaml at runtime. It's just a block at runtime. All of the names are gone, as they were only used at compile time.
I was assuming the TypeScript/JavaScript scenario, where TypeScript objects are implemented as JavaScript objects and their structure is available at runtime. Of course it does not work if you do not have that reflection capability.
Since it's all JS under the hood, the type system is an illusion that language plays tricks on you. This makes it hard for people to understand how JS works or functions; without prior knowledge. Just to quote example one of my team mate had an interface in Typescript, and he was not able to understand why cant he do `x instanceof Foo`. Long story short is you can't have good "Typescript" programmer without being good JS developer. Which I believe will be the case here too. Yes it makes auto-complete better and documents really well; but improves code is debatable.
Don't get me wrong; I am not against it. All I am mentioning is the flip side that nobody will mention. OCaml is really powerful and cool kids are going to experience it with this effort, may be bring in new features/inspiration for next ES. But IMHO just a transpiled language can give you better constructs to express code; but it can't prevent a dumb programmer from making errors. I will for sure give this a shot and blog about it.