coding

I wrote to my Dad one time that I was spending a lot of time coding, and he wrote back "what is coding?" I was never able to answer the question.

That's partly because, while the question isn't a bad question, the answer is kind of silly.

You could Google "coding", and you would get many articles ... or ... "what is coding" ... which would be about computer programming.

The reason that's silly is, you could read about code - and that's what most of those articles would be about - and I could write about code, about, say, an instruction which, when given to the computer by means of certain steps, would tell the computer what to do ... and I could do it (if I labored at it) in a way you could make sense of ... you could follow the directions and make it work yourself ... but this would be of little value to you if you actually wanted to program computers.

An actual computer program combines many instructions that intricately interact.

Coding is a process. I have found very little that qualifies as a discussion of that process ... and what I did find was extremely esoteric.

The crux of the problem is something like this: all code resolves into strings, which are made, in a sense, of fibers, which is to say, of strings. Each of the many instructions that combine, as noted, to form a program is a fiber. To interpret the program, the computer will move from one part of the string to another, from one fiber to another, from one instruction to another, and the instructions are scattered along the length of the program string, but the computer is very good at finding a fiber, the fiber it needs ... shall we say ... next.

To write a program, however, or, we might also say, to edit a program, we must parse the string ourselves, and we are terrible at parsing strings.

Computers can help us parse strings ... this is the thing about coding you will not find discussed.

Well, it's true that you will, if you really work at it, find it discussed, but you will find it is always discussed implicitly - or, as it may be, imprecisely. For example, you will read something and say "oh, they are talking about string parsing for people."

But they will not give the appearance, these writers, of knowing they are talking about ... that ... what I just said. And if someone is talking about something but doesn't know it, maybe it's somewhat likely what they are saying about that something won't make complete sense.

It is also, interestingly, true, that the tools we need to parse strings (us, as people) are already in place. They are computing tools, and they are perfectly brilliant. My theory is that early programmers needed these tools, because all programmers need these tools, and that because they were working (to build these tools) with highly abstracted languages, their results were extremely pure and true, even though they didn't actually realize what they were working on.


In order for people to parse strings it is helpful if those strings are displayed on pages.

Almost all human string parsing, well, in the coding world (but might it be a universal truth? and then, not almost all, but all) is done this way. Recognize now, if you weren't already aware of it, that the term "string" refers to a string of symbols. This essay, for example, is presented to you as such a string.

But displaying strings on pages is problematic, because a longer string will not fit on a page. There was a time when such a string would simply be spread across the pages of a book, and moving from page to page in a book is extremely easy. The problem arose because in the world of coding we no longer define a page as being part of a book. I mean, we can define a page that way, still, but doing so extremely cumbersome. Well, maybe it's not defining them as such that's extremely cumbersome (though it somehow seems to be), but moving from page to page in such a book that is ... extremely cumbersome ... it certainly appears to be so.

And, out of this difficulty, there emerged scrolling.

Well, scrolling is extremely pure, and good, but at the same time it is a kind of impurity that entered the realm of human string parsing.

It actuates certain possibilities, but it also gums up the works.


Also emerging in response to the problem of string parsing, in response to the problems of pages and books in coding, was the link.

The link has none of the problems of scrolling ... it is a completely pure expression of the way computers parse strings ... though, because the link is highly abstract, its application can be difficult to comprehend.

Well, the link is not only superior (to scrolling ... or anything else) in principle, it is superior in practice, and for a very specific reason which is not necessarily obvious.

Consider this: if a scroll is very long, it is essentially impossible to find in it some one line or section.

If the sections of a document are properly linked, though, finding the next section - the next relevant section - become automatic.

The question is, what is proper linking? How can that idea be rationalized? And while it's possible there are various answers, it is also possible there is just one: close inspection of this suggests that the word "organize" describes the arrangement of things into a tree.

So, if we are undertaking the "writing" or "coding" of a program ... we want to somehow begin by defining a root. From there - this is the procedure - we will link to a few branches, and from each of those to a few branches, so that, after a time, we will be able to "get to" any of a very large number of branches from the root.


The instruction for parsing the string now becomes "go to the root, and proceed from there out branches."


There is also a reverse instruction: from a branch, go back towards the root. Along the way, other branches will be encountered, and they can be explored at will.


As an example, I have been working on a program that is supposed to do a certain set of things. I haven't made much of an effort to say what that set of things is, here - after all, the document is really for my own use, as a work space and a log - but I'm collecting information about the mechanics of it. Here's what the reader needs to know: this essay is a root. From here you can now branch to the just described project ... to its root ... and from there along branch after branch to its outer branches ... and then, using the browser's back button, back from branch to branch until you arrive again here.


I can or could, and may, add additional links here, in this root ... including one that might lead to whole other project branches or libraries of project branches ... and others that would essentially not go anywhere ... those would be like leaves, here on this root ... and you could link out to one, see what's there, and then link back - using the browser back button, the browser back button - to here again.