ppog

Not to mention that they are also referring to functional programming being used within those existing languages. Even Visual Basic contains a pretty capable functional subsystem these days, with lambdas, higher order functions and so on (albeit lacking concepts like immutability and referential transparency).

Going that extra mile was necessary to make this a big story instead of having it brushed under the carpet. It seems that the leak was known about as much as a year ago (http://www.nzherald.co.nz/nz/news/article.cfm?c_id=1&obj...), MSD were informed, but nothing was done because there was no media firestorm. By showing what was exposed, Keith Ng made the horrific impact of the leak understandable to the public and media and greatly increased the likelihood that something will get done.

Related to points 2 and 3, Microsoft didn't just make it easier to get the Windows tools, they made a tool that made it easy to write Windows programs: Visual Basic. Everyone loves to hate VB, but it was a huge factor in enabling line of business developers -- people who just need to bash out CRUD apps as quickly as possible, people who don't need the fine control of C/C++, people who want to knock together a bunch of forms rather than mastering the vast Windows or Presentation Manager APIs -- to create applications on Windows. And of course VB was also adopted by hobbyists and people creating simple utility programs, again ensuring that those programs would be available on Windows but not OS/2.

In .NET, you can just do "new StackTrace()" to capture the current stack of the calling thread. One minor risk with this may be if an optimiser has elided function calls (e.g. converted to a tail recursion). I'm not sure how realistic this is in the C#/.NET case, but having the information injected by the compiler eliminates the possibility.

Also, .NET stack traces only contain line numbers if the debugging symbols are deployed. With the attributes, the C# compiler can inject line numbers at compile time, obviating the need for symbols. Similarly, if a vendor uses an obfuscator, the stack trace will include obfuscated names but the compiler attributes will have injected the real names, making it much easier for developers to read the log files.

Finally, for scenarios like INotifyPropertyChanged, having the caller name injected at compile time is much more efficient at run-time than capturing an entire stack trace just to figure out which property setter is running. This may not a big consideration for logging, but for property setters it is definitely worth bearing in mind.

By contrast, the Register is reporting Microsoft is talking to OnLive and is 'striking a conciliatory note.' http://www.theregister.co.uk/2012/03/08/microsoft_office_ipa...

They fixed that in Windows XP. (Although in Vista they made the Start button circular so it no longer appeared to occupy the corner pixel, the entire bottom left corner did remain hot, and remains so in Windows 7.)

"Bottom line: If the main topic of conversation you have with your friends is not how you can better yourself, you need to get new friends."

Thanks, but I'm happy with the friends I have and with the kind of conversations we have. If your friends love talking about "how you can better yourself," then fair enough -- whatever works for you. On the other hand, if your friends love talking about the things they do, interesting things they've learned, neat ideas, activities, etc. then don't ditch them just because they're not talking about "how you can better yourself." You'll "better yourself" by being immersed in a social environment of new ideas and options and acting on the things you learn, not by dumping your friends and finding people who want to talk about self-improvement.

Geoffrey K Pullum has a delightful article tearing Strunk and White's prescription and examples to pieces. While there's some truth to the advice, it is often simplistically presented and ludicrously overapplied (uh, I mean, "style guides often present it simplistically, and editors often overapply it"). There's plenty of room for the passive voice, and even more so when you consider what Strunk and White consider to be passive even though it isn't.

http://chronicle.com/article/50-Years-of-Stupid-Grammar/2549...

But for a small function (which a lambda typically is), the syntactic overhead of "new Runnable() { public void run()" swamps the actual logic. When I read this version, it's hard for my eyes to find what work is actually being done because there are so many braces and brackets and words. The big deal of lambda syntax is that it lets you focus on the code that does the work (the doStuff) instead of the adapter (the "new Runnable() { public void run()") that the library needs around that code.

When I see people getting breathless about "awesome CSS-only buttons" or "cool CSS-only wallpaper," I am always reminded of the old proverb of the dancing bear: "The marvel is not that the bear dances well, but that the bear dances at all."

"Impossible matter"? What's "impossible" about it? That we don't know what it is, and that it isn't predicted by our current models, doesn't make it "impossible." It means we're going to need to extend our models, which we've been doing on a regular basis for hundreds of years. Rob Knop sums this up nicely:

"In the face of evidence otherwise, many still insist that most of the Universe must be made up of baryonic stuff that interacts with other baryons and our familiar photons. Is this not just as much hubris as insisting that the Earth, where we live, must be the center about which all the other Solar System bodies orbit?" (http://scientopia.org/blogs/galacticinteractions/2011/08/14/...)

The dark matter hypothesis seems to have a great deal of explanatory power. The antigravity hypothesis, like other MOND theories, has a good fit for the specific phenomenon it was designed to tackle, but doesn't explain a lot of the other things that dark matter does. Ethan Siegel has a good post on "What Dark Matter's Alternatives Must Do" (http://scienceblogs.com/startswithabang/2011/08/what_dark_ma...) which points out some of the stuff that dark matter explains and rival theories don't (e.g. temperature fluctuations, hydrogen/helium ratio). He does presciently note that 'antimatter has negative mass' could explain more than traditional MOND theories but claims that this impacts other well-tested assumptions such as conservation of energy.

He also has a specific article on the antigravity theory: http://scienceblogs.com/startswithabang/2011/09/dark_matter_... (and yes, he does acknowledge that "dark matter ... historically has problems for individual galaxies").

Of course, none of this is to say that the dark matter hypothesis won't eventually be disproved and go the way of Vulcan as you suggest. Ironically, though, it sounds to me like the MOND and antigravity theories are the Vulcans here: they solve only one specific problem, while dark matter fits with so much more.

Not OCaml per se, but at least one F# library makes liberal and very effective use of custom operators: FParsec, Stephan Tolksdorf's parser combinator library (http://www.quanttec.com/fparsec/reference/primitives.html). Of course, FParsec is adapted from the Haskell Parsec library, so maybe that just makes your point for you!

Classes in C# are inheritable by default, as in Java, but can be marked sealed (final). Members (methods and properties) in C# are final by default, and must be explicitly marked virtual.

This is probably a fair point about the "enterprise .NET" community, which is by nature very conservative and closely aligned to core Microsoft technologies where the guarantees of support are strongest and the developer pool the largest.

However we as a smaller shop have used F# on a couple of projects within the last year -- to embed an expression engine within an analytics product, and for the parser/analyser in our Sass plugin for Visual Studio. But I know I'd have struggled to get that technology choice into the last enterprise environment I worked in. So the lack of uptake may be more to do with the culture of "enterprise .NET" shops, more than the "broader .NET community."

Func<Action> would be a function that takes no arguments and returns an Action. The desire is to be able to specify void as the return type of a Func, so that you can use Funcs for all callbacks, instead of having to use Funcs for callbacks that return a value and Actions for callbacks that don't.

Last time I looked (early 2009), Scala compilation to the CLR was a bit of a joke. It targeted version 1.1 of the CLR, which had been superseded nearly 4 years earlier. I think the problem was with the predefined libraries. Supposedly you could get it to work with v2 but I never did.

They also did themselves no favours by having the Scala compiler dump out MSIL assembler code rather than a .NET assembly. You had to separately run the ilasm tool to get an executable. Obviously for a production environment you'd package this up in a build file, but for experimenting with the language it was a bit of a speed bump.

This is without even looking at the language features and libraries that were supported on the JVM but not on the CLR (e.g. structural types, parser combinators).

My experience may be out of date here, but the scala-lang page on .NET support is still datestamped July 2008, so I'm not too optimistic. A great pity, as Scala always seemed a great fit for the CLR and would provide some nice competition to C# and F#.

Nitpick: You're right that the C# designers don't have to worry about a JCP-like standardisation process, but they do put some effort into producing a formal language standard (I think through ECMA). Unlike earlier Microsoft proprietary languages, where the language definition was whatever the compiler said it was, the C# team do try to pin it down, make sure all the edge cases are considered, and so on. The compiler implementers try to write to this spec. They don't always succeed, but from what I read on compiler guy Eric Lippert's blog, when they do diverge, he regards that as a bug in the compiler, not an error in the spec.

That said, the standard is very much owned and written by Microsoft. You're absolutely right that they don't have to work through a JCP-like process.

Looking at that article, the slowness doesn't come from having to download the entire RSS feed. As commenters there note, If-Modified-Since means you only need to download the feed when there are changes. So in your second paragraph, you have to ping the RSS feed 10 times, but you'd only need to download it once.

Rather, the slowness seems to come from the lack of an aggregation mechanism. If I want to follow 100 feeds (e.g. 100 Twitter users), I have to query each of those 100 feeds. Even though I can query them efficiently using If-Modified-Since, that's still slower than firing off one query to find out which of those 100 feeds have updates, and then querying only those which do.

It may be unnecessary, but I don't think it's an abuse. As I understand it, frameworks like Rails use idioms like this quite extensively, and enabling code written in static languages to receive dynamic member calls is pretty much the point of having DynamicObject in the .NET framework.

That said, it's probably more relevant if you need to call the repository from DLR languages. And in that case you might as well choose to write the repository class in the DLR language, which will presumably have native support for dynamic method resolution.

Typo in the link: http://omgubuntu.co.uk

Just to add to the historical perspective... One of the Project 7 languages was a Haskell dialect named Mondrian. If memory serves, this was brought to production as a scripting language back in the .NET 1.x days, but it never really got much traction and is no longer available. The same people have continued to work on Haskell for .NET, but only as an in-house project (see http://kahu.zoot.net.nz/).

That's partly correct. The danger comes not because F# is "based on" .NET but because it can call into other .NET libraries. F# code by itself, including the F# libraries, won't create null references except in two very specific cases (see http://msdn.microsoft.com/en-us/library/dd233197.aspx). And F# types are non-nullable unless you ask for them to be nullable.

But if you call into non-F# libraries, including .NET framework libraries, then they can return null references. And if your F# code tries to use a null reference obtained in this way OO-style (e.g. making an instance method call through the reference), then that will indeed cause a NullReferenceException.

Obviously, it's easy to wrap 'dangerous' calls to return option values (F#'s equivalent of Haskell Maybe) instead of nulls -- it's a judgment call as to whether it's worth it for any given API.