SeveredCross

Because the chemical in this case is something we have all the necessary things to produce.

I can't make energy (ie. food) from no input, but with some energy expenditure, my body could carry out the set of reactions to convert glucose (which is readily available in the diet) to Vitamin C.

Jurors are selected based on all sorts of things.

You'll find that jurors with higher education are often eliminated (prosecutors hate educated jurors, they tend to be harder to convince), jurors with law experience (even if it's as simple as a law class in high school) also tend to be eliminated, because they know at least a little something about standards of proof and nullification, etc.

The list of things that you can be eliminated for by either the judge or one of the attorneys (who get a limited number [3, I think] of eliminations) is staggering.

I disagree with the author when he says that "RPG, in the context of video games basically means quest based game with turn based combat." IMO, this is extremely narrow-minded, and entirely sidesteps the most important part of the RPG acronym: the R and P, standing for role-playing.

That said, just role-playing is not enough to make an RPG (otherwise, all games would be RPG's!). To say Zelda is anything other than an RPG is narrow-mindedness at best, and intentionally misleading at worst.

The list of people who didn't already know this is very, very short.

It was a joke, lighten up. For what it's worth, I'm a .NET developer and think it's awesome.

Well…I think Roslyn will be good, but I think it's reaching to say it must be because the MS team themselves will use it.

After all, these are the same people who invented (and used!) MFC, long known as the Microsoft Frustration Classes.

I agree with all of your points, though the only one I can address is the LINQ for source code quip and amend it somewhat to an already possible "LINQ for codebases." It should, in theory, be just a few weekends worth of work to use Mono.Cecil (https://github.com/jbevain/cecil) to provide a nice queryable API to inspect an (already compiled) codebase. I'm sure some nice static evaluation tools could be written based on this that nobody's thought of yet.

That said, being able to inspect the source-code pre-compilation is a whole other level above and beyond—as a fan of the compile-time safety that statically-typed languages provide, any opportunity to eliminate bugs and complexity before the code makes it to a customer is a welcome one, and if Roslyn is good, it could be huge.

I loved this book. If the movie is half as good, I'll love it too.

Linking is done on the target box, and not on the distcc builders, so link-time optimization should be unaffected.

I suspect that they wouldn't be that stupid. That would alienate sizable parts of the Skype userbase. Microsoft is stupid, but not that stupid. This seems like pure paranoia to me.

I think I should've been more specific—I know that the two interact, but I wasn't sure if they /react/. That is, would collision between photons and antimatter produce the same sort of decay as matter-antimatter collision. Some research suggests that it indeed would.

Possibly with something like http://en.wikipedia.org/wiki/Laser_cooling, where you're not actually striking it with matter, but only with photons, though I don't know if photons react with antimatter (I presume not, but I am not a particle physicist).

I invariably find myself doing this in C projects because not doing it is a serious violation of DRY--writing possibly hundreds of lines of free (foo->bar); free (foo->baz); free (foo->quux->fnord); ... ; free (foo) is not only hugely error prone, but a waste of everyone's time.

Actually, it covers all implementors (the community promise does, that is).

Known issue, they use some nasty combination of IFRAME and JavaScript for the site that breaks in a lot of browsers.

This matches my experience almost exactly. I wasn't sure that I needed a smartphone, so I got a low-end Android handset on Verizon (Droid Eris), and it's been an absolute piece of garbage, even with custom ROM (currently running a Gingerbread ROM based off CM7). The higher-end Android models I've played with have been better, but even my girlfriend's HTC Desire has boatloads of issues, and some of them are the same as the issues on my Eris (scroll lag, menu lag, poor input responsiveness across the board).

Google really needs to focus on Android's user experience if they want to be a serious competitor to Apple across all market segments[1]. That said, I doubt that Google is going to place a strong focus on fixing Android's UX issues, because it seems to me that Android is yet another platform to get more ads in front of more eyeballs, and if shoveling OS updates and cheap handsets out is the way to do it, then that's what they'll do.

[1]: While it's true that Android has the #1 market share right now, I doubt that it's because of Android's UX attracting the masses--I have a feeling that it's due to Android's low price and availability at said low prices in emerging markets with many fresh-faced consumers (China, India come to mind). I strongly suspect Apple still kicks Google's ass in the all-important sector of consumers with money to spend on phones and apps.

You had me until dynamic typing. ;) And I really hope you mean Lisp-y macros, and not CPP macros.

The issue is not with the open-source portion, it's with relicensing. The implication is that parts of the code that are in Android's Java implementation were copied outright and then relicensed to APL, which is not allowed--the original code is GPL, and must stay GPL, unless the original author decides to license it under a different license.

Indeed, though as the OP points out just below, if you have fixed frequencies, you don't have to sort.

That said, you generally have fixed frequencies with a predetermined set of constraints on the data, and you can determine the most common character frequency (or it's already known). I'm not sure how common this is in real-world applications of Huffman coding.

Seeing as you should only be building the tree once though, you're right--you'd be hard-pressed to tell the difference between the two approaches, barring implementation mistakes. Designing an implementation mistake that would cause noticeable differences is an exercise left to the reader.

I found the two-queue technique to be much more intuitive than the binary heap technique, which definitely resulted in it being more fun to code.

As an aside, the two-queue technique is also more performant, as you can build the tree in O (n) time instead of O (n log n) time.

Great summary post, but I want to add one thing—Mono just got a new garbage collector with the 2.8 release called SGen. SGen is a generational garbage collector with nurseries, a cardtable-based write barrier, a parallel mark and sweep collector (which is not enabled by default right now, but there are instructions on how to enable it).

SGen should show better performance on GC-heavy workloads, a fact demonstrated by the SGen part of http://www.mono-project.com/Release_Notes_Mono_2.8. Also, the LLVM backend can be used for yet-another-JITter, though the garbage collector I think remains SGen/Boehm (not sure on this).

As a .NET/PHP on Linux developer, I 100% agree. I just wanted to provide a counterexample. ;)

I don't know of any .NET/Java programmers who say they can't live without IntelliSense. I certainly know I can, and do, frequently. Why, just this morning, I wrote some Java in Emacs. No IntelliSense there.

As far as async I/O, that is a problem. It might get better with the new GC, but proper async I/O would need to use one of the async I/O implementations available (libev/libevent, libaio, etc.).