Python becomes the most popular language

[PlainName]

So what exactly are you ranting about?

It is what he does. As treez couldn't help but thank, eti can only rant

[Cerebus]

Executive summary: Python is the Windows of programming languages.

Perhaps this is true in terms of popularity.
But it is definitely not true in terms of licensing. Python is free and open-source.

The whole "FOSS" baloney is meaningless, people parrot it like it's magic sauce.

The irony that we can only read your "enlightened" opinions because they have been posted on a platform that relies entirely on FOSS is no doubt completely lost on you.

[eugene]

Ha! Good point.

I challenge anyone to go a full day without making use of something running a linux kernel. (Which brings us full circle back to Nominal's comment RE: Python and MS Windows.)

[SL4P]

It’s a bit like the evolution of cars and drivers through the 80s…

Yes, you can be a driver without knowing anything about cars or engines.
or, you can study and understand the car and it’s mechanisms - and be a driver.

One of these two people will be a better operator of the car in unexpected situations, and can explain driving a lot better to their children, friends and others.

[Nominal Animal]

One of these two people will be a better operator of the car in unexpected situations, and can explain driving a lot better to their children, friends and others.

The problem I most often see in this kind of discussion, is more analogous to people discussing car behaviour on slick ice, when a long-haul trucker having a 40-year career in the Australian outback ridicules the entire discussion as fantasy because they certainly never had to deal with ice on asphalt, so it is impossible for it to occur to anyone else.

This is extremely common with those who have a long history in Windows use and no other OS experience, and with those who expect the vendor to provide a solution path for every conceivable problem.  In particular, they will ridicule the Unix philosophy, and ignore any arguments showing how it is still the most effective paradigm in e.g. high-performance computing, because it just doesn't fit their personal experience.  They will demand frameworks and cathedrals instead of modular libraries, because they find the responsibilities associated with freedom scary or difficult.  Similarly, they often make claims about various software licenses and international intellectual property law, based on something they believe (having perhaps heard it thirdhand at a coffee shop before), and if their opinion is shown to be bullshit, start spouting how only lawyers should be allowed to discuss this stuff online.  Qt licensing is a particular sore spot.

In short, it is better to just ignore the rants.  It's not like they're going to respond rationally anyway.

[brucehoult]

As a general thought regarding programming languages, and not specific to Python (although it definitely is concerned), I have a problem with languages that are tightly coupled with their implementation. This is wrong on many levels.

Yes, this is annoying, especially when they feel free to make seriously incompatible changes between versions so that old programs don't work on new versions.

I also dislike languages that are too inexpressive or too low performance to usefully implement the majority of their own libraries. It is possible to design high level expressive features in ways that don't force low performance implementation.

[Ed.Kloonk]

As a general thought regarding programming languages, and not specific to Python (although it definitely is concerned), I have a problem with languages that are tightly coupled with their implementation. This is wrong on many levels.

Yes, this is annoying, especially when they feel free to make seriously incompatible changes between versions so that old programs don't work on new versions.

This.

Even if there is a use_version_x param or whatever, nobody seems to use it. And then to build a interpreter that -could- deal with it at worst with a noisy warning but instead fatal errors out. 

It's as though they resurrected all the worst bits of winword *.doc obsolete versioning, DLL hell and syntax stupidity like it's some kind of competition or homage to MS. If the next version of Python shows up with a floating paper clip, I'm gunna do backflips.

[Cerebus]

As a general thought regarding programming languages, and not specific to Python (although it definitely is concerned), I have a problem with languages that are tightly coupled with their implementation. This is wrong on many levels.

Yes, this is annoying, especially when they feel free to make seriously incompatible changes between versions so that old programs don't work on new versions.

This.

Even if there is a use_version_x param or whatever, nobody seems to use it. And then to build a interpreter that -could- deal with it at worst with a noisy warning but instead fatal errors out. 

It's as though they resurrected all the worst bits of winword *.doc obsolete versioning, DLL hell and syntax stupidity like it's some kind of competition or homage to MS. If the next version of Python shows up with a floating paper clip, I'm gunna do backflips.

To be fair to Python, this business of producing a new version of the programming language itself every few weeks/months/each-year is not a Python exclusive "feature". Most of the new kid on the block programming languages do this, and to my mind it is an insane way to go about producing tools. Would anyone produce mechanical tools that had a new version every few months which required you to use, say, a version 4.3 screwdriver to insert/remove a version 4.3 screw? No one would try to do this with actual physical tools to a bunch of burly hammer wielding men for fear of serious bodily damage.

Moreover, the practice leads to a sense that everything is ephemeral, everything is in beta, nothing is built to last, nothing has passed the test of time, so why should you bother to produce anything stable, long lived and itself capable of passing the test of time with these tools?

[2N3055]

As a general thought regarding programming languages, and not specific to Python (although it definitely is concerned), I have a problem with languages that are tightly coupled with their implementation. This is wrong on many levels.

Yes, this is annoying, especially when they feel free to make seriously incompatible changes between versions so that old programs don't work on new versions.

This.

Even if there is a use_version_x param or whatever, nobody seems to use it. And then to build a interpreter that -could- deal with it at worst with a noisy warning but instead fatal errors out. 

It's as though they resurrected all the worst bits of winword *.doc obsolete versioning, DLL hell and syntax stupidity like it's some kind of competition or homage to MS. If the next version of Python shows up with a floating paper clip, I'm gunna do backflips.

To be fair to Python, this business of producing a new version of the programming language itself every few weeks/months/each-year is not a Python exclusive "feature". Most of the new kid on the block programming languages do this, and to my mind it is an insane way to go about producing tools. Would anyone produce mechanical tools that had a new version every few months which required you to use, say, a version 4.3 screwdriver to insert/remove a version 4.3 screw? No one would try to do this with actual physical tools to a bunch of burly hammer wielding men for fear of serious bodily damage.

Moreover, the practice leads to a sense that everything is ephemeral, everything is in beta, nothing is built to last, nothing has passed the test of time, so why should you bother to produce anything stable, long lived and itself capable of passing the test of time with these tools?

You have a point but it is actually in reverse: because mentality of ephemerality (sorry!) is the reason why they don't care. Old is shit and is there to be thrown away. There cannot be any merity given to the old, no compatibility or any kind of confession that old version was pretty damn good and these few things had to be fixed to make it perfect. You NEED to throw away and do it from the scratch..

And that brings the second point: What makes you think that software intellectual types consider it it a TOOL as you explain it. Software "tools" are measured by different merits. They will wax poetic about all kinds of theoretical concepts the new "tool" or language supports. Actual practicality, usability or productivity is not really a priority...

[tepalia02]

Not an expert. But I like python. It helped me a lot for Raspberry Pi based embedded system engineering projects.

[SiliconWizard]

I also dislike languages that are too inexpressive or too low performance to usefully implement the majority of their own libraries.

Yes, this is actually an interesting discussion in itself. Also true for the compilers.

Many general-purpose languages used to have their compilers and libraries written in their own language. Compilers are then bootstrapped in some way.
That is becoming rare these days. Sure you can say that for interpreted languages, this would probably not be practical. But interestingly enough, that's not just true for interpreted languages. Many newer programming languages have their compilers (and sometimes libraries) written in another language.

Even if the language never got popular, one seminal example IMO is Modula-3. Everything was written in Modula-3, from the compiler to tools to libraries, and the set of libraries was known to be of high quality. You can have a look at the project, which is seeing some revival lately: https://github.com/modula3/cm3

[SiliconWizard]

Moreover, the practice leads to a sense that everything is ephemeral, everything is in beta, nothing is built to last, nothing has passed the test of time, so why should you bother to produce anything stable, long lived and itself capable of passing the test of time with these tools?

This is actually a concerning trend that is plaguing the software industry in general, and has become the new norm, out of so-called productivity.
So it's not surprising at all that languages promoting this behavior are part of the trend, and have become very popular, backed by large corporations.

[SL4P]

From what I’ve seen over the last few years, it looks like Python is the 21st century BASIC.

I’ve used both, but honestly, like many languages both have strong points for quick application development, but are almost delusional for system or anything near-real-time or mission-critical.

I doubt you’d find any critical life support system in either.  They may exist, but I’d bet they’re not ‘certified’ or ‘verified’ by any responsible authority.

[mansaxel]

Money is a GIGANTIC motivator.

I agree about the motivator, but since you'll make more money by ignoring the bugs rather than paying programmers to fix them, the notion that closed source software somehow is better is pretty silly. It is made to a price, and it's more important that it got features than it is that it is fault-free. Sells better that way.

The highest quality operating systems are either extremely expensive (AIX et al) or free, like all the large BSD systems. Linux does not stand a chance, especially not since the Lennart started to get his code in distributions.

[eugene]

Another powerful motivator is the need for something that does not exist commercially. Obviously there's a lot of crap available for free. Nobody ever disputed that. But I frequently find myself using open source software that was developed by the people that use it. They developed it because they need it and were not satisfied with commercial options.

OpenFOAM is a good example of that. Researchers at Imperial College in London wanted a flexible and powerful tool for computational fluid dynamics. They created what would become OpenFoam. It was sold commercially briefly, but quickly was made open source and it continues to be developed and maintained entirely by people that use it. The project is overseen by the OpenFOAM Foundation, but improvements and features are added by people that need them. It works along with a set of other high quality open source tools for meshing and pre- and post-processing and is becoming the tool of choice for a growing number of researchers in CFD, even when commercial tools are available.

Another example is Blender. It was originally developed by an animation studio for internal use but was eventually made open source. Today it is used almost universally by everyone producing animation or realistic graphics. This includes game programmers and major movie productions. It is maintained entirely by people that need a high quality and powerful tool. No programmers are being paid by yearly license and support fees.

[PlainName]

Linux does not stand a chance, especially not since the Lennart started to get his code in distributions.

But but but... Linux, and especially systemd, is free. Therefore, by your argument, systemd must be better.

[nctnico]

As a general thought regarding programming languages, and not specific to Python (although it definitely is concerned), I have a problem with languages that are tightly coupled with their implementation. This is wrong on many levels.

Yes, this is annoying, especially when they feel free to make seriously incompatible changes between versions so that old programs don't work on new versions.

This.

Even if there is a use_version_x param or whatever, nobody seems to use it. And then to build a interpreter that -could- deal with it at worst with a noisy warning but instead fatal errors out. 

It's as though they resurrected all the worst bits of winword *.doc obsolete versioning, DLL hell and syntax stupidity like it's some kind of competition or homage to MS. If the next version of Python shows up with a floating paper clip, I'm gunna do backflips.

To be fair to Python, this business of producing a new version of the programming language itself every few weeks/months/each-year is not a Python exclusive "feature". Most of the new kid on the block programming languages do this, and to my mind it is an insane way to go about producing tools. Would anyone produce mechanical tools that had a new version every few months which required you to use, say, a version 4.3 screwdriver to insert/remove a version 4.3 screw? No one would try to do this with actual physical tools to a bunch of burly hammer wielding men for fear of serious bodily damage.

Moreover, the practice leads to a sense that everything is ephemeral, everything is in beta, nothing is built to last, nothing has passed the test of time, so why should you bother to produce anything stable, long lived and itself capable of passing the test of time with these tools?

Where it comes to Python, I have to agree with this. Over the years I have tried to install some Python based software but ran into many incompatibilities between versions and OS. Initially I had the impression that Python was easely portable and maintainable but the opposite is true. It is even worse compared to the DLL hell that plagued the older Windows versions. IMHO it is better to write an application in C++ using Qt or WxWidgets and link it statically to have a fighting chance of being able to install & run an application next year compared to using Python.

If you want to distribute a Python application, you have to hand-out pre-configured VM images.

Bottom line: Python is great to tinker a script together but it absolutely sucks for writing applications (unless you want to keep sinking money into software that is essentially finished).

[SiliconWizard]

Well, as far as I've seen over the years, every such promise of instant portability and "runs everywhere" has fallen short. Java is a prime example, not just Python. The same shit largely applies. If you don't embed your own, known to work with your app-JVM, chances are that users won't be able to run it properly, or will encounter various bugs.

[mansaxel]

Linux does not stand a chance, especially not since the Lennart started to get his code in distributions.

But but but... Linux, and especially systemd, is free. Therefore, by your argument, systemd must be better.

You troll! 

No, Price / Quality relationship is a quite non-linear equation. That is about as much as we can say. 

Anyway, I just took a peek at some Python code (desperately trying to get back to topic.), this time for Home Assistant to check the ARP table in a router.  My observations:

• Yes, the code is readable, but that is because all things that do something are strings for the interactive HMI (Human-Machine-Interface, the command line used to configure and troubleshoot the router) sent via a SSH connection emulation library. Basically a screen-scraper, the most fragile way of interprocess communication short of rumours.
• The approach chosen when fetching information is very simply put "monkey see, monkey do"; the code emulates what I'd do to go look manually. It is a cute but immature first step.
• The approach to adaptation to the network setup further is a very QnD one, no provision is made for anything beyond the most simple out-of-the-box, click-next-next-next-OK-reboot setup of a network.  This is no fault of Python, it is the usual case of assumptions made to give impressions of Magic. Most common in IOT and media servers, but not unheard of in other auto-configuring software systems.
• The proper way to get the ARP table out of a network element when machine is talking to machine is either the classic SNMP or the more modern NetConf/YANG model.
• There are Python libs for this too, but they're not used. Probably too much understanding of problem required.

Fast and wrong, Internet of Shit style. Not impressed.

Simply because it is easy to write does not mean it is easy to get right.

[DiTBho]

Fast and wrong, Internet of Shit style.

It must the new hipster hype.

Internet of smart things but in Fast and wrong Shit style.

It greatly sucks, but they are earning a lot of money on that *educational* internet of shit because it's supposed to *teach* something ... as you well summarized, the problem here is the fast and wrong shitty approach.

And Python has certainly been overused for the purpose.

[Picuino]

I have been using Sphinx in a Windows environment for years and have never had any compatibility problems with either the Sphinx package or any of the dependencies, which are updated automatically with pip.  I have had no problems with older installed versions of Python or when upgrading Python to newer versions.

I'm not saying there aren't problems with other packages, but I've never had problems with Sphinx.

https://www.sphinx-doc.org/en/master/

[Picuino]

In other cases I have seen recommended managers like conda to avoid inconsistencies between Python packages.
https://docs.conda.io/en/latest/

[Mattjd]

If you're having incompatibility issues with python you are

1.) Using a code from a bad project who isn't specifying their dependencies.
2.) Aren't familiar with how the various environment specification systems work and are blaming that instead of learning how to use the provided tools.

What do you individuals do in lower level languages for dependency management?

[nctnico]

If you're having incompatibility issues with python you are

1.) Using a code from a bad project who isn't specifying their dependencies.
2.) Aren't familiar with how the various environment specification systems work and are blaming that instead of learning how to use the provided tools.

You are stepping over one very important point here: from what I have been experiencing is that Python library / component developers are not making their software backwards compatible with 'older' OS versions. They assume you always upgrade to the latest & greatest which just isn't going to work in an engineering environment. Updating a system with a bunch of software packages installed can easely take a fulltime week of work for preparation & execution and still runs the risk of breaking functionality. There really needs to be a good reason to invest that amount of time (return on investment)!

So Python developers can specify the dependancies of their software just fine but the Python libraries simply won't install. IMHO Python is a dead end where it comes to commercial / professional application development. Look at Kicad for example which no longer runs on Windows 7 because the newer Python libraries don't support Windows 7. I'm having similar issues when trying to run Python software on Linux. That is just stupid. In contrast: When I compile a C++ program that uses the WxWidgets framework, it will run on any Windows version from Windows 95 to Windows 10 (and likely Windows 11) without needing to install any external libraries. That makes life a whole lot easier for my customers.

[Mattjd]

To complain that an OS which has officially reached its End of Life isn't support by a language and furthermore the open source community driving it, is quite ridiculous to say the least.

There's nothing stopping you from finding older versions of python and 3rd party packages that work on the older and End of Life OS'es, the source code for real building the wheel or conda package isn't just disappearing.


It seems like you want the latest and greatest python but not the OS? Seems hypocritical. Is there not an older version of Kicad to be used that is Windows 7 compatible?

Lastly if you are sending out software to 3rd parties you are most likely going to compile the python into a .exe which will include all the necessary 3rd party libraries, etc. This may not work how I think it does, and it wont in fact run on a old OS (hence your Kicad example).

Regardless I really don't see the complaint here.

EDIT:

Seems like we're perfectly capable with literally compiling python to work different OSes

https://pyoxidizer.readthedocs.io/en/stable/pyoxidizer_comparisons.html

You just have to use the correct executable creating library and include the necessary DLLs.

https://stackoverflow.com/questions/14747788/py2app-compile-app-for-older-mac-versions

Put in an issue with Kicad, or build it yourself. https://github.com/KiCad