• Saturday, 06/10/2023 ** 11:08 I did not finish my website hot reloading plan. I swapped that hot reloading functionality with a really simple file server.

However, my website is now a quine; it renders its own source code to $source.html files and lists those directories. That’s been a great exploration of what is possible once the source code’s been rewritten to use a more solid framework. I’m excited to see what else I can do there.

First, though, we’ll build a dynamic file server that can render information on the fly. I’ll need this to quickly design pages like my page for showing photos, which I would like to be statically generated and server-side rendered. The components and dependency architecture we’ve set up will finally come in handy - now that the source code is much more clear and disciplined.

The best tool behind this source code organization was cacheing as much information as we could up-front through the ‘info’ function. This gives some files the max amount of information that they can get form other files at any time, at the cost of a bit of querying up front (though this might actually be faster - it certainly feels faster - because more information is cached rather than being repeatedly queried or calculated).

I’m thinking about language paradigms that would let me declare data as lazy without using tools like ‘async’ - for example, getting the contents of a file dynamically when it’s queried from an object rather than having to fetch that up-front. Maybe this is what traits and OOP are for - that cache can just be implemented as an object access on a per-struct basis - but I feel like there is some other core language feature that this one could ‘fall out of’ with no boilerplate. Declare that an attribute exists and how to retrieve it, then retrieve and cache it on that object when that attribute is retrieved.

The problem here is invalidating files and information; we have to assume that the root source hasn’t changed, which isn’t necessarily the case, so we can’t do this every time. We almost want some way of indicating whether the source of data we pull from is static - whether it can change during code execution, so we might want to refetch - or dynamic - in which case we’ll keep our stuff in memory and never re-fetch a potentially expensive operation. (I think it’s safe to assume in most cases that we will have enough memory available, so we can cache whenever).

This reminds me of the 3CPS work - if we know statically how much information something will take up in memory, we can build that information in at compile time and avoid requiring heap allocations for that data by making a separate heap space available to us that we statically allocate during our compile step.

We’ll explore these ideas after we have fully dynamic hot reloading - that’s when a real programming language could surface from this whole static/dynamic mess : )

I’m missing some real features from javascript. Lisp programmers often say that ‘fear of syntax’ is the biggest reason for not using a lispy language, and that too many parentheses scare people - but frankly the lack of expressive syntax makes coding more difficult. I can recognize javascript structures based not only on their names but also the shape of the code - and because JSX code has so many different shaped (especially the inline html!) it’s far easier for me to quickly scan and grok a JS(X) file than it is for me to take a peek at a clojure one, where I have to drill down into the names of every line and evaluate the open and closing parens. Lisp is great for language developers and macros - but for most programmers, being able to identify, literally, ‘the shape of a problem’ can be a big deal. I’ll probably use a JS or ML-based syntax for whatever language this becomes.

I’m also missing the lack of expressive type annotations and stakc traces. Tracking down my file rendering bug was a complete mess. ** 12:53 You should design things so that an algorithm has to relearn. ** 13:35 I love resurrecting old projects and using them to re-explore ideas. Most of my ideas from the past couple of years have gone unfinished - I just didn’t have the technical knowledge, the stamina, or the determination to follow a project through. Now that my site is breaking through - as is the index page - I’m really getting there. Fear is the mind killer. I can’t wait to close out many of this site’s issues, build a splash page, and get to smess and joss and making a game and rendering for desktop - all things I’ve wanted to do for a long, long time.