Python becomes the most popular language

[nctnico]

Regardless I really don't see the complaint here.

I guess you have never tried to actually use a computer then; otherwise you'd actually understand the problem. You completely missed / ignored the point about how difficult and time consuming it is in the real world to update a working system (with dozens of software packages installed) to a newer OS. On top of that, there is quite a bit of engineering software out there that doesn't work on newer OSses. Xilinx -for example- has taken a couple of years before they published a version of their ISE 14.7 software suite that can run on Windows 10.

[madires]

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.

Windows 7 ESU runs until January next year. Another fact is that a lot of special applications are running on older OS versions because of different reasons, such like certifications (e.g. medical imaging) or expensive legacy hardware (industrial or scientific stuff).

[ve7xen]

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.

I'm not really sure why you think this has anything to do with Python. Taking the 'wrong' high-level approach to the problem is a language-agnostic issue, and if anyone is to 'blame' for it, it's the software developer not the language developer.

Specifically though, Home Assistant as far as I know doesn't provide anything native to 'check the ARP table in a router', and I'm not quite sure what the use case for this would be in that application in the first place. So you're talking about some random dude's third-party addon to a piece of software that happens to be written in Python but is not associated with the Python team. It's also in the name - Home Assistant is for use in homes, and most home networking equipment doesn't implement SNMP, let alone netconf. Finally, HA does in fact include an SNMP poller in core.

I don't think this is a fair assessment.

[mansaxel]

I'm not really sure why you think this has anything to do with Python. Taking the 'wrong' high-level approach to the problem is a language-agnostic issue, and if anyone is to 'blame' for it, it's the software developer not the language developer.

Specifically though, Home Assistant as far as I know doesn't provide anything native to 'check the ARP table in a router', and I'm not quite sure what the use case for this would be in that application in the first place. So you're talking about some random dude's third-party addon to a piece of software that happens to be written in Python but is not associated with the Python team. It's also in the name - Home Assistant is for use in homes, and most home networking equipment doesn't implement SNMP, let alone netconf. Finally, HA does in fact include an SNMP poller in core.

I don't think this is a fair assessment.

Oh, there's some merit to the observation that bad coding will prevail regardless of language. Anything I write is testament to that.

OTOH, Python shows up a bit more often than others in those situations. I think we need to test this observation against time; for it is always so that the language du jour attracts morons.

On a side note; if there's a SNMP poller in HA, why oh why did they not use it?

[Nominal Animal]

the language du jour attracts morons.

True, because most human beings are morons in the first place.  (In the olden days 'moron' had a specific meaning, which only applied to about 2% of the population.  I define the term as "unable, unwilling, or reluctant to apply logical or rational thinking in ordinary everyday situations, and relying on repetition, habit, instincts, or emotions instead".)

Which leads to a genuine question: should we even consider the moron-written code when comparing practical uses of programming languages?

Or more generally, when looking at how programming languages are used and can be used – for example, to evaluate which language(s) one should consider for some particular project – should one consider all extant projects, or only a subset of projects?  (Well, only a subset, obviously, as there is too much code available already for all of it to be considered; but which subset?  Which subsets should obviously be discarded?)  What metric to use for comparison?

This might be considered a philosophical question, but I don't want to touch those with a ten-foot pole excluding a match and some gasoline.  Instead, I am interested in the purely practical aspect, say a software designer/architect with a new product as a goal.  (One has to consider what kind of developers are available, what kind of skill levels the team can afford, and so on.)  Or, say a hobbyist, considering which language to learn to create specific kinds of programs.

As I've ranted and explained sufficiently already, "popularity" is definitely not a metric I consider useful.  Also, I don't think the worst examples should be considered at all.  I think that it is important to consider only software that is widely used, or generally accepted as "acceptable quality".

[ve7xen]

OTOH, Python shows up a bit more often than others in those situations. I think we need to test this observation against time; for it is always so that the language du jour attracts morons.

I really think you need some sort of citation if you're going to make that claim. But it also stands to reason that the most popular language is also the most commonly misused, it will be the one that most beginners tend toward, and just by numbers will have the largest quantity of bad examples, and the most visibility. Some languages really do tend towards bad implementation because they make correct implementation hard (see PHP), but I would really take issue with claiming that of Python. The language is quite sane, doesn't really hinder good design, and doesn't provide an excessive amount of footguns.

I would also say that basically by definition, the most popular language can't be the 'language du jour' which implies relative newness, which isn't true of Python, it's been entrenched in its segment for a long time now. I'd say this applies more to Golang or Rust at this point.

On a side note; if there's a SNMP poller in HA, why oh why did they not use it?

Presumably the target device did not implement SNMP or they wanted to use an alternative method for some reason (more functionality? a device-specific alternative to the universal SNMP?). Assuming you want to do presence detection, it's built-in, just point it at the ARP OID: https://www.home-assistant.io/integrations/snmp/#precense-detection . I do find with HA that finding the best integration for a given task is not always trivial...

[nctnico]

the language du jour attracts morons.

True, because most human beings are morons in the first place.  (In the olden days 'moron' had a specific meaning, which only applied to about 2% of the population.  I define the term as "unable, unwilling, or reluctant to apply logical or rational thinking in ordinary everyday situations, and relying on repetition, habit, instincts, or emotions instead".)

Which leads to a genuine question: should we even consider the moron-written code when comparing practical uses of programming languages?

I don't think so. I've seen poor programming in every language I have come across.

[mansaxel]

On a side note; if there's a SNMP poller in HA, why oh why did they not use it?

Presumably the target device did not implement SNMP or they wanted to use an alternative method for some reason (more functionality? a device-specific alternative to the universal SNMP?). Assuming you want to do presence detection, it's built-in, just point it at the ARP OID: https://www.home-assistant.io/integrations/snmp/#precense-detection . I do find with HA that finding the best integration for a given task is not always trivial...

Indeed.

My only gripe is this



...more specifically when he puts a ruler up against the screen. I hate the lack of proper structure. Programming languages that distinguish between space and tab need to be taken out and shot.

[madires]

Looking at that table and keyboard tells me he isn't a software developer, more likely a marketing guy.

[emece67]

.

[Nominal Animal]

the language du jour attracts morons.

True, because most human beings are morons in the first place.  (In the olden days 'moron' had a specific meaning, which only applied to about 2% of the population.  I define the term as "unable, unwilling, or reluctant to apply logical or rational thinking in ordinary everyday situations, and relying on repetition, habit, instincts, or emotions instead".)

Which leads to a genuine question: should we even consider the moron-written code when comparing practical uses of programming languages?

I don't think so. I've seen poor programming in every language I have come across.

I agree.

For example, I don't think PHP is a "bad language" because there is so much insecure and inefficient PHP code out there; I think it is a "bad language" because it is quite difficult to write robust, reliable, secure, and maintainable PHP code.  I've been paid to do that in the past.  It feels like fighting against the language, not with the language.

I wonder if a programming language based upon repetition, habit, instincts and emotions can be devised so to enable morons to do fruitful work.

I do not believe so, because habit, instincts and emotions are easy to model and automate.

Consider, for example, human traffic behaviour.  While it is very difficult to predict what a single driver might do at any point in time, we can model traffic (be it automobiles, or even pedestrians) very accurately, with high predictive power, with rather simple models.  This means that rather than hiring morons as traffic directors, we are better off using sensible algorithms in traffic lights instead.

What we can do, is make any new programming language intuitive.  This involves having a consistent "world view" towards programming problems and situations, a paradigm if you will, that a human can adopt.  Then, the programmer (language user) will approach problems and solutions the same way the language designer did, and intuitively find the tools, without knowing those tools beforehand.  (Because a single paradigm will never be the best one for all problems, we'll always need more than one programming language.)  In simple terms, assuming a good paradigm, such a programming language makes it easy to write robust, efficient, maintainable code.

(I for one really like the Python pydoc interface, which examines the code itself and documentation strings (comments) in it, to produce an useful synopsis of the classes and interfaces the code implements.  It does not replace proper documentation, but it does make it easy to check things.  With minimum effort, you can get most of the documentation done.)

I don't think there is much use for morons outside the human-interface (service) industry in any post-industrial societies, I'm afraid.

[nfmax]

the language du jour attracts morons.

True, because most human beings are morons in the first place.  (In the olden days 'moron' had a specific meaning, which only applied to about 2% of the population.  I define the term as "unable, unwilling, or reluctant to apply logical or rational thinking in ordinary everyday situations, and relying on repetition, habit, instincts, or emotions instead".)

Which leads to a genuine question: should we even consider the moron-written code when comparing practical uses of programming languages?

I don't think so. I've seen poor programming in every language I have come across.

Exactly. Every Turing-complete language is also necessarily Turd-complete

[2N3055]

Consider, for example, human traffic behaviour.  While it is very difficult to predict what a single driver might do at any point in time, we can model traffic (be it automobiles, or even pedestrians) very accurately, with high predictive power, with rather simple models.  This means that rather than hiring morons as traffic directors, we are better off using sensible algorithms in traffic lights instead.

I my experience, instead, they hire morons to write cretinous algorithms..

[Nominal Animal]

Consider, for example, human traffic behaviour.  While it is very difficult to predict what a single driver might do at any point in time, we can model traffic (be it automobiles, or even pedestrians) very accurately, with high predictive power, with rather simple models.  This means that rather than hiring morons as traffic directors, we are better off using sensible algorithms in traffic lights instead.

I my experience, instead, they hire morons to write cretinous algorithms..

Sure, but that's a management problem.  As in, those who hire morons are themselves even worse morons.  (Usually very happy to waste other peoples' money, too.)

[DiTBho]

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 easily take a full-time week of work for preparation & execution and still runs the risk of breaking functionality.

Yes, this is exactly * THE * problem I have with Gentoo / Linux where the package manager (emerge + portage) is written in Python, and stops at * EVERY * major update.

This is also the reason why Python-update-xxx and Python-fix-xxx were developed. But they do not prevent anything, they simply try to repair the damage and are not always successful.

On Catalyst where you build a stage3 from source, Python is so problematic that it always takes a couple of weeks of full-time work to avoid future disasters.

[PlainName]

While it is very difficult to predict what a single driver might do at any point in time, we can model traffic (be it automobiles, or even pedestrians) very accurately, with high predictive power, with rather simple models.

Kind of. There have been instances where traffic flow has improved when lights at a junction are out of commission, and one place in London (I think) improved 'traffic calming' measures by removing all lights and road markings. It would be interesting to know if those situations were modelled or if no-one thought they might achieve anything so were never examined. If they were modelled then either someone has an axe to grind or the models were crap

[Nominal Animal]

While it is very difficult to predict what a single driver might do at any point in time, we can model traffic (be it automobiles, or even pedestrians) very accurately, with high predictive power, with rather simple models.

Kind of. There have been instances where traffic flow has improved when lights at a junction are out of commission, and one place in London (I think) improved 'traffic calming' measures by removing all lights and road markings. It would be interesting to know if those situations were modelled or if no-one thought they might achieve anything so were never examined. If they were modelled then either someone has an axe to grind or the models were crap

As far as I understand, they are rarely modelled fairly.  Typically, there is a mid-level boss that forces the designers to do silly choices, like ensuring a specific street has a green flow, even if it means severe congestion elsewhere, since that happens to be the street that boss uses to commute.  The rest of the system is worked around such arbitrary priority assignments.

Only when the traffic patterns become so congested the municipal/city politicians/paper-pushers start worrying about losing their jobs because of it, are the actual known models applied with inputs/parameters based on actual real-world data without such "tweaking".  Then, you also see things like multi-lane junctions converted to roundabouts.  (Love or hate modern roundabouts, they are proven to increase traffic flow in the same footprint, and reduce the number of accidents compared to junctions.)  This is why I wrote can be modelled, and not are modelled.

When people talk about "algorithms" –– especially so when it is about social media filtering ––, what they actually usually mean is "algorithms that have been perverted by humans arbitrarily tweaking the control parameters to achieve arbitrary personally-preferred results".  Never forget this.

The place where I learned to understand this, was in materials physics and chemistry simulations, using "classical" (non-quantum-mechanical) potentials and force field models.  You see, you can define a form for such a potential or force field based on atom properties, and then fit the parameters to achieve desired bulk or surface properties (matching actual physical measurements).  It is typical to consider a model that gives good surface (or bulk) properties, while the bulk (or surface) properties are off by an order of magnitude, "pretty good".

All practical algorithms have such tunables.  For traffic control, there are many; the estimated traffic density being the most important one.  You only need to tweak those a little bit to get exactly the effects you want.  Since the models are run in simulations, the effects of small tweaks can be experimented on, until one gets the results one wants.  If you think it is in traffic designers' best interests to optimize the overall pattern and ignore the personal preferences of the people who evaluate their work and pay their wages, you are woefully naïve.

And that is what is wrong in today's world, where both the algorithms and the parameters supplied to them are secret: those who apply them (and very often having tweaked the parameters from the actual existing data to skew the end result to something they want) can lie to people and say that "it wasn't me; it's just the algorithm ".

Remember: the output of basically all models and algorithms is dictated by its inputs (tunable parameters).  To get good results, those inputs must be chosen fairly, too.

[DiTBho]

This should explain why GPUs are so weird with PCIe and none of them(1) is made with a clean design 

(1) Radeon { 5450, 6450, 7470, RX 6700 XT }

[PlainName]

This is why I wrote can be modelled, and not are modelled.

OK

[brucehoult]

Then, you also see things like multi-lane junctions converted to roundabouts.  (Love or hate modern roundabouts, they are proven to increase traffic flow in the same footprint

Love roundabouts. They are everywhere here in New Zealand, from ones barely bigger than a dinner plate in suburbs (SO MUCH better than #$%^ 4-way stop signs) to one big enough to put an international-quality cricket ground in the middle of it.

Roundabouts give very low latency when traffic is light, but scale to pretty high traffic levels too.

Here's one near where I used to live in Wellington (viewed from a McDonalds):

[Nominal Animal]

Maybe I was too ranty above.  My point is, we do have good models and algorithms, but they do need to be set up with proper fair inputs and parameters to produce fair results.  Currently, especially in social media, people seem to accept the insane notion that it is the algorithm that makes decisions; that's not true.  It is the humans that set up the algorithms and their inputs.  Even fuzzy logic and expert systems ("AI", neural networks) that are trained with input; selecting the training input is what determines the outcome.

Circling back to programming languages' "quality": just like we cannot qualify algorithms based on results with skewed inputs and parameters, we cannot evaluate languages based on worst examples.

Instead, we do need to look at what is possible.  However, we cannot only look at the best examples, because that would be like qualifying algorithms and models based on results that are due to excellent inputs and parameters –– perhaps due to luck; with programming languages, perhaps due to extreme effort!

Because so many of us are morons –– I'm not even sure whether I'm a moron myself; I certainly seem to act so at times (using my own definition above) ––, I claim we need to look at how easy or how hard it is to write robust, maintainable, and relatively efficient code.

I do not believe a programming language should attempt to stop morons from writing horrible code; I'd be perfectly happy if it only made that harder than writing sensible code.  Help and hint, perhaps even guide; but not enforce.

So, let's circle back to Python in particular.

I've described my own opinion already in this thread, but to summarize, even though it has its downsides (version incompatibility from 2 to 3, slow I/O due to treating "strings" differently than "bytes", structural whitespace, and so on), I feel I can work with it just fine.  I do not need to fight against it.  It is certainly easier to write robust web service or backend code in Python than it is in PHP.  Many of the reasons I use Python and not better existing languages is that in the cases where I need an interpreted language like Python, those other languages have unrelated practical side issues – like not being as easily available, perhaps not being available at all (say, most web hosting services).

Thus, the reason I feel I can work with it just fine has at least as much to do with how the interpreter is packaged and available, its configuration (minimal, compared to e.g. PHP), and other such features, than it has to do with the programming language itself.

[nctnico]

Then, you also see things like multi-lane junctions converted to roundabouts.  (Love or hate modern roundabouts, they are proven to increase traffic flow in the same footprint

Love roundabouts. They are everywhere here in New Zealand, from ones barely bigger than a dinner plate in suburbs (SO MUCH better than #$%^ 4-way stop signs) to one big enough to put an international-quality cricket ground in the middle of it.

Roundabouts give very low latency when traffic is light, but scale to pretty high traffic levels too.

The biggest problem I have with roundabouts is that a fair share of drivers has what I call 'roundabout anxiety' and those drivers severly hamper traffic flow.

The French are very creative; you can find a fair amount of roundabouts that are shaped like the Audi logo in France. And ofcourse there is the one where the Arc du Triomphe sits in the middle.

[Cerebus]

The French are very creative; you can find a fair amount of roundabouts that are shaped like the Audi logo in France.

Ha! They've got nothing on us Brits, towhit the infamous "magic roundabout" in Hemel Hempstead:



I used to work in Hemel Hempstead and the roundabout is in fact much easier to negotiate from a driver's view than it looks to be from an aerial view.

Swindon has one too:

[Siwastaja]

The biggest problem I have with roundabouts is that a fair share of drivers has what I call 'roundabout anxiety' and those drivers severly hamper traffic flow.

Yeah, I have witnessed senile drivers get completely mentally stuck in a roundabout, suddenly braking to a complete stop to "give way" for someone entering the roundabout, has happened more than once. This is of course because roundabouts were nonexistent when they learnt driving, and old people tend to revert back to what they learned when still young. This problem fixes itself with time, though.

[brucehoult]

Then, you also see things like multi-lane junctions converted to roundabouts.  (Love or hate modern roundabouts, they are proven to increase traffic flow in the same footprint

Love roundabouts. They are everywhere here in New Zealand, from ones barely bigger than a dinner plate in suburbs (SO MUCH better than #$%^ 4-way stop signs) to one big enough to put an international-quality cricket ground in the middle of it.

Roundabouts give very low latency when traffic is light, but scale to pretty high traffic levels too.

The biggest problem I have with roundabouts is that a fair share of drivers has what I call 'roundabout anxiety' and those drivers severly hamper traffic flow.

These happen, but a lot less frequently in places where roundabouts are common. You can see a few of those in the video I posted.

You do need to have confidence in getting off the mark and accelerating quickly to roundabout speed (typically 15-30 km/h, 10-20 mph) and into the gap you just spotted. Completely doable with a small engine and manual transmission (1st will be fast enough), but easier for sure with a bigger engine and/or automatic.

You also need to trust in only having to look for traffic on the right (on the left in USA/Europe) -- and also of course that traffic in front of you isn't stopped. Still, much much easier than trying to get onto a busy road from a side road or driveway and spot gaps arriving from both left and right at the same time.