I recently read a post by someone lamenting the thanklessness a programmer gets. I once worked in IT where services are really considered a utility. No one calls the utility company unless there is a problem. Have you ever called your electric, phone, or gas company to thank them for the great service? I didn’t think so. This was my response:

Sounds like a bad environment. For a long time now, I’ve worked on teams where we are our own worse critic and where I’ve received more thank you emails than criticizing emails. That said, I don’t consider error reports to be criticizing emails. They are just that, a report of something which went wrong. Things always go wrong, not just in programming. In business and in life, something will always go wrong. How you respond to the wrong doing can largely influence your happiness as a human being.

Sometimes mind shift has to happen to really make this effective. Things like http://www.c2.com/cgi/wiki?EgolessProgramming can help you remember that you are not your code. Error reports mean that someone care about what you created and wants to help you make it better. That is awesome. I’d love much but maybe not too much of that kind of feedback.

When Reversing the Interview Process becomes How Would You Do Fun Things in C

My boss’s boss’s pals wrote this: http://blog.exodusintel.com/2012/09/18/reversing-the-interview-process/

Its a story about how someone was asked a crazy fun C question in an interview and how the new team decided to try it.

After reading this and discussing it with coworkers, I decided to try it and of course the first thing that came to my mind was a way to use tail recursion to do it.

 1 #include <stdio.h>
 3 int c;
 4 //auto func0 = [&] () -> int { c++; _strlen(s+1);};
 5 //auto funcn = [&] () -> int { return c; };
 6 int rs(char* s);
 7 int go(char* s) { c++; return rs(s+1); }
 8 int ret(char* s) { return c; }
 9 int rs(char* s) {
10     int (*func[2]) (char *s) = {ret,go};
11     char i = (*s>>7 | *s>>6 | *s>>5 | *s>>4 | 
        *s>>3 | *s>>2 | *s>>1) & 1;
12     return func[i](s);
13 }
14 int _strlen(char* s) {
15     c = 0;
16     return rs(s);
17 }
19 int main(int argc, char* argv[]) {
20     printf("_strlen(%s): %d\n", argv[1], 
21     return 0;
22 }

After writing it, I went and looked at the other fella solutions for the second time. I should also mention that I haven’t written C on the job in 11 years, and when I did then, it was one tiny program which was quickly replaced with perl. I have never been anything other than an intro beginner C programmer.

Things I noticed after going back is that my solution is somewhat similar to Brandon and Zef’s solution, but I think both my use of function pointers and bit shifting are more elementary. I’m still not sure about how some parts of their solution works.

Are Access Modifiers Antiquated?

I just wrote a rather lengthy reply to a Programmers StackExchange question which I’d summarize as “why are the types and or methods I want to extend often sealed in common Java and .NET frameworks and libraries?” Its actually titled “Why shouldn’t classes be designed to be ‘open’?’”

My reply is here:

Because they don’t know any better.

The original authors are probably clinging to a misunderstanding of SOLID principles which originated in a confused and complicated C++ world.

I hope you will notice that the ruby, python, and perl worlds don’t have the problems that the answers here claim to be the reason for sealing. Note that its orthogonal to dynamic typing. Access modifiers are easy to work in most (all?) languages. C++ fields can be mucked with by casting to some other type (C++ is more weak). Java and C# can use reflection. Access modifiers make things just difficult enough to prevent you from doing it unless you REALLY want to.

Sealing classes and marking any members private explicitly violates the principle that simple things should be simple and hard things should be possible. Suddenly things that should be simple, aren’t.

I’d encourage you to try to understand the viewpoint of the original authors. Much of it is from an academic idea of encapsulation that has never demonstrated absolute success in the real world. I’ve never seen a framework or library where some developer somewhere didn’t wish it worked slightly differently and didn’t have good reason to change it. There are two possibilities that may have plagued the original software developers which sealed and made members private.

1. Arrogance – they really did believe they were open for extension and closed for modification
2. Complacence – they knew there might be other use cases but decided not to write for those use cases

I think in the corporate framework world, #2 is probably the case. Those C++, Java and .NET frameworks have to be "done" and they have to follow certain guidelines. Those guidelines usually mean sealed types unless the type was explicitly designed as part of a type hierarchy and private members for many things which might be useful for others use.. but since they don’t directly relate to that class, they aren’t exposed. Extracting a new type would be too expensive to support, document, etc…

The entire idea behind access modifiers is that programmers should be protected from themselves. "C programming is bad because it lets you shoot yourself in the foot." It is not a philosophy that I agree with as a programmer.

I much prefer python’s name mangling approach. You can easily (much easier than reflection) replace privates if you need. A great write up on it is available here: http://bytebaker.com/2009/03/31/python-properties-vs-java-access-modifiers/

Ruby’s private modifier is actually more like protected in C# and doesn’t have a private as C# modifier. Protected is a little different. There is great explanation here: http://www.ruby-lang.org/en/documentation/ruby-from-other-languages/

Remember, your static language doesn’t have to conform to the antiquated styles of the code written in that language past.

Why I Love C# More Than I Care About Ruby

@robconnery I’m really glad that you are excited. I think anytime someone is healthily and safely passionate about something, it can only be a good thing.

Rob has a great post where he lists 4 cases where he likes Ruby and compares to the same thing in C#. Case 1 Expressiveness: Rob likes the unless statement and the post expression if statement. Case 2: Rob likes Gems. Case 3: Rob likes simple things. Case 4: Rob likes sending messages, open classes and method missing.

Python and Perl already did all this, so why Ruby?

Case 1 and 3 were true in python when i started writing it in 1996 and case 1, 2 and 3 were true in perl when i started writing it in 2000. I’m sure case4 is true in both python and perl too, but I never went that deep into either of them. Much like in Ruby, you don’t have to go that deep to get things done.

I am of the opinion that if you have never seen a dynamic typed language before, or maybe a dynamic typed language other that BASIC or VB before, that Ruby has all of the appeal which you tout. However, there are some of us who write C# because we actually like it, we write desktop applications, and find it to be the best static and strong typed language around. We came to C# and were super impressed because the weak typing of C wasn’t there. The rough edges of C++ wasn’t there and for nearly all applications there is no performance difference and sometimes the GC and managed environment actually gives a boost in performance over some of the bad C++ we were writing before.

So should someone who has never written in Perl, Python, Pike and PHP go try out Ruby… absolutely… get the exposure.

Alternatively, if you have done some Perl or Python and now you are a C# guy. Ruby might not seem so impressive. In fact, it looks more like the same thing with a new coat. I can’t tell what the hype is about. There isn’t much new and different.

All that said, after years of Perl, learning C# was a challenge, especially since I was using it to solve many of the same problems for which I had been using Perl. WHY? was I doing it that way? Well I wanted Windows Forms UI front ends on my Perl versions of programs there were ultimately just sed/awk/grep and some ldapsearch/ldapadd/ldapmodify commands. Not commands really, but calls to libraries.

There is a good reason that the “simple things” aren’t AS simple.

What I learned was that there is a damned good reason that Case 3 “The Simple Things” were a little more complex in C#. The separation of stream and textreader abstract types in C# make huge sense once you realize that doing the same thing in perl or python (or ruby) can be a bit of a hassle. The organization of decorator streams in the .NET BCL just makes sense. Want to compress? Decorate with the stream compressing class. Want to encrypted? Decorate with the stream encrypting class. Want to do both? In either order? Decorate appropriately.

I do share Rob’s opinion. It is a little prettier in Ruby. I’ve already gone on record as saying that “var” in C# should be optional. In VB6 the Let statement was optional. In VB.NET the Let statement is no supported. IMO C#’s var isn’t much different than VB.NET’s Let and Dim. Sure would be nice if it were optional.

I’ve also requested static imports so that we could do things like just call the open method instead of saying File.Open. When you are in a nice tiny singly responsible file, it just makes sense.

These things don’t change my ability to write code.

On .NET’s lack of a CPAN, Cheeseshop, Gem equivalent: YES! YES! YES WE NEED IT NOW!

I can’t say anything other than .net needs CNAN (comprehensive .net archive network) or maybe CCAN (comprehensive CIL archive network). I can’t decide which name I like better.

As for metaprogramming, I think that Python, Perl and Ruby’s ability for runtime metaprogramming will continue to be far beyond anything you see in the C# world. That is not say that metaprogramming is not possible in C#. Its just very different. Its typically compile time metaprogramming. Thanks to the addition of T4 in VS2008 and 2010, metaprogramming in C# is readily available and powerful.

I could go on and insert above about how I learned to love the .NET RegularExpression API after having it blow my mind in comparison to perl’s. Or about how poorly documented the System.DirectoryServices API is, but that once I got it I loved it so much more than Net::LDAP. Or about the extreme pain in building CPAN modules on a Sun Sparc and how installing Mono and using Visual Studio and C# was actually easier than making Perl work properly.

But rather than elaborate on those things, I’ll end by saying, yes, Ruby is awesome, if you have never seen any of the things which make it awesome before.

C# 4 Optional Parameters Limits Default Value

Jon Skeet has an excellent C# 5 talk video from the recent Norwegian Developer Conference. Go watch it.

When he showed Default<T>, I immediately thought it was just an variation of Option<T> or F#’s option type, but with added default value logic. Its cool.

He was asking for compiler support so that things like this would be possible.

Default<int> a = 1;

Well, I thought, you don’t need compiler support for that, just add an implicit type converter to your definition of Default<T>

        public static implicit operator Default<T>(T value)
            return new Default<T>(value);

No worries, right?

Oh I was so wrong. While this will work for the regular above statement, it won’t work as a default parameter value.

     class Things { public Things(Default<int> a = 5) { } }

This provides a wonderfully descriptive error (I love this compiler) which says “a value of type ‘int’ cannot be used as a default parameter because there are no standard conversions to the type ‘Default<int>’”

Now I’m crying? Why the limit? Instead of Jon’s request for awesome Default<T> support in C# 5, I request considering implicit type converters on optional parameter default values.

WlanChannelInfo aka Windows 7 Net Stumbler aka Wifi Channel Info

I finally got around to updating WlanChannelInfo. It started because I wanted to play with some .NET 4 beta features and I also struggled with getting a simple net stumbler running. I figured that Windows had to have something better to offer, and it turns out that in windows 7 the WLAN API was updated to expose everything that I cared about. I really only want to see what WIFI channel’s my neighbors are on so that I can move my WIFI AP to an unused channel.


I finally updated it to use a .NET release instead of a .NET 4 beta, but when I did, I decided that I didn’t need .NET 4. I just stuck to using 3.5 so that this app will run out of the box on Windows 7. No need to get .NET 4 to run this. I figure my parents might have windows 7 but probably won’t have .NET 4 installed just yet. Maybe someone else’s parents would have the same issue, and since the download is only 19KB… yes, 19KB… since the app is dead simple and does nothing but use existing WPF controls and p/invoke into the WLAN api (via the ManagedWifi.dll also on codeplex) its *TINY*.

Let me know if you find this useful.

Teaching New Programmers

I teach at a local community college. This semester I’m teaching one of a handful of sections called “Introduction to Computer Science”. This course is supposed to be a bridge course before throwing new students directly into the typical C++ Programming course.

The thought is that some students need a little extra help before taking that first C++ course. This course is intended to give them some intermediate information and some very basic programming introduction.

Since there are other sections to this course I’ve not had to make my own course material. I’ve used PowerPoint created by others. A few times I’ve had to say things like “Just ignore that bullet, its only true from a certain point of view.”

It wasn’t until the introductory C++ slides that I blew a gasket.

After a slide on “Documentation” with these bullets:

•A well-documented program is easier to understand and modify
•You use comments to document programs
•Comments should appear in a program to:
?Explain the purpose of the program
?Identify who wrote it
?Explain the purpose of particular statements

I advanced to this slide with an example of “good” comments:

int feet; //variable to hold given feet
int inches; //variable to hold given inches
int totalInches; //variable to hold total inches
double centimeters; //variable to hold length in centimeters

At this point I lost my professionalism a bit and cursed quite a lot. I ranted about how this was useless. I feel like a channeled a little bit of everyone who I’ve heard say “comments are evil”.

When I finally got to a complete demo program instead of a code snippet, It was time for conniption.

//named constants
const int CENTIMETERS_PER_INCH = 2.54;

int main() {
  //declare variables
  int feet, inches;
  // statements

For the love of programming will someone explain to me what value any of these comments have?

I can only hope that my ranting was not so extreme that students stopped listening. Hopefully they will all have a better understanding of comments and what NOT to do.

LINQ Abuse with the C# 4 dynamic type

With C# 4 adding some support for dynamic typing one of the first thing that I wanted to do is use it with LINQ.

I want to do this:

dynamic x;
var h = from y in x where y == 1 select y.something;

But I get error messages on both where and select that says

Query expressions over source type ‘dynamic’ or with a join sequence of ‘dynamic’ are not allowed

Major bummer.

But surely there is something I can do. 🙂

*the title of this post starts with LINQ abuse… please don’t comment about how stupid and evil this is. I know it. Instead, consider this an exercise in getting to know C# a little better.

The dynamic type is just sugar for the object type and some attributes to which the compiler pays attention.

Lets use object…

object things = new[] { 0,1,2,3,4,5,6,7, };
var whatIwant = from thing in things
                            where thing % 2 == 0
                            select thing;
// or if you like longhand:
var wiw = things.Where(thing => thing%2 == 0).Select(thing => thing);

How does this compile? Well, by making Where and Select resolve to extension methods on object instead of extension methods on IEnumerable<T> (which is what people USUALLY think of when they think LINQ).

public static IEnumerable<dynamic> Select(this object source, Func<dynamic, dynamic> map)
    foreach (dynamic item in source as dynamic)
        yield return map(item);
public static IEnumerable<dynamic> Where(this object source, Func<dynamic, dynamic> predicate)
    foreach (dynamic item in source as dynamic)
        if (predicate(item))
            yield return item;

Extension methods on object, then cast to dynamic (extension methods aren’t allowed on dynamic).

It should be short work to fill out whatever LINQ methods are necessary to make whatever LINQ expressions you wish work against dynamic (object) and now you can use LINQ with a source that is typed dynamic.

double.IsNaN is 100 times slower

Its not just your programming group that can’t get it right. I work in a semi-disfunctional group on contract for a client who, not matter how hard we try, doesn’t seem to listen to basic software engineering principles.

I feel a little better (and a great deal worse after thinking about it) when I see that the largest software company in the world deals with some of the same problems.

I found this gem in the WPFToolkit (it is MSPL) source.

// The standard CLR double.IsNaN() function is approximately 100 times slower than our own wrapper,
// so please make sure to use DoubleUtil.IsNaN() in performance sensitive code.
// PS item that tracks the CLR improvement is DevDiv Schedule : 26916.
// IEEE 754 : If the argument is any value in the range 0x7ff0000000000001L through 0x7fffffffffffffffL
// or in the range 0xfff0000000000001L through 0xffffffffffffffffL, the result will be NaN.        
public static bool IsNaN(double value)
    NanUnion t = new NanUnion();
    t.DoubleValue = value;

    ulong exp = t.UintValue & 0xfff0000000000000;
    ulong man = t.UintValue & 0x000fffffffffffff;
    return (exp == 0x7ff0000000000000 || exp == 0xfff0000000000000) && (man != 0);


My jaw was open pretty far for quite a few seconds as I read this.