While this country has done rather well with a single spoken and written language, English, the most powerful and useful tool ever created by humanity, it remains convinced that it cannot do without a vast array of programming languages. Literally thousands of different languages exist, and, by some estimates, six to eight hundred of them remain in active commercial use today.
The software industry employs numerous highly skilled and imaginative individuals, among whom it appears to be a badge of distinction to have “invented” one’s own programming language. This has resulted in a wealth of toy languages of varying degrees of commercial acceptance. Instead of adapting and refining a single language to better deal with an expanding array of requirements, the industry instead invents new languages, each with its own grammar, rules, peculiarities, and weaknesses. The inevitable consequence is a polyglot disaster in which programmers struggle to master sufficient different languages in order to address their own job demands.
Invoking the image of Babel seems too obvious to belabor, but, as this is our reality, we must select from this cacophony of alternatives a language that satisfies several critical criteria:
Second — It must be usable as a general-purpose tool. For sheer power, you cannot beat machine code. It enables the programmer to bring into play every single feature designed into the CPU. Machine code programmers are rare; they can be recognized by the fact that their feet do not touch the floor when they walk across the room.
Assembly language has almost the same power and is far more human-friendly, but not quite enough. Worse, it is CPU-specific and the very epitome of non-portability. Forget that.
We need a language with sufficient abstraction to insulate the novice programmer from the vicissitudes of coding close to the metal while not boxing her into a narrow range of capabilities. A database language such as SQL, for instance, would have great power but only within its specialty. Not for us.
Third — It must be popular enough to be both well-supported and in demand commercially. A language used by a large percentage of active programmers will benefit from ample resources readily available via the ubiquity of the Internet. This seemingly modest characteristic can easily spell the difference between success and failure for the new programmer.
Fourth — Our choice must be up-to-date. The computer science student at university has no choice but to learn OOP. The casual amateur can easily choose to avoid OOP complexity and remain comfortably within the gentle arms of conventional procedural coding.
Consider the granddaddy of all modern programming languages, the elegant C. Any language as universally usable as C has to be one of our candidates. But, would this be wise? We are not certain. Thus, our chosen language may require OOP capability designed into it . . . or it may not care to be objectified. Stay tuned.
(Just for the record, C is a viable candidate for this series.)
Fifth — Some of our audience will go on to serious, full-time, formal education in programming. For them, what they learn in their introduction to software developing in “The Art of Programming” must be fully compatible with their future studies. This means encouraging such habits as useful and informative code commenting, thinking the application domain through before coding, and implementing code reusability when and as optimal.
Sixth — A very low price of admission matters greatly. The need to install complex toolsets won’t dissuade a full-time programmer from considering a language to work with, any more than a carpenter refusing to build a house because it means buying a hammer and saw. For our audience, however, the game must be played under very different rules. Ideally, the student should be able to follow the course without buying or installing anything that she does not already have. A computer and an Internet connection will suffice.
However . . . this could end up going in any of a variety of directions. What remains certain is that the student following the lessons in this series must be able to do so without needing to purchase any extra hardware or software.
Although some languages have first-class toolsets available at no cost, these resources can occasionally carry a hidden price: they introduce significant additional learning-curve burdens that can easily defeat the average student’s desire to master the language. Have you ever watched a complete neophyte trying to figure out Eclipse entirely on her own?
Seventh — A complete library of functions, including mathematics, collections, security, audio, video, images, regular expressions, strings and text, dates and times, scripting, networking, cryptography, databases, graphics, and printing.
Eighth — Interoperability with a reasonable subset of the software biosphere always defines the scope and usefulness of every programming language. It’s a given that low-level or system languages, such as C and C++, can do anything and connect with anything. High-level toy languages have only those capabilities designed into them, and these languages are by their very nature limited to narrower ranges of application. In selecting a language, the programmer must know clearly which functionalities her application will need and ensure that the language she uses will be able to provide them. One major case is database manipulation. For our circumstances, it will do very nicely to limit database coding to SQL, specifically, SQL Server, PostgreSQL and SQLite.
The real issue, however, is the ability to execute, on as close as possible to an inline basis, device drivers written in C and C++. The central course exercise in “The Art of Programming” will be a building automation system with unbounded scope for growth and expansion. As this necessitates utilization of proprietary industrial I/O hardware, each device with its own (usually) closed-source driver, our language must call external modules meant to be used in C and C++ code.
What, then, is our choice of language?
Choosing one’s first programming language can prove daunting. That notwithstanding, we need to pick one.
Java and C# are well-established, full-featured languages which differ primarily in the breadth of platforms on which they run. Or not. Java clearly has the advantage in that it comes closer to being platform-agnostic than C# currently does or likely will in the near future.
We cannot overstress the importance of making the entire learning process friendly and easy. Abandoning a four-year CS degree program is a massively serious step. Turning off the telly is not.
Given the emphasis that we will put on desktop programs having nothing to do with web pages and web applications, as well as its ability to run almost anywhere on any operating system, we have provisionally opted for Java, but this decision cannot be regarded as final. For one thing, we haven’t yet assessed what effect Oracle’s 2019 licensing changes will have on the suitability of Java for this series. C# appears to offer greater assurance of the free availability of not only the language itself but a solid complement of sophisticated development tools, although at the cost of lesser platform ubiquity.
Currently, the .NET environment for Linux and OS X appears to have limited capability for graphical applications. Whether this is entirely correct, we cannot say, nor can we assess whether this would be acceptable in our circumstances. It requires further consideration.
This quotation from the Monodevelop web-site may be instructive:
“MonoDevelop enables developers to quickly write desktop and web applications on Linux, Windows, and macOS. It also makes it easy for developers to port .NET applications created with Visual Studio to Linux and macOS, maintaining a single code base for all platforms.”
In any event, both Java and C# satisfy all of our selection criteria.
Web-site by Dreadnaught Steam Traction & Electric Broadcasting Works, Ltd