6 ms·

> 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, b

> 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.

tomtheelder 9y 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.
- jnbiche 9y 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?
  - simplify 9y 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.
    - jnbiche 9y ago
      What problem did you have?? I've been using Flow.js for work for several years now, to great success. I feel very uncomfortable now writing plain JS.
      - simplify 9y ago
        For some reason I could never get flow's in-editor errors and type information to work. Personally I use TypeScript. Their sublime support is nice and fast.
gcanti 9y ago
working on a fp library for TypeScript if you want to take a look https://github.com/gcanti/fp-ts https://github.com/gcanti/fp-ts
Skinney 9y 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.
- jnbiche 9y 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-plugin-flowtype-rules-no-weak-types https://github.com/gajus/eslint-plugin-flowtype#eslint-plugi...
  - Skinney 9y 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.
    - jnbiche 9y ago
      > Cool! Does it enforce third-party libraries as well? Yes, as long as you lint those libraries, too. > A thing that typescript and/or flow doesn't support, is JSON. What if a JSON object doesn't match the type? That's why you do runtime validations of your incoming JSON if you feel like you can't trust the data (and if it's an external API, you probably can't). How is this different from Elm? > But I've been bitten several times by the fact that typescript isn't as strict as Elm forces things to be In my experience with Flow, between the Flow analyzer and accompanying linter, you can make it just about as strict as you want with respect to types. The main thing you'll miss (as discussed elsewhere) is that unlike Elm, there's no way to guarantee referential transparency with JS and Flow.
fbonetti 9y 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.
- jnbiche 9y 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.
fulafel 9y 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.
- laughinghan 9y 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.

tomtheelder 9y 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.

jnbiche 9y 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?
- simplify 9y 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.
  - jnbiche 9y ago
    What problem did you have?? I've been using Flow.js for work for several years now, to great success. I feel very uncomfortable now writing plain JS.
    - simplify 9y ago
      For some reason I could never get flow's in-editor errors and type information to work. Personally I use TypeScript. Their sublime support is nice and fast.

gcanti 9y ago

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

Skinney 9y 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.

jnbiche 9y 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-plugin-flowtype-rules-no-weak-types https://github.com/gajus/eslint-plugin-flowtype#eslint-plugi...
- Skinney 9y 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.
  - jnbiche 9y ago
    > Cool! Does it enforce third-party libraries as well? Yes, as long as you lint those libraries, too. > A thing that typescript and/or flow doesn't support, is JSON. What if a JSON object doesn't match the type? That's why you do runtime validations of your incoming JSON if you feel like you can't trust the data (and if it's an external API, you probably can't). How is this different from Elm? > But I've been bitten several times by the fact that typescript isn't as strict as Elm forces things to be In my experience with Flow, between the Flow analyzer and accompanying linter, you can make it just about as strict as you want with respect to types. The main thing you'll miss (as discussed elsewhere) is that unlike Elm, there's no way to guarantee referential transparency with JS and Flow.

fbonetti 9y 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.

jnbiche 9y 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.

fulafel 9y 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.

laughinghan 9y 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.