Comega talk

  • Article

On Thursday I gave a .NET users group talk on Comega to somewhere around 100 .NET developers.  Overall I think it went pretty well.  I was nervous at first, but once I got into talking about the cool stuff I like I forgot about the pressure and had a good time.  If you were there, please let me know what you thought about both my presentation style and the technical content.

I asked the audience how many of them wrote a lot of code for interacting with databases or XML data, and almost every hand went up.  My premise was that there was a huge potential to improve the productivity, quality and security of a lot of mainstream software development through data-oriented language features like those in Comega, and that if customers agreed, it was their responsibility to demand these features from the industry.  In my opinion, we're far too content as programmers to go about doing things the way we've always done them rather than push for (and pay for) better ways of building systems (obviously finding the right balance here is hard).  Perhaps this reflects a typically short-term-oriented reward system of the software industry (shipping the next new feature sooner), or perhaps it just reflects a cynicism of a market full of half-baked "improve productivity quickly" products that lack empirical data and research (which development shops often aren't eager to share).  

One thing that surprised me was that when I showed the naive ADO.Net query code and asked the audience what the problems were with it, it wasn't until the 3rd response a minute or so into the discussion that someone said it was vulnerable to a SQL injection attack.  This may have just been typical developer shyness to answer obvious questions, but I had expected that to be the most obvious response.  Regardless, it is scary how easy it is to fall into this trap without noticing right away that constructing a SQL query based on user input is a bad idea.  It's also unfortunate how many more keys you need to press (~128 in my example) to avoid the problem.

There was some great discussion around how Comega might or might not be able to also help with the encapsulation typically provided by business objects.  After playing with some options and thinking about this a bit more, I think the two issues (accessing back-end data, and exposing that data through business objects) are largely orthogonal.  If you want to add a layer of abstraction that provides encapsulation, data hiding, client-side validation, etc. then you're still going to have to wrap the data in some custom objects that define the interface and logic you want.  However, Comega can make it much easier to implement those objects, especially due to the simple syntax for converting data to different shapes.

Anyway, for those of you that asked me after the presentation to post my slide deck, here it is.  Sorry I didn't post sooner, but my whirlwind vacation in Ontario was pretty hectic.  Here also are some links to papers and relevant video: