- Everything is a program, so just write them directly
- 14 Jun 2016 02:49:12 pm
- Last edited by shkaboinka on 17 Jun 2016 08:33:40 am; edited 3 times in total
Professional software is typically built in layers: source code specifies what the software is/does; configuration files configure the built product; project files specify how it gets built; external "build scripts" automate the process of building, testing, and packaging-up the software product for use; and the installers are essentially a bundle of even more "build scripts" that do the work of installing.
So what's really going on here?
It's all just layers of instructions for what to do with what. In other words, it's all just a big computer program which generates a software product. Software engineering boils down to making programs which manipulate and generate other programs!
This process SHOULD afford complete control over every last detail of the software product being built; HOWEVER, the common practice for "computer programming" imposes needless layers of language barriers which highly restrict any control one has over the generated software product.
Any tool that processes input (user input, code, or configuration), also controls the grammar (i.e. expected format) for its input, and thus also defines a language for which it is the interpreter (e.g. it can read instructions and do what they say, even if those instructions are limited to setting values).
In other words, any such input (e.g. a configuration file) IS a program, but is only as capable as its "programming language" allows it to be.
This also means that any tool (program) which processes inputs of language X is also a virtual machine for language X. Going the other way, a computer processor (CPU) is nothing more than a hard-wired program that processes input in some assembly language. Ergo, programs are processors are computers ("virtual machines").
A compiler is a program which reads code in language X and converts it into language Y.
BUT WAIT, since the compiler is itself a virtual machine for language X, then code written in language-X IS a program which is executed by the compiler. Since the compiler spits out program Y by running X, a program in X is REALLY just a program which builds a program in Y.
Thus, a compiler specifies (is a computer for) a language X for which the ONLY kind of program that can be written, is a program that generates another program Y; but that Y program can only be made from the kinds of building blocks of language X. So, you really cannot write an X program with full control of what goes into Y.
MY POINT:
Rather than being limited only to the language of the compiler, or of the build-tool, or of the project-file, why not just directly write the actual program that makes the software product? This option is ENTIRELY available RIGHT NOW, so there is no excuse for a software engineer to NOT be capable of being 100% a master of his own craft (construction-wise).
THOUSANDS of programming languages exist, but they are all specific configurations of only a few core ways of doing software.
If instead of writing programs for specific compiler-languages, we start writing programs to make programs, then the concept of "programming language" can stop being a hard wired thing and become something that you cobble together however you want, for the specific software being made.
For example, a "class" or a "function" is not part of a set-in-stone grammar, but part of a code library that you import or make yourself. When you declare an entity (e.g. a class) in a compiled language, it is really a command to GENERATE that entity into the built product; but instead of a command, it may as well be a function that you call to create one, and that entity-making-function is no different than any of the other code in your program-making-program.
(JavaScript already enjoys a good portion of this style; and this is also why ES6 makes me uncomfortable. DUDE, it was already a REAL language BECAUSE it was open ended, so way to hard wire it up!)
One last perspective:
Part of the language limitations imposed by a compiler comes from the fact that it acts like a framework rather than a library. A framework is an already-written program for which you can "fill in the blanks"; but you don't have any control over what it's doing, in what order, or making changes to its rigid structure. A library is a collection of pieces that you embed within YOUR program, and thus your code drives the component, rather than the other way around. What is a compiler other than a framework? Likewise, a framework defines it's own machine, and thus its own language. You can choose to program within that model, or write your own program to build the structure/wiring exactly how you want.
Processors are computers are programs are frameworks. Come to think of it, functions are programs with their own grammar and execution as well. You can call it and deal with its side effects, or you can write code specific for your specific case. There is no lock-in here, so why should it be this way with programming languages? (After all, they're all really the same thing. To paraphrase Alan Kay, It's programs (computers) all the way down!)
Addendum:
Certainly, this may be overkill for small/personal projects; but professional software has all these layers, often with lots of common points that all have to be lined up just right, especially for different configurations, and the wiring to put into it can essentially be on par with the effort of just writing a program to do it.
A good example is WiX (Windows Installer XML), which in my opinion would be infinitely more usable as a programming API than as an XML language. For example, I ran into a case just the other day where what I needed could only be accomplished by manually tweaking the built installer with Orca. The result is a perfectly valid installer, but WiX provided NO way to override the built-in table value that I needed. An API could provide all the same "language" conveniences, but also give me ad-hoc access to the tables I want to generate.
(Related Video)
So what's really going on here?
It's all just layers of instructions for what to do with what. In other words, it's all just a big computer program which generates a software product. Software engineering boils down to making programs which manipulate and generate other programs!
This process SHOULD afford complete control over every last detail of the software product being built; HOWEVER, the common practice for "computer programming" imposes needless layers of language barriers which highly restrict any control one has over the generated software product.
Any tool that processes input (user input, code, or configuration), also controls the grammar (i.e. expected format) for its input, and thus also defines a language for which it is the interpreter (e.g. it can read instructions and do what they say, even if those instructions are limited to setting values).
In other words, any such input (e.g. a configuration file) IS a program, but is only as capable as its "programming language" allows it to be.
This also means that any tool (program) which processes inputs of language X is also a virtual machine for language X. Going the other way, a computer processor (CPU) is nothing more than a hard-wired program that processes input in some assembly language. Ergo, programs are processors are computers ("virtual machines").
A compiler is a program which reads code in language X and converts it into language Y.
BUT WAIT, since the compiler is itself a virtual machine for language X, then code written in language-X IS a program which is executed by the compiler. Since the compiler spits out program Y by running X, a program in X is REALLY just a program which builds a program in Y.
Thus, a compiler specifies (is a computer for) a language X for which the ONLY kind of program that can be written, is a program that generates another program Y; but that Y program can only be made from the kinds of building blocks of language X. So, you really cannot write an X program with full control of what goes into Y.
MY POINT:
Rather than being limited only to the language of the compiler, or of the build-tool, or of the project-file, why not just directly write the actual program that makes the software product? This option is ENTIRELY available RIGHT NOW, so there is no excuse for a software engineer to NOT be capable of being 100% a master of his own craft (construction-wise).
THOUSANDS of programming languages exist, but they are all specific configurations of only a few core ways of doing software.
If instead of writing programs for specific compiler-languages, we start writing programs to make programs, then the concept of "programming language" can stop being a hard wired thing and become something that you cobble together however you want, for the specific software being made.
For example, a "class" or a "function" is not part of a set-in-stone grammar, but part of a code library that you import or make yourself. When you declare an entity (e.g. a class) in a compiled language, it is really a command to GENERATE that entity into the built product; but instead of a command, it may as well be a function that you call to create one, and that entity-making-function is no different than any of the other code in your program-making-program.
(JavaScript already enjoys a good portion of this style; and this is also why ES6 makes me uncomfortable. DUDE, it was already a REAL language BECAUSE it was open ended, so way to hard wire it up!)
One last perspective:
Part of the language limitations imposed by a compiler comes from the fact that it acts like a framework rather than a library. A framework is an already-written program for which you can "fill in the blanks"; but you don't have any control over what it's doing, in what order, or making changes to its rigid structure. A library is a collection of pieces that you embed within YOUR program, and thus your code drives the component, rather than the other way around. What is a compiler other than a framework? Likewise, a framework defines it's own machine, and thus its own language. You can choose to program within that model, or write your own program to build the structure/wiring exactly how you want.
Processors are computers are programs are frameworks. Come to think of it, functions are programs with their own grammar and execution as well. You can call it and deal with its side effects, or you can write code specific for your specific case. There is no lock-in here, so why should it be this way with programming languages? (After all, they're all really the same thing. To paraphrase Alan Kay, It's programs (computers) all the way down!)
Addendum:
Certainly, this may be overkill for small/personal projects; but professional software has all these layers, often with lots of common points that all have to be lined up just right, especially for different configurations, and the wiring to put into it can essentially be on par with the effort of just writing a program to do it.
A good example is WiX (Windows Installer XML), which in my opinion would be infinitely more usable as a programming API than as an XML language. For example, I ran into a case just the other day where what I needed could only be accomplished by manually tweaking the built installer with Orca. The result is a perfectly valid installer, but WiX provided NO way to override the built-in table value that I needed. An API could provide all the same "language" conveniences, but also give me ad-hoc access to the tables I want to generate.
(Related Video)