Category: Programming

OK, it isn’t exactly broken, it just doesn’t know about vista’s virtual path features. This means you can run the exe as a non-admin user and it does not get installed properly.

The work around is to not run the installer as a regular use and wait for UAC to invoke itself. It never will. Instead, save the .exe file and right click on it and choose "Run as administrator…"

Now the program will actually get installed to C:\Program Files or C:\Program Files (x86) instead of the virtual are c:\Programs\data\user\blah\wahterver\it\is\vista\has\some\crazy\features.

Why am I using GIT? Well, unfortunately because I have to. Cloning was easy enough but just typing git help or git help clone and I immediately miss the polish of bazaar. The "I have to" is in reference to the no longer ignorable myriad of projects now hosted at github. IMNSHO all of these should have opted to be hosted a launchpad. But as we have seen in the past in technology, the best solutions don’t always win. Sometimes the solution with the loudest voice wins. (VHS>Beta?) (DAT>DCC?) (Blueray>HDDVD?)

I replied to a blog post by Tosos over here:

The reply was long enough that I thought it warranted posting here too. I expand on why “var” is not dangerous and can go away. I also describe why it isn’t duck or dynamic or anything but strong and static. If you know F# this is nothing new to you.

Here it is:

I love these.

@Mike Borozdin:
Consider F#’s definition of methods(functions). It is just as strongly typed as C#, yet the compiler is left to infer the return type.

In the example above the return type is not weak, it is not vague or dynamic or relying on duck typing. The return type is the anonymous type defined by the select clause of the linq statement. All of the static type checking and strength of warnings and errors of the compiler will still occur.

I’d like to see similar syntax, but drop the var, it is needless noise.

e.g.

public GetFirstPageOfFiles(string dir)
{
  return Directory.GetFiles(dir).Take(10);
}

The signature of the method GetFiles takes a string and returns a string so we (and the compiler) KNOWS that GetFirstPageOfFiles returns a string.

But have we simplified the language as much as we can? F# wouldn’t make me specify the type of the argument to the method. It would infer it.

public GetFirstPageOfFiles(dir)
{
  return Directory.GetFiles(dir).Take(10);
}

Again, the argument to GetFiles is string so the compiler knows how to turn the method signature of

public GetFirstPageOfFiles(dir)

into

public string GetFirstPageOfFiles(string dir)

Where the compiler can’t infer, it should give an error and require the explicit use of the type.

This exactly the behavior of var now.

As for #3, I would NOT want this to be the default behavior. The default behavior should be strong-static types. As strong and as static as possible. That said, some compiler support for the equivalent of duct typing via reflection would be rather nice. AFAIK what you are asking for is already available through a 3rd party library from David Meyer at http://www.deftflux.net/blog/page/Duck-Typing-Project.aspx

With respect to default behavior being duck, Phil Haack is wrong, everyone is wrong. If you want that, use Iron Ruby or Iron Python.

I wrote about my uncertainty about the GetEnumerator duck here: http://jrwren.wrenfam.com/blog/2007/07/21/c-has-duck-typing/  It may have been necessary. If it wasn’t necessary, I’d call it a mistake. Maybe it was an accident. I don’t know.

Could I be more against duck typing? Yes, I could be against it entirely. I could completely misunderstand it. Unfortunately I’ve written in duck languages. I’ve probably written more code in PHP, Python and Perl than I have in C#. (I wrote A LOT of Perl and PHP.)

My simply request is to require the manual selection of behavior of duck, like Boo. Yes, I say “like boo” a lot, but much could be learned from boo. Boo had extension methods before C#. Boo has duck in a strong, static typed language. Of course, boo is not a special case. It is best to learn as much as possible from neighbors so that you can make your own decisions about things. My request is probably going to be granted. Charlie Calvert wrote about the dynamic keyword and dynamic blocks as a possible solution to this.

I do not write business applications. Oh sure, I write applications for a business. This business makes money. The applications which I write helps them make more money. However, these applications are in the domain of product engineering. They are not in the domain of running the business. They do not deal with cash flow, inventory, accounts receivable or payable. There is no letter opener of death involved with any of my application users.

My applications have no Business Logic. The business processes could change at this company and my applications don’t know anything about it. We solve engineering problems. That said, separation of UI and Business Logic is still a strong concern. It isn’t Business Logic. It is Application Logic.

Why mention this? I feel like there are programmers out there who say to themselves, “I do not write business applications, therefore this silly separation of business logic does not apply to me.” These programmers are wrong. Separation of application logic from UI code is valid not matter what the application. Separation of Concerns extends to every type of software. I cannot imagine a type of software from which separation of concerns does not benefit. I’ll go so far as to say that if you think you have a case: that you are wrong. If you think you can justify it to me, I will simply redesign to a case which does fit.

Do you write math apps?  Separate your Math Logic from your UI.

Do you write engineering apps? Separate your Engineering Logic from you UI.

Do you write medical apps? Separate your Medical Logic from your UI.

Do you write biology apps? Separate your Biology Logic from your UI.

Do you write Anthropology apps? Separate your Anthropology Logic from your UI.

Do you write Sociology apps? Separate your Sociology Logic from your UI.

Do you write Psychology apps? Separate your Psychology Logic from your UI.

Do you write Legal apps? Separate your Legal Logic from your UI.

Do you see a pattern here? Separate your seeing of patterns from your UI.  Good.

I previously had a list of things I wanted. Yes, I am like a 2-year old. I want. I want. I want.

mdavey posted a link to a channel 9 video which made me rethink my request. Oh I still want all of the original list and… I want more. I want more. I want more.

• List Literals – it is silly that I even have to request this
• Dictionary Literals – see list literals for comments
• Extensible Literals – the .NET BCL already has this really great type conversion system. You ask for a type converter for a specific type and whether or not it can be converted between two types. One of these types is often a string. You can write your own converters and register them with this system of type converters. It is very elegant and beautiful. The compiler should use this to let me express my own literals. Type initializers are nice, but this would be nicer.
• Variable Generic Type Parameter Arity – Chris Marinos had a use case for this and had to implement a solution in a much less elegant way because he was missing this feature. Its a request in Java too. Cliff Biffle says that Mongoose has them, but I can’t find whatever became of the smalltalk inspired language.
• Restricted Types – The same post on Variable Generic Type Parameter Arity, Cliff reminded me of my favorite Modula-3 feature. He points out that Dylan has it. I like Modula-3’s approach to this using Subtypes. This paper by Cardelli, Donahue, Jordan, Kalsow and Nelson does a great job of explaining Modula-3’s simple but powerful type system. Not all of the subtypes in M3 make sense in a .NET world. We already have a well defined type system and some of the constructs would not mix. One concept that I think would mix well is range subtypes. Imagine that you know a value is always going to be between zero and 100. You can define a subtype of int and use that type throughout your program. The compiler actually checks that variables of this type are never out of this predefined  range. Type Conversion is automatic from int subtype to int type, but not the other way. It is awesome if for nothing other than eliminating IndexOutOfRangeException on array indexers.

Yes, I do want my cake and to eat it too.

I hate xml.

: Now that isn’t to say that XML is never the right technology for a given problem. I respect it for those cases.

However, XML is overused. Its used where it shouldn’t be.

So here is to 10 years of XML.

Thanks to Vikas for pointing it out.

I work with some great people whose initials are BWW, DWH, etc. They already comment up a code base which I inherited with their initials. Visual Studio’s Task List feature lets me get a list of all of these comments just bad adding their initials as tokens.

I’ve also added a token named “SMELL” for when I see something I think is code smell, but I cannot fix it immediately.

Now, my proposal is for teams to exploit this feature. A small team could easily get all of the initials of its team mates and add them as tokens and then export only the Task List settings from VS and post that to their web site, repository, wiki, whatever for all of the team to download and import into settings.

This might be a cool team feature for teams who don’t have blame setup in their source control management system.