One of the most powerful and important ideas in computer science is abstraction. (At least, that’s what they told me when I took 6.001 at MIT 20 years ago, and I’ve believed it ever since…) The power of abstraction isn’t that you can do new things, but that you can think about existing things in new and different ways. In this talk, Tom Stuart introduces the idea of abstraction, and demonstrates how and why it’s so powerful, and why it allows to reason in new ways. This talk isn’t about one language, or even specifically about programming, although it does include some Ruby code to demonstrate the ideas.
The programming world has been divided for many years between advocates of static typing and advocates of dynamic typing. (Separately, we can discuss strong typing vs. weak typing.) . In this talk, Michael Bernstein teaches us what type systems, and static typing, really mean — and the advantages that they bring to the table. He then discusses how Haskell approaches types, and considers why Ruby doesn’t include any such type checking.
Even in an object-oriented language such as Ruby, there are many ways to write code. Some code styles are more in the spirit of OO than others. In this talk, veteran Ruby developer Jim Gay describes his theory of OO programming, in which we issue commands, rather than querying objects about their state. This leads, Gay says, to code that is easier to understand, debug, and maintain. If you’re looking for ways to make your Ruby (or other OO) code clearer and more obviously intentioned, this code will likely give you some insights.
How far should we go in making sure that our programs are robust? What techniques can we employ to make our code more readable? What stories can we tell via our object and method names? In this talk, Katrina Owen creates and evolves a set of programs, describing the trade-offs that we make when we create code, and what object-oriented design principles can teach us about improving our code.
Developing programs in Ruby almost certainly means using software developed by other people. This means that your software — and maybe even your business — now depends on the quality of software written by people you don’t know, and who don’t owe you any support. How can we improve this state of affairs? How can we improve the ways in which people within the open-source ecosystem improve their communication, trust, and general interest in working together for everyone’s mutual benefit? In this talk, Justin Searls describes the current state of open source, and describes different ways in which open-source contributors and their users might be able to improve not only the code, but also the ways in which that code is developed.
Everyone talks about Smalltalk in reverent tones, but not too many people actually use it. Why not? Why aren’t there lots of people using Smalltalk nowadays? And what can we learn from this, to ensure that Ruby continues to be popular? In this talk, Bob Martin describes (starting with the beginning of the universe) the reasons why Smalltalk never caught on massively, and what the Ruby community can do to ensure that it doesn’t happen there, too.
Programming in a modern, high-level language means that you don’t have to worry about memory allocation; the language takes care of it for you. But this doesn’t mean that you can ignore the computer’s memory, or the garbage collector, completely: Knowing how memory allocation works, and how you can monitor your memory use, can improve the efficiency of your programs, and the quality of your code in general. In this talk, John Crepezzi describes how Ruby uses memory, including the garbage collector — how Ruby’s built-in objects and APIs allow you to inspect your current state, and where you might end up causing trouble for yourself if you aren’t careful.
Programs are neat, and the world is messy. When we try to use software to model the real world, there is an inevitable clash. In this talk, John Feminella points to three things that are messy in real life — and that are even messier when you try to deal with them inside of your program. These things are character sets, time zones, and people’s names. His examples are in Ruby, but the problems he’s describing are universal across programming languages.
Lately, Matz (the inventor of Ruby) has been focusing, like many people in the technical world, on mobile devices. How can Ruby be used to program in an increasingly mobile world? The answer is mRuby, a mobile-oriented version of Ruby, on which Matz and others are working. In this talk, Matz introduces mRuby, and describes his considerations and thoughts on the topic. What is truly crucial to keep in the language, and what can be left out?
Would you describe your code as “confident” or “timid”? That’s not a question I had really ever considered before watching this talk by Avdi Grimm, which shows how we can write code which doesn’t have to second-guess itself or its inputs. The code becomes easier to read and more maintainable. The examples all use Ruby, but can apply to many different languages, and particularly dynamic object-oriented languages.