There are approximately 28,600 Types in the .NET 2.0 Framework Class Library (FCL). I am not sure how many more are in WinFX, now called
.NET 3.0. Even 28,000 Types is a staggering number to learn a FCL. There is a very good
article that explains the 9 most common Types to get started. As the article summary states,
The .NET Framework Class Library and the common language runtime (CLR) serve as the foundation for all .NET-based applications. But how much do you know about any of the thousands of CLR classes in the library and where do you begin to learn about them?
In this article, the author uses the number of relationships with other types to determine which types are going to affect your programming most frequently and how often you'll encounter them. He programmatically surveys the CLR library using reflection to make that determination. Following that, an in-depth examination of the nine most important CLR types is provided.
I like this article as it shows a pragmatic way of understanding the .NET FCL. In addition, using Lutz Roeders
Reflector, you can literally inspect, disassemble and decompile any Assembly, (.NET FCL or other assemblies), to your favorite .NET language. Do you believe that
source code = design? Even though the article is 14 years old, it is one of the most decisive articles on software design I have ever seen. It also most closely resembles my belief the source code listings are the design documents.
Since the FCL and runtime (application execution) environment are packaged together, you basically have a programmable runtime environment. Using a dynamic language, like say,
IronPython, and through an interactive console, I can program the FCL and have it execute as I am programming line for line.
As each line is entered in the IronPython interactive console it is being dynamically executed by the IronPython engine (interpreter). In some lines of code, I have built a trivial Windows Presentation Foundation application borrowed from the tutorial that comes with the
IronPython download.
As trivial as it is, there is an important concept being demonstrated here which is with IronPython embedded in your .NET application or in Visual Studio (i.e. using the VSSDK) or using the standalone interactive console, you can dynamically program the execution environment so to speak. A programmable runtime environment.
I have always been a fan of software reuse, mainly because I am lazy. Also, I know it works. I make a living at it. In my world of programming business applications, the reality is that most if not all of it has already been coded several times over. As seasoned programmer once said to me, its all been done before. When was the word processor invented? How many word processors have we had since? Whats different? Probably the same thought goes for spreadsheets, workflow - paper or otherwise, invoicing, ecommerce, etc. Most of these business problems have already been solved with software many (or a million) times over. My question is, how can I reuse this incredible wealth of software that has already been designed and built? Thats my thesis to prove.
I can reuse software much like the way I am practicing today, finding components of various sizes and shapes that loosely or exactly match a functionally decomposed problem I need to solve. For example, my System Browser needed a way to parse an Assemblys XML document file to retrieve code comments on Types and Members when reflecting on an Assembly. Surely that has been written before is what I am thinking. And with a little bit of searching,
yes it has, to the point where after I have included the example class (or Assembly) in my System Browser application, I can integrate it with one line of code.
This means I did not have to modify the code at all, I could just use the public interface and problem solved. Next component. And that is how I am building my System Browser application. The 80/20 rule is in effect. 80% reuse and 20% net new code, distributed between coding new functionality, modifications to existing components, and glue code to stitch all of the pieces together.
So what am I saying? I am saying that there is a lot of code out there in the world to reuse. I and others have been doing it for years. Sometimes known in our practice as clip-board inheritance. But, how can I pragmatically reuse pre-built code? While having the source is nice, it does not have to be a requirement. In fact, using System.Reflection will let you look at practically anything inside the Assemblies black box. And I can load any black box (i.e. Assembly, COM Object) and not only inspect it, but use it dynamically in my application using an embedded IronPython engine. Thats what the System Browser is all about. A tool to dynamically program the runtime environment.
The System Browser application is designed to be an emulation of Smalltalks programming environment. It has a dynamic/interpreted programming language integrated with a large class library and an application execution environment. Essentially a virtual machine.
Rather than Smalltalk, and the Smalltalks class library, I am using IronPython and the .NET 2.0 FCL. The CLR on a Windows OS takes care of the application execution environment. Through a similar GUI like Smalltalks System Browser, I can use System.Reflection to get access to the Type system. Using IronPython I can dynamically create new classes and subclass the FCL at will.
Not only can I browse and use in real-time the FCL, I can do that with any other .NET assembly or COM object. I wonder how many .NET assemblies are compiled everyday world-wide? How many COM objects over the years have been compiled? I must have produced over 100 DLLs by now after 15 years at it. I am one of approximately 12 million programmers worldwide.
According to IDC, the number of professional developers worldwide will increase to 13.3 million by 2006 from 7.8 million in 2001.
Theoretically speaking, even if each developer compiled the equivalent of 1 DLL a year over the last 10 years, times 10 million developers, thats tens of millions of DLLs that have been produced. Even if it is a magnitude more or less, its still an incredible amount of potentially reusable DLLs. Again, how to use them?
I modeled my System Browser after
Smalltalks System Browser. Why? Smalltalk and its environment was best suited for me where I can browse classes, instantiate them, inspect other instances, manipulate them, all in a simple to use dynamic environment. At least for me, that was the pinnacle of an OO development environment, along with Brad Coxs Objective C System Browser. Now I can have the same thing but different. Maybe it is just the way I feel most comfortable navigating and manipulating a FCL.
Another reason for this approach is assisting in the industrialization of software development. I want to program at a higher level of abstraction. To me, that means heavy reuse of pre-designed and pre-built, components is critical to raising this level of programming abstraction. Why write source when the compiled unit is already there?
In the many pages of this blog, you will have read statements like, from a software development point of view, given whatever software application or component you have been tasked to build, chances are that it has already been done before. Look it up on the internet. In fact, this System Browser application is being constructed using this reuse pattern.
Once I have found an existing Assembly or COM component or source code (that will be compiled into an Assembly) that meets 80% (or best choice) of my requirement, I download the assembly and import it into my image or System Browser which means it just became part of the programmable runtime environment.
Now I can reflect on the assembly and all of its Public Types and Members. If there is an associated XML code documentation file, then that is parsed and displayed each time I click on a Type or Member. If there isnt a corresponding document XML file, then I code generate on the fly an XML code documentation file, using a standard template, so that a sentence is formed for each Type and Member as basic (but editable) code documentation. It is already generated and reflected back into the System Browser before you can click on anything.
Using the embedded IronPython inside the System Browser, as I am entering code in the console window (interactive mode) and/or code editor (file mode), both are being recorded then compiled and added to System Browser on the fly. This is done in real-time and totally seamless. At least that is one of the goals of my System Browser.
I would not take too much of this too seriously. This is more of an experiment for me to learn from. It is for my research on software industrialization. However, the System Browser will be
freely available just like th