Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Stop Coding Pascal

Stop Coding Pascal

Languages vs. Compilers, Imperative vs. Declarative, Ideas vs. Implementation.

Oleksii Kachaiev

April 06, 2013
Tweet

More Decks by Oleksii Kachaiev

Other Decks in Programming

Transcript

  1. Stop coding Pascal ...emotional sketch about past, present and future

    of programming languages, Python, compilers, developers, Life, Universe and Everything Saturday, April 6, 13
  2. 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
  3. So, next 55 minutes we will talk about the core

    of the problems Saturday, April 6, 13
  4. 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
  5. 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
  6. (λx.2 * x + 1) 3 β-reduction abstraction application The

    are many application operators in Haskell, ML Saturday, April 6, 13
  7. 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
  8. 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
  9. Imperative advantages(?) • algorithms O(*) - the same • low

    level optimization? - oh, not in Python • manual memory control? - oh, not in Python Saturday, April 6, 13
  10. 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
  11. When somebody tells you that each language is sugar over

    Turing machine... do not believe Saturday, April 6, 13
  12. Python • mostly imperative, but... • higher-ordered functions (*) •

    lambdas (*) • no for(i=0;i<10;i++) (**) • iterators (**) • map/filter/zip/itertools (**) • generators (**) • futures (concurrency, tulip) * ast/abt ** sequence-based semantic Saturday, April 6, 13
  13. Move on to more practical questions * starting from easiest:

    looking for high-level patterns Saturday, April 6, 13
  14. Do you see the patterns? * we already talked that

    loops do not compose Saturday, April 6, 13
  15. 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
  16. Iterators is not only about lists ... this is the

    semantic way to think about possible solutions Saturday, April 6, 13
  17. Only last function matters ... other functions are common and

    you can find them in Python documentation or implemented in Fn.py library Saturday, April 6, 13
  18. What stuff do you know about? • iterators • generators

    • lazy-evaluation • undelimited continuations • delimited continuations • coroutines • macros • monads • “staging” • “deref scope” Saturday, April 6, 13
  19. 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
  20. 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
  21. 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
  22. 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
  23. 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
  24. 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&filter... okay... Saturday, April 6, 13
  25. 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
  26. In 5 years Python should (*) solve other problems *

    technologies are changing very fast Saturday, April 6, 13