2004-11-17
2004-10-31
Tribe Discussion: Bodhisattvas - tribe.net: "October 30, 2004 - 07:31 PM new
Re: MISSION CLARIFICATION
1. To do the greatest amount of good for the largest number of people while causing the least amount of harm to the fewest number of people, all without imposing my will as much as possible.
2. Increase my level of awareness and observation every moment of every day. Inspire in others the desire to do the same.
3. To see the Truth in all things. "
Re: MISSION CLARIFICATION
1. To do the greatest amount of good for the largest number of people while causing the least amount of harm to the fewest number of people, all without imposing my will as much as possible.
2. Increase my level of awareness and observation every moment of every day. Inspire in others the desire to do the same.
3. To see the Truth in all things. "
2004-10-29
2004-06-12
Ablitics is the study of seemingly complex systems, searching for the simple underlying patterns behind them.
It's about the realization that we as programmers make everything more complex then things actually are.
If with traditional programming we write 1000 lines of code to solve a problem, then with Slice and Dice (the Simple Pattern Replication philosophy) we say that we can generate 10,000 lines of code that will be faster to write and execute, easier to maintain and enhance, yet be highly replicatable to a variety of tasks. Ablitics says if we had paid attention initially, we'd have seen we would have only needed 100 lines in the first place.
Each template in Slice and Dice is more than just a way to get something done more quickly. It is an expression of the simplicity behind a task that a programmer has to achieve.
Error handlers, for instance. You got tired of writing the same error handlers over and over again. You saw the pattern behind them. Go to the top of the current function, insert a couple of lines, go to the bottom and insert a few more utilizing the context of the function itself.
Yet if you think about it, the way you write an error handler and the way I write an error handler are different. The specifics that is. Still, there is a pattern behind the way that you and I write an error handler.
If we expand our field of thought to all programmers and the way all programmers write an error handler, we could further refine the pattern behind the way everyone writes error handlers in each language of their choice. A pattern emerges to the pattern behind writing error handlers.
If we expand our field of thought even further to the way all programmers approach writing all code, a pattern behind the pattern behind the pattern emerges.
What's amazing about each pattern is that it is a more simple to implement pattern. Each level of abstraction somehow becomes more concretely definable within the context of our abstract thoughts. This is what I call a concrete abstract, a template is a good example of a concrete abstract as it allows the programmer to take an abstract, they way he performs some sets of actions, and express them concretely even to the point of tangibly transferring the knowledge of performing that task to another programmer like I do when I share my templates with the world.
If we zoom back into you, we suddenly see that, as with the pattern behind all coding, there is a pattern behind the way that you code. Likewise, there is a pattern to the way I code. These patterns are very different, but cover a lot of the same ground. Areas of your pattern will overlap my pattern and other areas will stretch into places neither reaches. Further, as we include other programmers in the picture, each has a greater chance for overlap, but will still reveal a unique portion of the pattern no one else brought to the table.
This implies that the sum of our patterns form, you guessed it, another pattern. This pattern to our collective pattern is another concrete abstract, sort of like a differential equation is to a quadratic. I would like to stress at this point that the comparison to mathematics is purely a metaphor. There is no mathematics in any of my philosophies, only patterns.
As you move up the chain of patterns, each becoming simpler than the last, a common theme to those patterns emerges; this is what I call an Alpha Pattern.
I've been told that I use the word pattern too much, and it's important to understand that when I'm talking about patterns in programming I do not mean development patterns or management patterns, but coding patterns.
Go to the top of the class, add a private string, go to the bottom of the class, add a property get and property set, repeat for every field in the table, and repeat for every table in the database.
Slice and Dice is a representation of the second philosophy I developed, Simple Pattern Replication.
However, as I used Slice and Dice, writing more and more of my coding patterns (templates), an interesting thing happened. The pattern I was talking about, my pattern, began to emerge from the templates. Several hundred templates later, I came to get the bazaar feeling that Slice and Dice was "showing" and "implying" templates to write.
I can do A and C which implies B. And when I write a template that does F, D and E suddenly become obvious. I can take a list of fields and generate an array from them (A), I can read and write to the clipboard (C), I can read a list of fields from the clipboard and write an array to the clipboard (C).
Simply Pattern Replication was actually showing me areas of my coding pattern that I did not possess. Eerie in its implications, a program was teaching me how to program better. It was as if there was a shape behind the way that I coded, what I now call my coding pattern. All I had to do was follow the path the pattern took and it naturally led me to a greater understanding of my code and myself.
This suddenly led to the understanding that there was not only a "master" pattern behind the way that I wrote code, but behind the way everyone wrote code. Each programmer contributing a unique set of skills, templates that collectively reveal a base pattern behind coding itself.
This realization that pattern existed in a visceral form, one that could not only be observed, but actively described as a series of small steps (as with SoftCommands), that a language could emerge to describe the way a pattern works, lead me to think of programming from the inside out.
Ablitics came at me like a rush taking only a few months to formulate, contemplate, categorize, and start using.
But before going into Ablitics, let me take a step back and explain the first philosophy I came up with, FlexCode.
Simple Pattern Replication was the second philosophy I developed. Ablitics was the third, which flowed naturally from the second. In a similar way, Simple Pattern Replication flows from FlexCode.
FlexCode says that we can write generic applications that make a set of assumptions about a given business and allow the inputs and outputs to "flex" around those assumptions. Forms, reports, tables, and fields flow from these assumptions and are dynamically generated at run-time based on Meta data stored in a database. Thus instead of creating a series of input forms, you create a single form that implements a set of rules that follow the assumptions and dynamically flexes to the required task at the required time.
Once written, a FlexCode application can be made to change extraordinarily fast since all of the configurations are stored in tables that describe what the forms and reports should look like instead of hard coding that describes a form or a report.
Unfortunately, FlexCode applications are extremely difficult to write and take a pretty good chunk of time. Further, almost no results can be seen until practically the end. Clients don't like this. However, they love the final result that they can change at the drop of a hat.
Another downside to FlexCode is the base assumptions. If any of them change, large portions of the FlexCode application must be re-written which always takes as long as the original set of assumptions took to implement, if not longer.
This length of time to implement led me to lose a client. When I finally had something to show them, they had already lost interest since they couldn't see the product as it developed. There was nothing to see until the end because so much of the visible portion of the coding comes at the end of a FlexCode development cycle.
This loss forced me to rethink the way I wrote code. Indeed, I soon had the thought "what would happen if I turned the idea of FlexCode inside out". I'd have a FlexCode application that generated static representations of dynamic models. I could generate the forms, reports, whatever I needed at will. Further, if I made the FlexCode application generic and assumed that the actual code to generate would be interspersed with very granular commands that described how I wrote code, I could create an infinite number of these templates.
Within a few weeks I had the beginnings of Slice and Dice. The database to code generator was the first feature that represented the dynamic mapping from database to forms I previously had FlexCode dynamically creating at run-time. Ironically, I could now generate a set of forms as fast as I could write the tables to persist their information. It didn't do 100% of the work, but took away the 95% that was boring and tedious and allowed me to concentrate on the actual differences between one application and the next. In fact, writing data persistence layers became trivial as I could generate an entire hierarchy of objects that read and wrote to the underlying tables that described the objects themselves.
So at this point we can see where traditional programming gave way to an attempt to make generic, FlexCode applications, which lead me to create Slice and Dice (a FlexCode application) that gave me the freedom to perform Simple Pattern Replication. These simple patterns themselves eventually lead me to understand my overall coding pattern and that others had these patterns.
In fact, when you think about it, this same observation could be made not only about programming, but authors, scriptwriters, documenters, or anyone who writes anything. Or for that matter, with some careful thought, one realizes that pattern exists in everything that anyone does anything with any object. This realization gave way to the understanding that pattern systems exist, could be described, and even manipulated regardless of their seeming complexity.
In Ablitics, I call these systems Ablitic Systems.
They always include the same things:
Active Participants,
Passive Definables, and
Their Interactions
Which shift through time.
The shifting through time is the most important part.
I define the Universe to be an Ablitic System of Ablitic Systems.
As for the other two philosophies, these are somewhat difficult to talk about as I am still exploring them.
However, it goes like this.
There was a time when you didn't know how to drive and you had to learn. Your active mind was involved in every step of the operation of driving until you became comfortable and trained to drive. However, today, you don't think about driving, you just do it. That's because you've trained your subconscious (what I shall from now on refer to as your Intuition) to drive for you. In fact, you can probably drive yourself to work and back home without even thinking about any of the steps involved.
So if we have trained our Intuition to drive for us, isn't it logical to assume we do the same thing with anything we do with any object we learn to manipulate. Typing for instance. Or more important to this conversation, Programming.
That's right. We've been training our Intuition this entire time to write code for us. So why no leverage that enormous amount of built-in processing power within ourselves and stop thinking about writing code consciously. Instead we turn that task over to our Intuition, guiding it as little as possible.
Just like we let our Intuition drive us to work and back home again safely, so would we allow it to write code that naturally takes us to the solution to the problem we're currently trying to solve. And even more importantly that solution will fit naturally, even organically, into a set of solutions, each designed to interlock with one another to increasing levels of benefit and ability.
This I call, Intuitive Programming. It's the conscious choice to remove the consciousness from the act of programming whenever possible. It's a very difficult technique to master, and one that I am still working on.
However, an interesting thing happens as I've explored this technique. What does the conscious mind do while the Intuition is coding?
Clearly some mental and physical energy has to be expended to accomplish a task. But why limit ourselves to a single task?
Our Intuition is constantly performing dozens if not thousands of simultaneous tasks in keeping the body going.
In cause you're wondering, I define Intuition as that sub/super conscious portion of our mind that actively learns to perform tasks throughout our lives. I define instinct as those qualities that have been learned genetically. Generally, I consider instinct to be inferior to Intuition as it is the basis for our fears and what holds us back in our lives far more than it saves us.
So now we have our Intuition programming for us, but with the realization that our Intuition is capable of multiple, simultaneous action, it becomes important to allow those actions a semi-coordinated value to the real world of interaction.
That's where Temporal Programming enters the picture. Temporal Programming is when the conscious mind becomes a vehicle for the Intuition removing the last layer of resistance, silencing the questions, and allowing the multiple Intuitive ongoing tasks, time synchronized access to the real world.
Essentially, what it feels like is you suddenly become aware that 90 minutes have gone by, you've written 4 or 5 things, but you really don't remember how you got there. Because the consciousness became a vehicle for the Intuition that simply "flowed", you wind up with a solution without having to have defined the path to it. Invariably the code written this way is much simpler than the code we would have written had we really thought about it.
Needless to say, no beginning programmer could ever perform Intuitive or Temporal programming as one would have to have already trained the Intuition to program, which the beginning programmer has not yet done.
In fact Intuitive and Temporal programming are difficult for the typical programmer to actually do because of the sizable ego that seems to come along with the job. Ego is that quality of the conscious mind which is constantly questioning, doubting, controlling the processes attempting to out guess the Intuition in an attempt to train the Intuition to greater and greater feats. However, it eventually holds us back because ego eventually prevents progression as we become more set in our ways.
Intuitive and Temporal programming challenge the ego to "let go" of the process and in so doing, to allow further learning at an Intuitive level. It's a difficult and time-consuming process where the conscious mind must be trained to step aside. To listen to the little voice that says to do something and which you immediately think "why". That is the moment to listen to the little voice, do what it says, learn to listen to your self. Your Intuition has access to more information than you do since it is the active filter to your consciousness.
I wrote this document using these techniques. You see, since I've hit Ablitics, I've had the same conversation with people about Ablitics hundreds of times, each time training my Intuition to respond in more and more succinct ways. As I look at the length of this email, it's hard to believe that it only took about an hour to write. I'm not a writer, yet with the Intuition in charge, it's easy.
I hope you have enjoyed reading it as much as I have to write it.
------------------------------------------------------------------------
I'll stop at this point to allow you to absorb this, to read the Ablitic Primer (http://www.sliceanddice.com/cpp.html) again, and respond with any questions you have.
It's about the realization that we as programmers make everything more complex then things actually are.
If with traditional programming we write 1000 lines of code to solve a problem, then with Slice and Dice (the Simple Pattern Replication philosophy) we say that we can generate 10,000 lines of code that will be faster to write and execute, easier to maintain and enhance, yet be highly replicatable to a variety of tasks. Ablitics says if we had paid attention initially, we'd have seen we would have only needed 100 lines in the first place.
Each template in Slice and Dice is more than just a way to get something done more quickly. It is an expression of the simplicity behind a task that a programmer has to achieve.
Error handlers, for instance. You got tired of writing the same error handlers over and over again. You saw the pattern behind them. Go to the top of the current function, insert a couple of lines, go to the bottom and insert a few more utilizing the context of the function itself.
Yet if you think about it, the way you write an error handler and the way I write an error handler are different. The specifics that is. Still, there is a pattern behind the way that you and I write an error handler.
If we expand our field of thought to all programmers and the way all programmers write an error handler, we could further refine the pattern behind the way everyone writes error handlers in each language of their choice. A pattern emerges to the pattern behind writing error handlers.
If we expand our field of thought even further to the way all programmers approach writing all code, a pattern behind the pattern behind the pattern emerges.
What's amazing about each pattern is that it is a more simple to implement pattern. Each level of abstraction somehow becomes more concretely definable within the context of our abstract thoughts. This is what I call a concrete abstract, a template is a good example of a concrete abstract as it allows the programmer to take an abstract, they way he performs some sets of actions, and express them concretely even to the point of tangibly transferring the knowledge of performing that task to another programmer like I do when I share my templates with the world.
If we zoom back into you, we suddenly see that, as with the pattern behind all coding, there is a pattern behind the way that you code. Likewise, there is a pattern to the way I code. These patterns are very different, but cover a lot of the same ground. Areas of your pattern will overlap my pattern and other areas will stretch into places neither reaches. Further, as we include other programmers in the picture, each has a greater chance for overlap, but will still reveal a unique portion of the pattern no one else brought to the table.
This implies that the sum of our patterns form, you guessed it, another pattern. This pattern to our collective pattern is another concrete abstract, sort of like a differential equation is to a quadratic. I would like to stress at this point that the comparison to mathematics is purely a metaphor. There is no mathematics in any of my philosophies, only patterns.
As you move up the chain of patterns, each becoming simpler than the last, a common theme to those patterns emerges; this is what I call an Alpha Pattern.
I've been told that I use the word pattern too much, and it's important to understand that when I'm talking about patterns in programming I do not mean development patterns or management patterns, but coding patterns.
Go to the top of the class, add a private string, go to the bottom of the class, add a property get and property set, repeat for every field in the table, and repeat for every table in the database.
Slice and Dice is a representation of the second philosophy I developed, Simple Pattern Replication.
However, as I used Slice and Dice, writing more and more of my coding patterns (templates), an interesting thing happened. The pattern I was talking about, my pattern, began to emerge from the templates. Several hundred templates later, I came to get the bazaar feeling that Slice and Dice was "showing" and "implying" templates to write.
I can do A and C which implies B. And when I write a template that does F, D and E suddenly become obvious. I can take a list of fields and generate an array from them (A), I can read and write to the clipboard (C), I can read a list of fields from the clipboard and write an array to the clipboard (C).
Simply Pattern Replication was actually showing me areas of my coding pattern that I did not possess. Eerie in its implications, a program was teaching me how to program better. It was as if there was a shape behind the way that I coded, what I now call my coding pattern. All I had to do was follow the path the pattern took and it naturally led me to a greater understanding of my code and myself.
This suddenly led to the understanding that there was not only a "master" pattern behind the way that I wrote code, but behind the way everyone wrote code. Each programmer contributing a unique set of skills, templates that collectively reveal a base pattern behind coding itself.
This realization that pattern existed in a visceral form, one that could not only be observed, but actively described as a series of small steps (as with SoftCommands), that a language could emerge to describe the way a pattern works, lead me to think of programming from the inside out.
Ablitics came at me like a rush taking only a few months to formulate, contemplate, categorize, and start using.
But before going into Ablitics, let me take a step back and explain the first philosophy I came up with, FlexCode.
Simple Pattern Replication was the second philosophy I developed. Ablitics was the third, which flowed naturally from the second. In a similar way, Simple Pattern Replication flows from FlexCode.
FlexCode says that we can write generic applications that make a set of assumptions about a given business and allow the inputs and outputs to "flex" around those assumptions. Forms, reports, tables, and fields flow from these assumptions and are dynamically generated at run-time based on Meta data stored in a database. Thus instead of creating a series of input forms, you create a single form that implements a set of rules that follow the assumptions and dynamically flexes to the required task at the required time.
Once written, a FlexCode application can be made to change extraordinarily fast since all of the configurations are stored in tables that describe what the forms and reports should look like instead of hard coding that describes a form or a report.
Unfortunately, FlexCode applications are extremely difficult to write and take a pretty good chunk of time. Further, almost no results can be seen until practically the end. Clients don't like this. However, they love the final result that they can change at the drop of a hat.
Another downside to FlexCode is the base assumptions. If any of them change, large portions of the FlexCode application must be re-written which always takes as long as the original set of assumptions took to implement, if not longer.
This length of time to implement led me to lose a client. When I finally had something to show them, they had already lost interest since they couldn't see the product as it developed. There was nothing to see until the end because so much of the visible portion of the coding comes at the end of a FlexCode development cycle.
This loss forced me to rethink the way I wrote code. Indeed, I soon had the thought "what would happen if I turned the idea of FlexCode inside out". I'd have a FlexCode application that generated static representations of dynamic models. I could generate the forms, reports, whatever I needed at will. Further, if I made the FlexCode application generic and assumed that the actual code to generate would be interspersed with very granular commands that described how I wrote code, I could create an infinite number of these templates.
Within a few weeks I had the beginnings of Slice and Dice. The database to code generator was the first feature that represented the dynamic mapping from database to forms I previously had FlexCode dynamically creating at run-time. Ironically, I could now generate a set of forms as fast as I could write the tables to persist their information. It didn't do 100% of the work, but took away the 95% that was boring and tedious and allowed me to concentrate on the actual differences between one application and the next. In fact, writing data persistence layers became trivial as I could generate an entire hierarchy of objects that read and wrote to the underlying tables that described the objects themselves.
So at this point we can see where traditional programming gave way to an attempt to make generic, FlexCode applications, which lead me to create Slice and Dice (a FlexCode application) that gave me the freedom to perform Simple Pattern Replication. These simple patterns themselves eventually lead me to understand my overall coding pattern and that others had these patterns.
In fact, when you think about it, this same observation could be made not only about programming, but authors, scriptwriters, documenters, or anyone who writes anything. Or for that matter, with some careful thought, one realizes that pattern exists in everything that anyone does anything with any object. This realization gave way to the understanding that pattern systems exist, could be described, and even manipulated regardless of their seeming complexity.
In Ablitics, I call these systems Ablitic Systems.
They always include the same things:
Active Participants,
Passive Definables, and
Their Interactions
Which shift through time.
The shifting through time is the most important part.
I define the Universe to be an Ablitic System of Ablitic Systems.
As for the other two philosophies, these are somewhat difficult to talk about as I am still exploring them.
However, it goes like this.
There was a time when you didn't know how to drive and you had to learn. Your active mind was involved in every step of the operation of driving until you became comfortable and trained to drive. However, today, you don't think about driving, you just do it. That's because you've trained your subconscious (what I shall from now on refer to as your Intuition) to drive for you. In fact, you can probably drive yourself to work and back home without even thinking about any of the steps involved.
So if we have trained our Intuition to drive for us, isn't it logical to assume we do the same thing with anything we do with any object we learn to manipulate. Typing for instance. Or more important to this conversation, Programming.
That's right. We've been training our Intuition this entire time to write code for us. So why no leverage that enormous amount of built-in processing power within ourselves and stop thinking about writing code consciously. Instead we turn that task over to our Intuition, guiding it as little as possible.
Just like we let our Intuition drive us to work and back home again safely, so would we allow it to write code that naturally takes us to the solution to the problem we're currently trying to solve. And even more importantly that solution will fit naturally, even organically, into a set of solutions, each designed to interlock with one another to increasing levels of benefit and ability.
This I call, Intuitive Programming. It's the conscious choice to remove the consciousness from the act of programming whenever possible. It's a very difficult technique to master, and one that I am still working on.
However, an interesting thing happens as I've explored this technique. What does the conscious mind do while the Intuition is coding?
Clearly some mental and physical energy has to be expended to accomplish a task. But why limit ourselves to a single task?
Our Intuition is constantly performing dozens if not thousands of simultaneous tasks in keeping the body going.
In cause you're wondering, I define Intuition as that sub/super conscious portion of our mind that actively learns to perform tasks throughout our lives. I define instinct as those qualities that have been learned genetically. Generally, I consider instinct to be inferior to Intuition as it is the basis for our fears and what holds us back in our lives far more than it saves us.
So now we have our Intuition programming for us, but with the realization that our Intuition is capable of multiple, simultaneous action, it becomes important to allow those actions a semi-coordinated value to the real world of interaction.
That's where Temporal Programming enters the picture. Temporal Programming is when the conscious mind becomes a vehicle for the Intuition removing the last layer of resistance, silencing the questions, and allowing the multiple Intuitive ongoing tasks, time synchronized access to the real world.
Essentially, what it feels like is you suddenly become aware that 90 minutes have gone by, you've written 4 or 5 things, but you really don't remember how you got there. Because the consciousness became a vehicle for the Intuition that simply "flowed", you wind up with a solution without having to have defined the path to it. Invariably the code written this way is much simpler than the code we would have written had we really thought about it.
Needless to say, no beginning programmer could ever perform Intuitive or Temporal programming as one would have to have already trained the Intuition to program, which the beginning programmer has not yet done.
In fact Intuitive and Temporal programming are difficult for the typical programmer to actually do because of the sizable ego that seems to come along with the job. Ego is that quality of the conscious mind which is constantly questioning, doubting, controlling the processes attempting to out guess the Intuition in an attempt to train the Intuition to greater and greater feats. However, it eventually holds us back because ego eventually prevents progression as we become more set in our ways.
Intuitive and Temporal programming challenge the ego to "let go" of the process and in so doing, to allow further learning at an Intuitive level. It's a difficult and time-consuming process where the conscious mind must be trained to step aside. To listen to the little voice that says to do something and which you immediately think "why". That is the moment to listen to the little voice, do what it says, learn to listen to your self. Your Intuition has access to more information than you do since it is the active filter to your consciousness.
I wrote this document using these techniques. You see, since I've hit Ablitics, I've had the same conversation with people about Ablitics hundreds of times, each time training my Intuition to respond in more and more succinct ways. As I look at the length of this email, it's hard to believe that it only took about an hour to write. I'm not a writer, yet with the Intuition in charge, it's easy.
I hope you have enjoyed reading it as much as I have to write it.
------------------------------------------------------------------------
I'll stop at this point to allow you to absorb this, to read the Ablitic Primer (http://www.sliceanddice.com/cpp.html) again, and respond with any questions you have.
Subscribe to:
Posts (Atom)
