undefined | Better HN

0 pointsjnbiche8y ago0 comments

> I've been programming a long time, and elm shattered my views of the relationship between a coder and his/her compiler.

I love Elm as much as the next guy, but be aware that you can get many, if not most, of these same benefits while working in JS if you use Flow.js or Typescript. I prefer Flow because the community is more oriented toward functional programming vs OOP in Typescript, but they're both capable static analyzers for JS.

0 comments

tomtheelder8y ago

I would disagree strongly with this, but I don't quite know how to put my objection into words. The enforced functional purity, "true" and incredibly friendly compiler, and the robust message system are all things that I don't think you really get in those other languages. To me, it's a bit like saying that you get all the benefits of Haskell in Java, because Java is also statically typed.

jnbicheOP8y ago

Please read my comment again, I said "many if not most" of the benefits. And I was referring specifically to the tire system, not the language as a whole.

Listen, I love pure functional languages, but the step up from JavaScript to flow in program correctness is greater than the step up from flow to elm (in my opinion). Flow even has sum types.

Have you actually tried flow?

simplify8y ago

I've tried to use flow three times now, but the tooling just isn't there yet. It might be better now, but Facebook doesn't seem to invest heavily in developer UX.

1 more reply

fbonetti8y ago

Cons of using Typescript:

* Lack of purity. You can unintentionally trigger side effects from a function that's a supposed to simply return a value.

    function add(x: number, y: number): number {
      fireTheMissiles()
      return x + y
    }

* It's impossible to validate that external JSON data is the correct type at runtime. If a JSON API returns something weird, you're going to get a runtime error.

jnbicheOP8y ago

> Lack of purity.

I agree. Which is why I said "many if not most" benefits, not all benefits.

> It's impossible to validate that external JSON data is the correct type at runtime.

Not sure I understand what you're saying. Of course you'll get a runtime error if your external JSON is the wrong type, what else could you do? Accept the data and enter an inconsistent state?

However, similar to the Elm JSON validation, in Typescript and Flow, you can write schemas to to runtime validation of external JSON. There are multiple libraries for this.

Skinney8y ago

I've used both Typescript and Flow, and this breaks down in practice. At least, it did for me.

Problem with both Typescript and Flow is that it requires discipline from you, your team, and those who provide third party libraries. If someone was lazy and inserted `any` at a key location, you can start having familiar bugs even if the type checker tells you everything is fine.

jnbicheOP8y ago

This is trivial to avoid with a linter (which is a good idea to use anyway with JavaScript). For Flow, there's an eslint plugin that allows you to raise an error on the use of any weak type, such as `any` [1]. I'd be very surprised if the same doesn't exist for TypeScript.

1. https://github.com/gajus/eslint-plugin-flowtype#eslint-plugi...

Skinney8y ago

Cool! Does it enforce third-party libraries as well? A thing that typescript and/or flow doesn't support, is JSON. What if a JSON object doesn't match the type? This can cause sneaky bugs later :/

I'm not saying that typescript/flow is bad. Whenever I have to use node.js, I end up using typescript. But I've been bitten several times by the fact that typescript isn't as strict as Elm forces things to be.

1 more reply

fulafel8y ago

That's like saying an angry bear has many of the benefits of a bicycle. It may be factually true but the downsides of riding an angry generally outweigh the benefits, and anyway it's a different kind of thing altogether from a bicycle.

laughinghan8y ago

It's nothing like that. The downsides of riding an angry bear relative to a bicycle also apply relative to just walking, to the point that it's always better to just walk than to ride an angry bear for transportation. The downsides of Flow.js or TypeScript relative to Elm don't at all apply relative to vanilla JS, it's often better to use them rather than vanilla JS.

gcanti8y ago

working on a fp library for TypeScript if you want to take a look https://github.com/gcanti/fp-ts

j / k navigate · click thread line to collapse

0 comments

tomtheelder8y ago

jnbicheOP8y ago

Please read my comment again, I said "many if not most" of the benefits. And I was referring specifically to the tire system, not the language as a whole.

Listen, I love pure functional languages, but the step up from JavaScript to flow in program correctness is greater than the step up from flow to elm (in my opinion). Flow even has sum types.

Have you actually tried flow?

simplify8y ago

I've tried to use flow three times now, but the tooling just isn't there yet. It might be better now, but Facebook doesn't seem to invest heavily in developer UX.

1 more reply

fbonetti8y ago

Cons of using Typescript:

* Lack of purity. You can unintentionally trigger side effects from a function that's a supposed to simply return a value.

    function add(x: number, y: number): number {
      fireTheMissiles()
      return x + y
    }

* It's impossible to validate that external JSON data is the correct type at runtime. If a JSON API returns something weird, you're going to get a runtime error.

jnbicheOP8y ago

> Lack of purity.

I agree. Which is why I said "many if not most" benefits, not all benefits.

> It's impossible to validate that external JSON data is the correct type at runtime.

Not sure I understand what you're saying. Of course you'll get a runtime error if your external JSON is the wrong type, what else could you do? Accept the data and enter an inconsistent state?

However, similar to the Elm JSON validation, in Typescript and Flow, you can write schemas to to runtime validation of external JSON. There are multiple libraries for this.

Skinney8y ago

I've used both Typescript and Flow, and this breaks down in practice. At least, it did for me.

jnbicheOP8y ago

1. https://github.com/gajus/eslint-plugin-flowtype#eslint-plugi...

Skinney8y ago

Cool! Does it enforce third-party libraries as well? A thing that typescript and/or flow doesn't support, is JSON. What if a JSON object doesn't match the type? This can cause sneaky bugs later :/

1 more reply

fulafel8y ago

laughinghan8y ago

gcanti8y ago

working on a fp library for TypeScript if you want to take a look https://github.com/gcanti/fp-ts

j / k navigate · click thread line to collapse