Anders Hejlsberg and Gilad Bracha: Perspectives on Programming Language Design
- Posted: Apr 28, 2009 at 10:33 AM
- 38,779 Views
- 21 Comments
Loading User Information from Channel 9
Something went wrong getting user information from Channel 9
Loading User Information from MSDN
Something went wrong getting user information from MSDN
Loading Visual Studio Achievements
Something went wrong getting the Visual Studio Achievements
Right click “Save as…”
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.
Follow the Discussion
Oops, something didn't work.
What does this mean?
Following an item on Channel 9 allows you to watch for new content and comments that you are interested in. You need to be signed in to Channel 9 to use this feature.What does this mean?
Following an item on Channel 9 allows you to watch for new content and comments that you are interested in and view them all on your notifications page.sign up for email notifications?
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?
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...
C
Gilad rocks.
C
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.
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)
C
Most of us are GP imperative programmers (C, C++, C#, VB, Javascript, Python, Ruby, Java, etc) using related tooling. I meant no disrespect.
C
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.
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.
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.
C
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.
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.
i wonder what beckman or sylvan (the haskell fan) would have to say about this
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
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
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
its all a trade off imo.. there is no right awnser
as you say charles, you can mess up in any language
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!
C
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.
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#).
also, my GetFruits() method might have 100% coverage but might be totaly wrong for the banking app that im working on
i think us humans need all the help we can get to reduce errors.
@charles
i agree with you there, dynamic is a really good compromise imo, getting the best of both worlds
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
Remove this comment
Remove this thread
close