6 ms·

You can, but in Haskell you can enlist the compiler's help to prove that everything is completely airtight. This property continues to hold, even as the applic

You can, but in Haskell you can enlist the compiler's help to prove that everything is completely airtight. This property continues to hold, even as the application and the tests are modified by developers who do not even fully know what sort of effects they should otherwise be concerned with. For instance, most programming platforms give you pretty ready access to a pseudo-random number generator. This is great until some well-intentioned new hire checks in code someplace that uses it to instrument something 1 out of 1000 runs. We can't have this problem in Haskell and we don't have to spend any ongoing code review hours on it. It's gone.

pron 11y ago
Yep, it's also great that we can enlist the runtime's help to do the same thing in Java (or any other JVM language) and support use of third-party libraries (the Haskell approach places a pretty severe burden on the code) and make it even more airtight (IIANM you can't prevent unsafePerformIO): We just disable IO by enabling the security manager with a "no-IO" policy[1]. So it's less intrusive, more widely applicable and more airtight than the Haskell approach. True, the security manager does not limit access to the random-number generator, but this, too, can be done with an extra bit of one-time effort, by injecting a security check into the random number generator's seed generation method (we still want to allow fixed seeds like StdGen). [1]: Or a finer-grained policy of "no IO except for logging".
- chongli 11y ago
  An application which does "no IO" does nothing other than make the computer get hot. Why even run it?
  - pron 11y ago
    Why, for testing. The calls to IO are replaced with calls to mocks which are then used to verify IO behavior. It's like replacing the IO monad with a type that doesn't actually do IO, only it doesn't require the code to change, so it works even for third-party code. You can then use the security manager during the test to verify that all IO calls are indeed mocked.

pron 11y ago

Yep, it's also great that we can enlist the runtime's help to do the same thing in Java (or any other JVM language) and support use of third-party libraries (the Haskell approach places a pretty severe burden on the code) and make it even more airtight (IIANM you can't prevent unsafePerformIO): We just disable IO by enabling the security manager with a "no-IO" policy[1]. So it's less intrusive, more widely applicable and more airtight than the Haskell approach. True, the security manager does not limit access to the random-number generator, but this, too, can be done with an extra bit of one-time effort, by injecting a security check into the random number generator's seed generation method (we still want to allow fixed seeds like StdGen). [1]: Or a finer-grained policy of "no IO except for logging".

chongli 11y ago
An application which does "no IO" does nothing other than make the computer get hot. Why even run it?
- pron 11y ago
  Why, for testing. The calls to IO are replaced with calls to mocks which are then used to verify IO behavior. It's like replacing the IO monad with a type that doesn't actually do IO, only it doesn't require the code to change, so it works even for third-party code. You can then use the security manager during the test to verify that all IO calls are indeed mocked.