These are chat archives for got-lambda/expression

Oct 2018
Jean-Louis Giordano
Oct 26 2018 07:58
yeah I don't think he's being objective with the potential of typing systems... One thing I do note though is that we're pitting the "potential" of types vs the current realities. For backend code I don't think there are many alternatives that address the issues raised by him? Like PureScript, TypeScript and Elm each have some answers for that (and they all have their drawbacks), but they are in the front end. Haskell or Scala I guess are the current best alternatives. Scala does address some of those concerns as well I guess (clearly with its own drawbacks). It generally feels to me that when we discuss dynamic vs static, it's often dynamic vs "the best of each approach to static typing from each static language that exists without combining their respective drawbacks"
I like the racket spirit though, because then you would get closer to what @Zalastax is dreaming of
like if your problem is ideally address with dependent types, or with structural typing, or with dynamic typing, you write each part in the relevant language with a unifying abstraction at the bottom
(which in my book is slightly different from gradual typing? I not longer believe that much in gradual typing due to boundary check & conditions and unsoundness, but I like the concept of Language Oriented Programming)
Oct 26 2018 13:37
@Jell Yeah I agree. And I like that Rich Hickey is pushing it a bit. There is a "problem selection bias" tendency in the FP community, and then people extrapolate that FP is the best for everything. (It might be, but the conclusion is often ill-founded.) It's a general tendency that people think that all programming is the kind of programming they do, and Rich Hickey makes a good point when saying that if you write a language to write compilers, device drivers, phones switches or "information-drive situated programs" you get different languages.
Like, he's not terribly worried about correctness. He even says he's tired of hearing about correctness.
Oct 26 2018 13:42
One thing that he might underestimate (but I dunno, he's spent a lot of time in the hammock), is the value of types for seeing the structure. He says that "if you actually parameterized an information system, it would be Maybe everything".
So I disagree with that. You're central data type would have a lot of Maybes, but your functions would not.
If you have a function that takes a huge map, and it needs a non-nil social security number in it (his example), you can just as well say that. From that point and beyond, you will start to not have Maybes. Or you will at least be explicit about the maybeness. So since you can use applicative functors if you might have maybes, you can still write your functions so that they don't do nil checks.
But I get the impression that he would do the (when-let [snr (:snr big-map)]) and let the function return nil if it didn't have the required data. In an Haskell-like you'd write that with <$> and <*> instead.