Description

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.

The Discussion

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

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?

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.

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

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)

I accept being wrong all the time 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.

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

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.

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.

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

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.

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 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 the cognitiveload 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

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

its all a trade off imo.. there is no right awnser Gilad says in the interview that the safety of types are not worth the loss of flexibility, but thats a subjective matter 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 -but why not use what aids are available to limit the likelyhood of that?

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.

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.

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.

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.

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

but even unit testing dont garantee that you program is error free 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 what i mean is that if you have a perfectly error free, 100% tested solution for the wrong problem, you've still failed

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

@charlesi agree with you there, dynamic is a really good compromise imo, getting the best of both worlds