Computer scientists need a system of symbols to simplify and unify the expression of concepts, and thereby reduce the complexity of the development process. Programmers have been stuck using the same symbols as typists for 50 years, because, in the beginning, it was expensive to make a separate keyboard for programming and for typing, and it was impractical to re-code the software to work with a special keyboard, since the software systems that were created were hard-coded to make use of the common keyboard. As a result, people were reluctant to change keyboard layouts. As a result of that reluctance, entire generations of current programmers grew up using software and keyboards that were not designed for programming, all because our predecessors set a precedent, and this precedent has constricted our minds and prevented people from dreaming about better alternatives. Most people do not even know how the keyboard works with the operating system, so they do not question it.
Unlike the computer science discipline, the math and language disciplines, as well as many other scientific disciplines, including chemistry, created their own systems of symbols to express concepts. It is ironic, then, that the programming discipline, which uses languages extensively, has not once introduced a new symbol to simplify the concepts of programming.
Strictly speaking, this is not true. The functional programming paradigm is strictly founded on the lambda calculus. The lambda calculus, a mathematical formalism of computation, has introduced the λ (lambda) to symbolize a function in the abstract. While the mathematical field uses this symbol, the programming languages that implement the lambda calculus, such as Scheme Lisp, Common Lisp, and Clojure, do not. While the Racket programming ecosystem (based on Scheme) has made it possible to do this, it is not convenient to click on a menu and select a menu item to insert a character, and this example is but one lone exception.
λ
The keyboard has dominated the programming scene since its inception, but it was designed primarily for office workers and typists, not mathematicians or any other specialized domain of knowledge that uses its own set of symbols.
This symbolic void in computer science has encouraged language designers to re-use symbols from the standard typist set, and this simply doesn’t work. The symbols already have many meanings associated with them, and these meanings are useful as is, so overriding them to mean something else results in a slew of arbitrary decisions about which symbol is more intuitive for the concept one is trying to express, and a number of work-arounds when the programmer wants to add these symbols under their original meaning, or literally, in a string.
The lack of transferrable knowledge between programming languages is due to the lack of accessible symbols on our input devices, and a lack of formal symbols within the profession. I see this as a significant pain point for programming, and I believe this is a problem that could be addressed, but hasn’t.