Software magicians of the tribe
In the olden days, anyone getting sick would be taken to the tribe’s healer. When a patient died, it was generally presumed that the patient was possessed, or something like that. Actually, that is a general pattern for the evolution of most of our beliefs and notions, albeit with different coloring. Superstition is only one of the many variations of this phenomenon.
A software developer is usually a self-trained software engineer, who sometimes proudly announces that his college training was a total waste. He is capable of developing complex software in a variety of languages, and simultaneously interacting with a multitude of technologies such as Web, Database, operating systems etc.
As reflected by their job descriptions, software companies are well aware of this magical capability. At the other end of the spectrum, scientists are talking about formal and disciplined methods of developing software. In between, we are losing astronauts, equipment, and cell-phone calls. The most expensive of these losses, that is astronauts, has become rare, only to reappear in hospitals where we lose patients instead.
The nature of low-level software for controlling a patient’s life-support system is not a topic for a blogger. In other articles I have classified domains of software development, and indicated that the domain of applications has a completely different nature than others.
Specifically, developing an application is an abstract process quite apart from programming devices. You are probably reading this as, specification and design should be done without taking any particular device into consideration. Actually, I am speaking of the development, the phase during which we write the “code”.
Perhaps the title of this note makes more sense when we realize that most of the development activity is in the area of applications, with the highest rate of failure. In other words, the majority of software is application as opposed to life-support systems. Admittedly it is not easy, and at times not even feasible to apply formal methods. In particular, almost all applications require some form of user interface, an area outside of scope of formal methods.
Crafting a graphical user interface is somewhat like a tailor’s activity. After all, a tailor must make exact measurements and use a handful of tools and equipment. Now, a tailor does not choose his scissors based on the shape and size of his customer. However, a developer picks C# for one kind of target, and Java for another, etc. Since neither one of these languages are adequate, he always falls back on C++ to make things actually work. At the end we have a mush of languages, as well as all the gluing languages, which is why software companies believe in the existence of Software Magicians.
The development of an application is just as abstract as is the creation of its graphical user interface. We create GUI very much like the drawing of an artist on a canvas. Our expectation is that, once we are done with the drawing itself, the problem is solved. That is, engineers do not need to encode the GUI for any particular platform.
The expression of a solution, as a development of an application, should look and feel abstract and algorithmic. The solution should not be in the form of lengthy chains of obscure encoding resulting from the limitations and inadequacies of the language. In particular, writing code in several languages promotes the bad habit of translating peculiar encoding techniques of one language into another, which may actually have appropriate abstractions. But then, with all these partial languages around how does one avoid having to deal with multiple languages.
Z++ includes the entire language C++ as a subset. The ability of Z++ complier to link with C++ DLLs is only for Service-oriented Architecture. After all, C++ barely furnishes half of the constructs needed for abstract software development. Furthermore, Z++ is truly platform independent with exactly one version of the language for all platforms, small and big alike.
Z++ Visual is freely available from ZHMicro.
A software developer is usually a self-trained software engineer, who sometimes proudly announces that his college training was a total waste. He is capable of developing complex software in a variety of languages, and simultaneously interacting with a multitude of technologies such as Web, Database, operating systems etc.
As reflected by their job descriptions, software companies are well aware of this magical capability. At the other end of the spectrum, scientists are talking about formal and disciplined methods of developing software. In between, we are losing astronauts, equipment, and cell-phone calls. The most expensive of these losses, that is astronauts, has become rare, only to reappear in hospitals where we lose patients instead.
The nature of low-level software for controlling a patient’s life-support system is not a topic for a blogger. In other articles I have classified domains of software development, and indicated that the domain of applications has a completely different nature than others.
Specifically, developing an application is an abstract process quite apart from programming devices. You are probably reading this as, specification and design should be done without taking any particular device into consideration. Actually, I am speaking of the development, the phase during which we write the “code”.
Perhaps the title of this note makes more sense when we realize that most of the development activity is in the area of applications, with the highest rate of failure. In other words, the majority of software is application as opposed to life-support systems. Admittedly it is not easy, and at times not even feasible to apply formal methods. In particular, almost all applications require some form of user interface, an area outside of scope of formal methods.
Crafting a graphical user interface is somewhat like a tailor’s activity. After all, a tailor must make exact measurements and use a handful of tools and equipment. Now, a tailor does not choose his scissors based on the shape and size of his customer. However, a developer picks C# for one kind of target, and Java for another, etc. Since neither one of these languages are adequate, he always falls back on C++ to make things actually work. At the end we have a mush of languages, as well as all the gluing languages, which is why software companies believe in the existence of Software Magicians.
The development of an application is just as abstract as is the creation of its graphical user interface. We create GUI very much like the drawing of an artist on a canvas. Our expectation is that, once we are done with the drawing itself, the problem is solved. That is, engineers do not need to encode the GUI for any particular platform.
The expression of a solution, as a development of an application, should look and feel abstract and algorithmic. The solution should not be in the form of lengthy chains of obscure encoding resulting from the limitations and inadequacies of the language. In particular, writing code in several languages promotes the bad habit of translating peculiar encoding techniques of one language into another, which may actually have appropriate abstractions. But then, with all these partial languages around how does one avoid having to deal with multiple languages.
Z++ includes the entire language C++ as a subset. The ability of Z++ complier to link with C++ DLLs is only for Service-oriented Architecture. After all, C++ barely furnishes half of the constructs needed for abstract software development. Furthermore, Z++ is truly platform independent with exactly one version of the language for all platforms, small and big alike.
Z++ Visual is freely available from ZHMicro.
Labels: abstract language, software engineer, Z++
1 Comments:
re "a programmer proudly announces that his college training was a total waste." my brother is a top programmer and never even got his GED, much less any college..... he makes a lot more money than i or any of my other brothers....
Post a Comment
<< Back to Blogger Start Page >>