Scott Hanselman

Are they serious about the whole "type inference is just the var keyword"? That was not at all what I was expecting...

It is interesting that 'hard' programming would ever be considered better than 'easy' programming. It might be fun to struggle through a cryptic language but isn't there more satisfaction in solving real problems?

In any case, this was a great and very entertaining video -- lots of really smart people spewing out a bunch of nonsense ;) -- Please post more!!

wow , that was cool

Presuming the content is the same that Joel and Jeff posted on the Stack Overflow podcast, I must say that I loved listening to this podcast. Contrary to your assertion, it's not content-free and highly entertaining to listen to. More podcasts featuring Rory please!

First Guy - Ya, I'm hoping he was misspeaking about the var thing. I'm not sure he 100% gets it.

sadegh - Really?

MikeC - Thanks!

Hey Scott,
Is the audio of this conversation also be available as a podcast somewhere? Either on your podcast or the Stack overflow one?

Thanks!

I love this podcast ... but personally I can't wait until you get back to the idea of the "podcast that doesn't waste your time."

There was good content here - but I didn't like having to wade through all of the blather about trying to make Joel say something bad, where Rory's daughter works, and on and on.

I don't mean to be harsh ... but frankly I don't rely on this podcast for comedy. Some offhand funny comments are fine, but this one (and some other recent ones) feel like the focus on tech is getting lost.

I wish that this podcast had undergone some editing to improve the signal/noise.

That is just my two-cents ... love this podcast and have had many good times ... I just miss the prior focus on very high content-time ratio.

You just said you *loved* the podcast so why are you complaining!? I mean you can't make every one happy.
Some people take a lot of effort to give a free podcast. So once a while Scott does a little different podcast than the usual 30 minutes and some people start bitching as if the podcast ruined their day and made them miserable. Some people get so anal about everything, I bet they are never happy. BTW, it's Rory's sister. Not that you care.

Wow.

Joel REALLY doesn't get it on type inference. And I can't believe he takes Apple to task about their programming experience being behind the times, and he's still all about Wasabi. Little wonder he doesn't know the difference between dynamic typing and type inference.

When I talked to him a couple of years ago, he insisted Wasabi wasn't a DSL, but instead a more general purpose language. Ugh. He's spent too much time talking about programming and definitely not enough time actually doing it.

-D

Hey scott,
I really like ur interviews, but cant you do anything to bring down the size of those videos.

I should've mentioned
by size i mean the file size.

Scott, I love the video. I actually would love to hear more of these type of podcast in a formal setting. Yeah, the audio was kind of sucky and the noise -- but hey, you said that up front. You didn't force anyone to listen to it.

It's great when Rory goes off on a topic, you start throwing jabs at Jeff about his lack of C programming experience, and Joel trying not to piss off the world with every comment he makes. Having you point out the flaws, weaknesses, or maybe experience and trying to put new terms in plain english is awesome! And the fun part is that you all do it out of fun and respect for each other -- it is nice to see non of you take it personally and that is what makes this show entertaining....

I'd love to hear more with Rory and iPhone and MonoTouch. You should really have him on the phone more because he brings any postcast alive with his personal style, opinions, and antecdotes to the show.

Keep up the good work!

Anon: Why are you hating on my post? The guy asked for feedback and I provided my feedback. Are you saying people cannot post here who disagree with your point of view?

I do not hate everything. I am just saying -- look, this episode is the top-of-page link on MSDN right now. I want the content in this episode. I just wanted it in a more concentrated dosage than I received it in. I am not "never happy" as you seem to say.

Peace out.

I didn't say you can't post. I disagree with what you said. If the episode is longer than normal, it is OK.. right? You don't have to listen to the whole show in one session. What does more concentrated dosage mean exactly?
What I am saying is be happy with what you get. The format of this show is not the trend. It was probably meant for channel 9.. Actually no need to continue. .. you can't please everyone. You don't like it, just delete it.

Hug it out people! :)

I second the motion for more Rory. He was great as a host of DNR, I miss that.

It is possible to do type inference on parameters in a statically typed language, with the right type system. Haskell is statically typed and has full type inference. For example, the following function in Haskell:

id x = x

Has type: "a ->a", where "a" is a generic type parameter, which means it takes one 'a' and returns an 'a'. So it's equivalent to the following C# signature:

public T id(T t);

Or consider a function like this:

incr x = x + 1

In that case, a Haskell compiler would use the fact that the "+" operator requires that its operands be part of the typeclass "Num" (don't be confused by the word 'class', typeclasses in Haskell are more like interfaces in C# than classes) to determine the signature of the function. So the compiler can determine that the signature of this function is:

Num a => a -> a

(my Haskell syntax is a little shaky so that may not be 100% correct) which means that given a type "a" which is part of the Num typeclass (i.e. implements the Num interface in C# terms), the function takes an 'a' and returns an 'a'. So the closest C# equivalent to this (assuming there's an interface called INumber) would be something like:

public T incr(T t) where T : INumber;

Complete type inference in a statically typed language is possible. It's important not to confuse "static typing" with classes and interfaces. Static typing just means that the type of all values can be determined by the compiler at compile-time, it doesn't impose a specific type structure. Haskell's type system allows it to be 100% static, but still have full type inference. In fact, F# does type inference throughout almost the entire language (I believe there are a few edge cases where types must be specified), and it uses the Common Type System of the CLR, so even without a specially designed type system, it can be done.

Btw, I strongly recommend checking out Erik Meijer's Functional Programming Lecture Series on Channel9. It's interesting lunch-time watching and it exposes us .Net developers to a side of programming we've generally stayed away from.

Yes! Thanks @Andrew! I was just about to write something similar. This "type inference" confusion really bugged me.

Joel was merely trying to say that a language doesn't need to require that types are statically defined to support parametric polymorphism, since the compiler can figure it out.

// C#
void id<T>(T x)
{
    return x
}
void foo()
{
    id<int>(5);
    id<float>(5.f);
}

-- Haskell
id x = x
id 5
id 5.0

Both of the id() functions above do the same thing, and they both generate two functions behind the scenes. In haskell, the compiler infers the type of the function that will be generated by inferring the type of the parameter passed, rather than requiring syntax to specify the type in the application of the function.

Like Joel said, what's the difference between binding a variable in a function and an assignment? :) The compiler can still tell that 5.0 is a floating point number for var x = 5.0f, as well as id(5.0f).

Joel was describing a typeless system from what I could tell. You can infer the left side but you have to specify the right side or you end up with the world of PHP , or VBScript, or Javascript. In PHP world anything can be a string (and unless it's changed since 3.x), a string not being null is still equal to true.

public MyPerson : IPerson
{
   public var Name { get;set; }
}

public class Program
{
    public static void Main(string[] args)
    {
        // On Error Resume Next
        MyPerson p = new MyPerson();
        p.Name = new NameClass("Bob");
        p.Name = "bob"; // A value type or ref? How far can we push the CLS before it ends up being a typeless (dirty!) system?
    }
}

@Chris, I think you are assuming that because no type specified in the source code that it suddenly becomes a dynamic language. That's not the case.

The example you gave would never compile in a statically typed language, because the first assignment of MyPerson.Name sets the type to be NameClass. At that point, you'd get a type error if you assigned "bob" to p.Name. Your example doesn't work for the same reasons that his doesn't work in C#:

var x = 5;
var x = "foo";

That example is a little funky though.

If C# had type inference, the following function definitions would be equivilant in C#:

// Current C#
T Foo<T>(T x)
{
    return x;
}

// Mythical C# with type inference for parameters (still statically typed!!!)
var Foo(var x)
{
    return x;
}

Both definitions of Foo are generic. Every the type is inferred at the call site. The compiler has plenty of information for Foo(5.0f) to work, but C# still requires us to use Foo<float>(5.0f).

Wikipedia has an article on type polymorphism.

Your example doesn't work for the same reasons that his doesn't work in C#:

var x = 5;
var x = "foo";

Sorry, I meant for that to be:

var x = 5;
x = "foo";

Joel was describing something along these lines, I think:

 var ElapsedTime(var x) { return DateTime.Now - x; }

 var ElapsedTime(var x) { return TimeSpan.Parse(x); }

 ...
     var time1 = ElapsedTime(someDateTime);
     var time2 = ElapsedTime(someTimeSpanString);
 ...

It's still statically typed because the compiler figures out what the types should be at compile time. The types are determined by the calling code as much as by the method itself. In a sense this does start to border on duck typing. But it should be obvious from this example that it could be workable in many cases, and in others it might be necessary to provide greater hinting for the compiler.

@Scott: Safari 4 for windows supports tab previews just like IE8 and Firefox 3.6

I took the audio form of this podcast and LOVED it! It's nice to hear some seasoned developers shoot the breeze a little and have some informed discussions without going into any kind flame war. Good stuff! While you could say that there wasn't a lot of "first hand" stuff to learn due to the "rambling", there was lots "second hand" type knowledge in this podcast and it was great.

Do more roundtable type things, that would be awesome.

i'm with Andrew Nurse on this one. I thought Joel was correct that type-inferencing can be applied very well to parameters/arguments.

I expect that Anders left this out of the design so that they would be very careful when they do introduce it, as it changes the interface of methods and thus has more ramifications for backwards compatability etc.

So it's something to be done carefully, more carefully than internal use of type inferencing, but it's definitely possible. For "existence proofs" we don't need to look at Wasabi -- we can look at O'Caml, F#, Haskell and I presume a lot of other languages.

For me, the origin of this stuff is the paper 'The next 700 programming languages' and the theoretical 'DWIM' language.