The Maestro Language

I have heard the rumors about a new language from Microsoft called Maestro. It will be for use with the .Net platform. This language will be specialized for parallel programming. The goal is to make it easy for programming to do parallel processing without spending much time on that aspect.

Components in Maestro will be isolated from each other. Therefore a large part of the language will deal with message passing. The language will have access to all of the .Net framework. However it won't be meant as a stand alone language. Instead it will be used in tandem with other .Net languages.

Maestro is still in the early phases of development at Microsoft. You will not hear a lot about it for a while. Doctor Dobb's did an article on it. Or at least they interviewed a guy from Microsoft about Maestro. Some have determined that Maestro looks a lot like the Erlang programming language. The Maestro development team begs to differ.

Silverlight 2

Microsoft has recently released Silverlight version 2. It is a rich Internet application (RIA) platform. This platform is a subset of the .NET framework. It has the goals of being able to enable media and RIAs. The stated benefit is the ability to leverage existing .NET skills that developers have.

The Visual Web Developer Express IDE is currently a free offering from Microsoft. It supports Silverlight development. Developers are free to use any programming language with Silverlight.

Currently the supported browsers are Internet Explorer, FireFox on the PC and Macintosh, and Apple Safari. Linux browsers are suspiciously absent from the list. There is hope for the Linux community however. The Moonlight project is Silverlight version 1 running on Linux.

The majority of developers use AJAX for RIA purposes now. However that is a primitive option. It also forces you to write complex code which must run on the server for the design to work. Besides, Silverlight has a cooler name than AJAX.

ASP.NET

I read an article by Rick Strahl called “ASP.NET Gets No Respect”. Rick stated that ASP.NET offers great flexibility. He said it can be done easily. And although the framework is big, the model is clean. Usually a single machine can handle the load. You don’t need to do load balancing. People call ASP.NET both slow and insecure.

The competing technologies for ASP.NET are PHP, Python running on Apache, and LAMP. A downside to ASP.NET is that it is not free. You have to pay for Microsoft Windows. Most big sites do not use it. However some popular sites like MySpace, Dell, and CareerBuilder do.

Rick did say that you need to make a large up front investment in learning to do ASP.NET well. There was a lot of excitement when ASP.NET first came out. However it has been stagnating ever since .NET 2.0. Other areas in .NET such as WCF, WPF, and LINQ are hot now. But ASP.NET is just not a hip technology. You normally do not see startups using it. Microsoft is, however, very popular in the enterprise.

There were a lot of comments to Rick’s article. Some commented that Microsoft does provide support. But PHP is much simpler. A few people argued that they had to reboot their servers when they ran ASP.NET applications. Others complained that Visual Studio is just plain slow. There were a whole lot of other complaints, mostly about Microsoft.

Some web developers on my team use classic ASP for the web sites they run on the side. They seem pretty content. However I do see these guys having to reboot their servers sometimes when things go awry. They also get their customers to pay for the Windows Server operating system and hardware. So perhaps this is not a fair comparison. I can say that I have neither any experience with classic ASP or ASP.NET. I am really not a web developer. And for work I suspect I may have to go the Java route based on the client’s decision. I still wanted to talk about ASP.NET a little bit today though.

Unmanaged Into Managed

The other day I read the latest blog post on the Coding The Wheel blog. It was entitled “How to Inject a Managed .Net Assembly (DLL) into another process”. The author is James Devlin, who wrote a series of articles on how to write a poker bot that makes money. I will not go into the details of how you perform this injection. See James’ post for the full details. However I though his outlook on what managed code really means is interesting.

James comes out and says there is really no difference between managed and unmanaged processes. All applications are always unmanaged. Managed just means you have access to .NET, and there is a Just In Time compiler. James’ idea is that an unmanaged application can load the .NET runtime. So the call stack is that an unmanaged DLL loads the .NET runtime, and the runtime invokes your managed assembly.

James did state that loading the .NET runtime was not a trivial task. And somebody who commented on the blog post added that you could have problems if you tried to inject a .NET version 3.5 DLL into a .NET version 2.0 host.

I spent some time trying to get a mental image of what is exactly happening here. The main application James is talking about is truly unmanaged. However it invokes the .NET runtime. So the part in the middle that is injected is actually managed. Perhaps this is a way of an application running both managed and unmanaged code at the same time.

While it is true the application that starts the injection is indeed unmanaged, the code that gets injected is managed. Also I think it is obvious that in the end all code gets executed by the CPU. However this does not necessarily mean that all code is managed. Maybe this is just a semantics issue. However the code that James injects is an assembly that must conform to the .NET framework. In the end it executes as native code. But it is still managed.

This may all be much ado about nothing. However James is one of the first guys that comes out and says that there is no managed code, only native code. Maybe this was the shock value needed to attract readers to the blog entry. That worked in my case.

LINQ: Good or Bad

Eric White wrote a blog entry asking whether developers are using Language Integrated Query (LINQ). I have to confess that I had heard about LINQ. But I was definitely not using it either on the job or in my side projects. So I thought I would delve a little deeper, and summarize some of the points brought up by Eric and those that commented on his post.

To start with, LINQ is an extension to the .NET framework. It extends the C# and VB languages. LINQ comes with Visual Studio 2008. It allows the developer to express query behavior efficiently. Essentially it makes SQL a part of the programming language. It addresses the database model in the context of Object Oriented Programming.

Now let's review some of the bad thing about LINQ. Not a lot of people understand it. Once again I will confess that I am no LINQ expert myself. Although I am now trying to learn more about at a high level. I heard that it is difficult to debug LINQ statements. And finally LINQ has performance issues when returning a large list of objects.

For every bad thing about LINQ, there is a good side too. Programs written using LINQ tend to have fewer bugs. It works well with C#. And for those who have delved into it, they say it provides a good return on investment. In other words you will benefit greatly if you put a little work into learning LINQ.

It takes about a week to get the hang of LINQ basics. And it will take closer to a month to get to a deeper knowledge of the technology. When LINQ is coded on top of stored procedures, it makes for simpler code. Finally I have been guided to use IEnumerable extension methods but not the pseudo SQL syntax. Well I do not know enough about LINQ to qualify the last statement fully. But I may just dive in and try to my bearings so I can at least evaluate the technologies.

Microsoft Priorities

Microsoft CEO Steve Ballmer recently came out with a memo to all Microsoft employees reviewing the company priorities for the next year. This comes at a critical time for Microsoft since Bill Gates has retired. Ballmer outlined a 3 pronged focus on Windows Vista, WPF, and Silverlight. I thought I would discuss each of these as they relate to .NET development.

Windows Vista is the latest version of the Windows operating system. It was previously known as Longhorn during the development days. The O/S was released on January 30, 2007. This was a lengthy 5 years after the release of Windows XP. There has been a very cool reception to this version of the O/S. Users do not like the high level of system requirements for it. There are also a number of compatibility issues with legacy hardware and software. Early adopters complain of slow file operations. PC World called the O/S a big disappointment. And InfoWorld stated Vista was a flop. Microsoft has a lot of damage control to do with this version of the O/S.

Windows Presentation Foundation (WPF) is a .NET graphics subsystem. It was formerly known as Avalon during development. WPF version 3.0 comes standard with Windows Vista. The subsystem help aims to separate the user interface and business logic of applications. It introduces the XAML language. Microsoft is marketing WPF as a unified framework. Applications can use it in a desktop or browser configuration. The API for WPF is exposed only via managed code. But internally, its composition engine (named the Media Integration Layer) is written in native code.

Silverlight is a browser plugin from Microsoft. It competes with popular products such as Flash from Adobe. It supports animation, graphics, and audio-visual effects. Silverlight was previously named WPF/E (E stands for everywhere). It is a web based subset of WPF. As such it is designed to work with XAML. Initially Silverlight was criticized because it would only run under Windows. Version 2 of Silverlight comes with a .NET framework version that can run .NET code. Personally I get annoyed every time a web site refuses to load unless I install Silverlight. But that is just me.

There is a lot going on in the Microsoft development world. As you can see, a lot of it revolves around the .NET environment. I look forward to monitoring Microsoft’s progress in each of the key areas identified by its CEO this year.

Bloatware

At work we support a suite of applications. We bundle two of the main applications into one install program. Historically this install program has been about 17 Megabytes in size. There are a lot of business rules implemented by these applications. So some of our DLLs are pretty large even in release mode. But all of this bloat is not due to our custom code. We ship the install of the Microsoft Data Access Controls (MDAC) with each of our installs. That alone adds over 5 Meg to the install size. So far the customer has lived with this software install size. I know they must be having some pain because they push the install out to a lot of workstations.

This year we are moving to a new version of Visual Studio and the Oracle client. The move alone should not require a larger install program size. However we gained a Visual Basic Dot Net developer on out team. He has been struggling with learning the Visual C++/MFC programming that is required by our applications. It is also a chore to learn the business rules of the software. So when given the opportunity, he wrote a new piece of the software for our system in Visual Basic dot NET. I don't blame the guy for this. He was finally happy once he got back to doing what he knows best.

We gave the new developer the task of upgrading the install package for our software. Having added a Visual Basic dot NET component, he needed to ensure the right version of the dot NET framework was installed on the target platform. So he added the dot NET framework to our install program. All of a sudden, the 17 Meg install program has blown up to a 44 Meg monster. We have only pushed the new install out to our internal test team. But I expect there to be an outcry once the user community gets wind of this.

I know in this day and age, memory and disk space and bandwidth are plentiful. However users still expect installs to happen quickly. And they do not want complicated install packages. User has never liked install programs that are not fully stable. We might be heading into darker waters by ramping up our install to include the dot NET framework. The jury is still out on this. The real heart breaker is that we really did not have a solid need to do this. It was just due to one developer that was having trouble with our current software language and platform. I guess this is just life.