The document discusses the potential for functional programming to be liberated from static typing while examining the limitations of conventional programming paradigms. It explores the differences between static and dynamic typing, highlighting the need for a balanced integration of both in programming. Additionally, it emphasizes the importance of gradual and optional typing in improving program correctness and flexibility.

1. Can functional programming be
liberated from static typing?
@vseloved, 2015-10-31

2. Can functional programming be
liberated from static typing?
(also how? why? Wtf? …)

3. Can programming be liberated
from the von Neumann style?
-- John Backus, 1978
https://www.cs.cmu.edu/~crary/819-f09/Backus78.pdf

4. Conventional programming languages are growing ever more
enormous, but not stronger. Inherent defects at the most
basic level cause them to be both fat and weak: their
primitive word-at-a-time style of programming inherited
from their common ancestor--the von Neumann computer, their
close coupling of semantics to state transitions, their
division of programming into a world of expressions and a
world of statements, their inability to effectively use
powerful combining forms for building new programs from
existing ones, and their lack of useful mathematical
properties for reasoning about programs.
An alternative functional style of programming is founded
on the use of combining forms for creating programs.
Functional programs deal with structured data, are often
nonrepetitive and nonrecursive, are hierarchically
constructed, do not name their arguments, and do not
require the complex machinery of procedure declarations to
become generally applicable. Combining forms can use high
level programs to build still higher level ones in a style
not possible in conventional languages.

5. www.slideshare.net/ScottWlaschin/fp-patterns-buildstufflt

7. The Value of Programming
Paradigms
• To be taught in universities

8. The Value of Programming
Paradigms
• To be taught in universities
• To ignite flamewars

9. The Value of Programming
Paradigms
• To be taught in universities
• To ignite flamewars
• To characterize programming languages

10. The Value of Programming
Paradigms
• To be taught in universities
• To ignite flamewars
• To characterize programming languages
• To inspire memes

13. Programming is a Pop Culture
Binstock: You once referred to computing as pop culture.
Kay: It is. Complete pop culture. I'm not against pop culture. Developed
music, for instance, needs a pop culture. There's a tendency to over-
develop. Brahms and Dvorak needed gypsy music badly by the end of the 19th
century. The big problem with our culture is that it's being dominated,
because the electronic media we have is so much better suited for
transmitting pop-culture content than it is for high-culture content. I
consider jazz to be a developed part of high culture. Anything that's been
worked on and developed and you [can] go to the next couple levels.
Binstock: One thing about jazz aficionados is that they take deep pleasure
in knowing the history of jazz.
Kay: Yes! Classical music is like that, too. But pop culture holds a disdain
for history. Pop culture is all about identity and feeling like you're
participating. It has nothing to do with cooperation, the past or the future
— it's living in the present. I think the same is true of most people who
write code for money. They have no idea where [their culture came from] —
and the Internet was done so well that most people think of it as a natural
resource like the Pacific Ocean, rather than something that was man-made.
When was the last time a technology with a scale like that was so error-
free? The Web, in comparison, is a joke. The Web was done by amateurs.
http://www.drdobbs.com/architecture-and-design/interview-with-alan-kay/24000
3442

14. The Real Value of
Programming Paradigms
• Taming complexity
• Scaling programming

15. The Real Value of
Programming Paradigms
• Taming complexity
• Scaling programming
There are only two hard problems
in Computer Science:
cache invalidation
and naming things.
-- Phil Karlton

16. How?
• Promoting key principles
• Discouraging some approach
(something should be
“considered harmful”)

17. “Cache Invalidation”
SP: global state considered harmful
OOP: state is incapsulated in objects
FP: state is passed in function calls
“Closures + Hash Tables = As Much OOP
as You’ll Ever Need”
https://lispy.wordpress.com/2007/07/09/closures-hash-tables-as-much-oop-as-youll-ever-n
eed/

18. Levels of Paradigm Coverage
• In-the-small
• In-the-large
• In-between
From the linguistic point-of-view:
• Syntax
• Semantics
• Pragmatics

19. Functional Programming
The good:
• Everything is an expression that
returns a value [in-the-small]
• Referential transparency
[in-the-large]
• Composition [in-between]
The ugly:
• mutable state considered harmful

21. Programming Patterns

22. Programming Patterns

23. Funcprog Patterns
• Functions all the way down
• Transformation-oriented programming
• Parametrize all the things
• Be as generic as possible
• Partial application
• Continuations
• Monads (composition of two-tracks
functions): use bind to chain
options/tasks/error handlers
• “Railway-oriented” programming
• Use map to lift functions (functors)
• Use monoids for aggregation
(map-reduce)

24. Dealing with Errors
There are only two hard problems
in Computer Science:
cache invalidation
naming things,
and off-by-one errors.
-- Anonymous

25. Type checking
The fundamental observation was that while memory is untyped,
the operations are typed and yield bad results if given
values that were expected to be of a different type than they
actually are, but the computer was utterly unable to report
any of this as a problem because by the time the operations
got their values, the binary representation was assumed to be
that of the type the operations had advertised that they
required. The reason for the compile-time type analysis is
precisely that the execution of the program has no idea
whatsoever which of the many types that map onto to the
binary representation the actual value in
memory is of, and the kind of mistakes that
were made in the past when programmers had
to keep track of this thing by hand was
very expensive.
-- Erik Naggum
https://groups.google.com/forum/#!topic/comp
.lang.lisp/7nhbeh2NIuw%5B126-150%5D

26. Static Typing
Types are declared for both values and
variables. And they are checked at
compile-time.
Applications:
• Check program correctness
• Inform compiler optimizations
• A tool for domain modeling
• Executable documentation

27. Type-oriented
Design Patterns
• Strive for purity
• Use types to represent constraints
• Types are cheap
• Strive for totality
• Use types to indicate errors
• Make illegal states unrepresentative
• Use sum types instead of inheritance
• Use sum types for state machines
• It's ok to expose public data
• Types are executable documentation

28. Functional programming & static typing
are completely orthogonal

29. Types vs Structures/Objects
Terminology:
• Product types ~ Structures
• Sum types ~ Unions, Inheritance
• Pattern matching ~ Destructuring
“Favor object composition over class
inheritance.”

30. Dynamic Typing
Values have types, variables don't.
Type-checking happens at run-time.
Address static typing limitations:
• Additional burden on the programmer
• Not all correct programs typecheck
• Limit program development workflow,
rule out some scenarios (interactive
and exploratory programming)
• Premature optimization

31. A request for more static type checking in Common Lisp is
regarded as a throw-back to the times before we realized
that disjointness is in the eye of the beholder, or as a
missing realization that disjointness does not exist in the
real world and therefore should not exist in the virtual
world we create with our software. Just because computers
are designed a particular way that makes certain types of
values much more efficient to compute with than others, does
not mean that efficiency is /qualitative/. Efficiency is
only quantitative and subordinate to correctness. It is a
very serious error in the Common Lisp world to write a
function that returns the wrong result quickly, but does not
know that it was the wrong result. For this reason, type
correctness is considered to be the responsibility of the
function that makes the requirements, not of the caller or
the compiler. If the programmer who makes those
requirements is sufficiently communicative, however, the
compiler should come to his assistance. The default
behavior, on the other hand, is that functions have to
accept values of type T.
-- Erik Naggum

32. Gradual/Optional Typing
The Common Lisp declaration facility
(declare (ftype (function (integer list) t) ith)
(ftype (function (number) float) sine))

33. Gradual/Optional Typing
The Common Lisp declaration facility
(declare (ftype (function (integer list) t) ith)
(ftype (function (number) float) sin))
You can also declare other properties:
• (declare (dynamic-extent item))
• (declare (ignore dummy))
• (declare (call-in traverse))
• (declare (declaration call-in))

34. Example
> (defun s+ (s1 s2)
(declare (ftype (function (string string) string) s1))
(format nil "~A~A" s1 s2))
> (defun s++ (s1 s2 s3)
(declare (type integer s3))
(s+ s1 (s+ s2 s3)))
; in: DEFUN S++
; (S+ S2 S3)
;
; caught WARNING:
; Derived type of S3 is
; (VALUES INTEGER &OPTIONAL),
; conflicting with its asserted type
; STRING.

35. Type Checker ~
Garbage Collector
Dynamic typing ~ GC runtimes
Static typing ~ Manual memory
management

36. Cons of Gradual Typing
“Why we’re no longer using Core.typed”
• Slower iteration time
• Core.typed does not implement the
entire Clojure language
• Third-party code is not covered
http://blog.circleci.com/why-were-no-longer-using-core-typed/

37. Fractal Programming
The Domain Layer
This is where all the actual domain rules are defined. In
general that means one or more domain specific languages.
This part of the system is what needs to be malleable enough
that it should be possible to change rules in production,
allow domain experts to do things with it, or just plain a
very complicated configuration.
The Dynamic & Stable Layers
The stable layer is the core set of axioms, the hard kernel
or the thin foundation that you can build the rest of your
system in. There is definitely advantages to having this
layer be written in an expressive language, but performance
and static type checking is most interesting here. There is
always a trade-of in giving up static typing, and the point
of having this layer is to make that trade-of smaller. The
dynamic layer runs on top of the stable layer, utilizing
resources and services provided. This is where all
interfaces are defined. But the implementations for them
lives in the dynamic layer, not in the stable. By doing it
this way you can take advantage of static type information
for your API’s while still retaining full flexibility in
implementation of them. It should be fairly small compared
to the rest of the application, and just provide the base
necessary services needed for everything to function.
-- Ola Bini
https://olabini
.com/blog/2008/
06/fractal-prog
ramming/

38. Static typing is a powerful tool
to help programmers express their
assumptions about the problem
they are trying to solve and
allows them to write more concise
and correct code. Dealing with
uncertain assumptions, dynamism
and (unexepected) change is
becoming increasingly important
in a loosely couple distributed
world. Instead of hammering on
the differences between
dynamically and statically typed
languages, we should instead
strive for a peaceful integration
of static and dynamic aspect in
the same language. Static typing
where possible, dynamic typing
when needed!
-- Erik Meijer
https://www.ics.uci.edu
/~lopes/teaching/inf212
W12/readings/rdl04meije
r.pdf

39. Summary
• Discussed programming paradigms
• Defined functional programming
• Established that
functional programming ≠ static typing
• Discussed static and dynamic typing
• Described gradual/optional typing