3 ms·

I would like to add that just like in our universe, in Haskell entropy only ever increases and never goes down. I.E., add more functionality to your program and

I would like to add that just like in our universe, in Haskell entropy only ever increases and never goes down. I.E., add more functionality to your program and the complexity will go up. This is true for all programming languages of course, but in my limited experience larger Haskell programs seem to become exponentially more complex.

quickthrower2 3y ago
Item is not O(functionality) but O(category theory knowledge)
zadler 3y ago
More instances. More.
whateveracct 3y ago
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
  - 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.
slacknatcher12 3y ago
not to argue your major point, but more entropy makes things more uniform/less complex. think of the heat death of the universe.
- mathisfun123 3y ago
  complex can be a synonym for disorder and it can also be a synonym for structure. in this instance, the clear meaning is disorder. > become exponentially more complex obviously this can't be read as "become exponentially more structured" given the tone of the sentence.
ogogmad 3y ago
I have a theory that Haskell's main applications are in teaching and academic research - both concerning theoretical computer science. It's not a practical engineering language.
- agentultra 3y ago
  I have evidence to the contrary. I have a job writing Haskell for a living doing boring, normal software. I also started a stream where I write libraries and games and build stuff in Haskell purely to disprove this theory. It's been going well: we've written a logical replication client library for Postgres, built an asteroids clone, etc. It is a very practical language.
  - dannyobrien 3y ago
    Do you have a link to your stream?
    - agentultra 3y ago
      https://twitch.tv/agentultra https://twitch.tv/agentultra and Youtube where I archive my streams: https://www.youtube.com/channel/UCg4RIhvLDjiAzMmWgdcMG1g https://www.youtube.com/channel/UCg4RIhvLDjiAzMmWgdcMG1g
slacknatcher12 3y ago
this is an interesting observation. I have various explanation on why that might be the case. on a commercial setting there is more pressure to deliver code then to review it. combine it with the lack of our benevolent dictator for life (that has been on the project the world life cycle, not just recently), there is no one with power to actually say no to changes. language geeks are novelty seekers. they will use every feature of their language . stronger languages have more features to abuse. so on a commercial setting you will have all the features being used without much thought an architectural design that says you that no, we shouldn't do that. that's also why I think projects with benevolent dictators for life on the open source ward don't fall these in paths even though they use languages that are stronger. you could restrict yourself to use languages that have only one way to be used, so python as it was originally. or use a language little abstraction power. but you will suffer in other ways. as abstraction power is genuinely useful. accidental complexity has a way of getting in by expressive means or by social means.
riku_iki 3y ago
I imagine there can be some language, which can automatically modify programs, e.g. you added some conditions, and compiled removed/disabled/moved to obsolete package all unnecessary branches which became unreachable or simplified logic.

quickthrower2 3y ago

Item is not O(functionality) but O(category theory knowledge)

zadler 3y ago

More instances. More.

whateveracct 3y ago

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
- 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.

slacknatcher12 3y ago

not to argue your major point, but more entropy makes things more uniform/less complex. think of the heat death of the universe.

mathisfun123 3y ago
complex can be a synonym for disorder and it can also be a synonym for structure. in this instance, the clear meaning is disorder. > become exponentially more complex obviously this can't be read as "become exponentially more structured" given the tone of the sentence.

ogogmad 3y ago

I have a theory that Haskell's main applications are in teaching and academic research - both concerning theoretical computer science. It's not a practical engineering language.

agentultra 3y ago
I have evidence to the contrary. I have a job writing Haskell for a living doing boring, normal software. I also started a stream where I write libraries and games and build stuff in Haskell purely to disprove this theory. It's been going well: we've written a logical replication client library for Postgres, built an asteroids clone, etc. It is a very practical language.
- dannyobrien 3y ago
  Do you have a link to your stream?
  - agentultra 3y ago
    https://twitch.tv/agentultra https://twitch.tv/agentultra and Youtube where I archive my streams: https://www.youtube.com/channel/UCg4RIhvLDjiAzMmWgdcMG1g https://www.youtube.com/channel/UCg4RIhvLDjiAzMmWgdcMG1g

slacknatcher12 3y ago

this is an interesting observation. I have various explanation on why that might be the case. on a commercial setting there is more pressure to deliver code then to review it. combine it with the lack of our benevolent dictator for life (that has been on the project the world life cycle, not just recently), there is no one with power to actually say no to changes. language geeks are novelty seekers. they will use every feature of their language . stronger languages have more features to abuse. so on a commercial setting you will have all the features being used without much thought an architectural design that says you that no, we shouldn't do that. that's also why I think projects with benevolent dictators for life on the open source ward don't fall these in paths even though they use languages that are stronger. you could restrict yourself to use languages that have only one way to be used, so python as it was originally. or use a language little abstraction power. but you will suffer in other ways. as abstraction power is genuinely useful. accidental complexity has a way of getting in by expressive means or by social means.

riku_iki 3y ago

I imagine there can be some language, which can automatically modify programs, e.g. you added some conditions, and compiled removed/disabled/moved to obsolete package all unnecessary branches which became unreachable or simplified logic.