“We have to plan for the rot to overcome it.” How can we overcome rot? What plan can we have?
Surprisingly, making short methods and functions helps a lot. When modifying existing code, I generally prefer rewriting short functions to modifying them.
Small namespaces are better than large ones. How small can we go? If smaller is better, is one line better than two lines? Is one function call better than two? And at what point are we creating complexity with excessively many small functions?
Bob Martin’s Single Responsibility Principle says functions should do one thing. If a function solely calls another function, aside from re-arranging the arguments, it adds nothing, other than the rename. Programming is adding all those small changes to build large fantastic structures: a true statement whether referring to small functions or machine code.
John McCarthy named Lisp in the 1950s and built a programming language from 9 core operators. Individually the operators did almost nothing and in a visual programming language as I’m imagining, a few of them disappear.
One problem I’m having with my visual programming language is names. As I wrote last week, names are comments, they are superfluous to the program at hand. We could draw a line between the outputs of one function and the inputs of another to represent the data stored. We can thus dispense with variable names and remove one source of rot.
Functions, conversely, need names. To date, I haven’t found a way to choose between functions except by name. The compiler and the run time system do not need names except to implement reflection.
Reflection gives the programmer convenience to allow a runtime choice of classes and functions. We can create other forms for runtime choice. I did it plenty when programming in C.
And that’s where I’m stuck in my visual programming language. How would the user interface provide functions for the programmer to use whether written by me or herself? How could she choose a function without names?