The October issue of Dr. Dobbs Journal has a small article called Quantifying Popular Programming Languages. This article is unfortunately not available on-line for free. Dr. Dobbs surveyed web-based job boards to see what percent of the job postings contained references to specific programming languages, but they did not divulge which boards they surveyed. The survey lasted from July 2002 to June 2003. Only 16.4% of the jobs posted contained references to .Net, 5.35% mentioned VB.Net specifically, and 5.16% mentioned C#. Java ocurred in over 40% of the ads and C++ was in over 50% of the ads. Visual Basic was in 19.2% of the ads. Does this reflect a slow adoption of .Net? Or is this just an effect of the economy, or both? I have lurked around the MCAD usenet group and seen frequent comments about the lack of jobs specfically for .Net. Of course, my company is certainly not hiring (see my post here), and the project I am on is the only .Net project in the company. In my experience the benefits of .Net development are significant compared to what we were doing in the past, even for the customer. Are we just not getting through to the business decision-makers about where we need to go? Or should I really spend more time learning C++?
There a fascinating discussion going on at Tim Sneath’s blog about the functionality of the business layer moving to compiled stored procedures in Yukon. At least in my project, we have been doing that very thing and struggled with the n-Tier issue as a result. In our case, the database is Oracle 8i, and the application is/was ASP, which we are now converting to .Net. We have some very complex business logic encapsulated in PL/SQL stored procedures. There were two concrete reasons for the decision:
The amount of data that would need to be transferred was huge.
Oracle is more efficient than ASP code at many of the operations involved.
With ADO.Net, some of the ineffieciency may be addressed, but the database is designed for efficiency at certain operations that ADO.Net won’t be able to match.
We did not need to approach this from a scalability issue, as the app receives hundreds of hits per hour, not thousands or more. I still think it will scale OK as your business objects will have much shorter life spans and you can still pool and queue database connection objects if needed due to long-running stored procedures.