The way I look at it, we're all programmers. For anyone not familiar, programming nowadays is usually done in some variant of the object-oriented paradigm, one of the key features of which is encapsulation. Basically, encapsulation means a programmer can build a new object (call it X) from preexisting objects A, B, and C, because he knows what objects A, B, and C typically do and how they can interact. In order to build X, he doesn't have to think about or even know how A works inside, or how B works inside, or how C works inside.
A different programmer (or the same one) can then build another new object from preexisting objects X, Y, and Z, because he knows what objects X, Y, and Z typically do and how they can interact. He doesn't have to think about how X, Y, or Z work inside.
Similarly, a programmer was previously able to build object A from preexisting objects Q, R, and S, because he knew what those objects typically do and how they can interact. He didn't have to know how they work inside.
This is useful not only for division of labor (all 3 aforementioned programmers may in fact be the same person), it's useful also because it gives us the ability to build something more complex than we can understand all at once. No matter how smart you are, if you continue to make a program more and more complex, at some point or other it will exceed your ability to hold all the component pieces in your head at the same time. But with encapsulation, this doesn't limit your ability to make the program, because you only have to understand it one "level" at a time - you can think about either the QRS level, the ABC level, or the XYZ level, and you don't have to hold the other 2 levels in your head at the same time.
There is no limit to the number of levels you can go "up", that is, no limit to the number of times you can build a new object from preexisting ones. Within the realm of computer science, there is a limit to the number of levels you can go "down", that is, there is a limit to the number of times you can look inside a preexisting object and figure out how it works - this lower limit is called machine code. However, you can still continue to lower levels, and then you leave computer science and enter the realm of computer engineering. In computer engineering, some of your "objects" are microprocessors and RAM.
If you go lower, you move from computer to electrical engineering. In electrical engineering, some of your objects are transistors and operational amplifiers. If you go even lower, you move into physics, and your objects are p-n junctions and electrons. If you go still lower, you get to quantum physics, where the objects are wave equations and virtual particles. And if you want to go any lower, the objects get speculative - no one has figured them out yet. Let's speculate and say the objects turn out to be called strings. Can you go down another level, and look at the objects inside strings? No one knows. This is a heavily simplified and abridged overview, of course.
In light of this analogy, the source material of reality is objects. That is, no matter which level(s) you work at, the things you work with have certain characteristics - in a nutshell, they're black boxes. You know what they typically do and how they can interact, but you don't necessarily know how they work inside. If you do know how they work inside, it's always the case that either a) there's another level down where you don't know how the objects work inside (possibly because no one does), or at best b) no one knows whether or not there's another level down - there may or may not be.
Doubtless everyone's thought along these lines before. Something I didn't stress with the programmer analogy is that objects are predictive theories. For example, if I give object A input "bob", I predict object A will give me back output "Bob". Every time I give object A input "bob" and get back output "Bob", this is further evidence in support of my predictive theory for object A. However, there is the chance, however small, that one time in the future I'll give input "bob" and get back output "fsg". Then I'll have to look inside object A and figure out why this happened, that is, figure out how to predict if and when it will happen again.
Once I figure out what objects Q, R, and S typically do, I should be able to make accurate predictions about when object A will give me "fsg" instead of "Bob". That's if the "lower level" programmers did a better job than the guy who built object A. In reality, there's no guarantee I'll be able to make these accurate predictions even after figuring out what objects Q, R, and S typically do. Perhaps object A only gives me "fsg" instead of "Bob" when object Q does something atypical, that is, something I can't predict. In that case, I'll have to look inside object Q and figure out why and when this atypical thing happens.
There's no guaranteed limit to the number of levels you may have to go down in order to fully understand object A, that is, no lower limit to how deep you have to go to always be able to make accurate predictions about what object A will do. (In the programming analogy, this is exemplified by the "blue screen of death".) There is the chance, however small, that you'll have to understand any lower level in order to understand object A. You may even have to understand a level no one understands yet (like string theory), or a level no one has even conceived of yet. At any level, there's always the chance of atypical behavior, which may require a deeper understanding. In this sense, our understanding is never "absolute", because there is always the chance of behavior that contradicts our predictions.
There is a way to sidestep this issue: don't make any testable predictions. While I've been describing this hierarchy of objects, I've been assuming they will be used to make predictions about things outside the hierarchy. Not only that, I've been assuming these objects will be used to make predictions about things not known when the hierarchy was devised, that is to say, these objects will be tested. For example, my predictive theory for object A not only says that object A always has given output "Bob" for input "bob", but that object A always will give output "Bob" for input "bob". It would be a lot easier if I only had to "predict" things I already knew, but not very useful.
Firstly, it's entirely possible to create a hierarchy, potentially a very complex one, that makes no testable predictions. Secondly, it's also entirely possible to create a hierarchy, again potentially quite complex, that makes no new predictions, that is, that only restates what is already known. For both of these possibilities, our understanding can be "absolute", in the sense that there is no chance of behavior that contradicts our predictions (in the first case, because we make no predictions, and in the second case, because all the "predictions" where known when we started). All levels are known.
Thirdly, it's possible to create a hierarchy that makes new predictions to be tested in the future. For this possibility, our understanding can never be absolute - there may always be deeper levels. So my question to Quinn, Rowden, or Solway, is does your philosophy fall into the first, second, or third camp? (And if the third, what are the new predictions?)
Any other feedback from anyone else is more than welcome, of course.
programmer philosophy
Re: programmer philosophy
That's a nice post, well written. How long did it take you? I want to add two things.
First, I describe what you're speaking about as "abstraction" and thus "levels of abstraction."
Second, you spoke of going to a lower level to try to more fully understand the behaviour of the level(s) above, but how do you know when or if a particular level has been fully explored, known and understood itself? Isn't there a chance that something on the level you're at has been missed? Maybe you touched on this when you said that levels can behave "atypically", although I read that as still concerning behaviour generated from interaction with other not fully understood/known/predictable levels.
First, I describe what you're speaking about as "abstraction" and thus "levels of abstraction."
Second, you spoke of going to a lower level to try to more fully understand the behaviour of the level(s) above, but how do you know when or if a particular level has been fully explored, known and understood itself? Isn't there a chance that something on the level you're at has been missed? Maybe you touched on this when you said that levels can behave "atypically", although I read that as still concerning behaviour generated from interaction with other not fully understood/known/predictable levels.
Re: programmer philosophy
Thanks for the compliment, Jason. The post took me about an hour.
You're right, I didn't mention the possibility of incompletely understood levels of abstraction. I guess I forgot about it in my effort to drive home the point that the hierarchy is fundamental not only to programming but to how we think in general, and for similar reasons.
You're right, I didn't mention the possibility of incompletely understood levels of abstraction. I guess I forgot about it in my effort to drive home the point that the hierarchy is fundamental not only to programming but to how we think in general, and for similar reasons.
-
Matt Gregory
- Posts: 1537
- Joined: Tue Jun 07, 2005 11:40 am
- Location: United States
Re: programmer philosophy
It's also fundamental to the way people have organized themselves into large groups throughout history. There's always a leader or a leading group. There have been societies who have experienced anarchy at times, but there has never been a society based on anarchy. There have been lots of studies done on group behavior and hierarchical groups always form when people are thrust into anarchy.
-
brokenhead
- Posts: 2271
- Joined: Mon Aug 07, 2006 8:51 am
- Location: Boise
Re: programmer philosophy
Nice post, |read|.
This is something that has given me periodic nightmares over the years.
Let me give you an example. Back in the day, a lot of young guys devoted their early years taking apart and reassembling their first cars. I was one - I had a '64 Dodge Dart whose engine I had all but rebuilt at one time or another. Changing sparkplugs, belts, fans, tires, electrical components, you name it, my friends and I tried it on my car and it still ran. My father wouldn't allow me to work on the brakes and he drew the line when I unaccountably wanted to replace the automatic tranny with a manual. His reasoning was if I screwed anything else up, I'd never get it out on the road, so I would still be safe. But poorly done brakes wouldn't stop you from going once you were out there. And a manual transmission would ruin what tiny resale value the car had.
I got rid of that car to get some money for college. My next car was so complicated and different, so encapsulated, that even my old mechanic declined to work on it because of the computerized components. So to this day, I am almost as helpless as a nun with my current car.
Maybe erroneously, I used to have the confidence that I could take the Dart across country and fix any problem that cropped up. Now, I pay someone else to change the oil.
Encapsulation has increased the complexity of the modern car so that it is unrecognizable.
But that's not even the tip of the iceberg. In IT, which is my field, you have the OSI model upon which all distributed programming and networking is based. The idea is pure encapsulation. A machine at one node communicates to one at another via TCP/IP and/or other protocols, which are built around either the OSI model or the related DoD model.
The OSI model has 7 conceptual levels which each program developer adheres to, at least in theory. The data goes from the top, or Application, level of one machine, down through all the levels to the physical (the network card and cabling), over to the physical level on the second machine across the room or across the world. It does not matter how far away. The data then goes through all of the layers in reverse order on the second machine. The layers are entirely encapsulated, in that any layer on machine A "thinks" it is dealing only with the corresponding layer on machine B. It is entirely unaware of what goes on in the layers above it and below it. It is encapsulated.
Networking is thus often said to be "modular" as is programming. When various interfaces within a program are well-defined, a programmer can just "plug" a standard subroutine into the program. Then when required, his program calls this subroutine into memory. With windows, many of these are the ubiquitous "DLL" files. They do not have to know anything about the code that delivers input, nor do the care anything about the code to which they pass output. As long as the API's are standard and used correctly, the program will behave seamlessly.
But here's where I lose sleep:
IT people are not paid to surf the web all day. You have to understand which encapsulated part is not doing its thing when something goes wrong. This is the tricky part, because often, when dealing with the OSI model, the layer where the problem resides usually IS doing its job properly, but in the real world has run into a situation the program developers had not foreseen or had decided to ignore. I have spent hours troubleshooting a problem, only to find that the cause was an upgraded DLL that was doing its job too well.
I lose sleep because I am not nor have I ever been a programmer, although I have worked in program development as an administrator and/or QA analyst. The QA analyst tries to "break" a program in the lab before it is deployed, and the administrator just keeps programmers, when scores of them are working on the same code, from stepping on each other's toes. Neither role helps when, say, MS Exchange is screwing up on a production server, potentially affecting thousands of users all at once for mission-critical information flow.
"Encapsulation" means no one ever seems to have the answer but everyone has suggestions. It means conference calls across the enterprise and to Microsoft and talking VIPs in the sales department down from a ledge somewhere in Boise. (Thankfully, the ledges in Boise aren't all that far off the ground...)
It means "spreading out the liability" so all you lose is sleep and not your job.
Aaaah!
This is something that has given me periodic nightmares over the years.
Let me give you an example. Back in the day, a lot of young guys devoted their early years taking apart and reassembling their first cars. I was one - I had a '64 Dodge Dart whose engine I had all but rebuilt at one time or another. Changing sparkplugs, belts, fans, tires, electrical components, you name it, my friends and I tried it on my car and it still ran. My father wouldn't allow me to work on the brakes and he drew the line when I unaccountably wanted to replace the automatic tranny with a manual. His reasoning was if I screwed anything else up, I'd never get it out on the road, so I would still be safe. But poorly done brakes wouldn't stop you from going once you were out there. And a manual transmission would ruin what tiny resale value the car had.
I got rid of that car to get some money for college. My next car was so complicated and different, so encapsulated, that even my old mechanic declined to work on it because of the computerized components. So to this day, I am almost as helpless as a nun with my current car.
Maybe erroneously, I used to have the confidence that I could take the Dart across country and fix any problem that cropped up. Now, I pay someone else to change the oil.
Encapsulation has increased the complexity of the modern car so that it is unrecognizable.
But that's not even the tip of the iceberg. In IT, which is my field, you have the OSI model upon which all distributed programming and networking is based. The idea is pure encapsulation. A machine at one node communicates to one at another via TCP/IP and/or other protocols, which are built around either the OSI model or the related DoD model.
The OSI model has 7 conceptual levels which each program developer adheres to, at least in theory. The data goes from the top, or Application, level of one machine, down through all the levels to the physical (the network card and cabling), over to the physical level on the second machine across the room or across the world. It does not matter how far away. The data then goes through all of the layers in reverse order on the second machine. The layers are entirely encapsulated, in that any layer on machine A "thinks" it is dealing only with the corresponding layer on machine B. It is entirely unaware of what goes on in the layers above it and below it. It is encapsulated.
Networking is thus often said to be "modular" as is programming. When various interfaces within a program are well-defined, a programmer can just "plug" a standard subroutine into the program. Then when required, his program calls this subroutine into memory. With windows, many of these are the ubiquitous "DLL" files. They do not have to know anything about the code that delivers input, nor do the care anything about the code to which they pass output. As long as the API's are standard and used correctly, the program will behave seamlessly.
But here's where I lose sleep:
IT people are not paid to surf the web all day. You have to understand which encapsulated part is not doing its thing when something goes wrong. This is the tricky part, because often, when dealing with the OSI model, the layer where the problem resides usually IS doing its job properly, but in the real world has run into a situation the program developers had not foreseen or had decided to ignore. I have spent hours troubleshooting a problem, only to find that the cause was an upgraded DLL that was doing its job too well.
I lose sleep because I am not nor have I ever been a programmer, although I have worked in program development as an administrator and/or QA analyst. The QA analyst tries to "break" a program in the lab before it is deployed, and the administrator just keeps programmers, when scores of them are working on the same code, from stepping on each other's toes. Neither role helps when, say, MS Exchange is screwing up on a production server, potentially affecting thousands of users all at once for mission-critical information flow.
"Encapsulation" means no one ever seems to have the answer but everyone has suggestions. It means conference calls across the enterprise and to Microsoft and talking VIPs in the sales department down from a ledge somewhere in Boise. (Thankfully, the ledges in Boise aren't all that far off the ground...)
It means "spreading out the liability" so all you lose is sleep and not your job.
Aaaah!
Re: programmer philosophy
I hear you. The advantage of encapsulation is no one has to hold the entire system in their head at the same time, and the disadvantage of encapsulation is no one has to hold the entire system in their head at the same time. :p
However, despite the lost sleep, I know that a) you can make a more complex program with encapsulation than without, and I'm of the strong opinion that b) it's worthwhile to do so. I don't value complexity for complexity's sake. In fact, I believe things should be kept as simple as possible. But complexity can be useful, in that often the only way to accomplish a certain useful task is with a complex system - a simple one just wouldn't be possible.
Similarly, sometimes the only way to make accurate predictions about the natural world is with a complex theory, because the world is naturally complex. The way I see it, encapsulation is how we transcend the limits of the human brain and reach for greater things, with all the potential pitfalls that entails.
By the way, I've never worked in IT - can you give me an example of how an upgraded DLL can do its job too well?
However, despite the lost sleep, I know that a) you can make a more complex program with encapsulation than without, and I'm of the strong opinion that b) it's worthwhile to do so. I don't value complexity for complexity's sake. In fact, I believe things should be kept as simple as possible. But complexity can be useful, in that often the only way to accomplish a certain useful task is with a complex system - a simple one just wouldn't be possible.
Similarly, sometimes the only way to make accurate predictions about the natural world is with a complex theory, because the world is naturally complex. The way I see it, encapsulation is how we transcend the limits of the human brain and reach for greater things, with all the potential pitfalls that entails.
By the way, I've never worked in IT - can you give me an example of how an upgraded DLL can do its job too well?
-
brokenhead
- Posts: 2271
- Joined: Mon Aug 07, 2006 8:51 am
- Location: Boise
Re: programmer philosophy
Well, I can tell you what I was thinking about when I wrote that. I was remembering a version of MS Schedule that published schedule changes across to my client's affiliate company when it wasn't supposed to.|read| wrote:By the way, I've never worked in IT - can you give me an example of how an upgraded DLL can do its job too well?
-
sue hindmarsh
- Posts: 1083
- Joined: Mon Oct 24, 2005 9:02 am
- Location: Sous Le Soleil
Re: programmer philosophy
|read|wrote:
But I'll take it that you do know something of their philosophy, and that you are serious about your inquiry, and ask, which "camp" do you consider best fits?
That doesn’t ring true. Your opening post contained very little substance wrapped up in a hell of a lot of unnecessary packaging.I don't value complexity for complexity's sake. In fact, I believe things should be kept as simple as possible.
It is a strange question to ask them due to the nature of their philosophy. But I take it you have studied their ideas and have constructed your "camps" with your interpretation of their central ideas in mind. Or - you have no idea about their philosophy, because you can't be bothered to investigate and think about their philosophy - and this whole exercise is a complete wank on your part.So my question to Quinn, Rowden, or Solway, is does your philosophy fall into the first, second, or third camp?
But I'll take it that you do know something of their philosophy, and that you are serious about your inquiry, and ask, which "camp" do you consider best fits?
Re: programmer philosophy
Sue, I take it you don't know that [read] has been around, or at least known of, GF for a very long time, and that he is a very intelligent, thoughtful boy. No need to assume he doesn't understand QRS philosophy, or that he is a wanker.
Re: programmer philosophy
Thanks for the compliment, Shahrazad. :) Good to see you again.
Sue, I'm sorry if you didn't get much out of my post - perhaps it will make more sense to you later. Anyway, I promised myself I wouldn't get caught up in the competitive micturation that seems all too common around here, so I'll just respond to your question. My current best guess is the QRS philosophy is in the third camp.
Sue, I'm sorry if you didn't get much out of my post - perhaps it will make more sense to you later. Anyway, I promised myself I wouldn't get caught up in the competitive micturation that seems all too common around here, so I'll just respond to your question. My current best guess is the QRS philosophy is in the third camp.
-
sue hindmarsh
- Posts: 1083
- Joined: Mon Oct 24, 2005 9:02 am
- Location: Sous Le Soleil
Re: programmer philosophy
Read,
The length of your time here is in no way reflected in your original post. Your "camps" are constructs that have very little, or anything, to do with the type of philosophy being highlighted here. Thanks for spilling out your "camp" selection though. Could you squeeze out a few more drops that pertain to why you believe Quinn, Rowden, and Solway's philosophy fit the third camp?
The length of your time here is in no way reflected in your original post. Your "camps" are constructs that have very little, or anything, to do with the type of philosophy being highlighted here. Thanks for spilling out your "camp" selection though. Could you squeeze out a few more drops that pertain to why you believe Quinn, Rowden, and Solway's philosophy fit the third camp?