Hacker News Reader

Comment by opvasger | Hacker News Reader

I'm coming at this from the Elm-camp, and my first impression (and largely why I think languages like Elm is promising) is how languages that are implemented as supersets of other languages have the potential to be as bad as their subsets.

The example that I was given was C++ and C, but I think TypeScript with it's gradual-typing approach is forced to remain potentially as bad as JavaScript itself - that is, if you're feeling weak and want to "get shit done", you can bypass all the goodness that TypeScript undeniably offers you.

For a language like Elm, the type-system is invariably gonna have your back - a value-proposition I think means a lot more in practice than some self-proclaimed pragmatists realize :)

View on HN

I absolutely love Elm, and think it's great because it's a totally new approach for the frontend. That said, new approaches take much longer to build the critical mass for adoption than incremental ones (like Typescript). In a lot of ways, Elm reminds me of this Onion article from the early 2000's.

"Ghost Of Christmas Future Taunts Children With Visions Of PlayStation 5"

http://www.theonion.com/article/ghost-of-christmas-future-ta...

There's a project on my plate right now that when I saw the requirements and specs, I immediately thought, wow, Elm in a year from now would be absolutely perfect for this.

But it's just not there yet, so I'm exploring things like Typescript that have the advantage of the Javascript ecosystem beneath it. But I really cannot wait for Elm to be production-ready across the board and not just for specific use cases.

Check out Purescript [0]. I've used it in production.

[0] http://www.purescript.org

tsc --noImplicitAny solves that.

Or to go all-in - we have a `--strict` flag that gives you `noImplicitAny`, `strictNullChecks`, `noImplicitThis`, and a mode that always puts you in `"use strict"` mode.

I don't understand why `strictNullChecks` is not the default behavior. It being a special compiler option makes me somewhat dubious of TypeScript in general.

Backwards compatibility.

Ah, cool! The last major project I worked on in TS was still before null and this checking.

I think when he says bypass, he might mean you can explicitly cast to `any`.

Dynamic language proponents sometimes like to say that static types can't catch all errors and are therefore of little use.

Static type proponents sometimes like to say that unsound type systems that leave escape hatches are of little use.

The truth is that both are somewhat wrong.

Types are a tool. They help catch some errors and help code evolve - even when not completely sound, they still help catch some errors and evolve code.

They also don't understand all correct code, so sometimes they get in the way and when that happens, its important to get them out of the way in a manner that doesn't compromise things too much.

Nothing is black and white, there are only shades of grey.

In Haskell you can also explicitly cast to any type a using "error", "undefined" and "throw". But that's just what exceptions are in Haskell. This is fine, as long as it's only used in exceptional cases.

Reply on news.ycombinator.com