Sessions at Strange Loop 2010 about Programming Languages

Unscheduled

• Classes are Premature Optimization

  by Justin Love

  Classes are premature optimization, forcing the programmer to freeze method implementations and often memory layouts during the design stage in order to make things easier for the compiler writer. Classes are also accidental complexity forcing the programmer to deal with rules and limits unrelated to the problem domain, and sometimes expend extra effort working around the class system. This talk will gaze into the soul of object oriented programming to see why classes might not always be beneficial (though they often are). We'll look at alternate visions from the hard core classlessness of Self to the modern renaissance of Javascript. Finally, there will be a review of patterns for the proper application classless patterns.

  • Object Oriented Programming
  • Programming Languages
  Coverage slide deck

• How to Think about Parallel Programming: Not!

  by Guy Steele

  Anyone remember the old days, when for good performance you had to worry carefully about which register should hold which variable, and when? Sometimes we still do this to get extremely high performance from critical inner loops, especially when using specialized processing hardware such as GPUs.

  On the other hand, we have been able to write ever more complex and ever more capable software systems only by sacrificing such micromanagement and using general-purpose tools and abstractions for coding the bulk of our software. Along the way, we have discovered that code generated by automated tools often does a better job than hand-crafted code.

  And we learn to code in such a way that the behavior of our code does not depend critically on the detailed optimization decisions that we have delegated to the tools. If we want to let a compiler's register allocator have the freedom to put variables in registers, we stop writing code that takes the address of a variable, as in the C expression &myvar . If we want to allow an automatic storage allocator to do its job, we must write code that works properly independently of where an object or array happens to have been allocated, and perhaps independently of whether the object or array happens to be automatically relocated in the middle of a computation. Once we do this, we don't have to think about memory placement. Good programming language design can get us from the place where we must remember "don't use this difficult feature" to the place where it's not even on the radar screen because the language provides other, better ways to think and get things done. (Example: Java doesn't even have a way to take the address of a variable.)

  Likewise, the best way to write code for multiple processors is not to have to think about multiple processors. We need to get to the point where we worry about the assignment of tasks to processors just about as much as we worry about the assignment of data to memory---which is to say, only for truly critical portions of the code---and for the most part leave such decisions to automated tools.

  This will require further adjustments in our programming habits---adjustments that, we argue, in the end will make programs easier to understand and maintain as well as easier to run on parallel processors. The key is not to focus on a particular technology but on useful invariants. Here, as in the past, good programming language design can help to encourage good programming habits.

  • Parallel Programming
  • Performance
  • Programming Languages
  Coverage slide deck

• Mary Poppins Meets the Matrix

  by Bruce Tate

  Every foreign language you learn makes you a little smarter, and even shapes the way you think. In the Pragmatic Programmer, Dave Thomas and Andy Hunt say that a developer should learn a new programming language every year. In the upcoming book Seven Languages in Seven Weeks, Bruce takes this challenging advice to the extreme. The book, in progress, helps a developer solve a nontrivial problem in each of seven different programming languages, spanning four different programming paradigms. In this talk, Bruce will take a light hearted look through the evolution of programming languages, paying special attention to the seven languages in his book, Ruby, Io, Prolog, Scala, Erlang, Clojure, and Haskell.

  • Clojure
  • Erlang
  • Haskell
  • Programming Languages
  • Scala

• Panel: "Future of Programming Languages"

  by Douglas Crockford, Bruce Tate, Joshua Bloch, Ted Neward, Guy Steele and Alex Payne

  This panel will be moderated by Ted Neward and focus on the future of programming languages, language features, concurrency, and more.

  • Programming Languages
  Coverage video