An Interview with C# Essentials Coauthor Ben Albahari

by Bruce Stewart
02/06/2001

C# (pronounced C sharp) is Microsoft's latest programming tool, and it is the first language designed to take advantage of the new .NET programming platform. Taking cues from Java and C++, C# is an object-oriented programming language that promises to increase programmer efficiency and reduce development time. Ben Albahari is a coauthor of O'Reilly's new C# Essentials. oreilly.com recently spoke to Ben to get some insight into this new language and see what Microsoft has in store for the next generation of programmers.

Stewart: What are the main strengths of C#?

Albahari: C# is a pretty elegant language, but it doesn't sacrifice expressiveness in an attempt to be pure. It provides direct support for properties and events and makes programmers use the override and unsafe keywords so they can clearly see what's going on. With Java for instance, sometimes it feels a little idealistic. It's like, "Everything is an object, so we don't need enums, stack-based objects, etc." or "Pointers are evil, therefore the language completely eliminates them." So C# allows these things, but in a tidier, safer way than in C++. Probably the other major strength of C# is that you use it to leverage the .NET Framework. If you want to code the .NET Framework, then C# is a good language to use. It was designed specifically to work well with the underlying runtime.

Stewart: How does C# compare to Java?

Albahari: I get asked that a lot. I actually wrote an article on this when .NET was first released because I noticed a lot of people were saying some pretty crazy things. There were, of course, the people who go to Java church, who simply couldn't accept that C# was anything more than some marketing from Microsoft. There were the people who said C# was a Java clone. And of course, Microsoft was going to great lengths to not even use the J-word and was saying that it was closer to C++. Really, it was fairly ridiculous, so I decided to write an article that would be as objective as I could.

I'm pretty sure this won't be as articulate as what I said in my article, but here goes: C# is probably pretty similar to what the Java people would come up with if they were allowed to forget about backward compatibility and just make the language better. The improvements are quite deep though. They're not just refinements. I'm sure Anders Hejlsberg [co-author of C#] sat under a Bodi tree until eventually he unified C#'s type system. Of course, a big difference between them comes down to the fact that the Java language targets the Java platform, while the C# language targets the .NET platform. So in real terms, when comparing C# and Java, you've also got to look at each respective platform.

Stewart: Let's extend the comparison to .NET and the Java platform. What advantages does .NET have over the Java platform?

Related Reading C# Essentials By Ben Albahari, Peter Drayton, Brad Merrill Table of Contents Index Sample Chapter Author's Article Read Online--Safari Search this book on Safari:   Only This Book All of Safari Code Fragments only

Albahari: Obviously Microsoft has put a huge amount of work into Web Services, ASP.NET, XML, etc. It's such a big topic, and I'm still getting myself familiar with it all, but I think some of the advantages of the .NET Framework stem from the fact it was designed much later, which means you get the ground-up effect as opposed to that append-it-on-later effect. As a developer, I know that as you progress into a project, you start seeing the way something should have been designed, but it's too costly to change.

For example, the Java platform hasn't been designed with versioning in mind. It was certainly an improvement on C++, whereby you had extremely brittle types because you access fields by offset rather than by a name. But there are more subtle types of brittleness. Adding a new method to a Java class in the Java API can break programs that subclass it and that inadvertently have the same signature as that method. This was addressed in the .NET Framework and languages that target it, like C#. A really cool feature of the .NET Framework is attributes, which are again mirrored in the C# language. They're utilized throughout the .NET Framework, determining, for example, how objects are serialized when passed in a SOAP call. It's hard to just add these things later. One thing people should bear in mind though, is that the NET runtime, although reasonably separable from the operating system technically, is currently tied to Windows.

Stewart: How does C# compare to C++?

Albahari: C++ is too complex. I mean the whole concept of header files is a waste of time. I think one day it dawned on me that all these pointers and symbols were distracting me from what I wanted to do--think about application logic rather than plumbing--so I switched to Java. The main reasons you'd want to use C# as opposed to C++ are in common with why you'd want to use Java over C++. It's way more productive, and you can actually understand code written by another programmer.

Stewart: So it sounds like C# more closely resembles Java than C++?

Albahari: Yes, it's closer to Java. Microsoft obviously doesn't want to say this for competitive reasons, but there's also underlying technical reasons. Java itself popularized rather than invented most of its language features, which came from other languages. In fact, in the Java Language Specification, they blatantly say they avoided including new and untested features in the language since it was a production rather than a research language. So in a sense, the similarity between C# and Java comes from both design teams acknowledging the same set of benefits of successful features of existing languages. But it can get tiring when Microsoft starts singing the praises of particular features of C# like "no header files" as if they're entirely new innovations.

Stewart: How does C# compare to Visual Basic?

Albahari: Is that VB 6.0 or VB.NET? I've always done my best to avoid VB 6.0 and earlier versions, actually. The fact that it wasn't object oriented made it unappealing to me. VB.NET, though, is a totally different story. It's very similar to C#. I think the differences do run deeper than braces, but not by much. But I'm not saying that this is a bad thing. Both are languages designed to leverage power of the underlying runtime. C# keeps some familiarity with C/C++, and VB.NET keeps some familiarity with VB 6.0.

It's quite interesting, this multilanguage proposition Microsoft is offering. It's a mixture of technical merit and marketing merit. Technically, it's cool to be able to compile C++ programs like winword.exe into assemblies and support other languages like Eiffel. But it's also good marketing. I guess the idealism in me likes the idea of having one unified language, but realistically a language has to be sold to programmers. It makes sense providing a language especially for VB programmers. And obviously positioning .NET in terms of being a multilingual platform gives it an edge over Java.

Stewart: There seems to be a bit of a commotion among VB developers over the differences in VB 6.0 and VB.NET. Do you think these are valid criticisms of VB.NET, and will the same scenario be true for other languages that will be supported by .NET--where significant changes and tweaks may have to be made to existing programs to get them to work?

Albahari: I can appreciate the commotion--Hey, I was using J++, so I know what it feels like to have the development tools you're using die on you. But I think what's happened here is inevitable. In the case of VB, I'd say if you want an object-oriented, threaded, secure, robust environment, then you need a Java or .NET model to achieve this, which will be very different from VB 6.0. You just can't ignore the benefits of these features anymore.

Concerning other languages, it comes down to a trade-off the language designer makes. If they want interoperability with other languages and libraries, etc., then, yes, the differences between the languages become increasingly syntactic. However, as a language designer you can choose to ignore these benefits when you write the compiler if you want say, templates. What's really cool is that you can mix and match them, which is exactly what VC.NET does. You can have a method that is callable from another language, with an implementation that uses a C++ class that has templates as a local variable, even though the method is part of a class that is CLS compliant, which means other languages can see it and use it.

Stewart: It's been said that C# combines the ease of VB with the power of C++. Is that a fair comparison?

Albahari: Yes. In fact, I'd go further and say it's easier than VB and in some ways more powerful than C++. I know it sounds like I'm going overboard here, but I'll explain myself. VB 6.0 and earlier weren't even object oriented. It's pretty much accepted that an object-oriented language will be easier when you have to deal with any moderately sized project. Concerning C++ (except for managed C++), compiling to assembly language as opposed to an intermediate language means you lose a huge amount of power. With C#, you're always compiling to an intermediate language, so when you use C#, you're getting all the benefits associated with that. This means you get features like reflection, security, etc. You can use C# to write code that can safely execute on a client computer without doing any damage. You can't do that with C++ programs because you can't verify assembly language as being safe or unsafe. So your powerful C++ language is powerless as a scripting language.

Stewart: What features does C# have that haven't been borrowed from any other language?

Albahari: I guess I can't possibly know every other language, so this question is inviting me to put my foot in it. So I apologize in advance if I think the following features are novel but they aren't. I haven't seen attributes before. I think it's really cool how you can take any code element, like a property, method, or struct, and associate custom information with it. For example, you can have a property, mark it with an attribute specifying its default value, and another attribute giving it a description.

Speaking of properties, I prefer the way they're handled in C# to other languages. It's just a simple get/set combo. Events are also a feature that I haven't seen treated as well in any other language. In C#, it's very easy to wire an event source to an event target, and the same source can fire multiple events, and the same target can have multiple sources. It's similar to the way events work in J++ (by the same design team), but they've made it even easier and a little more powerful.

Stewart: Do you agree with Mark Anders, Microsoft's product unit manager of the .NET Framework, that C# is the most productive language in the C/C++ family of languages?

Albahari: The only languages in this family I'm really familiar with are C/C++/Java, and it's definitely the most productive of these languages. I've coded the same things in C++, Java, and now C#. When moving from C++ to Java, you really notice a big jump in productivity. It's hard to generalize and quantify these things, but I personally found I was at least twice as productive.

With C#, I'm still learning the APIs and dealing with a rather slow Visual Studio.NET, but certainly I can see there will be a jump in productivity, though not as extreme as when going from C++ to Java. One particular library I had in Java I converted to C#, and it was quite a bit simpler and cleaner than the Java equivalent.

Stewart: Microsoft claims that the modern design of C# eliminates the most common C++ programming errors. In what ways is C# less prone to programmer errors?

Albahari: The obvious one is that, like in Java, when you're working with C#, you're working with a type-safe pointerless programming model. Type safe means you can only use variables via the rules imposed by that type. So you can't, for instance, typecast a rectangle into an int and start processing it as if it were an int. This naturally fits with a pointerless model too since pointers let you bypass type-safety by accessing memory, regardless of the type associated with that memory.

When you're not using pointers you don't have to worry about pointing at garbage or forgetting to delete an object. For the same reasons, array indexing is always bounds checked to ensure you're not reading or writing to memory beyond the end of the array. So these things eliminate many errors. Another big factor in removing errors stems from the fact that the language is much simpler. If a program is easier to understand, then it's easier to avoid and debug errors.

Stewart: How does C# relate to Web Services?

Albahari: C# targets the .NET Framework, and the .NET Framework provides APIs to make Web Services really easy to create and consume. It's kind of magical the way you think you're just accessing an ordinary method on a C# class, but really it's doing some SOAP call across the Internet to some server. But each .NET language can utilize this API. And if you zoom out, you can use whatever language or whatever platform you want to participate in Web Services--say Java on Linux. It just comes down to the fact that C# is a good language, and that the .NET Framework has a nice API, which is the reason you'd want to use C# for this.

Stewart: A lot has been made of the claims that C# can dramatically reduce development costs. What features of C# will make it a more efficient language to develop in?

Albahari: As you've already asked, C# offers productivity benefits and prevents common programming errors compared to other languages, so that will of course reduce development costs. Certainly aside from being a productive language in terms of writing code, it's also productive in terms of reading code. Your classes have their properties, methods, events, etc.; and you can embed XML documentation right along with your code. It's quite easy to understand someone else's C# program.

Stewart: What is "unsafe mode" in C#, and how does it work?

Albahari: Contrary to the claims I've heard some people make, unsafe mode does not equip programmers with a loaded gun. C# has an unsafe keyword, that you can use to mark a region of code that explicitly manages memory. This is useful when you don't want to be restricted by the primary memory model that the runtime imposes on you, like where all variables are type-safe and everything is automatically garbage collected. For instance, in an unsafe block you can get a pointer to an array and just zap it with zeros. Generally you wouldn't want to do this; but if you're doing some really fast graphics process, it might be the extra bit of performance you need.

Another example is when you're dealing with memory outside of the managed heap. You might be interoperating with native dlls, and want to explicitly use pointers. It's nice to do this within your C# program rather than write some extra dlls to do this for you. Of course, when you start explicitly managing memory you can read or write to some arbitrary address in an inadvertent or malicious way. So code marked as being unsafe can't safely execute without the appropriate security permissions, which is why it's called unsafe. The language and APIs have been designed so that over 99 per cent of the time you won't need or want to use unsafe code. VB.NET for instance, doesn't have it.

Stewart: How well do you think C# is being accepted by the developer community?

Albahari: I'm not a market researcher, but I think it's gathering momentum. When it was first released, there was much more skepticism. There was a whole lot of crap circling around from people who were more interested in making their opinion heard than understanding the technology. But there were a whole bunch of us who downloaded every bit of information we could on it, and realized it was pretty cool technology.

So the Web sites just keep popping up, people start debating it on newsgroups and mailing lists, and now the books are starting to roll out. It's certainly going to be impossible to ignore by Windows developers.

Stewart: What C# features or concepts are hardest for C/C++ or Java programmers to grok? Why do you think that is, and what would you say to help dismantle the mental block?

Albahari: Let's take each language one by one. C programmers are going to be shocked by any language they see nowadays. C++ programmers will have the same sort of groking experience as if they learn Java, though perhaps somewhat easier. Sure, they essentially have to move to a garbage-collected, pointerless object model, but at least they can have stack-based objects, operator-overloading, etc. I think it's an easier jump. I guess lack of generics, like templates, is a big one. That's one case when C++ is simply better hands down, and at first you always miss them. I guess what I'd say is that, overall, the benefits of C# outweigh this, so just put up with it.

They are planning on adding generics to C# in a future version, though I'm convinced that if they'd added them from the start a lot more Java and C++ programmers would be drooling over the language. Personally, I don't think this is that much of a big deal, though. I'm at a stage where I'm much more concerned with how to improve the APIs than the C# language itself. Certainly for Java programmers, there is nothing very difficult to understand about C#. Again, it's the APIs which will impose the biggest learning curve.

Stewart: What is the relationship between C# and .NET? Can one exist without the other?

Albahari: Well, you have a language and a runtime. Neither is dependent on the other, but they do work well together. C# was designed specifically to target the runtime, so it provides a type system which closely maps the type system of the Common Language Runtime. C++, for instance, doesn't map so well onto the runtime because the runtime doesn't provide the concept of multiple implementation inheritance in metadata. You can still write a class that inherits from multiple classes, but this is lost when you compile to metadata, so you don't get the benefits of reflection and interoperation with other languages from doing this. So it's good to have a language that was designed with the model imposed by the runtime in mind.

The specification for the C# language has been submitted to ECMA, so it can theoretically be implemented on other runtimes. Similarly, the CLI (Common Language Infrastructure) has also been submitted to ECMA, which theoretically allows other implementations of the Common Language Runtime.

Stewart: Microsoft Chief Architect Anders Hejlsberg feels that C# is the first language to address the needs of component developers. What features make it so well suited to this task? To what degree are those features unique to C#? How much comes from the underlying .NET Framework itself and is therefore available to other .NET languages (VB, JScript and Managed C++)?

Albahari: Programmers have had this dream for a long time of a software world where you've got these wonderful pluggable units that you piece together so you can build your killer app in one week. Unfortunately, it usually doesn't work out like this. Part of the problem is that the standard object-oriented features of languages just aren't enough. I'm a big advocate of object-oriented design, but I don't see why messages between objects should solely be transmitted via methods. I think it's very natural to design classes that provide their interface to the world via properties, methods, and events, rather than just methods. C# provides this, which to me makes a lot of sense.

Then once you've built your set of classes, or rather types, you need a way of bundling them into a unit that expresses the fact they're a team of types that may be incorporated into various applications. In the C#/.NET environment, all your types are grouped into an assembly, which provides this unit. When you build a C# application, you are in a sense piecing together a bunch of assemblies. You might have the assembly you wrote, the core assemblies provided by the .NET Framework, and, say, a third-party assembly for some special functionality. Each assembly has types and functions that can only be seen within themselves, and ones that can be seen by other assemblies. That feels to me really component oriented.

What's also cool is that the runtime has been designed to make it much easier to deal with version upgrades to an assembly, so that your code doesn't break. Versioning goes right down into the design of the C# language itself, too. Overall, though, most languages targeting .NET will benefit from the component-oriented emphasis the runtime provides.

Stewart: What will readers find valuable about C# Essentials, your new book on C# and .NET?

Albahari: It's a small, densely packed book. If you want to get up to speed with C# and the most essential parts of .NET, then C# Essentials will get you there fast. From the outset the decision was made to be foundational. We wanted a book that would give people a nucleus of knowledge from which they can explore more specific things, whether from other books or the Web. It's the core stuff that everyone should know.

---

Ben Albahari is cofounder of Genamics, a provider of tools for C# and J++ programmers and software for DNA and protein-sequence analysis. He is the author of A Comparative Overview of C#, a frequently cited article comparing C# with C/C++ and Java that was recently named by DevX.com as one of the Top Ten .NET Sites. Ben is a resident of Perth, Australia, and in his spare time enjoys composing music on his computer. He can be reached at ben@genamics.com.

Bruce Stewart is a freelance technology writer, focusing on Web development and wireless issues. He coauthor's the Industry Standard's Wireless News, and is a regular contributor to ZDNet and Web Tools.

O'Reilly & Associates recently released (February 2001) C# Essentials.

• Sample Chapter 1, Introduction, is available free online.

• You can also look at the Table of Contents, the Index, and the Full Description of the book.

• For more information, or to order the book, click here.