{"id":4877,"date":"2018-11-06T19:50:39","date_gmt":"2018-11-06T18:50:39","guid":{"rendered":"https:\/\/monodes.com\/predaelli\/?p=4877"},"modified":"2018-11-06T17:06:28","modified_gmt":"2018-11-06T16:06:28","slug":"the-forgotten-history-of-oop","status":"publish","type":"post","link":"https:\/\/monodes.com\/predaelli\/2018\/11\/06\/the-forgotten-history-of-oop\/","title":{"rendered":"The Forgotten History of OOP"},"content":{"rendered":"

\"\"\/<\/a>The Forgotten History of OOP \u2013 JavaScript Scene \u2013 Medium<\/a><\/em><\/h1>\n

<\/p>\n

Eric Elliott<\/a><\/p>\n

\n
\n
\n
\n
\n
Make some magic. #JavaScript<\/a><\/div>\n
\n
\n
\n
\n

The Forgotten History of OOP<\/h1>\n<\/div>\n
\n
\n
\n
<\/div>\n
<\/div>\n<\/div>\n<\/figure>\n<\/div>\n<\/div>\n<\/section>\n<\/div>\n
\n
\n
\n
\n
\n
<\/div>\n<\/div>
Smoke Art Cubes to Smoke\u200a\u2014\u200aMattysFlicks\u200a\u2014\u200a(CC BY 2.0)<\/figcaption><\/figure>\n<\/div>\n
\n

Note: This is part of the \u201cComposing Software\u201d series on learning functional programming and compositional software techniques in JavaScript ES6+ from the ground up. Stay tuned. There\u2019s a lot more of this to come!
\n< Previous<\/a> | << Start over at Part 1<\/a><\/p><\/blockquote>\n

Most of the programming paradigms we use today were first explored mathematically in the 1930s with lambda calculus and the Turing machine, which are alternative formulations of universal computation (formalized systems which can perform general computation). The Church Turing Thesis showed that lambda calculus and Turing machines are functionally equivalent\u200a\u2014\u200athat anything that can be computed using a Turing machine can be computed using lambda calculus, and vice versa.<\/p>\n

Note: There is a common misconception that Turing machines can compute anything computable. There are classes of problems (e.g., the halting problem<\/a>) that can be computable for some cases, but are not generally computable for all cases using Turing machines. When I use the word \u201ccomputable\u201d in this text, I mean \u201ccomputable by a Turing machine\u201d.<\/p><\/blockquote>\n

Lambda calculus represents a top-down, function application approach to computation, while the ticker tape\/register machine formulation of the Turing machine represents a bottom-up, imperative (step-by-step) approach to computation.<\/p>\n

Low level languages like machine code and assembly appeared in the 1940s, and by the end of the 1950s, the first popular programming high-level languages implementing both functional and imperative approaches appeared. Lisp dialects are still in common use today, including Clojure, Scheme, AutoLISP, etc. FORTRAN and COBOL both appeared in the 1950s and are examples of imperative high-level languages still in use today, though C-family languages have replaced both COBOL and FORTRAN for most applications.<\/p>\n

Both imperative programming and functional programming have their roots in the formal mathematics of computation, and predate digital computers. Object Oriented Programming (OOP) came later, and has its roots in the structured programming revolution that arrived in the 1960s and 1970s.<\/p>\n

The first objects I know of were used by Ivan Sutherland in his seminal Sketchpad application, created between 1961 and 1962 and published in his Sketchpad Thesis<\/a> in 1963. The objects represented graphical glyphs displayed on an oscilloscope screen (possibly the first use of a graphical computer monitor), and featured inheritance via dynamic delegates, which Ivan Sutherland called \u201cmasters\u201d in his thesis. Any object could become a \u201cmaster\u201d, and additional instances of the objects were called \u201coccurrences\u201d. This makes Sketchpad the first known programming language that implemented prototypal inheritance.<\/p>\n

The first programming language widely recognized as \u201cobject oriented\u201d was Simula, specified in 1965. Like Sketchpad, Simula featured objects, but also featured classes, class inheritance, subclasses, and virtual methods.<\/p>\n

Note: A virtual method<\/strong> is a method defined on a class which is designed to be overridden by subclasses. Virtual methods allow a program to call methods that may not exist at the moment the code is compiled by employing dynamic dispatch to determine what concrete method to invoke at runtime. JavaScript features dynamic types and uses the delegation chain to determine which methods to invoke, so does not need to expose the concept of virtual methods to programmers. Put another way, all methods in JavaScript use runtime method dispatch, so methods in JavaScript don\u2019t need to be declared \u201cvirtual\u201d to support the feature.<\/p><\/blockquote>\n

What the Father of Object-Oriented Programming Wants You to Know About OOP<\/h3>\n

\u201cI made up the term \u2018object-oriented\u2019, and I can tell you I didn\u2019t have C++ in mind.\u201d ~ Alan Kay, OOPSLA \u201897<\/em><\/p><\/blockquote>\n

Alan Kay coined the term \u201cObject Oriented Programming\u201d in reference to the Smalltalk programming language (1972), which was developed by Alan Kay, Dan Ingalls, and others at Xerox Park for a laptop project called \u201cDynabook\u201d. Smalltalk was more object-oriented than Simula\u200a\u2014\u200aeverything in Smalltalk is an object, including classes, integers, and blocks (closures). The original Smalltalk-72 did not feature subclassing. That was introduced in Smalltalk-76.<\/p>\n

While Smalltalk supported classes and eventually subclassing, Smalltalk was not about classes or subclassing things. It was a functional language inspired as much by Lisp as it was by Simula. Alan Kay considers classes as a code reuse mechanism to be a mistake, and the industry\u2019s focus on subclassing to be a distraction from the true benefits of object oriented programming.<\/p>\n

Because they share so many features in common, I like to say that JavaScript is Smalltalk\u2019s revenge on the world\u2019s misunderstanding of OOP. Both Smalltalk and JavaScript support:<\/p>\n