Interesting word choice…

Some of the spam I get turns out to be pretty amusing… I just take a walk now and then through my spambox, just to see what sort of goo is being thrown around lately… Today I stumbled into something that really made me laugh. Here’s a quote from an ‘OEM-priced’ software company’s wonderful flyer explaning how they are able to offer such spectacular prices on good products:

It’s easy to miss it in the list of stuff that isn’t included…. that’s right folks, they sell you software without a BULKY license! Why didn’t I think of that?! Sounds so… portable! With shipping costs sky high like they are these days, you can save a bundle by eliminating the middle men… but the real savings come when you take the manufacturers out of the equation too!

Even the Development world is Round…

So now with the market advent of Microsoft .NET 3.0, the diffusion of the the ‘example videos’ and sample tutorials is rampant. In particular I’ve been reading a little about Windows Presentation Foundation (WPF). The WPF is basically a fusion of concepts from winforms and asp.net (a la XAML) in that the controls are declared for line of business type applications (smart/thick client apps) using an Xml-ish markup language. Something that seems like a joke to me (though it’s a welcome addition, like an old friend) is this ‘new’ idea they have for these things called ‘commands.’ Now get this… commands are event handlers… They can be fired from anywhere, and when you call one, it executes the code in the event handler! Amazing! I can’t help but think… They used to have something like this way back in the stone age of programming; I think it’s called “Procedure Oriented Programming!” So, we see that even the programming world is round, and even though we’ve sailed pretty far we’re not really in exotic India afterall, just somewhere off the coast of Florida… so watch out for hurricaines!

More Powershell coming soon…

I want everyone to know I haven’t given up on powershell, but I just have been distracted by production projects at the moment… I will continue to report as I learn more, and experiment some more. (Please don’t hate me powershell!)

What I want in a .NET programming language:

Some thoughts here. I’m starting with C# as the ‘base’ language here, because mostly I like it. I’d just like to see some changes. Most of these are in Nemerle… some of them are not.

Static methods which take only the type of object to which they belong as a parameter can be called on instances, even null ones, and the compiler will be smart enough to figure out that it just passes a null parameter to the static method.

Like this:
if (MyString.IsNullOrEmpty)

There is no point to having to write if string.ISNullOrEmpty(mystring)… useless extra drivel and confusing to people who don’t already know what that means. Sure Static methods go with the ‘class,’ but we’ve just told the compiler what sort of class we have when we declared the variable… so let it use that information instead of us developers having to write it again.

Values will be True if they are not Default. if(MyString) means if MyString is not null. This functionally can be defined and overriden for custom and inherited classes.

int x = getSomeIntegerFromSomewhere();
if (x) means if X is not zero.

Null means the same as Default. Value Types can be null. This is useful in generics.

Compiler will allow more generic (covariant) parameters in delegates even if a matching signature isn’t found for all cases. An exception will be thrown if you USE a signature that doesn’t exist, but not just because you theoretically COULD:

For example:

public delegate string GetStringDelly(object value);

public string StringFrom(int value);
public string StringFrom(double value);
public string StringFrom(DateTime value);

All of those are valid targets of the delegate as long as you only pass those types of values, the compiler is happy and you suck if you violate the rules. If you pass in a byte[], eat error, you deserve it. This is allowed so that we can store delegates in a hash table, and have each one call a different signature. Like a switch statement on steroids.

None of this operator overloading bullsh*t. If an operator doesn’t have a standard meaning, then it will confuse the daylights out of people. Sure it’s fun for the obfuscation contests. Name your METHOD something useful or make a MACRO.

Macros are legal, and can be used as inline syntax in your code. Yes. You too can extend the language Not because you feel the urge to write a language, but becasue you need the shorthand.

A function is a valid value. You can declare delegates, yes, but also define functions as parameters and values inline.
This also implies that I can finally use Properties of instances as Output parameters in functions. Can I tell you how much I hate stuff like this:


string SomeDateString = GetADateString();
if( !string.IsNullOrEmpty(SomeDateString))
{
    DateTime attemptedDate = new Date();
    if (DateTime.TryParse(SomeDateString, out attemptedDate))
    {
         MyPerson.DateProperty = attemptedDate;
     }
}


it should be more like:

DateTime.TryParse(SomeDateString, out MyPerson.DateProperty);

You can access properties of classes by string name at runtime without killing the system performance, or requiring extra permissions. If you don’t have the permissions. Dynamic calls and accessors respect conventional access methods. Meaning if the developer marked it as internal, and you are not in their library, you cannot ever gain access to it. Ever. Never. Why reflection in .NET lets you get at things you shouldn’t be able to is a mystery to me. It’s useful sometimes, but it’s a bad idea. Really. If you ever find this to be ‘useful’ and you put it into production code, you’re asking for trouble in maintenence. I mean, the exposed namespace is what you’re supposed to see, and thus, what the library writer will leave intact, or likely so, in future versions. If you go poking about in private methods and fields, and it breaks, that’s your own lookout, and you shouldn’t be able to break the rules that the original developer set for you.

Code generation at runtime is legal, and can happen without full trust. Certain functions or methods will not be accessible to generated code, but you can do the basics without full trust. This runtime generated code cannot be persisted to disk, and cannot be called by other assemblies other than that which has generated it. The fact that you can’t, and that say.. the XmlSerializer can really BOTHERS ME!

Interfaces can contain static members as well as access modifiers in any place that you can write them in a class. Why not?

This is shaping up to be a cross between Nemerle and what I think c# 3.0 will be… with of course a few differences. It is a mix of concepts between ML, OOL, and dynamic languages that simply would make my life grand.

I’m on the fence about type inference… but sure.. why not. Throw that in too.

Eval() is implemented, but only for numeric and string expressions.. you can’t call methods of classes other than operators that are defined by the system… no going and injecting things into custom operators, because you can’t overload them. You cannot call macros in Eval().

Lazy instantiation can be declared in the same way that Nullable<> is currently in c# 2.0
Lazy<Person> p = null;

p.Address = foo; does not throw an exception, becasue I declared it as LAZY. It will call the default constructor, and then perform the assignment.

I know that a lot of this would be tough to have in the same language, and why don’t I ask for a villa on the moon while I’m at it? But, I’m just hypothetically postulating here… Nobody has to listen to me… I’m not asking YOU to write this language, I just want to explain what I feel are shortcomings, and say what I’d like to see.

Maybe I’ll just switch to Nemerle, and write a lot of macros.

XmlSchemaProvider and the Duplicate Namespace problem SOLVED

Ok. I’ve hated, despised, abhored, and feared the XML schema provider and using the XML SOM to generate schema because the thing makes you use separate namespaces for EVERY single thing… right?

WRONG!

There is a tiny little trick, that just about EVERYONE misses that lets you get away with MURDER. Even though in this case it should technically be legal.

In the Schema provider static method, you have to initialize the XmlResolver of the schemaset like this:

I now feel like it does what it’s supposed to do.. but jeeeeeeeez, it shouldn’t be so hard to find this information.

Edit: I did see this on MSDN’s example code… but the entire explanation therein failed to mention the monstrous importance of the fact that you MUST initialize that resolver if you are going to be able to survive this venture. I for one don’t automatically copy and paste code unless I see some value in it at the time, so when I read that about a year or more ago, I didn’t see it explained, and I didn’t realize why I was in such a hole until… today at 3:30pm. I looked over the whole thing again, for the 20 millionth time, and this time I saw that stupid line… none of the articles I’ve seen anywhere (and thus my own on DevX) included this little tidbit, so I feel this burning desire to highlight it. Excuse me for a bit while I get very angry at nobody in particular for no good reason at all. Things like that just frustrate a person. I won’t blame microsoft like you’d expect me to. So there.

More on PowerShell… My first script.

Ok, in case you missed it, don’t want to read it, in my last post, I’ve been looking at PowerShell now. Since I’ve had so much use for VBScript in the past, and I really like .NET, it seems like a good match.

PowerShell is .NET Based, which is something I like, because I have lately come to think in objects, and it works for me. This may also be a good path for developers to get FROM scripting into .net programming eventually. (Though all of the systems admins who turn into programmers surely leave behind many broken hearts, especially managers’.)

It’s extensible, meaning that with a quick flick of visual studio and a once over of the API documentation, you can write your own .net cmdlets (command-letz) that will allow you to effectively extend the ‘language’. This is all a feature of the dynamic linking style that .NET affords us, so while it’s billed as a new feature of the scripting architecture, it’s really just a sort of modified duck typing that hides .NET’s normal modus operandi not too far under the covers.

You can make Aliases, or shortcuts for the otherwise seemingly longwinded names of commands. I’m not sure I really get the idea behind the ‘must use a verb, must use a noun’ when defining cmdlets, but I suppose if the idea of programming is foreign to you, they can tell you any rules they want and that’ll be ok with you.

REALLY cool feature number one: They’ve unified the concept of browsing a filesystem with browsing a ’something’. In this case the ’something’ can be (out-of-the-box) a registry hive or a filesystem. Very handy.

REALLY cool feature number two: ADSI and WMI have integrated syntax. Just prefix your objects instantiation with either and you magically have a data source seemingly out of thin air.

I also like the structure of the code. It’s block-scope-oriented like any of our ALGOL descendant friends like C, C++, C#, and Java, but duck typed like our other languages Python and Ruby (or variants in vb-like languages)

I was playing with the bit, just for fun, and here’s what I have:

You’ll see that the variables aren’t declared before they’re used, and the types aren’t specified. You also can see that accessing the ADSI WinNT provider (which appears to be named after a bad, old, joke) is as simple as a set of bar brackets and a quoted path. This is just my first little test bit here, but things are going to hopefully move on pretty quick.

The next topic I want to investigate is the enterprise deployment of the powershell runtime. I’m guessing, and this is just a guess, that since the intention was to originally have PowerShell as a default component of the Vista OS that this topic will have already been given much attention by the folks at Microsoft.