Bridging Ousterhout's Dichotomy to hone your prog-fu Andy Grover [email_address] [email_address]
John Ousterhout <ul><li>“OH-stir-howt”
Creator of Tcl/Tk
Wrote “Scripting: Higher Level Programming for the 21st Century” </li></ul>
The Dichotomy Two kingdoms of languages: <ul><li>System Languages
Compiled into machine code
Statically typed
Complex data structures & algorithms </li></ul><ul><li>Glue/Scripting Languages
Dynamically typed
No complex structures
Runtimes, VM, byte-compiled </li></ul>
I say: Learn One of Each  <ul><li>C and Python </li><ul><li>Or Ruby, Ocaml, Haskell, Lisp </li></ul><li>Not C++ </li><ul><...
Java if you must </li></ul><li>Use Python instead of shell scripting </li></ul>
&quot;I am a big proponent of temporarily changing programming scope every once in a while to reset some assumptions and h...
Upcoming SlideShare
Loading in …5

Bridging Ousterhout's Dichotomy


Published on

By Andy Grover. This talk discusses the diversity and dichotomy of languages, and why a programmer who works in either a high- or low-level language would benefit from learning another language.

Published in: Technology
1 Like
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • I&apos;m actually filling in for the original presenter, who chose this presentation&apos;s title. I was a little confused by it. You don&apos;t need to be godly or have mad leet skillz to use python. It also is a very productive language, so it helps you make the most of your time on earth.
  • Obviously this is incomplete, and there are many languages that don&apos;t fit this. Maybe it&apos;s easier to simply say high-level (focused on problem space, productivity) vs low-level (dealing with the machine as it actually is with little abstraction) o&apos;s false dichotomy This talk is not about taxonomy, it&apos;s simply about that being comfortable with a lang from each camp will bear fruit, even if your day-to-day work is in one or the other Low-level: C, C++, modula2, pascal. Only real choice today is C HL: Python, perl, ruby, haskell, lisp, C#, java
  • C and Python syntax are both relatively small, and can be left unused for a while without completely leaving the brain Popular Do not try to learn C++. It is useful only as an exercise in demonstrating to yourself you can learn anything if you try hard enough. Some people like to learn languages and read programming Reddit. That&apos;s cool. This talk is not for you so much. :) Shell scripting is easy but I&apos;ve found a real scripting language makes it much easier to grow code beyond a certain point
  • Because of this last point, C has very good debugging tools, including Valgrind, oprofile, systemtap, gdb, ddd, gprof, and the like.
  • C excels at code weight. It may be painful to write and debug, but the payoff is that ten million users will have that much more RAM for other things. Like Compiz and lolcats. When FOSS apps become popular, sometimes they will be rewritten in C! Tomboy, git porcelain
  • It&apos;s not. But all the Plumbing and infrastructure is written in C, so if you hack down the stack, you should know it. If you&apos;re not writing a kernel or plumbing, fer gad&apos;s sake write it in a HLL
  • In C the need to define everything would quickly take the fun out of such freewheeling use of collections. Exception handling makes code more compact and task focused – less “programming sit-ups” Anything you want to do, chances are someone&apos;s already done it, since writing a module is so easy. The corollary is, it may be easier for you to write it from scratch than to use their code :) No mess with .sonames (wiipresent story here) REPL&apos;s power is easy to underestimate
  • If you know Python, then Ruby code is weird-looking, but you can follow it. Many langs based on c-style syntax, so also very helpful Design Patterns are missing language features?
  • Our scm systems are rapidly improving, and this makes it trivially easy to pull down code and jump in. so pop around a little and see what other folks are doing. I&apos;ve found myself contributing to some one-person projects, and they are THRILLED someone else is contributing.
  • Bridging Ousterhout's Dichotomy

    1. 1. Bridging Ousterhout's Dichotomy to hone your prog-fu Andy Grover [email_address] [email_address]
    2. 2. John Ousterhout <ul><li>“OH-stir-howt”
    3. 3. Creator of Tcl/Tk
    4. 4. Wrote “Scripting: Higher Level Programming for the 21st Century” </li></ul>
    5. 5. The Dichotomy Two kingdoms of languages: <ul><li>System Languages
    6. 6. Compiled into machine code
    7. 7. Statically typed
    8. 8. Complex data structures & algorithms </li></ul><ul><li>Glue/Scripting Languages
    9. 9. Interpreted
    10. 10. Dynamically typed
    11. 11. No complex structures
    12. 12. Runtimes, VM, byte-compiled </li></ul>
    13. 13. I say: Learn One of Each <ul><li>C and Python </li><ul><li>Or Ruby, Ocaml, Haskell, Lisp </li></ul><li>Not C++ </li><ul><li>Are you crazy?
    14. 14. Java if you must </li></ul><li>Use Python instead of shell scripting </li></ul>
    15. 15. &quot;I am a big proponent of temporarily changing programming scope every once in a while to reset some assumptions and habits.&quot; – John Carmack
    16. 16. The World of C <ul><li>As close as non-masochists get to the “bare metal”
    17. 17. Everything Unix (esp. old stuff) seems to be written in it
    18. 18. The Linux Kernel
    19. 19. Performance*
    20. 20. Anything that needs to be smallish
    21. 21. “Getting” pointers – a big deal?
    22. 22. Edit, compile, run, crash, repeat inspires ...attention to detail </li><ul><li>Like a hand on stove inspires respect for fire </li></ul></ul>
    23. 23. “Code Weight” Weight = running time * size * installed base
    24. 24. C is not for everything Greenspun's 10th Rule: Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp.
    25. 25. The World of Python <ul><li>High-level – dicts and lists, exception handling
    26. 26. Easy, Fun libraries to do everything </li><ul><li>Installed modules in src form, just a vi away
    27. 27. Cheeseshop, RubyGems, CPAN </li></ul><li>REPL great for learning
    28. 28. Documentation and introspection
    29. 29. Easy text handling & web programming
    30. 30. Don't Repeat Yourself (DRY) </li></ul>
    31. 31. The World of Python <ul><li>Why is my python process taking 140MB? </li><ul><li>I have no idea
    32. 32. Memory is cheap, no worries! </li></ul><li>Can I use threads to leverage my many-core CPU? </li><ul><li>It will go slower. </li></ul><li>I wrote a webapp 6 months ago and now it is obsolete </li><ul><li>That was 2 major releases ago
    33. 33. You forgot your TDD unit tests, pal </li></ul></ul>
    34. 34. Comparing C and Python <ul><li>They both are awesome and they both are terrible
    35. 35. In a complimentary way
    36. 36. Knowing when to use one or the other should be pretty obvious </li></ul>
    37. 37. Benefits of knowing both <ul><li>Each language learned makes learning an additional language easier </li><ul><li>Unless it's Haskell? </li></ul><li>Or, look at code in a new language and get the gist straight-off
    38. 38. Perspective </li><ul><li>HL informs LL design patterns
    39. 39. LL understanding aids working around HLL's leaky abstractions </li></ul></ul>
    40. 40. Code Co-operation <ul><li>ctypes – trivial to call C libs from Python </li><ul><li>also, SWIG </li></ul><li>More developers using HLL/dynamic langs
    41. 41. Language Bindings are key </li><ul><li>e.g. DBus in C, most/all clients use via bindings
    42. 42. Git </li><ul><li>Could really use a libgit to enable embedded use
    43. 43. Existing wrappers exec cmdline, blech! </li></ul></ul></ul>
    44. 44. Community Co-operation <ul><li>Practice Noosphere Cultural Exchange
    45. 45. Interact with people from distant cultures </li></ul>
    46. 46. Thanks!