Personally, I'm 100% convinced that .net is doing fine and will do fine for years to come. We just have to realize though where .net (and Java, for that matter) are used: Inside Enterprises. There is not a single day where I don't see someone pulling off some amazing stuff on Twitter, usually built in JavaScript, CoffeeScript or Ruby. Looking at people pulling off amazing stuff in .net is always a big undertaking though, because there are pretty much no big non-Microsoft .net projects that are "hip". I think FubuMVC, Caliburn.Micro and Bouncy Castle are the only three that I could mention off-hand. But then again, I see amazing stuff done in .net almost every day, except that no one else outside of my work environment will ever see it. Talking to other .net developers in other companies usually yields similar experiences - people are pulling off some seriously fantastic stuff, but it will never ever leave the company it was created in. The open source environment in .net has improved since I blogged about it 4 years ago, but it is still only a fraction of what node.js or ruby has. Just look at the list of most watched C# projects on GitHub or CodePlex and think how long ago some .net project really made headlines.

That doesn't mean it's a bad environment to work in, quite the opposite actually. If you look at popular libraries for node.js or ruby, you will often find that the BCL or Microsoft's .net Libraries already have something built-in, and it's usually rock solid and fast. You will find Microsoft supplying the big features that everyone uses or will use - LINQ, LINQ 2 Sql, Dynamics, TPL, Async/Await, ASP.net MVC are just a few I can think of. Combine the "No one ever got fired for choosing Microsoft" mentality in big enterprises with the fact that the vast majority of software development is done in enterprises, and you see why this attitude exists and why Microsoft has to deliver.

There is no denying that Microsoft had quite a few blunders, of course. WPF, EF and Workflow were downright garbage in .net 3.x, WCF is overly complex for simple scenarios and Velocity... let's just say that I've never heard anyone say anything good about it, and looking at it's API I doubt I'll have good things to say about it. Then, there are signs of the more than 10 year legacy that .net already has, together with the desire for backwards compatibility. System.Configuration is horrible because you cannot just create a Configuration object from a string or any other mechanism, that thing is hard wired to look at a file on your hard drive, which makes it really inflexible for modern, multi-tenant deployments. Have you tried parsing JSON in .net? How many different JSON Libraries/Deserializers do we have as part of the Framework? And how many did Silverlight add? And yet, people mostly prefer the Newtonsoft JSON.net. Have you worked with the ASP.net Provider Model, specifically Membership Providers? Only a mother could love the API of that thing. And speaking of ASP.net, have you ever tried catching an "Attachment too large" error? The error that gets thrown twice, once in IIS before it reaches your app and then in ASP.net itself without a clear way to associate it with the request?

I could go on and on and on about things that are seriously broken in .net, and I haven't even started about testability yet (there is a very good reason for products like TypeMock to exist). It is still overall a great experience, but it is frustrating that we can't do much about the shortcomings of it. To work around the stupid file handling and Configuration madness in ASP.net, we would need a whole different web server since we can't just patch IIS or the ASP.net core components thanks to their closed source nature. Of course, running Mono on nginx is a way to work around this, but enterprises won't approve of such a setup and if it breaks, your behind may be on the line.

I've often experimented with different setups, only to realize that I really like C#. I like its static nature which usually gives good, understandable compiler errors rather than cryptic runtime errors (face it, rails can be a pain to debug). I like that I can mix in dynamics for non-critical things like view models. I like that the Microsoft-provided libraries are mostly good. I like that we can buy support and that there are tons of resources about most topics, since everyone uses pretty much the same stack. I like that they keep backwards compatibility so sacred, even if it means that there is a lot of obsolete stuff in the API (like System.Collections.ArrayList - there is no reason whatsoever to use it. If you need a container for multiple types, fall back to List<object>.

On the other hand, it can be a really frustrating experience when you run against a wall that you can't climb because of its closed source nature and Microsofts reluctance to fix things (Take WPF in .net 3.5 as an example: Things were reported but not fixed. Then 4.0 comes out with Visual Studio, they run into the same problem (e.g., the scrolling popup menus) and HotFix it. That was the moment I've given up on WPF forever) until a major release, if ever. Sometimes it is a really tough sell to use other non-microsoft components like RabbitMQ instead of MSMQ (Search for MSMQ on MSDN and look on the big highlighted article - to me, that's proof that Microsoft doesn't care about their own message queue anymore), or NServiceBus, or a sane ORM instead of Entity Framework.

Most applications start out as simple CRUD applications, and it is usually a lot quicker to start them in node or rails. However, simple CRUD applications usually evolve into more sophisticated pieces, requiring more business logic and safeguards in different places, and here I must say that .net shines - in the long run, its strengths play out well.

However, I really think that we can do better in the web world, much better. Chad Myers had an interesting posting, and even though it was ripped to pieces by Rob Connery, it still holds a lot of truth. Web Applications are unnecessarily complex. I will write a follow up posting with some thoughts about this.

My conclusion would be that .net is overall doing perfectly well. It is used by tons of companies for very important apps, but it was never aimed to be a "hip" language. Microsoft is deeply rooted in the Enterprise, they are pretty much the exact opposite of Apple. That doesn't mean that they do a worse job at it, it just means you won't see as much about it since enterprises like to keep their "secrets" internal and err on the side of safety/secrecy. I have no doubt that there will be .net jobs for the next decade and beyond, while some other language will come and go.

Now, I don't have a problem with them charging now, it's their right. And $2 really isn't much, I bought it immediately since I use growlnotify a lot.

What is prompting me to write this blog posting: I wonder what this means for third party app developers?

When Growl was free (1.2.2 still is), it was a no-brainer to implement it in your App. You could tell your user to download it, or you just snuck it in with your apps (much to the dismay of the developers, who had to put up a notice on their web site). Now, your users have to make an additional $2 purchase regardless if your app is free or paid. And due to the way the Mac AppStore works, you can't just decide to pay the $2 for your users and bundle Growl with your app - even if you include a $2 git certificate, your users now need an iTunes account.

Now, in an ideal world where every user has an iTunes/App Store account this isn't an issue, but I still wonder if this decision will lead to everyone reinventing the wheel and adding their own notification system again? (Or forking/distributing Growl 1.2.2 for all of eternity or until a Mac OS X version that doesn't support it comes up).

Again, I don't want to speak ill of developers who created an amazing piece of software and now charge a minimal amount for it. I just wonder if this may cause issues for us Third Party app developers?

In an ideal world, Tim Cook will announce that Mac OS X 10.8 comes bundled with Growl, that all Apple Apps support it, that GNTP becomes an integral part for distributed notifications, that it integrates into iOS' notifications system etc. pp. Your move, Apple.

I'm a Linq2Sql user. I like it's relatively easy setup and good flexibility, and it has a really good query generator. However, I'm running into some issues with Unit Testing it, because you can't really emulate all the features that it has (EntityRefs with a composite Key or fields that are DbGenerated are a nightmare). Since it is a one-off technology for SQL Server, it doesn't work with any other database (not even SQL Compact 4, which sucks as it would be the perfect Unit Test drop in).

Some people are saying that OR/Ms are an anti-pattern, to which Ayende had an interesting reply. I don't fully agree with any of them. I think that OR/M is solving two different problems, one that it shouldn't solve.

The first problem is getting data from and to the database - the second problem is the mapping of the result to objects. The second problem is a good one, the first one is not a problem and thus doesn't require a solution.

Somehow, people seem to frown SQL, as if it were some evil or outdated concept. You know what? SQL is the language of your database, so you better learn it. Oh sure, it's nice to chain a gazillion Where/Select/ToDictionary/GroupBy calls together and don't have to worry about coming up with the SQL yourself. It's not so nice that the chance to produce a SELECT N+1 is pretty high. When was the last time you looked at the SQL that your OR/M generates and optimized it?

Speaking of optimizations: When was the last time your DBA improved your OR/M Code? Most DBAs I know speak one language very well, and that's the SQL Dialect of their database. They know these hidden tricks and tweaks, they can tweak the query plan and come up with ways to speed up your queries, thus lowering the load and therefore the cost of the system. I don't know many DBAs who would look at a piece of C# code and suggest moving the select outside of the foreach loop in order to turn a SELECT N+1 into a single select. They know the difference between the different JOIN Types (I use LEFT JOIN 99.99% of the time - who knows if there are better ways?) and are able to suggest putting in a READ UNCOMMITTED into a query that is okay to retreive slightly stale data. When was the last time you tweaked the TABLE LOCK setting on your OR/M query?

Granted, most developers don't seem to have access to DBA people and thus have to wear a DBA hat quite often. But you know what? If you have to know about DB stuff anyway, you can as well learn SQL. Even though you may not get everything highly optimized, in the moment a DBA looks at it and optimizes stuff you just have to change your query and call it a day. Maybe you two decide to create a Stored Procedure instead, in which case your SELECT becomes an EXEC - big deal, not.

Yes, I am aware that some queries can get pretty harsh. I have a query with 14 subselects (mainly because it has to do paging on the database) and I am glad that I can write it in Linq2Sql, creating an IQueryable and passing it through a dozen methods that apply more Where clauses based on some ridiculously huge filter class a user passes in. Not having to generate that through StringBuilders or other stuff is a great thing.

But you know what? That query is the one anomaly in a sea of standard CRUD queries. I can write those CRUD queries in my sleep, blindfolded. And I can look at them and immediately understand what this thing is doing. I can read up the T-SQL manual, run it in SQL Management Studio while the SQL profiler is running, look at the Execution plan, tweak the query, put it on Stack Overflow to get some input - I am talking to the DB in a language it understands and have no limitations in how I tweak it.

Really, all I want is the Mapping. I want to write a (parameterized) SQL query, but I don't want to do the ExecuteReader/foreach loop crap, because that's stupid work. I want to be able to insert a Parent Row and it's child rows in one go, without having to use client-side generated GUIDs for the primary key so that I can add it to the child rows. I love the EntitySet/EntityRef stuff in Linq2Sql, and that's what I want. Create an Object and it's children, put it in the database and not worry about capturing the @@IDENTITY and populating it on the children. I don't want an OR/M, I want an Object Mapper.

Luckily, there seems to be a small (but truly existing) movement into it, Dapper and Massive being two of the better known ones. Massive uses the new dynamic functionality in .net 4, a technology that could revolutionize OR/Ms once they start embracing it (rather than trying to stick to their Java roots or stay compatible with .net 2.0). I don't fully like how I have to create "empty" classes and it seems that it doesn't do "real" SQL but rather a DSL that looks like SQL. That would kinda suck.

Dapper is currently used as the OR/M for Stack Overflow, It's very bare bones (doesn't manage your connection, no UPDATE helpers), has some not-so-nice syntax quirks (Having to pass IsAnsi = true when querying a non-unicode - but that's an edge case I'd argue) and although I have not yet had a chance to use it, if Jeff Atwood is willing to use it on the thing that puts food on his table and rock band songs onto his Xbox, I'd assume it's stable.

Granted, one can argue that you're not paying your developers to write code that can be written faster in an OR/M, a claim I'd like to dispute when looking at the total lifetime of an application including maintenance, but if you want a catchy, quotable sentence: Traditional OR/M is like WebForms. It's rapid at first, does stuff just well, may even have a fancy GUI to drag/drop your tables. But just like WebForms limits you tweaking the genrated markup or core functionality ("I need my Data Grid to render the headers in a <thead> so that the jQuery TableSorter plugin works") and sometimes requires some hacks ("I know, I just put some javascript that wraps the generated table header rows into a <thead>"), an OR/M will put up some walls that you can't climb as well.

I think it's time for an OR/M that is to other OR/Ms what ASP.net MVC is to ASP.net WebForms: A Framework that allows and requires us to get deep into the guts, but does not limit the tweaking we can do, while still handling a lot of the stupid work, and I think it's great to see projects move into that direction. Just as MVC and WebForms both sit on top of an ASP.net core stack, ADO.net serves as a rock solid foundation for multiple philosophies of OR/M systems that can happily co-exist and serve both the people able and willing to write SQL and the people who'd rather spend money on an OR/M, profiling tools, and maintenance costs.

This book is specialized and concise. As you might see from the image, it comes it an well under 100 Pages and covers exactly one topic.

I have only very limited time compared to the amount of technology that’s out there. The Web is evolving so fast, it’s hard to keep up with new developments. Information is scattered in blog posts, and it’s often hard to just find a cohesive front-to-back tutorial. Also, even though I own both a Kindle and an iPad, I prefer my books to be on dead trees.

Tech Books are often massive, 500 to 1000 page compendiums, and there are cases when it’s necessary. If you read the .net Specification, the C# Language Specification or David Flanagan’s excellent JavaScript: The Definitive Guide, it’s hard to get these under 500 pages, and that’s okay because they are compendiums about an entire language.

However, way too often I see books that have a lot of text but very little information. One of my Pet Peeves is the Introduction and Installation section. Many Web Books start with a 50 page history of the Internet, from CERN to HTML5, how the internet has revolutionized the world and what great things lie in front of us. Sorry, if I really want to know about the history of the Internet, I hit up Wikipedia, just like the book author likely did when researching. The only interesting piece of History is the motivation behind a technology, answered by asking two questions: What Problem did the creator of a technology run into, and how is this technology attempting to solve it?

Same for the installation Section. I don’t need a 20 Page installation that’s outdated anyway when the book comes out, Give us the official Project Website and maybe a few gotchas, but we can take it from there.

Being able to read a book in an evening is a huge win because it already plants knowledge into our brain about what’s available. I might not have immediate need for a technology, but knowing what and how it does stuff means that the next time I run into a technical problem, I might think “Hey, I can use X to solve that!”.

The HTML5 Filesystem API book does just that. It has a small Intro and dives right into code examples. The API is simple, yet does introduce new objects into JavaScript. There is no example application per se (One could think that building an Address Book with uploadable Photos would be cool), presumably because it would take the focus away from the core. The code builds on top of each other though, from the creation of a file system to adding, deleting, uploading and remote getting files.

In fact, this book is good for another point: Tech Books are usually behind the applications they release. When a technology comes out, the early books are usually garbage, based on Beta/Prerelease versions with code examples that are slightly broken because RTM changed stuff. They don’t have many real world usage scenarios, often cover too much too shallow. This is even worse when the technology is an update (e.g., ASP.net MVC 3) and the early books are just previously released books (e.g., for ASP.net MVC 2) updated with some new features rather than redoing the entire book front to end with the new technology in mind.

The later books are usually too late – by the time they come out, the successor technology has already been announced, and people gained knowledge through blog posting, cursing at how bad the technology is documented.

Tech Books remind me a lot of Waterfall development, in that they simply take way too long to come to the market and don’t meet the needs of the customers. Writing a 500+ page tome simply takes time.

The agile version of that is what the above book demonstrates: The technology it’s discussing isn’t even out yet and may change, a fact that’s clearly stated in the book. However, because it’s only 80 or so pages, it’s quick to write and gives the reader enough knowledge about all aspects of the API, so that eventual changes should be fairly trivial to do (Eric also includes the link to the W3C Spec, so you can stay up to date). But even if they completely throw away and redo the API, it only wasted a small amount of my time – and my money. The book is $20 (cheaper on Amazon right now), so it’s not a massive investment at all, especially if I would calculate the time it would take me to scour through scattered blog postings as billable time.

Another great example is The Node Beginner Book. It’s cheap ($5), comes in at about 60 pages, is cohesive and available right now (compared to some books that are scheduled to come out in 4 months or more). CoffeeScript: Accelerated JavaScript Development is another excellent one. I heard that the Nuget folks are considering a book as well, and I would love to just get a book that covers how Nuget works internally, how the Server was written and how to interact with the Visual Studio plugin. Sure, I can look at the source code, but again, a concise and cohesive overview with samples and a reference part is all that’s really needed.

Some other books I would totally buy: Model Binding and Validation in ASP.net MVC 3/4, RESTFul WCF Applications, Ways to send data from the Server to a browser (From COMET and setInterval/JSONP crutches to Web Sockets and Server Side Events), Writing an ORM from Scratch.

I say that Business IT finally needs to move into the 21st century and embrace this thing called "Internet". Why do you need a long testing cycle for a web browser? This is most likely a sign that your internal web applications are written for a specific browser, usually Internet Explorer 6. It means that your web applications contain countless hacks for that browser and because you didn't upgrade to Internet Explorer 7 and 8 when they came out in 2006 and 2009 respectively. It means that you have amassed considerable technical debt, and now you have to pay the piper.

I say: Sucks to be you. The Web is improving fast. When you wrote that ASP.net 1.1 Application that displays an Oracle Database in a data grid, you made a commitment to the web. You committed to abandon a stable platform like Windows (even with all the negative reactions to Vista, Microsoft is doing a lot to ensure backwards compatibility) and chose a platform that has been chaotic, anarchistic and unstable since the dawn of time, or at least since Netscape 2.

The year is 2011. You don't have to embrace HTML5, but you should make sure all your applications work in IE8, Firefox, Chrome and Safari/Mac without hacks, because then browser updates will be no problem. If you are still on Internet Explorer 6 or 7, upgrade to 8 (XP) or 9 (Modern Windows). If you are vendor-locked in to IE6 - I'm sorry, but you sucked. Your Purchasing Department really dropped the ball when they bet on IE6, because no sane company ties itself to a single product version of anything.

If you wrote an in-house web app or browser extension, then just upgrade it. And don't tell me anything about cost here - your business made the decision to go to the web, so if changes to the web environment come as a surprise, you didn't do your homework properly. Please, go back and write Windows Client apps again or do your job properly. If you want to be a web developer, then you need to do more than just drag/drop a DataGridView and connect it to a SqlDataSource. If you want to be an IT Person, learn how to work with the developers to make them change their apps.

Or, more likely: Continue to whine about how fast stuff changes, how vendors dare to improve their products, how they change the version number. Continue to embrace the waterfall model, get obsessed with version numbers, create test plans that take a year to execute, and stay out of touch with the real world. After all, business needs are more important than quality.

Just do me one favor then: Make sure that your crappy web apps can't be easily hacked. I'm getting tired with incompetent companies constantly losing my customer data to hackers. But then again, there are no penalties for losing customer data, so my plea will go unheard.

I guess unbiased reviews need to start with something negative to support the claim that the review is truly unbiased So to roll with it, let me say that you shouldn’t judge the product by it’s homepage which sadly looks like a 2003-ish WebForms site. The application itself isn’t the best looking one either, but it has fancy colors and stuff. It also looks like 2003-Windows XP Luna when in 2011 we’ve moved back a bit to clean, serious, calm colors. But well, again, this is about the product.

My first question when looking at commercial software is of course: What problem does it try to solve, and is that problem really a problem?

NDepend is an analyzer to find some flaws that easily fall through the cracks: High Cyclomatic Complexity (which is not a problem when the code is still fresh in your head, but causes nightmares 6 months down the road when you need to find a bug in it). Dependencies with more dependencies with more dependencies with more… Comparing two code bases for a list of all changed methods.

It does a lot more, but what I was interested right now was their Code Query language, CQL. It’s like SQL, but for code.

For example, I’ve analyzed the Code, added a public method, analyzed again and the performed a “SELECT METHODS WHERE WasAdded AND IsPublic”. As a result, I get a list of all newly added Public methods:

What problem does this solve? It solved the problem of Diff Tools being unaware what they are diffing. Let’s say you merge a large commit that has 200 changed files. You glance at them and see that there’s tons and tons of tab vs. spaces changes, many added code comments, some refactoring. It’s a very bad signal to noise ratio when in reality you are mainly concerned with “How did functionality change?”. Of course, you can now easily say “One change per commit. Commit Messages are enough documentation. Do not commit both functional and semantic changes” and you are right – but this is not how the real world works.

Maybe you don’t even know the code base because your predecessor didn’t do a good job documenting stuff or even checking stuff into source control and now you have two codebases (one possibly a result of decompiling the assembly) and need to get an overview.

The CQL Query edit window has IntelliSense which is really helpful, but not without it’s flaws: “SELECT methods  WHERE  WasAdded” does not work, it needs METHODS to be uppercase. Also there seems to be no "SELECT * WHERE WasAdded”

The one thing I really dislike about this feature though is that it’s relatively complex to setup: Ideally I’d just love to tell NDepend “Here’s two Visual Studio solutions and/or assemblies, please analyze them and show me a list of functional differences”. Specialized tools like Inca are available to make that easier of course.

Methods with a lot of instructions

You can query for a lot of really neat stuff, like the number of IL Instructions:

SELECT TYPES FROM ASSEMBLIES "SWiki" WHERE NbILInstructions > 300 ORDER BY NbILInstructions DESC

This is a LOT more useful than lines of code (which is also possible) because I can easily write very terse but unneccessarily complex code among the line of this:

for (int i = 0, y = 1, z = 13; i++ < 10 && ++y < 8; CallSomeMethod(i, y, z)) ;

Only to save a few lines while still writing insanely crappy code that would make a C++ developer proud.

Methods called by many other methods

What else can we query by? Most Used Methods is nice, ignoring .net Framework assemblies and Properties:

SELECT TOP 50 METHODS WHERE !IsInFrameworkAssembly AND !IsPropertyGetter AND !IsPropertySetter  ORDER BY MethodCa DESC

This is different from running a profiler, because this analyzes all the theoretical calls: There’s 23 places in my source where a certain constructor is called. Sadly there seems to way to get the Method Name as well as the Signature… Note that this is NOT a profiler thing: Just because the ctor is called in 23 different places does not mean that it needs to be performance critical because no statement how often it is called is made. This list is not a “Where to optimize speed next”, it’s a “Do we have any methods that should be abstracted away a bit more?” thing.

Classes implementing an Interface

MSDN has a list of derived classes on certain base classes, but it lacks this for Interfaces. Quick, tell me which classes implement IPrincipal? The MSDN Page does not show, but NDepend does:

I was looking for ages for a way to “Query” MSDN like that, and NDepend does it once you created a project to analyze all the .net Framework assemblies (and any additional ones of course).

Comparing SharePoint 2007 to 2010

As NDepend works against assemblies rather than source code, you can run analysis of SharePoint 2007 DLLs, then the SharePoint 2010 ones. The result is a full report about public API changes.

Even better: Run analysis before and after installing a Hotfix and see what actually changed and analyze your custom code precisely for these changes.

What about existing Code Analysis and Resharper users?

Now, I’m using Visual Studio 2010 Premium with Code Analysis and ReSharper which means that a lot of the simple mistakes are already caught without NDepend: Making Fields readonly, marking assemblies CLSCompliant, methods that don’t use “this” could be static, methods with way too many dependencies etc. pp.

For some of the more common problems, users of Code Analysis should better write their own rules so that they run on every build. But when it comes for just quickly querying the code prior to a refactor (How much stuff is affected?) or just for finding stuff (I wonder what ActionResults ASP.net MVC has, and which ones we’ve added?) NDepend is a great resource.

Just stumbled upon a bug in SharePoint 2010. Imagine this scenario: You have two lists and add them to a Site as DataForm WebParts. You then configure the Web Parts so that one of them sends Filter values to the other one and uncheck the option for "Send first row to connected Web Parts when page loads". You refresh the Page and notice that the list that receives the Filter (the Consumer) does not show any items because the list that provides the Filter (the Provider) does not have any items selected.

In SharePoint 2007, not selecting an item in the Provider List would cause the consumer List to display all items instead, which was (at least for us) highly desirable. In SharePoint 2010, you have to select an Item in the Provider to provide a filter and there is no way to have the Consumer List display all items anymore.

The reason why I think this is a bug is the result of an extended Debugging session that eventually led me to the class Microsoft.SharePoint.WebPartPages.DataFormWebPart and specifically it's method ApplyReceivedFilterData. I'm not going to paste the source of this class, but the culprit is this line: if (dictionary2[str] != null)

This is supposed to only add Filters that have a value and skip the ones that are null. The problem is that dictionary2[str] is not null but DBNull, which then causes SharePoint 2010 to process the value anyway and generate a nasty <Query><Where><IsNull><FieldRef Name="FieldToReceiveFilter" /></IsNull></Where></Query> in the SelectCommand of the underlying DataSource

Unfortunately, DataFormWebPart.ApplyReceivedFilterData is not virtual, so sub-classing it does not seem to be an option. Not sure if there is a good workaround for this. I verified this behavior in both RTM and December 2010 Hotfixed versions of SharePoint 2010.

Edit: Just checked the SharePoint 2007 DataFormWebPart.ApplyReceivedFilterData() in Reflector and lo and behold, they did check for DBNull in 2007:

        Label_0046:
            if (current[str] is DBNull)
            {
                goto Label_006D;
                // Note by myself: Label_006D is the call to MoveNext, aka. continue
            }

So with a notification system and a scheduler at our disposal, I thought it would be good to write a little eggtimer script so that I can specify "Remove Pizza from oven in 10 minutes". I'm sure there are tons of graphical tools available, but I prefer a simple shell script.

The growl side is easy, this command needs to be executed:

growlnotify -t "Reminder at 03:54" -m "Remove Pizza from oven" -s -a iCal

The -t parameter specifies the title (even though the manpage incorrectly states "this does nothing"), -m is the message, -s means it's sticky (so it doesn't disappear unless explicitly closed) and -a specifies the icon to use, in this case the iCal icon.

The at command is used to create jobs that run at a specified time. However, it requires another "service" to run, called atrun. By default, this is disabled. Check the atrun manpage for the command to enable it, on my OS X 10.6.6 it's

sudo launchctl load -w /System/Library/LaunchDaemons/com.apple.atrun.plist

I found the syntax of at a bit weird as it kept complaining about garbled or incomplete time. It actually needs to read a whole input from stdin rather than just accepting a single command. So the invocation looks like this:

at now + 10 minutes << eol
growlnotify -t "Reminder at 03:54" -m "Remove Pizza from oven" -s -a iCal
eol

That works, but of course it's WAY too much to type for us lazy people So let's wrap this in another shellscript that accepts two parameters: A number for "Remind in X minutes" and a message:

#! /bin/zsh
function verifyminutes () {
  echo -n $1 | grep -Eq "^[0-9]+$"
  echo $?
}
function gettargettime() {
  date -v +$1M "+%H:%M"
}
function getmessage() {
  # function to collapse arguments $2..$n together (skipping $1)
  # I'm pretty sure there is a better way of doing this
  local FIRST_PARAMETER=0
  for i;
  do {
    if [ "$FIRST_PARAMETER" -eq 0 ]; then
      FIRST_PARAMETER=1
      continue
    fi
    echo -n $i" ";
  }
  done
  echo "\b"
}

local ISNUMBER=`verifyminutes $1`
[[ -z $1 || -z $2 || "$ISNUMBER" -gt 0 ]] && {
  echo "usage: $0 minutes message"
  exit 1
}

local TARGET_TIME=`gettargettime $1`
MESSAGE=`getmessage $@`
echo "Reminder set at $TARGET_TIME: $MESSAGE"

at now + $1 minutes >/dev/null 2>&1 << eol
growlnotify -t "Reminder at $TARGET_TIME" -m "$MESSAGE" -s -a iCal
eol

exit 0

Usage of this script is simple, just call eggtimer 10 Remove Pizza from oven and 10 minutes later you will get a Growl notification.

PS: If you are wondering about the getmessage function: Normally if you have spaces in an argument, you need to enclose the entire message in quotes. I wanted to get rid of the quotes, hence I'm collapsing all parameters after the first one together.

References for this on my blog:

• Parsing the command line
• Base36 Encoder/Decoder in C#
• A simple Even/Odd Cycler for .net
• A simple .ini File parser for C#
• Extension Method: Return another string if string is null or empty
• Turning string.Format into an Extension Method
• An Extension method to replace multiple Chars in a string

Any attempt to install a package - be it through 'Add Library Reference' or through PowerShell Install-Package - displays an error message: Description is required.

Turns out that one of the nuspec files has indeed an empty <description /> tag. Sadly, that breaks the entire repository.

The solution is to put in a description and rebuild the nupkg. In parallel, I have filed a bug on CodePlex in the hope that a single broken package does not break the entire Repository anymore.

However, Path.GetExtension does return the extension with a dot (or string.Empty in case the file does not have an extension).

Additionally, there may be upper/lowercase conflicts.

Remember how the compiler emits a ret instruction at the end of the constructor and Execute method? I said it's optional and only required for verifiable code. Well, I've asked on StackOverflow in the meantime and got the answer I was looking for:

Control is not permitted to simply “fall through” the end of a method. All paths shall terminate with one of these instructions: ret, throw, jmp, or (tail. followed by call, calli, or callvirt).

(ECMA-335; 12.4, 6)

So, there you have it: Make sure each method ends with one of the above instructions.

Quick Compiler Theory
Basically our end result has to be a series of bytes. For example, the IL Instruction ldc.i4.0 is compiled as 0x16. Some instructions take parameters. For example, the br instruction is compiled as 0x38 0x?? 0x?? 0x?? 0x??. That's 5 bytes: 0x38 for the actual br and then 4 bytes for the address to jump to.

However, there is more. .net assemblies are usually .exe or .dll files and pure IL may only help you on mono (not sure if that's true and if you can feed mono with a pure IL file). If you're running on Windows, you need some additional "stuff" to make a proper .exe - see this Article.

Now, how do we write a compiler? In what language do we write compilers? If you looked into Compiler development you may have heard the term "bootstrapping" which means "Write a compiler for language X in language X through an intermediary compiler written in language Y". So if you want to write the very first C# compiler you can't write it in C# as there are no C# compilers to compile your C# code with, so you use another language. You could use C, C++, Delphi, Assembler or any other language.

Needless to say, this whole process is very complicated and involves a lot of plumbing (many lines of code for simple things because you have to manage everything). Luckily, Microsoft gave us a fantastic built-in functionality to compile .net Assemblies: The System.Reflection.Emit Namespace.

Reflection.Emit and how a Console Application works
What does Reflection.Emit allow us to do? It allows us to emit IL instructions into an assembly - we just feed it the IL instructions and it takes care of everything else. As a side effect, this allows us to write our compiler in any .net language! In our case, it means we will write our Compiler in C#.

But, what will we actually need to emit? Can we really just take the BF code and emit IL from it? No, not really. Each .net Assembly needs an Entry Point: A method. Create a new C# Console Application and notice that you start with a method "Main":

static void Main(string[] args)
{
}

Try renaming the method to something else and compile your Application. You will get this error message:
Program 'test.exe' does not contain a static 'Main' method suitable for an entry point

Each C# Application needs a method called Main. This is the entry point of the Application, this is the very first method that .net calls. Does it have to be called "Main"?

Not really. In .net, any method can be an entry point. It's just that the C# guys at Microsoft decided that for C# it shall be called Main, possibly because that's how it's usually called in C/C++.

Additionally, you may notice that the Main method is part of a class called Program. Do methods have to be part of a Type? In C# yes, but in C++/CLI you can have global methods. So does .net as a whole require a Type to hold methods? Yes, it does. Let me quote from Partition I, 9.8: "The CTS does not have the notion of global statics: all statics are associated with a particular class.". There is an annotation to that: "[...] the CLI supports languages that supports global statics by creating a special class names <module>".

So to conclude, we need a class which contains a method. So, what will we actually compile now?

The BF Compiler we are going to write will create a Console Application. Specifically, we will create this class (shown as a C# class for illustration purposes):

public static class Program
{
    private static byte[] memory = new byte[short.MaxValue]; // 32767 bytes
    private static short pointer = 0;

    public static void Execute() {
        // Our BF Code here
    }
}

As you see, we have a byte-array that serves as our memory. We offer BF a generous 32 kilobyte of memory. Additionally, we have a pointer into the memory so that we know where we are in the memory. Our containing class is called Program and our entry point is called Execute (just to show that we are so cool, we don't need a method called Main). This method will then contain our compiled BF Code.

Creating the bare minimum compiler skeleton
Let's start simple. Create a new C# Console Application and use this code for your main method:

static void Main(string[] args)
{
    string sourceFileName = args[0];
    string outputName = args[1];

    var sourceCode = File.ReadAllText(sourceFileName);
    BFCompiler.Compile(outputName, outputName + ".exe", sourceCode);
    Console.WriteLine("{0} compiled to {1}.exe",sourceFileName,outputName);
}

Then, create a new class BFCompiler:

public static class BFCompiler
{

    public static void Compile(string assemblyName, string outputFileName, string sourceCode)
    {
    }
}

Create a new text file and call it "hello.bf":

++++++++++[>+++++++>++++++++++>+++>+<<<<-]>++.>+.+++++++..+++.>++.<<+++++++++++++++.>.+++.------.--------.>+.>.

In Visual Studio, set "Copy to Output Directory" to "Copy Always" and compile. You can now invoke your compiler using
bfnetc.exe hello.bf hello
and it should print "hello.bf compiled to hello.exe" on the command line.

Okay, that was our skeleton: Read the .bf source code, call the compiler with the desired assembly name, output filename and source code.

Creating an Assembly
Now we need to actually create the assembly. Change BFCompiler.Compile to contain this code:

public static void Compile(string assemblyName, string outputFileName, string sourceCode)
{
    var asm = AppDomain.CurrentDomain.DefineDynamicAssembly(new AssemblyName(assemblyName),
                                                AssemblyBuilderAccess.Save);

    var mod = asm.DefineDynamicModule(assemblyName, outputFileName);

    var mainClassTypeName = assemblyName + ".Program"; // e.g., hello.Program
    var type = mod.DefineType(mainClassTypeName, TypeAttributes.Class | TypeAttributes.Sealed | TypeAttributes.Abstract | TypeAttributes.Public);

    var pointerField = type.DefineField("pointer", typeof (Int16), FieldAttributes.Static | FieldAttributes.Private);
    var memoryField = type.DefineField("memory", typeof(Byte[]), FieldAttributes.Static | FieldAttributes.Private);

    var constructor = type.DefineConstructor(MethodAttributes.Static, CallingConventions.Standard, null);
    var cctorIlGen = constructor.GetILGenerator();
    GenerateConstructorBody(cctorIlGen,pointerField,memoryField);

    var mainMethod = type.DefineMethod("Execute", MethodAttributes.Public | MethodAttributes.Static);
    var ilGen = mainMethod.GetILGenerator();

    ilGen.Emit(OpCodes.Ret);
    type.CreateType();
    asm.SetEntryPoint(mainMethod);
    asm.Save(outputFileName);
}

Whoa, that looks complicated! (And also it doesn't compile as GenerateConstructorBody doesn't exist). Let us walk through the code step by step:

var asm = AppDomain.CurrentDomain.DefineDynamicAssembly(new AssemblyName(assemblyName),
                                            AssemblyBuilderAccess.Save);

var mod = asm.DefineDynamicModule(assemblyName, outputFileName);

var mainClassTypeName = assemblyName + ".Program"; // e.g., hello.Program
var type = mod.DefineType(mainClassTypeName, TypeAttributes.Class | TypeAttributes.Sealed | TypeAttributes.Abstract | TypeAttributes.Public);

We start by creating a new Assembly that has a certain name (in our example that would be "Hello"). This Assembly exists in the current Application Domain (This could be a security risk - please read up about application domains in .net if you want to know more). The second parameter specifies what can be done with this assembly. This is another security feature, as we specified that "The dynamic assembly can be saved, but not executed.". The "but not executed" part does not mean that we generate an assembly that can't be run (that would be stupid, right?). It merely means that the Assembly (which only exists in memory for now) cannot be executed in the context of our running compiler. We can save it to disk though.

We then specify a module. Assemblies are collections of modules, and each assembly needs to contain at least one module. Usually, it contains exactly one module as Visual Studio doesn't support us in packaging multiple modules into one assembly. If you come from a C/C++ background, think of modules as static compilations. If you don't come from a C/C++ background, read up on ilmerge and netmodules.

So our module is called "hello" and has a filename of "hello.exe".

We then create a new class (or Type) called "Program". This is a public sealed abstract class. Uhm... "sealed abstract"? Well, .net does not support static classes. But C# does? How? By cheating: A static class in C# is a class that is both abstract and sealed (something that's legal in .net but illegal in C#). By declaring it abstract it is ensured that nobody can instantiate it and by making it sealed it is ensured that nobody can subclass it. (For some trivia around C# static classes, see this article).

The other thing: What is the mainClassTypeName doing? It generates a namespace for us. Our typename in this example isn't Program - it's "hello.Program". During compilation, AssemblyBuilder will create a namespace "hello" and a Type "Program" automatically.

So now we have the "outer shell" of our compiled Application: An assembly called "hello" containing a module "hello.exe" containing a public "static" (abstract sealed) class "Program" in a namespace "hello".

Next, we define two fields in the Program Class:

var pointerField = type.DefineField("pointer", typeof (Int16), FieldAttributes.Static | FieldAttributes.Private);
var memoryField = type.DefineField("memory", typeof(Byte[]), FieldAttributes.Static | FieldAttributes.Private);

These fields are private and static and of type short (=Int16) and Byte-Array respectively. But wait, don't we specify the size of them?

No, we don't. See, the C# way of writing

private static byte[] memory = new byte[short.MaxValue];

is just a convenience feature. If you compile this assembly and look at the IL, you will notice that the assignment is done in a static constructor. This is why we define a constructor:

var constructor = type.DefineConstructor(MethodAttributes.Static, CallingConventions.Standard, null);

The first parameter declares that we want to create a static constructor (.cctor). The second parameter means that the constructor is a normal method (as opposed to a virtual method or one that takes variable arguments). The third parameter defines any arguments the method takes - static constructors are always parameterless, hence we pass null.

We have our constructor method now, next we need to put some code into it:

var cctorIlGen = constructor.GetILGenerator();
GenerateConstructorBody(cctorIlGen,pointerField,memoryField);

GetILGenerator is the magic that makes compilers happen. This thing allows you to write code into the method. Add a new method to the BFCompiler class:

private static void GenerateConstructorBody(ILGenerator ilGen, FieldInfo pointerField, FieldInfo memoryField)
{
    // construct the memory as byte[short.MaxValue]
    ilGen.Emit(OpCodes.Ldc_I4,0x7fff);
    ilGen.Emit(OpCodes.Newarr,typeof(Byte));
    ilGen.Emit(OpCodes.Stsfld,memoryField);

    // Construct the pointer as short = 0
    ilGen.Emit(OpCodes.Ldc_I4_0);
    ilGen.Emit(OpCodes.Stsfld, pointerField);

    ilGen.Emit(OpCodes.Ret);
}

Whoa, another highly complex method. Well, actually it's rather simple, just many lines of code. Remember, you are now directly generating IL, so no convenience features. You have to do all the plumbing yourself. What are we doing? First, we call ldc.i4 0x7fff which pushes the 32-Bit value 0x7fff (=32767 or short.MaxValue) to the stack. Then we call newarr typeof(byte) which creates a new Byte Array. Important: It's typeof(Byte), not typeof(Byte[])! newarr pops the length from the stack, so this now created a new Byte[32767] for us.

stsfld puts it into the memoryField.

So the static constructor now looks like this:

static Program(){
    memory = new Byte[0x7fff];
}

The next two instructions of the constructor initialize the pointer field: Push 0 to the stack, replace pointer with the value on the stack.

You may wonder about the last instruction:

ilGen.Emit(OpCodes.Ret);

This generates a return; statement. Why a return statement on a void method? Is this required? Technically, it's not. But in order to create verifiable assemblies, you have to emit it. Veri-what? Verifiable Code is a security feature in .net. It essentially allows tools (like PEVerify) to determine that no security boundaries are violated (that is: no unsafe pointer manipulation and a well defined "flow" through the application). In a nutshell: By emitting the ret statement at the end of a method, any static analysis tool knows for sure that at this point, control is returned to the calling method. So always generate ret at the end of each method, even for void methods.

So that's our constructor. We now have a class Program with two fields (pointer and memory) that are properly initialized. Great! Now we create the main method:

var mainMethod = type.DefineMethod("Execute", MethodAttributes.Public | MethodAttributes.Static);
var ilGen = mainMethod.GetILGenerator();
ilGen.Emit(OpCodes.Ret);

This is almost the same as above, except we call DefineMethod. The method is called "Execute" and is public static. We then get the ILGenerator for the method and emit a single instruction: Ret. Ignoring the issue with verifiable code outlined above, do we really need the ret statement? Yes, we do. No, actually we don't. We just need any statement. Why?

Because each method must have a method body. If you generate a method without any instructions in the body, you will get an exception:
System.InvalidOperationException: Method 'Execute' does not have a method body.

So we have to emit something, and we just return. We could also have chosen nop (no-operation), but since we want to create verifiable code, we emit ret.

The next three instructions then actually create the Type and Assembly:

type.CreateType();
asm.SetEntryPoint(mainMethod);
asm.Save(outputFileName);

CreateType essentially "compiles" the type - until this moment, the Type only exists as some description, but we can't use it from other code.

SetEntryPoint then points to the Execute method. If you don't set an entry point then the Assembly is still generated, but you can't run it ("hello.exe is not a valid Win32 application").

Save then finally writes the Assembly to disk.

Run your compiler again and you should get an hello.exe which does nothing, but at least it runs! Look at it in ildasm or Reflector and you should see this code:

class public abstract auto ansi sealed Program
   extends [mscorlib]System.Object
{
   .method privatescope specialname rtspecialname static void .cctor() cil managed
   {
       .maxstack 1
       L_0000: ldc.i4 0x7fff
       L_0005: newarr uint8
       L_000a: stsfld uint8[] Program::memory
       L_000f: ldc.i4.0
       L_0010: stsfld int16 Program::pointer
       L_0015: ret
   }

   .method public static void Execute() cil managed
   {
       .entrypoint
       .maxstack 0
       L_0000: ret
   }

   .field private static uint8[] memory
   .field private static int16 pointer
}

Whoa, nice! Notice that Program derives from System.Object - we don't have to do that manually, Reflection.Emit does that for us automatically. Also, we don't have to worry about all this other stuff that is required to create a Windows Executable - AssemblyBuilder does that as well.

Compiling the BF Code
We now have a working .net assembly that sets up some fields, but it doesn't do much. So let's do something with the BF Source Code! Add the following code to the BFCompiler.Compile method:

var ilGen = mainMethod.GetILGenerator();
// New Code
foreach(char c in sourceCode)
{
    switch (c)
    {
        case '>':
            GenerateMovePointerForwardInstruction(ilGen, pointerField, memoryField);
            break;
        case '<':
            GenerateMovePointerBackwardsInstruction(ilGen, pointerField, memoryField);
            break;
        case '+':
            GenerateIncrementInstruction(ilGen, pointerField, memoryField);
            break;
        case '-':
            GenerateDecrementInstruction(ilGen, pointerField, memoryField);
            break;
        case '.':
            GenerateWriteInstruction(ilGen, pointerField, memoryField);
            break;
        case ',':
            GenerateReadInstruction(ilGen, pointerField, memoryField);
            break;
        case '[':
            GenerateOpenBracketInstruction(ilGen, pointerField, memoryField);
            break;
        case ']':
            GenerateCloseBracketInstruction(ilGen, pointerField, memoryField);
            break;
    }
}
// New Code
ilGen.Emit(OpCodes.Ret);
type.CreateType();

We are walking to the sourceCode, character by character. For each of the 8 known BF instructions we call another function that generates the proper IL. Let's quickly look at each of them:
< and > instructions

private static void GenerateMovePointerForwardInstruction(ILGenerator ilGen, FieldInfo pointerField, FieldInfo memoryField)
{
    ilGen.Emit(OpCodes.Ldsfld, pointerField);
    ilGen.Emit(OpCodes.Ldc_I4_1);
    ilGen.Emit(OpCodes.Add);
    ilGen.Emit(OpCodes.Conv_I2);
    ilGen.Emit(OpCodes.Stsfld, pointerField);
}

private static void GenerateMovePointerBackwardsInstruction(ILGenerator ilGen, FieldInfo pointerField, FieldInfo memoryField)
{
    ilGen.Emit(OpCodes.Ldsfld, pointerField);
    ilGen.Emit(OpCodes.Ldc_I4_1);
    ilGen.Emit(OpCodes.Sub);
    ilGen.Emit(OpCodes.Conv_I2);
    ilGen.Emit(OpCodes.Stsfld, pointerField);
}

We've been through them in Part 3: Load the pointer value, add/subtract 1 from it, convert the result to an Int16, store it in the pointer field again.

+ and - instructions

private static void GenerateIncrementInstruction(ILGenerator ilGen, FieldInfo pointerField, FieldInfo memoryField)
{
    ilGen.Emit(OpCodes.Ldsfld, memoryField);
    ilGen.Emit(OpCodes.Ldsfld, pointerField);
    ilGen.Emit(OpCodes.Ldelema, typeof(Byte));
    ilGen.Emit(OpCodes.Dup);
    ilGen.Emit(OpCodes.Ldobj, typeof(Byte));
    ilGen.Emit(OpCodes.Ldc_I4_1);
    ilGen.Emit(OpCodes.Add);
    ilGen.Emit(OpCodes.Conv_U1);
    ilGen.Emit(OpCodes.Stobj, typeof(Byte));
}

private static void GenerateDecrementInstruction(ILGenerator ilGen, FieldInfo pointerField, FieldInfo memoryField)
{
    ilGen.Emit(OpCodes.Ldsfld, memoryField);
    ilGen.Emit(OpCodes.Ldsfld, pointerField);
    ilGen.Emit(OpCodes.Ldelema, typeof(Byte));
    ilGen.Emit(OpCodes.Dup);
    ilGen.Emit(OpCodes.Ldobj, typeof(Byte));
    ilGen.Emit(OpCodes.Ldc_I4_1);
    ilGen.Emit(OpCodes.Sub);
    ilGen.Emit(OpCodes.Conv_U1);
    ilGen.Emit(OpCodes.Stobj, typeof(Byte));
}

These were covered in part 2. Load the memory and the pointer, get the memory-byte at the pointer address, add/subtract 1 from it, convert it to a byte (UInt8), replace it in the byte array.

. and , instructions

private static void GenerateWriteInstruction(ILGenerator ilGen, FieldInfo pointerField, FieldInfo memoryField)
{
    ilGen.Emit(OpCodes.Ldsfld, memoryField);
    ilGen.Emit(OpCodes.Ldsfld, pointerField);
    ilGen.Emit(OpCodes.Ldelem_U1);
    ilGen.Emit(OpCodes.Call,
               typeof(Console).GetMethod("Write", BindingFlags.Public | BindingFlags.Static, null,
                                          new Type[] { typeof(Char) }, null));
}

private static void GenerateReadInstruction(ILGenerator ilGen, FieldInfo pointerField, FieldInfo memoryField)
{
    ilGen.Emit(OpCodes.Ldsfld, memoryField);
    ilGen.Emit(OpCodes.Ldsfld, pointerField);
    ilGen.Emit(OpCodes.Ldelem_U1);
    ilGen.Emit(OpCodes.Call, typeof(Console).GetMethod("Read", BindingFlags.Public | BindingFlags.Static));
    ilGen.Emit(OpCodes.Conv_U1);
    ilGen.Emit(OpCodes.Stelem_I1);
}

Part 4 covered these two, but now it gets a bit interesting. We need to call a method, Console.Read and Console.Write.

OpCodes.Call expects a MethodInfo and optionally an array of Types.

For Console. Read, We get the Console Type through typeof. Then we get a Method called "Read" which is defined as Public and Static. We pass this to the Call opcode. Console.Read writes it's return value to the stack, so we convert it to a Byte again and store it in memory[pointer].

With Console.Write it is a little bit more complicated because there are a lot of overloads to this methods. Remember that overload resolution is a convenience function of a compiler - as we are generating raw IL we need to precisely define which function we want to have. So we start again from the Console type, getting a Method called "Write". The fourth parameter is an array of types: The Argument signature. As we want the Console.Write(char) overload, we create a new Array containing the Char type. How do we pass parameters to Console.Write? By putting memory[pointer] onto the stack before.

[ and ] instructions
Part 5 covered the while loop. As you know, we need to create br instructions to jump into some parts of the method. Do we have to dynamically calculate the locations? No, we don't.

Add a new field to the BFCompiler class:

private readonly static Stack<System.Reflection.Emit.Label> _bracketStack = new Stack<System.Reflection.Emit.Label>();

Then add this instruction to the Compile method:

public static void Compile(string assemblyName, string outputFileName, string sourceCode)
{
    _bracketStack.Clear(); // Ensure that the BracketStack is clear (if Compile is called multiple times)

Then add these two methods to implement the [ and ] commands:

private static void GenerateOpenBracketInstruction(ILGenerator ilGen, FieldInfo pointerField, FieldInfo memoryField)
{
    var firstLabel = ilGen.DefineLabel();
    var secondLabel = ilGen.DefineLabel();
    ilGen.Emit(OpCodes.Br, secondLabel);
    ilGen.MarkLabel(firstLabel);
    _bracketStack.Push(firstLabel);
    _bracketStack.Push(secondLabel);
}

private static void GenerateCloseBracketInstruction(ILGenerator ilGen, FieldInfo pointerField, FieldInfo memoryField)
{

    var secondLabel = _bracketStack.Pop();
    var firstLabel = _bracketStack.Pop();
    ilGen.MarkLabel(secondLabel);
    ilGen.Emit(OpCodes.Ldsfld, memoryField);
    ilGen.Emit(OpCodes.Ldsfld, pointerField);
    ilGen.Emit(OpCodes.Ldelem_U1);
    ilGen.Emit(OpCodes.Ldc_I4_0);
    ilGen.Emit(OpCodes.Bgt, firstLabel);
}

This looks terribly complicated, but it's relatively simple. We are essentially implementing a GOTO. But we are not jumping to an address, we are jumping to a Label. The [ instruction defines two labels, firstLabel and secondLabel. These are essentially just uninitialized variables. We then emit a jump to the secondLabel - this is not defined yet, but it doesn't have to be.

MarkLabel then defines the Label firstLabel at the current location in the method. But wait, something is missing: We need to define secondLabel and we need to jump back to the first Label. We do this on the ] instruction. But we somehow need to pass the two labels from the [ to the ] function, and we need to support nested [ ] loops. This is why we defined a Stack<Label> in our Compiler: Whenever [ is called, we push the two labels onto it. Whenever ] is called, we pop the last two labels out of it.

So with the two labels available to the ] instruction, we mark the location of the secondLabel, then generate the comparison of memory[pointer] with 0. What we do was outlined in Part 5: If memory[pointer] is greater than 0, we jump to firstLabel.

Compile your Application again and run the compiler on hello.bf again. If everything went fine, you should now be able to run the generated hello.exe and see a satisfying "Hello World!" on the console.

Congratulations - you now have a BF compiler that generates a .net Console Application!

You can find the source code as a Visual Studio 2010 solution on http://github.com/mstum/bfnetc

This could conclude this series, but I'm going to write a Part 7 containing a few more considerations: EXE vs. DLL, Release vs. Debug builds and some more.

Now, while there may be a chance for IronRuby to survive, I personally think it's not something that Microsoft should do, so I think it makes sense for them to kill it off internally. Same for IronPython. I think the DLR is a great addition to .net though, and I think there is a far better language already available.

JavaScript.

Many of us perceive JavaScript as a Browser-only language that is hampered by different implementations in different Browsers (textContent vs. innerText anyone?), something which is being addressed through the use of frameworks like jQuery.

But think it one step further: How many languages do you need to write a Web Application? At least two: JavaScript and whatever backend language you use, for example C#, Java, Ruby or PHP. How do you write Form Validation? You write separate Code for the Client Side and for the Server Side so that users get instant feedback without being able to compromise the system by turning JavaScript off. This is stupid and a severe violation of DRY. Also there are subtle differences between the Code, for example because JavaScript's RegEx Engine works slightly different than the .net one.

.net is at it's core a language-independent technology that doesn't only support but encourage using multiple languages. Sure, there are only 3-4 really supported languages which are rarely mixed (Some people mix C++/CLI with C# or VB.net for some COM stuff, or F# with C# for financial/statistic stuff) and some languages that have some limited support (Boo is my favorite in this category).

So why not do what's logical and embrace JavaScript as a Server-Side technology? Node.js arrived recently and showed it's possible. Microsoft already somewhat supports JavaScript in Visual Studio (although the experience is far less than stellar) and they even had their own bastard child in form of JScript.net.

There is a big discussion whether or not C# is a good language to write Web Applications in. People point at Cucumber and talk about how great Ruby works with the Web while C# feels like a chore because of it's static typing, verbose Syntax and need for IoC Containers to do Unit Testing properly. Other people point at the insecurity of dynamic languages, about the lack of compiler errors, about the confusion created by not having to declare variables which leads to subtle bugs like `$total = 0; foreach(item in items) $totel += item.price`.

I say: Use both. Use C# for your backend code, for your Business Classes. Get Compiler Errors when you screw up. Make sure everything needs to be explicitly casted to whatever it has to be and that all variables have to be defined officially before use. For the frontend, use JavaScript. Create your Views and View Models like you would create them in the browser, through DOM Manipulation. Write and maintain your verification code exactly once, in one language, browser and server side. Feel free to whatever crazy manipulation you need to do without having to declare and cast tons of variables. If you screw up, it's "only" your Views, not your data structure because that's C# code.

Utopia? Maybe. JavaScript is not without it's faults and it may not be as elegant as Ruby in places. People would have to learn two languages, and people may ask "Why should we switch to an insecure language if C# served us well for years?" - well, the latter people are usually the ones who don't think they need Unit Testing and believe that WebForms is a perfectly good technology, so let them continue to use it and let the rest of us move forward to face the challenges of 2010 and beyond.

Customers want better apps. They want AJAX, they want snappy, cool looking UI. The Browser market is not a "Make sure it runs in IE and doesn't suck in Netscape 4.78" market anymore. We need to create cool apps, and we need to run them on Internet Explorer, Firefox, Safari on OS X, Safari on iPhone and Android. Our Web Apps need to do more in less time.

And Microsoft is in a great position because they have the foundation already built. Make Visual Studio a kick-ass JavaScript Development tool and bring it to the server side. Give us great debugging because even with FireBug and the IE Development Tools, it still sucks. Look what Node.js did. Look what you are doing with Internet Explorer 9's JS Engine. Look what you have with Active Scripting and look what you did with JScript.net.

It's incredible to see that Microsoft has all this technology already lying around and that no one had the idea to just combine them all together for ASP.net. Sure, Internet Explorer got a lot of (well deserved) crap for issues in it's JavaScript implementation, but IE9's previews look really promising.

Because let's face it: Any .net Language not supported by Microsoft in Visual Studio is doomed.

Checking if a bit is set:

// AND: Only return 1 if both bits are 1
// 0011 & 0100 = 0000
// 0111 & 0100 = 0100
isSet = (value & 0x4) == 0x4;
isSet = (value & 0x4) > 0;

Setting a bit:

// OR: If either operand is 1, return 1.
// 0011 | 0100 = 0111
newvalue = oldvalue | 0x4; // |=

Unsetting a bit:

// NOT: Invert the Bits
// ~0100 = 1011
// AND: Return 1 if both bits are 1
// 0011 & 1011 = 0011
// 0111 & 1011 = 0011
newvalue = oldvalue & (~0x4) // &= ~0x4;

Toggling a bit:

// XOR: If both bits are equal, return 0
// 0111 ^ 0100 = 0011
// 0011 ^ 0100 = 0111
newvalue = oldvalue ^ 0x4; // ^=