Bridging Ousterhout's Dichotomy
Upcoming SlideShare
Loading in...5

Like this? Share it with your network


Bridging Ousterhout's Dichotomy



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.

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.



Total Views
Views on SlideShare
Embed Views



0 Embeds 0

No embeds



Upload Details

Uploaded via as OpenOffice

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
Post Comment
Edit your comment
  • I'm actually filling in for the original presenter, who chose this presentation's title. I was a little confused by it. You don'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't fit this. Maybe it'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's false dichotomy This talk is not about taxonomy, it'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's cool. This talk is not for you so much. :) Shell scripting is easy but I'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'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're not writing a kernel or plumbing, fer gad'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'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'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've found myself contributing to some one-person projects, and they are THRILLED someone else is contributing.

Bridging Ousterhout's Dichotomy Presentation Transcript

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