5 ms·

Pure FP isn't the only acceptable programming paradigm, please stop pretending that it is. (For context: a language without null pretty much implies an Option

Pure FP isn't the only acceptable programming paradigm, please stop pretending that it is. (For context: a language without null pretty much implies an Option type, which is mostly useless (or no better than null itself) without static typing. Once you're that far you're probably gonna want to get monads to make them workable and congratulations you're reinventing Haskell)

baq 6y ago
Rust is quite far from pure FP.
alipang 6y ago
Found the guy who completely missed Kotlin, TypeScript and Scala.
- skrebbel 6y ago
  All three of which have null? TypeScript even has two kinds of null. Scala even has monads as well! :-)
  - neurotrace 6y ago
    TypeScript requires you to verify if the value is null-ish or not (assuming you're using the new default "strict mode"). I don't believe Gravity does
enricozb 6y ago
Since when does static typing imply monads...
- choeger 6y ago
  Actually, it does. If you want a sound and complete static type system for a practical language, you end up with monads (or something very close to it, like streams or effects) or you cannot type your side effects (and then your type system is either incomplete or your language impractical).
  - skrebbel 6y ago
    You don't need a sound type system for the language to be practical though. Eg C#, Kotlin, TypeScript.
  - tomcam 6y ago
    Argh this sounds interesting but I’m not smart enough to make the connections. Could you dumb the explanation down a bit?
    - lostcolony 6y ago
      It's just saying that your type system is incomplete if it doesn't capture side effects. That is, if the function can do something that is not expressed as part of its return type, its return type is insufficiently expressive. As an example, imagine an "updateDB" call that returns void. Totally could exist, and be useful, but all it does is a side effect; as a function you haven't expressed its functionality via its type. From a 'pure' perspective, it would be fair for the compiler to remove that call entirely, since you do nothing with the result (since there is no result). Instead you need a monad or something to express that side effect. Obviously, many languages don't choose to express side effects within their type systems. It's not that means the language isn't useful, just that its type system isn't complete; you have things happening without a type attached to them (and in that way it's dynamically typed).
      - tomp 6y ago
        Monads don't help you there, though. Even Haskell doesn't capture the effect of "division by zero". In the end, type systems (all of them, static as well as dynamic) are just a tradeoff between safety and practicality.
      - choeger 6y ago
        The problem is more that you cannot formally express your type system in such a case. The "pure" perspective you mentioned is basically the limited view that one can still work with when defining a type system. Side effects are then basically magic functions that have any necessary type (in fact, OCaml has such a function in its stdlib, called "magic", if I am not mistaken).
- skrebbel 6y ago
  Static typing and a useful option type in an ecosystem without null pretty much implies monads I think (or lots of boilerplate)
Risord 6y ago
First: Yes null VS option type is all about static knowledge so it's pretty irrelevant topic in context of dynamic language. In my mind in such languages null propagation operator is basicly all you need. But cmoon it's not about FP. Checkout C# value types nullable<T> for example. C# 8 brings same principles to reference types (however being non-safe since you cannot break compatibility). Only good reasons to have (Java like) null is to either because you already did it and you cannot take away or you are in ecosystem where it's fundamentally in. And to be precise it's not about null per se. Null can be just fine but it shouldn't be valid value for every type. You can solve it either by boxing (traditional option type) or some Type Scripty flat: Car | null ideology. In some sense all languages with Java like null have some option types buuut they are missing regular non-nullable types.
willtim 6y ago
The absence of nullable references is completely orthogonal to pure FP and static typing.

baq 6y ago

Rust is quite far from pure FP.

alipang 6y ago

Found the guy who completely missed Kotlin, TypeScript and Scala.

skrebbel 6y ago
All three of which have null? TypeScript even has two kinds of null. Scala even has monads as well! :-)
- neurotrace 6y ago
  TypeScript requires you to verify if the value is null-ish or not (assuming you're using the new default "strict mode"). I don't believe Gravity does

enricozb 6y ago

Since when does static typing imply monads...

choeger 6y ago
Actually, it does. If you want a sound and complete static type system for a practical language, you end up with monads (or something very close to it, like streams or effects) or you cannot type your side effects (and then your type system is either incomplete or your language impractical).
- skrebbel 6y ago
  You don't need a sound type system for the language to be practical though. Eg C#, Kotlin, TypeScript.
- tomcam 6y ago
  Argh this sounds interesting but I’m not smart enough to make the connections. Could you dumb the explanation down a bit?
  - lostcolony 6y ago
    It's just saying that your type system is incomplete if it doesn't capture side effects. That is, if the function can do something that is not expressed as part of its return type, its return type is insufficiently expressive. As an example, imagine an "updateDB" call that returns void. Totally could exist, and be useful, but all it does is a side effect; as a function you haven't expressed its functionality via its type. From a 'pure' perspective, it would be fair for the compiler to remove that call entirely, since you do nothing with the result (since there is no result). Instead you need a monad or something to express that side effect. Obviously, many languages don't choose to express side effects within their type systems. It's not that means the language isn't useful, just that its type system isn't complete; you have things happening without a type attached to them (and in that way it's dynamically typed).
    - tomp 6y ago
      Monads don't help you there, though. Even Haskell doesn't capture the effect of "division by zero". In the end, type systems (all of them, static as well as dynamic) are just a tradeoff between safety and practicality.
    - choeger 6y ago
      The problem is more that you cannot formally express your type system in such a case. The "pure" perspective you mentioned is basically the limited view that one can still work with when defining a type system. Side effects are then basically magic functions that have any necessary type (in fact, OCaml has such a function in its stdlib, called "magic", if I am not mistaken).
skrebbel 6y ago
Static typing and a useful option type in an ecosystem without null pretty much implies monads I think (or lots of boilerplate)

Risord 6y ago

First: Yes null VS option type is all about static knowledge so it's pretty irrelevant topic in context of dynamic language. In my mind in such languages null propagation operator is basicly all you need. But cmoon it's not about FP. Checkout C# value types nullable<T> for example. C# 8 brings same principles to reference types (however being non-safe since you cannot break compatibility). Only good reasons to have (Java like) null is to either because you already did it and you cannot take away or you are in ecosystem where it's fundamentally in. And to be precise it's not about null per se. Null can be just fine but it shouldn't be valid value for every type. You can solve it either by boxing (traditional option type) or some Type Scripty flat: Car | null ideology. In some sense all languages with Java like null have some option types buuut they are missing regular non-nullable types.

willtim 6y ago

The absence of nullable references is completely orthogonal to pure FP and static typing.