Google in its in­fi­nite evil put this ar­ti­cle in my phone's news feed to­day. ¹

The ti­tle is "Why Python is not the pro­gram­ming lan­guage of the fu­ture" and ... well, I sort of agree with it. The fu­ture is a very long time, so I hope at some point Python will stop be­ing used for any­thing. I even sort of agree with the the­sis that Python will not be as rel­e­vant as it is now in 5 to 10 years, be­cause ... why not?

Al­though it's sur­pris­ing­ly hard to find a lan­guage re­plac­ing an­oth­er in the past. Python most­ly re­placed Perl as the gen­er­al pur­pose script­ing lan­guage, and maybe Python re­placed BA­SIC as the be­gin­ner's first lan­guage, but oth­er than that?

Usu­al­ly peo­ple start do­ing new things, and those things are done in a new­er lan­guage, and the old things are done in the old lan­guages ... FOR­EV­ER.

That is why there are still COBOL pro­gram­mers do­ing busi­ness log­ic in main­frames, there are still FOR­TRAN pro­gram­mers do­ing math code, and there are still C pro­gram­mers do­ing em­bed­ded, and so on, but there are JS pro­gram­mers do­ing we­bapp­s, and Kotlin or Swift pro­gram­mers do­ing mo­bile app­s, and go pro­gram­mers do­ing what­ev­er go pro­gram­mers do. ²

So, let's look at some of the things in the ar­ti­cle. The head­ings are copied from the orig­i­nal ar­ti­cle.

What makes Python popular right now

It's old

Well, yeah. So is JORF. What makes it pop­u­lar is not its age, but that the age has made it pos­si­ble for Python to have been pop­u­lar for a long time. Yes, it's cir­cu­lar and a bit un­in­ter­est­ing, but pop­u­lar­i­ty is self­-prop­a­gat­ing.

The dif­fer­ence be­tween Python and JORF is that Python has a user­base, not age. And how did Python get it's user­base? By be­ing good.

It’s beginner-friendly

Yep. Al­so, the au­thor men­tions that dy­nam­ic typ­ing is nice for be­gin­ner­s. In­deed! And be­ing nice for be­gin­ners is why Python is one of the two ex­am­ples I can think of for a pro­gram­ming lan­guage re­plac­ing an­oth­er.

It's versatile

Oh yeah! When you are a ca­su­al or be­gin­ning pro­gram­mer, a gen­er­al pur­pose pro­gram­mer is a gift from the goods of com­put­ing.

Me? One of my first pro­gram­ming lan­guages was POCO, an in­ter­pret­ed C em­bed­ded in Au­todesk An­i­ma­tor PRO for DOS. Ver­sa­tile that was­n't, and in­deed forced me to have to learn oth­er lan­guages lat­er on. I would much rather have learned Python in­stead.

It's al­so why Python is pop­u­lar in ML and sci­en­tif­ic com­put­ing. Learn one be­gin­ner-friend­ly lan­guage and do stuff ... it's ex­hil­a­rat­ing.

Downsides of Python - and whether they'll be fatal

Based on the pre­vi­ous elab­o­ra­tions, you could imag­ine that Python will stay on top of sh*t for ages to come.

Well, no. The fu­ture is long.

Speed

Python is slow. Like, re­al­ly slow. On av­er­age, you’ll need about 2–10 times longer to com­plete a task with Python than with any oth­er lan­guage.

Oh, have not tried Ruby, have you, you sweet sum­mer child?

In any case: yeah, Python is not par­tic­u­lar­ly fast. I should trans­late my "Python faster than C" light­ning talk to eng­lish some­time. Us­ing just tool­ing, with­out chang­ing the code it­self, Python can have a vari­a­tion in per­for­mance of 100x. ³

Here you can see it with sub­ti­tles if that's ok.

An­oth­er rea­son is that Python can on­ly ex­e­cute one task at a time. This is a con­se­quence of flex­i­ble datatypes — Python needs to make sure each vari­able has on­ly one datatype, and par­al­lel pro­cess­es could mess that up.

No. Nope. No no no no no no no. Not touch­ing that. But no.

In the end, it does­n't mat­ter be­cause ...

[...] none of the speed is­sues mat­ter. Com­put­ers and servers have got­ten so cheap that we’re talk­ing about frac­tions of sec­ond­s. And the end us­er does­n’t re­al­ly care whether their app loads in 0.001 or 0.01 sec­ond­s.

Scope

Yes, Python is dy­nam­i­cal­ly scope­d. How­ev­er ...

Python tried to tran­si­tion to stat­ic scop­ing, but messed it up. Usu­al­ly, in­ner scopes — for ex­am­ple func­tions with­in func­tions — would be able to see and change out­er scopes. In Python, in­ner scopes can on­ly see out­er scopes, but not change them. This leads to a lot of con­fu­sion.

If there is a lan­guage with dy­nam­ic scop­ing and first class func­tions where func­tions can change out­er scopes, I re­al­ly don't want to use that lan­guage. ⁴

Lambdas

De­spite all of the flex­i­bil­i­ty with­in Python, the us­age of Lamb­das is rather re­stric­tive. Lamb­das can on­ly be ex­pres­sions in Python, and not be state­ments.

Yes. If you want state­ments use a func­tion.

On the oth­er hand, vari­able dec­la­ra­tions and state­ments are al­ways state­ments. This means that Lamb­das can­not be used for them.

ENOPARSE. Sure, you can't as­sign to vari­ables in­side lamb­das. There is no point in as­sign­ing to vari­ables in­side lamb­das, since lamb­das are ex­pres­sion­s. Al­so, yes, "s­tate­ments are al­ways state­ments".

Whitespaces

Oth­er lan­guages, for ex­am­ple C++, re­ly more on braces and semi­colon­s. While this might not be vis­ual­ly ap­peal­ing and be­gin­ner-friend­ly, it makes the code a lot more main­tain­able. For big­ger pro­ject­s, this is a lot more use­ful.

Ci­ta­tion need­ed. Al­so, Haskell is not new­er than Python.

Mobile Development

In­deed mo­bile de­vel­op­ment in Python is not awe­some.

Runtime Errors

A Python script is­n’t com­piled first and then ex­e­cut­ed.

Yes it is.

In­stead, it com­piles ev­ery time you ex­e­cute it

No it does­n't.

so any cod­ing er­ror man­i­fests it­self at run­time.

No they don't.

This leads to poor per­for­mance, time con­sump­tion, and the need for a lot of test­s. Like, a lot of test­s.

This is great for be­gin­ners since test­ing teach­es them a lot. But for sea­soned de­vel­op­er­s, hav­ing to de­bug a com­plex pro­gram in Python makes them go awry. This lack of per­for­mance is the big­gest fac­tor that sets a time­stamp on Python.

I am lit­er­al­ly mak­ing ges­tures at my screen.

First of al­l, there was a whole oth­er sec­tion about speed, so why is speed not crit­i­cal there but it's the big­gest fac­tor here?

Al­so, is the au­thor say­ing test­ing is great for be­gin­ners but not for "sea­soned de­vel­op­er­s"? Well cov­er me in salt and pep­per be­cause I must lack sea­son­ing.

Af­ter this he pro­pos­es that Rust, Go and Ju­lia will re­place Python in the next five to ten years. Who knows? May­be?

I sus­pect Rust is a bit too com­pli­cat­ed and low lev­el and Ju­lia too speci­fic, and Go is nice but bor­ing to write. But hey, lan­guages change, things change, I am not a psy­chic.

Since ev­ery­one is in lock­down and I am no ex­cep­tion, I have spent some of my time do­ing things in open source project­s. Let me in­tro­duce you two new plug­ins for Niko­la my favourite stat­ic site gen­er­a­tor.

1. marko

   Yet an­oth­er im­­ple­­men­­ta­­tion of Mark­­down! And since adding sup­­port for new im­­ple­­men­­ta­­tions of mark­­down is easy, I added it.

   Marko has some in­­ter­est­ing ideas. If a ecosys­tem of ex­ten­­sions de­vel­op­s, it will be easy to sup­­port them on the Niko­la side.

2. myst

   Yes, an­oth­er mark­­down but, again, one with orig­i­­nal ideas. In this case, myst has a lot of re­Struc­­tured Text flavour, with sup­­port for di­rec­­tives and roles.

Of course when us­ing marko or myst in Niko­la you al­so get sup­port for short­codes so they are ex­tra-ex­ten­si­ble here.

If you are look­ing for a stat­ic site gen­er­a­tor, I am fair­ly sure "it does­n't sup­port my favourite markup lan­guage" is not a rea­son not to choose Niko­la :-)

My site is cre­at­ed us­ing a tool I start­ed and on which I have put a ton of ef­fort over the last 10 years or so, called Niko­la, which is a stat­ic site gen­er­a­tor (SS­G).

One of the sell­ing points of SS­Gs is that the pro­duced sites are fast and I have al­ways tak­en care to check, ev­ery once in a while, that my site was fast ... but not late­ly. And when I checked on Google Page­Speed In­sights I was hor­ri­fied to see it scor­ing 20 points out of 100.

So, I start­ed to see what the heck had hap­pened.

Google PageSpeed HATES Youtube

Each em­bed­ded video is seen as 4MB of block­ing things load­ing and mak­ing your page suck.

So­lu­tion: de­fer load­ing them us­ing http­s://github.­com/­group­board­/yt­de­fer

Bundling things still works

It has been years since it was promised that bundling mul­ti­ple CSS files in­to a large one or merg­ing mul­ti­ple JS files in­to a sin­gle script would not be worth it.

Well, ac­cord­ing to Page­Speed, it's still worth it. Luck­i­ly Niko­la has good sup­port for it, so I made sure EV­ERY­THING was bun­dled. That al­so in­volved get­ting some things off CDNs and in­to my as­sets fold­er:

• pris­mjs
• jquery

Google fonts are SLOW

Like, 400ms for two fonts. So, you can self­-host them us­ing http­s://­google-web­fonts-helper.herokuap­p.­com/­fonts

Al­so:

• use font-display: swap
• preload the fonts using something like <link rel="preload" href="/assets/fonts/pt-serif-v11-latin-regular.woff2" as="font">

Check CSS for @import

Even after bundling them, if a CSS file uses @import that will still be a separate request.

Check compression and caching

Make sure your web serv­er is do­ing the right things there.

Remove useless stuff

I was load­ing font-awe­some for ONE ICON. There, gone.

Did it work?

Now the score hov­ers around 96 to 98 so, yes it did. And in­deed the page feels very, very snap­py.

I have been writ­ing some of my posts us­ing Mark­down late­ly. And not even plain old Python Mark­down, but mis­a­ka which is an al­ter­na­tive im­ple­men­ta­tion based on Hoe­down

So, I no­ticed that those mark­down files had no syn­tax high­light­ing! I looked and Mis­a­ka does of­fer some­thing to "high­light things". Here is what it does:

<pre>
<code class="language-python">
def f():
    pass
</code>
</pre>

No class­es in the el­e­ments, no noth­ing, just a class in the code el­e­men­t! It turns out that is the rec­om­mend­ed way to in­di­cate you are show­ing code:

There is no for­mal way to in­di­cate the lan­guage of com­put­er code be­ing marked up. Au­thors who wish to mark code el­e­ments with the lan­guage used, e.g. so that syn­tax high­light­ing scripts can use the right rules, can use the class at­tribute, e.g. by adding a class pre­fixed with "lan­guage-" to the el­e­men­t.

So, I looked for how to ac­tu­al­ly dis­play those things nice­ly, and found pris­mjs.­com which looked very nice!

So nice, in­deed, that now I hat­ed how my re­Struc­tured Text Pages looked!

There­fore, I wrote a new Niko­la plug­in that re­places do­cu­til­s' code di­rec­tive and re­places it with a much sim­pler one that just tags things as code of a giv­en lan­guage and lets prism do the rest.

AFAICS it's functionally equivalent, it supports the :linenos: option, including shifted line numbers.

I doubt any­one ev­er will want to use it but hey, there it is.