Finding solutions in lower level language

It is possible to do things using higher level functions, and it’s standard practice, but it may have drawbacks. I think it can be argued that lower level language is easier to understand than higher level language, so some people might be able to proceed using lower level language who could not proceed using higher level language. Well, it appears as if it would be very difficult to use lower level language to build our own higher level functions, which we must do — we must use higher level language — but I think I’m discovering that, for one thing, there is more to lower level language than I thought, that I was thinking some aspects of language which I thought were higher level actually aren’t, in other words, actually they are fundamental, which, come to think of it, could be used as an alternative term for lower level, and then that actual solutions emerge from that recognition.

In particular I think I’ve figured out how to build a database using pure HTML, CSS, and JavaScript. Well, I’ve been trying to figure this out, and what seemed to me to be going on was I needed to write the database as a string and then navigate it to access records and make changes, and, also, that maybe certain kinds of substrings need to be inserted into the string, to make it navigable, and, in a way, what I was struggling with was what symbols to use in those substrings. There was also this: to make the database fully navigable it needs to be rationalized as a tree.

Working with JavaScript, and using HTML to call functions and display input data and results, I explored turning strings into arrays, and arrays back into strings, as a way to navigate certain kinds of representations of trees expressed as strings, but it was always tough going. Meanwhile, I was aware, of course, that the DOM can be navigated quite effectively, and it seemed to me that that could be used to navigate data, somehow, and I experimented with a very literal interpretation of that idea, but, while my results were extremely interesting, they somehow weren’t definitive. However, I’m working a lot with a type of data that is very tabular, and using HTML to display that data in visual grids on web pages, and I’m noticing that the resulting HTML is kind of very regular, and kind of easy to navigate. I just became very much interested in that. It’s like the data is now embedded in a patterned cloud of … metadata, maybe … structure data … and when you look at the cloud, the data itself really stands out … plus, JavaScript is able to navigate this structure data!

So, really, the way it looks is, my problem is solved, and I’ll be able to build and maintain my database by navigating a DOM element, my database … <span id=”thedatabase”> … using DOM methods.

The key remaining problem is this: between sessions, how do you save the database. I’ve known how to solve it all along, but I never could quite see what to do with it. Now that I can see what to do with it it makes things look like smooth sailing. I ran a couple of tests the other day, and they just sailed along. The textarea has become kind of the foundation of my temple, and is it ever nice. JavaScript is happy to paste DOM strings into its .value, and textarea is completely agnostic in accepting those strings, which is not the case elsewhere in the DOM, at all. And JavaScript is happy, apparently, to copy HTML from the textarea .value into other DOM elements, perhaps with some limits but apparently none that will impede my progress, now.

I mean, these observations about textarea are the result of my attempt to discover how to copy HTML from the DOM, somehow, to the clipboard, and then save it using the text editor, and then, when beginning a new session, how to get that HTML back into some kind of empty vessel, a web page built for the purpose, which, where, earlier, I struggled with it a lot, now looks to be quite straightforward.

Another discovery: the nonofficial DOM method .innerHTML seems to be more reliable, in my experiments, here, than the official methods for making changes in the DOM — I believe it, too, has limits, but, again, they seem not to be affecting me any more — … and, isn’t it lower level language. I mean, it’s an add on, but does that make it higher level. And it’s less granular, which in a way makes it look higher level, but it’s simpler and more direct: now we are just telling JavaScript what strings to put where in the DOM … but we are using DOM navigation to tell it the “where” part of that … and then, if we put a correct string in a correct location, we’ve created a new DOM element, which has become part of the DOM map, and which can now itself be navigated using DOM methods.

pi, by the way, is a url

We can continue in this manner.