Imagination and Visualization
The dimension of curiosity is an instinctive and rather primitive survival mechanism. By primitive I mean less related to intelligence. However, imagination is a mechanism associated with intelligence. Furthermore, the dimension of imagination is independent of curiosity and is not an evolved form of it, despite the fact that we generally use them in conjunction to one another.
It is our imagination that enables us to wonder and theorize. Generally, we think of imagination as a mechanism for visualization through our sense of vision. On the other hand, we have Beethoven, Dante and Shakespeare to think about. In particular, a mathematician’s mental images are not limited to geometrical figures even though the sense of vision is the main tool for visualizing concepts and formulations. Obviously, a mathematician does not hear the sounds of mathematical notions.
How does a software engineer visualize? Software visualization comes as close to that of mathematics as theoretical physics. However, a physicist’s thinking is predominated with mathematical concepts such as derivative, gradient or an entire structure such as Hilbert Space (Quantum Mechanics). So, what type of concepts does a software engineer use in his/her thoughts?
Let me first emphasize that Beethoven must have remembered and thought about previous parts of, let us say his 5th Symphony, before adding a new segment to it. The point is that, Beethoven did not write the symphony by simply making a new line and forgetting about it, and then making another new line. He must have had some way of visualizing much of the entire work in order to make corrections to it. After all Beethoven could not have had his QA team test it for him.
Visualization in the form of thinking in terms of concepts requires language as a vehicle. A language could be the sounds of musical notes, the works of Michael Angelo, Leonardo da Vinci, or Shakespeare, a mathematician or a software engineer. In each case, what really matters is the level of maturity of the language. Perhaps mathematics is the best example for clarifying the point. Contemporary mathematics has a lot more notions and is much more expressive than the time of Euclid. We can model a much larger set of problems with more precision than olden days.
Software development has accumulated a large set of notions. In this note, we are primarily interested in the domain of applications as opposed to system specific programs. By notions I mean to say that the concepts are independent of any particular physical device (excluding user interactions). Furthermore, applications are abstractions modeling automation problems, such as insurance industry. In particular, an insurance analyst does not think in terms of Windows, Linux or whatever else. The modeling of an insurance problem for purposes of automation, accordingly, should only involve software abstraction within a language and independent of any system specific code. When using mathematics for modeling we do not think of theorems that only hold on a particular platform.
One criterion for measuring the level of maturity of a programming language for developing software is its closure. A language that needs help from a platform is not closed. In particular, system calls are gaps in the level of maturity of an abstract language.
A closed language without sufficient abstractions is not mature either. A huge library contributed by user community only increases the chaos to the time before Euclid. It is hard, if not impossible to think (visualize) in terms of library API (application programming interface). Libraries have all types of uses, but replacing linguistic notions is not one of them. Imagine Shakespeare using a small vocabulary, and describing the rest of his vocabulary with a paragraph per word. Ignoring the loss of beauty, just how readable would his work be? Would we be talking about it today?
By definition, libraries cannot increase the degree of abstractions supported by a programming language. The addition of a useful notion, such invariant, constraint or resumption from exception, must be orthogonal to the rest of the language in order to elevate the level of language for visualization. Libraries increase the utility of a language in the same dimension as the language because their additions to the language cannot be orthogonal to the rest of the language.
When using trigonometry I see the entire process of reducing an expression to another (as in establishing a trigonometric identity). This happens in other areas such as transformations in symbolic integration. On the other hand, when dealing with a geometrical problem I know I visualize circles, tangents etc. Perhaps the most interesting of these for our purposes is when I see (somehow) theorems and logical deductions in an abstract setting (take Banach Space as an example). Here, the visualization is mostly in terms of a spoken language. In fact, I can actually express my thoughts to another mathematician without pencil and paper.
Consider the notions of component-orientation and autonomous agents. In a manner analogous to mathematical notions of derivative and integral, these are abstractions that we need in order to model automation problems. We must be able to visualize our solutions within a language that has sufficiently evolved by automating such notions. If I think in terms of differentiation (requiring the notion of continuity) but try to solve my problem within the notions of algebra (discrete mathematics) my abstract model will not be a good approximation to the reality.
Perhaps someday engineers will visualize their solutions in Z++. Until then, they will have to implement their solution for calculus problems, in algebra.
On July 21 my first grandchild will be born. I neither know the gender, nor the name. All the same, this is the only gift that grandfather can afford. This article is devoted to my grandchild to be born to my eldest son, Payam.
Dr. Z.
It is our imagination that enables us to wonder and theorize. Generally, we think of imagination as a mechanism for visualization through our sense of vision. On the other hand, we have Beethoven, Dante and Shakespeare to think about. In particular, a mathematician’s mental images are not limited to geometrical figures even though the sense of vision is the main tool for visualizing concepts and formulations. Obviously, a mathematician does not hear the sounds of mathematical notions.
How does a software engineer visualize? Software visualization comes as close to that of mathematics as theoretical physics. However, a physicist’s thinking is predominated with mathematical concepts such as derivative, gradient or an entire structure such as Hilbert Space (Quantum Mechanics). So, what type of concepts does a software engineer use in his/her thoughts?
Let me first emphasize that Beethoven must have remembered and thought about previous parts of, let us say his 5th Symphony, before adding a new segment to it. The point is that, Beethoven did not write the symphony by simply making a new line and forgetting about it, and then making another new line. He must have had some way of visualizing much of the entire work in order to make corrections to it. After all Beethoven could not have had his QA team test it for him.
Visualization in the form of thinking in terms of concepts requires language as a vehicle. A language could be the sounds of musical notes, the works of Michael Angelo, Leonardo da Vinci, or Shakespeare, a mathematician or a software engineer. In each case, what really matters is the level of maturity of the language. Perhaps mathematics is the best example for clarifying the point. Contemporary mathematics has a lot more notions and is much more expressive than the time of Euclid. We can model a much larger set of problems with more precision than olden days.
Software development has accumulated a large set of notions. In this note, we are primarily interested in the domain of applications as opposed to system specific programs. By notions I mean to say that the concepts are independent of any particular physical device (excluding user interactions). Furthermore, applications are abstractions modeling automation problems, such as insurance industry. In particular, an insurance analyst does not think in terms of Windows, Linux or whatever else. The modeling of an insurance problem for purposes of automation, accordingly, should only involve software abstraction within a language and independent of any system specific code. When using mathematics for modeling we do not think of theorems that only hold on a particular platform.
One criterion for measuring the level of maturity of a programming language for developing software is its closure. A language that needs help from a platform is not closed. In particular, system calls are gaps in the level of maturity of an abstract language.
A closed language without sufficient abstractions is not mature either. A huge library contributed by user community only increases the chaos to the time before Euclid. It is hard, if not impossible to think (visualize) in terms of library API (application programming interface). Libraries have all types of uses, but replacing linguistic notions is not one of them. Imagine Shakespeare using a small vocabulary, and describing the rest of his vocabulary with a paragraph per word. Ignoring the loss of beauty, just how readable would his work be? Would we be talking about it today?
By definition, libraries cannot increase the degree of abstractions supported by a programming language. The addition of a useful notion, such invariant, constraint or resumption from exception, must be orthogonal to the rest of the language in order to elevate the level of language for visualization. Libraries increase the utility of a language in the same dimension as the language because their additions to the language cannot be orthogonal to the rest of the language.
When using trigonometry I see the entire process of reducing an expression to another (as in establishing a trigonometric identity). This happens in other areas such as transformations in symbolic integration. On the other hand, when dealing with a geometrical problem I know I visualize circles, tangents etc. Perhaps the most interesting of these for our purposes is when I see (somehow) theorems and logical deductions in an abstract setting (take Banach Space as an example). Here, the visualization is mostly in terms of a spoken language. In fact, I can actually express my thoughts to another mathematician without pencil and paper.
Consider the notions of component-orientation and autonomous agents. In a manner analogous to mathematical notions of derivative and integral, these are abstractions that we need in order to model automation problems. We must be able to visualize our solutions within a language that has sufficiently evolved by automating such notions. If I think in terms of differentiation (requiring the notion of continuity) but try to solve my problem within the notions of algebra (discrete mathematics) my abstract model will not be a good approximation to the reality.
Perhaps someday engineers will visualize their solutions in Z++. Until then, they will have to implement their solution for calculus problems, in algebra.
On July 21 my first grandchild will be born. I neither know the gender, nor the name. All the same, this is the only gift that grandfather can afford. This article is devoted to my grandchild to be born to my eldest son, Payam.
Dr. Z.
Labels: imagination, language, visualization
posted by Dr.Z. at 11:19 PM
2 Comments:
Please forgive me. I'm so sorry. I said things I shouldn't have. I'm so sorry.
I just saw all your comments. Thank you. I only posted the last one. If you wish I can post all of them.
I am headed to homelessness in just a few short weeks, unless a miracle occurs. Do not be concerned, the boys will shelter me. However, that will not be my home, will it?
Thanks again, and take care.
Z.
Post a Comment
<< Back to Blogger Start Page >>