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. You can have "application" monad in Haskell (read), the same in Python: most Python programmers create some Application class. 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). You can not change state anywhere, you can only send message. 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... 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 ;)
Did you see the recent "default mutable arguments" post? https://lethain.com/digg-v4/
Yeah, the "default parameter is an empty list but that's then going to be updated across invocations" classic. Other languages have made the same mistake. Default data needs to be either immutable or recreated on each call. Such mistakes can be mitigated, but they cannot be fixed while staying backwards-compatible.
Python actually did an incompatible switch from 2 to 3, but for some reason Guido didn't fix the above two, or some other things (such as Python's broken idea of multiple inheritance, or the horribly overcomplicated way annotations work). Python is nice for small tasks. If you accept its invitation to extend it you get fragility (due to the inability to define hard constraints so whatever you extend will violate *somebody's* assumptions), and if you scale to large systems you get fragility as well (because Python modularization is too weak).
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...
Well, enough of the off-topic thing here.
On 07/12/2018 07:58 PM, Brett Gilio wrote:
Python is poison, indeed. ;)
Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.