Anders Hejlsberg and Gilad Bracha: Perspectives on Programming Language Design

Download this episode

Download Video


Lang.NET Symposium 2009 was held on Microsoft's campus (make sure you watch the talks, which are available for your viewing pleasure). We were of course there and conducted several interviews with some of programming language design's brightest thinkers. Here, the great Anders Hejlsberg, father of C#, and one of my favorite language designers and personalities Gilad Bracha (you'll see more Gilad in the next few days discussing his Newspeak programming language) are interviewed by C# Program Manager Mads Torgersen (he works with Anders and others on the design of C#). Mads should consider a career in interviewing! Awesome job, man. This is a great conversation with two of the premiere programming language designers in the world. Enjoy!

See all the C9 Lang.NET conversations here. Their numbers will grow over the coming week so check back.



Available formats for this video:

Actual format may change based on video formats available and browser capability.

    The Discussion

    • aL_
      cool Smiley i watched gilads talk on hopscotch, interesting stuff Smiley i dont agere with all of his assertions but he has really interesting insights Smiley

      id love to see something with eric, his talk was great but it seemed he did a lot with his hands that didnt get captured in the video :/ that IObservable interface sounds really cool.. is it coming to .net maybe?
    • exoteric
      About Rx - yes, please let's see more about that. Eric Meijer - always fun and stimulating to watch.

      About Gilad vs Anders - always a pleasure, Gilad has a great sense of humor, as always and Anders is a seamless pragmaticist and he is of course right that Gilad can afford and should afford himself to be on the bleeding edge. I don't necessarily think he [Gilad] is right about everything (while not disagreeing or even being able to disagree) but he is quite visionary and the notion that types should be orthogonal sounds intuitive and right on the face of it - and more right than type-unsafety should be added rather than type-safety added.
    • Charles
      You will see Erik and the lead developer for Rx, Wes Dyer, in a two part series covering Rx in the near future. And, to boot, Erik will be first up in my new Lecture series on Channel 9 Wink

      We love Erik and his brilliant mind coupled with a very cool and humble personality. You will see much more Erik on C9 going forward.

      Wait until you see what we have from Lang.NET 2009 with Erik and a very special guest in the next episode of E2E... Smiley

    • Charles
      Gilad is on to something very special IMHO with respect to distributed synchronizable objects built into the fabric of Newspeak. The potential is invigorating and he is blazing very new trails. You will learn much more about this in another installment of our Lang.NET coverage. Stay tuned.

      Gilad rocks.

    • Kamujin
      I don't have the brainpower to know who's right on the static typing debate, but as someone who's written a great deal of code in static and dynamic languages for production use, I was shocked at the suggestion that static typing does not aid reliability.

      To my thinking, reliability based on code that will error at compile time is far more desirable than code that depends on developer discipline. Not because it makes coding easier, but because it frees my limited mind to be creative about far more interesting problems.

    • Charles

      One possible retort to your assertion is that the static type systems you depend on (I'm assuming you're a general purpose programmer using general purpose imperative tools) are not correct by construction in and of themselves in terms of guaranteed reliability post compilation (when it really matters; during execution). Nothing guarantees that any imperative type will be 100% reliable in execution context (you expect type A as a result of a computation, but instead get an Exception E.... Sure, you can decorate your code in exeception handlers, but this doesn't help your stated case, fundamentally)


    • Kamujin
      Let's just say that your assumptions about me are wrong and leave it at that.
    • Charles
      I accept being wrong all the time Smiley The Static versus Dynamic debate lives on and certainly I agree that knowing when you've made bad assumptions during compilation is powerful. I was just taking the more extreme theoretical position in the argument for the purposes of useful discourse.

      Most of us are GP imperative programmers (C, C++, C#, VB, Javascript, Python, Ruby, Java, etc) using related tooling. I meant no disrespect.

    • staceyw
      "Gilad is on to something very special IMHO with respect to distributed synchronizable objects built into the fabric of Newspeak. The potential is invigorating and he is blazing very new trails. You will learn much more about this in another installment of our Lang.NET coverage. Stay tuned."

      I like to hear Erik on this subject.  At one time (on C9), he talked about Remoteable types and possible IRemoteable.  I wonder where, if anywhere, that work is going.  Look forward to Erik.

      BTW-Gilad, great stuff.  IMHO, you may want to spend less time and energy on the sour grapes stuff and put that energy back into code instead.  It seems to have become a pattern in last few videos that you may not even notice.  You could have the best product in the world in design. But if it never hits the streets, does it really matter how much better it is then xyz?  As Anders says, at some point you have to ship a product.
    • punkouter
      Having always programming in static language I also not confinced with dynamic languages. I don't mean that it is bad, but for large complex systems I can't imagine how hard it will be to implement them in dynamic languages. Everytime I imagined that all I can see is pain. But then again although I did some research to an extent, I have never programmed in dynamic languages.

      The discussion here between Anders and Gilad is to me a great introductory to the design principles, but it is probably the same talks and papers that I've heard and read for the last year or two. It's just another dynamic vs static typing debate. Charles, I would really hope that in the future we can have discussions based more on real concrete examples and usages of the dynamic languages. Where can it be used as a powerfull tool. Especially on complex systems and development that involves a lot of developers (I imagine development with lots of developers will be a big problem with dynamic languages, but I might be wrong).

      All those said, thanks for the video. It sparks my interest even more into dynamic languages.
    • joechung
      It's ironic that someone whose handle is punkouter has a problem with dynamic languages.  void* is rather dynamic, void** even moreso.
    • Charles
      In all fairness, having talked with Gilad for a few years now, it's not sour grapes as much as it is simply Giladian sense of humor. Smiley

      Unlike C#, Newspeak is a virtually unfunded project at this point; without the muscle of a multi-billion dollar company backing it... You will learn more about it soon and be invited to help push it along (it's an open source project, after all).

      There are indeed some similarites between the synchronization objects of the Newspeak language and work Erik has done, but Erik's work is at the library level, not the language level and I think Gilad has taken the idea a bit further...

      You should play around with Newspeak and see for yourself.

    • dvanderboom
      There's a difference between actual reliability and provable reliability.  Gilad merely asserts that the actual reliability of programs written in dynamically-typed languages are equal to statically-typed languages.  Not sure whether that's true or not, but that distinction matters.

      Gilad is right (and Anders admits) that dynamic typing allows greater flexibility and power (at a cost).  But I think Gilad lacks appreciation for the advantages that static typing provides.  Yes, it's harder to make static-type languages perform tricks like pervasive type inference, and it's harder to implement metaprogramming, and this is due to the additional design constraints of proving reliability and safety.  But with every constraint, every proof of logical correctness, you get some advantage... like better performance.
    • punkouter

      i would not say void* (or void**) in c/c++ as dynamic. there are some similarities in behaviors but not just what i imagined what dynamic is in dynamic language. besides, even though you got a void* (or void**) on COM interfaces, chances are you are going to cast it to a static type and work with that (actually you will have to most of the time). thus reducing the point of failure to where you create the instance and when you cast it to a static type.

      one of the problem with dynamic languages (that im seeing) is that the point of failures can be virtually everywhere. and that causes me pain. Smiley

    • aL_
      @charles - about reliability

      i wonder what beckman or sylvan (the haskell fan) would have to say about this Smiley i think its pretty obvious that static typing aids reliability.. what gilad is getting at (i assume) is that static typing is not a requirement for reliability, and in principle i agree to that. in practice however, things are a bit diffrent.

      as someone who has written piles and piles of code in both dynamic and static languages i know first hand, just like anders mentions, when the applications/frameworks grow, it doesnt take long until its not humanly possible to remember every methodname and every argument Smiley the cognitive load on the programmers mind just becomes unrealisitc. gilad even says that as long as you have good programmers you'll be ok. well yeah, if you have good enough programmers you could write everything in assembly Smiley

      gilad is also right that there can be intellisense like constructs in dynamic languages and refactoring is not highly dependant on static typing, but dynamicity makes it harder to do these things.. thats the whole point Smiley - that less stuff are known by the system so that programs can be more flexible. this is true for , c# reflection, ruby, lua, or anything thats beeing run "after" its written.

      smalltalk and newspeak are interesting because they are written during runtime. runtime errors and design time errors sort of blur beucase you're running the program while you're writing it. in that case you can do things like intellisense/refactoring more easily because you know the runtime metadata -because you're running right now. there are still limits though.. Also there are  other issues with integrating the editor so closly with the program itself  Smiley

      its all a trade off imo.. there is no right awnser Smiley Gilad says in the interview that the safety of types are not worth the loss of flexibility, but thats a subjective matter Smiley sometimes it is and sometimes its not. i'm still in anders camp though, when there is no significant penalty to using types, why not use them? if a case turns up where you need the dynamicity, use a dynamic construct.

      as you say charles, you can mess up in any language Smiley -but why not use what aids are available to limit the likelyhood of that?
    • Charles
      I'm not in either camp. Each tool should be used when it makes sense in context. When you think about the web, it's clear that dynamic languages are the preferred application composition tools. The notion of reliability-for-free given static typing is questionable. That's the only point I attempted to make. Smiley

      I'm not a big fan of the Static versus Dynamic debate. There is a sweet spot and I think a language that supports both natively is an interesting concept, one that Anders et al have built into C# 4.0 with the static dynamic type.

      It's fun to debate!

    • JasonOlson
      Here's my take on what is being discussed. At the core of it, the static type checker that we know from .NET is largely nothing more than spell checker in a word processor. It tells us that the words are spelled correctly, but doesn't prove anything about the validity of the program itself. It merely says "yes, you compiled correctly."

      One of the largest impedance mismatches that has existed for all of software history is the known mismatch between the solution to a problem, and how developers have to express it to run on a computer (hence the important shift to more declarative ways of programming, versus general imperative styles we have today).

      It may sound silly, but it should be obvious to most developers that just because something compiles does not mean it actually works. I can have a perfectly spelled sentence that makes no grammatic sense whatsoever ("There upset about that? But its the best gift in the hole world."; spelled correctly but is not gramatically valid).

      So, a common trend you see in programming languages is the idea of unit tests and test-driven development. This helps developers prove a program is a valid solution for the problem wanting to be solved. And technically, if I'm doing TDD, I should have a lot of coverage of my code anyways, so why would I care about static type checking when my unit tests will cover most of those cases? Ah, but there's a catch. In the real world, I don't believe code will ever reach 100% test coverage (or very rarely), and what if the "mistyped variable" is in a code branch that is only executed once a quarter? There is obvious give-and-take so the question is whether you want to take the risk and settle for more flexible code.

      Yes, technically, static typing can be about more than just type checking. Still though, when using an imperative programming language, all the extra "goodies" will still only tell you whether the code itself is valid, not whether the solution trying to be expressed by the code is valid.

      But, both dynamic and static have their uses. As is always true with software, there's a grey area that exists, it is never black-and-white.
    • JasonOlson
      My favorite quote from Anders re: the dynamic keyword is from his PDC talk. He talks about how the variable that is declared with "dynamic" is "statically typed to be dynamic." Sounds hilarious, but it's totally true. Very interesting take the C# team took, and I think given all things, is much better than many other ways they could have gone.
    • stevo_

      I think the interesting thing about this talk is that its almost given in a way that people don't know non-statically typed languages today.. that all we do is c#.. I really disagree that static type systems limit creativity.. I program actionscript and javascript nearly every day.. as well as .net- typed systems make insurances for me that I'll well plan out my solution.. javascript and actionscript tends to allow developers to mismash anything together.. great! right?.. uh not really.

      I'm all for static languages, and giving them progressively more intelligent typing and tools so that the typing becomes as transparent to the developer as possible (see latest versions of c# and or even f#).

    • aL_
      but even unit testing dont garantee that you program is error free Smiley its just another aid for reducing errors.. 100% coverage only states that all the code is beeing run in some context but not in all possible contexts that the program can encounter in the wild.

      also, my GetFruits() method might have 100% coverage but might be totaly wrong for the banking app that im working on Smiley what i mean is that if you have a perfectly error free, 100% tested solution for the wrong problem, you've still failed Smiley

      i think us humans need all the help we can get to reduce errors. Smiley static checks where possible but not to restrictive, unit tests, system tests, code inspections, requirements engineering, its all good Smiley

      i agree with you there, dynamic is a really good compromise imo, getting the best of both worlds Smiley
    • deedubb

      I believe in that PDC talk Anders also implied that he was a strong supporter of statically typed languages. I wonder, is that still the case?

      If so, kudos to him be such a good interviewee and superb language designer... I admit I stopped looking when I found C#. It covers my needs -- 99.8% anyway.

      (Adding HTTP headers in WCF could've been a little easier Smiley)

    Comments closed

    Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation, please create a new thread in our Forums, or Contact Us and let us know.