One Daily, One Topic - Oct, 26 to Nov, 8

The engineering team of ShuttleCloud has started a new habit during the daily meetings. The day before, a member of the team proposes a technical paper or article that should be reading for the rest of the team. The next daily, they talk over the technical paper. Analyzing what they've learned or if they have some doubts."One Daily, One Topic" is the group of posts where we'll share the topics that we talk during the last sprint. Besides, our Director of Engineering, Félix López, will comment why they've selected these papers and the link to find them.You can also follow the engineering team in Twitter at @ShuttleCloudEng. Here, we share the topic discussed, best practices, ground knowledge, articles, papers, books and much more every day.

Papers discussed during the last Sprint

Is Abstraction the Key to Computing?

By Jeff Kramer

Why have we selected this paper?Abstraction is key to Computer Science. Every software developer must understand why is useful and important. This paper explains what an abstraction is and why it's important, give good examples and it's possible to teach it. (F.López)

The Law of Leaky Abstraction

By Joel Spolsky

Why have we selected this paper?In this post we can learn about one the most used abstraction, TCP, and one important issue with abstractions, they're good to leave out of consideration complex subjects and to have a general and simpler interface to talk about common properties, features... but that doesn't mean we don't need to have a good knowledge of what it's happening under the hood. (F.López)

Design Patterns: Abstraction and Reuse of Object Oriented Design

By Erich Gamma, Richard Helm, Ralph Johnson & John Vlissides

Why have we selected this paper?One of the most common and useful abstraction for OOP are patterns. This paper is a classic in Computer Science from which you can learn what they are and their classification. (F.López)

Encapsulation vs Abstraction

StackOverflow thread

Why have we selected this paper?Some people confuse Abstraction and Encapsulation in this StackOverflow thread you can learn the differences. (F.López)

Out of the Tar Pit

By Ben Moseley & Peter Marks

Why have we selected this paper?This is a must-read paper for Computer Science. In this paper, Moseley and Marks talk complexity and how it's the root of the vast majority of problems in Software. In the paper, they explain clearly that complexity can be essential and accidental.Essential refers to the complexity inherent from the problem you're trying to solve and accidental refers to that complexity that comes from the solution you're applying, for example using OOP or the election of the language.They argue that the biggest source of complexity is the handling of the state and the burden it adds, as it's difficult to reason about the system when you have to track mentally all the possible combinations."The mental processes which are used to do this informal reasoning often revolve around a case-by-case mental simulation of behaviour: if this variable is in this state, then this will happen — which is correct — otherwise that will happen — which is also correct. As the number of states — and hence the number of possible scenarios that must be considered — grows, the effectiveness of this mental approach buckles almost as quickly as testing.One of the issues (that affects both testing and reasoning) is the exponential rate at which the number of possible states grows — for every single bit of state that we add we double the total number of possible states. Another issue — which is a particular problem for informal reasoning — is contamination."They continue with control Logic as another factor for complexity."When a programmer is forced (through use of a language with implicit control flow) to specify the control, he or she is being forced to specify an aspect of how the system should work rather than simply what is desired. Effectively they are being forced to over-specify the problem."They also compare different programming languages paradigms to see how they affect to the complexity of the system. They talk about OOP, Functional Programming and Logic Programming."The bottom line is that all forms of OOP rely on state (contained within objects) and, in general, all behaviour is affected by this state. As a result of this, OOP suffers directly from the problems associated with state described above, and as such we believe that it does not provide an adequate foundation for avoiding complexity.""Whilst OOP developed out of a desire to offer improved ways of managing and dealing with the classic stateful von-Neumann architecture, functional programming has its roots in the completely stateless lambda calculus of Church.""We would argue that — whatever the language being used — there are large benefits to be had from avoiding hidden, implicit, mutable state."They give recommendations on how to build systems that are easy to reason about and finally they propose a purely hypothetical approach to overcome all these problems: Functional Relational Programming. (F.López)