4 ms·

That's not that weird. After trying to learn Haskell and reading "Understanding Computation" the Struct and enumerable style of structuring code feels very natu

That's not that weird. After trying to learn Haskell and reading "Understanding Computation" the Struct and enumerable style of structuring code feels very natural. I disagree with the conclusions though. Contracts and replacing `nil` with `Maybe` doesn't sound right to me at all since I use `nil` pretty heavily all over the place and the extra layer of `Maybe` doesn't buy me anything. I don't understand what he means by a dependency system since Gems have their dependencies spelled out pretty explicitly. Killing symbols is just silly because I use them to tag all sorts of stuff and message passing with symbols feels more natural than any other data type. Packaging could be better and optional types would also be nice. I like how TypeScript does it actually quite a lot.

codygman 12y ago
> extra layer of `Maybe` doesn't buy me anything. Wouldn't that layer be there all the time anyway? Either in the form of a sum type (Just a | Nothing), explicit nil checking, or ignoring nil's and getting a runtime error.
- dkarapetyan 12y ago
  It's there with nil to begin with. A Maybe type without pattern matching is basically nil checking. Now if he had said I want some kind of pattern matching then I would get behind that.
  - codygman 12y ago
    So you would prefer a language without sum types but with pattern matching and exhaustiveness checking for nil then?
    - dkarapetyan 12y ago
      Not what I said and I don't see why you make those choices mutually exclusive. You can have pattern matching without sum types and you can have sum types without pattern matching. In fact Ruby's case/when statement is very limited form of pattern matching that can be put to great use with proper use of Structs and overloading of ===.
      - masklinn 12y ago
        Erlang is probably a better example of pattern matching (complete) without formal sum types (though dialyzer has value and type alternatives)
tessierashpool 12y ago
if you think replacing nil with Maybe buys you nothing, I highly recommend this video: "Why and how to avoid nil" https://www.destroyallsoftware.com/screencasts/catalog/how-and-why-to-avoid-nil https://www.destroyallsoftware.com/screencasts/catalog/how-a... you have to pay to see it, but it's terrific. (not mine, just a fan.)

codygman 12y ago

> extra layer of `Maybe` doesn't buy me anything. Wouldn't that layer be there all the time anyway? Either in the form of a sum type (Just a | Nothing), explicit nil checking, or ignoring nil's and getting a runtime error.

dkarapetyan 12y ago
It's there with nil to begin with. A Maybe type without pattern matching is basically nil checking. Now if he had said I want some kind of pattern matching then I would get behind that.
- codygman 12y ago
  So you would prefer a language without sum types but with pattern matching and exhaustiveness checking for nil then?
  - dkarapetyan 12y ago
    Not what I said and I don't see why you make those choices mutually exclusive. You can have pattern matching without sum types and you can have sum types without pattern matching. In fact Ruby's case/when statement is very limited form of pattern matching that can be put to great use with proper use of Structs and overloading of ===.
    - masklinn 12y ago
      Erlang is probably a better example of pattern matching (complete) without formal sum types (though dialyzer has value and type alternatives)

tessierashpool 12y ago

if you think replacing nil with Maybe buys you nothing, I highly recommend this video: "Why and how to avoid nil" https://www.destroyallsoftware.com/screencasts/catalog/how-and-why-to-avoid-nil https://www.destroyallsoftware.com/screencasts/catalog/how-a... you have to pay to see it, but it's terrific. (not mine, just a fan.)