4 ms·

I write haskell and love typed languages, but I would never use anything like this. The fact is that it's forcing a concept that can't be expressed in the langu

by leshow 7y ago

I write haskell and love typed languages, but I would never use anything like this. The fact is that it's forcing a concept that can't be expressed in the language properly. And in the end you haven't gained anything, the functions that you use inside the block can still throw exceptions so you need a try/catch anyway. It's cool as an exercise, but I would never use it practically (in js). In other languages that fully support sum types and errors-as-values (like Rust). I find it a joy to work with and like it much more than exceptions.

lacampbell 7y ago
I write haskell and love typed languages, but I would never use anything like this. The fact is that it's forcing a concept that can't be expressed in the language properly. As someone who first discovered these kinds of types in F# and then ported them over to Javascript/Typescript - please explain why it can't be expressed in the language properly. Other than syntax it feels no different to me. It's been a great benefit to my programming. Objects have always been able to do a lot of what ADTs do and vice versa.
- leshow 7y ago
  To start, there's nothing linking the left and right variants together in the implementation shown in the blog. In Haskell and F# (never written f# but I assume) left and right are variants of a data type. In this blog they are just 2 disjoint classes. Those classes just happen to have the same functions implemented, but there's nothing specifying that to be the case. There's no support for sum types in js, or good support for pattern matching. If you like to use your home-grown Either type in js then more power to you. But there's no denying that you're shoehorning a concept into the language that it doesn't have good support for.
  - lacampbell 7y ago
    To start, there's nothing linking the left and right variants together in the implementation shown in the blog. In Haskell and F# (never written f# but I assume) left and right are variants of a data type. In this blog they are just 2 disjoint classes. Those classes just happen to have the same functions implemented, but there's nothing specifying that to be the case. In my javascript (well, typescript) version, I use an abstract base class and override the rightMap, leftMap etc versions. These concrete classes are internal, only the abstract one is exported. There's no support for sum types in js Using TSc is a linter, there 100% is support. I'd be happy to demonstrate if you're interested. Though it's a bit beside the point, despite having access to them I didn't implement them that way as I prefer method chaining. or good support for pattern matching. What pattern matching do you need for an either type? I enjoy pattern matching for lists, but even when using languages with pattern matching I don't use them for Option/Maybe, or Either. I was under the impression it was an anti-pattern to use pattern matching where a suitable function existed. But there's no denying that you're shoehorning a concept into the language that it doesn't have good support for. I deny it. IMO you can create a perfectly usable Either Type in any language that supports classes, objects and generics (well, maybe not C++). There's a lot I miss in JS from Ocaml and F#, but monadic error types are not one of them, because they're easy to implement and just as ergonomic. There's more than two ways to skin a cat, and after going back and forward between OO and FP for a while I realised I could accomplish the bulk of what I wanted in both paradigms.
    - leshow 7y ago
      > In my javascript (well, typescript) version, I'm critiquing the implementation shown in the blog, not your hypothetical implementation in typescript that I've never seen. > What pattern matching do you need for an either type? In nominal type systems like Rust/Haskell/F# you want to be able to match on the constructor. In typescript where '|' means something slightly different you need to fake a type constructor by adding a type: "variantname" property > I deny it. IMO you can create a perfectly usable Either Type in any language that supports classes, objects and generics (well, maybe not C++). Javascript doesn't support those things.
      - lacampbell 7y ago
        I'm critiquing the implementation shown in the blog, not your hypothetical implementation in typescript that I've never seen. That was not what you originally wrote: The fact is that it's forcing a concept that can't be expressed in the language properly. Your claim was that it cannot be expressed in the language properly, and I am disagreeing. In nominal type systems like Rust/Haskell/F# you want to be able to match on the constructor. In typescript where '|' means something slightly different you need to fake a type constructor by adding a type: "variantname" property You didn't answer the question, what useful pattern matching can you do with Either/Option? Give me pseudocode even. Javascript doesn't support those things. A few jsdoc comments and tsc command, and hey presto - it does.
- sideshowb 7y ago
  The lack of syntax alone puts me off. E.g. Inability to define an operator for composition
  - lacampbell 7y ago
    Yes that's annoying. It looks like JS will be getting the pipe operator soon. But Ocaml didn't have to wait around for it, since they can define operators in code.

by leshow 7y ago

lacampbell 7y ago

I write haskell and love typed languages, but I would never use anything like this. The fact is that it's forcing a concept that can't be expressed in the language properly. As someone who first discovered these kinds of types in F# and then ported them over to Javascript/Typescript - please explain why it can't be expressed in the language properly. Other than syntax it feels no different to me. It's been a great benefit to my programming. Objects have always been able to do a lot of what ADTs do and vice versa.

leshow 7y ago
To start, there's nothing linking the left and right variants together in the implementation shown in the blog. In Haskell and F# (never written f# but I assume) left and right are variants of a data type. In this blog they are just 2 disjoint classes. Those classes just happen to have the same functions implemented, but there's nothing specifying that to be the case. There's no support for sum types in js, or good support for pattern matching. If you like to use your home-grown Either type in js then more power to you. But there's no denying that you're shoehorning a concept into the language that it doesn't have good support for.
- lacampbell 7y ago
  To start, there's nothing linking the left and right variants together in the implementation shown in the blog. In Haskell and F# (never written f# but I assume) left and right are variants of a data type. In this blog they are just 2 disjoint classes. Those classes just happen to have the same functions implemented, but there's nothing specifying that to be the case. In my javascript (well, typescript) version, I use an abstract base class and override the rightMap, leftMap etc versions. These concrete classes are internal, only the abstract one is exported. There's no support for sum types in js Using TSc is a linter, there 100% is support. I'd be happy to demonstrate if you're interested. Though it's a bit beside the point, despite having access to them I didn't implement them that way as I prefer method chaining. or good support for pattern matching. What pattern matching do you need for an either type? I enjoy pattern matching for lists, but even when using languages with pattern matching I don't use them for Option/Maybe, or Either. I was under the impression it was an anti-pattern to use pattern matching where a suitable function existed. But there's no denying that you're shoehorning a concept into the language that it doesn't have good support for. I deny it. IMO you can create a perfectly usable Either Type in any language that supports classes, objects and generics (well, maybe not C++). There's a lot I miss in JS from Ocaml and F#, but monadic error types are not one of them, because they're easy to implement and just as ergonomic. There's more than two ways to skin a cat, and after going back and forward between OO and FP for a while I realised I could accomplish the bulk of what I wanted in both paradigms.
  - leshow 7y ago
    > In my javascript (well, typescript) version, I'm critiquing the implementation shown in the blog, not your hypothetical implementation in typescript that I've never seen. > What pattern matching do you need for an either type? In nominal type systems like Rust/Haskell/F# you want to be able to match on the constructor. In typescript where '|' means something slightly different you need to fake a type constructor by adding a type: "variantname" property > I deny it. IMO you can create a perfectly usable Either Type in any language that supports classes, objects and generics (well, maybe not C++). Javascript doesn't support those things.
    - lacampbell 7y ago
      I'm critiquing the implementation shown in the blog, not your hypothetical implementation in typescript that I've never seen. That was not what you originally wrote: The fact is that it's forcing a concept that can't be expressed in the language properly. Your claim was that it cannot be expressed in the language properly, and I am disagreeing. In nominal type systems like Rust/Haskell/F# you want to be able to match on the constructor. In typescript where '|' means something slightly different you need to fake a type constructor by adding a type: "variantname" property You didn't answer the question, what useful pattern matching can you do with Either/Option? Give me pseudocode even. Javascript doesn't support those things. A few jsdoc comments and tsc command, and hey presto - it does.
sideshowb 7y ago
The lack of syntax alone puts me off. E.g. Inability to define an operator for composition
- lacampbell 7y ago
  Yes that's annoying. It looks like JS will be getting the pipe operator soon. But Ocaml didn't have to wait around for it, since they can define operators in code.