News on Monday
more>>
SharePoint Tech Report
more>>


   

 
 
Download Current Issue
ISSUE 2/1/2010 PDF

Need Back Issues?
DOWNLOAD HERE

Receive the print Edition?


 
blogs tab
Visual Studio 2010 Release Candidate Available Today
A Visual Studio 2010 release candidate is available on MSDN.
02/09/2010 09:45 AM EST

Is Microsoft eyeing Office subscription pricing?
Microsoft may be preparing to offer a new Office pricing option called "union," which charges the same for cloud as on-premises.
02/01/2010 09:38 AM EST

Facebook rewrites PHP runtime
Facebook is about to open source its own PHP runtime, written from scratch for speed.
01/30/2010 08:53 PM EST

 

Events calendar tab
2/9/2010 to 2/13/2010
San Francisco
IDG World Expo

2/10/2010 to 2/12/2010
San Francisco
BZ Media

2/17/2010 to 2/25/2010
Atlanta
Python Software Foundation

2/19/2010 to 2/20/2010
Los Angeles
SCALE

2/21/2010 to 2/24/2010
Las Vegas
IBM


 
Most Read Latest News Blog Resources

One Language to Bind Them All


C# is more-much more-than a Java clone. It's the battlefield for a new type of programming.



March 1, 2006 — 
Why is C# the most successful of the languages running on the .NET Framework? Surveys done by BZ Media and others consistently show that C# is the most popular of the languages running on the .NET Framework, an observation that is bolstered by a review of training resources on the Web or at the local bookstore. Yet the language that publicly debuted in 2002 was seen by many as a “Java clone” and had little to mark it as particularly innovative.

Certainly, the programming community has voted repeatedly to embrace languages that derive from C. This preference is a combination of an appealing syntax (explicit typing is appealing for programming in the large), professionalism by association (real programmers use curly braces) and performance (all popular C-derived languages have rejected “everything is an object” for at least some primitive types).

Two things only now coming into focus make it clear, though, that C# is not just a winner by default, but also the field on which the battle for a new type of programming will be waged. WinFX, the next-generation API for Windows operating systems, is Microsoft’s gamble that managed code can handle the burden, not just of rapid application development or Web back ends, but for critical, distributed and public-facing applications.

While Microsoft has backed off the original premise of WinFX representing managed code all the way down to the level of device drivers, there is still the expectation that applications ranging from those heavily integrated with operating-system capabilities to those dealing with business-domain abstractions to those manipulating horizontal abstractions such as document flow will all be written in managed code. That managed code is appropriate across that range has sneaked up on the industry, which has spent the past decade paying attention to the successes (and challenges) of systems centered on network and Web services.

The other thing being seen now publicly is Language Integrated Query (LINQ). It is impossible to look at LINQ without wondering if language designer Anders Hejlsberg has had this facility in mind since joining Microsoft in 1996 and beginning work on the language that would evolve into C#.

To make query of arbitrary data stores (including databases, objects and XML) a first-class element of a programming language, you need to have a language-level construct for specifying code, not the results of a code calculation. That is, you need to be able to manipulate in code “this function that returns some integer,” not “this integer that’s returned by some function.” This has long been a capability in some languages, notably LISP’s s-expressions and C’s function pointers, but is largely unfamiliar to the mainstream as a fundamental programming style.

The power of LINQ
To understand the power of LINQ and how it seems foreshadowed in the evolution of C#, forgive a quick foray into code. Consider Listing 1 (page 29), which gives a hint of a LINQ-like function called “FindAll.” After the initial “using” statements (which make available important classes), we define a new type of function called a Predicate. Predicates are functions that take a value and do some calculation that results in a Boolean evaluation. In C#, function signatures such as this are first-class language features called “delegates.” These have been a feature of C# since the beginning. Our Predicate function, though, works on any type; we don’t need a separate definition for functions that evaluate integers, or strings or customer records. This “generic” functionality was added to C# in the 2.0 version.

If you take a look at FindAll, you see that, for convenience, it’s “static” (using it does not require an instance of type “Program” to have been instantiated) and publicly visible. Ignoring the parameterized type “T”s that sprinkle its signature, it should be clear that FindAll outputs a List after taking as input a List and a Predicate. The passed-in Predicate evaluates each of the values in the passed-in list to build the returned list (the predicate is applied with the call to function(value)). Note how generic it is: It makes no assumptions on the type of values it operates on and no assumptions on the workings of the supplied Predicate.

Skip down to the Main function and the lines where the FindAll function is called. I define a new function—a new Predicate. Notice that the Predicate is defined in-line, no variable is ever assigned to it. But not just one new function is created. As the loop spins and changes the “modulus” variable from 2 to 5, a new Predicate is created every time, capturing the changing value. Such “anonymous delegates with outer variable capture” were also introduced in C# 2.0 and are far more concise than the equivalent functionality expressed with classes and interfaces.

By combining delegates, generics and the closurelike “anonymous delegates with outer variable capture” you can create very concise expressions for working with collections. Of course, there is much more to LINQ. A complete SQL-like query ability is much more complex than what is shown here. The structural issues of selection and extension go beyond C# 2.0’s capabilities. And ultimately there’s a qualitative difference between a querying API and query built into the syntax of the language. Nevertheless, there’s a distinct feeling of design decisions made years ago contributing to a capability only now being previewed.

Bigger Than C#
LINQ is not confined to C#. It will be part of, at least, Visual Basic and C++/CLI. Nevertheless, like so much of the Common Language Infrastructure (the technical term for the .NET platform), LINQ seems most naturally expressed in C#. The shadow of Anders Hejlsberg falls across broad swaths of the CLI and the design alignment of C#, and the CLI is one of the major reasons why C# so dominates discussions of .NET.

Hejlsberg came to Microsoft from Borland, where his Turbo Pascal language matured all the way from CP/M to Windows 95 (and has continued, as Delphi, after his departure). He designed the Windows Foundation Classes for J++, Microsoft’s Java implementation, and laid the roots for familiar parts of the CLI. There were delegates, a class library that foreshadowed Windows Forms and an easy syntax for interoperability with native code. In that era, Microsoft also was engaged in evolving COM+ to be more productive and user-friendly. Also, the company was still playing catch-up in tools for developing Web applications, where CGI and ISAPI extensions didn’t hold a candle to the productivity achievable with Java servlets or JavaServer Pages.

Sun set, dawn of CLI
After cooperation with Sun over Java ended, the alignment of C# and the CLI was ensured. Microsoft had an investment in Hejlsberg’s designs for the language and class library, a Java VM and three needs that could feasibly be addressed by a managed code platform: rapid application development, Web development and a systemwide component-object model. It did not have the luxury of time, with Java peaking in its hype cycle, the dot-com explosion, and Redmond having become “the Borg” in the popular imagination.

Hejlsberg has said that the CLI is largely neutral to programming languages, that syntax has become “a preference.” He is fond of pointing out the shift that has taken place, wherein power comes not from learning new languages but from mastering a class library. While there’s a large amount of truth to this, particularly regarding the class library, one wonders if he’d be quite as sanguine if he were implementing a language with a different inheritance model or with a different type system.

The Common Type System (CTS) of the CLI dictates a view of program types that all .NET languages must support. While there’s much sound and fury about explicit versus implicit typing (often wrongly labeled “static versus dynamic” typing), decisions about type systems fundamentally affect compiler writers.

The CTS, for instance, dictates a difference between reference and value types: Reference types are garbage-collected “objects” while value types have semantics that allow them in many cases to be efficiently mapped into stack-based variables, increasing performance. Similarly, the CTS dictates class-based singly rooted inheritance. While clever compiler writers can extend the CTS (for instance, the maker of Eiffel supports multiple inheritance), it’s certainly easier to go with the flow.

Microsoft, not exactly known for sharing its intellectual property, has standardized both C# and the CLI by way of Ecma. Ecma standards 334 and 335 codify the two technologies (the third version by Ecma’s reckoning, but corresponding to the .NET 2.0 release). As Ecma standards, the technologies are placed on a “fast track” for ISO, ISO/IEC and ETSI adoption. Some have speculated that the Ecma process may be less rigorous than that of the ISO, but people familiar with both organizations have said it is likely to be more of a question of process than technical oversight. Whatever their reason for choosing Ecma as the route, C# is a standard and can be implemented by interested parties.

The Mono project, spearheaded by Miguel de Icaza and funded by Novell, brings C# and the CLI to platforms including Linux and Mac OS X. There’s enough interest in C# as a development language for these systems that Addison-Wesley recently announced a book series on Mono.

The next version of C# will, to a large extent, be dominated by LINQ and the sea change in programming techniques it will bring. Even before then, though, WinFX will be a showcase for the CLI and C#. The CLI was not originally conceived to carry the weight of systems-level programming. Somewhere along the line, that changed.

In 2003, Microsoft announced that SQL Server 2005 would “join at the hips” the database and the CLI. At the same time, it announced Longhorn and the subsystems now known as WinFX. At the time, Microsoft said that managed code would be used deep into the OS. After the “Longhorn reset” in 2004, WinFX was no longer coupled with the Vista operating system, and while “WinFX is all about managed code” is still the message, it’s now seen more as floating like an ice cap on top of the unmanaged operating system—thick in some sections, perhaps quite thin in others.

The integration of the CLI and SQL Server 2005, though, has already happened. It has not yet caused many ripples in the industry, but sources inside Microsoft say that the demands of the SQL Server team were of great benefit in forcing the CLI and Base Class Library teams to confront quality and performance limitations and to make improvements. This integration was the testing ground, within Microsoft, of the capability of C# and the CLI to be used in the most stringent environments. This is not to say that SQL Server 2005 is written in C# or that C# code performs at the level of expertly crafted C++, but it does show that C# and subsystems of managed code can be integrated into massive codebases that have daunting performance imperatives.

With the arrival of WinFX, managed code will be the preferred platform for the vast majority of Windows development. From handhelds and phones programmable with the .NET Compact Framework, to desktops, servers and distributed systems, the CLI will rule them all. While the coming era of manycore systems raises architectural and language issues, there’s little doubt that C# will be the language that most closely aligns with the underlying platform and thereby continue to dominate the world of .NET programming.


Share this link: http://www.sdtimes.com/link/29164
 

Add comment


Name*
Email*  
Country     


  • Comment
  • Preview
Loading