Alex’s most recent post was on Abstraction. Alex stating that he’s not convinced about it had lead me to convince him why his innovation theory just might be wrong.
The concept of abstraction, or making the underlying things go away and the purpose come to life, is one that is taught to computer scientists in almost their first week of school. It’s a concept you must learn, not because your stuck inside a world around you (like the x86 architecture), but because if you don’t, you yourself will get lost.
Now before I go any further, Alex, you do have something I believe is right. The people who are using the abstractions will not be developing new innovations for them *(most of the time)*. That’s true. This is why Intel has people working on the next architecture, as well as Mac, AMD, etc. Heck, if they didn’t, they why in the world am I working on a Opteron at work? The instruction sets within the x86 architecture have changed as well, to make use of some of the processors benefits (for example, mmx technology added a slew of media commands).
So to say innovation is slowed because not everyone understands the underlying concept, well, that might be true, but then again: we don’t want everyone developing the x86 chipset.
This brings us back to the main point: abstraction encourages innovation. The idea is simple, and has been used for quite some time. Take Henry Ford for example: he abstracted the car making process in his assembly line. The person in the line didn’t have to know how to add the part before theirs, they just needed to know how to add theres. Because of this, he didn’t need 500 people who knew how to build a car, he needed 500 people that could add a part to a car.
That said, the abstractions created in programming by other programmers allow programmers to program even further… As well as, allow people who don’t understand computers to work with them.
Take for example a content management system. The system itself builds up by adding modules, these modules are abstractions of code, that build on top of an already abstracted parent. This in turn has a two fold affect, it creates an abstraction layer at which the user can modify a page without knowing any code, and it creates an abstraction level that the programmer can build on (for example, my graph is running off an abstraction of my day entry).
That said, I can create new things that use both my graph and my blog module, to create even bigger things. This was something of sorts that I was talking about with Blaine earlier today. We were talking about where and how you abstract the layers. But before I get to that, let me talk first about JAVA.
Java’s ability to abstract is no greater than PHPs, C, C++, or any other decent programming language. It does have a layer of abstraction though that was never implemented. There is a layer of abstraction that occures at compile time. This layer for most programming languages is prohibitive, meaning: if you compile on a windows machine, your program will work for windows, not for mac. If you compile in linux, it will work in linux, but not on windows. That kind of things…. Java however, decided not to fully compile. They removed the abstraction barrier that had been created by compilers, and in turn, gave us a programming language that was both compiled and interpretted, allowing us to run it on any platform that Java had been developed for.
In some ways Alex, I wonder if your argument just curled up on itself. If you think about it, Java went under an abstraction barrier to create a new one of less importance. By the way, are you taking a Java class and not telling me about it :-)?
Ok, back to the content management abstraction. In my world, the W3 has created 2 levels of abstraction. They created an abstraction for structure (XHTML) and an abstraction for design (CSS). When put together you have a document. I would guess that CSS (if you work hard enough) can produce any layout, and XHTML can produce about 99.9% of all documents resonibly (limiting headers to h1-h6 might be why I say 99). There’s a layer though that most people don’t see. One that comes into play when you start working on dynamic sites and content management systems.
You start wondering how to abstract data from the structure.
Think about it: All documents must have the same structure of sorts,
h1, h2, p, h3, p, p, p, ul, h3, h2. You get the idea.
So why not take the data that goes with those sections and abstract them out. The question is, how to do that when we don’t really know what the content is. That get’s us to our new favorite thing at the W3. XML.
XML is a way to abstract the data. It is, in it’s very essence, a tree. A tree that you can navigate, parse, grow, and search. It contains meta data for the data which tells us what the content is. With this wonderful abstraction, can we really abstract all the data from our structure?
This is where we get into something that becomes interesting, and I can kind of see how it works, but I don’t know enough yet. Let me compare it to something else I’ve fallen in love with in the last 2 days. The SQL command JOIN. Join allows you two link two pieces of data that share a column. It’s a little more detailed than that, but that’s all you really need to know. So for example, if table a and table b both have a column called ID, you can link the ID’s together. Very cool huh?
So let’s think about how CSS Joins XHTML. What do they have in common. Well, at it’s heart, CSS and XHTML have nothing in common. They have no linking point. That is, until you specify the first part of it.
What good would CSS do us if we just had:
border: 1px solid;
none, but what if we do this instead:
h1 {
border: 1px solid;
}
Then we know what to link it to in the document. So then the next question is, how do we link the data with the structure? First instinct tells you to do the same thing… But you run into an issue. Your issue is, your content looks EXACTLY like your structured document would. Why is that? Because really, XHTML is a form of XML with a certain namespace. If your having trouble with those terms, check out the w3.
So… the question then becomes, what really is content. And that is what I’m still working on. Globality, speed, and ease of use is our goal. DOM_XML here we come.
So that’s where we are… What is content…
In other news: I discovered a bug in my graph again today. It’s amazing how after using something so long, you don’t find the problem with it till later. It turned out that a majority of my bandwidth was coming from a module file that the image was calling. Why? Because everytime the image needed a smile, it would summon (via apache) the smile it needed. What it should have been doing is calling a function inside itself that loaded the smile. That’s what it does now, and hopefully that will save on the number 1 bandwidth user here on Rinse First.
Congrats goes out to Alex who got more linkage today.
Well, that’s all for me tonight. It’s been a great night!