I looove the bloat
Mar. 19th, 2005 09:45 amOne of the things that moving from COBOL to VB6 to C# has shown me is that software _has_ most definitely become more bloated. The amount of 'stuff' that goes on for a simple operation has most definitely increased, and writing code to fit in 32k of RAM is just not going to happen in any modern language. On the other hand, it makes _programming_ an awful lot easier. This means that I can produce far more code, that does an awful lot more, in much less time.
For instance, I'm currently writing a GUI that's going to collect information from a Customer Services person, check it all makes sense, and then pass it on to the mainframe for processing. One of the many fields to collect is the payment date - which has to be in a particular format and not in the future. In COBOL checking data formats isn't too hard, but if a user enters the date in the wrong format (dd.mm.yy rather than dd/mm/yy) I can't actually tell that easily. Under C# I was able to take _any_ date format and then spit it back out again in the format the mainframe wants.
The complete code for the validation was:
which requires me to do nothing that's not high level and exactly to do with the problem at hand.
In addition the use of events has been fantastic - Normally if I want to share code triggered by two different objects then I have to have a method triggered by each one and have each of those functions call the shared code. In C# I can just have the events trigger that shared code in the first place.
It's not perfect - I really miss being able to change a line of code in the debugger and continue, which I hear is coming in VS 2005, and I'm very much looking forward to the refactoring code (which works very nicely in the C# Express beta I'm playing with).
Now to finally get asynchronous windows sockets working, before it destroys my brain.
For instance, I'm currently writing a GUI that's going to collect information from a Customer Services person, check it all makes sense, and then pass it on to the mainframe for processing. One of the many fields to collect is the payment date - which has to be in a particular format and not in the future. In COBOL checking data formats isn't too hard, but if a user enters the date in the wrong format (dd.mm.yy rather than dd/mm/yy) I can't actually tell that easily. Under C# I was able to take _any_ date format and then spit it back out again in the format the mainframe wants.
The complete code for the validation was:
DateTime checkDate; try { checkDate = DateTime.Parse(this.paymentDate.Text); if (checkDate > DateTime.Today) { SetError(sender, "Date must not be in the future", e); } this.paymentDate.Text = checkDate.ToString("dd/MM/yy"); } catch (FormatException) { SetError(sender, "Not a valid date", e); }
which requires me to do nothing that's not high level and exactly to do with the problem at hand.
In addition the use of events has been fantastic - Normally if I want to share code triggered by two different objects then I have to have a method triggered by each one and have each of those functions call the shared code. In C# I can just have the events trigger that shared code in the first place.
It's not perfect - I really miss being able to change a line of code in the debugger and continue, which I hear is coming in VS 2005, and I'm very much looking forward to the refactoring code (which works very nicely in the C# Express beta I'm playing with).
Now to finally get asynchronous windows sockets working, before it destroys my brain.