Thursday, October 25, 2012

Rant time, a very special episode of Bytecruft.

It's rant time..

I know it's so usual for us nerd/engineering types to get cranky online about something, so this may come as a shock....

I came across a post today on Hack a Day today about a guy who got the .Net Micro Framework running on a STM32F4 Discovery Board, something I have done, and briefly mentioned here.

Original link.

Mr [Singular Engineer] did a fantastic write up by the way, I wish that had existed when I was trying to get up and running, it sounds like his experience was slightly smoother than mine.

Anyways, as I read the comments section on the Hack a day article, I felt compelled against better judgement, to reply to some of the general criticisms against the .Net Micro framework. As my reply grew in the volume of prose, I thought, maybe it would be better presented on my blog. So here ya go:

I know this is such a loaded topic, so I'm hesitant to even reply, and yet... One should use the right platform for the job. C# is such a pleasure to work with, and the .Net Microframework is fantastic. There is such a stigma around anything Microsoft produces, that a lot of actually great technical innovations get lost in the chaff. I tried the same thing as this guy a couple months ago on this Discovery board(I wish I'd had the motivation to do as nice a writeup as he). In the end, I went with a RTOS/C++ route because the speed and resource overhead was too great for my need. Many people seem to not realize that Microsoft has open sourced the .Net MF, so if there is anything you don't like, *you can change it*. Microsoft even provides build scripts for building the framework with GCC.

You can also write your own drivers or extensions in C/C++, so write you code that needs to be high performance in C, and write your large scale application's logic in a modern language that lets you express your design in an elegant and straightforward way so you can focus on features instead of chasing corrupted pointers, array over-runs, mysterious deadlocks, and race conditions.

I'm troubled by the pervasive attitude in software engineering, and in embedded systems/gaming in particular, that somehow because a modern language/platform makes certain things easier, that it should be the domain of "novice" programmers, or those who somehow couldn't cut it.

[And here's where I decided to make this a blog post, instead of a comment on Hackaday, I didn't want to write 'bullshit' on someone else's website :) ]

Bullshit. Just because I know how a heap works, and can write my own string or collection classes or reference-counted auto pointers, doesn't mean I gain anything by doing so. In fact quite, the opposite is true, a "roll your own" API/framework has a much greater chance of having a bug than a proven API used by the masses. I may be a wiser, more proficient developer for knowing that, but it doesn't mean I'm working smarter by doing things the hard way.

I hear the same tired arguments against "managed" languages, but I'd bet a bitcoin 95% of the people speak not from experience with the technology, but from regurgitated myths and misconceptions.  Some may counter-argue that there's plenty of 3rd party, stable frameworks for C++, and I hear you, I live and have lived in that world for a long time. Problems is, you have to integrate those frameworks, and then you have overlapping, duplicated functionality, and you have to write a lot of glue to integrate those APIS (convert a fooString to BAR_CHARPTR_REF, etc), and then you're back to the same issue.

I've lived in many programming ecosystems over the years, I wrote my first line of code 30 years ago (wow, really? yikes). I wrote my first line C about 20 years ago, and have worked on many platforms; from Windows PC's to *nix servers to video game consoles to mobile phones and embedded systems.  I still write and (disproportionaly) debug C++ almost every single day at my current job, I do C# work on the side, and currently in my spare time do everything from assembly, C/C++, C#, Java, Scala, Python, SPIN, Pawn, to GPU shaders to VHDL, and probably some I haven't thought of. Everything has a right tool for the job. C# is the default "goto"(pun alert) language for anything on a desktop computer because the shear speed at which you can "get things done" in a maintainable, clean, concise way in unmatched in any other tech I've used.

In some embedded and extremely constrained systems, overall performance and resource consumption often become overriding factors. As much as I admire the .Net Framework, it was not the right choice for my recent embedded application because of those factors, so I went with what was appropriate for the task.

I get flak at times for my position on C# and the respect I have for it, but I make it a point to remain open minded about technology and to recognize the applicable opportunities and liabilities of all technology considerations. Every time I read a comment about being "locked in" to Microsoft, or ignorant stabs at garbage collection, I build up a little steam. Why is it so much easier for people to shoot from the hip in debating something than to spend a little time learning about the subject matter? You don't have to spend 10 years, 10 minutes with Google can dispel much of the junk that gets repeated over and over.

I expect to convince precisely no one with this, you can't "win" on the Internet. So now I just released all that hot air that had been building up for a while, I feel much better. I'll hang up now and listen to your answer. Peace.


PS. As a side note, one of the additional reasons I decided to not go with .Net for the board was that the firmware build, same one used by "Singular Engineer", is a nice, prepackaged binary, you don't have to build it yourself, but it you want to change anything, add drivers, native code, etc, you would have to build it yourself. I didn't want to do that.

PPS. I don't mean to single out the comments on Hack A Day, it's a general software nerd thing.


  1. Thanks for acknowledging! People are smart, but sometimes lazy to follow textual instructions which lead me to make a lot of screenshots than words. With your comment on Hackaday i was able to find your blog. You got pretty cool stuffs going on! Good luck with your robot (you got a lot of features added to it!). Looking forward for your robot to be born.

  2. Thanks! What are your plans for yours?
    One of the peripherals I use is an SPI serial Nokia knockoff LCD. It's got a 9 bit protocol(who does that?), which the STM hardware does not support, and I had to bit-bang the protocol. There's just no way I could have done the bit banging at the .Net level with reasonable speed. I tried using 16 bit, since I read some devices will just read the most recent bits shifted in when the CS line goes inactive, but that didn't work.


I welcome you're thoughts. Keep it classy, think of the children.