Saturday 26 April 2008

Another Vista laptop bites the dust

My brother the other day called me up at work. He'd just bought a new laptop and it had windows vista on it. So he spent the morning trying to install things and had finally given up. He rang me to find out if he could just back up vista onto disks and then downgrade to XP, keeping Vista in case he wanted to upgrade later.

Now my brother has a degree in engineering, and an MBA. He has worked as a materials engineer for a number of years, and then as middle management. Of late he's run his own business. I consider him to be pretty well educated and techno savvy.

So why did he give up on Vista? The learning curve is too big, the hassles of things just not working on it are too big. Microsoft had a morning of his time to ease him into it and it flunked. I haven't even upgraded to Vista as I'd need a new PC at home.

I guess its getting harder and harder for Microsoft to convince people to upgrade as there seems to be very little immediately obvious reason to migrate. Maybe the memory requirements of programs will eventually break the 4GB barrier and with that 64 bit processors will take over and Vista at the same time. Personally I hope it happens. 4GB of memory seems a silly limit to me and I like some of what I've seen in vista, but saying that we have never gotten over the x86 instruction set, so maybe it will just be easier to retro fit everything to XP forever? I hope not.

Tuesday 15 April 2008

Bjarne Stroustrup on DSL's

I found an interview with Bjarne Stroustrup of C++ fame on MSDN Magazine where they asked him about DSL's.

I noted that he also thinks DSL's need a general purpose (I used the word broad) language fall back position.

Q: What are your thoughts on DSLs in general? What do you envision as the relationship between DSLs and general-purpose languages?



Bjarne: I worry about the number of languages being designed, implemented, introduced with great fanfare, and then fading away without significant impact. During this—typically many-years long phase of development—a new language consumes significant resources with essentially no returns. I wrote a paper on this phenomenon called "A Rationale for Semantically Enhanced Library Languages" (research.att.com/~bs/SELLrationale.pdf). I argue for using libraries, possibly supported by tools, and a general-purpose language.
I think that a DSL should be a last resort, not a first. If at all possible, the DSL should be firmly rooted in a general-purpose language and standard tool chains. A DSL needs a general-purpose language (or at least a systems programming language) for its implementation and the implementation of its run-time primitives. I think it would be best if a DSL is consciously and firmly paired with at least one general-purpose language so that it is easy to add new facilities through the use of libraries written in that general-purpose language. Obviously, a professional should master several languages, but I do wonder if the sum of complexity of a variety of DSLs couldn't become so high that it became a problem. Also, many (if not most) DSLs seem to "want to" become general-purpose languages.

Here's the full interview if you want to see his opinion on other things.

Sunday 13 April 2008

The trouble with DSL's (Domain Specific Languages )

Why do we have domain specific languages? They are supposed to make our lives easier for a specific task. SQL is the classic example of this, but XPath and other DSL's exist. SQL does an excellent job of doing what it was designed to do, support database access. Or does it?


SQL began life without and If statement, without assignment statements (:=) and variables but PL/SQL and T/SQL added them to make it useful. SQL has changed its spec 6 times since 1986. To include new features that people thought it should do. Still this is not enough.


I think the concept of a DSL has a a fundamental flaw. They can't move with business requirements and as such they need access to a broader language. This almost defeats the entire purpose of them.



The solution going on around the database world is to replace or integrate the DSL (SQL) with broad languages.(Oracle and SQL Server now support .net assemblies). The other solution is to add the useful features of the DSL into the non DSL (LINQ kind of adds SQL to .net). The point is SQL as the most well known DSL has failed to accommodate the business requirements of the developers world. And yet it is hugely popular and very useful.


The wikipedia entry for domain specific languages makes a good comment. "A domain-specific language is somewhere between a tiny programming language and a scripting language, and is often used in a way analogous to a programming library." And herein lies some of the problems with DLS's.

  • DSL's are not libraries. They are not easily extensible. You can add to a library pretty easily. It's nigh on impossible for me to extend Oracle PL/SQL. The only people who can extend PL/SQL are Oracle and they move like a glacier. (Does this mean they are speeding up of late with global warming? ;) )


  • DSL's by definition are limited in scope and usually dont' have access to the entire operating system. This means they usually don't cover all of the area's that people want to use them for.


This is a big problem for the developer. Initially you get a problem and let's say you solve it with a DSL, like SQL. It seems a a good solution, the language is designed for the job, its all a neat fit. But inevitably business requirements change and code needs to be refactored. But its a change thats not really in the fundamental design of the DSL, (ie you want to do some maths on data retrieved from a database). You oughta turf the DSL and go with a more flexible solution but you can't. Time and effort has already been invested, there is no time, the impact would not be this one area of the code but would affect other areas of the system. You are forced politically to go with the existing solution and do some kind of work around. The code ends up as a bit of spaghetti as a result and maintainability suffers. This goes on for a while and eventually the entire system becomes a rigid, impossible to morph system prone to bugs and errors due to the enormous complexity.


The problem here was not the change of the system, that happens all the time, the problem was the choice of a DSL.


It is hard to refactor SQL and as far as I know you can't unit test SQL. While functions are supported, classes aren't and using maths libraries in SQL is way out there.


Part of the problem lies in that SQL does not have access to a broad language like C#. LINQ is an attempt to solve this. This traditional boundary of DSL's not having access to the full operating system (which is by design) is a fatal flaw.


So my thought is to be warned when you choose a DSL that will not have access to a broad language. Ask yourself will it work in the longer haul? Can you break out of it to do non DSL specific things? And do this before you are wedded to the code base it will create. They have good bits but they are all flawed. In the end I now try and only use DSL's that have access to a broad language if I reasonably can (note the use of reasonably). Still I like the fundamental structure of something like SQL.

Saturday 5 April 2008

The case against inheritance

I was posting a reply to a codeproject lounge comment the other day when I got a response that challenged me to justify why its good multiple inheritance is not in c#.

I'll cut and copy my response here

You don't have to know what every method does of the parent class(es). You just have to implement the interface.

If you don't know what the parent class(es) do then when you modify an existing class structure you may leave in (fail to override) code that will just not work. And that applies all the way up the inheritance tree too. The deeper the inheritance tree the more you have to know if your going to modify the structure. Usually I find just using a class is fine, but modifying a class hierarchy to me requires you understand it on a deeper level.

Now maybe this is just an argument against inheritance in general but multiple inheritance just makes it harder and binds things together more tightly.

In general I'm moving away from inheritance as it has
1. largely failed to provide code reuse on a big scale,
2. has a habit of hiding implementation details and
3. locks in structure based on assumptions/goals that change and make it hard(er) to modify.

The best form of code reuse I have heard of is in components, in particular VB components and they don't use inheritance in that model as far as I know. Though internally the component may.



One of my experiences with the problems of inheritance hierarchies was when designing a bunch of firewire camera classes to grab frames from multiple cameras and save them to disk, in c++. We initially designed a nice little class hierarchy based on a a Basler BCAM library with a common frame grabbing thread. The aim being that if we wanted to use a different library we could just replace the Basler camera library with the new camera library object.


Of course along came a second CMU library and we found that this was trickier than expected. The libraries grabbed frames in a different manner to each other and this is where we went wrong. The first one had a sequence of 1. Set callback in camera library, 2. Start 3. Wait for Frames to arrive. 4. End grabbing frames. The second library had a sequence of 1. Begin Grabbing Frames, 2. Grab Frame, 3. End grabbing frames.


So we tried to fit the second camera library to the existing structure, bad move. Eventually it got done but it was a huge effort just to maintain the same frame grabbing thread code.


It would have been much easier to have had an interface to each library and write code for each type of camera. What really happened is I foolishly believed that the original hierarchy we had defined would apply to all camera libraries and that a new camera would simply slide into our class hierarchy. This wasn't true, we had bound our existing classes too tightly to the Basler library. At that point we should have abandoned modifying the existing class hierarchy and moved to a different code base for the new type of camera library.



The real point about this is that because I had a class hierarchy I thought I should reuse it. If it had been just an interface then I probably would have been less emotionally and politically tied into it. What can I say, I was young and inexperienced, none the less it is a lesson well learned.


The lessons I learnt


  • Changing a class hierarchy may impact on many areas.

  • Class hierarchies can be hard to change

  • Because they are hard to change they can tie you politically and emotionally into a way of thinking

  • Inherited code can be harder to reuse than helper classes.

  • Inheritance doesn't necessarily lead to much code reuse.



If you want to know the arguments a little further get the book Effective C# by Bill Wagner page 118