These thoughts were born when I was thinking about Python2-Python3 revolution and bloat of C++. Python and C++ use different approaches to versioning and both of them have their flaws. These flaws have so dramatic effects that I think that both approaches are not suitable for Panda.
Python’s revolution
I call it revolution because there were no easy way to port programs written with Python2 to Python3 (Python3). This caused huge split in Python community and many popular python libraries got Python3 support years later Python3’s initial release. And Python2 is still supported. Almost all popular libraries still (as of January 2019!) support both Python2 and Python3. This dramatically slows down both language development and library development, because developers need to support double set of features.
It is just my “humble” opinion, but this python revolution is one of the reasons why python is still not the most popular language in the world, because where JS developers create two frameworks, python developers can create only one with support of two pythons (now it is not entirely true, because Python3’s codebase is more rich than Python2’s; just 5-9 years passed…).
Also this duality of python scared off many developers, who would use python for their projects in every other situation. Heck, back in 2013 there were a lot of holy wars between python2 and python3 adepts. It was very unclear which version to choose for new projects and it cost a lot of time and nerves to migrate from python2 to python3 later, when usage of Python3 got more advantages.
I hope that changes between Python3 and Python4 will not be so dramatic and smooth evolution will be possible.
Bloat of C++
Another extreme is C++ (same true for JS and some other languages, but let’s stick with JS). C++ never drops any features. NEVER. C++ is some kind of black hole of programming languages for features. If feature gets in C++, it stays here forever. You can’t drop macros support, though there is no need for it in modern C++. You can’t drop pre-increment (i.e. ability to increment variable by ++i
instead of i++
) which would increase language convenience.
Modern C++ is overwhelmed with features and it is hard to create new (even experimental) compilers for this language because of its monstrous weight. Because of C++'s monstrosity we didn’t get support of modules in 2017. It was just too hard to find a convenient implementations for them and shoot out major corner cases. I bet that “speed” of C++ will decrease even further and sooner or later Rust will “eat” it.
How does it concern Panda?
Panda has a small community, every new member is precious. Newcomers shouldn’t be confused which version to choose when they start their new projects and it should’n cost them a lot of time if their choice was bad. Actually, there should be only one obvious choice: latest stable version. Despite that, every new revolution will spawn new Panda and will cause a lot of problems to those users, who decided to stick with older versions. It may cause them to abandon Panda and I think that it is undesirable. It also will draw developers’ attention to support different old versions, which means that they will have less time to improve Panda.
The way of C++ is undesired too, though it is less painful for end users. The reason is the same: it slows down development. If the development slow down could be avoided it should be avoided. Couldn’t it?
True Evolutionary Approach
Since improvement is not only adding new required features, but also removing redundant features, there are no improvement without pain for both end users and maintainers. But I think that evolutionary approach could be applied. For example, current version is 1.10.x and there is set of features {A, B, C}
. Version 1.11.x is in development and maintainers have thoughts of version 2.0.0. Let’s say that during development of v1.11.x, maintainers understood that it would be good to replace feature B
with feature D
, because D
is faster and more convenient.
C++ way is to just add feature D
in version 1.11.x and never drop feature B
no matter what. Python way is to add feature D
in version 1.11.x and drop feature B
in version 2.0.0. Even with blog post, change lists and other notifications, I think it would be a bad surprise for users of feature B
when it would be dropped.
Evolutionary approach would be to deprecate feature B
in v1.11.x, add feature D
in v1.11.x and drop it in v1.13.x (for example). Deprecation should be as painful for end users as possible because maintainers want to discourage them from usage feature B
, and not just inform that this feature would be dropped in v1.13.x. How to do it is up to discussion. When to finally drop feature B
and how long they should coexist with feature D
is up to discussion too. Anyway, it is more a state of an art than an actual science.
Well, what do you think, folks?