Diese Präsentation wurde erfolgreich gemeldet.
Wir verwenden Ihre LinkedIn Profilangaben und Informationen zu Ihren Aktivitäten, um Anzeigen zu personalisieren und Ihnen relevantere Inhalte anzuzeigen. Sie können Ihre Anzeigeneinstellungen jederzeit ändern.

Illogical engineers

279 Aufrufe

Veröffentlicht am

"Illogical engineers" as presented at LambdAle 2018 in London

Veröffentlicht in: Technologie
  • Als Erste(r) kommentieren

  • Gehören Sie zu den Ersten, denen das gefällt!

Illogical engineers

  1. 1. Illogical Engineers “Those who cannot remember the past are condemned to repeat it.”
  2. 2. Software engineers
  3. 3. “Software Engineering” 7th-11th Oct 1968
  4. 4. 50 years ago
  5. 5. 50years ago
  6. 6. “A software system can best be designed if the testing is interlaced with the designing instead of being used after the design.”
  7. 7. “The good systems that are presently working were written by small groups. More than twenty programmers working on a project is usually disastrous.”
  8. 8. "I bought my boss two copies of The Mythical Man Month so that he could read it twice as fast."
  9. 9. “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.”
  10. 10. How to design successful software?
  11. 11. 1. Flowchart until you think you understand the problem.
  12. 12. 1. Flowchart until you think you understand the problem. 2. Write code until you realize that you don’t.
  13. 13. 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.
  14. 14. 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. 4. Write some more code and iterate to what you feel is the correct solution.
  15. 15. How to design successful software?
  16. 16. “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”
  17. 17. “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.”
  18. 18. “In general the products of successive stages approached the final design requirement; each stage included more facilities than the last.”
  19. 19. “Selig’s picture requires a feedback loop, for monitoring of the system. One must collect data on system performance, for use in future improvements.”
  20. 20. Speaking about waterfall...
  21. 21. “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.”
  22. 22. “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.”
  23. 23. “The earlier Benington and Hosier papers had good approximations to the waterfall model, and that Royce's paper”
  24. 24. "Pitfalls and Safeguards in Real-Time Digital Systems with Emphasis on Programming" W.A. Hosier, 1961
  25. 25. "Production of Large Computer Programs” H.D. Benington, June 1956.
  26. 26. http://gildingandcompany.co.uk/pegasus-computer-from-1956-the-passage-of-time/
  27. 27. “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.“
  28. 28. “"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."
  29. 29. “Software Process Management: Lessons Learned From History” Barry W. Boehm, 1987
  30. 30. “There are 2 hard problems in computer science:
  31. 31. “There are 2 hard problems in computer science: cache invalidation
  32. 32. “There are 2 hard problems in computer science: cache invalidation and naming things
  33. 33. “There are 2 hard problems in computer science: cache invalidation, naming things, and off-by-1 errors.
  34. 34. “There are 2 hard problems in computer science: cache invalidation, naming things, and off-by-1 errors.
  35. 35. Microservices
  36. 36. Microservices What is a microservice?
  37. 37. Microservices What is a difference between Microservices and SOA?
  38. 38. “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
  39. 39. “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
  40. 40. “The common notion that Gartner Group invented SOA is simply absurd. (...) the underlying approach to distributed computing was invented at least 15 years earlier.”
  41. 41. Are the problems being addressed and solved?
  42. 42. Software Engineer?
  43. 43. Software Craftsman
  44. 44. What does it mean to be a software engineer?
  45. 45. “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.”
  46. 46. “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.”
  47. 47. Towards engineering!
  48. 48. Towards engineering! ● Type System matters
  49. 49. Towards engineering! ● Type System matters ● Functional Programming is our lord and saviour
  50. 50. Towards engineering! ● Type System matters ● Functional Programming is our lord and saviour ○ statically typed ○ dependently typed ○ total
  51. 51. Towards engineering! ● Type System matters ● Functional Programming is our lord and saviour ○ statically typed ○ dependently typed ○ total ● Recognising Computer Science roots in math is essential to write correct software
  52. 52. if (a = 10) { ... } else { // will never be executed, variable a is changed! } The “beauty” of C++ Compiles! And that’s a bad thing
  53. 53. val a: Int = 10 if(a == “10”) “ten” else “sth else”
  54. 54. val a: Int = 10 “sth else”
  55. 55. val a: Int = 10 if(a == “10”) “ten” else “sth else”
  56. 56. trait Eq[A] { def ===(a1: A)(a2: A): Boolean } val a: Int = 10 if(a == “10”) “ten” else “sth else”
  57. 57. trait Eq[A] { def ===(a1: A)(a2: A): Boolean } val a: Int = 10 if(a === “10”) “ten” else “sth else”
  58. 58. trait Eq[A] { def ===(a1: A)(a2: A): Boolean } val a: Int = 10 if(a === “10”) “ten” else “sth else” Doesn’t compile
  59. 59. trait Eq[A] { def ===(a1: A)(a2: A): Boolean } val a: Int = 10 if(a === “10”) “ten” else “sth else” Doesn’t compile and that’s a goodthing!
  60. 60. Let's play a game
  61. 61. /** 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] = ???
  62. 62. 00:59
  63. 63. 00:58
  64. 64. 00:57
  65. 65. 00:56
  66. 66. /** 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] = ???
  67. 67. /** Concatenate two maps. Keys from both maps must be * included. If keys collide, add values together. */ def concat( map1: Map[String, Option[(Int, Option[FinancialReport])], map2: Map[String, Option[(Int, Option[FinancialReport])] ): Map[String, Option[(Int, Option[FinancialReport])] = ???
  68. 68. 00:27
  69. 69. 00:26
  70. 70. 00:25
  71. 71. 00:25
  72. 72. trait Semigroup[A] { def |+|(a1: A, a2: A): A }
  73. 73. trait Semigroup[A] { def |+|(a1: A, a2: A): A } trait Semigroup { def pairS[A, B]: Semigroup[(A, B)] = ??? }
  74. 74. trait Semigroup[A] { def |+|(a1: A, a2: A): A } trait Semigroup { def pairS[A:Semigroup, B:Semigroup]: Semigroup[(A, B)] = ... }
  75. 75. trait Semigroup[A] { def |+|(a1: A, a2: A): A } trait Semigroup { def pairS[A:Semigroup, B:Semigroup]: Semigroup[(A, B)] = ... def optionS[A:Semigroup]: Semigroup[Option[A]] = ... }
  76. 76. trait Semigroup[A] { def |+|(a1: A, a2: A): A } trait Semigroup { def pairS[A:Semigroup, B:Semigroup]: Semigroup[(A, B)] = ... def optionS[A:Semigroup]: Semigroup[Option[A]] = ... def mapS[A, B:Semigroup]: Semigroup[Map[A,B]] = ... }
  77. 77. /** Concatenate two maps. Keys from both maps must be * included. If keys collide, add values together. */ def concat( m1: Map[String, Option[(Int, Option[FinancialReport])], m2: Map[String, Option[(Int, Option[FinancialReport])] ): Map[String, Option[(Int, Option[FinancialReport])] = ???
  78. 78. /** Concatenate two maps. Keys from both maps must be * included. If keys collide, add values together. */ def concat( m1: Map[String, Option[(Int, Option[FinancialReport])], m2: Map[String, Option[(Int, Option[FinancialReport])] ): Map[String, Option[(Int, Option[FinancialReport])] = m1 |+| m2
  79. 79. If it compiles, it works!
  80. 80. Can I prove correctness of my program?
  81. 81. Can code be generated from types?
  82. 82. Can I prove that my program will terminate?
  83. 83. Curry–Howard correspondence Propositions as types, proofs as programs.
  84. 84. 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.
  85. 85. Curry–Howard correspondence Proposition ≡ Type Proof ≡ Program
  86. 86. Propositional Logic ∧ AND ∨ OR → IMPLIES ¬ NOT
  87. 87. Predicate Logic ∧ AND ∨ OR → IMPLIES ¬ NOT ∀ FOR ALL ∃ EXISTS
  88. 88. 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.
  89. 89. Constructive Logic (Intuitionistic Logic)
  90. 90. Constructive Logic (Intuitionistic Logic)
  91. 91. Constructive Logic (Intuitionistic Logic)
  92. 92. Constructive Logic (Intuitionistic Logic)
  93. 93. Constructive Logic (Intuitionistic Logic)
  94. 94. Constructive Logic (Intuitionistic Logic)
  95. 95. Constructive Logic (Intuitionistic Logic) P ∨ ¬P P → ¬¬P
  96. 96. Constructive Logic (Intuitionistic Logic) P ∨ ¬P P → ¬¬P
  97. 97. Curry–Howard correspondence Proposition ≡ Type Proof ≡ Program
  98. 98. Prove that: P ∧ (Q ∨ R) → (P ∧ Q) ∨ (P ∧ R)
  99. 99. Prove that: P ∧ (Q ∨ R) → (P ∧ Q) ∨ (P ∧ R) X ∧ Y (X, Y)
  100. 100. Prove that: P ∧ (Q ∨ R) → (P ∧ Q) ∨ (P ∧ R) X ∧ Y (X, Y) X ∨ Y X + Y
  101. 101. Prove that: P ∧ (Q ∨ R) → (P ∧ Q) ∨ (P ∧ R) X ∧ Y (X, Y) X ∨ Y Either[X, Y]
  102. 102. Prove that: P ∧ (Q ∨ R) → (P ∧ Q) ∨ (P ∧ R) X ∧ Y (X, Y) X ∨ Y Either[X, Y] X → Y X => Y
  103. 103. Prove that: P ∧ (Q ∨ R) → (P ∧ Q) ∨ (P ∧ R) def proof[P, Q, R]: (P, Either[Q, R]) => Either[(P, Q), (P, R)] = ???
  104. 104. Prove that: P ∧ (Q ∨ R) → (P ∧ Q) ∨ (P ∧ R) def proof[P, Q, R]: (P, Either[Q, R]) => Either[(P, Q), (P, R)] = ???
  105. 105. Prove that: P ∧ (Q ∨ R) → (P ∧ Q) ∨ (P ∧ R) def proof[P, Q, R]: (P, Either[Q, R]) => Either[(P, Q), (P, R)] = ???
  106. 106. 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)) }
  107. 107. 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)) }
  108. 108. So why can’t we prove? P ∨ ¬P
  109. 109. So why can’t we prove? P ∨ ¬P ¬P P => “False”
  110. 110. So why can’t we prove? P ∨ ¬P ¬P P => Nothing
  111. 111. So why can’t we prove? P ∨ ¬P ¬P P => Nothing def proof[P]: Either[P, P => Nothing] = ???
  112. 112. What’s the point of all this?
  113. 113. Computer Science is my rooted in Math
  114. 114. “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.
  115. 115. “We must know! We will know!” Question: could you derive all mathematical truth using axioms and inference rules of formal logic, in principle opening up the process to automatisation?
  116. 116. “We must know! We will know!” 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.
  117. 117. “We must know! We will know!” “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.”
  118. 118. Kurt Gödel “On Formally Undecidable Propositions of Principia Mathematica and Related Systems” (1931) Incompleteness theorem
  119. 119. 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)
  120. 120. 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)
  121. 121. def identity[A](a: A): A = a
  122. 122. def willProveAnything[A]: A = ???
  123. 123. def willProveAnything[A]: A = null
  124. 124. def willProveAnything[A]: A = throw RuntimeException(“ha!”)
  125. 125. def willProveAnything[A]: A = willProveAnything
  126. 126. 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)
  127. 127. 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)
  128. 128. 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.
  129. 129. Chymyst/curryhoward https://github.com/Chymyst/curryhoward
  130. 130. Before we finish...
  131. 131. The End Pawel Szulc Pyrofex @rabbitonweb http://rabbitonweb.com paul.szulc@gmail.com

×