4 ms·

The key is to not write large Haskell programs. Write many Haskell libraries and compose them. This scales infinitely and is an excellent way to build software.

The key is to not write large Haskell programs. Write many Haskell libraries and compose them. This scales infinitely and is an excellent way to build software. But it's also hard to do and takes good & deliberate technical leadership if you want to get 50+ engineers doing it.

ohduran 3y ago
You could say that it requires God levels of discipline.
kaba0 3y ago
If you can reason about f and g that doesn’t mean that you can tell anything useful about f o g, so no, this is a factually incorrect statement. Sure, if we have a separate unit of functionality, write a function for that. But that’s no silver bullet - complexity is unbounded.
- louthy 3y ago
  That isn’t true. If f and g are pure then the composition holds the same guarantees as the component parts
- woolion 3y ago
  >If you can reason about f and g that doesn’t mean that you can tell anything useful about f o g I'm confused. If you can reason about f and g, there is nothing more to know about f o g -- provided f and g are pure functions. The whole thing is about making sure side-effects are properly pushed at the boundaries so that you can keep working with pure functions. Haskell just provides more help (or more constraints) to ensure that you work with pure functions. Because if you aren't, all bets are off, and indeed the case of f o g may be a haze.
  - kaba0 3y ago
    f :: Integer -> Boolean g f n = if (f n) then (g f (n+1)) else (is_it_reachable) Will it ever terminate (or insert any other interesting property that you wish) with f = collatz? I know this is the atomic bomb case, but you can actually quite easily increase the complexity in realistic programs by just a few compositions, it doesn’t take much.
    - louthy 3y ago
      Who said anything about termination? The original point was about composition. The guarantees of the component parts are the same as the composition. It's neither clear that f or g will terminate, and it's the same for f . g If the halting problem is really your biggest concern when developing software then you're lucky!
      - kaba0 3y ago
        The Halting problem’s immediate consequence is Rice’s theorem, which is much more wide-reaching then termination.
        Quekid5 3y ago
        ... and entirely irrelevant when talking about function composition.
    - woolion 3y ago
      Here you are defining a new function, not composing two functions. But if you consider a program implementation of pure functions, this might not be true; for example f and g use a quantity of RAM, but the RAM used by f o g exceeds your computer RAM and thus explodes. Or, if we work with objects, some values (e.g. internal values of the object, or context values) may be changed that make the final result of f o g different from what you would normally expect. The promise of working "functionally" is to avoid the second class of problems. For the first class this is just a problem of computer systems, but pure functions means that the memory should be able to be reclaimed efficiently. And for the limits of computability theory (like the halting problem), nothing works except oracle machines, but no startup has ever delivered a functional one!
      - sterlind 3y ago
        Composing pure functions is equivalent to defining a new function, that's the idea behind the set of combinators being Turing-complete.
- whateveracct 3y ago
  > If you can reason about f and g that doesn’t mean that you can tell anything useful about f o g What? The ability to reason about f o g (for various definitions of o) is the promise of Haskell and one of its entire ecosystem's foundational principles. Local reasoning is absolutely possible.
cageface 3y ago
How is this different from any other programming language?
- whateveracct 3y ago
  Honestly, it isn't! But Haskell technical leadership sometimes is either lacking/inexperienced or goes down the rabbit hole of overusing the compiler to prevent fuckups to the point where you're compiling way too much code and get into a coupling nightmare.
koolala 3y ago
Monads!
pyuser583 3y ago
Yes. Seriously. Closest we have to this is micro services. But at the code level - nobody cares at all. It’s like we are writing literature, not building tools.

ohduran 3y ago

You could say that it requires God levels of discipline.

kaba0 3y ago

If you can reason about f and g that doesn’t mean that you can tell anything useful about f o g, so no, this is a factually incorrect statement. Sure, if we have a separate unit of functionality, write a function for that. But that’s no silver bullet - complexity is unbounded.

louthy 3y ago
That isn’t true. If f and g are pure then the composition holds the same guarantees as the component parts
woolion 3y ago
>If you can reason about f and g that doesn’t mean that you can tell anything useful about f o g I'm confused. If you can reason about f and g, there is nothing more to know about f o g -- provided f and g are pure functions. The whole thing is about making sure side-effects are properly pushed at the boundaries so that you can keep working with pure functions. Haskell just provides more help (or more constraints) to ensure that you work with pure functions. Because if you aren't, all bets are off, and indeed the case of f o g may be a haze.
- kaba0 3y ago
  f :: Integer -> Boolean g f n = if (f n) then (g f (n+1)) else (is_it_reachable) Will it ever terminate (or insert any other interesting property that you wish) with f = collatz? I know this is the atomic bomb case, but you can actually quite easily increase the complexity in realistic programs by just a few compositions, it doesn’t take much.
  - louthy 3y ago
    Who said anything about termination? The original point was about composition. The guarantees of the component parts are the same as the composition. It's neither clear that f or g will terminate, and it's the same for f . g If the halting problem is really your biggest concern when developing software then you're lucky!
    - kaba0 3y ago
      The Halting problem’s immediate consequence is Rice’s theorem, which is much more wide-reaching then termination.
      - Quekid5 3y ago
        ... and entirely irrelevant when talking about function composition.
  - woolion 3y ago
    Here you are defining a new function, not composing two functions. But if you consider a program implementation of pure functions, this might not be true; for example f and g use a quantity of RAM, but the RAM used by f o g exceeds your computer RAM and thus explodes. Or, if we work with objects, some values (e.g. internal values of the object, or context values) may be changed that make the final result of f o g different from what you would normally expect. The promise of working "functionally" is to avoid the second class of problems. For the first class this is just a problem of computer systems, but pure functions means that the memory should be able to be reclaimed efficiently. And for the limits of computability theory (like the halting problem), nothing works except oracle machines, but no startup has ever delivered a functional one!
    - sterlind 3y ago
      Composing pure functions is equivalent to defining a new function, that's the idea behind the set of combinators being Turing-complete.
whateveracct 3y ago
> If you can reason about f and g that doesn’t mean that you can tell anything useful about f o g What? The ability to reason about f o g (for various definitions of o) is the promise of Haskell and one of its entire ecosystem's foundational principles. Local reasoning is absolutely possible.

cageface 3y ago

How is this different from any other programming language?

whateveracct 3y ago
Honestly, it isn't! But Haskell technical leadership sometimes is either lacking/inexperienced or goes down the rabbit hole of overusing the compiler to prevent fuckups to the point where you're compiling way too much code and get into a coupling nightmare.

koolala 3y ago

Monads!

pyuser583 3y ago

Yes. Seriously. Closest we have to this is micro services. But at the code level - nobody cares at all. It’s like we are writing literature, not building tools.