Python becomes the most popular language

[PlainName]

And lost ALL its content upon the unfortunate press of a key.

If your browser is a FireFox clone (maybe Chrome also, but I don't use it so don't know) there is an addon for this:

https://addons.mozilla.org/en-GB/firefox/addon/textarea-cache/

Sits on your toolbar or wherever and just caches textarea doobreys in the background. If you have an upset you pop it open and paste the stuff into the now blank box. Simples.

[cfbsoftware]

How long does Python take to do an average comparison between files?

on 200Mbyte of files, we are talking about 12 minutes vs 40-50 minutes.

12 minutes? Do you know why it takes so long? What sort of system are you running on?

I just did a text compare of 2551 text files (656 MBytes total) using a commercial file comparison program (Beyond Compare) and it took 13 seconds. 1899 of the files contained differences. I believe the software was developed using Delphi. One reason for the difference might be that Delphi is particularly good at string manipulation as the core string processing libraries are written in assembler.

[mansaxel]

I do have a new empty text document in Pluma (text editor I use for plain text, including programming short snippets) always within a single keystroke (and a single-character alias, g, in my shell).

I use Pluma for light scripting also. I've got a dark theme and it highlights code and shows line numbers. It the one that annoys me the least. It doesn't seem to like -really- big log files.

From the old bad days when I did DNS administration for a country code top level domain i ${EDITOR}, I can tell that GNU emacs is pretty fast, while nvi is not. I did persist in using nvi, though, because it is line oriented, and therefore eminently suited to data like the zone file format. Actually it was opening the file that was the problem; once in memory/mmap it was fairly snappy.

I still use vi for nearly all system-close editing (where a line-oriented approach is prevalent), except really small jobs on the console, where it is beneficial to see shell history; then "ed" (which is the the standard editor!) wins. Longer pieces of code end up in Emacs (I run Aquamacs on OS X). Another exception is T_EX writing, which thanks to AUCT_EX packages also is best done in Emacs. I've made a template in L^AT_EX that emulates the company-mandated M$Word standard document, with a few extensions of my own, so I quickly can generate text that in appearance, as usual for T_EX derivates, surpasses everything made in Word. And it does not mess up the table of contents, one is not tempted to "just make the font bigger" to create a section header, it does not jump around in margins. It simply works.

Edit: If I'm in the sad position of having to use a Linux system, especially Ubuntu (which is Zulu for "I can't install Devuan") the first things that happen are the complete eradication of nano and vim, after which nvi and ed are installed.

[blacksheeplogic]

Edit: If I'm in the sad position of having to use a Linux system, especially Ubuntu (which is Zulu for "I can't install Devuan") the first things that happen are the complete eradication of nano and vim, after which nvi and ed are installed.

Up until the early 90's ED was the only editor installed and allowed to be used on the systems I worked on. Once we moved to screen editors,  I preferred Vi over EMACS simply because VI was always available and EMACS mostly was not. These days my editor of choice is VIM. I'm curious as to what advantage you see NVI has over VI? NVI was a implementation of VI.

[Ed.Kloonk]

I'm not anti vim or vi or emacs. I'll use vim at a pinch if I've done something horrendous.

I like Pluma cos it has a dark theme which I like and it highlights text and if you ask it nicely, the appropriate source. But yeah vim with green on black as long as it's big and contrast-y, I'm a happy guy.

edit: what I tried to say in the above sentences is I would really like to like full IDEs. But they wind up annoying me. The one aesthetic thing I wanna tweak is not possible. So back to text editor.

[mansaxel]

Edit: If I'm in the sad position of having to use a Linux system, especially Ubuntu (which is Zulu for "I can't install Devuan") the first things that happen are the complete eradication of nano and vim, after which nvi and ed are installed.

Up until the early 90's ED was the only editor installed and allowed to be used on the systems I worked on. Once we moved to screen editors,  I preferred Vi over EMACS simply because VI was always available and EMACS mostly was not. These days my editor of choice is VIM. I'm curious as to what advantage you see NVI has over VI? NVI was a implementation of VI.

I only want a "vi", I do not want something that has closet dreams of becoming Emacs. Therefore "vim" goes to the bit bucket. And "nano" is a text file destroyer that I've hated since last century. It breaks lines in files without being asked to. That and that alone is enough to evict it by force.

[DiTBho]

And lost ALL its content upon the unfortunate press of a key.

If your browser is a FireFox clone (maybe Chrome also, but I don't use it so don't know) there is an addon for this:

https://addons.mozilla.org/en-GB/firefox/addon/textarea-cache/

Sits on your toolbar or wherever and just caches textarea doobreys in the background. If you have an upset you pop it open and paste the stuff into the now blank box. Simples.

WOW, this somehow operates like my java-script text editor, but it's much more comfortable this way 

[blacksheeplogic]

I only want a "vi", I do not want something that has closet dreams of becoming Emacs. Therefore "vim" goes to the bit bucket.

Yes, I understand where your are coming from. VIM keeps growing mostly with stuff nobody actually uses. But I've got used to syntax highlighting and ctags in vim so it would be a hard switch back to vi.

[newbrain]

Performs poorly here..

Because his code is written to be slow.
It is obvious code that is ported from C without fully understanding all the features of the language.
He doesn't even use list comprehension.

I had a direct demonstration of this just yesterday.
A friend/colleague of mine was struggling with some data analysis task in Pyhton - he's a learner in both.
The code he wrote was taking hours to complete, and he asked me for some guidance.

I'm not an expert in either subject matter, but as soon as I saw his code I told him: "You have a number of explicit nested for loops. Turn them into list comprehension and slicing, check the library (pandas) for some smart indexing".
Twelve hours to a couple of minutes.

[brucehoult]

I had a direct demonstration of this just yesterday.
A friend/colleague of mine was struggling with some data analysis task in Pyhton - he's a learner in both.
The code he wrote was taking hours to complete, and he asked me for some guidance.

I'm not an expert in either subject matter, but as soon as I saw his code I told him: "You have a number of explicit nested for loops. Turn them into list comprehension and slicing, check the library (pandas) for some smart indexing".
Twelve hours to a couple of minutes.

The thing is, in a "real" programming language it doesn't matter whether you use a built in construct such as foreach in a container, or write it out explicitly yourself -- the speed will be the same either way (assuming the same algorithm).

It's still good to have things such as foreach and iterators and list comprehensions and array slicing in a real programming language, but it's notational convenience only -- less text to write, less to read. In Python / Ruby / Perl it's critical to use that built in high level stuff as much as possible.

[tszaboo]

I had a direct demonstration of this just yesterday.
A friend/colleague of mine was struggling with some data analysis task in Pyhton - he's a learner in both.
The code he wrote was taking hours to complete, and he asked me for some guidance.

I'm not an expert in either subject matter, but as soon as I saw his code I told him: "You have a number of explicit nested for loops. Turn them into list comprehension and slicing, check the library (pandas) for some smart indexing".
Twelve hours to a couple of minutes.

The thing is, in a "real" programming language it doesn't matter whether you use a built in construct such as foreach in a container, or write it out explicitly yourself -- the speed will be the same either way (assuming the same algorithm).

It's still good to have things such as foreach and iterators and list comprehensions and array slicing in a real programming language, but it's notational convenience only -- less text to write, less to read. In Python / Ruby / Perl it's critical to use that built in high level stuff as much as possible.

I'm sorry, but but what you are saying is bullshit, and goes against basic principles of computer science.
Saying that "No matter what sort of data structure I choose, the program will be fast" is fundamentally wrong, just try to find some data in a binary tree vs an array.

[PlainName]

Saying that "No matter what sort of data structure I choose, the program will be fast"

He didn't say that, did he? Looked to me like he said that using foreach is basically the same as typing it out explicitly (that is, a[0]=1, a[1]=2, etc) when it comes to speed.

[Picuino]

According to Pareto's law, 80% of the code only takes 20% of the execution time, while 20% of the code takes 80% of the execution time.
Normally you should only optimize 20% of the code to gain a lot of speed.
In Python this 20% of the code can already be optimized with external libraries, sometimes written in C (like numpy).

Many times the problem is not the speed but the management of 80% of the code, very extensive and prone to maintenance difficulties. That's where Python stands out and is better than C.

[SiliconWizard]

Many times the problem is not the speed but the management of 80% of the code, very extensive and prone to maintenance difficulties. That's where Python stands out and is better than C.

Really? Python better for maintenance? Maybe that is true, but I would certainly like to see a reasonable study proving that point. Because I'm not so convinced at this point.

[Picuino]

There are many programmers who think this way. But it's just an opinion, I don't know of any study to prove it.

Edit:
Some interesting links
https://www.stxnext.com/python-vs-other-programming-languages/
https://hilton.org.uk/blog/maintenance-expressive-languages
https://www.forbes.com/sites/forbestechcouncil/2020/04/10/reducing-maintenance-costs-with-functional-programming/?sh=36cee59bf643

[Nominal Animal]

I agree that maintenance is a serious problem, but:

My own observations indicate that most developers are much more interested in creating new stuff than in maintaining stuff, including stuff they themselves created, regardless of the programming language used.  Because more capable developers are in high demand, they can simply switch to more interesting stuff, and let others deal with the maintenance.

The problem is, new developers do not usually have the understanding of the projects to deal with design problems.  They do catch simpler bugs – stuff like off-by-one errors, typos, edits that miss a related expression or two – but when they become experienced enough to deal with design problems, they already can choose to move to creating new stuff instead.

I do not know if the programming languages differ in the bug complexity or amount of bugs that new developers can handle.  (That is, I personally cannot tell if they do differ in this.)
In some ways it seems likely that languages with shallower learning curve might let new developers fix more stuff, but I do not know if bugs in different languages are similar in complexity.  In Python and in Perl, the most efficient expressions use their own notation and paradigms, and are unlikely to be fully understood and easily manipulated by the newest programmers; in analogous terms, I'd say it is just as likely for their developers to just move to new projects from maintaining/fixing existing stuff earlier along the learning curve.

I wonder if those who hire programmers have learned to check how long the developers have actively maintained the projects they showcase as their own, as opposed to just dumped it on the web as an example of their development skills and passed on to other stuff?  That is, whether they even care about bugs in their own code, or just want to create new stuff and leave the tedious maintenance and bug-fixing to other people?

[brucehoult]

According to Pareto's law, 80% of the code only takes 20% of the execution time, while 20% of the code takes 80% of the execution time.
Normally you should only optimize 20% of the code to gain a lot of speed.

That's true if you write all the code in the same language (or at least similarly efficient languages).

In Python this 20% of the code can already be optimized with external libraries, sometimes written in C (like numpy).

Let's try a thought experiment.

We have some task written in C (or Java or C#) that takes 10 seconds to run:

8 seconds: the important 20% of the code
2 seconds: the "unimportant" 80% of the code that you want to be easy to maintain

We rewrite 80% of the code in Python. Python runs 50 times slower than C. Now we have:

8 seconds: the important 20% of the code (still in C)
100 seconds: the Python part

Total runtime just went from 10 seconds to 108 seconds. The Python code is taking 92.6% of the time.

I sure hope it's a LOT easier to maintain to make it worth it.

Or, it had better be more like 99%/1% in the C version, not 80%/20%.


(Of course 108 seconds is better than the 500 seconds it would take if you wrote it all in Python ... but 10 seconds is even better)

[Ed.Kloonk]

According to Pareto's law, 80% of the code only takes 20% of the execution time, while 20% of the code takes 80% of the execution time.
Normally you should only optimize 20% of the code to gain a lot of speed.

That's true if you write all the code in the same language (or at least similarly efficient languages).

In Python this 20% of the code can already be optimized with external libraries, sometimes written in C (like numpy).

Let's try a thought experiment.

We have some task written in C (or Java or C#) that takes 10 seconds to run:

8 seconds: the important 20% of the code
2 seconds: the "unimportant" 80% of the code that you want to be easy to maintain

We rewrite 80% of the code in Python. Python runs 50 times slower than C. Now we have:

8 seconds: the important 20% of the code (still in C)
100 seconds: the Python part

Total runtime just went from 10 seconds to 108 seconds. The Python code is taking 92.6% of the time.

I sure hope it's a LOT easier to maintain to make it worth it.

Or, it had better be more like 99%/1% in the C version, not 80%/20%.

Yes Bruce, but it depends on the deployment. If it finds it's way into the hands of normies like me, whilst, yes, C is preferable, a python script with low bandwidth in the grand scheme of things can be adjusted easily without having to figure out what the dev was smoking with the whole C tool chain.

[brucehoult]

I'm sorry, but but what you are saying is bullshit, and goes against basic principles of computer science.
Saying that "No matter what sort of data structure I choose, the program will be fast" is fundamentally wrong, just try to find some data in a binary tree vs an array.

No, I'm assuming the same data structure/algorithm in both cases. Just written by you vs written by whoever wrote the Python interpreter or external C library.

[brucehoult]

Yes Bruce, but it depends on the deployment. If it finds it's way into the hands of normies like me, whilst, yes, C is preferable, a python script with low bandwidth in the grand scheme of things can be adjusted easily without having to figure out what the dev was smoking with the whole C tool chain.

If you find C dangerous, Java and C# are just as n00b safe as Python, but run within a factor of 2 of C. Probably within a factor of 1.2 much of the time.

[Ed.Kloonk]

Yes Bruce, but it depends on the deployment. If it finds it's way into the hands of normies like me, whilst, yes, C is preferable, a python script with low bandwidth in the grand scheme of things can be adjusted easily without having to figure out what the dev was smoking with the whole C tool chain.

If you find C dangerous, Java and C# are just as n00b safe as Python, but run within a factor of 2 of C. Probably within a factor of 1.2 much of the time.

Whilst I don't get to code anywhere near as much as I'd like, no I don't find C dangerous for my own purposes.

But when trying to play the part as a distro package maintainer, I'm not going to re-write the whole thing back into C just because the person who wrote some wrapper chose the wrong language. I'm putting it to you that they did indeed choose the right language because of the included high level stuff that does the heavy lifting but the simple little tweaks such as wonky file locations can be made without having to upset the whole apple cart.

I realise embedded is a different kettle of fish.

[Mattjd]

Why is it that, one this site, there are discussions that devolve into identity politics, and there's always an individual, or two, whose posts consist of spastic thoughts just vomited out.

Have you ever had a discussion in identity politics, or in plain politics, that didn't eventually devolve into spastic thoughts just vomited out?

I've found that applies to just about everything concerning opinions in general.

The opinions themselves, in my opinion (HA!), are basically worthless.  What is interesting and important, is the reasons and experiences behind those opinions, because only by analyzing and comparing those, can one constructively build and rationally/logically examine ones own opinions.  I do that all the time, and I've found it extremely useful and helpful in various aspects of my own life.

That's why I asked why anyone should concern themselves with programming language popularity in any way –– except possibly when learning ones first programming language, or desperately seeking employment as a programmer.  I don't, but I know almost nothing about anything anyway, so I'm interested if anyone has some reasons I don't know about.

When the discussion devolves into combating opinions, I only participate when I believe the opinions are based on incorrect or non-factual or incomplete reasoning, and try to explain the issue, and ask how people think that affects their opinion.  (However, I only do "technical" English, and have basically zero skill in such social subtext and niceties, so I fail English often here.)  Especially opinions that differ from mine interest me, because their basis could be something I'm not aware of.

But when the opinions devolve (like in a recent Devuan thread) into "I'm a master in this, and I don't see the problems, so you must be wrong" without even checking the facts, I too get so irate I start spewing poor spastic counteropinions.  Sorry about that, but we're all only human.  Besides, online the bandwidth is too small to properly express the emotional content and context that would defuse/inhinit such emotive reactions and spastic outbursts.  Even sarcasm and jokes are easily misunderstood.

For what its worth, I wasn't talking about you

[Mattjd]

According to Pareto's law, 80% of the code only takes 20% of the execution time, while 20% of the code takes 80% of the execution time.
Normally you should only optimize 20% of the code to gain a lot of speed.

That's true if you write all the code in the same language (or at least similarly efficient languages).

In Python this 20% of the code can already be optimized with external libraries, sometimes written in C (like numpy).

Let's try a thought experiment.

We have some task written in C (or Java or C#) that takes 10 seconds to run:

8 seconds: the important 20% of the code
2 seconds: the "unimportant" 80% of the code that you want to be easy to maintain

We rewrite 80% of the code in Python. Python runs 50 times slower than C. Now we have:

8 seconds: the important 20% of the code (still in C)
100 seconds: the Python part

Total runtime just went from 10 seconds to 108 seconds. The Python code is taking 92.6% of the time.

I sure hope it's a LOT easier to maintain to make it worth it.

Or, it had better be more like 99%/1% in the C version, not 80%/20%.


(Of course 108 seconds is better than the 500 seconds it would take if you wrote it all in Python ... but 10 seconds is even better)

You're grossly over estimating speed differences. There's plenty of examples floating around of people writing some numerical routine in pure C/C++ and it being slower than numpy because said person doesn't know how to write the code to squeeze every bit of optimization from the compiler.

Edit: I don't even understand what you are arguing here. Its like you're completely ignoring that fact that for super hot spots in the code you can write C/C++ and use it directly in the python code.

People don't write python for speed, they write python for the user interface experience. The speed comes from writing stuff in C/C++

[Ed.Kloonk]

If there's one thing I've learned as a drive-by coder, optimization in code is never where you expect it to need to be.

[Marco]

- far more suited to long term results instead of newbie appeals

These don't have to be exclusive. The long term result of Perl's obtuseness and Python's newbie appeal will be Perl becoming ever more niche and losing ever more ground to Python, it being more suited in the abstract of a world filled with Perl specialists helps Perl little in the real world to prevent this.

In the end the increasing speed of computers was going to make scripting ever more important, a scripting language would end up on top eventually and this is a winner take all world.