I Think Perhaps I Also Just Don’t Like N-

by Jon Davis 29. September 2009 22:54

As I’ve been continuing to work on Gemli.Data, which has been continually been getting smarter and cleaner (last night I added to the dev branch the syntactic sugar of one-line loads and one-line saves straight to/from POCO objects) it keeps haunting me as it has since long before I even started the project that some people just won’t understand why I bother when there’s NHibernate.

I’ve briefly mentioned the main reason why I am not on the NHibernate bandwagon—that I find it has a steep learning curve and it’s cumbersome, even its Fluent flavor is cumbersome—but I think it goes a little bit beyond that. I think it has an ‘N’ prefix. And that bugs me.

It’s not just semantics.

Over the years in computer science’s past, the Java programming language picked up a few tools that were built for it, and were sometimes built for other environments but were re-tailored for Java, and these tools were prefixed with a ‘J’. This became a cutesy “I love my Java” naming convention for a few such tools. And then some of them learned C#.

So meanwhile in C#-land, we started getting these heavy duty toolsets that C# didn’t previously have, and they had either an ‘N’ prefix or a “.NET” suffix. NAnt. NDoc. NUnit. Lucene.NET. Spring.NET.

Every single one of these tools had one thing in common: they were ports! They came in from the Atlantic, hauling all their baggage and “cultural diversities” of Java into our world and showing little respect to the culture that was here. So to speak.

Truthfully, the people responsible for this had nothing less than the absolute best of intentions, and their efforts were both admirable and helpful to the computing society of .NET culture. We .NET folks, “Morts” that some of us were, didn’t really have much culture. Nor did we have discipline, as our culture and technical understanding of computer science were defined primarily by one single entity (which resides in Redmond, Washington) and its clients.

But these N-prefixed / .NET-suffixed ports seem just a little insulting to me; it feels like their creators are trying to tell us, “Here, Microsofties! Now you can say, ‘me, too!’” It’s not just hurt feelings, though. (LOL.) The ports themselves have language features that seem somewhat foreign to both traditional C# code as well as to what “could be and should have been”. This isn’t always the case, of course, but at times it makes me cringe.

So, putting things into perspective, why Gemli? Because I was here first, I was a native, and I want to play my little part, whether others participate or not, in shaping .NET to be, at least to me in my own little world, what I think .NET should be. It should be .NET. Not Java.

What does that mean to me? From the get-go, .NET had features Java didn’t have (although it perhaps now does), like System.Reflection which gives us the power to infer things, and System.Reflection.Emit which gives us the power to optimize on-the-fly (and which I’m not taking advantage of yet, by the way, but do intend to). Microsoft totally FAILED the opportunities, in my opinion, to exploit such things for tooling, while at the same time feeling free to exploit it with JITting and other areas where the CLR works in a more proprietary manner. But that’s fine, that’s where open source comes in. But you know what? If we’re going to be open sourcing software based on .NET I’d like it to NOT come from the environments that didn’t have these features already.

Spring.NET comes from Spring which is a Java thing which in turn did not originally have the eventing and delegate power that C# always had. And NHibernate comes from Hibernate which is a Java thing which in turn did not originally have the reflection power that C# always had.

So then we have Fluent NHibernate, which has automapping support, which is nice. Fluent NHibernete is, I perceive to be, original to C# and not yet another port from Java which recently acquired reflection support. I have to confess, Fluent NHibernate is beautiful, I’d recommend it to anyone who’s taking software development seriously, because it has its origins in .NET, aside from its NHibernate mother. But it comes with a few ALT.NET encumbrances of hyper-configurability with delegates (lambdas) in the name of “convention over configuration” which comes across to me as an oxymoron in this case. But don’t get me wrong, I actually do like Fluent NHibernate, I just don’t, well, like it. What?

Which reminds me, this ALT.NET thing… It got real big and popular a year or two ago and from them came the influences that led up to ASP.NET MVC, good for them, good for us, hurray! But it seems to me that there are two “alt” crowds in the .NET community—those who have had enterprise-level experience in formal software shops that used open source tools and who have a lot of expectations in software tooling in general to be flexible (i.e. the Java crowd), and those who prefer to approach software tools from a “get ‘er done'” approach and who are constantly looking for ways to shortcut the process of writing software quickly and effectively, without being treated like little children, by identifying conventions and building around them (i.e. the Ruby on Rails crowd). ALT.NET seems to be driven by these two forces and they often contradict each other.

The enterprise crowd seems to win, though. And it annoys me. NHibernate has Java-esque eccentricities written all over it. Gemli, meanwhile, is more for the “get ‘er done” but I do fully appreciate flexibility and raw power, too. My long-term goal with Gemli (not just Gemli.Data but the whole project) is to make the Ruby on Rails intro video here look like a headache and a chore to produce the same output. The video has a lot of “look what we had up our sleeves that we won’t show you” stuff happening. My goal is to create tooling, working alongside other originating-from-the-.NET crowd (as in, not ported from Java or Ruby) open source solutions for .NET like the Spark View Engine and the Argotic Syndication Framework, that makes the process of building the same web app both intuitive and well-designed and not feel like a bunch of tricks up our sleeves. I also plan to produce a video that is concise and understandable that produces the same solution with the same features (to detail), with a better user experience, in only 10 minutes and not 15. Gemli needs a few more things to make this happen, but it’s all coming and I’m still very much on track.

Currently rated 5.0 by 1 people

  • Currently 5/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5


Add comment

(Will show your Gravatar icon)  

  Country flag

  • Comment
  • Preview


Powered by BlogEngine.NET
Theme by Mads Kristensen

About the author

Jon Davis (aka "stimpy77") has been a programmer, developer, and consultant for web and Windows software solutions professionally since 1997, with experience ranging from OS and hardware support to DHTML programming to IIS/ASP web apps to Java network programming to Visual Basic applications to C# desktop apps.
Software in all forms is also his sole hobby, whether playing PC games or tinkering with programming them. "I was playing Defender on the Commodore 64," he reminisces, "when I decided at the age of 12 or so that I want to be a computer programmer when I grow up."

Jon was previously employed as a senior .NET developer at a very well-known Internet services company whom you're more likely than not to have directly done business with. However, this blog and all of jondavis.net have no affiliation with, and are not representative of, his former employer in any way.

Contact Me 

Tag cloud


<<  December 2020  >>

View posts in large calendar