Concepts of Higher Programming Languages Chapter 1: Introduction Jonathan Thaler Department of Computer Science 1 / 39
Introduction The limits of my language are the limits of my world. – Ludwig Wittgenstein Tractatus Logico-Philosophicus 5.6, 1918 2 / 39
Introduction Write down all languages, which you have written programs in. 3 / 39
The Blub Paradoxon As long as our hypothetical Blub programmers are looking down the power continuum, they knowsthey are looking down. Languages less powerful than Blub are obviously less powerful, because they’re missing some feature they are used to. But when our hypothetical Blub programmers look in the other direction, up the power continuum, they don’t realize they are looking up. What they see are merely weird languages. They probably consider them about equivalent in power to Blub, but with all this other hairy stuff thrown in as well. Blub is good enough for them, because they think in Blub. Paul Graham, Beating The Averages 4 / 39
A few opinions... Alan Kay I invented the term object-oriented, and I can tell you I did not have C++ in mind. 5 / 39
A few opinions... Joe Armstrong Objects bind functions and data structures together in indivisible units. I think this is a fundamental error since functions and data structures belong in totally different worlds. The problem with object-oriented languages is they’ve got all this implicit environment that they carry around with them. You wanted a banana but what you got was a gorilla holding the banana and the entire jungle. 6 / 39
A few opinions... James Gosling If you could do Java over again, what would you change? I’d leave out classes. 7 / 39
A few opinions... Edsger Dijkstra Object-oriented programs are offered as alternatives to correct ones. 8 / 39
A few opinions... Paul Graham Object-oriented programming offers a sustainable way to write spaghetti code. 9 / 39
A few opinions... Rich Hickey I think that large objected-oriented programs struggle with increasing complexity as you build this large object graph of mutable objects. You know, trying to understand and keep in your mind what will happen when you call a method and what will the side effects be. 10 / 39
Question Is there something wrong with OOP? 11 / 39
Historical context Kristen Nygaard conceived objects in Simula 67 , the first OO language used for programming (event) simulations . Alan Kay pioneered OOP in the early 1970s in Smalltalk a language which pioneered Graphical User Interfaces . OO became popular in mid 1980s was considered to be a silver bullet . By the mid 90s OOP has taken the industry by storm. At first, OOP was not properly understood, industry needed to develop best practices (patterns) . Zenith of OOP was ∼ 1995 to ∼ 2005 12 / 39
Historical context From 2005 onwards Zenith reaction against OOP : A movement away from static typing and toward dynamic typing . A movement away from compiled languages and toward script languages . A movement away from heavy-weight frameworks and toward lighter frameworks . A movement away from OOP and toward the functional paradigm . 13 / 39
Unique Strengths of OOP? 14 / 39
What is wrong with OOP: Polymorphism Polymorphism Referring to the same object in different contexts. Not unique to OOP, exists in non-OO languages as well e.g. Haskell Type Classes. Often confused with Inheritance (where it is mixed up, things get really messy). Single main use case for polymorphism in OO are interfaces . The problem of instantiation arises, which is not a subtle one. 15 / 39
What is wrong with OOP: Abstraction Abstraction Hiding unnecessary details from the programmer. Not unique to OOP, exists in non-OO languages as well in a stronger form. Disconnection between source code and runtime entities makes it problematic. Control / data flow becomes extremely difficult to follow, therefore one ends up programming in the debugger (that is what Smalltalk developers actually do). OO has tendency to overabstract , leading to unmaintainable and unmanagable and incomprehensible bloated code and frameworks (e.g. Java EE) Design patterns are a form of complexity . There is a conception that patterns in OO are just workarounds of deficits in the host language: if you find yourself frequently writing a bunch of boilerplate design pattern code to deal with a ”recurring design problem” it’s a sign that your language is fundamentally broken . 16 / 39
What is wrong with OOP 17 / 39
What is wrong with OOP: Encapsulation Encapsulation Placing both data and operations within a class. Is in fact glorified global state . Hides mutation and sharing of data. Makes composition difficult . Makes concurrency extremely painful (impossible). Need to know about implementation details and about implicit dependencies to re-use it. Forces to deal with i ssues of coupling and cohesion . This results in tremendous effort and ceremony to get things into manageable shapes using the GRASP and GoF patterns ultimately requiring a HUGE effort and brainpower to think about where to put which operation (data). 18 / 39
What is wrong with OOP 19 / 39
What is wrong with OOP: Inheritance Inheritance Aquiring properties and behaviour from another class. Should always be avoided in favour of composition and delegation. Fixes structure of application in advance including the connections. If parent class is changed, it might break child classes . Ultimately it violates encapsulation (Inheritance in OOP is primarily a mechanism for reusing source code as opposed to a mechanism for reusing binary objects). The agreed convention about using Inheritance in OO is ”don’t do it” . 20 / 39
What is wrong with OOP 21 / 39
What is wrong with OOP 22 / 39
Unique Strengths of OOP? Compared to other languages (lisps, functional languages, etc) 1.) OOP languages have no unique strengths . Abstraction, Poloymorphism, Encapsulation exists in other languages in stronger and better versions - Inheritance is outright dangerous . 2.) OOP languages inflict a heavy burden of unneeded complexity such as patterns, cohesion, coupling, instantiation, dependency injection, ORMs,... 23 / 39
What is wrong with OOP Good programmers write good code , independent of the paradigm , bad programmers write bad code. However with OOP it is easier to write terrible code than say with Haskell because the FP paradigm constrains bad programmers from making crazy things which in OOP all boil down to unmaintainable graphs of shared mutable objects where data dependencies are in a way that they are no longer comprehensible and everything can happen. 24 / 39
Why is it used in the industry? Political : OO was a hype , every company had to do OOP. Financial : OOP created a new software industry with an abundance of new jobs, training, consulting,... Job protection : separate the pros from outsiders It was thought to be easy to learn and make code reuse easier 1 It reached a critical mass . Therefore, universities teach students . Now the industry cannot get out of it easily , therefore they have to stick to it, therefore they need OOP people, therefore universities train students in OOP, therefore the industry will find mostly OOP people 1 OOP promised or marketed itself as being the foundation for outsourcing coding to cheap ”3rd” world countries. Some ”genius” architect developed the specification in UML and other (semi-)formal languages, sends this to cheap labor force in India who then simply implements it. 25 / 39
The real danger... Industry suffers from the managerial dogma that for the sake of stability and continuity, the company should be independent of the competence of individual employees . Hence industry rejects any methodological proposal that can be viewed as making intellectual demands on their workers . The moral of this sad part of the story is that as long as computer science is not allowed to save the computer industry, we had better see to it that the computer industry does not kill computing science. 26 / 39
What is wrong with OOP What are alternatives? 27 / 39
Alternatives Lisp 28 / 39
Alternatives Erlang 29 / 39
Alternatives Scala 30 / 39
Alternatives Rust 31 / 39
Alternatives Haskell 32 / 39
Why look at Haskell? Understand that there is more than OOP . Know more powerful abstractions and concepts . Think more abstract about your program. Thinking in types . Easier parallelism and concurrency. Programming is all about composition . Functional concepts popular in recent years : Immutable Objects (ever since the beginning...) Generics (Java 5) Lambdas, Functional Interfaces, Method References, Streams, Optionals (Java 8) JavaScript, Python,... all have functional concepts. This will make you a better programmer and software engineer! 33 / 39
Content Pure Functional Programming Concepts: Immutable Data, Recursion, Pattern Matching, Higher-Order Functions, Algebraic Data Types Type Classes Random Numbers Monads & Monad Transformers IO and Concurrency Property-Based Testing Dependent Types Real-World Haskell 34 / 39
Recommend
More recommend
