A few years back when I was working at Canonical, I made Nikola packages for the Snap store ... which sadly got neglected a fair amount after I stopped
SO ... while I don't work there, there is no reason for neglect, so I just fixed the build,
updated some snapcraft.yml details
that had rusted from disuse, checked the automated build and promoted current git master to the
What does this mean for you?
Well, probably nothing, but if you want to try Nikola, you can do this:
snap install nikola
At least in Ubuntu, Ubuntu derivatives and Arch derivatives if you have snapd installed, and
end up with a working installation of Nikola.
Now, is this the recommended way to get it? No. This has a number of problems because of the
nature of snap packaging.
You can't launch binaries so some features will just not work (example: nikola serve -b).
You can't install python packages into the snap, so if you install a plugin with a python
dependency, it will not work unless by chance that dependency is there already (I added some!)
I am not testing it much, so there is no guarantee it works on any given day (But it should!)
If you are using Nikola as a snap and run into any issues, ping me via an issue.
Sometimes I may take a while to get to it, but I will get to it.
Google in its infinite evil put this article in my phone's news feed today. 1
The title is "Why Python is not the programming language of the future" and ... well,
I sort of agree with it. The future is a very long time, so I hope at some point Python
will stop being used for anything. I even sort of agree with the thesis that Python
will not be as relevant as it is now in 5 to 10 years, because ... why not?
Although it's surprisingly hard to find a language replacing another in the past.
Python mostly replaced Perl as the general purpose scripting language, and maybe Python replaced BASIC as the beginner's first language, but other than that?
Usually people start doing new things, and those things are done in a newer
language, and the old things are done in the old languages ... FOREVER.
That is why there are still COBOL programmers doing business logic in mainframes,
there are still FORTRAN programmers doing math code, and there are still C programmers
doing embedded, and so on, but there are JS programmers doing webapps, and Kotlin or Swift
programmers doing mobile apps, and go programmers doing whatever go programmers do. 2
So, let's look at some of the things in the article. The headings are copied from the original article.
What makes Python popular right now
Well, yeah. So is JORF. What makes it popular is not its age, but that the age has made it possible for Python to have been popular for a
long time. Yes, it's circular and a bit uninteresting, but popularity is self-propagating.
The difference between Python and JORF is that Python has a userbase, not age. And how
did Python get it's userbase? By being good.
Yep. Also, the author mentions that dynamic typing is nice for beginners. Indeed!
And being nice for beginners is why Python is one of the two examples I can think of
for a programming language replacing another.
Oh yeah! When you are a casual or beginning programmer, a general purpose programmer
is a gift from the goods of computing.
Me? One of my first programming languages was POCO, an interpreted C embedded in
Autodesk Animator PRO for DOS. Versatile that wasn't, and indeed forced me to have
to learn other languages later on. I would much rather have learned Python instead.
It's also why Python is popular in ML and scientific computing. Learn one beginner-friendly
language and do stuff ... it's exhilarating.
Downsides of Python - and whether they'll be fatal
Based on the previous elaborations, you could imagine that Python will stay on top of sh*t for ages to come.
Well, no. The future is long.
Python is slow. Like, really slow. On average, you’ll need about 2–10 times longer to complete a task with Python than with any other language.
Oh, have not tried Ruby, have you, you sweet summer child?
In any case: yeah, Python is not particularly fast. I should translate my "Python faster than C" lightning talk to english sometime. Using just tooling, without changing the code itself,
Python can have a variation in performance of 100x. 3
Here you can see it with subtitles if that's ok.
Another reason is that Python can only execute one task at a time. This is a consequence of flexible datatypes — Python needs to make sure each variable has only one datatype, and parallel processes could mess that up.
No. Nope. No no no no no no no. Not touching that. But no.
In the end, it doesn't matter because ...
[...] none of the speed issues matter. Computers and servers have gotten so cheap that we’re talking about fractions of seconds. And the end user doesn’t really care whether their app loads in 0.001 or 0.01 seconds.
Yes, Python is dynamically scoped. However ...
Python tried to transition to static scoping, but messed it up. Usually, inner scopes — for example functions within functions — would be able to see and change outer scopes. In Python, inner scopes can only see outer scopes, but not change them. This leads to a lot of confusion.
If there is a language with dynamic scoping and first class functions where functions can change outer scopes, I really don't want to use that language. 4
Despite all of the flexibility within Python, the usage of Lambdas is rather restrictive. Lambdas can only be expressions in Python, and not be statements.
Yes. If you want statements use a function.
On the other hand, variable declarations and statements are always statements. This means that Lambdas cannot be used for them.
ENOPARSE. Sure, you can't assign to variables inside lambdas. There is no point in assigning to variables inside lambdas, since lambdas are expressions. Also, yes, "statements are always statements".
Other languages, for example C++, rely more on braces and semicolons. While this might not be visually appealing and beginner-friendly, it makes the code a lot more maintainable. For bigger projects, this is a lot more useful.
Citation needed. Also, Haskell is not newer than Python.
Indeed mobile development in Python is not awesome.
A Python script isn’t compiled first and then executed.
Yes it is.
Instead, it compiles every time you execute it
No it doesn't.
so any coding error manifests itself at runtime.
No they don't.
This leads to poor performance, time consumption, and the need for a lot of tests. Like, a lot of tests.
This is great for beginners since testing teaches them a lot. But for seasoned developers, having to debug a complex program in Python makes them go awry. This lack of performance is the biggest factor that sets a timestamp on Python.
I am literally making gestures at my screen.
First of all, there was a whole other section about speed, so why is speed not critical there but it's the biggest factor here?
Also, is the author saying testing is great for beginners but not for "seasoned developers"? Well cover me in salt and pepper because I must lack seasoning.
After this he proposes that Rust, Go and Julia will replace Python in the next five to ten years. Who knows? Maybe?
I suspect Rust is a bit too complicated and low level and Julia too specific, and Go is nice but boring to write. But hey, languages change, things change, I am not a psychic.
No, Google is probably not evil, but come on, it's a good opening. ↩
Since everyone is in lockdown and I am no exception, I have spent some of my time doing
things in open source projects. Let me introduce you two new plugins for Nikola my favourite static site generator.
There is no formal way to indicate the language of computer code being marked up. Authors who wish to mark code elements with the language used, e.g. so that syntax highlighting scripts can use the right rules, can use the class attribute, e.g. by adding a class prefixed with "language-" to the element.
So, I looked for how to actually display those things nicely, and found prismjs.com
which looked very nice!
So nice, indeed, that now I hated how my reStructured Text Pages looked!
Therefore, I wrote a new Nikola plugin that replaces docutils' code directive and replaces it with a much simpler one
that just tags things as code of a given language and lets prism do the rest.
AFAICS it's functionally equivalent, it supports the :linenos: option, including
shifted line numbers.
I doubt anyone ever will want to use it but hey, there it is.