Python becomes the most popular language

[brucehoult]

And at the end of the day CPUs run machine code. Another interesting point is that soft devs arguing about which programming language might be the best often treat CPUs as a magic black box. But all the different CPU architectures, designs and add-ons have an impact on what can be done with a specific CPU. We should consider the whole package!

The difference between Instruction Sets surviving in 2022 is pretty minor. One of them is much harder to implement well than than others -- but the companies using that one have a lot of money from their historical near-monopoly.

It matters a bit how wide memory addresses and ALUs are, and whether or not there is an FPU and (these days) SIMD.

But all this pales compared to the efficiency of programming languages.

A RISC-V CPU you design yourself in a weekend and implement in an FPGA runs C code roughly as quickly as the fastest Intel or AMD CPU that had billions of dollars spent on it runs Python.

[mansaxel]

an installation of a horrible Perl web groupware

We need names!

I don't wanna, because I actually like the authors, and I don't want them get pissed at me.

Fair.

Actually, I've never been burned by Perl. Speaks mostly about my inexperience of course.

Still, I've produced working systems that use Perl, mostly making up for lacking functions in other stuff. 

[Nominal Animal]

Still, I've produced working systems that use Perl, mostly making up for lacking functions in other stuff.

Yup; there is quite a lot of perfectly okay Perl code out there.

Typically, the pain-inducing features of a codebase are when there is no proper structure and organization, and instead code gets copied around, and occasionally modified –– the exact wrong kind of code reuse.  Without proper comments and documentation, and without any modular or organized approach, the interdependencies in the code quickly become so complicated, that "code spaghetti" becomes an apt description.

If you learn Perl by working with well-organized code, you mostly see the power and ease of Perl expressions. But, if basically the only Perl code you work with for a couple of years is copy-pasta spaghetti, I'm sure you can see why one might develop to an aversion to the language, even though it's not the languages fault per se.

[SiliconWizard]

If you learn Perl by working with well-organized code, you mostly see the power and ease of Perl expressions. But, if basically the only Perl code you work with for a couple of years is copy-pasta spaghetti, I'm sure you can see why one might develop to an aversion to the language, even though it's not the languages fault per se.

That is true for any language, even. =)

[Nominal Animal]

If you learn Perl by working with well-organized code, you mostly see the power and ease of Perl expressions. But, if basically the only Perl code you work with for a couple of years is copy-pasta spaghetti, I'm sure you can see why one might develop to an aversion to the language, even though it's not the languages fault per se.

That is true for any language, even. =)

Languages with more concise and powerful expressions are a bit more vulnerable to it, though.

At the extreme end, things like complex regular expressions are pretty much write-only by humans.
At the simple end, in languages like Basic spaghetti code doesn't really differ that much from ordinary code; I do not think I could describe how "beautiful basic" would differ from "spaghetti basic" at all.

I also severely dislike the Systems Hungarian notation, where the type of a variable is part of the variable name.  I'm not sure where that came from; perhaps it is the repetition that annoys me. 

[Cerebus]

I also severely dislike the Systems Hungarian notation, where the type of a variable is part of the variable name.  I'm not sure where that came from; perhaps it is the repetition that annoys me. 

Popularising it is Microsoft's fault. The original instigator is probably languages that infer type from the initial letter of a variable e.g. IMPLICIT types in FORTRAN.

[mansaxel]

What do you use to *debug* PHP?

A very strong degausser on the storage media. That should teach it.

[Bassman59]

I also severely dislike the Systems Hungarian notation, where the type of a variable is part of the variable name.  I'm not sure where that came from; perhaps it is the repetition that annoys me. 

Hungarian notation was invented by an actual Hungarian, Charles Simonyi, originally at Xerox PARC, later of Microsoft.

[Bassman59]

What do you use to *debug* PHP?

A very strong degausser on the storage media. That should teach it.

That's the problem with these newfangled SSDs. A degausser won't work. I suggest a flamethrower.

[Nominal Animal]

I also severely dislike the Systems Hungarian notation, where the type of a variable is part of the variable name.  I'm not sure where that came from; perhaps it is the repetition that annoys me. 

Popularising it is Microsoft's fault. The original instigator is probably languages that infer type from the initial letter of a variable e.g. IMPLICIT types in FORTRAN.

I mentioned it, of course, because of Perl sigils ($ for scalars, @ for arrays, and % for hashes, & for subroutines, and * for typeglobs).

I thought about this for a while, and I think that the variable name represents the purpose of the variable for me in my mind at the abstract level, and having the type or form associated with the name hinders my ability to keep to the abstract level, and drags my feeble mind to the implementation level where I worry about such implementation details.  Essentially, it makes it more difficult for me to bounce between complexity levels; me being not capable of encompassing huge complex structures at once at multiple different complexity levels... I'm certain that for others the sigils (and even Systems Hungarian type prefixes) help them in other ways, and see this as a stupid limitation, but this is my only mind I have to work with, and I just have to deal with its weaknesses the best I can.

What do you use to *debug* PHP?

A very strong degausser on the storage media. That should teach it.

What about PHP code that is rock solid?  Granted, that stuff is basically write-only code.

"This is absolutely paranoid" is something I have heard from more than one person reading my PHP code.  Several times, weeks or months after putting the code into production, a coworker has heard of a new Apache attack pattern, and emails me in panic, just to get a reply from me pointing out which part of my paranoid filter completely defuses that particular attack.

I used to giggle and cackle to myself with glee, when looking at Apache log files full of failed access attempts with some part of the query being ../../../../windows/system/cmd.exe, query strings containing %00, and similar shenanigans.. Like I said earlier, my PHP code sanitized even the CGI environment variables.  Usually, I convert raw and urlencoded Western European non-ASCII letters (including ÅÄÖØÆåäöøæ) to their closest ASCII 'equivalents', then filter stuff like consecutive . and / out (eliminating any such consecutive pairs, ./ and /. altogether), and finally filter out all non-safe characters out.  The end result is that no path shenanigans can pass through, no matter what you try.

But, it wasn't fun writing it in PHP, because PHP has overlapping orthogonal interfaces doing the exact same thing (both OO and non-OO imperative), and it was basically impossible to see how the language developers envisioned it being used properly.  Especially during the efforts of making PHP easier for non-programmers to use "safely" –– things like magic quote support ––, one had to actively fight against idiocy, to make things secure.  One could trust nothing, and really needed to be paranoid, or the PHP devs helpful attempts would bite one in the ass, hard.  At least Python has PEPs, for what they're worth.

(And I cannot tell you how often I had to endure the question, "Are you sure this is necessary?  Couldn't we just do simpler-but-less-secure-method?".  Still makes me sad and depressed getting asked that, actually.)

I also severely dislike the Systems Hungarian notation, where the type of a variable is part of the variable name.  I'm not sure where that came from; perhaps it is the repetition that annoys me. 

Hungarian notation was invented by an actual Hungarian, Charles Simonyi, originally at Xerox PARC, later of Microsoft.

By 'that', I was referring to my severe dislike, not to Systems Hungarian.
That is, I don't know where my severe dislike of Systems Hungarian stems from.  I do know how and where Systems Hungarian came about.

Apologies for being unclear; me fail English

[mansaxel]

What do you use to *debug* PHP?

A very strong degausser on the storage media. That should teach it.

That's the problem with these newfangled SSDs. A degausser won't work. I suggest a flamethrower.

I was going to suggest one of those thermite weld pots they use to join rails. That's pretty definitive.

https://youtu.be/5uxsFglz2ig

but I thought that a degausser would be more classique.

[Nominal Animal]

I was going to suggest one of those thermite weld pots they use to join rails. That's pretty definitive.

I don't think my "explosion containment pie dish" (per BigClive) could handle thermite, though.  Darned stuff burns through everything.

Perhaps an industrial shredder?

[brucehoult]

If you learn Perl by working with well-organized code, you mostly see the power and ease of Perl expressions. But, if basically the only Perl code you work with for a couple of years is copy-pasta spaghetti, I'm sure you can see why one might develop to an aversion to the language, even though it's not the languages fault per se.

That is true for any language, even. =)

Languages with more concise and powerful expressions are a bit more vulnerable to it, though.

At the extreme end, things like complex regular expressions are pretty much write-only by humans.

That's the fault of the reader not taking enough time. It's the same as people complaining mathematics or physics are hard because they try to read pages full of equations in textbooks as quickly as they read pages from a spy novel – and often not even studying what ∫ or ∑ or other symbols actually mean. Or *, +, ? etc in regular expressions.

SLOW DOWN!

It's a heck of a lot easier to read and understand a regular expression than to read and understand C or BASIC or COBOL code that recognises the same pattern -- let alone assembly language code.

[brucehoult]

I also severely dislike the Systems Hungarian notation, where the type of a variable is part of the variable name.  I'm not sure where that came from; perhaps it is the repetition that annoys me. 

Popularising it is Microsoft's fault. The original instigator is probably languages that infer type from the initial letter of a variable e.g. IMPLICIT types in FORTRAN.

I mentioned it, of course, because of Perl sigils ($ for scalars, @ for arrays, and % for hashes, & for subroutines, and * for typeglobs).

That's not the type of the variable, it's the namespace.

It's just like "foo" vs "struct foo" in C. "foo" is from the namespace of runtime values, "struct foo" is from the namespace of types.

Or like the difference between "foo" and "(function foo)" in Common Lisp where there are different namespaces for variables and functions. This is mostly transparent because Lisp knows that in (a b c) "a" is in the function namespace while "b" and "c" are in the variables namespace, but from time to time you want to store a reference to a function in a variable or pass it as an argument, and then later you want to use the value in that variable as a function to call.

Code: [Select]

(defun square (x) (* x x))
(square 9)
=> 81
(set 'foo (function square))
(funcall foo (13))
=> 169

Perl just has a lot more namespaces than the other languages, and less ability to implicitly know which namespace you mean just from context.

Note that Perl *does* know implicitly that you want to access the value of the function namespace and call the function &foo when you just write foo(13), so you only have to write the & in the same kind of situation that you use (function foo) in Lisp.

I personally prefer programming languages with a single namespace — such as Pascal, Dylan, Scheme — but I seem to be in a minority. I've learned to cope. By reading the respective manuals.

[Nominal Animal]

If you learn Perl by working with well-organized code, you mostly see the power and ease of Perl expressions. But, if basically the only Perl code you work with for a couple of years is copy-pasta spaghetti, I'm sure you can see why one might develop to an aversion to the language, even though it's not the languages fault per se.

That is true for any language, even. =)

Languages with more concise and powerful expressions are a bit more vulnerable to it, though.

At the extreme end, things like complex regular expressions are pretty much write-only by humans.

That's the fault of the reader not taking enough time. It's the same as people complaining mathematics or physics are hard because they try to read pages full of equations in textbooks as quickly as they read pages from a spy novel – and often not even studying what ∫ or ∑ or other symbols actually mean. Or *, +, ? etc in regular expressions.

I disagree, because modifying a complex regular expression is completely different to understanding one.

As an overly simplified example, consider the regular expression /ab*c/.  This matches any substring starting with a, ending with c, and containing only zero or more b in between.  Because of a change elsewhere, we now need to change this expression so that it matches those substrings, but also the ones that start with ac followed by zero or more d after, matching the longest matching substring of course.  Do you modify the expression, or do you rewrite it?

By "write-only", I mean that even if you fully understand what the code (or here, expression) does, modification may not be feasible, and rewriting the part will actually save time and effort, and yield a more reliable result.

SLOW DOWN!

That I do agree with.

Perhaps I chose the term, "write-only", poorly.  I only now realize that it is typically used to refer to code that is too difficult to understand and is better just rewritten to achieve the same result.  Here, I meant it in the sense that when the syntax is concise and efficient enough, even small changes are "better" (more reliably and in less time) implemented by rewriting the expression instead of modifying it.

Granted, finite state machines tend to be so complex that to maintain one, one usually relies on external documentation for it, describing the states and their relationships; so that modifying the code depends much more about understanding the state machine the code represents, and very little on understanding exactly how the code implements the state machine.  (Basically, understanding just the states that are affected by the change is enough.)

For most regular expressions (excepting the monsters like the one that verifies valid email addresses) one can build the model in ones mind from the regular expression easier than one can build it from the corresponding C, BASIC, or COBOL code, yes.

All those are inferior to actually properly documenting the finite state machine properly in the first place –– even as the separate patterns that the regular expression can match, say using augmented Backus-Naur form as described in RFC 2234. Because most developers will have to read RFCs at some point, and aBNF is the most commonly used form in them, it makes for a suitable format in my opinion.

I personally prefer programming languages with a single namespace — such as Pascal, Dylan, Scheme — but I seem to be in a minority. I've learned to cope. By reading the respective manuals.

Is that a veiled insult suggesting that I just don't get it because I do not read manuals, eh?

I am well aware of Perl general documentation and perldoc.perl.org, and very recently reread some of the tutorials to refresh my memory.  I have been very clear that I do not consider my own hangups with Perl the fault of the language. 

[brucehoult]

If you learn Perl by working with well-organized code, you mostly see the power and ease of Perl expressions. But, if basically the only Perl code you work with for a couple of years is copy-pasta spaghetti, I'm sure you can see why one might develop to an aversion to the language, even though it's not the languages fault per se.

That is true for any language, even. =)

Languages with more concise and powerful expressions are a bit more vulnerable to it, though.

At the extreme end, things like complex regular expressions are pretty much write-only by humans.

That's the fault of the reader not taking enough time. It's the same as people complaining mathematics or physics are hard because they try to read pages full of equations in textbooks as quickly as they read pages from a spy novel – and often not even studying what ∫ or ∑ or other symbols actually mean. Or *, +, ? etc in regular expressions.

I disagree, because modifying a complex regular expression is completely different to understanding one.

As an overly simplified example, consider the regular expression /ab*c/.  This matches any substring starting with a, ending with c, and containing only zero or more b in between.  Because of a change elsewhere, we now need to change this expression so that it matches those substrings, but also the ones that start with ac followed by zero or more d after, matching the longest matching substring of course.  Do you modify the expression, or do you rewrite it?

Is there something wrong with inserting "|acd*" at the end (or "acd*|" at the beginning? Seems fairly straightforward, and the NDA->DFA conversion will factor out the common "a" for you.

If a and/or c are at all complex you can factor them out in very much the same way as in BNF.

For example ... oh, I don't know ...

Code: [Select]

if ($ARGV[0] =~
    /^(?&fpconst)$
(?(DEFINE)
(?<osg>[-+]?)         # optional sign
    (?<int>\d++)          # integer
    (?<dec>\.(?&int)?)    # decimal fraction
    (?<fpconst>(?&osg)\ * ( (?&int)(?&dec)? | (?&dec) )(?: [eE](?&osg)(?&int) )?)
    )/x
){
    print "yes\n";
} else {
    print "no\n";
}


Code: [Select]

$ perl isfp.pl 123
yes
$ perl isfp.pl 123e
no
$ perl isfp.pl 123e4
yes
$ perl isfp.pl 123.e4
yes
$ perl isfp.pl 123.34e4
yes
$ perl isfp.pl 123.
yes


By "write-only", I mean that even if you fully understand what the code (or here, expression) does, modification may not be feasible, and rewriting the part will actually save time and effort, and yield a more reliable result.

Fair enough but as you yourself said, that's not what is usually meant by "write-only".

I personally prefer programming languages with a single namespace — such as Pascal, Dylan, Scheme — but I seem to be in a minority. I've learned to cope. By reading the respective manuals.

Is that a veiled insult suggesting that I just don't get it because I do not read manuals, eh?

Nope, it's about me. I try not to be ambiguous about insulting someone, or do it by accident.

[Nominal Animal]

By "write-only", I mean that even if you fully understand what the code (or here, expression) does, modification may not be feasible, and rewriting the part will actually save time and effort, and yield a more reliable result.

Fair enough but as you yourself said, that's not what is usually meant by "write-only".

Righty-o.  I wonder what term I should use for this, because it is actually a situation I encounter relatively often (say, once a month at least).

I do unit test both the old form and the new form of whatever function or structure or thing is involved.  I don't do rewrites because I'm not arsed to fully understand the existing code; I only do it when I do have a better form, and verify it indeed is better (using whatever definition of "better" is appropriate in each particular case).

Oh, and I do relatively often find out that the idea I had actually does not yield a better solution.  When that happens, I document it, and use the original.
This is a large part of why I have done so many (at least a couple of thousand) "unit test cases" (mostly programming, some math):  Theory is nice and good and useful, but practical reality rules.

I personally prefer programming languages with a single namespace — such as Pascal, Dylan, Scheme — but I seem to be in a minority. I've learned to cope. By reading the respective manuals.

Is that a veiled insult suggesting that I just don't get it because I do not read manuals, eh?

Nope, it's about me. I try not to be ambiguous about insulting someone, or do it by accident.

Ah; thank you.  Good to hear.

I do not do veiled insults at all, but I do often fail in English, and end up inadvertently offending people (like yourself, if you happen to remember).  Online, it is difficult to tell.

I am rather sensitive about this in this topic, because I am the only one who openly admits that they dislike a specific programming language because of a purely personal, subjective reason, and not due to some rational reason.  Those who have said they refuse to use Python because it uses whitespace indentation to denote code structures, have simply claimed they do so because "Python is stupid" and similar variants.  To me, being honest in this way is not admitting a weakness, because those underlying reasons are what sway – and should sway – those without much experience reading this thread.  Everyone has an opinion, but the important things are the reasons behind those opinions, because they are the only way to rationally evaluate the merits of each opinion.  However, this kind of honesty is often taken as a sign of weakness, usually worthy of denigration.

I did jump the keyboard, though: if I had stopped to consider the author, I would have realized it was not intended as an insult.  Apologies.

[RoGeorge]

That is why namespaces are good.
 

[mansaxel]

I was going to suggest one of those thermite weld pots they use to join rails. That's pretty definitive.

I don't think my "explosion containment pie dish" (per BigClive) could handle thermite, though.  Darned stuff burns through everything.

Perhaps an industrial shredder?

Shredding harddrives is fun. Before such things were available, I used to take them apart, and cut the platters into small strips with a metal shears before distributing the slivers one in each waste basket on a stroll through town.  Being a bit tedious, this operation was reserved for things like Kerberos KDC machines and such.

[Nominal Animal]

Shredding harddrives is fun. Before such things were available, I used to take them apart, and cut the platters into small strips with a metal shears before distributing the slivers one in each waste basket on a stroll through town.  Being a bit tedious, this operation was reserved for things like Kerberos KDC machines and such.

A hot torch is easier.  Just burn the thin coating off the aluminium platter, and twist it into a pretzel.  Assuming fume extraction is available, of course.  Then the bit carrying parts literally do not exist anymore.

Actually, recovering data from a physically malformed platter is nigh impossible, so just taking out the platters and hammering or otherwise taking your frustration out on them a bit is more than enough.
Plus, the magnets are quite fun to play with, and when taken apart, the boards and spindle magnetics can be put in e-waste, and the cast aluminium parts in metal recycling.

[Cerebus]

Shredding harddrives is fun. Before such things were available, I used to take them apart, and cut the platters into small strips with a metal shears before distributing the slivers one in each waste basket on a stroll through town.  Being a bit tedious, this operation was reserved for things like Kerberos KDC machines and such.

A hot torch is easier.  Just burn the thin coating off the aluminium platter, and twist it into a pretzel.  Assuming fume extraction is available, of course.  Then the bit carrying parts literally do not exist anymore.

Actually, recovering data from a physically malformed platter is nigh impossible, so just taking out the platters and hammering or otherwise taking your frustration out on them a bit is more than enough.
Plus, the magnets are quite fun to play with, and when taken apart, the boards and spindle magnetics can be put in e-waste, and the cast aluminium parts in metal recycling.

As always, these things depend on your "threat model", your value as a target and how much someone is prepared to pay to recover that data. I know people who have worked on networks of international importance, from domain registries to ISP/peering/telco networks ranging from "never heard of them" to household names who would be tempting targets both for criminals and three letter agencies. While lowly techies may not be of themselves particularly interesting, their credentials can get you places that people would pay big money to get to and at that point "nigh impossible" can change to "recoverable with enough money, a clean room, a tunnelling SEM and time". If you ran a TLA, what would you pay to get access to an SSH key or VPN keys for a techie who had 'root' or 'enable' on core networks of a large international telco?

[Nominal Animal]

at that point "nigh impossible" can change to "recoverable with enough money, a clean room, a tunnelling SEM and time".

That "nigh impossible" was based on the physics of the situation, and not current technological capabilities.

Each platter is basically an aluminium disc with a suitable thin Magik Sauce coating.  The coating exhibits one of the magnetoresistive effects: although it is a thin membrane or layer, at the atomic level it can be grouped into small cells with each cell having their own magnetic field.

(By measuring the exact magnetic field in each such cell using superconducting magnets in low temperatures, one can give a surprisingly reliable statistic on the possible states of this particular "bit".  Each write affects a relatively constant change in the magnetic field, so "past data" can often be uncovered from the current magnetic field, by comparing the magnetic field strength and direction among all such cells on that particular platter.  But, I'm just a physicist, and know of this in theory; the guys who design this stuff could describe it much better.  In the "cost does not matter" world, they do have access to cryogenic cooling with amazingly sensitive and precise magnetic sensors using superconducting materials, and reading e.g. a platter cut in two dozen pieces but otherwise intact is not a problem, that much I do know.)

The potential energy involved in that magnetic field is small.  Enough heat, and the increased motion of the atoms in the storage membrane will randomize the magnetic fields.  Physically deforming the platter also randomizes the magnetic fields in the deformed region.  (Chiefly, instead of somewhat clear cell boundaries, you get very soft transitions.)  Trying to re-form the surface back to semi-planar just worsens it, so does delaminating the layer from the aluminium substrate, because the aluminium actually forms the base lattice that helps keep the magnetic cells in place.

However, I stand by my suggestion of using an simple, cheap acetylene/propane torch, and simply burn off the data layer completely.  The atoms whose spins contained the data are then impossible to gather, much less put back together.  Plus, it is fun.  The fumes you get, however, can be quite, quite toxic (who knows exactly what they use as dopants here?). Hence, fume extraction and activated carbon filtering is kinda-sorta a must.

[Nominal Animal]

If you ran a TLA, what would you pay to get access to an SSH key or VPN keys for a techie who had 'root' or 'enable' on core networks of a large international telco?

Exactly.  The true professionals do not bother with your used hardware, they turn one of the workers instead.  There is always someone greedy enough, in too much debt, or with secrets to hide.  I suspect the higher ups are easier than the actual line workers to turn, though.

This is why 'wet work' (human-to-human) is so much more effective than technological monitoring.

[mansaxel]

If you ran a TLA, what would you pay to get access to an SSH key or VPN keys for a techie who had 'root' or 'enable' on core networks of a large international telco?

I once happened to run tcpdump on the WiFi at a RIPE meeting. That was educational. Telnetting to the jumphost and THEN using SSH to log on to the core router does not help if I'm listening in on the first hop...   

[Picuino]

There seems to be a project to speed up CPython by a factor of x2 to x5 in the next few years.

https://github.com/faster-cpython

Presentation of Guido van Rossum (May 2021): https://github.com/faster-cpython/ideas/blob/main/FasterCPythonDark.pdf

Edit:
https://faster-cpython.readthedocs.io/
https://www.theregister.com/2021/05/13/guido_van_rossum_cpython_3_11/