Thoughts on #Hugo and static site generators in general. TL/DR: I'm not a fan.
ugh that sounds nasty. I glanced once at the site generator landscape and ran away screaming. I was hoping maybe something usable had emerged but... at least this one doesn't seem to be it.
I don't actually much like any current markup/query/config formats, which is why I've been trying to brew my own (slightly extended Lisp S-expressions).
My problem with most markup formats is that they start out thinking 'oh it's okay, don't sweat the syntax, nobody will ever need to do $BIG_THING in it' and always, always, sometimes within six months, they have to do $BIG_THING in it.
Every markup format becomes a Turing-complete programming language. Law of nature.
@fgaz @natecull @teleclimber the problem comes from the sorta stuff the blog post is complaining about. sooner or later complexity is going to seep in somewhere, and it’s a choice about where you put that complexity. the filesystem, and subtleties in naming are the wrong choice. similar problems would arise from starting with a “simple” non turing complete markup/templating language and trying to force it to do something outside the original usecases that it wasn’t designed for
@fgaz @natecull @teleclimber a good example is the mustache templating language. really great for most things. but then you need a simple way of feeding in an array and getting a numbered list. or you just want to print out the keys and values of an object and it doesn’t provide a way to print keys. or you need to show a different bit of content depending on the contents of a value. mustache can’t do any of that, so you either put more logic in code outside of mustache, or you make handlebars
I feel like there's maybe a rider to this:
if you divide a system into modules such that the complexity is in the correct modules, overall system complexity lowers. If you put the complexity in the wrong modules, overall system complexity rises (potentially exponentially if you got the module divisions super wrong).
ergo you can tell if you've decomposed a system correctly by how much non-essential complexity the system as a whole has.
I think platform churn is a huge driver of complexity. Complexity that's 'essential' for the person having to solve the short-term problem of 'getting the system running on platform X, and then platform Y, and then platform Z'. but not really essential to the long-term problem of 'this just needs to run, somehow'.
I guess that means system design is increasingly a social problem. "What culture do I trust with my system? What are their demands on it, and me?"
i'd say one can get pretty far on coding or contributing without "talking to anybody" in terms of like, bothering to know anybody posting on a forge
i don't feel like i know anybody on the pinephone issue trackers nor do I look at the ubuntu touch forum like I probably should, and yet i can get involved in debugging the distros to push issues closer to closing / problems closer to fixing pretty easily
but then you have API surfaces, explicitly documented and implicit unintended APIs, each one a social contract.
For people who care about, support, or build Free, Libre, and Open Source Software (FLOSS).