User:Antti Karttunen/Speculations/Search for meaning, don't assign it

This is my speculative mini-essay about the data types, programming language paradigms, ways of being creative, and the greatness of OEIS.

An instance of whining

What bugs me most with the object-oriented programming paradigm? While many people have already offered good bashing on it, I now realize other bad aspects of it, especially when one is doing solitary, experimental programming, not tied to any external requirements.

It is that OOP encourages very much top-down design, and assigning pre-established categories over the design. See also . It encourages programmers to program only the things they need, or actually, only those things that they think they need.

The other thing that annoys me: the data operated on is not free, but always imprisoned inside some object. And the paradigm expects that you should use only those methods that the object's class provides to access that data. Of course you can side-step this, if the object's internal data has not been made private, but this is against the grain of the whole philosophy of OOP: one should use only the methods provided by the class. In the essence, they assign a meaning to the data inside the object, and only that meaning which the original designer of the class had in his/her mind.

So, I can't get into the flow in the front of an OOP language.

Anti-dote to whining

Now, I firmly believe that one should not restrict one's view of mathematical objects like integers or such universal data-types as S-expressions to any pre-established meanings. If it is at all possible to manipulate elegant and timeless mathematical objects like them with our current digital hardware, then it should not be programming language's task to try to restrict in how many ways the programmer can employ and interpret them.

And that is why I like such programming languages as:

Machine/Assembly language: Everything is just a n-bit byte or word. The language doesn't enforce any types on those words, and depending on situation, the same n-bit chunk can be interpreted as a bit-vector, a signed or unsigned integer (which one it is interpreted as depends only the statement that is manipulating it), or even a machine instruction to be executed, allowing self-modifying code in Von Neumann architectures.

Forth: much like above, what comes to data types, but in addition, there are two stacks (called parameter stack and return stack), and the system doesn't really enforce any pre-established rules, how to use those stacks. So for example, they don't need to be "balanced" between calls from one subroutine to another, anything goes as long as the overall program works. I think this (in addition to threaded code and easy switching between the compiler and the interpreter) is the big idea of Forth.

APL/J: Everything is a scalar, vector or higher-dimensional array, out in the open, and when the language provides powerful functional primitives for their manipulation, the results can be spectacular. This is the big idea of APL.

Lisp/Scheme: The basic data-type is S-expression. Even the code itself is composed of S-expressions, so together with machine languages, it is one of the rare examples of homoiconic programming languages. This is the big idea of Lisp.

I think in all of the above examples, the expressive power of the language has been invested around its big idea, and if the idea is not still-born, it will soon unleash unforeseen consequences. Often these languages do not attract people who first put a question: "What is it useful for?" (top-down approach, engineering and economy), but instead, for ones who let the structure itself guide their thinking (bottom-up, research and art), and soon realize the inherent possibilities in it: emergent creativity from their own flow.

Of course I see that all this freedom must look just as a liability, not as an asset for the people who are used to external discipline and are better motivated by the external factors.

OEIS

I think the big idea of OEIS is that it does not assign any fixed primary meaning to its entries. Every entry is an instance of integer sequence, which is just a bare mathematical definition. However, this allows unambiguous indexing of the entries, totally independent of their "meanings". Thus, they are free to acquire whatever meanings and additional meanings over the years.

Now, consider what happens when we abandon even the preconception that positive integers are objects that count something, that counting is what natural numbers were meant for. Consider them instead as codes for some structures, which can be deciphered or "opened up", if the right algorithm for this magical operation is known or discovered.

For example, integers can be used to code for various sorts of trees, with various recursive schemes. Now see what whole worlds open up, when one diligently starts examining what one will find in such forests: Matula-Goebel encoding, Riffs and Rotes.

Left-brain and right-brain

Now see Michael Gazzaniga's lecture at the University of Edinburgh. What is interesting in this video is how the right brain so sovereignly detects abstract visual and geometric patterns, just as they are, raw, while the left brain is desperately trying to come up with "explanations", how the things can be justified. I think the real creativity in programming and mathematics (especially of that sort of "experimental mathematics" we do here) needs an ability to silence the left brain for a while, with its incessant demands of "what is it used and useful for?", so that the right brain can delve into the patterns themselves, with no accountability to the left brain.

See also

Tom Schouten, author of Staapl, (a Scheme to Forth metaprogramming system), wrote a reply to this page, comparing especially the differences in programming experience with Scheme versus Haskell. See http://zwizwa.be/-/math/20120825-085206

Authorship

The first version of this page was written by Antti Karttunen Aug 23, 2012.

Comments

If you are a registered user of OEIS, you can leave comments on Talk-page.