Python becomes the most popular language

[Marco]

People were still screwing up SQL input sanitation in every language used on the Web at the time. PHP wasn't special, just popular.

Sometimes security is hard, sometimes unquestionable traditions made it hard. C, null terminated strings and escape sequences in general outside of corruption resistant transmission protocols should have been ditched decades ago for sensitive code facing untrusted inputs. It would have prevented far more misery than PHP ever caused.

All strings should have had length, all operators should have been coded separately from data/text strings and the editors should have just color coded it and hidden and handled the minutia. Plain text was a mistake (for HTML, XML etc too).

[Siwastaja]

It seems that criticizing is easier than explaining the reasons why things work.
It is also more exciting and more satisfying to criticize something than to try to explain reality.
Now PHP has had its moment of criticism.
I'm not going to be the one to support the use of PHP, because I don't think it's a good language.
But, after all, PHP is still used in more than 80% of dynamic websites.

You keep falling into that fallacy that popularity proves anything else than popularity. Or rather, I don't understand what your point is. You are agreeing that PHP sucks. We both also know how popular it is. So?

In the Real World, it's completely normal that things just happen. The reasons can be historically interesting, but hugely complicated, and often totally non-technical.

People have become rich by being in the right place at the right time. Or won in lottery. And yes, they prefer to write the history in such a way proving they are business geniuses, or whatever.

PHP is popular because PHP is popular. It's as simple as that. It's called traction. Why I say such an obvious thing? Because hear this out: if PHP didn't exist in the first place, we would just have something else, instead, similarly popular. That makes PHP, per se, in itself, totally irrelevant! And chances are high the alternative would work better. It's of course possible it would be even worse, but there are physical limits to that. If something does not get the job done at all, then it won't stay popular.

But it isn't always this way. If something is truly well designed and well performing, and it also happens to get the necessary traction, it will shape the world into a much better place than if we have to work around crappy solutions. PHP gets the job done, but that is literally the minimum base level, and all the wasted time working with it is removed from more fruitful work.

[Picuino]

I started programming like a hobbyist in in my teens with Microsoft Basic interpreted on a CPM machine with two floppies. That was a great pain. Slow and difficult to develop, but with all the glamor and excitement of the discovery of computing.

When I later discovered compiled languages ​​(first Turbopascal and later C) it was a blast. Both for its great speed and for the ease of implementing large programs thanks to structured programming.

But I was still missing a good tool to work with texts. The Internet was in its infancy, Google did not exist and it was not easy to learn like it is now. At that time awk was a revelation for me. An interpreted language, easy to debug and with enormous power when working with text strings and files. It is not a language for large programs, but it was good for simple calculation scripts and text handling.

Later, working with PLCs, the possibility of compiling program descriptions in ladder language came to my mind. I saw it done at Siemens with Excel spreadsheets to generate the base of the PLC programs. But Excel seemed very limited to me.
At that time I met Python and it was another great discovery for me. Like a very vitaminized awk.
I first used Python to validate PLC structured text (similar to Pascal) that resulted from compiling a block diagram. That allowed me to find the bugs in the block diagram that made the emergency stops work.
Python worked simply for a complex job such as interpreting Pascal-like code to find its bugs.
From then on I did not stop using compiled languages, but I recognized the great advantage of having Python, interpreted free language (not like the first turbopascal and c compilers I had) so versatile with which to do jobs that in C would have taken 10 times more work.

I have the point of view of someone who has been missing this tool (Python) for many years and who finally discovered it after going through many languages ​​with limitations that Python does not have.

Of course, when programming a microcontroller, I do it in C. I know that micropython exists, but I haven't used it and it doesn't bother me because microcontrollers don't have to perform the tasks for which Python is specialized.

The language that I am now hoping to find is one similar to the first basic of my beginnings, to be able to debug with an interpreted language that weighs little, small microcontrollers of about 8k-16k flash.

Regards.

[jfiresto]

... I have the point of view of someone who has been missing this tool (Python) for many years and who finally discovered it after going through many languages ​​with limitations that Python does not have....

Having had to use a few too many half-baked fourth generation languages, I was happy to see Python finally become popular. Python has its ad hoc, historical warts, but I still find it the most agreeable high level language so far.

[Picuino]

Speed ​​is important to me, but I've used interpreters running at a few hundred cycles per second (Microsoft-Basic) on a Z80 4 MHz machine. Then the world of PLCs where a 10ms response is fast and only several thousand instructions per second are interpreted. The same with microcontrollers. A typical 8-bit PIC runs at just 16MIPS in machine code.

I fully understand what it means when someone says that Python is slow, but I also think that there is a lack of perspective when it comes to assessing its speed and to say that a loop of 10,000,000 iterations per second is slow, is to misunderstand what slow means.

Regards.

[PlainName]

I fully understand what it means when someone says that Python is slow, but I also think that there is a lack of perspective when it comes to assessing its speed and to say that a loop of 10,000,000 iterations per second is slow, is to misunderstand what slow means.

Seems to me you are all arguing the same thing from opposite ends. On the one hand Python is slow compared to alternatives, but is fast enough for the particular purpose. On the other hand, since some purpose doesn't require the speed of alternatives, Python is fast. Just different viewpoints and ways of saying the same thing.

[Siwastaja]

Speed just relates to what you can do. In itself, it is also uninteresting. Cars and airplanes enable you to go to places where you wouldn't go otherwise, at all.

If you want to draw graphics on a 4K display, or decompress a full-HD cat video, this just needs the enormous speed of modern computers in full. If you slow it down by two orders of magnitude, then you can do the state-of-the-art things of 1980's/early 1990's on a modern PC. That's the difference.

But quite obviously, many things we do on our computers were already doable in 1970's hardware. In such cases, any amount of execution speed penalty does not matter.

This is all artificial talk, because you can get best of the both worlds. Write performance critical pieces of software in languages such as C, and use Python whenever the libraries (written in C) are available to do the heavy lifting for you. This should be obvious, but it clearly always isn't.

To say you wrote a video player in Python equals to saying you walked from Sydney to New York, because you walked into the airplane. The performance of this simple walking operation does not matter, because the real work is done elsewhere, and hidden from you.

[Vtile]

Nonono this is just turning to poo throwing real programmer vs. The world fight. 😆

I wonder how many that claims python as scripting language and something where you only do some minor call logic for libraries that are written with 'The Allmighty', are actually rolling their own compiler and libraries to avoid being scriptkiddies with 'The Allmighty'... xD

Tldr; So much fucked up logic as in nerd talks we used to do in age of 10.

[Siwastaja]

Didn't understand any of that cynical outburst. I'm sure many of us can discuss things without throwing poo. I hope the best for you.

How many are writing libraries? Um, quite many? It's completely normal software practice.

[madires]

Scripting languages are great for automating tasks, testing an idea or as a quick way to write some code. But they are not meant for high demand processing, because they don't scale as well as compiled languages. It's like using a 3D printer at home vs. injection moulding. You can do 10000 plastic parts with your inexpensive 3D printer. It works but it will need a very long time. Or you go for the more expensive moulding form and get the 10000 parts quite fast. On the other hand, you wouldn't use injection moulding for a single part, but your 3D printer is the right tool for that. It's about using the best solution for a given problem. Unfortunately these basics are ignored more and more. And that's the reason why we have to deal with crawling slow websites, people claiming that X is the best programming language ever and other stupidities.

[madires]

If you want to draw graphics on a 4K display, or decompress a full-HD cat video, this just needs the enormous speed of modern computers in full. If you slow it down by two orders of magnitude, then you can do the state-of-the-art things of 1980's/early 1990's on a modern PC. That's the difference.

Exactly! We would't try to write an H.265 decoder in python. But in C, or better in silicon. I don't want to run a cluster of 10 PCs just to be able to watch a cat video in 4k.

[Cerebus]

The language specification itself is crappy, too, many historical layers of poor design,

It's the historical curse of interpreted languages produced by semi-competent 'designers'. One thing they all seem to have in common is parsing by an ad-hoc, non-recurvive, version of recursive descent. Often the language isn't designed as such, but cobbled together as they go along. It can be instructive to try and write a grammar for one of that class of languages; you'll quickly find yourself in a mire of special cases and one offs, with a noticeable lack of any kind of regular structure. This is because the language was never designed as such, there was never a specification for the language, just a bunch of ideas and an implementation. If such a language gains popularity, and finds itself in need of a proper implementation, eventually some poor sod has to reverse engineer all that has come before them into an actual specification and then try to reimplement it with a standard set of compiler tooling, or at least a hand-written recursive descent parser (probably with lots of hacks based on heuristics).

Every programmer has their own pet ideas on what would/will make a good programming language. If you are ever tempted to try and make your own more than a pipedream, then please, please, start by trying to write a formal grammar for it and feeding it into lex/yacc (or equivalent tooling of your own choice) and seeing if you can even produce a parsable language. If that doesn't stop you in your tracks then you might be about to produce something usable (you might not as well) but at least you won't be producing something that is pure nightmare from day one.

[Nominal Animal]

I wonder how many that claims python as scripting language and something where you only do some minor call logic for libraries that are written with 'The Allmighty', are actually rolling their own compiler and libraries to avoid being scriptkiddies with 'The Allmighty'... xD

If you are referring to me, I'm using "scripting language" as purely a technical term for an interpreted language, as opposed to a compiled language.
There is no qualitative aspect involved.

It definitely has nothing to do with the term "script kiddie".  Which itself has basically nothing to do with writing interpreted code, and instead describes someone who downloads scripts and uses them without knowing how they work.

To me, a "script" is something that is easy to maintain, modify and adapt, without requiring any development tools (like a compiler).  The run time environment, the interpreter and any other run-time requirements like libraries, suffice.  I use "script" solely as a technical term without any negative connotations.  Just because something is a script, does not mean it is of lesser value or utility or complexity than a program; to me it only means it is run using an interpreter directly from its source, instead of requiring a separate compilation step.

[Cerebus]

To me, a "script" is something that is easy to maintain, modify and adapt, without requiring any development tools (like a compiler).  The run time environment, the interpreter and any other run-time requirements like libraries, suffice.  I use "script" solely as a technical term without any negative connotations.  Just because something is a script, does not mean it is of lesser value or utility or complexity than a program; to me it only means it is run using an interpreter directly from its source, instead of requiring a separate compilation step.

Some of the most valuable programs I have written, in terms of saved man-hours, and thus saved actual hard cash money have been "scripts", mostly csh. I can't put a figure on it, but I would not be surprised if the total in aggregate came to millions of pounds/dollars/whatever, but certainly we're talking multiple 100s of thousands.

If we extend "scripts" to code written in Python then we're definitely there as the last Python project I was on was expected to save a few hundred thousand euros a year. It won't because the organisation it was written for is the kind of large organisation that immediately finds another way to be inefficient and piss money away. But the task it was intended to undertake will now be trivial and cheap, whereas before it was slow, expensive, complex, and (most importantly) risky.

[Picuino]

This is all artificial talk, because you can get best of the both worlds. Write performance critical pieces of software in languages such as C, and use Python whenever the libraries (written in C) are available to do the heavy lifting for you. This should be obvious, but it clearly always isn't.

Yes, it is obvious to me.
I have never said that it makes sense to develop a video decompressor in Python. It's something absurd.

When I celebrate that Python is so popular because it is a language that has helped me on many occasions, several forum users appear explaining all the drawbacks and problems of Python to show that it is a language that is worth almost nothing.
Ok, everyone has their opinion and is respectable. But don't get me wrong. I only appreciate Python to the extent that it has served me on many occasions. And I think the same thing has happened to many other users.

If now the Tiobe index has recognized Python as a very popular language and Python has served you well, I think it's time to congratulate yourself for it. And perhaps wonder why it has been like this or, also, why I am happy about it.

I think I'm going to create another thread called "Why i don't like Python and why it's a lousy language", so that those who disagree can elaborate. The topic of this thread is why Python is popular not why Python shouldn't be popular.

Edit:
Perhaps I should change the original question and ask "Who is happy that Python is so popular and why?"
(only for Python fans) 

[Siwastaja]

When I celebrate that Python is so popular because it is a language that has helped me on many occasions, several forum users appear explaining all the drawbacks and problems of Python to show that it is a language that is worth almost nothing.

This is where we differ. You have emotional attachment to Python, making your communication about it unclear (like the comments about Youtube). Me, on the other hand, I have no emotional feelings about Python at all, in any way, good or bad.

This makes you misinterpret my comments which are just based on facts, not opinions since I don't have strong opinions related to Python, with the sole purpose of letting people gain more understanding. Most non-trivial computing tasks require heavy some lifting, and in Python programs, it's the preferred way to let existing C library code handle that. This is just a fact, regardless of whether you notice it. I spell it out because it's good to know if you want to understand how things work.

Now I understand your mere purpose of discussion is to celebrate your Python fanboyism, and you are not interested in factual discussion. Nothing wrong with that since I have nothing against Python fanboys. Go for it.

I have mostly decent experience on projects written in Python, but I also see some problems, which kind of balances to neutral opinion about it.

[Picuino]

I've made my pro-Python position clear from the start. But being a fan is not being a fanboy, which is derogatory.

I am not against the opinions that may be held against Python. I'm the first one that I would like it to be faster and I've already commented that I'm glad Guido finally intends to speed up the language.

What I think you explain on many occasions are facts about Python and sometimes against and I'm glad for that, it can serve to put things in their place. But I also notice an emotional attachment against me for being a Python fan.

I'm not against you explaining the facts, I'm against you misunderstanding me and accusing me of being a fanboy.

[Siwastaja]

Oh, I'm sorry for being derogatory. I sometimes have that tendency on the interwebz. I'm really not against you, I just felt like some comments in particular were pretty simple-minded (and this is not to mean that you are simple-minded; no, just the few comments) and wanted to correct them, but I can see now that I don't need to sound so condescending to do that.

This "pro-programming language" scene is just very weird to me. I have always used them as tools, maybe even have some weird love-hate relationship (not with Python, though, it's neutral to me), but never pro- or con- just because of the language. In the end, they are tools and suit certain jobs.

[Picuino]

Python is a tool for me too. But we all have love-hate relationships with our tools.
I hated BASIC because of its many limitations and slow speed.
I have never come to hate C, on the contrary it allowed me to free myself from the assembler and I appreciate it very much for that, although sometimes it drives me crazy when debugging.
Programming in Python gives me good feelings that no other language achieves, I can only put the but of being an interpreted language and therefore not valid for small microcontrollers or for low level, but for that I have C. This makes me bias towards Python, as you can see and I do not hide.

Edit: Is like drive a car. Many people love to drive and some love internal combustion engines, others love electric motors and others don't care because it is nothing more than a means of transport.

[brucehoult]

This is all artificial talk, because you can get best of the both worlds. Write performance critical pieces of software in languages such as C, and use Python whenever the libraries (written in C) are available to do the heavy lifting for you.

You can get the best of both worlds by using a language that allows you to write code as quickly and sloppily as Python to get your algorithm right, and then improve the most critical code IN THE SAME LANGUAGE to get C-like speed by doing things such as adding declarations, not by re-writing the whole thing.

[Nominal Animal]

This is all artificial talk, because you can get best of the both worlds. Write performance critical pieces of software in languages such as C, and use Python whenever the libraries (written in C) are available to do the heavy lifting for you.

You can get the best of both worlds by using a language that allows you to write code as quickly and sloppily as Python to get your algorithm right, and then improve the most critical code IN THE SAME LANGUAGE to get C-like speed by doing things such as adding declarations, not by re-writing the whole thing.

Is there such an interpreted language right now?

(Note that it is not Siwastaja, only myself, that needs the language to be interpreted.  Thus, this is not a counter-question, this is a new question that just happens to fit into the discussion at this point.  I am the one that uses Python3+Qt5 for user interfaces, with all proprietary and high-performance code in native dynamic libraries, implemented in C.)

The only one that I know of, Julia, seems to be directed at research, and Windows/MacOS desktop users.  In particular, there does not seem to be a sane maintained Qt interface package at all; I could find two Python-derived ones, and a MacOS-only package.  Even the GObject Introspection Julia Package seems to be incomplete and unmaintained; it would immediately provide interfaces for tens of dozens of useful, well-known, trusted libraries available in standard Linux distributions.

There does seem to be one for Gtk+ 3.0, so anyone using Python+Gtk+3 should consider the Julia alternative.  Of course, since no major distribution (especially Debian) have Julia package(s), installation will require executing a binary with superuser privileges from julialang.org, which is not something I personally can vouch for (compared to e.g. installing a Debian package from the official repositories).

I fully agree that Julia is such a language, in theory.  (I particularly love its native/C interface capabilities.)  In practice, however, the lack of native Linux packages and a maintained Qt interface, does mean one cannot currently use Julia as a practical replacement for Python3+Qt5.

I also use Python for server-side scripting.  As to using Julia for server-side scripting, I really worry about the security implications of its precompilation mechanism.  I have not yet investigated this thoroughly, but especially in an environment where server-side scripts are run as dedicated user accounts with a shared home directory, controlling such precompilation is paramount.  (For Python, there is the -B command-line option and PYTHONDONTWRITEBYTECODE environment variable that can be used to avoid "precompilation"/bytecode file generation issues.  For HTML templates and similar, the Python exec() interface provides a way to limit "untrusted" code access to specified variables, objects, and even limit the availability of standard library functions, including import.)

In other words, to me it looks like the Julia language developers are really not interested in this kind of use cases at all (including multi-user security and privilege separation techniques), and are instead directed at research and Windows/MacOS single-user desktop users, rather than cross-platform and server-side uses.
This look, of course, is only very superficial, and I could easily be wrong.  I probably am wrong.  You seem to have much more experience in it than I do; do you disagree with my – admittedly superficial! – observations above?  Was there some other interpreted language you were thinking of?


The reason I post this, is that language features and theoretical capabilities are one thing; practical use cases and patterns are another thing.  Neither thing alone is sufficient to determine what language is most appropriate for a given task: one must consider all things, using whatever weighing pattern one deems most appropriate.  For myself, even superior excellence in one thing does not override deficiencies in another.  I am not looking for "the best language"; I am looking for the tool with the least drawbacks instead.  (Except for a few purely personal quirks, of course, like my avoidance of Perl purely for non-technical personal reasons.)

For myself, I hope I've made it clear that Python language is not the main reason I use it.  I do not think it is anything exceptional; it just avoids many of the pitfalls I had to work around in PHP, and has a gentler learning curve than Perl.  It is the practical use cases, especially portability and ease of use that determine when I use Python; with everything proprietary and anything requiring computational efficiency provided as native binary dynamic libraries, implemented in C.  (I avoid C++ here, to keep dependencies and Python interfacing as simple as possible.)

Julia comes very close.  To replace Python3+Qt5 in normal application development, all I'd need is Debian packaging and native/non-PySide Qt5 support.  (If it cannot be provided as a Debian package, an application is not worth much in Debian-derived Linux distributions.)  To use as a server-side scripting language, some investigation and perhaps development first with precompilation and privilege separation seems necessary, to avoid exploits using precompilation or runtime access to Julia package repositories.  As it is, I cannot trust Julia as a server-side scripting language.

[RoGeorge]

I didn't know that  ↓

Code: [Select]

~$ python3
Python 3.8.10 (default, Nov 26 2021, 20:14:08)
[GCC 9.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.

>>> a = 1234
>>> b = 1234

>>> a is b
False

>>> a = 123
>>> b = 123

>>> a is b
True

 

[tszaboo]

I didn't know that  ↓

Code: [Select]

~$ python3
Python 3.8.10 (default, Nov 26 2021, 20:14:08)
[GCC 9.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.

>>> a = 1234
>>> b = 1234

>>> a is b
False

>>> a = 123
>>> b = 123

>>> a is b
True

 

Cause you are asking about memory locations, which is not intended. You have to use ==. It's like comparing pointers in C.

[RoGeorge]

I didn't intend to check if the values are equal, and anyways, that doesn't explain why 123 and 1234 behaves differently.

It's funny how 1234 is not automatically interned, but 123 is.
https://stackoverflow.com/questions/13650293/understanding-pythons-is-operator

Python is allowed to automatically intern any immutable types, but not required to do so. Different implementations will intern different values.

CPython (the implementation you're using if you don't know which implementation you're using) auto-interns small integers and some special singletons like False, but not strings (or large integers, or small tuples, or anything else).

[Cerebus]

I didn't intend to check if the values are equal, and anyways, that doesn't explain why 123 and 1234 behaves differently.

It's funny how 1234 is not automatically interned, but 123 is.
https://stackoverflow.com/questions/13650293/understanding-pythons-is-operator

Python is allowed to automatically intern any immutable types, but not required to do so. Different implementations will intern different values.

CPython (the implementation you're using if you don't know which implementation you're using) auto-interns small integers and some special singletons like False, but not strings (or large integers, or small tuples, or anything else).

Which kind of undermines the whole point of interning in the first place. One wonders what kind of wooly thinking is involved in implementing something which one can't then rely on. Either identical values should have an is relationship or they shouldn't, they most certainly shouldn't have an is relationship for some subset of values and not for others, what bloody use is that? Even crazier is to only implement interning in the cases where it won't imbue some performance advantage and to not implement it in the cases where it will offer a performance advantage. It's like a cargo cult version of interning which offers neither dependability nor improved performance but just exists because someone has heard that 'interning' is good and thinks that having it will magically also cause the thing that has it in name only to be 'good'. Crazy.