Back to Basics
I am an active participant in the ASP.NET Forums. One of the things I have noticed is that there is a huge difference between developers who understand the underlying technologies such as HTTP, HTML, JavaScript, and CSS, and those who do not. Those developers who do understand these basic technologies are able to pull their head out of the ASP.NET sand, and look around to find the simplest solution to a given problem. Conversely, those developers who do not understand these basic technologies are held hostage to Visual Studio or whatever program they use. They will peek and poke about in the IDE, hoping to find a command that looks vaguely promising.
It can be argued that an ASP.NET developer should not need to know these underlying technologies, just as a Windows Forms developer should not need to know how what a pointer is. But this argument does not hold due to the Law of Leaky Abstractions. Sometimes the right answer to a problem lies in these underlying technologies. But the IDE is working so hard to hide these underlying technologies that it ends up hiding the answer, too.
One of the lessons I learned from Cuyahoga is that developers can also be split between those who understand the fundamentals of object-orientation, and those who do not. Once again, Visual Studio and similar programs tend to hide the details. We tell Visual Studio to create a new class, and one appears. We then spend many minutes, or even hours, putting code into that empty class. Because the class appears instantly, and our code takes a long time to create, we can be mislead into believing that our code is all-important, and the class is merely a container for the code.
By way of example, an ASP.NET developer can tell Visual Studio to create a new .aspx web form, and one instantly appears. We type some code into its Page_Load method, and it all magically works when we request that page in a web browser. Visual Studio is hiding the fact that the .aspx web form inherits from System.Web.UI.Page, implements System.Web.IHttpHandler, and responds to the Control.Load event through its Page_Load delegate. That is, Visual Studio is hiding inheritance, an interface, an event, and a delegate—some of the most fundamental aspects of object-oriented programming in .NET.
Once again it can be argued that an ASP.NET developer should not need to know about all this background stuff. If the developer is creating a website to report on his Half-Life clan, what does he care if the .aspx page inherits its behaviour from System.Web.UI.Page or from Paris Hilton? (If you scour the internet, you can learn of the behaviour of each.) Once again though, sometimes the right answer to a problem lies in these underlying constructs. But the IDE is working so hard to hide these underlying constructs that it ends up hiding the answer, too.
I should note at this time that I am not blaming Visual Studio—it does its job very well. What I am saying is that it is vitally important for developers to know when to put Visual Studio to one side, and look at the fundamental technologies and constructs that Visual Studio hides from view.
Cuyahoga’s clever use of the basic principles of object-orientated programming made me realize that I did not have a professional’s grasp of these basic principles. Cuyahoga’s creator, Martijn Boland, was able to solve, in a simple yet flexible way, problems that I would have been hard-pressed to solve, simply because he demonstrated a solid grasp of the basic principles of object-oriented programming. I decided then that the final research step before commencing Charlie would be to truly understand object-oriented programming, by going back to basics.
by Alister Jones | Next up: Will Charlie be Open-Source? →
----
Post a Comment