The Learning Curve

For the last couple of years we have given a quarterly internal class on how to write great APIs for WinFX.  One of the highlights in a class like this is the Q&A.  We built in some time for an hour+ long Q&A time with Anders Hejlsberg and I always learn something from those sessions. 

 

One of the pearls of wisdom I took away from yesterday’s class was Anders’ assertion that when the C language was developed the learning curve for most developers was 90% in learning the language and 10% in learning some libraries.  But today with C#, VB.NET, MC++, etc the learning curve is more like 10% for the language and 90% for the library.  (Well, OK, maybe it is 20% for the language in the case of C++ ;-)).  The relevant point for my class was that if most of the learning curve is in the library then to make the system easier to learn we have to focus on the library.  It is also worthwhile to think about what the implications of this assertion is on the great language debates (C# vs. VB vs C++ vs Eiffel vs Cobol vs Ruby vs Perl vs….)

 

As library designers the burden has moved to us to make the system easier to use.  In a lot of ways that is scary as the job is more diffuse across a wide range of library designers inside and outside of MS.  But the good news is that there is the design guidelines and tools such as FxCop to help.

Published 16 December 03 03:58 by BradA

Comments

# milbertus said on December 16, 2003 5:07 PM:
That's actually a really good point. I never thought of it that way before, but it's totally true. I had quite a difficult time picking up C/C++ in high school, but once I had the libraries were pretty straight forward. With .NET, C# came easy for me (due to my experience using C++ and other languages), but it took me some time to figure out how the BCL was laid out.
# Greg Wilson said on December 17, 2003 9:07 AM:
A comment and a question: 1. One of the reasons I'm sticking to Python, rather than switching to Ruby, is that Ruby's developers haven't learned this lesson (that the libraries matter more than the language). The Ruby libraries are growing in the same ad hoc, sprawling, inconsistently-named, 90%-done-but-never-finished way that Perl's and Python's did. If 90% of the learning curve is the libraries, any advantages Ruby (or other newcomers) have *as languages* get lost in the noise compared to the advantages or disadvantages of their libraries. 2. A lot of the students in the course I teach at the University of Toronto [1] have been using Java style-checking tools like Checkstyle and PMD. Now that you have guidelines for the libraries, are you (i.e. Microsoft) planning to build a tool to check conformance? Getting that out now, as part of the standard toolkit, could save you a lot of grief in the long run... (If Checkstyle or PMD had been available in first-generation releases of Java from Sun, a lot of today's Java code would be a lot more readable.) Thanks, Greg
# milbertus said on December 17, 2003 9:46 AM:
Greg, Microsoft has already developed such a tool, if I'm understanding you correctly. FxCop, which Brad linked to in his entry, checks class libraries for conformance to the design guidelines adhered to by the BCL.
# Brad Abrams said on December 17, 2003 9:50 PM:
Yes, thanks... FxCop is a great tool for this kind of checking.. http://www.gotdotnet.com/team/fxcop/
# phil said on December 21, 2003 9:14 AM:
Excellent point! Being proficient in one too many languages ... I've never felt over the past 20 years that language was the barrier. The runtime library is. Once upon a time ... (yes I feel like grampa sometimes) ... you (over time) memorized the runtime (e.g. Common Lisp -- and yes I know that with Lisp it's a blurry area between what's the language and what's the runtime). So you knew 300+ ways of doing things. Same goes with C -- but I remember the endless debates about standardizing the runtime libraries. With the advent of frameworks, templates, IDEs, editors that fill in the blanks ... well ... the requirement of having to know the runtime in order to type it into your editor of choice is, in my opinion, viewed as an option for the vast majority. This of course leads to the use of cut & paste program construction models and the endless reuse of a subset of the runtimes capabilities (I'm just as guilty as anybody else). There's no substitute for the long-term studying (and memorization) of a framework and the runtime. That's like I like printed books -- and why I really like stuff like Matthew MacDonald's cookbook / recipe approach (something I tried to do with my book on Groove).
New Comments to this post are disabled

Search

Go

This Blog

Syndication

Page view tracker