There’s a thread on the CSLA .NET discussion forum about possible differences between the VB and C# versions of CSLA .NET. I started to answer the thread, then got on a roll, so it became a blog entry
I strive to keep the two versions of CSLA .NET in sync within a reasonable time window. Everything after version 1.0 (the version in my books) is essentially my donation to the community. What I get out of it is not wealth, but rather is a lot of very interesting and useful feedback from the vibrant CSLA .NET community. I'm able to try out some of the most interesting (to me) ideas by releasing new and updated versions of the code. It is a learning opportunity.
The fact that I have to do every mod twice is a serious pain and does reduce the fun, but I think it is worth the pain because it makes the end result more useful for everyone.
I do most of my first-run coding in VB, because I prefer it. Simple personal preference. I've done some first-run coding in C# too, I just don't find it as enjoyable. Some people have the reverse experience and that's cool too. That doesn't bother me one way or the other. I fully understand feeling an affinity toward a specific language. It took me years to get over Pascal. Ahh VAX Pascal, I still harbor such fond memories.
But what I am more concerned about in terms of CSLA .NET is VS 2005. In .NET 2.0 we start to see some feature divergence between VB and C#. Most notably the My namespace in VB. Fortunately by playing in the middle-tier, CSLA is less subject to the differences than some code will be. However, there'll still be some differences that will make my dual life harder.
The biggest one that will impact me is My.Resources, which makes the use of resources somewhat simpler than C#. This isn't a huge thing, but it does mean there'll be extra code differences to reconcile between the two versions in CSLA .NET 2.0.
There's also My.Settings, though I don't know if that will impact me quite as much. I anticipate dropping the DB() function from BusinessBase in 2.0, since most people (rightly) avoid putting db connection strings in their config files.
The two primary C# features (yield and anonymous delegates) don't appear to have a home in CSLA, so I don't expect any differences from them. Not that they aren’t seriously cool features, but they just don’t have a place in CSLA .NET itself.
The new strongly typed TableAdapter classes are very cool. They are useful in both languages. And I hope to use strongly typed TableAdapter objects to simplify the code in the DataPortal_xyz methods.
There are some features that are more accessible to VB than C# in the new strongly typed DataTable (due to C#'s lack of WithEvents functionality - a major oversight imo). However, I don't expect to use any of those features in CSLA to start with, so there's no impact there.
When I write the book I'll create Windows and Web UI chapters. Those are what I dread most, because that's where the differences due to My become much more serious. There are numerous examples of UI development where My will be a serious code-saver - thus causing direct differences between the VB and C# code. Not that I can't do the same stuff in C#, just that it will take more and different code, which increases the effort on my part as an author.
Fortunately most of the book is about the framework and creating business objects, and the language divergence will have relatively minimal impact in those areas.
It is hard to speculate on what comes after VS 2005, but personally I expect more divergence, not less. Earlier in the thread someone noted that things like the Mac, Linux and Java still exist even though you can technically do everything they do with Windows and .NET.
The fact is that they all serve a purpose, as does .NET to them. People deep in C# often think different than those deep in VB. People in Java think different than those in .NET. This means they have different perspectives, different priorities, on the same problems and issues. This is only good. This means there are competing ideas that we can all evaluate and use to the best of our abilities, regardless of the language or platform we choose to use.
Loving distributed computing as I do, I am constantly taking ideas from the C++ and Java worlds. I closely watch the SOA world, even though I think it is misguided in many ways, because there are interesting ideas and perspectives there that can apply to distributed object-oriented systems as well.
I’ve said it before and I’ll say it again, if you only know one programming language family (such as the C family or the Basic family) then you really, really need to get out more. Your horizons and thus your career are simply too limited and you can’t be considered credible in most of these discussions.
That’s an interesting meme. Which programming languages have you been competent in during your career? I’ll start (in rough order of usage):
1. Apple BASIC
2. VAX Pascal
3. Turbo Pascal
5. FORTRAN 90
6. VAX Basic
9. Visual Basic (1-6)
10. Visual Basic .NET
While I did write a VT terminal emulator in C once, I don’t think I was ever really competent in C, so I’m not counting that. My memories of that experience are not inspirational in the slightest… I’ve also dabbled in various Unix shell languages and bat files, but was never competent in them.
Converting the list to language families is harder, because things like ARexx aren’t obvious, but here’s my attempt:
1. Pascal (Pascals and Modula-II)
2. Basic (various)
4. Scripting (ARexx, DCL)
5. C (C# and C if you are generous)
So, having wandered from the topic of CSLA .NET parity between VB and C# we arrive at what could be a cool meme. Go ahead, comment or blog – what languages and language families have you been competent in during your career?