sylvan | Niners | Channel 9

Expert to Expert: Harry Shum - General Purpose Search, Decision Engines and Bing
Jul 02, 2009 at 2:06 PM

I tried bing, set it as my default search provider when it came out. Switched back to google a few days ago. I really wanted it to be good, but the fact is that it just doesn't provide nearly as relevant search results for my usage.

It pained me to have to admit it, but using Bing for a few weeks I frequently had to go to google's home page to try my search terms again after Bing failed to provide anything relevant and it almost always produced better results so eventually I just had to admit that Bing, even though it may have a bunch of extra fancy stuff that google doesn't, simply doesn't stack up for plain old search so there was no point in making my life harder by not having google as the main search provider

If bing, which is beta, had a "these result suck" link that you could click to easily report crappy results I'm sure you could learn a lot.
VC 10: Stephan T. Lavavej and Damien Watkins - Inside STL
May 21, 2009 at 4:05 PM

Or as my mother used to say "When your hammer is C++, everything starts looking like a thumb"
Axum Published! Tutorial: Building your first Axum application
May 09, 2009 at 4:28 AM

This is pretty cool, but I think the semantics are overly complicated. I couldn't say that I know of a better way of doing it off hand, but I feel that there *must* be some way of making this simpler. As it stands writing agents still seems to be quite painful and clumsy, and something you would avoid doing up front, and instead do as an afterthought once you realise you need it. I think it's critical that writing agents should be as "light weight" as possible so that people write *all* their code using agents not because they necessarily believe they need them, but because they're the most convenient way of getting stuff done even when running on a single-threaded machine.

For example, there seems to be two main ways of interacting with an agent, either by just passing messages and reading from the channels, or by using request-reply ports if you want to be able to send off multiple requests and then get the reponse back while keeping track of which response belongs to which request. It seems to me that this duplication is unecessary. If you want to send multiple requests couldn't you just be required to use multiple agents, one for each "transaction" (associating a result with a given request is then trivial)? If they need to share state you could use a domain, right? I've only briefly looked at it but it does seem that the request-reply ports just complicate things and aren't actually necessary.

Also, I think first-class tuples will be very important for this, as you tend to want to make quick ad-hoc groupings of data all the time when sending and receiving messages.

The semantics and syntax of this needs to be simplified a lot to make it easier to use, it still seems that you spend far too much time and screen real-estate dealing with the details of coordination, rather than your algorithm.
Erik Meijer and Matthew Podwysocki - Perspectives on Functional Programming
Mar 26, 2009 at 11:03 AM

There is a very important difference, and it's that reference types don't prevent you from calling a method on something that's null.
In haskell, if you try to pass a Maybe String to a function that accepts a String, you'll get a type error. In C# every reference typ can be null, which means that a function that takes a string may have to make do with a null instead. There's no way of saying that you do not want to accept a null reference to a method (and get static checking for that) because there is no notion of "non-nullable references" in C#.

It seems that a lot of people, including Tony Hoare who invented null pointers and members of the C# design team IIRC, now agree that "nullable by default" was a mistake, and that regular references should not be allowed to take a null value, instead you'd have to explicitly annotate a type with a ? (or something) to indicate that this reference may be null (and there would be some syntactic construct for "unpacking" a T? into two branches, one which gets passed a T and one which has to deal with what to do if the T? was null).

To bad that changing this would probably be way to cumbersome considering existing code (e.g. the entire framework!), but there's definitely value in being able to eliminate (statically) any chance of null pointer exceptions by just splitting the two concepts "reference" and "nullable" into two parts rather than conflating them into a single concept.
Expert to Expert: Erik Meijer and Anders Hejlsberg - The Future of C#
Mar 07, 2009 at 11:51 AM

So I was going to play with the .Net 4.0 CTP and went through the huge hassle of downloading 14 separate files etc. etc., but when I actually load it up in Virtual PC the windows server installation on it asks me to activate! Is there some time restriction on the CTP or something or do I need to manually type in some key (I've looked, couldn't find one)?
Expert to Expert: Inside Concurrent Basic (CB)
Feb 28, 2009 at 4:25 AM

Don't worry, it's not a problem on your end. I've had some codec issues here lately affecting all sorts of videos.
Expert to Expert: Inside Concurrent Basic (CB)
Feb 27, 2009 at 3:46 PM

I don't understand why the "handler" has to be a separate function. Seems highly redundant. I mean look at the example, "CasTakeAndPut ... Take, Put". Why do we need a named function here? WHen else would it be called? Why not just do what Polyphonic C# did?

Actually I don't mind separating the handler (Polyphonic C# did get pretty long function headers because you specified them all "in line" with the handler statement), actually, but I don't see why it needs to be named. Also, seems a bit weird how the inputs for the various channels gets mapped to the parameter list of the handler - if you have ten of them taking different numbers of argument (including zero) of different types, then what does the parameter list for your handler look like and how long does it take you to get that right on average? Why not something like:

Asynchronous Put( ByVal s As String)

Synchronous Take() As String

When Put( ByVal s As String ), Take() As String

return s

End When

This removes the rendundant function name (and Function keyword), as well as making it obvious where each parameter comes from. In fact, we may possibly omit the type in the "When" clause since it's already declared and just say "Put(s)"? So you'd basically specify all your channels up front first, giving the types and any other modifiers (like access), and then just a short and sweet "when" clause at the end. Seems pretty clean to me:

Asynchronous Put( ByVal s As String)

Synchronous Take() As String

When Take, Put(s)

return s

End When

I think this idea is very promising, but I do think the syntax here is unecessarily clumsy... Unless someone can explain why we need all that extra stuff? Caveat: The video broke about half way through for me so maybe there's a really good motivation for this later on?
Expert to Expert - Joe Duffy: Perspectives on Concurrent Programming and Parallelism
Feb 20, 2009 at 12:21 AM

Could explain specifically what about that snippet makes it hard to "think" about it? You're just saying kinda vaguely that you can't find yourself "thinking" in it, but I don't understand what specifically is posing a barrier to you.
The way I see it that snippet is, barring syntax, pretty much identical to what you would write in any imperative language to do GUIs. I could accept that you find it harder to use a certain style of programming, e.g. functional vs imperative, but you chose an entirely imperative snippet of Haskell! I don't even see the difference between this and C# other than the extremely superficial (different syntax).

You create objects imperatively.

You set properties (e.g. text) and event handlers (e.g. on command) on those objects.

How is this a different way to think about things than C#? I just don't understand what specifically you have an issue with.
Expert to Expert - Joe Duffy: Perspectives on Concurrent Programming and Parallelism
Feb 19, 2009 at 3:53 PM

Uh, I don't see what's so bad about that? This is pretty much what you'd write in any language. Is it just that the syntax is unfamiliar? That's a fairly shallow reason to dismiss something forever.

I really don't see how that sample is in any way more complicated than the equivalent C# code. You create a bunch of widgets, and set event handlers (specified inline here, but they could obviously be named and declared separately if they were larger), what's the problem, surely this is very familiar if you've used any imperative GUI toolkit?

Honestly I thought you were being sarcastic at first, poking fun at Charles by taking something that's very similar to standard imperative programming to illustrate how simple it is, but the rest of the post indicates you're not.

And yes, Haskell is statically typed (that's sort of the point), so auto-completion works fine. There is a mode for Haskell in visual studio, but sadly it's not maintained anymore...
Expert to Expert - Joe Duffy: Perspectives on Concurrent Programming and Parallelism
Feb 19, 2009 at 2:52 PM

I think we should give people more credit. Most people probably didn't understand basic algebra before they were taught it either. I really don't think Haskell is that big of a deal compared to something like OOP with all the nuances it has. It's just that it doesn't share too much with OOP so it's not as easy to learn as "yet another OOP language", but if you think in terms of the overall effort to go from zero to OOP or zero to Haskell, I'd probably expect Haskell to win.
I was a TA at university teaching Haskell, and people seemed to have a much harder time picking up Java than Haskell if they didn't already know any programming at all (and initially, people who hadn't programmed at all did better than people who had - they just had less baggage - but after a few weeks the experienced students did start to find ways of reusing existing knowledge).

It's a challenge yes, but like I said earlier it's mostly marketing. You need to convince people to make the effort, and help them once they're convinced. But I don't really see it as that big of a problem.

Comments