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.

Can functional programming be liberated from static typing?

1,320 views

Published on

- Discussed programming paradigms
- Defined functional programming
- Established that functional programming ≠ static typing
- Discussed static and dynamic typing
- Described gradual/optional typing

Published in: Technology
  • Be the first to comment

Can functional programming be liberated from static typing?

  1. 1. Can functional programming be liberated from static typing? @vseloved, 2015-10-31
  2. 2. Can functional programming be liberated from static typing? (also how? why? Wtf? …)
  3. 3. Can programming be liberated from the von Neumann style? -- John Backus, 1978 https://www.cs.cmu.edu/~crary/819-f09/Backus78.pdf
  4. 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. 5. www.slideshare.net/ScottWlaschin/fp-patterns-buildstufflt
  6. 6. The Value of Programming Paradigms • To be taught in universities
  7. 7. The Value of Programming Paradigms • To be taught in universities • To ignite flamewars
  8. 8. The Value of Programming Paradigms • To be taught in universities • To ignite flamewars • To characterize programming languages
  9. 9. The Value of Programming Paradigms • To be taught in universities • To ignite flamewars • To characterize programming languages • To inspire memes
  10. 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
  11. 11. The Real Value of Programming Paradigms • Taming complexity • Scaling programming
  12. 12. 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
  13. 13. How? • Promoting key principles • Discouraging some approach (something should be “considered harmful”)
  14. 14. “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/
  15. 15. Levels of Paradigm Coverage • In-the-small • In-the-large • In-between From the linguistic point-of-view: • Syntax • Semantics • Pragmatics
  16. 16. 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
  17. 17. Programming Patterns
  18. 18. Programming Patterns
  19. 19. 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)
  20. 20. Dealing with Errors There are only two hard problems in Computer Science: cache invalidation naming things, and off-by-one errors. -- Anonymous
  21. 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. 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
  23. 23. 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
  24. 24. Functional programming & static typing are completely orthogonal
  25. 25. Types vs Structures/Objects Terminology: • Product types ~ Structures • Sum types ~ Unions, Inheritance • Pattern matching ~ Destructuring “Favor object composition over class inheritance.”
  26. 26. 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
  27. 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
  28. 28. Gradual/Optional Typing The Common Lisp declaration facility (declare (ftype (function (integer list) t) ith) (ftype (function (number) float) sine))
  29. 29. 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))
  30. 30. 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.
  31. 31. Type Checker ~ Garbage Collector Dynamic typing ~ GC runtimes Static typing ~ Manual memory management
  32. 32. 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/
  33. 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. 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
  35. 35. Summary • Discussed programming paradigms • Defined functional programming • Established that functional programming ≠ static typing • Discussed static and dynamic typing • Described gradual/optional typing

×