Four Languages From Forty Years Ago (NewCrafts 2019)

NewCrafts 2019
Four Languages From
FortyYears Ago
@ScottWlaschin
fsharpforfunandprofit.com
a.k.a What can we learn
from the 1970's?

I'm old …
I'm so old that I was
actually alive in the 1970's

How much do you know
about the 1970's?

Do you know these 1970's classics?

Do you know these 1970's classics?
Prolog
ML family

What does your toolkit
look like?

Does your DIY toolkit look like this?
For hammering nails:
For screwing things in:
For cutting wood:
For tightening bolts:
I hope not! That would be silly!

Does your programming toolkit look like this?
For domain modeling:
For complex business rules:
For querying data:
For live coding:
Hmmmm...

Don't use hammers only…
…expand your toolkit!

"A language that doesn't affect the way
you think about programming, is not
worth knowing" – Alan Perlis
Galaxy Brain
seal of approval

The most popular programming languages
• Java
• JavaScript
• C++
• C
• C#
• Python
• PHP
• Ruby
• Visual Basic
• Go

Australian English
British English
"I speak three languages"

It's a big world out there
Not every language looks like C or C# or Java or JavaScript

What programming paradigms
do you need to know?

The most important programming paradigms
• Imperative-procedural
– ALGOL, 1960
• Object-oriented
– Simula 1967
– Smalltalk 1976
• Functional
– ML 1972
• Symbolic
– Lisp 1959
– Maclisp/Scheme 1970's
• Logic
– Prolog 1973
• Concatenative
– Forth 1970
...and all paradigms had
stabilized by mid-1980's
Concepts originated in
the 1970's...

Are you caught up
with the state of the art
from 35 years ago?

So…
let's go back to the 1970's…

SQL background
• Part of IBM's System R, the first practical
relational database.
• Before SQL: the dark ages of proprietary and
custom database query APIs.

Learning from SQL #1:
A consistent model
Everything is a set of relations

TABLE Person
| Name | Age |
|---------|-----|
| Liz | 92 |
| Charles | 69 |
| Wills | 35 |
| Harry | 33 |
TABLE ParentChild
| Parent | Child |
|---------|---------|
| Diana | Wills |
| Diana | Harry |
| Charles | Wills |
| Charles | Harry |
| Liz | Charles |

| Name | Age |
|---------|-----|
| Liz | 92 |
| Charles | 69 |
| Wills | 35 |
| Harry | 33 |
SELECT Name FROM Person
The result is another set
of relations

| Name | Age |
|---------|-----|
| Liz | 92 |
| Charles | 69 |
| Wills | 35 |
| Harry | 33 |
SELECT * FROM Person WHERE Age > 50
The result is another set
of relations

SELECT Parent,Age
FROM Person
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:

Composability
It's an expression-oriented language

SELECT Name
FROM Person
WHERE Age > 50
You can take a query like this:

And embed it as a subquery
SELECT Child
FROM ParentChild
WHERE Parent IN
(SELECT Name
FROM Person
WHERE Age > 50)

And embed *that* as a subquery
SELECT Child as Grandchild
FROM ParentChild
WHERE Parent IN
( SELECT Child
FROM ParentChild
WHERE Parent IN
(SELECT Name
FROM Person
WHERE Age > 50))

Expressions are great, part 1:
Expressions are composable


There's another reason to prefer
expressions over statements…
They eliminate many types of error

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?

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

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;
}

Expressions are great, part 2:
Expressions reduce bugs
and make refactoring easier


It's declarative
"What" not "How"

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

SELECT * FROM Person WHERE Age > 50
Example of "What" programming

Separation of concerns
It's a QUERY language!

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.

What can we learn from SQL?
• Consistent model
– And predictable
• Composable
– Because expression-based
• Declarative interface
– "What", not "how"
• Separation of concerns
– Reinvented as Command-Query Separation
• Interactivity is important
– You can play and experiment

Prolog background
• First mainstream logic programming language
– Designed in Marseille, France.
– From "programmation en logique"
• European answer to LISP for AI.
– But now just as esoteric 

Learning from Prolog #1:
A consistent model
Everything is a fact or a rule

Facts
age(liz,92).
age(charles,69).
age(wills,35).
age(harry,33).
parent(charles,wills).
parent(charles,harry).
parent(liz,charles).
Rules
grandparent(GP,C) :-
parent(GP,P),
parent(P,C).
isOlder(P1,P2) :-
age(P1,A1),
age(P2,A2),
A1 > A2.

Learning from Prolog #2:
It's declarative
"What" not "How"

age(liz,92). % is it a fact?
true.
age(P,92). % P is unbound, so tell me
P=liz.
age(liz,A). % A is unbound
A=92.

grandparent(liz,harry).
true.
isOlder(wills,liz).
false.
grandparent(liz,P). % P is unbound
P=harry.
P=wills.
isOlder(P,charles). % P is unbound
P=liz.
Rules and facts look the same

% what is [1] followed by [2,3] ?
append([1], [2,3], X).
X = [1,2,3] % only one answer
% what do you prepend to [2,3] to make [1,2,3]?
append(X, [2,3], [1,2,3]).
X = [1] % only one answer
% how many ways can you make [1,2,3]?
append(X, Y, [1,2,3]).
X = [] Y =[1,2,3] % multiple answers
X = [1] Y =[2,3]
X = [1,2] Y =[3]
X = [1,2,3] Y =[]
Bi-directional unification is awesome

What can we learn from Prolog?
• Consistent model (again)
• Declarative (again)
– "What" not "how" in the Sudoku example
• Unification is very cool
– Bi-directional queries
– Ask both "is true?" and "what matches?"
• Interactivity is important (again)

ML (1973)
Parent of SML, OCaml and F#

ML background
• "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#

Learning from ML #1:
A consistent model
Functions are "normal" things
just like ints, strings, bools, etc.

Don't worry.
I'm not going to talk about
functional programming.

Type inference

let doSomething f x =
let y = f (x + 1)
"hello" + y
NOTE: I can't show the original ML from the 1970's,
so I'm using F# instead.

let y = f (x + 1)
"hello" + y

let y = f (x + 1)
"hello" + y
Inferred type of doSomething :
f:(int -> string) -> x:int -> string

// 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

Sensible defaults

Sensible defaults
• Immutable by default
– Mutable is a special case
• Non-nullable types by default
– Nullable is a special case
• Structural equality by default
– Reference equality is special case
• Everything must be initialized

Algebraic type system
NB: Technically not part of original ML but
now a standard part of "ML family"

New types are built from smaller types by:
Composing with “AND”
Composing with “OR”

Example: pairs, tuples, records
FruitSalad = One each of and and
Compose with “AND”
type FruitSalad = {
Apple: AppleVariety
Banana: BananaVariety
Cherry: CherryVariety
}

Snack = or or
Compose with “OR”
type Snack =
| Apple of AppleVariety
| Banana of BananaVariety
| Cherry of CherryVariety

A real world example
of composing types

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

type CheckNumber = int
type CardNumber = string
With an algebraic type system you would probably
implement by composing types, like this:

type CheckNumber = ...
type CardNumber = …
type CardType = Visa | Mastercard
type CreditCardInfo = {
CardType : CardType
CardNumber : CardNumber
}

type CardNumber = ...
type CardType = ...
type CreditCardInfo = ...
type PaymentMethod =
| Cash
| Check of CheckNumber
| Card of CreditCardInfo

type CardType = ...
| Cash
type PaymentAmount = decimal
type Currency = EUR | USD

type CardType = ...
| Cash
type PaymentAmount = decimal
type Currency = EUR | USD
type Payment = {
Amount : PaymentAmount
Currency : Currency
Method : PaymentMethod }

Types can become
executable documentation

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!

| Cash

A big topic and not enough time  
More on DDD and designing with types at
fsharpforfunandprofit.com/ddd

I could do an ML demo here
But I won't!

What can we learn from ML?
• Consistent model (again)
• Expression-based (again)
– Everything is composable
– Also prevents bugs
• Type inference is awesome
• Sensible defaults make accidents harder
– E.g. immutable by default
• Algebraic types are awesome

Is a simulation of a teletype really the best interface
for interacting with an operating system?
-- @gambler on HN, Jan 2019

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.

Learning from Smalltalk #1:
A consistent model:
everything is an object

Minimal syntax

Minimal syntax
Put the power in the language instead.

Late binding
If you're going to be a dynamic language,
be a really dynamic language.

Who needs text files?
If everything is accessible
you have a lot of power

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!

What can we learn from the 1970's?
• Many great ideas were developed 40 years ago
– They should be more widely known
• There are many different approaches to solving
problems.
– A bigger toolbox is a good thing to have
– Use the right tool for the job

And one more thing…
C-style syntax is not the only possible syntax!
– No curly braces
– Sentences can end properly, with a period!
– No dot syntax (not even in OO Smalltalk)

"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!

Slides and video here
fsharpforfunandprofit.com/fourfromforty
Thank you!
"Domain modelling Made Functional" book
fsharpforfunandprofit.com/books
@ScottWlaschin Me on twitter

Four Languages From Forty Years Ago (NewCrafts 2019)

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à Four Languages From Forty Years Ago (NewCrafts 2019)

Similaire à Four Languages From Forty Years Ago (NewCrafts 2019) (20)

Plus de Scott Wlaschin

Plus de Scott Wlaschin (17)

Dernier

Dernier (20)

Four Languages From Forty Years Ago (NewCrafts 2019)