Crystal Reports stinks

Agony, Crystal Reports is sheer agony. I hate it with a passion. Let me tell you a story about Crystal Reports.

Once upon a time there were no reporting tools. Programmers would simply format a canvas, in your chosen programming language, and then dump that canvas to the printer. This approach was reviled by a lot of Computer Science types. You see, you embedded the very formatting of the report into the EXE file you distributed. This meant that lesser business experts could not modify a report. Only a programmer god could do something as elementary as changing to the numerical formating of currency values on a report. Every time such trivial changes were made, a new EXE would have to be compiled and distributed. Clipper programmers made out like Bandits.

Then there was Crystal Reports, and there was nothing else but Crystal Reports. Crystal provided us a with a relatively simple editor tool which resembled any other modestly powerful office application. You would point to a database, fetch sample results, arrange them on a canvas, and save out a report file. The *.rpt file defined what the report did, and what it looked like. You embedded the Crystal Browser inside your app, but the report defs were separate. They could be changed ad infinitum by any fool smart enough to use the editor. There were plenty of these guys. Now the reports could change, and the EXE would not have too.

There was a serious downside to all this. Crystal was not famous for durability, reliability, dependability, stability, and robustness. If you took a dependency on Crystal, you very well might be embedding a source of bugs in your app; bugs you could do absolutely nothing about.

If you were a PowerBuilder, Visual Basic or Delphi programmer, you had to rely on this crap. Various people attempted to build competitor products. I only saw one that worked... while externalizing the report editing function. Unfortunately, Crystal became the institutionalized standard. Microsoft and Borland both included Crystal inside their development tools. This was unfortunate. Microsoft and Crystal became business buddies. Crystal did everything Microsoft's way, until...

Then came .NET. Microsoft wanted to kill COM and ActiveX. Microsoft also wanted everything on the web. This horrified Crystal Decisions. You see, Crystal had built the entire plumbing of their system according to the COM architecture. It was all Visual C++ and Active Template Library. This stuff doesn't work well at all in a webserver context, and it doesn't play well with the CLR.

Basically, Crystal gave Microsoft the finger. They never changed their plumbing. Crystal is a COMmie technology to this very day. That is a very bad thing. The company was sold around to an assortment of different owners. There were several points in recent history where we openly questioned whether Crystal would survive. Unfortunately, nothing seems to be able to kill these bastards. This despite the fact that their product looks like shit on the web.

Finally, sometime around 2004, Microsoft introduced SQL Reporting Services. At first it was primitive, and I didn't like it much. It got better in a hurry. This system was built from the ground XML up to play beautifully on the web. The engine is written in fully managed .NET CLR objects all the way down to the core. It works great with .NET apps. The stability and reliability difference was like night and day.

Microsoft didn't do this on a whim. According to various accounts, they built their reporting tools reluctantly, under duress. They had to. Their partners at Crystal would not keep pace with the times. They would not introduce native .NET technology. They would not flush the COM. They would not fix their ugly web presentation. They would not get rid of the unsafe code running under the web server. They had to be replaced.

I stopped using Crystal altogether sometime early in 2005. I am very happy I did. There is nothing Crystal does that SQL Reports can't do better. SQL Reports can do anything better than Crystal.

Now, today, I am suffering this infamous tool yet again. We took delivery on an out-source tool that does not work. We terminated the firm's contract abnormally, without full-deliverables. This is because they could not deliver. They were a bunch of Java guys trying to write VB.NET. They did not do very well. The part that has to work is the IDLR reports. Forget what those are. The key point is that they are in Crystal, and they will not run. We are getting errors from within the bowels of the Crystal Engine. These are inner-inner-inner exceptions that are driving us crazy.

My mission is clear cut: Make it work. Don't replace these reports... yet. What fresh hell is this? Several attempts to upgrade these reports to the latest Crystal runtimes have failed. I'm digging deep now. This is dread man. This is truly dread-y man!

The problem with C# 4.0

I hear many things about my favorite programming language these days.  Not all are favorable.  Some statements conflict.  There are a couple of facts about the latest edition (additions) to C# that cannot be denied.

1.  Anders has added in support for dynamic language interop.  This is mostly a matter of implementing a new static type whose static type is dynamic.  I guess that is the C# way to do it.  Basically, a declaration of 'dynamic X;' means we will obtain a boxed object with some metadata attached to it to let us know what type it really is.  This is almost like generics in Java.  The performance penalty is not too terrible at run time when all factors are considered.  Still, there will be a penalty.  This won't be high performance.  Worse, there is no question that this is full-bore late-binding.  In any late binding situation, you loose type safety.  No compiler can ever predict that any piece of late-bound code will ever work, or work in all scenarios.  The compiler will go along with it, presuming that you know what you are doing.  When the build is successful, do not presume that the compiler has endorsed your code.

2.  Anders has added support for optional parameters, so we can now have pain-free use of C# in connection with the dreadful, much-detested, out-dated, out-modded Microsoft Office object model.  Optional params are big in OLE2 or COM or ActiveX or whatever you want to call that disgusting old shit we used to do.  Lamentably, the dastardly Microsoft Office object model is still a filthy COM beast.  You should obtain less painful interops with all COM servers because of Anders most recent additions to C#4.  Still... this is a dirty thing to accommodate.  It is the programming equivalent of saying "have sex with HIV infected individuals, just use this condom".

3. There is also some stuff about co & contra-variance with greater safety.  I have never stubbed my toe on Co & Contra Variance, so I see no issues solved here.  I suppose this helps in a few marginal edge cases.  I know of none in my code.

4. Finally, Anders & co are re-writing the C# 4.0 compiler in C# itself, thus making the compiler available as just another managed code software services at run time.  The presumption is that C# 4.0 programmers will now use this handy-dandy, ever-ready compiler to engage in meta-programming techniques and tactics.  Once upon a time, this was the exclusive privilege of people coded with Interpreters.  Java programmers can only get access to this sort of dynamism through a jar library called Janino.

These last two items are of no consequence to guys like me.  Some may be jumping for joy, but I don't need a runtime compilers just now.  

Surprisingly, the announcement of these language features has tripped off a debate surrounding the question of whether C# is getting too big for it's britches.  Some say that C# is becoming an over-bloated Swiss Army knife.  I really think this debate misses the point entirely.  The issue is not one of whether the language is getting too big, but rather whether it is growing in the wrong direction.

Certainly, I do not welcome the advent of the dynamic type.  I don't need it, and I don't plan to use it.  I suspect that the mere presence of this type will slow the compiler considerably.  I hope it doesn't result in generally fatter CIL for all, which would in turn lead to fatter X86 code.

I am not a fan of optional parameters.  Optional parameters are element & aspect of a generally sloppy approach to programming.  That is why they are in VB.  They are not unlike the unstructured goto statement.  They are just bad for your code.  Either a param is necessary or it is not.  If it is necessary, it should always be required, and it should always be set.  Programmers should not be allowed to 'safely' ignore a parameter. This is one of the many ways in which unexpected and somewhat unpredictable behavior emerges in a system.  Programmers should be aware of the change in behavior flag settings will produce.  Of course, I realize that Optional Parameters were big in the days of COM.  This is one of several reasons why COM was a dirty, fifthly, nasty, ugly, disgusting, detestable, nasty, wretched, leaky, buggy, unstable, evil piece of shit.  [Did I mention that COM had no security model and was single handedly responsible for the Great Spyware Pestilence of 2003?]  There are explicit reasons why we flushed COM down the toilet in .NET.  One of the reasons optional params were rejected in C# is that we wanted to rid ourselves of this corruption.  Now here we go again.  Not good.

I understand why Anders reversed himself.  Many, many, many C# programmers have been bitching for years about how difficult it is to drive the Microsoft Office Model because C# does not support optional params.  Anders caved in under pressure from customers and the high command.  In a very real sense, I know this will make my life easier when I must do an Office automation project.  Still, I do not look forward to fully managed C# library, with no element of COM, which show optional params all over the place.  This eventuality will signal the arrival of sloppy coding techniques in the rather purist world of C#.

My real bitch is that the two language features we really need the most did not make it into C# 4.0.  What are those features?

1.  Traits, just like in Scala

2.  XML literals just like in VB.NET

In all honesty, these are the only two linguistic innovations I have seen in the past 6 ot 7 years that did not originate in the C# project.  

Traits are basically implemented Interfaces which you can tack on to almost any object.  They give you the advantages of interfaces with the advantages of mixins in Ruby.  The final yield is a language feature which gives you the reliability of single inheritance with some of the advantages of multiple-inheritance.

XML literals threw me for a complete loop.  XML literals took VB, a language which was dying IMHO, and suddenly made it the best language for the MVC framework. You don't know how much it hurts me to say this, but I would never want to code a helper class in MVC without the aid of VB.NET XML literals. This is not to mention all of the complex XML transforms which this system makes incredibly easy.  

XML literals are probably the greatest, most practical, most useful idea I have encountered in the past 5 years.  The biggest thing since Generics.  Scala also has a form of XML literals, but they don't seem backed by the sort of library power VB.NET offers.  In any case, C# should have had this feature.  Omitting XML literals from C# 4.0 is the same thing as capitulating the MVC framework to VB.NET.  Anders needs to take notice of this fact and make some corrections.

So the final verdict is clear.  C# is not guilty of getting too big.  C# is guilty of expanding in the wrong direction.  C# is guilt of not expanding in the right direction.  All-in-all I am quite disappointed.