Wounded Pride and the Python Community

All technology enthusiasts have favorite technologies, languages, operating systems, hardware etc. With somebody says something about our favorite technology we easily get defensive.

When somebody new to macOS complains about maximize windows does not work they way it does in Windows, it may annoy me, because in my mind macOS does it in a smarter and better way.

But my response should never be RTFM. This is a real experience to a Windows user new to macOS. It gives useable information about what would trip up a Windows user new to macOS. Sometimes it may expose some things which are not that user friendly in macOS even as long time users we may have come to love those very characteristics.

One can see the same responses in all sorts of progamming languages. Most users are somewhat protective of their language of choice. But Python developers seems to stand out. One can find many discussions of Python online and the Python developers can at times react with a sort of angry wounded pride.

There is perhaps some logic to this. Python is a celebrated language. It is dearly loved for its ease of use, clarity, philosophy and versatility. People who program love Python, in a way that say Java developers never could.

The closest thing to this emotion would probably be LISP developers. It is an even older language and thus many of the kinds of problems plaguing Python exists in an amplified form in the LISP community. A beginner to LISP will have to navigate even more arcane choices of tools, libraries and dialects than what is the case with Python. Which LISP should I use? SBCL? Then there are different package systems, and a myriad of different libraries. There are different editors, different forms of REPLs etc.

Sometimes it isn’t merely about age but perhaps more about popularity. When switching from iOS development to Java development my first impression was the sheer size of the Java community. The myriad of tools and IDEs. Setting up an Android development environment was a significantly larger task than doing it for iOS despite the fact that Objective-C is actually an older language than Java.

A confirmation that things like that matters was given when I trained a young developer who already knew Java to develop for iOS. Despite Objective-C being a bit of an odd language, she found iOS development a lot easier to do. A lot of that was undoubtedly down to the much narrower sets of tools and options more strictly curated by Apple.

User Experience: Less is More

Python strengths are exactly multiple number of implementations of interpreter to let’s say speed up of things or making things easier for specific software eco system or niche software domain.

If you have read a bit more of my articles you may have noticed that a number of my writing in on the topic of user interface design and usability. I am not purerly a technologist. And I see this culture crash frequently between technologists and user experience people.

To a technologist or engineer, more is always more. To someone focused on user experience, less is often more. If more was always more, then there probably would never be a language better or more impressive than C++. You get the whole kitchen sink. But it is a faustian bargain. There is a considerable price to pay for all of this. That is usability.

What you price as an expert Python developer may be a stumbling block to a beginner. In user interface design we know one of the easiest ways to destroy usability is to approach it with the attitude “I will just add this one more option. It may come in handy later.”

Concurrency and Parallelism

For example, you might point out that GIL is problem for threading in cPython. Do you know what is happening on that front in most recent versions of language or what will soon emerge from prospective of multiprocessing in Python.

I know a lot of progress has been made in that area. But a lot of that happened since I wrote the article and it is rather beside the point. The point is that Python community had to endure this for quite a number of years and considerable effort went into solving it.

Do we even know what is the difference between thread and process, how could you do things both ways without really affecting performance.

A very strange question to ask. Perhaps if I was a JavaScript developer or used Visual Basic it may have made sense. But you don’t end up using an obsure language for high performance computing if you never heard about threads and processes.

How about coroutines and threads, know the difference? What about concurrency and parallelization? How about SIMD vectorization? Julia can do all of these things and in combination. You can run multiple threads on multiple processes on multiple machines using SIMD vectorization. That is why Julia e.g. is used for the Celeste project run 1.3 million threads on 9,300 Knights Landing (KNL) nodes, achieving peak performance of 1.54 petaflops.

Like I said before, it is pointless to tell everyone that you like Julia over Python.

As we speak there are thousands of people writing subjective opinions on some technology they are just trying out. Many people find that useful. Are you going to run after all of them and tell them to become experts before writing anything critical of something you love?

My writing is take it or leave it. I don’t write for your pleasure of for anybody else’s pleasure for that matter. I write for my own pleasure. If somebody enjoy my writing or get something positive out of it, that is a bonus.

Do your thing in Julia, pass on making statements on Python and start asking questions about Python if you really want to master it …

I am not really looking to be a Python master. I am a tourist. I come on visit and describe what I see.

Machine Learning and Python

The worst part is that in domain of ML, AI and related tools Python simply does best of any language, and that domain is hardest to keep up from prospective of API’s.

Depends entirely on what you mean by best. Does Python have some of the broads usage and most industry commitment? Sure. Is this because Python is a language well designed for ML and AI? Absolutely not. This is more an attribute of age, community and libraries available.

Evaluated alone, Python is a rather poor language for this thing in fact. If you look at symbolic AI, e.g. LISP will excel over Python and that is purely down to language design.

Without C/C++, Python is rather useless in the machine learning domain. And the two-language approach used by Python with ML is quite a problematic choice.

ML Frameworks like TensorFlow and PyTorch are really about manually building up abstract syntax trees which one then performs automatic differentiation on using the chain rule.

This is actually a rather kludgy solution. One is performing manually and explicitly what a compiler already does: Building syntax trees to be evaluate.

If you got an algorithm written in Python which you want to train using deep learning techniques, you cannot use the algorithm as it is. No you have to go through all the logic and rewrite everything as an elaborate manually constructed syntax tree.

Not to mention you will most likely hit the wall if you took any complex code, as TensorFlow and PyTorch have limited support for control flow statements such as loops, and if-statements.

This is in stark contrast to Julia, where you can actually let the compiler to the job. Just take regular Julia code and let Flux do its magic on it. You get automatic-differentiation without any need to do extensive manually rewrite your code.

You can take e.g. a whole raytracer and do deep learning on it. You can solve a differential equation using machine learning.

This is why Google is making big investments in Swift to build automatic-differentiation into the language. If Python could deliver this they would not have been spending this massive effort into doing it.

This is an important thing for the field. That large investments are going into this shows that people with big money bags have deemed this important. Just because Python is big today does not mean it is the way of the future.

When the first diesel trains or electric trains arrived in small numbers should we have deemed them inferior to steam locomotives just because they commanded a tiny share of the market? Everything begins with small steps. You got to analyze the technology. You cannot just look at where the momentum or buzz currently is.

Why Write About Julia and Compare to Python?

Julia is a very new and promising language which few people have heard about. To get an impression of new technology it is often useful to compare with what people already know. There are many ways of doing this. This article was an out-of-the-box experience. But it is hardly my only writing on the topic. If you want writing focused on more concrete issues, here is some of my other writing:

• Explaining advantages of multiple dispatch by comparing a Julia solution to a Python solution for implementing custom units.
• Type annotations in Julia and Python.
• Null values in Julia and Python.
• String interpolation in Julia and Python.
• Generators and Iterators in Julia and Python.
• Coroutines and Tasks in Julia and Python.

Many people who begin using Julia have a Python background. They typically switch to Julia because it is offering the performance they need or in many cases the ease of use they need. E.g. doing machine learning is often easier in Julia. And in some areas like differential equations Julia has the best packages bar none.