undefined | Better HN

0 pointshudon8y ago0 comments

I agree that Elm is more strict at compile-time than TypeScript, there is no argument there.

What I have a problem with is using an example where the programmer is lazy in TypeScript, then assuming the programmer is NOT lazy when coding in Elm.

If you just print an empty error string and your app continues running assuming it decoded successfully, you can be in as bad a place as the app that crashed. Actually, in some mission critical cases, failing hard is safer than continuing with corrupt data.

In both cases, TypeScript AND Elm, you must do work to handle the failure to decode gracefully, it will actually be less work in TypeScript because you have less to specify. The only difference is that in Elm, you are reminded more often to do that work.

0 comments

Skinney8y ago

The difference here, is that a lazy programmer, when forced to handle this particular case, would use "Debug.crash 'should not happen'", which causes the Elm application to crash at runtime. The TypeScript program doesn't force you to deal with it, so the lazy programmer can assume everything works, no exception is raised, and you're now running with invalid state.

To catch this bug in TypeScript, you'd have to write runtime validation, which you are less likely to do, since you can just do JSON.parse. Elm, again, forces you to write runtime type validation, and handle the potential error (which could be something simple as crashing the entire application).

When it comes to reliability, that makes all the difference.

And I'm not arguing that Elm is great because of poor developers either. I do theese sort of things when I write typescript, simply because I just don't think about the error case that often. Elm is a wonderful straight jacket that makes me a better developer <3

hudonOP8y ago

> Elm, again, forces you to write runtime type validation

But it does not force you to handle failures correctly (as your lazy programmer example proves). Forcing you to handle a Left value from an Either type is not the same as forcing you to handle a Left value correctly.

Elm doesn't save you from bad failure handling, which is what the post I replied to claimed.

What Elm does do is remind you that you should handle failures, which I think is very valuable and I'm not arguing against (and is what you're arguing for). But you still need to write a correct handler, and Elm won't force you to do that!

Skinney8y ago

The original post did not make that claim. It said Elm made you handle errors where they can happen. It said nothing about handling it well. Typescript will not remind you every where an error will happen, and so it is very likely that you do not handle every error, even if it is your intention to do so.

j / k navigate · click thread line to collapse

0 pointshudon8y ago0 comments

I agree that Elm is more strict at compile-time than TypeScript, there is no argument there.

What I have a problem with is using an example where the programmer is lazy in TypeScript, then assuming the programmer is NOT lazy when coding in Elm.

0 comments

Skinney8y ago

When it comes to reliability, that makes all the difference.

hudonOP8y ago

> Elm, again, forces you to write runtime type validation

Elm doesn't save you from bad failure handling, which is what the post I replied to claimed.

Skinney8y ago

j / k navigate · click thread line to collapse