Chapter 3. Your First Language

Discuss this Chapter!

Chapter 3. Your First Language

Context: You are just starting out and have only a shallow understanding of one or two programming languages.

Problem: Your job depends on you delivering a solution that depends on a programming language. Or perhaps obtaining a job depends on your proficiency in a programming language.

Solution: If the problem dictates a programming language, let the drive toward the solution direct your learning and your choice of language. Either way, ask the most experienced and available programmer you know for ongoing help.

One of the fundamental ways to improve your experience of learning Your First Language is to have an actual problem to solve. Keeping this problem in mind helps to ground your learning in reality and provides you with your first, relatively large, feedback loop. Learning with the small, contrived examples of books and articles is limiting, and you lose the benefit of applying your discoveries to a problem you have in your head, which, after all, is what you'll be doing on the job. The fundamental way to improve this experience is to relentlessly Chapter 30, Create Feedback Loops. In particular, creating small feedback loops helps you gauge your progress. Some languages have better tools for feedback than others, but regardless of the language, you can take some steps to set up a learning sandbox for you to experiment.

In Ruby, there is the interactive command line tool irb. In Rails, there is script/console. Similarly, Erlang has erb. Firebug provides many useful ways to explore the JavaScript runtime in the browser, including an interactive shell. Sometimes tools won't suffice and you'll need a bigger sandbox. Dave likes to keep an empty Java class open in his IDE when he needs to play around with an unfamiliar API or language feature.

  
  public class Main {
      public static void main(String[] args) throws Exception {
      System.out.println(/*play with stuff here*/);
      }
  }
  
  

Once you've learned enough to actually start writing code, test-driven development techniques can help keep you focused on taking small steps and ensure you check your assumptions. Thanks to the popularity of test-driven development, you'll be hard pressed to find a language that doesn't have an xUnit testing framework. Don't hesitate to write simple tests to check your understanding of the language, or to just familiarize yourself with the testing framework. Start by taking almost insanely small steps. Here is an example in Ruby:

  
require "test/unit"

class LearningTest < Test::Unit::TestCase
  def test_my_understanding_of_blocks_and_procs
    original = [1, 2, 3]
    expected = [2, 3, 4]
    p = Proc.new { |n| n + 1 }
    assert_equal expected, original.map(&p)
  end
end
  
  

These learning tests should grow into more mature tests that check your actual code rather than your understanding of language constructs and APIs, but it is an example of how you can take some first steps toward unit testing.

The following is a discussion of learning a new language in order to help someone think differently, but Ralph Johnson's (a member of The Gang of Four) advice applies to Your First Langauge as well...

Dave's original intent for this pattern was to encourage apprentices to start with a dynamically-typed language because he believed they are good at Chapter 30, Create Feedback Loops. Dave's thoughts on this were based on his early experiences trying teaching himself Java and Perl. Reflecting on Ralph's advice helped me realize that the attributes of a language are not the only way to shorten feedback loops, and are not of primary importance. In hindsight, Dave realized that his success at learning Perl was mostly due to having a real problem to solve (keeping his job) and having experienced Perl programmers mentoring him. Contrasting this with trying to teach himself Java in isolation, without a problem to solve, and reading (not kidding) Java for Dummies as his tutorial, it is clear see that dynamic vs. static typing had little to do with the results.

Ralph's advice ties directly into Chapter 18, Find Mentors and the impact the mentors can have on your learning. Thus, the availability of the feedback of a nearby language expert should be a major factor when selecting Your First Language. We should also mention that by choosing a language you're opting into a virtual community of practice with established idioms, social gatherings and mechanisms for communication. You should take advantage of that support network so that you don't just learn Your First Language but in fact join your first community of Chapter 19, Kindred Spirits. The preferred work, boundaries, prejudices and beliefs of this community will be all you have at first. In addition to starting to learn a language you should attend meetings of a local group of that language's enthusiasts (or visit one of their internet forums) and see if it's a community that you can actually belong to.

Dig deep into your first language. Stick with it for several years. Your first language will be the framework against which you learn other languages. The better you know your first language, the easier it will be to learn your next language. Although you will primarily be using Your First Language to solve day-to-day problems and deliver functionality, periodically take some time to stretch it beyond where you would in the normal course of your work. Stretching the language in unconventional directions will help you discover where one language excels and one language struggles.

One danger of digging deep into Your First Language is getting stuck. Perhaps Your First Language will remain with you throughout your career as your native tongue. But do not allow your proficiency in Your First Language to prevent you from learning and using other languages. Chapter 9, The Long Road should introduce you to the diverse language landscape of software development. Each language provides an opportunity to solve problems using different paradigms. As you move beyond Your First Language, look for opportunities to learn languages that take a radically different approach to what you're accustomed to. Apprentices comfortable with an object-oriented language should explore a functional programming language. Apprentices comfortable with dynamic typing should explore static typing. Apprentices comfortable with server-side programming should explore user interface design. Along the way, you will certainly develop preferences for languages and problem-solving approaches, but avoid the dogmatic, religious subcultures that try to push you toward a one-size-fits-all approach. This broadening is the first small step toward the wide-ranging mastery required of a master craftsman.