Hi Marcel, I have read through the article and it seems to me that all of the problems described boil down to one important point: use the right tool for the right job. Python is probably not the best language for developing large, complex systems (although there are such systems). Most (or all?) of the concerns that Murthy raises (dynamic typing, support for multithreading, performance, Python2/3, encapsulation) speak to that. He is not wrong about any of the points, but it could be said that he is expecting too much. We don't expect a carpenter with a hammer to build an entire apartment building, and we don't expect a big construction company to build a coffee table.
Python does have many desirable features: it is easy to learn and the code is relatively clear. It is available on most platforms (I can run it directly on my phone), and it is easy to port to new platforms. There are many things that Mathematica can do that Python can't, and vice versa. Right tool/right job. I have often used Python to build prototypes to see if an algorithm works, but then I use a more efficient language (like Java or C) for the "real" implementation. Out of interest, Mathematica itself is written in C, C++, and Java, and consists of a few million lines of code. Python has several implementations; the "reference" implementation is CPython which is written in C and consists of ~540,000 lines of code. Because Python is open-source, it has the strengths (many contributors) and weaknesses (more difficult to coordinate development) that comes from this paradigm. As far as the documentation is concerned, Python is considered a well-documented language. Of course, individual libraries may not be, but as it happens, pyeda has good documentation (http://pyeda.readthedocs.io/en/latest/). I think you may just have been unlucky not to have found it. I think your case illustrates the Python/Mathematica issue well: you found a job for which Mathematica was not the perfect tool and you used Python. At the end of the day, both M & P have their place. For example, we probably won't use either to teach Introduction Computer Science soon, because they both lack features that we expect our students to be familiar with at the end of their first year. Prof Jaco Geldenhuys Medeprofessor: Rekenaarwetenskap | Associate Professor: Computer Science Fakulteit Natuurwetenskappe | Faculty of Science e: g...@sun.ac.za | t: +27 21 808 4232 | a: Algemene Ingenieurswese Gebou A519 | General Engineering Building A519 <https://www.facebook.com/stellenboschuniversity> <https://twitter.com/StellenboschUni> <https://www.instagram.com/stellenboschuni> <https://www.linkedin.com/edu/school?id=19873&trk=tyah&trkInfo=clickedVertical:school,clickedEntityId:19873,idx:3-1-6,tarId:1478079024397,tas:stellenboschu> <https://www.youtube.com/user/StellenboschUni> <http://www.sun.ac.za/> On 2018/02/20, 19:11, "Wild, Marcel, Prof <mw...@sun.ac.za>" <mw...@sun.ac.za> wrote: I scarcely know Python, and I have no intention delving into it further. I was forced to use Python because it features binary decision diagrams, which MATHEMATICA doesn't. Coming from Mathematica the account of Nathan Murphy reads like a nightmare. The one point that stroke me the most was the schism between Python 2 and 3. No such thing with Mathematica: All its 11 or more versions are fully compatible, I never experienced any problems in this regard. Another point is the bad online help provided to "teach yourself" Python. For instance, it took me more than an hour to find out how to negate a Boolean variable, whereas in Mathematica you would just type "Negation" in the Wolfram Documentation search window, and get the information you need. I know one pays for Mathematica whereas Python is open source, but I've come to realize now that this money is very well spent! Question: Apart from a few commands not available in Mathematica, such as expr2bdd, is there really any domain of computation where Mathematica is inferior to Python? Marcel -----Original Message----- From: Python-list [mailto:python-list-bounces+mwild=sun.ac...@python.org] On Behalf Of bartc Sent: 19 February 2018 02:35 PM To: python-list@python.org Subject: Re: Are the critiques in "All the things I hate about Python" valid? On 19/02/2018 02:59, Chris Angelico wrote: > On Mon, Feb 19, 2018 at 1:14 PM, bartc <b...@freeuk.com> wrote: >> How would even a type for the odd numbers from 1 to 10 inclusive work? >> (That, a type consisting of one of the values in {1,3,5,7,9}.) Would >> they be ordered or unordered? Can I do arithmetic with them: will 3*3 >> work, but not 3*5? > > The type is "positive odd number below ten" and could be written as > int(1..9|1%2). That is an orderable type; you can say that 3 < 7, for > instance. And yes, arithmetic would be defined just fine; Sometimes, the reason for creating a special numerical type is precisely so you can't do arithmetic on them, if it's not meaningful for the type. So the special type of the values 65..90 might not allow the type be multiplied or divided, or added to itself. Because they represent characters A..Z. Or house numbers. Or the age of pensioners. (You'd need to convert to ordinary integers, is that is allowed.) there's no > requirement for the result of an operation to have the same type as > its inputs: > >>>> 5 / 2 # two integers > 2.5 Try that when the type of {1..13} represents playing card ordinal values. Type systems get rapidly very complicated when you have to deal with arbitrary sets of values and with arbitrary rules of interaction. Someone has to devise a programming language to allow all that without tying itself up in knots. Someone else has to program in it. And someone else has to try and understand it! Ones like C++ has already tied itself itself up in knots just doing the basics; I'm not sure how it would handle even my 1,3,5,7,9 type. But Python has classes and can do some of this stuff; how would it handle a numeric type that is constrained to be whole numbers within 0..9 inclusive? -- bartc -- https://mail.python.org/mailman/listinfo/python-list The integrity and confidentiality of this email is governed by these terms / Die integriteit en vertroulikheid van hierdie e-pos word deur die volgende bepalings gereël. http://www.sun.ac.za/emaildisclaimer -- https://mail.python.org/mailman/listinfo/python-list
