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