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.
And even if the markup format ITSELF doesn't become a Turing-complete programming language, some poor soul will find themselves forced to encode a Turing-complete programming language OVER it.
And some syntax choices make that task pleasant, and some syntax choices make that task extremely unpleasant.
And then I'm looking at, eg, Wordpress Shortcodes, and Tiddlywiki Filter notation, and I go "Stop! Stop! You're writing Turing-complete query functions over an ill-defined markup language that never imagined you'd want to do this, but you do, because of course you do, so you just threw another layer of syntax over the top, and of course it's all going to go terribly wrong."
I mean, you can't get more simple than CSV, right?
Well, CSV doesn't work for some things. What if you have fields inside fields?
Well then JSON, right?
Ok but JSON doesn't work for some things. What if you need keys to be objects?
(at that point I guess we can look at microformats or protocols on top of JSON, because good or bad we're probably stuck with it for a century now, so that's sorta where my thinking is)
@natecull @teleclimber are we talking about statically generating html at the end of the process or something to replace html and browser tech? i agree that there’s annoying topological inconsistencies in the syntaxes of html/json/xml/csv. but in my experience, it’s inconsistencies in vocabularies and schemas that end up being more of a pain in the ass than the particular way the data is stored.
@natecull @teleclimber that really rather depends on what the big complicated problem is. a concrete example I can think of off the top of my head is a hairy multi-page form with complex dependencies and nesting structures, like say, a section that requires the addresses of multiple people, with the address fields depending on which country and state is selected for each.
at that point a new language is probably justified, along with a simple way to integrate /link it with the existing stuff.
The big complicated problem, for me, is "integrate and connect data from *all the other data formats on my desktop* without loss of data." Because we have a big social problem if we can't connect up all our knowledge because we don't have a language that can express *connections between* knowledge.
At least that's where I want to be.
I think the answer is more that "nothing went right in the first place" rather than "something went wrong". All these separate languages came from different communities and just got wodged together, which is okay, but also, kinda sucks now.
@natecull @teleclimber web assembly is useful but fundamentally it’s kinda just flash/java/silverlight/unity all over again. webassembly it’s way more secure than those, but sooner or later some client is going to ask me to make a critical change to a webassembly thing and all I’ll be able to do is shrug at them. in fact, this has already happened.
But it won't work like that, will it? The WebAssembly ecosystem is effectively just a bunch of binaries, so it'll be like CP/M and DOS all over again.
The Linked Data people seem to be trying their best to revive the idea of RDF and the Semantic Web, and they've picked JSON as the syntax, which is a pragmatic choice, but I think still will cripple them. But, it is pragmatic.
But still, I wouldn't want to try to use JSON-LD to write a *program* in. And if I can't write a program in it, then I probably can't write a database query or spreadsheet-cell function in it. And if I can't write those, it seems.. insufficient.
@natecull @teleclimber it does seem almost easier to just roll your own. a couple lines of bash and a makefile. a dash of perl. make your own and you can have your own opportunities to fuck up the design when you need to do $Big_Thing, in a codebase you understand cos you wrote it.
though i do admire the simplicity of a makefile and judicious application of hxincl
> I've been trying to brew my own [master data/coding language] (slightly extended Lisp S-expressions)
hey do you have a demo of this
What i've really wanted for a while is literally just....
i would surely find at least one way to put this language to the test
@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?"
And unfortunately, Free/Open Source Culture didn't entirely make Silicon Valley Culture better. It mitigated some of the worst parts (the ability for a company to completely evaporate big chunks of infrastructure software with copyright). It didn't quite mitigate all the endless loops of trend-chasing and the dominance of big money with small ethics on what free code gets written. Maybe that part didn't even come from Silicon Valley but somewhere deeper.
Yes! I find software *terrifyingly* social now, what with git and automated testing. The social barriers to entry seem really high. Yes you can publish any code I guess but if you want to publish 'the right code' using 'the right libraries/frameworks/methodologies' in 'the right places' to be seen by 'the right people'.... it starts to feel more like the art scene? Very cliquey? Very fashion-conscious?
@natecull @clacke @teleclimber @fgaz i thought it was aimed at newbies too. but then I tried to use it and the first decision it asks me to make is which “skin” do i want, which sounds like i am picking a color scheme but actually includes the wiki dialect and which features are available. anything beyond plain text, including just an ordinary image, i needed to edit html to add in.
that’s the impression i got from the documentation which seemed to assume it was talking to twine devs
> A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system.
The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!