I’m in the Alt.net podcast on jQuery
Mike Moore was kind enough to invite me on the alt.net podcast to talk about the recent jQuery announcement by Microsoft. Chris Brandsma, Rick Strahl, Dave Ward, Bertrand Le Roy, and Steven Harman were also on the podcast.
This was a great discussion. It was especially nice to have Bertrand during the discussion. If we had any questions about how or why Microsoft did something, we could ask him. I was happy to hear that one of the reasons they chose jQuery was because they didn’t want to write their own CSS selector functions for MS AJAX. It’s nice to see that Microsoft sees the benefit in not always reinventing the wheel. Now, any new features or improvements that Microsoft would have made to their own selector engine can be contributed towards jQuery, making it a better product for all of us.
Herding Code #18 – F# with Matt Podwysocki
We posted episode 18 last week. It’s a great overview of F# and functional programming with Matt Podwysocki. Matt has a great love for F#. We wanted to do a show about F# that was a little more than just talking about F# itself and cover more about what functional programming is and why it’s important.
Some topics we cover in the podcast:
- What is functional programming, and why should we care?
- Types of applications that would and wouldn’t benefit from F#
- How F# differs from C# 3.x and Javascript
- How F# is being used (games, scripting, data analysis and scrubbing, etc.)
- F# pattern matching
- Using F# in your C# or VB based applications today
- Getting started: F# Interactive, reading the F# source, books and resources
- Interaction with DLR
- Functional features we’d like to see in C# and VB
- Spec# and Sing#
The post containing the podcast is turning into a great resource if you are interested in Functional Programming and F#. Matt provided us with a lot of links and we’ve been adding new links as we find them. If you know of any Functional Programming or F# links, feel free to leave them in the comments here or at the Herding Code post.
Why can’t you declare a static method in an interface?
I've stated on Twitter a couple of times that I'd like to be able to declare static methods as part of my interface. My reasoning is: If an interface defines a contract in my code, why can't a static method be part of that contract?
-
public interface ITryStatic {
-
static void Foo();
-
void Bar();
-
}
I found a great answer over in this forum.
In both Java and .NET, classes can only inherit from one class but a class can implement multiple interfaces. So consider the following code.
-
public interface ITryStatic {
-
static void Foo();
-
}
-
-
public interface ITryAnotherStatic {
-
static void Foo();
-
}
-
-
-
public class Whoops : ITryStatic, ITryAnotherStatic {
-
public static void Foo() { printline("Foo"); }
-
}
-
-
ITryStatic staticWhoops;
-
staticWhoops.Foo(); //which one does it try? It doesn't matter since there's no code to run.
-
((Whoops)staticWhoops).Foo(); //Sure, but it defeats the purpose of using an interface.
Essentially the answer is: The compiler tries to run the code specified by the static method in a class. Since an interface doesn't provide an implementation details, there is nothing to run. You could, if the compiler would let you, cast the interface to the concrete type that's actually being represented. But that defeats the purpose of declaring an using an interface.
I do wonder if type inference could be used to route around this problem?
New Languages Considered Helpful
New Languages Considered Harmful
I can't disagree more with this post.(1) There's no research or study that shows that learning impedes further learning. Once you learn how to program, moving between languages becomes easier. Every language has some kind of flow control syntax, some way to declare a variable, and some way to encapsulate code. You do have to think a little differently if you switch between OOP, functional, and procedural languages. But even Scheme has an if-else statement. It doesn't take much effort to learn a new language, but it does take a lot of effort to master a programming language.
1. I think I could disagree more with this post if I really tried, but I know I disagree enough to make a post.
Modern JavaScript Development: null and undefined
In my last post on constructors and objects in JavaScript, I mentioned that the logical OR operator || was short-circuited and allowed us to set default values for arguments passed into the constructor. So we know that the argument evaluates to false if we don't pass it in to the constructor, but what value does the argument have that makes it evaluate to false?
There are three different values, or types, that a variable can have in JavaScript, null, undefined, and the value you set.
-
var isNull = null; //null type
-
var isUndefined; //undefined
-
var isNumber = 1; //neither null nor undefined, contains a value
A variable is null if you explicitly set it to the null value or if it receives a value from an expression that results in null; A variable is undefined if you declare it and haven't assigned a value to it yet. The tricky part about null and undefined is that they are equal, but are two separate types. Consider the following code.
-
var isNull = null;
-
var isUndefined;
-
alert(isNull == isUndefined);
So how do we differentiate between null and undefined variables? By using either the typeof function or the identity(===) operator. The identity operator has an evil twin (!==) that returns true if the object is not of the type you passed. The typeof function is defined in the JavaScript global object and returns a string containing the name of the type of object passed to it. The identity operator is a binary operator that compares the types of the two objects being compared and returns a boolean.
-
var isNull = null;
-
var isUndefined;
-
alert(isNull == isUndefined);
-
alert(isNull === isUndefined);
n.b. If you pass "null" as an argument to a function, typeof will return "Object", but the object will === null.
-
function defaultArgs(name, options) {
-
alert(typeof(name));
-
alert(name === null);
-
alert(name === undefined);
-
this.name = name || "unknown";
-
this.options = options || { size: 42 };
-
};
-
var instanceOne = new defaultArgs("Scott");
-
var instanceTwo = new defaultArgs();
-
var instanceThree = new defaultArgs(null, {size : 43 });
So, how does this affect the logical OR operator? Well, both null and undefined are evaluated to "false" by the || operator, but the argument is still declared in the scope of the function and you can assign a default value to it. It's important to know the distinction between null and undefined. A function call may result in a null return value, a failed function call may result in an undefined value.
VB wasn’t so bad, well kinda
From Ted Newards blog, comments from the Lang.NET language symposium.
Editor's Note: I don't know what Visual Basic did to anger the Gods of Computer Science, but think about it for a second: they were a dynamic language that ran on a bytecode-based platform, used dynamic typing and late name-based binding by default, provided a "scripting glue" to existing applications (Office being the big one), focused primarily on productivity, and followed a component model from almost the first release. Then, after languishing for years as the skinny guy on the beach as the C++ developers kicked sand on their blanket, they get the static-typing and early-binding religion, just in time to be the skinny guy on the beach as the Ruby developers kick sand on their blanket.
Oh, and to add insult to injury, the original code name for Visual Basic before it got a marketing name? Ruby.
Whatever you did, VB, your punishment couldn't have fit the crime. Hopefully your highly-publicized personal hell is almost over.
While I agree about the dynamic typing and so forth. The reason VB got kicked around was:
- The CS majors thought that it promoted bad code written by bad developers. In reality, it promoted bad code written by inexperienced developers which still managed to meet whatever dorky requirements they had for the tiny application they were writing. Which is OK in my book. You weren't writing eBay in VB, you were writing Sally's strudel recipe database.
- A complete and utter lack of pain-free inheritance. Sure you had editor inheritance, but that's no way to run a language.


