Illogical engineers

Illogical Engineers
“Those who cannot remember the past are
condemned to repeat it.”

“Software Engineering”
7th-11th Oct 1968

“A software system can best be designed if
the testing is interlaced with the designing
instead of being used after the design.”

“The good systems that are presently working
were written by small groups. More than
twenty programmers working on a project is
usually disastrous.”

"I bought my boss two
copies of The
Mythical Man Month
so that he could read
it twice as fast."

“The reason that small groups have succeeded (...) is
that there is a need for a certain structure of
communication, and a structure of decision making in
the development of software. This succeeds with small
groups, because it can all be done intuitively by one
person serving as most of the network. For large groups
to succeed, we (...) have to face organizational
structure for communications and decisions.”

How to design successful software?

1. Flowchart until you think you understand the problem.

2. Write code until you realize that you don’t.

3. Go back and re-do the flowchart.

3. Go back and re-do the flowchart.
4. Write some more code and iterate to what you feel is the
correct solution.

“Design and implementation proceeded in a
number of stages. Each stage was typified by
a period of intellectual activity followed by a
period of program reconstruction”

“Each stage produced a usable product and
the period between the end of one stage and
the start of the next provided the operational
experience upon which the next design was
based.”

“In general the products of successive stages
approached the final design requirement;
each stage included more facilities than the
last.”

“Selig’s picture requires a feedback loop, for
monitoring of the system. One must collect
data on system performance, for use in future
improvements.”

“I believe in this concept, but the implementation described above is
risky and invites failure. The testing phase which occurs at the end of
the development cycle is the first event for which timing, storage,
input/output transfers, etc., are experienced as distinguished from
analyzed. (...) then invariably a major redesign is required. A simple (...)
redo of some isolated code will not fix these kinds of difficulties. The
required design changes are likely to be so disruptive that the software
requirements upon which the design is based and which provides the
rationale for everything are violated. Either the requirements must be
modified, or a substantial change in the design is required. In effect the
development process has returned to the origin and one can expect up
to a lO0% overrun in schedule and/or costs.”

“Royce's 1970 paper is generally considered
to be the paper which defined the stagewise
"waterfall" model of the software process. But
it is surprising to see that (...) he already
incorporates prototyping as an essential step
compatible with the waterfall model.”

“The earlier Benington and Hosier papers had
good approximations to the waterfall model,
and that Royce's paper”

"Pitfalls and Safeguards in Real-Time Digital
Systems with Emphasis on Programming"
W.A. Hosier, 1961

"Production of Large Computer Programs”
H.D. Benington, June 1956.

http://gildingandcompany.co.uk/pegasus-computer-from-1956-the-passage-of-time/

“As soon as specifications a system program
are definitive, contractors should begin to
consider how they will verify the program's
meeting of the specifications.“

“"A requirements spec was generated. It has a
number of untestable requirements, with
phrases like 'appropriate response' all too
common. The design review took weeks, yet
still retained the untestable requirements."

“Software Process Management: Lessons
Learned From History”
Barry W. Boehm, 1987

“There are 2 hard problems in computer
science:

science: cache invalidation

science: cache invalidation and naming things

science: cache invalidation, naming things,
and off-by-1 errors.

Microservices
What is a microservice?

Microservices
What is a difference between Microservices and SOA?

“When we've talked about microservices a common
question is whether this is just Service Oriented
Architecture (SOA) that we saw a decade ago. (...) The
problem, however, is that SOA means too many different
things, (...) the fact that SOA means such different things
means it's valuable to have a term that more crisply defines
this architectural style.” -- Martin Fowler

“Alexander Pasik, a former analyst at Gartner, coined
the term SOA. (...) Pasik was driven to create term SOA
because “client/server” had lost its classical meaning.”
from “SOA in Practice: The Art of Distributed System Design” by Nicolai M. Josuttis

“The common notion that Gartner Group
invented SOA is simply absurd. (...) the
underlying approach to distributed computing
was invented at least 15 years earlier.”

Are the problems being
addressed and solved?

What does it mean to be a software engineer?

“The phrase ‘software engineering’ was
deliberately chosen as being provocative, in
implying the need for software manufacture
to be based on the types of theoretical
foundations and practical disciplines, that are
traditional in the established branches of
engineering.”

Towards engineering!
● Type System matters

● Functional Programming is our lord and saviour

○ statically typed
○ dependently typed
○ total

○ statically typed
○ dependently typed
○ total
● Recognising Computer Science roots in math is essential to
write correct software

if (a = 10) {
...
} else {
// will never be executed, variable a is changed!
}
The “beauty” of C++
Compiles!
And that’s a
bad thing

val a: Int = 10
if(a == “10”) “ten” else “sth else”

val a: Int = 10
“sth else”

trait Eq[A] {
def ===(a1: A)(a2: A): Boolean
}
val a: Int = 10
if(a == “10”) “ten” else “sth else”

trait Eq[A] {
}
val a: Int = 10
if(a === “10”) “ten” else “sth else”

trait Eq[A] {
}
val a: Int = 10
Doesn’t
compile

trait Eq[A] {
}
val a: Int = 10
Doesn’t
compile
and that’s a goodthing!

/** Concatenate two maps. Keys from both maps must be
* included. If keys collide, add values together. */
def concat(
map1: Map[String, Int],
map2: Map[String, Int]
): Map[String, Int] = ???

def concat(
map1: Map[String, Option[(Int, Option[FinancialReport])],
map2: Map[String, Option[(Int, Option[FinancialReport])]
): Map[String, Option[(Int, Option[FinancialReport])] = ???

trait Semigroup[A] {
def |+|(a1: A, a2: A): A
}

def |+|(a1: A, a2: A): A
}
trait Semigroup {
def pairS[A, B]: Semigroup[(A, B)] = ???
}

def |+|(a1: A, a2: A): A
}
trait Semigroup {
def pairS[A:Semigroup, B:Semigroup]: Semigroup[(A, B)] = ...
}

def |+|(a1: A, a2: A): A
}
trait Semigroup {
def optionS[A:Semigroup]: Semigroup[Option[A]] = ...
}

def |+|(a1: A, a2: A): A
}
trait Semigroup {
def optionS[A:Semigroup]: Semigroup[Option[A]] = ...
def mapS[A, B:Semigroup]: Semigroup[Map[A,B]] = ...
}

def concat(
m1: Map[String, Option[(Int, Option[FinancialReport])],
m2: Map[String, Option[(Int, Option[FinancialReport])]
): Map[String, Option[(Int, Option[FinancialReport])] = ???

def concat(
m1: Map[String, Option[(Int, Option[FinancialReport])],
m2: Map[String, Option[(Int, Option[FinancialReport])]
): Map[String, Option[(Int, Option[FinancialReport])] = m1 |+| m2

Can I prove correctness of
my program?

Can code be generated
from types?

Can I prove that my
program will terminate?

Curry–Howard
correspondence
Propositions as types, proofs as programs.

The Curry–Howard correspondence is the
observation that two families of seemingly
unrelated formalisms—namely, the proof
systems on one hand, and the models of
computation on the other—are in fact the
same kind of mathematical objects.

Curry–Howard correspondence
Proposition ≡ Type
Proof ≡ Program

Propositional Logic
∧ AND
∨ OR
→ IMPLIES
¬ NOT

Predicate Logic
∧ AND
∨ OR
→ IMPLIES
¬ NOT
∀ FOR ALL
∃ EXISTS

Constructive Logic (Intuitionistic Logic)
In mathematics, a constructive
proof is a method of proof that
demonstrates the existence of
a mathematical object by
creating or providing a method
for creating the object.

P ∨ ¬P
P → ¬¬P

Prove that:
P ∧ (Q ∨ R) → (P ∧ Q) ∨ (P ∧ R)

Prove that:
P ∧ (Q ∨ R) → (P ∧ Q) ∨ (P ∧ R)
X ∧ Y (X, Y)

Prove that:
P ∧ (Q ∨ R) → (P ∧ Q) ∨ (P ∧ R)
X ∧ Y (X, Y)
X ∨ Y X + Y

Prove that:
P ∧ (Q ∨ R) → (P ∧ Q) ∨ (P ∧ R)
X ∧ Y (X, Y)
X ∨ Y Either[X, Y]

Prove that:
P ∧ (Q ∨ R) → (P ∧ Q) ∨ (P ∧ R)
X ∧ Y (X, Y)
X ∨ Y Either[X, Y]
X → Y X => Y

Prove that:
P ∧ (Q ∨ R) → (P ∧ Q) ∨ (P ∧ R)
def proof[P, Q, R]: (P, Either[Q, R]) => Either[(P, Q), (P, R)] = ???

Prove that:
P ∧ (Q ∨ R) → (P ∧ Q) ∨ (P ∧ R)
def proof[P, Q, R]: (P, Either[Q, R]) => Either[(P, Q), (P, R)] =
(input: (P, Either[Q, R])) => input match {
case (p, Left(q)) => Left((p, q))
case (p, Right(r)) => Right((p, r))
}

So why can’t we prove?
P ∨ ¬P

P ∨ ¬P
¬P P => “False”

P ∨ ¬P
¬P P => Nothing

P ∨ ¬P
¬P P => Nothing
def proof[P]: Either[P, P => Nothing] = ???

What’s the point of all this?

Computer Science is my
rooted in Math

“We must know! We will know!”
While the roots of formalised logic go back to
Aristotle, the end of the 19th and early 20th
centuries saw the development of modern logic and
formalised mathematics.

Question: could you derive all
mathematical truth using axioms and
inference rules of formal logic, in principle
opening up the process to automatisation?

In 1929, Mojżesz Presburger showed that the theory
of natural numbers with addition is decidable and
gave an algorithm that could determine if a given
sentence in the language was true or false.

“Bertrand Russell and Alfred Whitehead set out to
do something amazing.”
“Starting with just basic axioms of set theory, tried
to build complete edifice of mathematics as one
system, published as Principia Mathematica.”

Kurt Gödel
“On Formally Undecidable Propositions of
Principia Mathematica and Related
Systems” (1931)
Incompleteness theorem

Kurt Gödel proved that for any system which
is at least as powerful to represent simple
arithmetic: either your system is incomplete
(i.e. cannot prove its own axioms) or it is
inconsistent (i.e. can derive a contradiction)

def willProveAnything[A]: A = ???

def willProveAnything[A]: A = null

def willProveAnything[A]: A = throw RuntimeException(“ha!”)

def willProveAnything[A]: A = willProveAnything

Automated Theorem Prover
It follows that an automated theorem prover will fail to
terminate while searching for a proof precisely when the
statement being investigated is undecidable in the theory being
used. Despite this theoretical limit, in practice, theorem provers
can solve many hard problems, even in models that are not fully
described by any first order theory.

Chymyst/curryhoward
https://github.com/Chymyst/curryhoward

The End
Pawel Szulc
Pyrofex
@rabbitonweb
http://rabbitonweb.com
paul.szulc@gmail.com

Illogical engineers

More Related Content

Similar to Illogical engineers

More from Pawel Szulc

Recently uploaded

Illogical engineers