> It has been built at a glacial pace, over a period of seven years, as my website expanded in content.
Three cheers for slow software. Thoughtful solutions are under-appreciated. I'm surprised how many junior devs I need to convince that the fact that programs like vi, emacs, make and TeX are 40+ years old is a _good_ thing.
When the new and exiting software gets older, it accumulates cruft and can fall under the weight of features. Software that that keeps going and keeps going past 40+ years has found a way to survive time.
The mental front investment required to learn emacs (or vi) and TeX just keeps paying dividends. After using emacs for two decades it's like brain implant.
Of course you can. The question is, whether the correlation is strong or weak, and what sign it has.
I'd argue the correlation is positive and somewhat strong, for the following reasons:
- Survivorship effect (not really bias in this context): old software that survived and is still used to this day survived for the reason. Old legacy systems in companies may survive because they're too expensive to replace, but old end-user software survived because it is good. Often, it's better than any new software - vi(m), Emacs and TeX all are - and so they kind of suck the oxygen out of the room (why build a new, better vim, when real vim can be made better faster?).
- The times of vi(m), Emacs and TeX were much saner. It was because web apps were the dominant mode of building end-user software, it was before SaaS was the dominant business model - and both of those incentivize bad software that's disrespectful of user's cognitive and computational resources (not to mention privacy). People cared more about end-user ergonomics than developer team velocity. People cared about performance, because it was a difference between a working and not-working application. Today's software doesn't care, because bad performance only means the user can't run more than few applications simultaneously, and that's not any individual vendor's problem.
So yeah, I find it to be a good heuristic that old end-user software that's still in use is going to be better than new software, if you're willing to overlook some idiosyncrasies of the past.
Sometimes these "idiosyncrasies" are quite relevant: LaTeX is still 8 bit and uses a number of fixed-size tables for managing objects (resulting in a numer of "weird" limitations), the way TeX processes documents is quite complex and not particularly fast (depending on what you compare it to), it only supports it's own fonts and none of the industry standards and so on
There's thousands of video games that are still around and are not 'good'. Win XP was used for years (decade?) and the question of it's goodness was up for debate for a long time. Something that's older will have more security issues. You can say WinXP did a lot of good things for it's time (sane networking, ect), but it's ability to fulfill the role 'good enough' waned pretty quickly.
Vim/emacs/notepad++ are all good enough text editors, there's not much call for machine learning ai on text editing, what new conceptual application is there for text editing tech? Excel has been the same for ten years because it fills a finite hole. There are other products that age quickly spill over to categories of programming that can always benefit from the infinity of detail or quality and don't fill a fixed finite hole. e.g. video games.
Yeah computers as a rising force of workhorse power is only now restarting. We had a period of stagnation for a while.
The basic tech behind it. The ui has changed a lot. There was an article a year or so ago saying the engineering team doesn't get a lot of big meaty change to do and new rotating managers push ui changes. A few details of that might be off, but the grid of cells has stayed.
Of course you probably don't want to correlate that but the fact these apps are battle-proven for so many years is a good sign if you search for something stable that you can rely on. Probably even in decades to come.
There is many creative solutions people come up with but if they are not tested long enough I would not be eager to do so on a production system if I wouldn't exactly know that everything will be fine (which is difficult in this case if it is not your domain).
You can survive for a long time doing bad or evil things. The theory stipulates a need to gauge health for a probabilistic outcome. For this correlation it has two parameters, time and health.
It also describes survival for non-alive, non-mechanical items. Implying no physical moving parts. There would be an interesting argument as to whether something that does not move can be judged as travelling across time, with or without being necessarily good? Surely to measure the success of an idea or thing you are also in part measuring the actions of creator or consuming humans, which muddies the water on the central non-alive point.
As an aside why is Taleb related stuff so popular here? I've only heard of him from one other place but he shows up a lot on HN.
I do not understand the point in these static site generators.
To me, the attractiveness of having a static website is that you get to choose the presentation appropriate to the particular content of each page. You can also automate some of the work in making those pages — generate a particular folder or preprocess some of the htmls — but static site generators seem to insist on running the whole thing.
If you are happy with a blog + a couple of similarly-formatted static pages, why not Wordpress?
Also: ‘minimalist’ generator with its own made-up markup format.
I used to run 5 wordpress sites on shared hosting. For a number of reasons I decided to move to a vps. It had basic resources but nothing special as I wasn't doing anything special. They were all very low traffic sites. But even with that, mariadb kept crashing due to running out of ram. As I was investigating what was going on I also started to realize the huge amount of traffic aimed at my sites just trying to compromise them. I took some steps to secure them but I still kept having issues.
I've transitioned all but one to static sites. Wordpress really didn't bring anything I needed that I don't get with Hugo. With my static sites I don't come close to the resource issues I had. Things are much more secure, there's nothing to "hack". My workflow is simple and I really like it. I edit my posts locally in Atom. I push changes to my git repository and then build the site and use rsync to push those changes to the host. It works great.
So that's the point for me. Much more resource efficient, more secure, gives me what I need without losing anything.
Another option I haven't used but I think could make sense in some situations is using wordpress as a static site generator.
MovableType, from what I remember, defaults to generating static pages. It’s proprietary these days, though. wget -r on a wordpress site probably takes a bit too long? I don’t know.
Anyway, the task solved by static generators is trivial, so we get a trillion non-supported github repos all building the same kind of site (basically a Wordpress site), badly. Moving from one to another without breaking links is hard. Wordpress at least will not go away at a random moment.
Because it is safer. With Wordpress and other execution environments your attack vectors will increase.
Why would I use Wordpress if all I need are some static sites and maybe a form?
I would rather use a form handler that processes data that comes from the form and let the other sites be what they are: static sites. So my question in this case is: Why Wordpress?
For me less is more sometimes and I can sleep better when I don't need to watch WP and it's plugins to be updated before the next malicious actor decides to attack half of the internet with an PHP exploit. Of course there is auto-updates for WP itself nowadays but the basic problem is still the same. You use a dynamic programming language though you probably don't need one.
I am also not an advocate of custom markup because I think we already have more than enough flavors now.
That is an argument for static sites — which I fully agree with. I do not understand this particular pre-packaged approach. These things are trivial to build in a site-specific way, and you do not need to sacrifice quite as much flexibility to do it.
I think "pre-packaged" approaches like this (or hugo, gatsby etc.) try to solve a very specific purpose.
As I see it from a quick glance this one is for people who want to publish math/science work and therefor it supports rendering LaTex.
I read about people building shops with SSG's and I myself use hugo for many tasks.
Sure I could still do it manually but I prefer writing content in markdown and SSG's like hugo because I am way faster and don't tend to forget something. When I build the site then everything is included and I am ready to deploy.
SSG's work with neat little plugins to ease your work with SEO, links and whatnot and while I didn't understand this in the first place I sure did when I finished my first project with hugo.
Just give it a shot and tell us why you still don't need an SSG but rather stick to coding everything yourself.
I will never look back and I enjoy working with SSG's.
Looking back on my own experience, the first step is always "I'll write my own static HTML because why run a full service?" But then you want to put a list of pages or something in, so you need some kind of preprocessing. So you try to write a program to do that. But if you don't have something like XSLT, Rascal, or XTran in your toolbox, the straightforward path seems to be to have your own representation that's easy to parse in your general purpose language of choice and then emit HTML.
I use something similar but aimed for the documentation on projects I work on. Its a bundle of mkdocs, plantuml, matjax etc. available in docker container.
I dislike Ruby and have written about my issues with the language at length, but this is rarely a productive discussion to have. People work with whatever language they have to hand unless they are explicitly setting out to learn a new one. Almost certainly seven years ago the author was using Ruby as a central tool of their work and when they started a project just did it in whatever was in this toolbox at the moment.
Three cheers for slow software. Thoughtful solutions are under-appreciated. I'm surprised how many junior devs I need to convince that the fact that programs like vi, emacs, make and TeX are 40+ years old is a _good_ thing.