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.
UPDATE: After fixing bugs, it turns out the improvement is roughly 25%, not 75%, which is still nice :-)
Image galleries is one of my favourite features in Nikola
I use them in my site and they are awesome! Just dump a bunch of images in a folder and you will have them nicely presented. Then you can add
a file with a folder description amd so on.
One thing I did not like was that they were pretty slow. My site has 3290
images in the galleries section, and I dreaded processing them because they took forever, where forever means around 5 minutes.
Unrelated to performance, we had a feature request for supporting multiple thumbnail
sizes, which is useful for things like presenting the ideal image size for your display and such.
Well, to support that someday, a good first step is to have our generic image processor class support more than one thumbnail size. So, just take the scale_image implementation and have it support more than one size and more than
one destination path, then loop over those, and that's that. Right?
OTOH, it turns out we processed each image TWICE because we would clean EXIF data
and/or resize the "original" images. Sometimes the source images have resolutions that simply make no sense on a website!
So, since our implementation of scale_image only accepted one destination, we would:
read original image -> cleanup -> resize to thumb size -> save
read original image -> cleanup -> resize to "large" size -> save
So, since I had now a version that could do the "resize" and "save" parts on one call, this became:
read original image -> cleanup
resize to thumb size -> save
resize to "large" size -> save
And the really slow part is ... reading the original image. So this suddenly made
the whole process take 25% of the time it took before.
In my specific site, it went down from 356 seconds to 112 seconds. That's a 70%
decrease in rendering time. Which is big. And in code I first wrote around
2013, that is huge.
So, the lesson is ... I am a crappy programmer, maybe? Or used to be? Or maybe just
that even old, mature code could still have large opportunities for improvement?
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. ↩