Skip to content

SeparabilityOfDomains

John Qase Hacker edited this page Aug 31, 2015 · 1 revision

In an earlier era, this was called "structured programming". Then, after that "modular programming". The idea is that you want your logic to be well-defined in separate functional domains rather than all blended into one big block of machine code, or one big function/procedure. So programming languages have keywords, AND they have mathematical operators which are kept in their own category separate from keywords, because math is conceptually separate (i.e. a separate domain) from logic flow. You get the picture?

Exercise: Imagine keywords being used for all math operations in your code rather than +/- symbols, you'd see that you can't tell what your code is doing at a glance anymore. The best you could hope for is to make them upper-case, so as to be distinct from your flow-logic keywords.

In C/C++, a function definition allows the specification of variable names with the expected type. This demonstrates separabiltiy of domains by specifying the list of values/variables to be expected (rather than an ambiguous stack say), while also giving an example of ClotheYourData, as your variables are not arbitrary things anymore, but clothed with a pre-specified type. Why does Python drop this? to create a greater domain. By not having pre-specified types, you gain the ability to make collections easily. So they've dropped ClotheYourData by not having hard typing, but gained a new, separate domain that opens up new possibilities of programming.

Another thought: the reason C++ can't replace C nor become the OOP language of choice, is because it breaks the separation of domains. The domain of C was super efficient code that matched the machine, C++ doesn't do that. But nor can it create the domain for OOP, because it's broken by the intentions of C, so it does neither well. It remains a good exploration, like Python did with Object unification, but failing to reach the goal.

In any event, this one is one of the most powerful ideas and also one of the toughest to crack. The idea is that you want non-overlapping domains of functionality. You want these to be distinct so that it's easy to figure out the code you want there and there's no question about it. So you don't merely want a proliferation of semi-arbitrary functions in a library, hence a companion rule: ZeroSuperfluousNames.

Clone this wiki locally