Article Discussion
In the Spirit of C
Summary: Veteran developer Greg Colvin traces the evolution of C, C++ and Java with an eye to a better future.
22 posts.
The ability to add new comments in this discussion is temporarily disabled.
Most recent reply: August 11, 2004 6:29 PM by Walter
    Chuck
     
    Posts: 32 / Nickname: cda / Registered: February 11, 2003 0:06 PM
    In the Spirit of C
    June 20, 2004 8:00 PM      
    Veteran developer Greg Colvin traces the evolution of C, C++ and Java with an eye to a better future.

    http://www.artima.com/cppsource/spiritofc.html
    • Michael
       
      Posts: 1 / Nickname: maengden / Registered: May 20, 2003 8:54 AM
      Re: In the Spirit of C
      June 22, 2004 9:23 AM      
      Ah the memories of why started down this path in the first place.

      My personal trek started in '87 with the minor battle of Object C vs. C++ (grad student in Mathematics doing non-linear dynamics on a Next prototype...type safety verses the elegance of Smalltalk...) and took me through most all the ordeals surveyed. I reluctantly jumped off the C++ boat for Java just as it was becoming standardized and generic programming better understood.

      I want to point out that the spirit lives on in an odd corner: the Javascript branch of the language tree. Though branded a bastard child because of the torching it took in the browser wars and hindered by a horrific misnomer, the language proper (calling it ECMAScript helps avoid some of the most embarrassing moments) is an elegant re-simplification of C to the typeless world of script-oriented languages (i.e.: perl and company). In this strange lange, instead of everything being a word or a byte or a pointer, everything is a number, string or object reference and loose typing thrives again and the programmer is trusted. If only the object-oriented features were more transparant...

      Thanks for a both insightful and pleasent refresher.
    • Isaac
       
      Posts: 51 / Nickname: igouy / Registered: July 10, 2003 7:42 AM
      Re: In the Spirit of C
      June 22, 2004 0:12 PM      
      BCPL is available for various platforms from
      http://www.cl.cam.ac.uk/users/mr/BCPL.html

      Try typeless programming with BCPL & MCPL.
    • Jason
       
      Posts: 1 / Nickname: zappini / Registered: January 28, 2003 10:41 AM
      Re: In the Spirit of C
      June 22, 2004 2:41 PM      
      ...the lack of stack-allocated objects can make it more difficult to manage resources other than memory.

      The correct answer is "escape analysis". C#'s notion of stack-allocated pseudo-objects is a brain-dead idea.

      I do agree with the bits about Java's concurrency being problematic. And Java's generics are beyond redemption.
    • Sean
       
      Posts: 1 / Nickname: scorfield / Registered: February 29, 2004 7:27 AM
      Re: In the Spirit of C
      June 22, 2004 8:55 PM      
      It's great to see an informed view of the trade offs involved in the evolution of C++!

      I remember BCPL with a fair bit of fondness and did a lot of C and then C++ programming over the years but I've been off the scene for a while (I pretty much switched to Java in '97/'98 although, frankly, I've never really enjoyed Java as much as I enjoyed C++).

      The 'optional template' idea is intriguing... One of the issues there is the 'implicit type' syntax problem - one of the reasons why we removed the 'implicit int' rule from C++ (following the lead of the C Standards committee) but, assuming that could be solved, it would certainly do away with quite a bit of syntactic baggage!

      I'm looking forward to future material in this series.
    • Daniel
       
      Posts: 1 / Nickname: danjames / Registered: June 23, 2004 9:30 AM
      Re: In the Spirit of C
      June 23, 2004 1:41 PM      
      I think including Java in an article about the Spirit of C is probably unfair, it's designers were trying to move away from it. Guy Steele once said:

      "we were not out to win over the Lisp programmers; we were after the C++ programmers. We managed to drag a lot of them about halfway to Lisp."

      http://fishbowl.pastiche.org/2004/03/17/halfway_between_the_gutter_and_the_stars

      Of course, basing a programming language on one that you don't even like, is not going to produce the best results.
    • Andrew
       
      Posts: 1 / Nickname: andrewb / Registered: June 22, 2004 3:35 AM
      Re: In the Spirit of C
      June 22, 2004 7:39 AM      
      The author appears to be describing the kind of static type system which languages like ML and Haskell have had for ages. They are strongly typed (as in, all type errors are caught at compile time, rather than hanging around to runtime) but the compiler automatically infers almost all of the types itself. Writing "generic" functions becomes easy, since you have none of the syntactic mess of C++ and the "generic-ness" falls out for free.
      • Greg
         
        Posts: 9 / Nickname: gregc / Registered: June 23, 2004 5:24 AM
        Re: In the Spirit of C
        June 23, 2004 9:36 AM      
        Yes -- ML and Haskell are exactly what I had in mind.
        • Arkadiy
           
          Posts: 2 / Nickname: arkadiy / Registered: July 2, 2004 6:38 AM
          Re: In the Spirit of C
          July 2, 2004 10:53 AM      
          Looks like the ability to practice "typeless" programming is somewhat addressed with the typeof/decltype/auto facility that is currently being discussed by the C++ standard committee...
        • Chris
           
          Posts: 3 / Nickname: cdutton / Registered: July 20, 2004 9:25 PM
          Re: In the Spirit of C
          July 21, 2004 1:39 AM      
          Though I certainly appreciate the way types are handled in Haskell and ML, I wonder if that is consistent with the other four concepts which described The Spirit of C.

          Neither of these languages is truly typeless. In fact, they're strongly typed, and can be rather rich in different types. The fact that a programmer doesn't have to explicitly declare the types doesn't mean that he or she doesn't have to be concerned about them.

          Perhaps more importantly, it clashes with the idea of trusting the programmer and offering freedom. In C, I would be free to, perhaps unwisely, cast an arbitrary memory address to an arbitrary data type. My knowledge of ML may be lacking, as I've only recently begun experimenting with O'Caml, but it doesn't seem that such a thing is possible with the type system that exists there.
    • Todd
       
      Posts: 27 / Nickname: tblanchard / Registered: May 11, 2003 10:11 AM
      C++ - the wrong turn
      July 21, 2004 8:54 PM      
      I love C - economy of expression - bare bones - spartan - portable assembly. Brilliant language.

      Two different individuals set out to add OO capabilities to C. One focused on bringing the dynamic typing and message sending features of Smalltalk. The result was Objective C, the core of the vaunted NextStep development system (and now of Mac OS X). Objective C is a tiny and elegant extension to C with astonishing flexibility and provides useful strategies for typing errors at runtime (doesNotUnderstand: messages).

      The other focused on text processing tricks along the lines of the C preprocessor and paid excessive attention to preventing rather than dealing with type errors. This approach imposes a rigidity on code that results in developers working extra hard to pacify the compiler rather than focusing on the problem domain at hand. While C++'s generics are an interesting feature for implementing high performance algorithms, dynamically typed language users do without them simply because they don't need them to work around their type system.

      Java is simply C++ taken too far.

      What I find most interesting in the hoopla around various new tools such as scripting languages and web services is the drive to replace the loose coupling that the C++ model strives to eliminate. It begins to look like a very silly game to the dedicated Smalltalker who starts out with a language based on loose coupling in the first place.

      C++ was a wrong turn in language design. Its time we recognized that and began working towards more flexible software construction environments that encourage experimentation and innovation rather than punishing the developer for the slightest error. With laptops starting at 1GHz, I could give a fig about performance.
    • Bruce
       
      Posts: 5 / Nickname: beckel / Registered: June 3, 2003 6:54 AM
      What is the definition of "typeless"?
      July 26, 2004 2:35 PM      
      I really appreciate this article and look forward to reading the sequels.

      I never paid much attention to B or BCPL because I assumed they were just variants of C, so I was unaware that their typing system was so different.

      However, you introduce the term "typeless" without defining the term. I've learned through long study that a language that allows you to give function arguments without specifying the type can have very different meanings and behaviors. I can only guess that since this is a C-like language, everything is determined at compile time, like C++ templates. But does "typeless" mean that all variables are of a single unified type, or does some kind of type inference take place to figure out if something is an int, long, float, double, etc.? Or is it something else? I'd really like a more specific definition of "typeless."
      • Greg
         
        Posts: 9 / Nickname: gregc / Registered: June 23, 2004 5:24 AM
        Re: What is the definition of "typeless"?
        July 31, 2004 3:12 PM      
        By "typeless" I just meant the ability to code without explicitly declaring types. I B this was possible because there was really one underlying type, the machine word. In C++ this might be possible by reusing the type inference machinery.
        • Gregg
           
          Posts: 28 / Nickname: greggwon / Registered: April 6, 2003 1:36 PM
          Re: What is the definition of "typeless"?
          August 3, 2004 8:09 PM      
          > By "typeless" I just meant the ability to code without
          > explicitly declaring types. I B this was possible because
          > there was really one underlying type, the machine word.
          > In C++ this might be possible by reusing the type
          > e inference machinery.

          In most cases it is a decision of when the language will bind the value to a type. I designed a language in the early 1990s that used the value of the expression to assign type. The type was then carried with the value and used in future expressions to manage the semantics of its use.

          So you might write:
          integer i = 3;
          

          and that would allow i to only reference integer valued values, and the value 3 would be assigned to it. But, you could also just write
          i = 3;
          

          if you didn't need to type restrict i. At runtime, all the type checking made sure that the correct thing was done. This complicates the runtime environment from the perspecive that it has more overhead for expression evaluation. But, it frees the programmer and the code to be more expressive. Thus, a functional expression engine might have methods such as the following.
          func add(a,b) 
             return a + b;
          end;
           
          func mult(a,b)
             return a * b;
          end;
          

          As expressions are recognized and need to be evaluated, I don't have to have an add(integer a, integer b) and other such type specific versions. I just need the one version. The type checking is still done, its just that the types are not bound until entry to the method and thus the type check is not performed until the '+' is evaluated.

          This is placing a lot of trust in the programmer. What happens with this type of programming over a long time, is that inadequate test cases can cause changes that break the application to not be found at first. Then, someone else introduces the execution path that demonstrates the bug, but is sure they did not change anything related.

          So, a lot more runtime testing has to be in place. Coverage analysis was an integral part of my language so that we could see what code had and had not been executed after our lab/test sessions.
    • Nathan
       
      Posts: 1 / Nickname: ncm / Registered: June 26, 2004 10:34 AM
      Re: In the Spirit of C
      June 27, 2004 7:40 AM      
      (Was it really in Santa Cruz where Erwin demonstrated his compile-time prime filter? I seem to recall King of Prussia, Pennsylvania, or maybe Kitchener, Ontario.)

      I found the article far too kind to Java. Had Java come along before C++, many of its design mistakes could be forgiven. Given full hindsight, though, there can be no excuses.

      C++ "exception declarations" were recognized early as a mistake, but incorporated into Java nonetheless in even more intrusive form. (In C++ they can be ignored; not so Java.) Real C++ exceptions work well to reduce error-handling clutter, but in Java they actually increase clutter. C++ destructors, combined with template techniques, make it possible to encapsulate management of any kind of resource -- enough so that I have not needed to code a "delete" statement in many years. Java handles memory invisibly, but all other resources must be managed manually, C-style. C++ got the default "virtualness" of member functions right; Java got it wrong, so that Java classes, by default, expose much more of their implementation. Haste is a disastrous ingredient in language design.

      The designers of Java, freed from compatibility constraints, had a golden opportunity to correct many of the problems inherent in C, and incorporate the power of C++ while leaving behind much of its complexity. They squandered that opportunity. C# designers had the same opportunity, again, and (given the greater hindsight) did even worse, retaining even many of the failed choices from Java. D did only a little better.

      I call them "cargo-cult languages". Their designers copied features from other fashionable languages, but without understanding. They are the language equivalent of those shareware CDs that used to be described as shovelware. They are full of features, tossed into a bag with little thought given to how the features will interact.

      A true successor to C++ is dearly needed. We need a language that leaves behind C's promiscuous conversions, its chaotic declaration syntax, its gratuitous undefined behaviors, its ill-thought-out library. We need a language that leaves behind C++'s name-lookup complexity, its awkward compile-time pattern-matching and expression syntax, its unfortunate library history. These other languages are only distractions.
      • Jeroen
         
        Posts: 3 / Nickname: jwenting / Registered: March 2, 2004 8:00 PM
        Re: In the Spirit of C
        June 29, 2004 3:36 AM      
        One person's fault is another person's pet feature.

        IMO Java got exceptions right in forcing them to be handled.
        It's far too easy in C++ to just gloss over whatever problems are reported by functions and let someone else in the future wonder why the application keeps crashing who doesn't have the source of the function that throws the hidden exception.
        Just a little example...

        Again with exposure of implementation, it's all a design choice. You like it or not, that's up to you.
        Which you prefer is up to your own pettiness, calling anything anyone else prefers wrong shows that pettiness and the shortsightedness of your own views more than anything else.
        Maybe default access should better have been private, but then something else would have bugged you. Most likely the extra syntax needed to expose features to other classes.

        C++ is IMO suffering from extreme feature creep. It's now so large and monolithic that it's impossible to learn the entire language on even one platform and portability is almost impossible to achieve as a result.

        You seem to consider everything BUT C++ to be fundamentally flawed while in effect most of the world seems now of the opinion that pretty much the reverse is true.
        Learn to live with it...
      • Greg
         
        Posts: 9 / Nickname: gregc / Registered: June 23, 2004 5:24 AM
        Re: In the Spirit of C
        June 27, 2004 7:20 PM      
        As I recall Erwin presented his proof of template Turing completeness at Santa Cruz, but I may well misremember.

        As for java, I did hint that it had foolishly given up one eye in extremis. Still, I have seen a lot of good work by people I respect who choose java over C++ for some purposes.
        • redguard
           
          Posts: 1 / Nickname: redguard / Registered: June 29, 2004 2:53 PM
          Re: In the Spirit of C
          June 29, 2004 7:06 PM      
          Hi,Greg Colvin :
          I am a programmer in China. I like your article and want to translate it. Maybe it will be published in CSDN (most popular programming magazine in China). I need your permission before translation.

          My Email:
          chb_sh@hotmail.com

          Regards
          redguard
      • Walter
         
        Posts: 5 / Nickname: walterb / Registered: July 22, 2004 8:48 AM
        Re: In the Spirit of C
        July 22, 2004 0:54 PM      
        > [...] D did only a little better.
        >
        > I call them "cargo-cult languages". Their designers
        > copied features from other fashionable languages, but
        > without understanding. They are the language equivalent of
        > those shareware CDs that used to be described as
        > shovelware. They are full of features, tossed into a bag
        > with little thought given to how the features will
        > interact.

        I'd be interested if you'd like to present a more concrete critique of D. There's not much I can respond to here.

        > A true successor to C++ is dearly needed. We need a
        > language that leaves behind C's promiscuous conversions,
        > its chaotic declaration syntax, its gratuitous undefined
        > behaviors, its ill-thought-out library. We need a
        > language that leaves behind C++'s name-lookup complexity,
        > its awkward compile-time pattern-matching and expression
        > syntax, its unfortunate library history. These other
        > languages are only distractions.

        Would your language look like C++, or be something completely different?
        • Nathan
           
          Posts: 3 / Nickname: nathan2 / Registered: August 2, 2004 3:38 AM
          Re: In the Spirit of C
          August 10, 2004 10:45 AM      
          >
          > I'd be interested if you'd like to present a more concrete
          > critique of D. There's not much I can respond to here.

          I looked into D at one point, after reading about it in Dr. Dobbs Journal. While reading the newsgroup about it, I got the impression that the designer just wanted a native code version of Java. He had included templates only because there was imense popular support for them, and would not budge on his refusal to provide scope bound objects. He claimed to like using 'finally' clauses instead of destructors, and he felt that only memory management and thread syncronization were important enough resources to justify language level support for managing. That convinced me that I didn't want anything to do with the language.
          • Walter
             
            Posts: 5 / Nickname: walterb / Registered: July 22, 2004 8:48 AM
            Re: In the Spirit of C
            August 10, 2004 4:18 PM      
            > I looked into D at one point, after reading about it in
            > Dr. Dobbs Journal. While reading the newsgroup about it,
            > I got the impression that the designer just wanted a
            > native code version of Java. He had included templates
            > only because there was imense popular support for them,
            > and would not budge on his refusal to provide scope bound
            > objects. He claimed to like using 'finally' clauses
            > instead of destructors, and he felt that only memory
            > management and thread syncronization were important enough
            > resources to justify language level support for managing.
            > That convinced me that I didn't want anything to do with
            > h the language.

            Since D has long had templates in many ways more powerful than C++, and has scoped destruction of variables (the 'auto' storage class), the issues you raised are history. (D has very little in common with Java beyond a shared heritage of C++.)
            • Nathan
               
              Posts: 3 / Nickname: nathan2 / Registered: August 2, 2004 3:38 AM
              Re: In the Spirit of C
              August 11, 2004 7:41 AM      
              >
              > Since D has long had templates in many ways more powerful
              > than C++, and has scoped destruction of variables (the
              > 'auto' storage class), the issues you raised are history.
              > (D has very little in common with Java beyond a shared
              > heritage of C++.)

              I'll have to look into it again. When I was reading the news groups, I was hearing "never" for the auto storage class. I wonder if Nathan Myers was reacting to an old version too.

              Nathan Holt
              • Walter
                 
                Posts: 5 / Nickname: walterb / Registered: July 22, 2004 8:48 AM
                Re: In the Spirit of C
                August 11, 2004 6:29 PM      
                D is a young language, and is rapidly evolving much like C++ did in its early days. It moves in the direction that the D community wants it to go. There isn't any holy writ that comes with it <g>.