Optimizing for programmer happiness

Optimizing for Programmer
Happiness
Or my seven year love affair with Ruby

Once upon a time...
Not Mine :-(

Josh Schramm
TW: @joshreedschramm
Level Seven

Today’s Talk
Why do people show up every month to talk about Ruby?
Discussion not a lecture
Mix of new people and “vets”.
Lots of opinion in these slides. References where referenceable
History, Culture (both ‘social’ and programming), unique parts of the language and
impact on the industry. Not much code

History Lesson - Founding Fathers
Yukihiro Matsumoto “Matz”
Invented the Ruby Language in ‘93, first release in
‘95
Influenced by Perl, Eiffel, Ada, Lisp and Smalltalk
Much of the culture of the Ruby community comes
from the principals Matz followed when building out
the early versions of the language

History Lesson - Founding Fathers
David Heinemeier Hansson “DHH”
Invented the Ruby on Rails web framework. First
release in 2005
Founder of 37signals (now Basecamp)
Coauthor of Agile Web Development w/ Rails
(along with Dave Thomas and Sam Ruby)
Rails was largely responsible for the rise in
popularity of the Ruby language.
Inflection point in 2006

Jim Weirich
Inventor of Rake, co-founder/early contributor to Rubygems
Was a prominent conference speaker
_why the lucky stiff
Wrote the semi-irreverent “Why’s (poignant) Guide to
Ruby”
Yehuda Katz
Co-inventor of Merb, an early Rails competitor that
merged w/ Rails. It helped introduce modularity to Rails.

The Ruby Way
“Matz is nice and so we are nice”
- Early culture of niceness, inclusiveness and evangelism.
- Lead to a spike in user groups, conferences and events (like Rails Rumble)
- Regional conferences took off (Windy City Rails, Madison Ruby, Steel City
Ruby, Great Lakes Ruby Bash)
- Evangelism gave way to great tools for learning the language:
- Ex: Ruby Koans, Try Ruby
Is this still true?

Culture of the Code
Principle of Least Astonishment (POLA)
- The language should minimize confusion amongst experienced users.
- Matz’s early driving design principle
- Confusing to whom?
Optimized for Programmer Happiness
- Inspired by POLA
- Language decisions are intended to delight the user (the programmer) even if
that has performance, verboseness or other tradeoffs.

The Rails Doctrine
Convention over Configuration
- Starts from the position of opinionated software. That most use cases in web
development are similar and we shouldn’t reinvent the wheel every time.
Push Up a Big Tent
- That said, the tool should support customization and the introduction of new
tools if people prefer / have valid use cases.
- Ex: RSpec over MiniTest / TestUnit
More: http://rubyonrails.org/doctrine/

_Why Ruby? - Dynamic
With Ruby you can manipulate or modify the program you are running as it runs.
Part of a concept known as metaprogramming.

Optimizing for programmer happiness

_Why Ruby? - Dynamically and Strongly Typed
Dynamic Typing: A variable can change type to whatever you assign to it.
Strong Typing: You cannot perform an action on a variable that doesn’t make
sense for the current type.

_Why Ruby? - Reflective
You can inspect the characteristics of a class, method, variable at runtime.
Combine this with the dynamic language features and dynamic typing and you can
make decisions about what your code should be based on what your code
currently is.
How very zen

There are no primitive types in Ruby. Literally everything you interact with is an
object of some sort. A class, an instance of a class, etc.
Contrast with .NET / Java / C where int, char, decimal and several others are
primitives, not objects
Main differences
Primitives tend to be faster to interact with, pull out of memory and copy but
immutable and inflexible.
Objects are slower, more memory but far more flexible
_Why Ruby? - Everything is an Object (Super OO)

_Why Ruby? - Lack of Ceremony
Ruby syntax tends to be clean(er) and devoid of most markers that other
languages require like semicolons or parentheses
At the same time ruby can support those things if preferred

_Why Ruby? - Domain Specific Languages
Ruby tools are usually written to be expressive and easy to read. They leverage a
concept called DSL to describe the actions the tool can take.
Ex: Rspec

Ruby and Rails’ Impact - RubyGems
One of the most comprehensive dependency management / library distribution
tools anywhere at its release.
Helped contribute to rise of social coding
Inspired other platforms: NuGet (.NET), Composer (PHP), CocoaPods
(Swift/Obj-C), NPM (Node.JS)

Ruby and Rails’ Impact - Testing
Flexibility of the language drove the rise in BDD and ATDD as a first class
practice.
Tools like: RSpec, Cucumber, Capybara, Watir
Inspired other platforms: SpecFlow (.NET), Watin/Watij (.NET/Java), Jasmine
(Javascript)

Ruby and Rails’ Impact - Web MVC
Rails implementation of a full-stack web framework designed around a Model
View Controller architecture became the standard for framework design for about
a decade.
Just now starting to see a change to this with API driven, single page apps and
functional programming.
Inspired other platforms: ASP.Net MVC (.NET), Play (Java and Scala), Laravel /
CodeIgniter (PHP)

Ruby and Rails’ Impact - DevOps
The DSL features of Rails helped spur the adoption of configurable operations
tooling. It became easier to automate the setup of infrastructure and ultimately
spawned an entire “new” category of IT.
Examples: Chef / Puppet

Ruby and Rails’ Impact - Opinionated Programming
Rails “Convention over Configuration” mantra broke down some of the stigma
associated with setting intelligent defaults in frameworks / tools.
Now most platforms package with a preferred DBMS, View Layer, Emailing Tool,
etc. even if they are customizable.
Ex: ASP.Net MVC with Entity Framework

Optimizing for programmer happiness

Recommended

More Related Content

Viewers also liked (20)

Similar to Optimizing for programmer happiness (20)

Recently uploaded (20)

Optimizing for programmer happiness

Editor's Notes