Stop Coding Pascal - Speaker Deck

Slide 1

Slide 1 text

Stop coding Pascal ...emotional sketch about past, present and future of programming languages, Python, compilers, developers, Life, Universe and Everything Saturday, April 6, 13

Slide 2

Slide 2 text

About me • Alexey Kachayev • CTO at KitApps Inc. • Open source activist • Functional programming advocate • Erlang, Python, Scala, Clojure, Go, Haskell • @kachayev • kachayev <$> gmail • github.com/kachayev/fn.py Saturday, April 6, 13

Slide 3

Slide 3 text

Einstein problem solving principle Saturday, April 6, 13

Slide 4

Slide 4 text

So, next 55 minutes we will talk about the core of the problems Saturday, April 6, 13

Slide 5

Slide 5 text

What are we going to talk about? • difference between syntax and semantic • imperative code: when and WHY? • machine VS language: problems and solutions • where did Python features come from • what is the current problem • why should I care? Saturday, April 6, 13

Slide 6

Slide 6 text

Simple task count of unique substring Saturday, April 6, 13

Slide 7

Slide 7 text

Pascal Saturday, April 6, 13

Slide 8

Slide 8 text

* just sample... it’s really hard to show Pascal version in slide Saturday, April 6, 13

Slide 9

Slide 9 text

Python v.1 Saturday, April 6, 13

Slide 10

Slide 10 text

Python v.2 Saturday, April 6, 13

Slide 11

Slide 11 text

Haskell Saturday, April 6, 13

Slide 12

Slide 12 text

What the difference is? • “pascal” VS “python.v1” - syntax (mostly) • “python.v1” VS “python.v2” - semantic • “python.v2” VS “haskell” - (mostly) syntax (*) * iterators VS. lazy-evaluation is a different story Saturday, April 6, 13

Slide 13

Slide 13 text

Let’s dig deeper Saturday, April 6, 13

Slide 14

Slide 14 text

Why is Haskell code so compact? • transformations • compositions • * unix way, BTW Saturday, April 6, 13

Slide 15

Slide 15 text

Where did all these i, j, k come from? Saturday, April 6, 13

Slide 16

Slide 16 text

Instructions Transformations VS. Saturday, April 6, 13

Slide 17

Slide 17 text

... and deeper Saturday, April 6, 13

Slide 18

Slide 18 text

λ-calculus Turing machine VS. Saturday, April 6, 13

Slide 19

Slide 19 text

Turing machine • inﬁnite memory • instructions (ﬁnite) Saturday, April 6, 13

Slide 20

Slide 20 text

λ - calculus • terms • abstraction • application • β-reduction Saturday, April 6, 13

Slide 21

Slide 21 text

(λx.2 * x + 1) 3 β-reduction abstraction application The are many application operators in Haskell, ML Saturday, April 6, 13

Slide 22

Slide 22 text

Q: “How it’s possible that everything is a transformation?” Saturday, April 6, 13

Slide 23

Slide 23 text

A: “Have you ever thought about how (4+5-2*9) works?” Saturday, April 6, 13

Slide 24

Slide 24 text

Programming language Hardware & compiler VS. Saturday, April 6, 13

Slide 25

Slide 25 text

What the problem is? “reusability” && “composability” ... oh, off course modularity matters, but we created many ways to split our programs since goto Saturday, April 6, 13

Slide 26

Slide 26 text

Imperative • hard to reuse/compose (context) • hard to test (context) • “interactive style” is hard • it’s not the language that I want to talk • parallelism is impossible • ... but it’s widespread • ... but it’s common • ... but it’s hard to see the root of the problems (“Vietnam”) Saturday, April 6, 13

Slide 27

Slide 27 text

Imperative advantages(?) • algorithms O(*) - the same • low level optimization? - oh, not in Python • manual memory control? - oh, not in Python Saturday, April 6, 13

Slide 28

Slide 28 text

Turing machine Assembly Algol 60/8 Fortran С Python Pascal Type theory Set theory λ-notation λ-calculus λ-calculus as PL Logic combinators ML (family) Haskell OCaml AST-base Lisp (family) ABC SETL Speedcoding Saturday, April 6, 13

Slide 29

Slide 29 text

When somebody tells you that each language is sugar over Turing machine... do not believe Saturday, April 6, 13

Slide 30

Slide 30 text

Python • mostly imperative, but... • higher-ordered functions (*) • lambdas (*) • no for(i=0;i<10;i++) (**) • iterators (**) • map/ﬁlter/zip/itertools (**) • generators (**) • futures (concurrency, tulip) * ast/abt ** sequence-based semantic Saturday, April 6, 13

Slide 31

Slide 31 text

Move on to more practical questions * starting from easiest: looking for high-level patterns Saturday, April 6, 13

Slide 32

Slide 32 text

http://wrongsideofmemphis.ﬁles.wordpress.com/2013/03/screen-shot-2013-03-23-at-12-32-17.png Saturday, April 6, 13

Slide 33

Slide 33 text

Do you see the patterns? Saturday, April 6, 13

Slide 34

Slide 34 text

Do you see the patterns? Saturday, April 6, 13

Slide 35

Slide 35 text

Do you see the patterns? Saturday, April 6, 13

Slide 36

Slide 36 text

Do you see the patterns? Saturday, April 6, 13

Slide 37

Slide 37 text

Saturday, April 6, 13

Slide 38

Slide 38 text

Saturday, April 6, 13

Slide 39

Slide 39 text

Saturday, April 6, 13

Slide 40

Slide 40 text

Saturday, April 6, 13

Slide 41

Slide 41 text

Do you see the patterns? * we already talked that loops do not compose Saturday, April 6, 13

Slide 42

Slide 42 text

Do you see the patterns? Saturday, April 6, 13

Slide 43

Slide 43 text

Saturday, April 6, 13

Slide 44

Slide 44 text

Not only syntax... • transformations instead of instructions • reduction declarations without dealing with application • reuse pure function in some context (functor) • high(er) level of composability Saturday, April 6, 13

Slide 45

Slide 45 text

When syntax sucks... Saturday, April 6, 13

Slide 46

Slide 46 text

Iterators is not only about lists ... this is the semantic way to think about possible solutions Saturday, April 6, 13

Slide 47

Slide 47 text

Saturday, April 6, 13

Slide 48

Slide 48 text

Only last function matters ... other functions are common and you can ﬁnd them in Python documentation or implemented in Fn.py library Saturday, April 6, 13

Slide 49

Slide 49 text

More examples Lazy evaluation and declarative approach: http://kachayev.github.com/talks/ Saturday, April 6, 13

Slide 50

Slide 50 text

What stuff do you know about? • iterators • generators • lazy-evaluation • undelimited continuations • delimited continuations • coroutines • macros • monads • “staging” • “deref scope” Saturday, April 6, 13

Slide 51

Slide 51 text

What stuff do you use in code? • iterators • generators • lazy-evaluation • undelimited continuations • delimited continuations • coroutines • macros • monads • “staging” • “deref scope” Saturday, April 6, 13

Slide 52

Slide 52 text

What stuff do you want to use? • iterators • generators • lazy-evaluation • undelimited continuations • delimited continuations • coroutines • macros • monads • “staging” • “deref scope” Saturday, April 6, 13

Slide 53

Slide 53 text

I saw many coroutines during conference talks Saturday, April 6, 13

Slide 54

Slide 54 text

I never saw coroutines in real-life projects Saturday, April 6, 13

Slide 55

Slide 55 text

Can you describe* coroutine advantages? * using one word Saturday, April 6, 13

Slide 56

Slide 56 text

Can you describe coroutine disadvantages? Saturday, April 6, 13

Slide 57

Slide 57 text

What the problem is? • easy to start with simplest stuff (it’s cool, but don’t stop!) • habits, traditions (???) • mutable variables and assignments dictate (*) • syntax doesn’t support non-imperative semantic (“for” is only one good example of support, “yield from” is also cool) (**) • internal contradictions (***) Saturday, April 6, 13

Slide 58

Slide 58 text

Can you see semantic under the syntax? Saturday, April 6, 13

Slide 59

Slide 59 text

https://gist.github.com/e000/1023982 Saturday, April 6, 13

Slide 60

Slide 60 text

Are you getting on a bit? Saturday, April 6, 13

Slide 61

Slide 61 text

Can you see ABT under your AST? Saturday, April 6, 13

Slide 62

Slide 62 text

I don’t want you to write code this way I just want you to understand how it works and why it’s possible Saturday, April 6, 13

Slide 63

Slide 63 text

BTW, it’s common pattern in JS code... Saturday, April 6, 13

Slide 64

Slide 64 text

yield from is not only the new syntax! Saturday, April 6, 13

Slide 65

Slide 65 text

Saturday, April 6, 13

Slide 66

Slide 66 text

Saturday, April 6, 13

Slide 67

Slide 67 text

It’s all about composition. Saturday, April 6, 13

Slide 68

Slide 68 text

You can (*) write point- free (**) code * you just don’t have readable syntax to do this ** applyTwice is good example to show Saturday, April 6, 13

Slide 69

Slide 69 text

Isn’t this wonderful? Saturday, April 6, 13

Slide 70

Slide 70 text

Contra • no composition syntax!!! • okay... def new function (not readable enough) • no recursion!!! • okay... the list is...? iterators is...? • oh, I know! recursion = fold + unfold :) • no fold!!! we have list comprehensions • but... LC = map&ﬁlter... okay... Saturday, April 6, 13

Slide 71

Slide 71 text

Code vs. Ideas So now reduce(). This is actually the one I've always hated most, ... almost every time I see a reduce() call with a non-trivial function argument, I need to grab pen and paper to diagram... it's better to write out the accumulation loop explicitly. (c) Guido Van Rossum Saturday, April 6, 13

Slide 72

Slide 72 text

fold / unfold ... dig deeper Saturday, April 6, 13

Slide 73

Slide 73 text

Everybody knows this examples... Saturday, April 6, 13

Slide 74

Slide 74 text

Dig deeper. Saturday, April 6, 13

Slide 75

Slide 75 text

Saturday, April 6, 13

Slide 76

Slide 76 text

I want you to think about semantic Saturday, April 6, 13

Slide 77

Slide 77 text

In 5 years Python will solve other problems Saturday, April 6, 13

Slide 78

Slide 78 text

In 5 years Python should (*) solve other problems * technologies are changing very fast Saturday, April 6, 13

Slide 79

Slide 79 text

Is Python ready to be a cutting-edge language? Saturday, April 6, 13

Slide 80

Slide 80 text

Are you ready? Saturday, April 6, 13

Slide 81

Slide 81 text

Questions? * other talks: https://kachayev.github.com/talks ** fn.py: https://github.com/kachayev/fn.py Saturday, April 6, 13