Arcadian Visions

While I do use C# a fair bit, I’m not an early adopter of test releases of Visual Studio or new versions of the language. I try to keep up on what new features are coming, so when final releases are made I can dive right in, but I’ve fallen a bit behind on the syntax and implementation details for a few things in C# 3.0. My question now is: at what point did identifier names start trumping other indicators for semantic interpretation of code?

For a good long time now, statically typed language compilers have presented developers with a proposition that can loosely be stated thusly: you give your variables types so I know what to do with them, and then you can call them whatever you want so you know what to do with them. Now, it turns out that type annotations can be very useful for helping people understand code as well, but such information isn’t strictly necessary for productive development (e.g. dynamically typed languages and those with good type inferencing capabilities).

But now, it seems, the folks steering the C# ship are turning to identifiers to infer programmer intent in the form of object and collection initializers. The identifier-based mechanism for collection initializers is described here.

What I think is interesting about this is that such behavior is much more commonly found in dynamic languages, where there often isn’t as much developer-generated metadata available. C# let’s developers “mark up” their code with type specifications and attributes, so why aren’t we using those mechanisms instead of relying on compiler conventions and guess work? Automatic properties (also described in the first link above) can well be managed by using an attribute, which then avoids the somewhat odd issue of having a private field whose name nobody but the compiler knows. Collection initializers could benefit from having the appropriate Add method decorated with an attribute, or implementing an interface that specifically defines the interface used by the collection initialization mechanism. Object initializers… well, that one I like except for the unifying of common property names (i.e. passing a property of one object to an object initializer without assigning it to a specific property, thus relying on the compiler to equate common names). It’s just strange to me that, what seem to me to be, more idiomatic C# techniques are not being used.

All that said, I am very interested to see how this all pans out. I use reflection constantly in my C# code. I very often build base classes, or frameworks, that are sensitive to field, property, and method declarations in sub-classes. These techniques can be used to eliminate masses of boiler plate code, and, ideally, minimize developer responsibility by relying on very compact behavior declarations, rather than imperative specification of how the behavior is to be accomplished. When I do this, I very often require that a default constructor be available (because constructors that take parameters can be a pain when instantiating objects programmatically), and I often do use identifier names as part of the patterns I’m looking for to trigger the metaprogramming routines. That style of development seems like just what C# 3.0 is heading towards. Rather than constructors with positional arguments, we throw a dictionary with some number of parameters at the constructor (beware developers who assume properties have been set in the constructor!). Rather than lean on potentially complicated inheritance, let’s look for idiomatic collection definition.

I’ve never had many reservations about doing this within the scope of a single project. All the developers can agree that declaring a Connect method is going to trigger some framework-defined behavior. But does this kind of logic belong in the compiler for the underlying language? If the 80/20 rule applies to library design, does it also apply to compiler design?

More noise on how everyone loves to hate XML. Don Box links to a couple posts by James Clark detailing an alternative to XSD for specifying schemas. As I’ve mentioned before, I don’t find the idea of naming my closing tags so horrible, and I choose to not use much of the badness in the various specifications associated with XML (I realize that’s a worthless point to people who have to use XSD). I’ve had success in the past with XML and RELAX NG mediating data transfers between Ruby and C#, and, more recently, I used JSON for serializing the state of a Scheme interpreter since JSON does do at least one thing much better than XML: anonymous lists.

Okay, all that stuff is great, but what I’d like to comment on is Don’s statement that Microsoft is moving towards more structural typing, and James’ comment on nominative vs. structural typing. I know this is a taste issue as well as a technical one, but I really can’t help but wonder about the potential results of cooperation between the algebraic data type people and the more mainstream nominative typing people. It’s great to pattern match by blowing up a structure, and it’s great to be able to differentiate tuples of three floating point numbers as position, velocity, or acceleration. My hope is that we’ll see more typing that looks somewhat like the XML pattern matching you see in functional languages. If I don’t care what my 3D vector is, then I just want a structure that has those three elements. But if I do care, then I want a structure with those three elements and a particular name. People are great at naming things, so let’s not lose sight of that in order to gain the advantage of structural typing.

While this issue is somewhat orthogonal to XSD vs. TEDI, a more structural bent to mainstream programming languages should make the very notion of schema specification more natural from a programming language point of view. Microsoft is in a tremendous position to make things happen in this area due to the resident expertise in Haskell and C#, and I’m sure we’ll be seeing more of it over the next few years. What will be interesting is how the XML / serialization / data interchange people at MS play off of how the programming languages evolve.

I really appreciated this article on Worse Than Failure. The author is basically talking about one of many ways to over-engineer a system. The issue here is awfully murky, and there are no blanket rules, but I think there are a few important aspects of today’s technology that should be considered.

There are many reasons to move data (e.g. string and numerical constants) out of source code, and into configuration files. Namely, there is an aspect of DRY at play: define the constant once so that it can easily be edited in one place should it need to be changed. There is also an aspect of designer-programmer interaction: people who can’t program should just have to open up notepad to change an application behavior (this practice is particularly prevalent in game development). But I think a large part of the allure of configuration files is that code is considered sacrosanct.

The idea that once a program is compiled and known to be working, that nobody should even look at it funny in case it should collapse is, at least in part, an artifact. Sure, if compilation is a time-consuming process that requires specialized tools, or if the program is encoded in an unreadable string of obscure runes (i.e. asm), then it must be the case that only properly-equipped engineers be given the responsibility of interacting with source code. But there comes a time in many complex, data-driven applications when the language used to encode the data needs to be augmented to express, perhaps, rules about the conditions under which the data should be used. In some cases, multiple constants that are always used jointly are defined without any indication of that coupling, so basic logic is added to define the relationship between them. At some point, the engineering team may realize that they are providing the designers, and even users, with yet another programming language.

This situation speaks to the fact that programming is something much larger than C. Editing data in configuration files is programming, just in a very limited language. While I’m not advocating repeated definitions of constants in source code, I would argue that we, as programmers, should all be comfortable with non-programmers editing something that can legitimately be called code. There’s no need for compiling these files in any intimidating way, so no special tools are needed. We, as a community, have a ton of knowledge and available code to allow us to embed various levels of scripting at every level of an application. We are also writing more automated test and verification code than ever, so let’s leverage all these things to provide non-engineers with more powerful tools.

If a rule set is well-expressed in a programming language with basic conditional expressions, as in the example provided by the article linked above, then let’s encapsulate that logic so it’s not buried in a huge source file, but let’s also leave it in code form. I believe that many of the bad examples of so-called Soft Coding are a result of a belief that all logic should be generic, and all data should be inert. Instead, we should be willing to enliven our data with the logic that gives it meaning.

Don Box provides an amusing summary of XML vs. JSON that serves as a good back-cover to the recent iteration of this particular pointless debate.

What I find interesting about this is that none of these features that justifiably frustrate reasonable users of XML are required. You can happily use XML as a format for yourself without cluttering it up with any of this cruft. The phenomenon, in fact, is that seeing an ugly, inelegant usage of the technology actually dissuades people from using it in a simpler way.

The same effect can be seen in many of the Ruby on Rails vs. Java debates for building websites. While RoR has many merits, some of the arguments against Java highlight specific examples of Java usage as evidence against its worthiness as a language. Clearly, drawing such conclusions is unfair, but it is consistent with the way of the world in other matters. Consider, for example, companies not wanting their brand associated with anything they deem as inappropriate, or negative. That the same brand management is important to technology, with it’s ostensible attendant objectivism, is surprising. Perhaps the best way to kill a technology you don’t like is to use it in the construction of a notably unpleasant program.

Nick Carr references an essay at The Register that urges the web development community to get over the fancy interfaces associated with Web 2.0, and get on to developing the distributed computing future.

While I appreciate the wonderful turn of phrase, “Web 2.0 marks the dictatorship of the presentation layer,” I disagree strongly with the contention, implied by statements such as “away from Ajax towards something grounded in decent engineering,” that Ajax-style development isn’t significant. The truth is that the future of the distributed-computing web (aka the unfolded web) may well be developed as an extraction from the Ajax-based interface distractions of today. The key to this progress is the growing division between the back-end and front-end necessitated by people’s desire for today’s dynamic interfaces.

Rather than viewing the focus on interfaces as a misstep in the evolution of software, I instead view it as a saddle point. Sure we can spend some time just developing new interfaces without advancing the overall state of software engineering, but I think it would be short-sighted analysis to see that as a stable situation. Instead, consider that static websites of the past were, in fact, mashups of various pieces of data available on the server. The data was mashed up in a static way, determined solely by the administrator of the website, thus presenting the user with a coupling between interface and data. In fact, the user, seeing only the final product, could only infer that the data behind the website was just as complex as that final, viewable product. But while the complex whole may have hidden the divisions between the component pieces, the pieces were there, non-mashed, behind the scenes. Today, people are building Ajax front-ends that are capable of requesting those individual pieces of data as discrete transactions. No more does HTTP-GET translate into MASH-DATA on the server.

The drive to give users granular control over the way data is presented has pushed the development of REST and WS-* in a very productive way. While today’s technologies may not be the identical foundations for tomorrow’s world of decentralization, the move to view a website as a collection of resources, spurred by the desire for dynamic interfaces, is nothing but a positive revolution in design strategy. Once this mindset fully takes over, a shift to alternative methods for serving individual resources will not require the type of philosophical crusade associated with Web 2.0.

Fancy interfaces are not a bad thing, they are simply the low hanging fruit available on the march towards taking advantage of distributed data and computation.