Stop coding Pascal. Saturday, April 6, 13

Transcription

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

2 Alexey Kachayev CTO at KitApps Inc. Open source activist About me Functional programming advocate Erlang, Python, Scala, Clojure, Go, kachayev <$> gmail github.com/kachayev/fn.py

3 Einstein problem solving principle

4 So, next 55 minutes we will talk about the core of the problems

5 difference between syntax and semantic What are we going to talk about? 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?

6 Simple task count of unique substring

7 Pascal

8 * just sample... it s really hard to show Pascal version in slide

9 Python v.1

10 Python v.2

11 Haskell

12 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

13 Let s dig deeper

14 Why is Haskell code so compact? transformations compositions * unix way, BTW

15 Where did all these i, j, k come from?

16 Instructions VS. Transformations

17 ... and deeper

18 Turing machine VS. λ-calculus

19 Turing machine infinite memory instructions (finite)

20 terms λ - calculus abstraction application β-reduction

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

22 Q: How it s possible that everything is a transformation?

23 A: Have you ever thought about how (4+5-2*9) works?

24 Hardware & compiler VS. Programming language

25 What the problem is? reusability && composability... oh, off course modularity matters, but we created many ways to split our programs since goto

26 hard to reuse/compose (context) hard to test (context) interactive style is hard Imperative 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 )

27 Imperative advantages(?) algorithms O(*) - the same low level optimization? - oh, not in Python manual memory control? - oh, not in Python

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

29 When somebody tells you that each language is sugar over Turing machine... do not believe

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

31 Move on to more practical questions * starting from easiest: looking for high-level patterns

32

33 Do you see the patterns?

34 Do you see the patterns?

35 Do you see the patterns?

36 Do you see the patterns?

37

38

39

40

41 Do you see the patterns? * we already talked that loops do not compose

42 Do you see the patterns?

43

44 transformations instead of instructions Not only syntax... reduction declarations without dealing with application reuse pure function in some context (functor) high(er) level of composability

45 When syntax sucks...

46 Iterators is not only about lists... this is the semantic way to think about possible solutions

47

48 Only last function matters... other functions are common and you can find them in Python documentation or implemented in Fn.py library

49 More examples Lazy evaluation and declarative approach:

50 iterators generators lazy-evaluation What stuff do you know about? undelimited continuations delimited continuations coroutines macros monads staging deref scope

51 iterators generators lazy-evaluation What stuff do you use in code? undelimited continuations delimited continuations coroutines macros monads staging deref scope

52 iterators generators lazy-evaluation What stuff do you want to use? undelimited continuations delimited continuations coroutines macros monads staging deref scope

53 I saw many coroutines during conference talks

54 I never saw coroutines in real-life projects

55 Can you describe* coroutine advantages? * using one word

56 Can you describe coroutine disadvantages?

57 easy to start with simplest stuff (it s cool, but don t stop!) habits, traditions (???) What the problem is? 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 (***)

58 Can you see semantic under the syntax?

59

60 Are you getting on a bit?

61 Can you see ABT under your AST?

62 I don t want you to write code this way I just want you to understand how it works and why it s possible

63 BTW, it s common pattern in JS code...

64 yield from is not only the new syntax!

65

66

67 It s all about composition.

68 You can (*) write pointfree (**) code * you just don t have readable syntax to do this ** applytwice is good example to show

69 Isn t this wonderful?

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

71 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

72 fold / unfold... dig deeper

73 Everybody knows this examples...

74 Dig deeper.

75

76 I want you to think about semantic

77 In 5 years Python will solve other problems

78 In 5 years Python should (*) solve other problems * technologies are changing very fast

79 Is Python ready to be a cutting-edge language?

80 Are you ready?

81 Questions? * other talks: ** fn.py: