Saturday, September 5, 2015
and
And this is about building really deep web sites, a real abundance of content, organized into a multiplicity of categories and a highly rational tree.
the secret
The idea that people generally shouldn't need to code is, well, screwy. It's not necessarily wrong, but it is not by any means that simple, nor is it in fact simple, this question of whether people generally should need to code. I think it could be argued that people generally need to code, period. It's pretty much stating the obvious to say that people who can code have a huge advantage in computing. On the other hand, I was looking at some app, or, well, I was reading about it, and it talked about things you need to do with code, to use the app, and I thought, I mean, it's just obvious you should be able to do those things from a menu, by pointing and clicking, not because that's easier, but because the menu acts as a tip sheet, so instead of needing to remember the command, or figure out what it is, you go to the menu and it gives you the function you need.
Still, code is interesting. I don't know why it feels this way, but it feels like with code you can just do whatever you want, whereas with an interface, you are narrowly limited to what the interface does. I'm not saying this makes sense. It seems to me code and an interface do the same thing. They translate our actions of typing or clicking into, oh, what? Instructions to the computer, let's say. The fact that they do seem to be different, I suspect, originates in the approach taken to interface design. And yet, code does have its own characteristics. I mean, you know what it is when you see it, and if you read it it's a kind of lens that reveals all sorts of things in its own way. It may indeed have its own peculiar power originating in something like that.
Really, here's the issue: code and interfaces are one and the same thing. If you try to separate them from each other you don't get it, but that's what everyone does. True, if the interface were very magical, you could do anything without ever typing, you know, html tags, function declarations, all that kind of thing, but it's not like there's anything wrong with typing code. It's not even that hard to learn these languages, so the idea that we need the interface to remind us of what's available is, at its root, a fallacy. As a kind of aside, I think the cheat sheet function is a big reason so much effort is put into translating functionality to an interface, and it's a fallacy, but there is something about an interface, nonetheless. It's attractive, and there's probably a reason for that. I'm picturing an interface consisting of a panel in which you see graphics that you generate by typing code into a console. I think it's a very attractive idea, although, yeah, there's a kind of coldness to it. An interface is possessed of a certain warmth. But who cares. With this console based interface you can start to build a graphical interface, and then you can use that whenever you want, and the console whenever you want that.
Well, you are going to say these are really duh observations, that, duh, that's what programmers do, and anyone can do it, but code is very complicated, what with its many many lines and all the functions that have to interact with each other, stuff like that, and ordinary people will never be able to master it, and if I, who am whining and complaining, were actually as smart as I seem to think I am, I would figure out code, and if I'm not smart enough, even if it's painful, I should just accept that I'm a less privileged, less capable class, and that it's nobody's fault but my own. Well, I just looked at everything I could stomach in terms of searching for information about how to set up a good console, and control what's displayed in a window from there. A good console needs to have certain specific features, and there are consoles out there that do, apparently, possess those features, but trying to figure out how to use them has been like wading through a swampy jungle. I have yet to be able to access those essential console features. Here's what it comes down to: every existing product is a complete maze of brilliant features, but, in among them, it is impossible to locate the one essential feature. Talk about irony!
Now, and of course this is probably quite incorrect, since you can see I'm an idiot, by console I mean a window - it is that - in which you can type code and from which you can run that code. I do use Notepad, and that's my console. I type in the code, save it, and open the file in a browser, and that's how I run my code from my console.
So, it's great. I'm able to do wonderful things this way. If I were more adept, I could do anything this way. But there is a problem. If I build a file with a lot of functions in it, the code itself becomes very difficult to work with. Notepad lacks the key feature that is necessary for easily working with code, which is code folding. (But I must add that code folding is not quite as simple a thing as you might think. It is not some extremely simple and even simplistic thing that you might be able to do something with, it is a slightly complex thing that is absolutely necessary if you are going to do anything.)
So, I spent the last twenty four hours installing Notepad++, which supposedly includes code folding, and then trying to figure out how Notepad++'s code folding works, completely without success. That's ridiculous! Code folding should be the very first thing you see, anywhere and everywhere.
Well, I am trying to think how to build a proper text editor. It's a code editor, and it runs your code when you perform an edit. It's in JavaScript in HTML and it runs in the browser.
Still, code is interesting. I don't know why it feels this way, but it feels like with code you can just do whatever you want, whereas with an interface, you are narrowly limited to what the interface does. I'm not saying this makes sense. It seems to me code and an interface do the same thing. They translate our actions of typing or clicking into, oh, what? Instructions to the computer, let's say. The fact that they do seem to be different, I suspect, originates in the approach taken to interface design. And yet, code does have its own characteristics. I mean, you know what it is when you see it, and if you read it it's a kind of lens that reveals all sorts of things in its own way. It may indeed have its own peculiar power originating in something like that.
Really, here's the issue: code and interfaces are one and the same thing. If you try to separate them from each other you don't get it, but that's what everyone does. True, if the interface were very magical, you could do anything without ever typing, you know, html tags, function declarations, all that kind of thing, but it's not like there's anything wrong with typing code. It's not even that hard to learn these languages, so the idea that we need the interface to remind us of what's available is, at its root, a fallacy. As a kind of aside, I think the cheat sheet function is a big reason so much effort is put into translating functionality to an interface, and it's a fallacy, but there is something about an interface, nonetheless. It's attractive, and there's probably a reason for that. I'm picturing an interface consisting of a panel in which you see graphics that you generate by typing code into a console. I think it's a very attractive idea, although, yeah, there's a kind of coldness to it. An interface is possessed of a certain warmth. But who cares. With this console based interface you can start to build a graphical interface, and then you can use that whenever you want, and the console whenever you want that.
Well, you are going to say these are really duh observations, that, duh, that's what programmers do, and anyone can do it, but code is very complicated, what with its many many lines and all the functions that have to interact with each other, stuff like that, and ordinary people will never be able to master it, and if I, who am whining and complaining, were actually as smart as I seem to think I am, I would figure out code, and if I'm not smart enough, even if it's painful, I should just accept that I'm a less privileged, less capable class, and that it's nobody's fault but my own. Well, I just looked at everything I could stomach in terms of searching for information about how to set up a good console, and control what's displayed in a window from there. A good console needs to have certain specific features, and there are consoles out there that do, apparently, possess those features, but trying to figure out how to use them has been like wading through a swampy jungle. I have yet to be able to access those essential console features. Here's what it comes down to: every existing product is a complete maze of brilliant features, but, in among them, it is impossible to locate the one essential feature. Talk about irony!
Now, and of course this is probably quite incorrect, since you can see I'm an idiot, by console I mean a window - it is that - in which you can type code and from which you can run that code. I do use Notepad, and that's my console. I type in the code, save it, and open the file in a browser, and that's how I run my code from my console.
So, it's great. I'm able to do wonderful things this way. If I were more adept, I could do anything this way. But there is a problem. If I build a file with a lot of functions in it, the code itself becomes very difficult to work with. Notepad lacks the key feature that is necessary for easily working with code, which is code folding. (But I must add that code folding is not quite as simple a thing as you might think. It is not some extremely simple and even simplistic thing that you might be able to do something with, it is a slightly complex thing that is absolutely necessary if you are going to do anything.)
So, I spent the last twenty four hours installing Notepad++, which supposedly includes code folding, and then trying to figure out how Notepad++'s code folding works, completely without success. That's ridiculous! Code folding should be the very first thing you see, anywhere and everywhere.
Well, I am trying to think how to build a proper text editor. It's a code editor, and it runs your code when you perform an edit. It's in JavaScript in HTML and it runs in the browser.
Friday, September 4, 2015
theory
No one seems to be talking about hardware architecture. I'm looking everywhere and it's barely even mentioned.
When you start a computer, electrons begin to flow through an closed circuit. They enter through a single wire, and then that wire divides again and again.
Hmm. At the very beginning, most of the switches must be automatically open. Electrons need to initially flow along very specific paths that check certain things and then close and open switches to initiate a cascade of events that brings the computer into a certain state, where, normally, it waits for further instructions.
It seems that memory is a network of nodes and an impulse applied to a node on its surface cascades through it creating changes, somehow. I don't understand it. Telling me that isn't starting at the beginning and then proceeding to the end. It's for whatever reason not forthcoming.
At some point the startup process checks various ports for initialization files or some such thing. It basically moves the code in those files, or, the data, into specific portions of memory. If you connect some kind of media to one of those ports, with a file in it with a certain name, the contents of that file will be mapped to some location in memory. And once that is done, something will appear on the screen. It will invite you to touch it.
Let's say it's a cursor on an otherwise blank screen. What you want to do now is type in ones and zeros and, after that, save them as a file, or the file, of the ini or config type type, on your media. Then you re-start.
So you think we are too dumb to do this? What's brilliant about you is that you did it first. It's not that you are the only person who will ever do it, or can ever do it, or should ever do it.
Now there's a white or beige box on the black screen, and the cursor is in that. Actually, no, there are two of them and the cursor is in the first one.
Maybe it's like this ... i mean, if you press a key, a character is inserted at the cursor location. Pressing that key creates a pattern of ones and zeros on some part of the surface of memory, and then that moves through the layers of memory and emerges as a pattern on the opposite surface. Maybe that pattern acts as a kind of filter that happens to send various amounts of ... well ... color, to a pixel on the screen.
Going over and over this in my mind. No, I don't think that's how it actually works. I don't know how it works. I can't tell you how it works. But there's some layer of functionality that's built into the hardware, maybe in layers, like some part of it actually is software but it rarely changes. Or never. So it is hardware, really. Anyway, software is required to go further, but you could give me an original screen where I can type. Listen, machine language has to exist, but I'm actually not completely stupid and I don't think that's really what I'm talking about. Or how about this: what kind of abstract language is built into the computer? None? It all comes from media? It's limited to this: plug in media with these files on it and I'll run?
Well, OK, I can accept that. That's fine. My computer did come with all sorts of software installed, and, as a result, it does basically anything, or can. And there's this thing I forgot, which is that I can still create a blank slate of some kind. It's a blank slate in a full one, but I can do it.
The question is, what is it supposed to do? I mean, you could ask, "what is a blank slate?" And the answer is, it does something. True, on the surface there's a blank screen, and around it are controls. Oh, right! The controls are part of the slate! But then there's also something behind the slate, or behind the surface, which is blank, which is, really, a sea of data, but also, represented in it, a sea of imagery, and the controls can explore into that and bring images to the surface.
Where does this imagery originate? Plenty of it was loaded with the new ready to use computer, and then it comes from your camera, or, that is, your cameras, and then it comes from the Web. In fact, it is the Web.
This is why I say I'm writing about operating systems. It might be an app, that runs in an environment that runs the hardware, sort of. I mean, it does, but it also creates an environment that is full of its own features, and what I want so badly seems to be an environment that sort of has no features. It's just space. That is, by the way, very deliberately a feature, zennish, a design. But I say I am writing about operating systems because I am writing about, well, not the machine, but its product, image data, and also because I am writing about windows, which are an operating system feature. How can you not see, all of you, every one of you, how completely wrong you are about windows? For one thing, just for starters, there should be multitudes of them, and not just a few, and very few of them should be large, or none of them, except as desired, and they should certainly not be cluttered with menu options, there should be basically only one, and it should occupy a small space nearby, and when you click it, it will create another window, or does, because this is what an interface does, and the window should be starkly borderless, but all these windows will be of various sizes and they will float around each other and you can move them, and more than that, you can re-size them. I don't mean you can change their shapes, you can change their sizes. The whole window becomes either larger or smaller, and so does everything in it. Why don't you see that this is an essential function of windows? Why don't you see that without it windows are on the edge of uselessness? So we are going to create a browser window. It's a window, on our screen, and, actually, it's displaying a web page. Let's say this is a Firefox window, which displays a page of frequently visited sites, with colorful screenshots, something like that. But I've got lots of stuff on my screen, and I don't want this window to cover it all up, so I make it a really small window. I mean, I can see it, there. I can see it's that new Firefox window. And if I want to see it up close, I can enlarge the window. But I might not really want to do that. It's disconcerting. It changes the desktop. There's another approach which doesn't and we'll get into that. But there's this other thing: windows can overlap, and you should be able to overlap them with complete control, all these different windows, and you should be able to work in a window that's behind another window. Without bringing it out in front. This has all sorts of useful implications, but it's also just strictly correct.
I started thinking about something else, but I can't quite remember what it was. There are all sorts of interesting things to be implemented in this framework, but this was something somehow theoretical.
When you start a computer, electrons begin to flow through an closed circuit. They enter through a single wire, and then that wire divides again and again.
Hmm. At the very beginning, most of the switches must be automatically open. Electrons need to initially flow along very specific paths that check certain things and then close and open switches to initiate a cascade of events that brings the computer into a certain state, where, normally, it waits for further instructions.
It seems that memory is a network of nodes and an impulse applied to a node on its surface cascades through it creating changes, somehow. I don't understand it. Telling me that isn't starting at the beginning and then proceeding to the end. It's for whatever reason not forthcoming.
At some point the startup process checks various ports for initialization files or some such thing. It basically moves the code in those files, or, the data, into specific portions of memory. If you connect some kind of media to one of those ports, with a file in it with a certain name, the contents of that file will be mapped to some location in memory. And once that is done, something will appear on the screen. It will invite you to touch it.
Let's say it's a cursor on an otherwise blank screen. What you want to do now is type in ones and zeros and, after that, save them as a file, or the file, of the ini or config type type, on your media. Then you re-start.
So you think we are too dumb to do this? What's brilliant about you is that you did it first. It's not that you are the only person who will ever do it, or can ever do it, or should ever do it.
Now there's a white or beige box on the black screen, and the cursor is in that. Actually, no, there are two of them and the cursor is in the first one.
Maybe it's like this ... i mean, if you press a key, a character is inserted at the cursor location. Pressing that key creates a pattern of ones and zeros on some part of the surface of memory, and then that moves through the layers of memory and emerges as a pattern on the opposite surface. Maybe that pattern acts as a kind of filter that happens to send various amounts of ... well ... color, to a pixel on the screen.
Going over and over this in my mind. No, I don't think that's how it actually works. I don't know how it works. I can't tell you how it works. But there's some layer of functionality that's built into the hardware, maybe in layers, like some part of it actually is software but it rarely changes. Or never. So it is hardware, really. Anyway, software is required to go further, but you could give me an original screen where I can type. Listen, machine language has to exist, but I'm actually not completely stupid and I don't think that's really what I'm talking about. Or how about this: what kind of abstract language is built into the computer? None? It all comes from media? It's limited to this: plug in media with these files on it and I'll run?
Well, OK, I can accept that. That's fine. My computer did come with all sorts of software installed, and, as a result, it does basically anything, or can. And there's this thing I forgot, which is that I can still create a blank slate of some kind. It's a blank slate in a full one, but I can do it.
The question is, what is it supposed to do? I mean, you could ask, "what is a blank slate?" And the answer is, it does something. True, on the surface there's a blank screen, and around it are controls. Oh, right! The controls are part of the slate! But then there's also something behind the slate, or behind the surface, which is blank, which is, really, a sea of data, but also, represented in it, a sea of imagery, and the controls can explore into that and bring images to the surface.
Where does this imagery originate? Plenty of it was loaded with the new ready to use computer, and then it comes from your camera, or, that is, your cameras, and then it comes from the Web. In fact, it is the Web.
This is why I say I'm writing about operating systems. It might be an app, that runs in an environment that runs the hardware, sort of. I mean, it does, but it also creates an environment that is full of its own features, and what I want so badly seems to be an environment that sort of has no features. It's just space. That is, by the way, very deliberately a feature, zennish, a design. But I say I am writing about operating systems because I am writing about, well, not the machine, but its product, image data, and also because I am writing about windows, which are an operating system feature. How can you not see, all of you, every one of you, how completely wrong you are about windows? For one thing, just for starters, there should be multitudes of them, and not just a few, and very few of them should be large, or none of them, except as desired, and they should certainly not be cluttered with menu options, there should be basically only one, and it should occupy a small space nearby, and when you click it, it will create another window, or does, because this is what an interface does, and the window should be starkly borderless, but all these windows will be of various sizes and they will float around each other and you can move them, and more than that, you can re-size them. I don't mean you can change their shapes, you can change their sizes. The whole window becomes either larger or smaller, and so does everything in it. Why don't you see that this is an essential function of windows? Why don't you see that without it windows are on the edge of uselessness? So we are going to create a browser window. It's a window, on our screen, and, actually, it's displaying a web page. Let's say this is a Firefox window, which displays a page of frequently visited sites, with colorful screenshots, something like that. But I've got lots of stuff on my screen, and I don't want this window to cover it all up, so I make it a really small window. I mean, I can see it, there. I can see it's that new Firefox window. And if I want to see it up close, I can enlarge the window. But I might not really want to do that. It's disconcerting. It changes the desktop. There's another approach which doesn't and we'll get into that. But there's this other thing: windows can overlap, and you should be able to overlap them with complete control, all these different windows, and you should be able to work in a window that's behind another window. Without bringing it out in front. This has all sorts of useful implications, but it's also just strictly correct.
I started thinking about something else, but I can't quite remember what it was. There are all sorts of interesting things to be implemented in this framework, but this was something somehow theoretical.
Thursday, September 3, 2015
concept
Web - definition of: if you "go to" a certain address the Web will put certain things on your screen.
This is, strictly speaking, a definition of the Web, not the definition. A more general definition would be "if you 'go to' a certain address, the Web will do certain things", one of which is likely to be putting certain things on your screen.
Terminology: On the Web, "going to" a certain address is called surfing.
"Web programming" is the process by means of which particular actions are associated with a certain Web address. A "Web programmer" is a person who gives the Web instructions. These may be of two general types: surfing, and editing. A web programmer who is surfing, but not editing, is called a "visitor". A person who is editing the Web is called a programmer. It's overlapping terminology but it is logically consistent.
Editing the Web means telling the Web what actions to perform when someone surfs to a particular address.
The concept of the day is "live editing".
Normally, to edit the Web, you would surf to an address and there you would edit the instructions that apply to a different address. In the case of live editing, you surf to the address you want to edit, and do your editing there.
This is not strictly correct. In one sense, everything the Web can do has its own unique address. Rather than being strictly a question of what address you need to go to to perform a certain action, whether it is surfing to a page, or editing a page, it is a question of how you get to one address from another. The root procedure for surfing to an address is typing the address into the address bar of a browser. Once you are at that address, though, it is usually possible to surf to other addresses by interacting with the features of that address you are at. For instance, the address might put a button on your screen, and when you click that button, it will take you to a new address. Typically, to request that the Web perform the actions associated with an address, you would surf to that address, or, that is, to a page, and then to edit the actions associated with that page, you would surf to another page. We introduce, here, the idea that a "page" can contain multiple addresses. A page, then, is some set of elements that are displayed on the screen, when you surf to a particular address, and then, normally, to edit that address, you would surf to a different page. The elements displayed on screen would be replaced by a different set of elements. In the case of live editing, though, the elements of the page - what you see on your screen, primarily - remain largely unchanged when you surf to an editing address. For example, typically, if you want to edit, the page you want to edit will disappear, and be replaced by a page where you "do" editing, whereas in the case of live editing, when you access an editing address, perhaps by pressing a button which is one of the elements of the page, maybe an editing interface will appear superimposed on the page.
Live editing is not, in a sense, a technical concept, that is, it is not, in fact, something to do with the basic mechanics of the Web, if by its basic mechanics we mean the "code" which tells the Web what to do when someone surfs to an address, and the protocols, which are rooted in the architecture of Web hardware, which give that code meaning, but rather is conceptually about the user experience. It is not about how we get the Web to do things, but about what we ask the Web to do. It may be true that in its early days the infrastructure of the Web could only move us from one page to another, but today it can modify the elements on a page, without requiring us to surf to another page. Live editing shifts our perspective on editing, from one that is focused on the problem of giving the Web instructions, to one that is focused on the context within which we wish to edit. We are looking, now, at a set of elements on a page. They are meaningfully related to each other in various ways. The meaningfulness of the page is not simply a function of the information contained in one or another element, but of the relative visual effect of the combination of various elements. For example, we might be looking at a group of images, some of which are from a trip to Paris, while others are about a visit to London, and we might decide to move those images around on the page so as to create two groups, one of pictures from Paris, one of pictures from London. Now, if you were to ask me to look away from the screen and give instructions to move this image here, and that image there, it would be a challenging test. That's a user experience. If, on the other hand, I could issue those instructions while looking at the screen, and at the group of images, the challenge of it is greatly reduced. It is true that some visible element on the screen is the most likely way to allow me to issue instructions. The question is, does this element replace the group of images, that is, cause them to disappear, or does it appear on the screen together with them? The former possibility is standard editing and the latter is live editing.
This is, strictly speaking, a definition of the Web, not the definition. A more general definition would be "if you 'go to' a certain address, the Web will do certain things", one of which is likely to be putting certain things on your screen.
Terminology: On the Web, "going to" a certain address is called surfing.
"Web programming" is the process by means of which particular actions are associated with a certain Web address. A "Web programmer" is a person who gives the Web instructions. These may be of two general types: surfing, and editing. A web programmer who is surfing, but not editing, is called a "visitor". A person who is editing the Web is called a programmer. It's overlapping terminology but it is logically consistent.
Editing the Web means telling the Web what actions to perform when someone surfs to a particular address.
The concept of the day is "live editing".
Normally, to edit the Web, you would surf to an address and there you would edit the instructions that apply to a different address. In the case of live editing, you surf to the address you want to edit, and do your editing there.
This is not strictly correct. In one sense, everything the Web can do has its own unique address. Rather than being strictly a question of what address you need to go to to perform a certain action, whether it is surfing to a page, or editing a page, it is a question of how you get to one address from another. The root procedure for surfing to an address is typing the address into the address bar of a browser. Once you are at that address, though, it is usually possible to surf to other addresses by interacting with the features of that address you are at. For instance, the address might put a button on your screen, and when you click that button, it will take you to a new address. Typically, to request that the Web perform the actions associated with an address, you would surf to that address, or, that is, to a page, and then to edit the actions associated with that page, you would surf to another page. We introduce, here, the idea that a "page" can contain multiple addresses. A page, then, is some set of elements that are displayed on the screen, when you surf to a particular address, and then, normally, to edit that address, you would surf to a different page. The elements displayed on screen would be replaced by a different set of elements. In the case of live editing, though, the elements of the page - what you see on your screen, primarily - remain largely unchanged when you surf to an editing address. For example, typically, if you want to edit, the page you want to edit will disappear, and be replaced by a page where you "do" editing, whereas in the case of live editing, when you access an editing address, perhaps by pressing a button which is one of the elements of the page, maybe an editing interface will appear superimposed on the page.
Live editing is not, in a sense, a technical concept, that is, it is not, in fact, something to do with the basic mechanics of the Web, if by its basic mechanics we mean the "code" which tells the Web what to do when someone surfs to an address, and the protocols, which are rooted in the architecture of Web hardware, which give that code meaning, but rather is conceptually about the user experience. It is not about how we get the Web to do things, but about what we ask the Web to do. It may be true that in its early days the infrastructure of the Web could only move us from one page to another, but today it can modify the elements on a page, without requiring us to surf to another page. Live editing shifts our perspective on editing, from one that is focused on the problem of giving the Web instructions, to one that is focused on the context within which we wish to edit. We are looking, now, at a set of elements on a page. They are meaningfully related to each other in various ways. The meaningfulness of the page is not simply a function of the information contained in one or another element, but of the relative visual effect of the combination of various elements. For example, we might be looking at a group of images, some of which are from a trip to Paris, while others are about a visit to London, and we might decide to move those images around on the page so as to create two groups, one of pictures from Paris, one of pictures from London. Now, if you were to ask me to look away from the screen and give instructions to move this image here, and that image there, it would be a challenging test. That's a user experience. If, on the other hand, I could issue those instructions while looking at the screen, and at the group of images, the challenge of it is greatly reduced. It is true that some visible element on the screen is the most likely way to allow me to issue instructions. The question is, does this element replace the group of images, that is, cause them to disappear, or does it appear on the screen together with them? The former possibility is standard editing and the latter is live editing.
Wednesday, September 2, 2015
fundamentals
In a way what I'm seeing is that the future of the Web is going to be achieved by undoing certain things, and certain kinds of things. I'm talking, really, about patterns of thought, in particular the idea that this one thing over here is fundamentally unrelated to this other thing over there. This operates in two dimensions. First there's the idea that this one among an array of functions is separate from and essentially unrelated or unconnected to others in the array of functions, or, to put it another way, that all the functions do not reside in the same space, and then, seemingly implicit in that, the idea that a function is unrelated, somehow, to, in some sense, its origins. These are in the nature of the function's history and its component, taking these two as two kinds of origins of its functionality. And then looking more closely at these two types of origination we see the first subdivided into two kinds of history, and even more, but first its development - let us say the function is an application, that does such and such and such - and then the history of an installation, while components subdivide into components of various types and conceptions of type, thus, the code, at one level, and the language, at another, and underneath that, other levels of language. Well, there is a third originating dimension, maybe, which I'll call Math. We are working back into that and from there into, essentially, virtual reality, asking questions like: given a file with model data in it, and if that data describes, in part, a camera, and if the film plane is a defined geometry and it is divided into pixels, and if other data describes a surface, in the same model as the camera, at some specified place in the model, and with a specified color, and if a line is drawn from a point that acts as a lens, through the first pixel on the film plane, does that line intersect that surface?
Subscribe to:
Posts (Atom)