Slideshare uses cookies to improve functionality and performance, and to provide you with relevant advertising. If you continue browsing the site, you agree to the use of cookies on this website. See our User Agreement and Privacy Policy.

Slideshare uses cookies to improve functionality and performance, and to provide you with relevant advertising. If you continue browsing the site, you agree to the use of cookies on this website. See our Privacy Policy and User Agreement for details.

Can functional programming be liberated from static typing?

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.

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

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

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

10.
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

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

21.
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

22.
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.
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

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

34.
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