The transition from Visual Basic to C#

utilities.utilities.errorHandler(strError, this.Name, strProcedure, objException.ToString(), false, "", false, false);

I know I was ready to swear off Microsoft development a few months ago but practically I need to stay the course for a while, in part to meet an old committment to improve the published compiler.

I can relate to this. Good old practicality has kept me a Microsoft developer for years. There have been a few times where I almost had an opportunity to go other directions, but either the window never opened or I decided not to jump. That said, while I have for years coded for the Microsoft platform in my day job, I do enjoy all the non-Microsoft exposure I get working in the LAMP stack on this web site. I can't take credit for *any* of the great PHP code behind the Drupal framework, but I do get to noodle in it sometimes when I need to customize something.

Edward, I'm glad you're going to keep going on spinoza development. The MS-DOS Command utility is indeed one of the most popular pages on the site every month, and a lot of people download the ZIP file with the code.

What would you say is the "value proposition" of spinoza? Or is that very idea anathema to your goals? Is there a vision of people adopting spinoza in a specific context, or is the language an intellectual end in itself? Or am I oversimplifying?

Do I understand correctly that you're going to write the spinoza language in C# instead of VB.NET?

Dan

I am fully committed to C Sharp.

The value proposition: stateful objects need a core personality so that programmers don't have to wrestle with the vagaries of objects. Every stateful object should have a Name, a Usability and a clear indication of when it is not fully usable. No rogue objects should be permitted to exist. Rogue Objects Must Die.

Also, there needs to be a clear distinction between class and object in all discourse, but classes must be first class objects; the idea of getting at class properties should not be ghettoized into a Reflection spoken of with fear and dread. After implementing Version One of this concept I found that Bertrand Meyer had already discovered it which only affirmed its value for me.

Simultaneously, mere code should always have the capability of full introspection while it should never be "unnecessarily necessary" to do this...because a lack in the system has psychologically or mathematically forced the programmer to build an UNNECESSARY data structure which typically turns out to be a time sink and an expense of spirit in a waste of shame.

...is characterSet, a stateful object that represents a Unicode character set, externally as a Boolean set formula such as union(upperCase, digits).

No, STRINGS do not adequately represent character SETS.

However, the dilemma I face is that the tostring/fromstring serialization as above of the character set is in its full Glory, yet another programming language because you might have to "do math" on character values to express a character set.

I am reluctant to use an existing programming notation that is compiled by the Framework, and pass the serialization to the appropriate compiler, because you shouldn't have to know a particular language to express a set. Except mine. Ain't I a stinker.

An alternative is of course to limit the expressivity of the set notation to

Actually, I added C Sharp calls to the Visual Basic utilities library that supported no optional parms. I needed to avoid code that whimpers "false, "", 0, null, false, false, false". Turns out that in the 1990s, when the utilities library was written, I was a big fan of optional parameters. Silly me.

Actually, I am no longer in love with my errorHandler of the 1990s. It basically just packages and date-stamps an error with an option to record it in a Windows event log (something that violates encapsulation since utilities should be Windows-agnostic, dammit) and another to display a message box (yecccchhhh in retrospecccchhh.)

Older versions maintained a pushdown stack of error handling rules: but with Throw this doesn't seem to be important since you Throw the exception into an environment where the "business rules" don't have to be coded parameters and can be instead code. The older model was based in part on the serious deficiencies of older error handling.

Hmm, I could simplify all error handling to Throws, and "let go and let Framework" do its job.

But then there would be no chokepoint at which I could date stamp or even translate errors to a foreign language.

Ever since the early days I have been a believer that errors should pass through some sort of central office in the code so as to enforce some sort of central Holy Inquisition on errors, because in early code written by others I saw no error handling or random, ad-hoc error handling.

I also wanted to have a locus where for a particular client I could enforce an error policy.

For now I shall keep errorHandler but in practice, since it Throws the error in a pretty form, what happens is that unless there is code in the form, the error becomes a prettified system error.

In general, thanks to an enforced absence from code, I am taking a fresh look at my own shibboleths. Perhaps as a psychological defense to the idea of being "only a programmer" I evolved a General Theory of What To Do in a Goddamn Business Program, Goddamnit.

I do feel in general that programs written self-consciously with self-conscious facilities to do things are of higher quality, and the BYO compiler runs reasonably well because its base is more solid than the typical code for a book; this has been confirmed by some of the Amazon reviews.

But, you have to continually rethink. errorHandler was written in the old days of VB when MsgBox was universally available and when a VB application needed a consistent policy.