On: On Getting Older in Tech

[kazinator]

OOP absolutely embraces I/O. I/O begs to be OOP and makes, hands down, the best use case for illustrating OOP.

[bbcbasic → kazinator]

What I am getting at is that OOP languages like C++ have no IO commands built in it is all delegated to libraries.

Haskell has no state support built in, it is all delegated to libraries.

So:

C++ has excellent IO support, but the language doesn't embrace IO at all.

Haskell has excellent State support, but the language doesn't embrace State at all.

[kazinator → bbcbasic]

C++ I/O libraries in fact depend on the sequencing semantics built into the language. If we make two calls to the library, they happen in that order; consequently, the I/O happens in that order. We can do wrong things like:

    f(cout << x, cout << y)

where we don't know whether x is sent to cout first or y.

C++ statements could be added to C++ (e.g. as a compiler extension). They would be straightforward to use; C++ doesn't inherently reject that the way Haskell and its ilk reject sequencing and state.

[bbcbasic → kazinator]

Haskell doesn't reject sequencing. f = g . h will require h is evaluated first.

[tome → bbcbasic]

h might not be evaluated at all! Consider

    h x = factorial x
    g x = 0

(but I agree that Haskell doesn't reject sequencing).

[bbcbasic → tome]

Yeah the IO monad will, but it isn't generally true of monads. Infant the maybe monad Will cease early on Nothing by design. So it is a brain shift.

[kazinator → bbcbasic]

> Haskell has excellent State support

Someone who understands where that support is and how to use it should rewrite atrocities like:

https://rosettacode.org/wiki/Assigning_Values_to_an_Array#Ha...

[codygman → kazinator]

I don't think that's so bad, it's just you are using a function instead of the usual built in indexing operator [0]. Here's something a bit more convenient using Data.Array.Lens[1].

    arr ^. ix 2

vs the original:

    readArray arr 2