Moving up the Food Chain

The astonishing, and to me, profound thing about some the new .NET technology coming out from Microsoft is how we are now beginning to move away from low-level, implementation worries and toward enabling construction of applications from ever larger abstractions. In a way, and to me at least, this is what will get us to where we need to be to deal with ever larger amounts of complexity.

Time for bigger plates.

If you look at technology like LINQ for example, you get an idea that the designers and architects of .NET technology at Microsoft are really groking over how to make this happen. Rather than have developers learn a query language like SQL for example, they would use a unified, built-in query/access mechanism within the target language, say C#. The actual database or storage vehicle containing the data would be beside the point. The LINQ mechanism would handle accessing and applying the appropriate query technology to access the data.

As a developer, and occasional database architect, this is a fascinating area of progress both from being able to embed query-like mechanisms in code to the idea that such a thing is actually possible. But beyond the mechanics of using something LINQ, what really got me thinking was how this and other like technologies are beginning to move developers up the abstraction chain ever higher and higher.

Years ago, when the language 'C' dominated Windows development, the notion of bundling blocks of code and data together seemed fanciful. It seemed on the one hand easier to understand, and on the other hand more cumbersome than just writing functions and declaring data when and where you needed it. All of a sudden being a really good 'C' language expert able to write super compact code was far less important than being able to "see" objects in an application. The ability to abstract was beginning to be more important than the ability to implement.

This got us just so far before the notion of dealing with objects became common and expected. As machine performance increased over the last several years, the worries about speed of code have continually receded to the point where in the majority of business applications that don't need to scale to tens of thousands of simultaneous users are much less of a concern to businesses than the speed at which those applications are created.

The ability to work with ever greater abstractions, whatever they may be, and whatever evolutionary state that they may be in, will be undoubtably key to the future of software development in .NET. Sometimes when my mind wanders, I do a thought experiment and try to envision the software developer of 2100. What do they use as their programming language? Do they even use programming languages? How large are their abstractions? How many of the performance and algorithmic problems we deal with are still issues then?

Granted, the answers to these questions are unknowable, to me at least. But I think that it's fair to say that over the coming years and decades the types of technology abstractions we'll deal with will continue to grow and evolve. Many will evolve to dead ends. Some will evolve to become workhorses of development. A very few select ones will be revolutionary. Which ones will be those, no one can tell at this point. But as software developers, in .NET especially, the pace of change is relentless.

No one ever said it was easy to be a programmer, er.., software engineer.

Posted by Mark M. Baker at 04:56 PM  Permalink