4 ms·

I agree with all your points. Have you looked at any strongly typed functional language from ML like Ocaml, F#, Rust, or say similar like Haskell? If you do ma

by whb07 6y ago

I agree with all your points. Have you looked at any strongly typed functional language from ML like Ocaml, F#, Rust, or say similar like Haskell? If you do make a slight tweak somewhere, the compiler will tell you there’s something broken in obscure place X that you would find out at runtime say with Ruby or Python. THATS the winning formula. I’ve written so many tests for Python ensuring a function’s arguments are validated rather than the core logic/process of it.

claudiusd 6y ago
I have only done a little bit but I know exactly what you're talking about and it's great.
- whb07 6y ago
  Really give it a go! It is beyond worldly. If you think Typescript is great, then ocaml/f# will make it look inferior. If you're doing React + Typescript give Reasonml which is a syntax sugar on top of Ocaml that compiles using bucklescript a go. Ocaml has the fastest compiler out there. [0] https://reasonml.github.io/ https://reasonml.github.io/
  - goostavos 6y ago
    You could always go even further to the FP darkside and join the Purescript community >:)
    - whb07 6y ago
      How’s the tooling for that? Haskell has the “best” compiler and garbage tooling that should be built on top of the ol’ rolls Royce engine it’s rocking on. Meanwhile the plugins and IDE integrations for Reason/Ocaml and F# are ready to go from the start and work pretty well.
marcosdumay 6y ago
> THATS the winning formula. Not so fast. For some problems it's great, for other ones it's not. Have you tried writing numeric or machine leaning core in Haskell? You'll notice that the type system just doesn't help you enforce correctness. Have you tried writing low level IO? The logic is too complex to capture on types, if you try to use them you'll have a huge problem.
- wizzwizz4 6y ago
  > Have you tried writing low level IO? The logic is too complex to capture on types, if you try to use them you'll have a huge problem. Rust's got a very Haskell-like type system, but it's a systems programming language. People are literally writing kernels in it. I think this is a pure-functional-is-a-bad-way-to-do-real-time-I/O thing, not a typing thing.
  - steveklabnik 6y ago
    While this is true in some senses, Rust's type system is very different than Haskell's when it comes to handling IO. That said, I don't think it's impossible to type IO. https://lexi-lambda.github.io/blog/2020/01/19/no-dynamic-type-systems-are-not-inherently-more-open/ https://lexi-lambda.github.io/blog/2020/01/19/no-dynamic-typ... isn't the same problem, but it's related.
  - marcosdumay 6y ago
    Hum... Pure functional is a bad way to do real time I/O, but my point was about types. If you try to verify the kind of state machines that low level I/O normally use with Haskell-like types, you will gain a huge amount of complexity and probably end with more bugs than without.
    - wizzwizz4 6y ago
      Low-level I/O doesn't seem to have that much complexity, unless you're trying to handle all of the engineers' levels of abstraction at once. Let's say you're writing a /dev/console driver for an RS-232 connection. Trying to represent "ring indicator", "parity failure", "invalid UTF-8 sequence", "keyboard interrupt", "hup" and "buffer full" at the same level in the type system will fail abysmally, but that's not a sensible way of doing it. I could definitely implement this while leveraging the power of Rust's type system – Haskell would be a stretch, but only because it's side-effect free and I/O is pretty much all side-effects.

by whb07 6y ago

claudiusd 6y ago

I have only done a little bit but I know exactly what you're talking about and it's great.

whb07 6y ago
Really give it a go! It is beyond worldly. If you think Typescript is great, then ocaml/f# will make it look inferior. If you're doing React + Typescript give Reasonml which is a syntax sugar on top of Ocaml that compiles using bucklescript a go. Ocaml has the fastest compiler out there. [0] https://reasonml.github.io/ https://reasonml.github.io/
- goostavos 6y ago
  You could always go even further to the FP darkside and join the Purescript community >:)
  - whb07 6y ago
    How’s the tooling for that? Haskell has the “best” compiler and garbage tooling that should be built on top of the ol’ rolls Royce engine it’s rocking on. Meanwhile the plugins and IDE integrations for Reason/Ocaml and F# are ready to go from the start and work pretty well.

marcosdumay 6y ago

> THATS the winning formula. Not so fast. For some problems it's great, for other ones it's not. Have you tried writing numeric or machine leaning core in Haskell? You'll notice that the type system just doesn't help you enforce correctness. Have you tried writing low level IO? The logic is too complex to capture on types, if you try to use them you'll have a huge problem.

wizzwizz4 6y ago
> Have you tried writing low level IO? The logic is too complex to capture on types, if you try to use them you'll have a huge problem. Rust's got a very Haskell-like type system, but it's a systems programming language. People are literally writing kernels in it. I think this is a pure-functional-is-a-bad-way-to-do-real-time-I/O thing, not a typing thing.
- steveklabnik 6y ago
  While this is true in some senses, Rust's type system is very different than Haskell's when it comes to handling IO. That said, I don't think it's impossible to type IO. https://lexi-lambda.github.io/blog/2020/01/19/no-dynamic-type-systems-are-not-inherently-more-open/ https://lexi-lambda.github.io/blog/2020/01/19/no-dynamic-typ... isn't the same problem, but it's related.
- marcosdumay 6y ago
  Hum... Pure functional is a bad way to do real time I/O, but my point was about types. If you try to verify the kind of state machines that low level I/O normally use with Haskell-like types, you will gain a huge amount of complexity and probably end with more bugs than without.
  - wizzwizz4 6y ago
    Low-level I/O doesn't seem to have that much complexity, unless you're trying to handle all of the engineers' levels of abstraction at once. Let's say you're writing a /dev/console driver for an RS-232 connection. Trying to represent "ring indicator", "parity failure", "invalid UTF-8 sequence", "keyboard interrupt", "hup" and "buffer full" at the same level in the type system will fail abysmally, but that's not a sensible way of doing it. I could definitely implement this while leveraging the power of Rust's type system – Haskell would be a stretch, but only because it's side-effect free and I/O is pretty much all side-effects.