Who's afraid of dynamic typing?

If you're afraid of dynamic typing, stop. Take some time to learn a good dynamically-typed language, then take some more time to learn how some people build big production systems with it, and how they manage to do it with less effort and increased safety and reliability vs. equivalent implementations in popular statically-typed languages. Regardless of your conclusions, I can guarantee you'll increase your breadth as a developer and that your new insights will improve your effectiveness in any programming language.

So why are people afraid of dynamic typing? Maybe it's the way most people approach dynamic languages:

1. skim through some tutorials
2. write some toy code
3. reach a final verdict about their applicability to large-scale development

These verdicts are usually based on gut instinct and second-hand stories rather than on actual experience developing real systems with guidance on proper ways to use the language.

I'll finish with a story: One time a good C++ developer got excited about a dynamic language. He used it extensively for scripting and was familiar with all of its features, and he convinced the necessary parties to develop a real upcoming system in this language. But when writing the system he threw every one of his development practices out the window and half-assed the whole thing, writing incredible spaghetti code, not testing, and cramming in as many language features as he could. The project was not a complete failure, but the "obvious" conclusion was that this language wasn't appropriate for these tasks, whereas my conclusions are:

1. Be responsible. You may also use a dynamic language for scripting, but when you're building a real system you're not scripting.
2. Don't rely on static typing - it isn't there to rely on. You have to unit-test.
3. Use your language's idioms and good shortcuts, avoid the evil ones. Seek experienced guidance on this issue.
4. Don't get in over your head - before applying a language feature in production, become familiar with it. Don't worry, it'll wait for you!
   

Some articles I love on the topic:

• Python Is Not Java, by Phillip J. Eby. A great quote from it is:
  
  

  "... if you've been using Java for a while and are new to Python, do not trust your instincts. Your instincts are tuned to Java, not Python."
  

• Java Is Not Python Either..., also by PJE
• Strong Typing vs. Strong Testing, by Bruce Eckel
  

Boo and TiddlyWiki

I'm now learning Boo (as part of learning Brail). One of the most helpful Boo sites I've found is The Book of Boo - and it's a TiddlyWiki, no less!

Inversion of Control and Dependency Injection for dummies

I'm a dummy.

I've been hearing about IoC and DI for several years, but every time I tried to figure out what they were the explanation was either too complicated or so trivial it didn't make sense (i.e. what is it good for?)


Now I understand. Thanks, Simone! Even more accessible than Martin Fowler's explanation, and that's saying a lot!

Here's the way I get it:

I. IoC happens when you use code that calls your code, such as whenever you use any framework. That means it's just a buzzword to fling at friends, but a really cool one. (Why do people insist on giving cool names to simple techniques? Oh well, Eddie Bravo does it too.)

II. You often program against interfaces instead of specific implementations.

interface Foo { ... }
interface Bar { ... }
class Alpha : implements Foo { ... }
class Beta : implements Bar { ... }
class Charlie {
  Charlie(Foo foo, Bar bar) { ... }
}

Charlie c = new Charlie(new Alpha(), new Beta())

DI happens when instead of choosing the concrete classes yourself you let a repository, called a "container", handle it for you.

// register implementations for Foo and Bar (could
// be done in a config file)
container.register(Foo, Alpha)
container.register(Bar, Beta)

// Create a Charlie - the container detects it
// needs Foo and Bar implementers for the constructor
// and chooses Alpha and Beta
Charlie c = container.createInstance()

When I needed to interchange different implementations I used to write it by hand, but no more - these containers are much better! Since they're general and easy to use, I have a feeling I'll be using them in cases I didn't bother with before.

Distributed version control

(I'm still trying to figure out DVCS)

I love version control. I started with CVS and moved to Subversion. I loved having Pragmatic Version Control using Subversion when I was making the move. If you write software and you don't use version control, c'mon!

I don't know my way around distributed version control systems, though.

I became interested in distributed version control a few years ago when a good friend recommended darcs. I've played with it and other systems including Mercurial and Bazaar, and I've read a lot of blog posts and opinion pieces, but I've never actually wrapped my head around how to effectively use them in the contexts I'm used to. Maybe I'm just stuck in the wrong contexts.

If anyone's reading this and can help me, I'm all ears.

Linus's great tech talk on git made me feel I understand distributed version control a little better, but I still don't see the relevance. To make it clear, I'm not claiming my ignorance is a virtue. I guess I'm just slow on this.

I have been able to discern the following benefits:

• No required master repository, all branches are equal
• Trivial branching, easy merging (including cherry-picking)
  
• Can work offline
• Performance for local work isn't affected by the network
  

Am I missing anything important?

What I find interesting is that most of these issues are irrelevant for the corporate environments I'm used to, where everybody's working on a LAN, committing to a central trunk is fine (constant integration, and good unit tests prevent breakage), and the branching model is intentionally simple and reduces merging because in many cases merging will be hard regardless of the tools (think heavy refactoring).

More good links:

• Jeff Atwood on branches
• Wincent Colaiuta explaining "Why Distributed Version Control"
• Perforce's "Best Practices in SCM" (a little long)