The Mythical Genius

Theories and observations of an ENTP who loves code

[mythofthegeniuscoder]

I like diagrams. Here’s a follow up visual for my post on Inward and Outward facing programs!

[mythofthegeniuscoder]

Some functional vs imperative doodles. I'm showing data flow in each paradigm with an otherwise identical algorithm. The idea was to show structural analogs in data between the two paradigms, but there are more diagrams necessary to demonstrate all the analogs.

[mythofthegeniuscoder]

Inward and Outward Facing

Let me start by saying that these aren’t existing terms. I’m defining them for myself: An inward facing program, abstractly speaking, is one where execution data structures are predictable and generally constant in structure, while operational data structures vary dramatically to accommodate a range of operations. This is in contrast to an outward facing program.

An outward facing program, abstractly speaking, is one where the execution data structures vary dramatically to accommodate the range of operations, while operational data structures are relatively predictable and constant in structure.

In practice, this means that for an inward facing program, the heap is a vortex of chaos laden with an incomprehensible graph of objects and references, while the stack is simple and shallow in most cases. An outward facing program is just the opposite. The heap is small and only has a few data structures that don’t tend to change too much, but the stack grows and shrinks wildly and messily and there’s all kinds of data stored in the stack frames. Some of you familiar with the contrast between imperative and functional languages might be seeing some parallels, just as I have. Generally, functional languages like to be outward facing while imperative languages tend to be inward facing. That’s not to say that the terms map perfectly - there are other factors. For example, as functional languages go, JavaScript programs can often be very inward facing (depending on how object-happy the programmer is) and Ruby can be pretty outward facing for an imperative language (especially on Rails, where it’s roughly modeled after JavaScript).

A couple of key features of inward facing programs:         they tend to create a lot of memory leaks and require a lot of garbage collection magic (just look at Java)         they usually have trouble being concurrent because of race conditions         they tend to rely heavily on mutable data         they take longer to write than their outward facing counterparts         they tend to be much better for servers and mainframes (where large, mutable, common data structures can benefit from caches and other assistant data structures)

And outward facing programs:         they tend to be great for client-side web applications         they tend to be lightweight         they tend to be the design choice of web crawlers and viruses         they are highly expressive         they can be hard to optimize         they can easily overflow the stack and jam a program         they can be very hard to debug         outward facing languages used by inward facing programmers tend to generate infinite streams of immutable data that has been replaced by “modified” copies. This is not inherent to outward facing programs but rather to an industry moving from inward to outward (and, incidentally, imperative to functional as well). See more next:

Why do these paradigms exist? What occurs to me is that computer memory and computer speed tend not to improve in lock step but rather 180 degrees out of phase from one another. So just after processing speed increases, it behooves the programmer to use lots of processor intensive programs that aren’t memory intensive. Then, memory makes a leap of its own that surpasses that of processing speed. At this point, programmers start to write programs that use lots of memory while sparing the processor. These shifts were much more frequent in the early days of computer hardware. The paradigm shifts of today are centered around ever increasing use of online facilities and ever smaller computers (from desktops to laptops to tablets to phones to watches and eventually even clothes). The race to the Internet has brought outward facing languages and programs to the forefront of modern programming, with, in my opinion, JavaScript at the helm. Hope this was interesting and informative! Please ask if you have any questions, or just if you think I’m totally off base here.

[mythofthegeniuscoder]

Hello World!

Hi everyone! First, the title of this blog is a reference to the Myth of the Genius Programmer.

I am an ENTP (one of the 16 types specified by the Myers Briggs Type Indicator). If you aren’t familiar with what this entails, you can find out more here or you can check out my Myers Briggs blog for my theories!

Speaking of Myers Briggs theory, you will see quite a few Myers Briggs references in this blog. I’ll do my best to explain them without the supposition of Myers Briggs knowledge on the part of the reader, but there may be times that isn’t practical.

My early history with languages is as follows: 11 years of age - learning batch files 13 years of age - learning robot code in LabVIEW 14 years of age - learning robot code in C 15 years of age - learning Java (I consider this my first language) 16 years of age - learning Brainfuck 17 years of age - learning Lisp (Clojure, then Scheme (Racket)) I consider 17 to be the end of the formative years, since after this comes more professional, focused programming effort. It is necessary for a college student to become fluent in languages he may not enjoy at all, including C/++, Python, and Matlab. To be clear, yes, I hate all three(four) of these languages. I don’t want to be arrogant, but I do want to be clear. Programming is very natural for me. It is the only activity that I have ever found to be able to tap all of the mental faculties that I hold dear. It perfectly enhances and challenges my mind. Consequently, I know that I have significant aptitude for programming. I have always learned quickly in this field and I have so far found it easy to surpass my peers both in understanding, throughput, and efficiency. The one aspect of my code that rarely surpasses my peers is readability. I know this is not an uncommon observation for skillful coders. When I was younger, my dream was to be one of the genius coders of pop culture. I wanted to have the brilliant idea no one else thought of, like Zuckerberg in The Social Network. I wanted to rethink “possible,” like Richard in Silicon Valley. I wanted to impress everyone with my esoteric brilliance. Unfortunately, as I found out later, there is no such thing. No worthy piece of code can be written by a single individual - even if an individual wrote a worthy piece of code on his/her own, it wouldn’t be praiseworthy. So much of real software is tedious: thousands of lines of intricate, non-genius-y code that has to work well despite being far from novel or even remotely interesting. And for the most part, we coders can stomach a sprinkling of tedium. In fact, it can be relaxing to the mind and soothing to our jittery fingertips. But for one person to singlehandedly manage all of the tedious loops and procedures is, at the very best, cringeworthy. And that’s me! Welcome to my blog. Hope you enjoy!