[Haskell-cafe] What is your favourite Haskell "aha" moment?

[Joachim Durchholz]

Am 13.07.2018 um 09:54 schrieb PY:
> 13.07.2018 09:47, Joachim Durchholz wrote:
>> Am 13.07.2018 um 01:40 schrieb Tony Morris:
>>> On python, we are fixing it (WIP):
>>> https://github.com/qfpl/hpython
>>
>> Some poisonous aspects of Python are unfixable.
>> E.g. having declarations as program-visible update to a global state 
>> causes all kinds of unnecessary pain, such as having to deal with 
>> half-initialized peer modules during module initialization.
>>
> I never understand that point. Mostly Python programs have not global 
> state, only global constants.

Well, try doing work on SymPy then.
I did. And I know for a fact that your idea is completely wrong; Python 
has a lot of global state, first and foremost all its modules and the 
data that lives inside them.

> Also OOP has long been solved "global state" problem, for example,
> Smalltalk (similar idea you can find in Erlang): state is hidden
> behind some FSM which is represented as class (process in Erlang).
No amount of TLAs will solve the issues with mutable global state.

Actually the Digg story was having mutable global state, in the form of 
a default parameter. Now that's insiduous.

> You can not change state anywhere, you can only send message.
If the responses depend on the history of previous message sends, you 
have mutable state back, just by another name.

> FSM guards you from any errors. Even more, FSM-style is super safe and 
> robust: you can visualize its behavior, to develop it very quickly, to 
> debug it easy, final code usually does not contain errors even...

This all holds only for trivial FSMs.
Once the FSM holds more than a dozen states, these advantages evaporate.

> Even I can imagine read monad with big record inside with a lot of 
> fields, flags, etc and to get absolutely the same spaghetti code with 
> flags manipulation and testing in Haskell, but under monad ;)

"Real programmers can write FORTRAN code in any language."
Sure.
Except that it's not idiomatic.

> Interesting here is that there are a big enterprise products written in 
> Python and they are very useful: 
> https://www.codeinstitute.net/blog/7-popular-software-programs-written-in-python/ 

Sure. Except they do not use some features, such as lists in default 
parameters, or face the consequences (as the Digg story demonstrates).
Which means that this feature is conceptually broken. Except Python 
can't fix it by mandating that default parameters need to be read-only, 
which is impossible because Python has no hard-and-fast way to mark 
read-only objects as such. (Read-only means: ALL function calls must 
ALWAYS return the same results given equal arguments. With additional 
constraints on argument behaviour vs. constness, but that's a pretty big 
can of worm to define properly.)

Also, such companies use extra-lingual process to get the modularization 
under control. Such as conventions, patterns, style guidelines - and woe 
to the company where a programmer accidentally broke them.

Finally, that "but large software IS successfully written in unsuitable 
languages" argument never held water. Entire operating systems have been 
written in assembly language, and are still being written in C. Which is 
a horrible misdecision from a reliability perspective, but it's being 
done, and the inevitable security holes are being duct-taped to keep the 
infrastructure limping along.
Which the large companies are doing, too. They just make enough money to 
keep that infrastructure going. The same goes for Linux BTW, they have 
enough paid^Wsponsored engineers to solve all the problems they're having.

The Haskell community does not have the luxury of excess engineers that 
can hold all the ripped-up steel together with duct tape.