<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=utf-8"><meta name=Generator content="Microsoft Word 15 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:#954F72;
text-decoration:underline;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0cm;
margin-right:0cm;
margin-bottom:0cm;
margin-left:36.0pt;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
.MsoChpDefault
{mso-style-type:export-only;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
--></style></head><body lang=RU link=blue vlink="#954F72"><div class=WordSection1><p class=MsoNormal><span lang=EN-GB>I agreed with most of your the arguments.<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-GB>Yes, Python has serious problem with modules locking mechanism in multi-process apps. And GIL. But it’s trade-off. And also not all Python implementations have GIL.</span></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><span lang=EN-GB>> </span>"Real programmers can write FORTRAN code in any language."<o:p></o:p></p><p class=MsoNormal><span lang=EN-GB>The same with my example of read monad usage </span><span lang=EN-GB style='font-family:"Segoe UI Emoji",sans-serif'>😉</span><span lang=EN-GB> No problem to avoid manipulation of global state in a way which leads to spaghetti-code.<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-GB>> </span>Once the FSM holds more than a dozen states, these advantages evaporate.<o:p></o:p></p><p class=MsoNormal><span lang=EN-GB>This is point only where I can not agree. I used FSM with hundreds states/transitions. It was automatically generated, I only check them. Also I know that in car automatics FSM are widely used (BMW, Mercedes, Audi). Also it’s using in software for space industry widely. My IMHO is: FSM is most reliable way to do soft without bugs. Also it’s easy to verify them (for example, with transitions’ assertions)</span></p><p class=MsoNormal><o:p> </o:p></p><div style='mso-element:para-border-div;border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm'><p class=MsoNormal style='border:none;padding:0cm'><b>From: </b><a href="mailto:jo@durchholz.org">Joachim Durchholz</a><br><b>Sent: </b>13 июля 2018 г. 22:08<br><b>To: </b><a href="mailto:haskell-cafe@haskell.org">haskell-cafe@haskell.org</a><br><b>Subject: </b>Re: [Haskell-cafe] What is your favourite Haskell "aha" moment?</p></div><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Am 13.07.2018 um 09:54 schrieb PY:</p><p class=MsoNormal>> 13.07.2018 09:47, Joachim Durchholz wrote:</p><p class=MsoNormal>>> Am 13.07.2018 um 01:40 schrieb Tony Morris:</p><p class=MsoNormal>>>> On python, we are fixing it (WIP):</p><p class=MsoNormal>>>> https://github.com/qfpl/hpython</p><p class=MsoNormal>>><o:p> </o:p></p><p class=MsoNormal>>> Some poisonous aspects of Python are unfixable.</p><p class=MsoNormal>>> E.g. having declarations as program-visible update to a global state </p><p class=MsoNormal>>> causes all kinds of unnecessary pain, such as having to deal with </p><p class=MsoNormal>>> half-initialized peer modules during module initialization.</p><p class=MsoNormal>>><o:p> </o:p></p><p class=MsoNormal>> I never understand that point. Mostly Python programs have not global </p><p class=MsoNormal>> state, only global constants.</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Well, try doing work on SymPy then.</p><p class=MsoNormal>I did. And I know for a fact that your idea is completely wrong; Python </p><p class=MsoNormal>has a lot of global state, first and foremost all its modules and the </p><p class=MsoNormal>data that lives inside them.</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>> Also OOP has long been solved "global state" problem, for example,</p><p class=MsoNormal>> Smalltalk (similar idea you can find in Erlang): state is hidden</p><p class=MsoNormal>> behind some FSM which is represented as class (process in Erlang).</p><p class=MsoNormal>No amount of TLAs will solve the issues with mutable global state.</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Actually the Digg story was having mutable global state, in the form of </p><p class=MsoNormal>a default parameter. Now that's insiduous.</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>> You can not change state anywhere, you can only send message.</p><p class=MsoNormal>If the responses depend on the history of previous message sends, you </p><p class=MsoNormal>have mutable state back, just by another name.</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>> FSM guards you from any errors. Even more, FSM-style is super safe and </p><p class=MsoNormal>> robust: you can visualize its behavior, to develop it very quickly, to </p><p class=MsoNormal>> debug it easy, final code usually does not contain errors even...</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>This all holds only for trivial FSMs.</p><p class=MsoNormal>Once the FSM holds more than a dozen states, these advantages evaporate.</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>> Even I can imagine read monad with big record inside with a lot of </p><p class=MsoNormal>> fields, flags, etc and to get absolutely the same spaghetti code with </p><p class=MsoNormal>> flags manipulation and testing in Haskell, but under monad ;)</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>"Real programmers can write FORTRAN code in any language."</p><p class=MsoNormal>Sure.</p><p class=MsoNormal>Except that it's not idiomatic.</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>> Interesting here is that there are a big enterprise products written in </p><p class=MsoNormal>> Python and they are very useful: </p><p class=MsoNormal>> https://www.codeinstitute.net/blog/7-popular-software-programs-written-in-python/ </p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Sure. Except they do not use some features, such as lists in default </p><p class=MsoNormal>parameters, or face the consequences (as the Digg story demonstrates).</p><p class=MsoNormal>Which means that this feature is conceptually broken. Except Python </p><p class=MsoNormal>can't fix it by mandating that default parameters need to be read-only, </p><p class=MsoNormal>which is impossible because Python has no hard-and-fast way to mark </p><p class=MsoNormal>read-only objects as such. (Read-only means: ALL function calls must </p><p class=MsoNormal>ALWAYS return the same results given equal arguments. With additional </p><p class=MsoNormal>constraints on argument behaviour vs. constness, but that's a pretty big </p><p class=MsoNormal>can of worm to define properly.)</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Also, such companies use extra-lingual process to get the modularization </p><p class=MsoNormal>under control. Such as conventions, patterns, style guidelines - and woe </p><p class=MsoNormal>to the company where a programmer accidentally broke them.</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Finally, that "but large software IS successfully written in unsuitable </p><p class=MsoNormal>languages" argument never held water. Entire operating systems have been </p><p class=MsoNormal>written in assembly language, and are still being written in C. Which is </p><p class=MsoNormal>a horrible misdecision from a reliability perspective, but it's being </p><p class=MsoNormal>done, and the inevitable security holes are being duct-taped to keep the </p><p class=MsoNormal>infrastructure limping along.</p><p class=MsoNormal>Which the large companies are doing, too. They just make enough money to </p><p class=MsoNormal>keep that infrastructure going. The same goes for Linux BTW, they have </p><p class=MsoNormal>enough paid^Wsponsored engineers to solve all the problems they're having.</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>The Haskell community does not have the luxury of excess engineers that </p><p class=MsoNormal>can hold all the ripped-up steel together with duct tape.</p><p class=MsoNormal>_______________________________________________</p><p class=MsoNormal>Haskell-Cafe mailing list</p><p class=MsoNormal>To (un)subscribe, modify options or view archives go to:</p><p class=MsoNormal>http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe</p><p class=MsoNormal>Only members subscribed via the mailman list are allowed to post.</p><p class=MsoNormal><o:p> </o:p></p></div></body></html>