C was the ubiquitous language of its time. It ran on every platform, although each platform had its own interpretation of things like integer size. It was a higher-level, more portable language than was commonly in use at the time. It was syntactically fairly simple, with a few key ideas that it used heavily, like macros and pointers. More than thirty years later, it’s still the interop language between different technical domains. Younger, higher-level languages offer the ability to write speedier code in C or to hook into other code written in C.

Javascript is the ubiquitous language of the Web. After a rocky start, it now runs on every Web browser, although some browsers interpret things differently and many users have configured their browsers differently.[1] It allows more interactivity than preceding technologies (server-side manipulation and DHTML). It’s syntactically quite simple, with a few key ideas that it uses heavily, like prototypes and first-class functions. It’s used extremely heavily. There are a large number of libraries built on it. Other technologies (like Silverlight) are starting to build out from it.

I think that C and Javascript are both going to be with us forever. I think that, just as C is increasingly the province of device drivers, compiler back-ends and heavily-optimized inner loops, Javascript is going to move into the background of Web programming, replaced by technologies we probably haven’t even met yet. However, despite their spiffiness, the new VirtualSmellX and 4DSpline Web languages will have Javascript modules at their core and will exchange data in JSON.

(Confidential to social historians of the 22nd century: you guys are going to have So Much Fun. “Rapid evolutionary change” doesn’t begin to cover it.)

[1] I once had to pay for a conference by hand-delivered check. My idiosyncratic NoScript settings had convinced the registration software that I didn’t have to pay, and no amount of twiddling on my part would convince it to allow me to pay.

C# 3.0′s extension methods bring first-class citizenship to enums, albeit in a way that reminds me more of Haskell’s modules than of C# classes. Now we can have member functions for enum values!

(Hey Microsoft, any hope for an EnumOutOfRangeException when someone tries to cast an unsuitable int? Please?)

The Java way to do this is to have a restricted interface for the locked-down users, and a broader interface/class definition for the generation.  The dynamic language way to do this is to ignore the issue altogether.  I’m probably going to do this the Java way, but I wonder if there’s an idiomatic C# way to do this, or if this is another area in which C# and Java are content to be close siblings.  I also wonder if there’s a language-design way to move this pattern wholely into the responsibility-space of the compiler.