Discussion on:

My move from VB.NET to C

VB.Net is a decent enough language, and does everything that C# does. At the same time, a lot of shops prefer C#. Have you thought about moving from VB.Net to C#? If so, why? If you haven't made the move yet (or decided not to), why?

J.Ja

Yeah, I was in a similar situation, having done Assembler, Basic, Pascal, C, VB6, Delphi (Well pascal), PHP, yet for some reason C# .Net seemed too complex, I put it off for a long time.

I actually thought due to the fact so many languages were about, something else would supersede it (like D)

But after actually learning and developing with it, the complexity fades, and it seems to grow on you. Things that were complex in other languages to acheive actually seem simpler in C#

Out shop codes in both C# and VB.NET just depends on what project we are working on. We develop Office based applications and find VB.NET is far better suited for Office development but one can use C# too. Before .NET we developed Office apps using VB6 and C++ and VB6 was too far better to develop Office apps than usign C++.

With C# one still has to pass all of the optioanl parameters whereas in VB.NET you don't. Plus one can record macros in Office applications and with a few simple steps turn the macro code into managed VB.NET code.

I been in the software business for over 25 years and I have never understood this silly language wars nonsense. I also come from a construction background and it comes down to using the right tool for the right job and the same applies to software.

It's nice to see that some people really have the "right tool for the job" philosophy.

I never understood those language wars... as a result I can read quite a few of the languages available as well as some "dead" ones. With some effort I could most probably master those I don't code in already (VB Classic, VB.NET, C#, PHP, Perl, Ruby, Java).

I get the feeling people just get comfy using their hammer and then try to change everything into a nail

On the other hand, from a business stand-point it makes sense to stick to one language or another, it's easier to move people around from project to project and hire new people when you have a "language ecosystem" that is uniform and simple.

That's the funny thing, while I always "felt" like I was missing something by using VB.Net instead of C#, I really don't enoguh practical differences to say that one is the "right tool" over the other, *all else being equal* (namely, what language you knew before you came to .Net, special tools that might only work with one and not the other, etc.). It's like the difference between a framing hammer and a basic claw hammer, for 95% of jobs they are completely interchangeable.

J.Ja

It all has to do with perception...

And your example with the framing hammer and basic claw hammer is that... use the tool called "professional" and you can claim lot more buck when doing a job...

That being said, the perception of limits that VB.Net seems to impose can play to your advantage when writting business level logic in your application. We all know one developer who did this very twisted thing just because the language allowed it... I have seen many of those doing VB.Net

Speaking of perception... it's funny, but 10+ years ago, that one developer doing those twisted things because the language allowed it, he called himself a "hacker" and prided himself on it, and everyone else was awed by it. Today, that is the person that everyone dreads having on their team, because the code only makes sense to the original author.

J.Ja

Yes definitely, best to use the appropriate tool for the job, though I've found my personal preference is C# over many other languages. At the moment it is my first choice for development of any application.

I recently returned from Microsoft TechEd developers, most of the code samples during presentations were done in C#. Additionally, Bill Gates gave the keynote address and the fact that he even had to address the question of "What is the future of VB?" was enough to raise an eyebrow. Bought any ASP.Net books from Microsoft lately? All the code is now in C# with VB.Net code on the included CD. Maybe I am reading too much into it, but I recently made the jump to C# as well... It isn't so bad.

Yeah, I've seen the same de-emphasis on VB.Net in samples and such as well. I am not sure if it is a deliberate "push", or that they just assume that anyone reading more "advanced" items will be using C# (or at least be able to comprehend it), or maybe it is to avoid the "Mickey Mouse" reputation of VB.Net. I have also noticed that as of .Net 3, C# gets new features much sooner than VB.Net... nearly a year earlier for LINQ and closures, for example. The support for VB.Net is sstill there, but I definitely get the sense that Microsoft considers C# the "favorite son".

J.Ja

of what they did was VB. The only time they did C# was for some of the new language features that weren't in VB at the time.

I can muddle my way through VB, but in my opinion it still contains far too many syntactic and semantic compromises to ease the transition from VB6, which was a f'ing horrible language.

For the more down-and-dirty stuff, C# certainly. For the stuff that needs to go out quickly, VB.net

IMO, it doesn't hurt to know both.

I agree it doesn't hurt to know both. However, I disagree with the notion that one language is more suited for rapid deployment. I am a C# programmer who knows VB.NET. I don't see any area where VB.NET increases my speed to market.

I think that VB.Net improves speed to market when the developers are transitioning from VB 6, VBA, etc. and don't have a steep learning curve. On that note, C# reduces speed to market for people transitioning from Java, C/C++, etc. I think that if someone knows them both equally well, neither one is outstandingly faster to write than others.

J.Ja

Microsoft is not trying to kill VB, it's just a lack of resources. That and most CS/EE grads are versed in Java nowadays, and C# is so danged close they are like twins.

Besides, the language isn't the big deal. When I had to write both VB.Net and C# samples, I would first write it in C#, then rewrite it in VB.Net.

The real issue is the framework. The bazillion classes, methods, properties, etc. It's always embarrassing to have someone point out neophyte code. For example, just in the past month I found out about the String class IfNullOrEmpty method. I'd been writing:

if(null == name || name.Length == 0)

I'm sure I will run into more of this as folks see my code.

doug

You know, I've been working in .Net since around 2002, and I never knew about that method either. Thanks! I've been doing the same thing as you have been. That is one of the big issues with learning by "jumping right in" like I do, sometimes some real "duh" knowlege goes right by you. Heck, I didn't figure out delegates until less than a year ago, simply because I had no reason to use them. Why? Because for the multithreading stuff, AddressOf() in VB.Net is sufficient, and it was not until about a year ago that I did some things that actually needed a delegate.

J.Ja

Ya know ... at this point in my career (+30 years) I stopped carrying a torch for one language over the other some time ago.

Whichever language suits the purpose is fine. My rules engine is all in VB.Net, a bunch of the stuff is in VB6 and the rest in C#. I can deal with all of 'em without getting my shorts in a wad about it.

My 2-cents.

-CB

Quote: C# simply did not have any features that VB.NET did not have that I needed ? until the release of .NET 3.0. With that version, C# had LINQ and closures, and VB.NET did not; this was corrected in .NET 3.5 and Visual Studio 2008 -Quote

If that was your prime reason for moving to C# your logic is wrong. Linq is part of .NET 3.5 and both C# and VB have full Linq support. .NET 3.0 does not contain any Linq bits. .NET 3.0 was a library release and contains the WPF, WCF and WF pieces. There is no advantage to either language as these are merely adjunct libraries for the .NET 2.0 runtime and both languages can utilize these libraries.

In the .NET 2.0 release however you are correct. C# has anonymous methods (VB did not get these until the 3.5 Lambda implmentations) and C# iterators. I'd say the iterators are the more interesting of the these two.

From what I have read, LINQ came to C# when C# hit version 3.0, which happened at the same time as .Net 3.0; VB.Net did not get it until version 9.0 of VB, which was .Net 3.5. At least, that is my understanding of it. LINQ was a reason why I *wanted* to move to C#, but not why I eventually moved. simply put, a project I was working on was modifying C# code, so it made sense to make the move.

J.Ja

What really bothered me about VB6 (and earlier versions) was that it wasn't an object oriented language (though 'object-based') and it was more 'fast and loose' type programming (although one can use things like 'option explicit'). At the same time I hated the memory management issues of C and C++ (especially for run of mill business apps).

So I avoided VB and C/C++, and ended up working with PowerBuilder for many years and was excited when Java came on the market. The problem with Java was no good development IDEs. Finally with the advent of .NET Framework developers had a real choice. VB.NET for the VB guys and C# for those who wanted to work with a 'clean' c-like language without some of its challenges (like memory management).

Think about this. What languages do Computer Science departments use to teach programming concepts? Usually a C-like language like C/C++, Java, C#, but generally not VB. Why? Probably the C type languages are 'cleaner' and allow students focus on concepts without getting exposed to baggage that VB brings.

Actually Microsoft 'had' to support both VB.NET and C#, so as to not lose the VB6 developer base 'and' capture the Java/C++ crowd. Longer-term, however, the trend seems to be away from VB.NET. Ask any Microsoft rep what they use internally to develop their tools. If it is in .NET, then it is likely C#. If Microsoft uses C# as their defacto .NET language, shouldn't you?

really quite arrogant about their high-class language. It used to be that the more unreadable their code and the more incomprehensible their semantics, the better they seem to think that it is. It that still the case?

After 25+ years of programming, I will learn C/C++/C#/C-Whatever if I need to. Until then VB.Net works fine for me.

Ken

Ken -

It's odd, but I finally "got" why those old C/C++ coders had that attitude. I think that they were really upset when things that used to take them 2 weeks at $50/hour to write could be written by anyone with a minimal amount of training by literally dragging and dropping. I vaguely remember looking at some C++ code back in the "good old days", just the code needed to get the Windows API to put a window on the screen with some buttons and such. It definitely made the bank account bigger! So yeah, I am sure a lot of those developers felt pretty threatened when VB 3 came out. It also doesn't help that the first few waves of VB developers really had a lot of people who had no idea what they were doing, and VB let them into the business when they could not have come anywhere near being called a "developer" without it.

J.Ja

i don't think c++ coders are arrogance (anyway i am a as400 rpgle programmer). there are valid reasons why they are high paid professional. you got to realize programming is more than just UI dragging & dropping, it takes years to become well-versed in o-o design, patterns, architecture, testing, performance tuning, etc.
90% of the vb programmers i met have very bad programming practice. they always take short cut & ignore the code quality.
i think this is the problem putting programming tool in the hand of someone without software engineering background.

Talk about laziness; is it that difficult to figure out proper verb conjugation, or better yet find the time to use the shift key?

Your post epitomizes arrogance as elitist ignorance. 90% of the VB programmers you've met have bad programming practices? What, you analyze their code, or they have trouble understanding yours?

VB is a tool, like JJ says enabled many people to enter the programming and developer fields that would not have been able to do so otherwise, and satelite technology allows worldwide communication, but a very small fraction of high end users of satelite technology could launch a satelite, or enable it to be a conduit for the massive communication it provides. Look, you only need to invent the wheel once.

As far as beeing highly paid, I see that your denial has landed you in the unemployment queue, and while I am sure that your unilateral dismissal of VB programming has nothing to do with that, I will let you know that I have been a very well paid for exclusively VB programming for the better part of 12 years, now. Enjoy your as400 rpgle niche you got going there.

Perfect reply.

I have to say, damn C# is an acquired taste when you come from a VB.NET background. Like Justin, I just didn't see any advantage in C# over VB.NET that justified making the move.
After using it for 3 months or so I can tell you that I find it hard to open my VB.NET solutions. They just seem so bulky and tedious to work on. I don't know what it is... Even though VB.NET is more verbose I actually somehow have an easier time understanding code at first sight in C# than VB.NET... my mind appears to have a thing for C#, lol....
Also, I find coding C# in VS much faster than VB.NET. Intellisense behaves differently as it stars displaying members at the first keystroke as opposed to the DOT (.) in VB.NET unless you write the Me keyword first. That alone got me off the bad habit I had developed of using the Me keyword all over in order to get intellisense-based fast typing.
Compilation seems faster too for some reason (technically they both produce the same IL code, except for NOPs).
Being able to just continue writing in the next line without having to use line continuation characters is also a HUGE plus. Native refactoring in VS 2005 for C# is great even though the VB.NET addin is not bad either.
What can I say, perhaps it's the thrill of working in "new" technology or maybe I just have fallen in love with them damn brackets, lol....

I use this. all the time in my C# code, mainly to *reduce* the number of matches to scroll through.

I haven't seen anyone harp about case-sensitivity. This usually trips up VB folks at one time or other. Fortunately I came up through the Unix ranks, so I always liked abc != Abc.


doug

I use "this" a lot too. The reason for me is that if I write a function that accepts a parameter which acts upon a class's property of the same purpose, I give it the same name. This happens a LOT in constructors. Like:

Class(int Property1, int Property2) {
this.Property1 = Property1;
this.Property2 = Property2;
}

I suspect that this is basically a result of my evolution from procedural coding to OO coding. Heck, I am just now switching to camel case, which I find to be against my inner nature as well.

J.Ja

That's almost as bad as

Class(int property1, int property2) {
Property1 = property1;
Property2 = property2;
}

And everybody knows braces should be at the same indent level!

... was developed when I was TWELVE for crying out loud. And that idiot Visual Studio keeps changing it! I was taught to put the open brace on the line that initiates the block, and the closed brace goes at the end of the black, same level as the line that initated the block. Then again, the person who taught me that also inflicted COBOL on me as my second language.

J.Ja

You do know that Visual Studio will let you specify how braces appear, indentation, tabs versus spaces, etc? I think most IDEs do that (heck, even emacs has the feature for us uber-geeks).


doug

Yeah, I know I can configure them, but I'm hoping to slowly beat myself into a more modern usage of braces and notation. I've had such a "hit or miss" type of "upbringing" on these things, a result of being largely self-taught, and I feel like it is time for me to get in line with some standards on the topic.

J.Ja

I admit it, I am guilty of same name variables in constructors, but never with the same cAsInG as the property!... lol

In fact, that is when I find case sensitivity useful...

I hate that thing with the braces too. They should be indented at the same level, but I understand Justin's point, ols school folks have that engraved in their heads for some reason!

Kernighan & Ritchie, in their original book on C, put the braces at the end of the line. That seems to have caused a lot of people to believe it is the one-true-way, including many in my company. It makes some sense when your "if" condition is short and the block is short, but makes it messy otherwise. Brace style is just a religious topic that you can't talk some pople out of.

I've heard other arguments, too. For example, it's pretty easy in emacs to write a macro to show you the whole line of code in the status line (without moving your cursor) that matches a closing brace. It seems to me it ought to be only slightly more difficult to show the previous line of code. But then, I'm a vi guy (which is another religion altogether).

In my mind, as long as everyone on a project does it the same way, you'll adjust. Unfortunately, we don't even have those kind of guidelines at our company (Kernighan laughed at this when he came to speak to us.)

Bracing style is a *style* not a rule.
Consistency is the rule.

Well, i'm more or less stuck with VB technology (ASP, ASP.NET, VB.NET, VB6). I've basic experience with Java and C#.NET. Not sure if i can make the jump.

FYI VB.NET and C# are both .NET languages and both compile to IL (Intermediate Language. If you know how .NET works and you're familiar enough with the necessary libraries, then using C# is just a matter of learning the C# syntax, which shouldn't be hard if you've done basic Java

You will need to get used to a few things but other than that, you should have no problem making the switch.

Don't fear, just go for it.

Thanks man, will try start my next project in C#. thou i believe there might be some frustrations in "dimming" in C# and leaving out the ";"

There is a large volume of VBA code that require maintenance and support. (MS Office and other major VBA enabled applications - and user's VB script.)

Until MS provides C# support for Office similar to VBA there will always be a requirement for VB skills. Regardless of the hype - MS does not appear to be committed to C#.

While it is true that large projects can use C# with Office - the small quick & dirty, user created VBA popups will continue to dominate MS Office.


Personally however I prefer C#

You are right about that. On the other hand, VBA (or, != depending if you've moved to C# yet ) VB.Net. VBA is really VBScript, wrapped in the appropriate object model (ugh). I *wish* it was VB.Net, then maybe, just maybe, the Collection object would support an Exists() method, instead of having to do:

Dim bFound As Boolen
Dim vTemp as Variant

bFound = False

For Each vTemp in cItems
If vTemp = vWhatIAmLookingFor Then
bFound = True
Exit For
EndIf
Next

If bFound Then
'Process
Else
'Not found!
'EndIf

It gets REALLY old writing that piece of code 50 times per application...

Of course, while VBScript/VBA and VB.Net are different, they are close enough to be considered as "the same" as VB 6 and VB.Net.; skill in one is directly usable in the other.

Additionally, it is possible to automate Office from .Net (both VB.Net and C#) using the VSTO system, but I beleive that the vast majority of people programming towards Office are still using VBA within it, rather than .Net external to it.

J.Ja

I don't remember how exactly, but you can form a really big string of VBA code and use some method to execute it. So you can still use your VBA code in C#!

However to paraphrase the saying: "if it works don't switch". So I can understand that you waited to make the jump (even if it is not really a "switch"). Moving to a new language when you master one that allows you to do everything you need is not a step to be undertaken lightly.
I don't fully agree with your statement that "C# is not more complicated than Java". Like you, I had been reading samples of C# code here and there and managed to learn the basics. However, for a few weeks now I have been "forced" to use it on a real project and learnng it in more detail. The result is that I feel that C# is sligthly more complex than Java. Some of the reasons include:
- It has a syntax that allows you to implement value semantic (the struct). While this is useful it does add complexity to the language while not being absolutly needed.
- It includes an overabondance of keywords. delegate is an example of this. Reading about it I quickly realized that this was just a syntactic convenience to implement the Observer/Observable pattern on steroid. It would have been good if it were not for the fact that you have to write almost as much code using it than using the Java Observer/Observable types.
const and readonly would be another example (one concept would have been sufficient).
Don't get me wrong (and I don't want to start a language war here) I'm glad I can use something like C# for my project. However, I feel that C# is more complicated than Java. For my part I decided that I would restrict myself to the subset of C# that I absolutly need (no struct, minimal operator overloading, etc...).
The one feature that C# has (no it's not closure) that I would like to get in Java is the accessor syntax (properties). This allows compliance with the "uniform access principle" and is a really nice feature.
C# Indexers are nice but could have been part of the operator overloading package. I think operator overloading should be available in Java. Used wisely (minimally) it is a great productivity booster.
I hope you enjoy your C# experience.
JS

It's been a *long* time since I used Java, and I never got *too* deep into it, so it is quite possible that (as you've pointed out) there are some deep features in one language and not the other. In fact, the way I program has evolved a lot, too. Java was my first OO language, so it never occured to me to look for certain features, particularly since I was transitioning from Perl at the time (now *that* was a hard leap to make, I kept trying to figure out a way to use eval() ). Now that's I've been using OO for about 7 years now, I immediately looked for things in C# that it never occured to me might be in (or not be in) Java.

That being said, when I compared the two, I meant (mostly) on a syntactic level. Even there, C# supports some things (closures & LINQ for starters) that Java doesn't, which makes it more complex. However... I think that the C# features and syntaxes that I know to not be in Java, and the ones you mentioned overwhelmingly fall into the camp of, "few programmers will use this" (other than, ironically, the property system, which I also greatly prefer over Java's; I just discovered "auto declarations" of properties and I love 'em). Yes, you know about it (despite your relatively short time with C#) because you (from what I can tell) are a very advanced programmer who would seek these features out and use them. But I think for the typical programmer, these features are lost on them.

J.Ja

I would not take any chance. If I was leading a team of programmers on a C# project I would define clear rules of usage (I would do that for any language).
The usage of some of the language features would be questioned when caugth in code reviews.
In his book Surviving Object-Oriented Projects Alistair Cockburn has a great section on technology. The section titled "Managing C++" is a great example of what I am talking about (the book is all good).
JS

Good point. I might check out that book, if I have the time for it (sadly, not likely ... my "to read" list now fills more than a shelf...).

J.Ja

One concept perhaps, but two quite different implementations (run-time vs compile-time).
A class can change the value of a readonly variable during construction, so you could have a readonly variable that represents a random number that changes with each new object.
A constant random number will only be random once (when you assign it at compile time).