Monday, September 10, 2007

The Curve is a Circle

Jim and I have talked about this at length, and considering our obsession with meme-fabrication, this is one we both felt the need to discuss.

The phrase "the curve is a circle" is one we concocted to deal with the inadequacy of the illustrative ability of the term "learning curve" to describe the movement from beginner to expert. Such a viewpoint cannot appreciate the actions of one who has surpassed such sophomoric phases and ascended to the ranks of utter simplicity. Such states are almost Zen-like - moving along the circle only to discover there is no active difference - only an epistemic one. Sometimes the beginner and expert find themselves in agreement, where the intermediate believes himself superior to both. Consider the example JW gives: moving from plain text editor, to fancier IDEs, eventually venturing back to plain text editors. Corinthians 13:11 didn't quite have it right - sometimes being a man requires embracing childish things.



So how can one tell what side of the circle someone, or yourself, is on? That's the bad news. Unless you are on the other side it's damn near impossible to effectively argue a point to one on a different cycle. And believe me - it doesn't do well for an argument to declare, "you just don't understand the situation - I'm so far ahead I've lapped you." It's a good way to get punched in the face.

It's not new or a leap to say that the very language of a discussion has a different meaning depending on your point of view. This really makes communication difficult between an expert and sophomore - a little knowledge is a dangerous thing.

Here is an illustration of a conversation between me as a beginner and you as someone with intermediate knowledge on static versus dynamic typing.

You: Static typing is awesome!
Me: Dynamic typing is better.
You: How do you figure? Static typing gives compile-time checks.
Me: But, dynamic type is easier to code in.
You: Static typing is safer for large development teams.
Me: Yeah, but uh, dynamic is easier?
... ad infinitum ...

Now, let's say you make a claim as an expert - and I make a counter-claim as an intermediate fan of static typing.

You: Dynamic typing is awesome.
Me: No, static typing is the best. You are a n00b.
You: I like dynamic-typing because it makes it faster to develop and manage code. Once the use-cases are satisfied, you'll find a lot of unnecessary time that would have been spent on static-type frameworks has been saved.
Me: Static typing is safer for large development teams.
You: Yeah, I know - but without all of that overhead (and frameworks) to manage types, you don't need as many developers involved in a project - so you don't really need to worry about team size.
Me: Naw - they'll get bigger eventually - you've just worked on trivial projects.
You: No, Eric, you are an ass - I've worked teams of various sizes.
... and scene ...

In both cases, the fan of static typing is an intermediate level, while the dynamic typing fan is a newbie in the first (unable to articulate his position) and expert in the second (able to make an experienced, non-theoretical case). But look at it from the static-typing fan's perspective: they're both wrong, and both inexperienced. The curve is a circle.

Of course, maybe this is all just hypothetical.

4 comments:

witkamp said...

Hey Eric,
Can you show me a abstraction that can't be statically type checked?
Isn't that the real test ?

Eric said...

No, I don't think so. I think the real test is: which is the cheapest way to develop software that satisfies the business case?

Considering that the majority of software projects never get off the ground-floor, I propose that speed of initial development cannot be stressed enough. If more projects showed progress earlier it makes sense that fewer projects would be shut down mid-development.

And yes, I stress that dynamically-typed (Object Oriented) languages are faster to develop in initially - in the long-run saving money.

jimbojw said...

> Isn't that the real test ?

For me, these are the real tests:

1. Lines of code - less is better (this includes configuration files, manifests and anything else required to run the thing).

2. Hackability - how easily can something (anything) be changed if need arises?

I think Eric wisely chose not to engage in the infinite loop of example/counter-example.

In the world of software development, nearly everything is "possible" with nearly every language, given enough time and code. The goal is to reduce both.

Greg said...

I really like the way you've composed this; leaving it at the "all of that overhead (and frameworks) to manage types" stage rather than going on to the "overhead vs safety depends on your project" or "static typing doesn't require overhead and frameworks, get over Java" stages really emphasizes that you can't tell which part of the curve you're on, even when you think you're at the end of it.

But eventually, I have to disagree with you. I don't think it's really a circle, cf "Blub programmers". Also, some people jump straight from stage 2 to stage 5, but later might revert to 4 when their tools are limited.