Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Four Languages From Forty Years Ago

1,801 views

Published on

(More info and video at fsharpforfunandprofit.com/fourfromforty)

The 1970's were a golden age for new programming languages, but do they have any relevance to programming today? Can we still learn from them?

In this talk, we'll look at four languages designed over forty years ago -- SQL, Prolog, ML, and Smalltalk -- and discuss their philosophy and approach to programming, which is very different from most popular languages today.

We'll come away with some practical principles that are still very applicable to modern development. And you might discover your new favorite programming paradigm!

Published in: Software

Four Languages From Forty Years Ago

  1. 1. Four Languages From FortyYears Ago @ScottWlaschin fsharpforfunandprofit.com a.k.a What can we learn from the 1970's?
  2. 2. Me The 1970's
  3. 3. Four languages from 40 years ago • A brief history of programming languages • Hammers and toolkits • Four (or five) languages: – SQL (1974) – Prolog (1972) – ML (1973) – Smalltalk (1976,1980) – Language X (1979) ^or five
  4. 4. A brief history of programming languages
  5. 5. A language that doesn't affect the way you think about programming, is not worth knowing – Alan Perlis Galaxy Brain seal of approval
  6. 6. The 1950s "Pre-Cambrian era" Assembly Languages 1950 1959
  7. 7. The 1950s 1950 1959 FORTRAN (1957) "Pre-Cambrian era"
  8. 8. The 1950s 1950 1959 "Pre-Cambrian era" COBOL (1959)
  9. 9. The 1950s 1950 1959 "Pre-Cambrian era" LISP (1959)
  10. 10. The 1960s 1960 1969 "IBM and the Seven Dwarfs." ALGOL 60 (1960)
  11. 11. The 1960s 1969 "IBM and the Seven Dwarfs." BASIC (1964) 1960
  12. 12. The 1960s 1969 "IBM and the Seven Dwarfs." 1960 PL/I (1964)
  13. 13. The 1960s 1969 "IBM and the Seven Dwarfs." 1960 ISWIM (1966)
  14. 14. The 1960s 1969 "IBM and the Seven Dwarfs." 1960 APL (1966)
  15. 15. The 1960s 1969 "IBM and the Seven Dwarfs." 1960 Simula 67 (1967)
  16. 16. The 1960s 1969 "IBM and the Seven Dwarfs." 1960 BCPL (1967)
  17. 17. The 1960s 1969 "IBM and the Seven Dwarfs." 1960 Logo (1967)
  18. 18. The 1960s 1969 "IBM and the Seven Dwarfs." 1960 ALGOL 68 (1968)
  19. 19. The 1970s 1970 1979 The Cambrian Explosion
  20. 20. The 1970s 1970 1979 FORTH (1970) The Cambrian Explosion
  21. 21. The 1970s 1970 1979 Pascal (1970) The Cambrian Explosion
  22. 22. The 1970s 1970 1979 C (1972) The Cambrian Explosion
  23. 23. The 1970s 1970 1979 Prolog (1972) The Cambrian Explosion
  24. 24. The 1970s 1970 1979 ML (1973) The Cambrian Explosion
  25. 25. The 1970s 1970 1979 SQL (1974) The Cambrian Explosion
  26. 26. The 1970s 1970 1979 CLU (1975) The Cambrian Explosion
  27. 27. The 1970s 1970 1979 Scheme (1975) The Cambrian Explosion
  28. 28. The 1970s 1970 1979 Microsoft Basic (1975) The Cambrian Explosion
  29. 29. The 1970s 1970 1979 Smalltalk (1976, 1980) Ex-practitioners are very influential: GoF Patterns, XP, Agile, Refactoring The Cambrian Explosion
  30. 30. The 1970s 1970 1979 Modula-2 (1978) The Cambrian Explosion
  31. 31. The 1970s 1970 1979 Language X (1979) The Cambrian Explosion
  32. 32. The most important programming paradigms • Imperative-procedural – ALGOL, 1960 • Object-oriented – Simula 1967 – Smalltalk 1976 • Functional – ML 1972 • Symbolic – Lisp 1959 – Maclisp 1970's – Scheme 1970's • Logic – Prolog 1973 • Stack-based – Forth 1970
  33. 33. Are you caught up with the 1980's state of the art?
  34. 34. Does your DIY toolkit look like this? For hammering nails: For screwing things in: For cutting wood: For tightening bolts:
  35. 35. Does your programming toolkit look like this? For domain modeling: For complex business rules: For querying data: For live coding:
  36. 36. The most popular programming languages • Java • JavaScript • C++ • C • C# • Python • PHP • Ruby • Visual Basic • Go
  37. 37. Australian English British English "I speak three languages"
  38. 38. It's a big world out there Not every language looks like C/C#/Java/JavaScript
  39. 39. Let's go exploring…
  40. 40. SQL (1974)
  41. 41. SQL Background • Originally "SEQUEL" (Structured English Query Language) • Designed as part of IBM's System R, the first practical relational database. • Before SQL: the dark ages of proprietary and custom database query APIs.
  42. 42. Learning from SQL #1: A consistent model: everything is a set of relations
  43. 43. TABLE PersonAge | Name | Age | |---------|-----| | Liz | 92 | | Charles | 69 | | Wills | 35 | | Harry | 33 | TABLE ParentChild | Parent | Child | |---------|---------| | Diana | Wills | | Diana | Harry | | Charles | Wills | | Charles | Harry | | Liz | Charles |
  44. 44. | Name | Age | |---------|-----| | Liz | 92 | | Charles | 69 | | Wills | 35 | | Harry | 33 | SELECT Name FROM PersonAge The result is another set of relations
  45. 45. | Name | Age | |---------|-----| | Liz | 92 | | Charles | 69 | | Wills | 35 | | Harry | 33 | SELECT * FROM PersonAge WHERE Age > 50 The result is another set of relations
  46. 46. SELECT Parent,Age FROM PersonAge OUTER JOIN ParentChild WHERE Parent = Person "Set operations, huh? I bet there's a way to do cartesian products then." Consistency => Predictability Here you go:
  47. 47. Learning from SQL #2: SQL is expression-based
  48. 48. SELECT Name FROM PersonAge WHERE Age > 50 You can take a query like this:
  49. 49. And embed it as a subquery SELECT Child FROM ParentChild WHERE Parent IN (SELECT Name FROM PersonAge WHERE Age > 50)
  50. 50. Expressions are great, part 1: Expressions are composable 
  51. 51. There's another reason to prefer expressions over statements…
  52. 52. void ifThenElseStatement(bool aBool) { int result; if (aBool) { result = 42; } printfn("result=%i", result); } How many things could cause problems in this C-like code?
  53. 53. void ifThenElseStatement(bool aBool) { int result; if (aBool) { result = 42; } printfn("result=%i", result); } How many things could cause problems in this C-like code?
  54. 54. void ifThenElseStatement(bool aBool) { int result; if (aBool) { result = 42; } printfn("result=%i", result); } How many things could cause problems in this C-like code?
  55. 55. void ifThenElseStatement(bool aBool) { int result; if (aBool) { result = 42; } printfn("result=%i", result); } How many things could cause problems in this C-like code?
  56. 56. void ifThenElseStatement(bool aBool) { int result; if (aBool) { result = 42; } printfn("result=%i", result); } How many things could cause problems in this C-like code?
  57. 57. public void IfThenElseExpression(bool aBool) { int result = aBool ? 42 : 0; Console.WriteLine("result={0}", result); } The same C-like code written in an expression-oriented way
  58. 58. public void IfThenElseExpression(bool aBool) { int result = aBool ? 42 : 0; Console.WriteLine("result={0}", result); } The same C-like code written in an expression-oriented way
  59. 59. public void IfThenElseExpression(bool aBool) { int result = aBool ? 42 : 0; Console.WriteLine("result={0}", result); } The same C-like code written in an expression-oriented way
  60. 60. public void IfThenElseExpression(bool aBool) { int result = aBool ? 42 : 0; Console.WriteLine("result={0}", result); } The same C-like code written in an expression-oriented way
  61. 61. public void IfThenElseExpression(bool aBool) { int result = aBool ? 42 : 0; Console.WriteLine("result={0}", result); } The same C-like code written in an expression-oriented way int StandaloneSubexpression(bool aBool) { return aBool ? 42 : 0; }
  62. 62. Expressions are great, part 2: Expressions reduce bugs and make refactoring easier 
  63. 63. Learning from SQL #3: It's declarative. "What" not "How"
  64. 64. FILE *stream; char *line = NULL; size_t len = 0; ssize_t nread; stream = fopen(argv[1], "r"); while ((nread = getline(&line, &len, stream)) != -1) { /* check what the age is */ if age > 50 fwrite(line, nread, 1, stdout); } free(line); fclose(stream); Example of "How" programming
  65. 65. SELECT * FROM PersonAge WHERE Age > 50 Example of "What" programming
  66. 66. Learning from SQL #4: Separation of concerns
  67. 67. SQL: Separation of concerns • It's a QUERY language, doh! – A Data Query Language • Insert/Update/Delete is a different language – A Data Manipulation Language • Defining tables etc. is a different language again – A Data Definition Language • "SQL" now means all of these together.
  68. 68. What can we learn from SQL? • Be predictable – use a consistent model • Expression-based – means code is composable • Declarative interface – Focus on exposing the what not the how • Separation of concerns • Interactivity is important – You can play and experiment
  69. 69. Prolog (1972)
  70. 70. Prolog Background • First mainstream logic programming language • Designed in Marseille, France. • From "programmation en logique" • European answer to LISP for AI  • Big in Japan ("Fifth generation" project)
  71. 71. Learning from Prolog #1: A consistent model: everything is a fact or a rule
  72. 72. Facts age(liz,92). age(charles,69). age(wills,35). age(harry,33). parent(charles,wills). parent(charles,harry). parent(liz,charles). Rules olderThan(P,Age) :- age(P,A), A > Age. isOlder(P1,P2) :- age(P1,A1), age(P2,A2), A1 > A2.
  73. 73. Learning from Prolog #2: It's declarative. "What" not "How"
  74. 74. Age(liz,92). true. Age(P,92). % P is unbound P=liz. Age(liz,A). % A is unbound A=92. Prolog uses unification
  75. 75. grandparent(liz,harry). true. grandparent(liz,P). % P is unbound P=harry. P=wills. Prolog uses unification
  76. 76. Q: "Would this make a good query language as an alternative to SQL?" A: "Yes, it exists and is called Datalog"
  77. 77. Get the names and addresses of employees who work for at least one project located in Houston but whose department does not have a location in Houston. worksOnHoustonProj(Manager) :- works_on(Manager,Proj,_), project(_,Proj,'Houston',_). notInHouston(Manager) :- employee(_,_,_,Manager,_,_,_,_,_,Dept), not dept_locations(Dept,'Houston'). answer(First,Middle,Last,Addr) :- employee(First,Middle,Last,Mgr,_,Addr,_,_,_,_), worksOnHoustonProj(Mgr), notInHouston(Mgr). Datalog example
  78. 78. append([1], [2,3], X). X = [1,2,3] append(X, [2,3], [1,2,3]). X = [1] append(X, Y, [1,2,3]). X = [] Y =[1,2,3] X = [1] Y =[2,3] X = [1,2] Y =[3] X = [1,2,3] Y =[] Bi-directional unification is awesome
  79. 79. Prolog demo
  80. 80. What can we learn from Prolog? • Be consistent and predictable (again) • Declarative (again) • Unification is very cool – Bi-directional queries – Ask both "is true?" and "what matches?" • Interactivity is important (again)
  81. 81. ML (1973)
  82. 82. ML • "ML" for "Meta Language" – Designed as part of a theorem-proving system – Not to be confused with Machine Learning. • An impure functional language – Parent of Standard ML, OCaml, F#
  83. 83. Don't worry. I'm not going to talk about functional programming.
  84. 84. Learning from ML #1: Type Inference
  85. 85. let doSomething f x = let y = f (x + 1) "hello" + y
  86. 86. let doSomething f x = let y = f (x + 1) "hello" + y
  87. 87. let doSomething f x = let y = f (x + 1) "hello" + y Inferred type of doSomething : f:(int -> string) -> x:int -> string
  88. 88. // C# code public IEnumerable<IGrouping<TKey, TSource>> GroupBy<TSource, TKey>( IEnumerable<TSource> source, Func<TSource, TKey> keySelector ) { ... } // F# code let GroupBy source keySelector = ... Benefits of type inference: * Less typing * Less noise, more logic Here's a more complex example
  89. 89. Learning from ML #2: Different defaults
  90. 90. Different defaults • Immutable by default – Mutable is a special case • Non-null types by default – Nullable is a special case • Structural equality by default – Reference equality is special case • Everything must be initialized
  91. 91. Learning from ML #3: Algebraic type system
  92. 92. New types are built from smaller types by: Composing with “AND” Composing with “OR”
  93. 93. Example: pairs, tuples, records FruitSalad = One each of and and Compose with “AND” type FruitSalad = { Apple: AppleVariety Banana: BananaVariety Cherry: CherryVariety }
  94. 94. Snack = or or Compose with “OR” type Snack = | Apple of AppleVariety | Banana of BananaVariety | Cherry of CherryVariety
  95. 95. A real world example of composing types
  96. 96. Some requirements: We accept three forms of payment: Cash, Check, or Card. For Cash we don't need any extra information For Checks we need a check number For Cards we need a card type and card number
  97. 97. type CheckNumber = int type CardNumber = string With an algebraic type system you would probably implement by composing types, like this:
  98. 98. type CheckNumber = ... type CardNumber = … type CardType = Visa | Mastercard type CreditCardInfo = { CardType : CardType CardNumber : CardNumber }
  99. 99. type CheckNumber = ... type CardNumber = ... type CardType = ... type CreditCardInfo = ... type PaymentMethod = | Cash | Check of CheckNumber | Card of CreditCardInfo
  100. 100. type CheckNumber = ... type CardNumber = ... type CardType = ... type CreditCardInfo = ... type PaymentMethod = | Cash | Check of CheckNumber | Card of CreditCardInfo type PaymentAmount = decimal type Currency = EUR | USD
  101. 101. type CheckNumber = ... type CardNumber = ... type CardType = ... type CreditCardInfo = ... type PaymentMethod = | Cash | Check of CheckNumber | Card of CreditCardInfo type PaymentAmount = decimal type Currency = EUR | USD type Payment = { Amount : PaymentAmount Currency : Currency Method : PaymentMethod }
  102. 102. Types can become executable documentation
  103. 103. type Deal = Deck -> (Deck * Card) type PickupCard = (Hand * Card) -> Hand type Suit = Club | Diamond | Spade | Heart type Rank = Two | Three | Four | Five | Six | Seven | Eight | Nine | Ten | Jack | Queen | King | Ace type Card = { Suit:Suit; Rank:Rank } type Hand = Card list type Deck = Card list type Player = {Name:string; Hand:Hand} type Game = { Deck:Deck; Players:Player list } The domain on one screen!
  104. 104. type CardType = Visa | Mastercard type CardNumber = string type CheckNumber = int type PaymentMethod = | Cash | Check of CheckNumber | Card of CreditCardInfo
  105. 105. A big topic and not enough time   More on DDD and designing with types at fsharpforfunandprofit.com/ddd
  106. 106. ML demo
  107. 107. What can we learn from ML? • Expression-based (again) • Type inference is awesome – Makes adding complicated parameters easy • Make bad things harder – E.g. immutable by default • Parametric polymorphism (aka generics) • Algebraic types are awesome
  108. 108. Smalltalk (1976,1980)
  109. 109. I
  110. 110. Smalltalk Background • Developed at Xerox PARC – Along with the first PC, the first GUI, the first laser printer, ethernet, and more. • Smalltalk introduced – Message-based OO – Model-View-Controller – A windowing IDE – Also had aVM, generational GC, etc.
  111. 111. Smalltalk-80 User Interface
  112. 112. Learning from Smalltalk #1: A consistent model: everything is an object everything is an object *everything* is an object
  113. 113. Learning from Smalltalk #2: Minimal syntax. Put the power in the language instead.
  114. 114. Learning from Smalltalk #3: Late binding. If you're going to be a dynamic language, be a really dynamic language.
  115. 115. Learning from Smalltalk #4: Who needs text files? If everything is accessible you have a lot of power
  116. 116. Smalltalk demo
  117. 117. What can we learn from Smalltalk? • A consistent model, again • Minimize syntax and make the language powerful • Be awesome and make people fall in love with you!
  118. 118. "But surely self-contained interactive languages like Smalltalk are a dead-end?"
  119. 119. Language X (1979)
  120. 120. Language X (1979) • In the 1980's people would pay thousands of dollars just to use this language. • Its descendants have been at the heart of the software products that dominate their field. • Its grandchild is the most popular programming language in the world.
  121. 121. A1 + B2 / 2 Why wasVisiCalc successful? Like Smalltalk, a consistent model, a highly interactive environment and a programming language: all fitting together beautifully. Like SQL, a domain-specific (expression-based!) programming language that non-programmers could understand: Like ML, lots of expressive power in functions: SUM(A1..A7) Like Prolog, programming by filling in slots (aka "cells"). Like Smalltalk, no separate text files!
  122. 122. What can we learn fromVisiCalc? • Programming languages appear in many guises. • Programming is not just for programmers. – People want to interact and explore. – Programming for a specific domain is often more useful than general purpose programming. • Use the right tool for the job.
  123. 123. Summary • There are many different approaches to solving problems. – A bigger toolbox is a good thing to have • C-style syntax is not the only possible syntax. – Sentences can end properly, with a period! – No curly braces – No dot syntax (not even Smalltalk)
  124. 124. A language that doesn't affect the way you think about programming, is not worth knowing – Alan Perlis So go forth and expand your Galaxy Brain!
  125. 125. Slides and video here fsharpforfunandprofit.com/fourfromforty Thank you! "Domain modelling Made Functional" book fsharpforfunandprofit.com/books @ScottWlaschin Me on twitter

×