The Learning Curve


style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">For the last couple of years we have
given a quarterly internal class on how to write great APIs for href="http://msdn.microsoft.com/Longhorn/">WinFX. style="mso-spacerun: yes">  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 href="http://www.microsoft.com/presspass/press/2001/apr01/04-11AndersPR.asp">Anders
Hejlsberg and I always learn something from those sessions. style="mso-spacerun: yes">  "urn:schemas-microsoft-com:office:office" />


style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"> 


style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">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. style="mso-spacerun: yes">  But today with C#, VB.NET, MC++, etc the
learning curve is more like 10% for the language and 90% for the library. style="mso-spacerun: yes">  (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….)


style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"> 


style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">As library designers the burden has
moved to us to make the system easier to use. style="mso-spacerun: yes">  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 href="http://msdn.microsoft.com/library/en-us/cpgenref/html/cpconnetframeworkdesignguidelines.asp">design
guidelines and tools such as href="http://www.gotdotnet.com/team/fxcop/">FxCop to
help.

Comments (5)

  1. milbertus says:

    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.

  2. Greg Wilson says:

    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

  3. milbertus says:

    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.

  4. Brad Abrams says:

    Yes, thanks… FxCop is a great tool for this kind of checking..
    http://www.gotdotnet.com/team/fxcop/

  5. phil says:

    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).