Monday, June 23, 2008
« CSLA Light serialization implementation | Main | CSLA Light data portal and n-level undo »

A couple people have suggested that I might be abandoning VB. Not so!

My first love was Pascal - VAX Pascal actually, which was more like Modula II in many ways. What an awesome language!

My next love was VAX Basic. Now that VB has structured exception handling in .NET, it has finally caught up to where VAX Basic was in the early 90's. No kidding.

Of course after VAX Basic came VB.

And after VB came .NET. I love .NET. I love .NET with VB and C#. C# is just VB with semi-colons, but VB is just C# without semi-colons too. I gave up on the silly language war thing a couple years ago, and am happy to let either or both language live or die by the hand of its users. The language thing was distracting me from truly enjoying .NET.

When it comes to writing books, it is really important to remember that they fund CSLA .NET. As much as I love what I do, I've got kids that will go to college in the (scarily near) future, so I can't work for free. So when I write a book, I can't ignore that C# books outsell VB books around 3:1 (it used to be 2:1, but the market has continued to shift). I still think it is worth writing a VB edition to get that 25% of the market, but you must admit that it makes a lot of sense to go for the 75% first!

It takes several weeks to port a book from one language to the other. The current plan for Expert 2008 Business Objects in C# is October (though I fear that may slip), and with the conversion time and publication schedule constraints, that pushes the VB edition into early 2009. Apress just hasn't put the VB book on their public release list yet, but that doesn't mean I don't plan to do that edition.

When it comes to CSLA Light, I'm doing it in C# because of the 3:1 split, and so again am focusing on C# first.

Whether I do a VB version of the framework or not depends on whether I decide to write a book on the creation and design of CSLA Light. I may or may not. If I don't write a book on the design of the actual framework, I won't port (and then maintain) the framework into a second language.

It is a ridiculous amount of work to maintain CSLA .NET twice, and I really don't like the idea of maintaining CSLA Light twice too. You have no idea how much writing, testing and debugging everything twice slows down progress (and eliminates fun). As wonderful as Instant C# and Instant VB are, the dual effort is a continually increasing barrier to progress.

I might write an ebook on using CSLA Light, in which case I'd leave the framework in C#, but create reference apps in both VB and C# so I can do both editions of the ebook. I think this is the most likely scenario. Certainly VB-compatibility has shaped a couple CSLA Light design decisions already - I won't allow a design that precludes the use of VB to build a CSLA Light app.

(The lack of multi-line lambdas and/or anonymous delegates in VB is a real barrier though... Worse even, than the poor way C# handles implementation of interfaces...)

In the end though, like all of us, I need to be where the market is vibrant. Where I can make money from my hard work. Just now, there's more money to be had from C# content and so that takes priority. But there are a lot of people using VB, and (assuming the sales ratio doesn't slip further) in my view it is worth producing content in the VB space as well.


Tuesday, June 24, 2008 1:16:41 AM (Central Standard Time, UTC-06:00)
The amount of time needed for testing would dramatically decrease if you would finally adopt a more TDD style of development. Believe me I have been using CSLA since its very first incarnation but now I'm disappointed more and more since you seem to just ignore patterns and principles that have proven to be superior especially when developing enterprise applications.
Maintainability of code is one of the key goals in an enterprise application. Another one is extensibility.
IMHO you can better achieve those goals when you respect e.g. SoC (and CSLA is an anti-pattern in that regard). The tight coupling of distinct responsibilities in CSLA make it nearly impossible or at least difficult to write unit tests.
Without unit tests any refactoring of code is a night-mare and VERY dangerous! And the CSLA light IS a refactoring. Also porting code from C# to vb.net IS a kind of refactoring. If you would have a decent set of unit test then this refactoring would be possible with much less friction.
I have read all your articles where you defend CSLA but in my opinion the architecture of CSLA is simply out-dated. I know what I'm talking about since I have done many projects with CSLA (medium sized and large ones). But currently I'm developing an enterprise application NOT based on CSLA but based on a DDD and implemented using TDD. What a difference!
Gabriel Schenker
Tuesday, June 24, 2008 8:03:50 AM (Central Standard Time, UTC-06:00)
Rocky -

Thank you for your very candid and honest explanation. I did not mean to be in anyway offensive and I completely understand your position regarding the whole work to money relationship. I've myself began transitioning from VB.NET to C# as my primary language for the exact market reasons. As much as I love VB.NET and have tried to stick it out, the market IS saying otherwise. I've also started buying all my tech books in the C# versions as well to help my transition and have mentally made the switch to consider VB.NET my "other" language. Sad, but true and it's silly to ignore the market facts.

Thanks again for being a stand up guy and giving an honest and practical explanation. I will of course continue to read and support your work as a respected professional.
Erin
Tuesday, June 24, 2008 10:25:32 PM (Central Standard Time, UTC-06:00)
Gabriel,
It just so happens that I am programming unit tests tonight on a CSLA.NET 3.5 application. I realize you're referring to unit testing the CSLA.NET framework itself, but, there are unit tests for that too. So, I'm not sure why you think it is impossible (or nearly impossible) to write unit tests. I've never found that to be the case. The CSLA.NET 3.5 framework is so full of new cutting edge .NET technologies that I find the term "out-dated" to be an unsubstantiated comment. As .NET has progressed forward with more and more features from 1.x to 3.x, CSLA has kept pace and has attempted to be backward compatible in many situations. Yea, out-dated, I simply don't agree with that statement at all.

Chris
Chris
Thursday, June 26, 2008 9:13:01 PM (Central Standard Time, UTC-06:00)
Gabriel, I am glad things are working for you. Things are working for me too. In a decade or so we'll see whether TDD and all the related "silver bullet" trappings are a fad or are real. They are far too young to make that determination now. But I'm glad you've found a cause you believe in, that can be a healthy thing as long as you can avoid becoming a fanatic :)

In this case I doubt very much that real TDD would save me time or code. The idea that I could mock Windows Forms data binding, Web Forms data binding, WPF data binding and Silverlight data binding to implement the kinds of tests I _really_ need is absurd. These technologies are so complex, and so ill-documented, and so idiosyncratic that mocking them would take an unreal amount of time and effort.

The rest of CSLA is easily tested, and I have reasonable tests for pretty much everything else. Those parts simply don't worry me.

But supporting data binding - which I believe is of critical importance for developer productivity (I know, RAD and TDD don't mix, sorry...) - takes more time than any other part of CSLA. Data binding is a real bear.

Now if you come back and show me someone who's got a 100% mock of Windows Forms data binding alone (much less Web, WPF and Silverlight) then I'll reconsider.

My goal with CSLA is to do all this hard work so a business developer doesn't have to. I fully understand that some people just don't like things to be that simple. They thrive on complexity and detail. Kudos - that's what the TDD world seems designed to support.

But you'll notice that not everything in the BCL is public. There's that little OOP concept of data hiding, and that other one of encapsulation. The TDD world seems so ready to throw out those concepts - and yet those concepts are very valuable. It boggles my mind.

But then again, the web world was so ready to throw out user interactivity to get low-cost deployment. Now they are crying for Windows-like experiences to the point that they spend ridiculous amounts of money building AJAX interfaces when Windows could do the same thing at a fraction of the cost.

Is TDD really good? There's no way to know today. In 10 years you and I can compare notes and see how it went, because the only real test is the test of time - especially when it comes to enterprise apps.
Friday, June 27, 2008 12:12:21 PM (Central Standard Time, UTC-06:00)
Im working a small software development company and we are using Csla 3.0.X with .NET Framework 2.0 SP1 and uses VB.NET 2005 for our business applications that we've created for our clients. If you decided later to only support c# then we have no problems adopting it. My colleague and I discussed this blog entry to see what will be the necessary changes that will be done on the long way run if we go to C# and what are the things need to be change. Me and my colleague have come to following suggestions/requests/questions:

1.) Create a poll to determine how many VB and C# Csla .NET users? This serve as a factor to determine if it is worthwhile to maintain VB
2.) Below are the following questions/suggestions/concerns/request in a scenario where-in you decided to maintain Csla .Net in c# only:
2.a) Can VB.NET users still use CSLA .NET even the Csla.dll assembly is compiled in C#?
2.b) If VB community wishes to have VB version of the Csla, would it be possible to have a community to maintain the VB version>?
2.c) For future release of ebook/book, shall we say Csla 3.6 or above, would it be possible to have one book only and have both examples in VB and C# (just like MSDN)? IMHO, more copies will be sold for the reason it will serve as a transition from VB.NET to C# or another way around
Glenn and Winlove
Saturday, June 28, 2008 6:45:37 AM (Central Standard Time, UTC-06:00)
Even if CSLA itself was written only in C#, other .NET languages could still use it - in the end it's all .NET. It's no different than using a third-party custom control - it might well have been written in C# and you're using it in VB (or vice-versa.)

Rockford could always maintain CSLA in C# only, but provide usage samples in VB for those who use VB. How many of us actually want to modify the CSLA code anyway? (and those likely to do so either know C# or can very well learn it quickly.) I was very surprised when I found out the source code was maintained in both languages!

If the C# book comes out months before the VB one, I'll probably get it even though my C# is quite basic (we have to use VB at work.) It's usually not too difficult to find the equivalent VB syntax. Personally the only advantage I find VB has over C# is how the Visual Studio editor handles it - it feels like it "knows" it more than it does C#. Oh and I guess the "My" namespace is cool too, but then again I usually don't use it.
Monday, June 30, 2008 10:22:24 PM (Central Standard Time, UTC-06:00)
Obviously, Rocky has to go with his sale numbers.

However, it's interesting to note that Microsoft is finding a different trend on it's download site. VB .NET Express is vastly more popular along with VB sample code. C# Express came a distant third. VB is the #1 MSDN language dev center and blog in terms of traffic. VB is the #1 .NET language (as reported by Forrester Research). Check here: http://www.hanselman.com/blog/IsRootingForVisualBasicLikeRootingForTheRedSox.aspx

I wouldn't give up on VB.NET just yet.
Luis Castro
Tuesday, July 01, 2008 9:03:43 AM (Central Standard Time, UTC-06:00)
There is no doubt that VB users could use CSLA if the framework were only in C#. The .NET framework itself is almost all in C#, and VB apps are built on top if it every day. If you use ADO.NET, Windows Forms, Web Forms, WPF, etc. then you are writing VB on top of C#.

The idea of putting both sets of code snippets in the same document is not a bad one. Some publishers have tried this with various books. The general feedback is mixed - some people don't mind, others dislike it. No one really loves it, at least with a printed book, because it increases the page count and thus the cost. With an ebook it wouldn't increase the cost, and so it might be a better approach overall.
Comments are closed.