Discussion on:

Why do C# developers look down on VB.NET?

What do you think? Is it the semi-colon thing? Are there major technical differences between C# and VB.Net that I am simply unaware of? Is VB.Net really that bad, and I just don't see it? Are those C# developers just plain wrong?

J.Ja

From what I gather:

- A lot of C# people see VB as the language that non-technical programmers use because it's easiest to pickup. i.e.- it's a bastardization of their sacred art

- VB (in the past at least) was *much* weaker technically. With VC++, you were able to do direct memory addressing, etc. in VB5 and 6 (as far as I ever knew), that wasn't possible.


One thing tho. I do know that, in my readings from MSes own forums and blogs (and those of peripheral sites) that many VB6 MVPs (if I remember right...over 200) had revolted against .NET simply because...well...at least through .NET 2.0, they said there wasn't anything .NET could do that they couldn't do in VB6 already.

Anyways, I only used VC++ through version 5. It was amazingly awkward to develop GUIs in, whereas VB5/6 was simply.

And, I have to agree with you: Delphi (even back in v2 when I was using it) was much better than VB.

Nonetheless, I would rather develop in VB.NET than C#.NET for one simple reason:

When you have a piece of code in VB, it is much more readable with VB's common constructs to any programmer than C-based languages often are.

Case in point:

Bring in a programmer with no VB or C skills (say a mainframe programmer...COBOL)...and see if they don't ask what the difference between = and == is? lol

Honestly, I can learn to program anything.

Question is, do I have the time or want to spend the time learning?

Not if I have a deadline. lol

Do I think C# programmers are wrong?

Yes. Because, .NET constructs are all interpreted to the MSIL which means that all their programming constructs and what not have the same 1:1 to IL on either side...or at least, that's what I'd been told years ago. Maybe things have changed?

Hence from what I was taught, VB is just C# with a different language construct. Really no difference.

Let's be clear on this. It's easier to pick up a language than a framework. I write developer docs. If I need to write a C# and VB.Net sample, I usually write it in C#, get it working the way I want it to work, then rewrite it in VB.

Learning a language is a snap compared to learning enough of the framework to be productive. There's nothing like a code review where someone tells you that your new jazzy method does exactly what the Foo class method WidgetDo does. Augh!

a) the framework for .NET should be identical in both languages

b) you should not have to re-write it. i believe there are facilities/tools that will convert .NET languages interchangably (because of their common base in MSIL).

In the case of .NET, learning the framework is a common task to all its languages.

Learning C#'s syntax, for the average person, would be more cryptic than VB (simply because VB is more linguistically based).

Not everything translates over well. I just read article where a programmer explained that you could use pointers in VB.net. He provided a code sample and described how to do it. The problem was that he originally wrote the code in C# for an article he did in C# which does support pointers like C. He assumed that VB.net would support pointers, but the code snippets he provided would not compile. VB doesn't recognize Integer* and & isn't used as address operator. He evidently put the code through a translator and figured that it would work in VB.

It was also revealing how the translator translated the code in parts of the code, it left & untranslated and in other parts it translated it as AddressOf. Regardless, the code wouldn't even pass the syntax checker let alone compile.

The instructor, a MS Certified Training and speaker at their events, showed us a tool that could take any .NET language, translate it to IL, then to any other .NET language.

From what we were taught (this was in 2004, mind you), all .NET languages have the same backbone...which is represented in IL.

So if you use the automated tools to cross-interpret the code, I imagine there would be no issues. I can't see Microsoft making a different interpretation into IL for each .NET-based language. That would be even too silly for them.

Of course as I said, that was almost 5 years ago. Microsoft may have changed things up drastically. Wouldn't surprise me.

However if you Write in X, then compile and decompile back to X your code will look different. It will achieve the same thing, but you might not like the way your source reads anymore.

this feature he was writing about required that you run it in "unsafe" mode. I became interested in the article because I was looking for a way to either bypass or adjust the .Net garbage collector because it was giving us problems due to Citrix. Pointers would have allowed me to create and destroy objects when I needed to and not have to wait for the gc to collect them. Due to the fact that where I work is a strict VB shop, I couldn't use C or C#. Nobody, would've been able to maintain the code once I left. So, it was kind of a disappointment that the pointer article didn't work, but it may have also been for the best.

Almost every single experienced person (in the "know") with whom I've talked, and almost every single blog/post that I've read says essentially the same thing: that there's really no REAL difference between C# and VB.NET (in terms of common practical applications).

Also, I'm personally experienced in both VB.NET and C# so can vouch that there's practically no real TECHNICAL difference between the two, because it really all comes down to usage of the .NET Framework of which both are surely capable. It's all mainly just "syntactic sugar". Their usage of .NET is so similar that when I see both VB.NET and C# code examples of how to do something with .NET, it seems almost REDUNDANT because their "key" .NET usage is practically IDENTICAL (except for the C# semi-colon, of course).

I believe that it's basically just SOCIAL; mainly just a PREFERENCE, and not REALLY based on technical merit (in MOST cases).

Consider these reasons (for favoring C# over VB.NET):

1. Familiar C-family syntax; e.g. beloved semi-colons and curly braces, etc.

2. Microsoft marketing "hype"; pushing their new C# (via documentation, etc.) upon introducing .NET

3. Negative VB.NET perception / "stereotype"; VB.NET was initially confused with VB and is still negatively associated with it (at least perceptionally)

4. More terse and "clean" C#; as a bonus, also more "geekier" and a little more "cryptic"

5. Band-wagon Effect; many individuals (and companies i.e. jobs) who moved to .NET moved to C# (because more and more OTHER people did so)

That being said, I'm sure that are other reasons I didn't list. But the main point is that it is for primarily NON-TECHNICAL reasons, and that VB.NET is actually really practically on a par with C#. Just choose your "flavor" (of syntax in .NET).

This is something I've only recently come to terms with, and I think it should be an embarrassment to the field: A significant part of the technical decisions made on what language/technology to use are indeed social, not based on technical merit.

Some of it is understandable. I hear a lot that IT or a developer chose a particular language or technology to use because they liked the features AND the community around it. Likewise I've heard the same rationale for not using a technology. They found features lacking and/or the culture of the community around it was not compatible with them. A lot of technologists feel like they need to be supported, both by the technology they use, and from other people who use the same thing. However, many hate the idea of feeling like a loner on an island more than any fear of using a technology that's going to make their life harder. This is a real problem, in my view. The real focus should be use the tool(s) that help you get your job done effectively. Use modes of thinking that do the same. Engineers (I'm talking EE, ME, CE) understand this. Most developers don't.

I think part of the aversion on the part of C# developers to VB.Net is they feel that VB.Net developers came up from the ranks of VB developers, and historically VB developers were not regarded as being as sophisticated or knowledgeable as fellow C/C++/Java developers about computers and computing. So again, community (and perception) comes into play.

Familiarity plays a big role, too. A lot of C# developers came to it from the C, C++, and Java worlds. The syntax and idioms feel familiar, and so they feel like they don't have to learn as much. Personally I think this is an illusion, because the challenge these days is learning the framework, not the language.

C/C++/Java/C# developers like to think that they're powerful, but along with that there's been a sense that they don't want programming to be too easy. It's a weird thing. It may come from experience. They like the idea of having control over their environment. If a language feels too easy they feel like they're losing that control. In the past that probably was true. There are a lot of things that VB could not do in the past, where one had to "drop down" into C/C++ to do it. The thing is, this is an illusion now. As Justin was saying C# and VB.Net are not that far apart. The only real difference between them is terseness, and VB.Net does have some features that come in real handy when it comes to interacting with COM.

What I've found frustrating, just looking at the field at large is that community and familiarity play such a big role that developers often don't see that they're hamstringing themselves. They could be using something more powerful if only they would have the sense that maybe they need to learn some more sophisticated ideas and learn a new language to get out of the rut. Just because a language feels weird or feels hard to understand doesn't mean it couldn't give you significantly more power to solve hard problems more easily once you learn what it's about.

I'd make the analogy to learning math. A lot of people think math is hard, and so stay away from it as much as they can. Learning it can help one think better, and solve problems that would otherwise also feel hard or insurmountable, even you don't use the math domain you learned. It teaches you new ways of thinking.

I do think that some of the social (and other non-technical) considerations are important, particularly community. Often, the community is the best (and sometimes the only) place to get useful information, particularly with poorly documented things out there. Another consideration is the future of the system; if the vendor support is disappearing or the community is shrinking quickly, you are setting yourself up for problems down the road. Tool quality is another issue. You can have the best language and libraries in the world, but without a decent debugger, you would be in a world of mess. Another issue that "the bosses" love to worry about, but does have some validity, is what the job market looks like. Committing to a system that you can't find qualified people to work on is dangerous (depending upon your team size). If your team is 5, 6 people (or more), you can stand to lose a developer, hire another one, and spend some time getting them trained in an unfamiliar system, as long as they have a solid understanding of the fundamentals. If your team is 1 or 2 developers, losing a developer and having to lose time training someone is a huge loss in productivity. As it is, new hires take about 6 months to reach full productivity; having to give them 1 - 3 months to learn and become acclimated to an unfamiliar language and framework makes it that much worse.

J.Ja

to be sure, but when you hire a new person into a team, the issue is that if they are familiar with the language used in house you can just worry about getting them up to speed on how you guys do it and not how to actually "do" anything?

I avoided this issue because I don't know how to solve it. I think everything you're talking about centers around the current economics of development--the length of time it would take for someone to get up to speed on the development environment, the length of time it would take to complete projects. It's the same reason that I figure most shops, if they pick C# as their language, want to hire other C# developers, not people with VB.Net experience, and vice-versa. Even though they are nearly identical architecturally, it would still be considered a loss of productivity to mix the languages because the conventions are different and C# developers would have to learn what those are if their VB developers left.

I can attest to this some. In one project I worked on four years ago I mixed C# and VB.Net code. I used VB.Net for dealing with Office COM, because it was better at it than C#. I noticed that the number of lines of code I could produce in a day went down (I didn't measure it, but I could tell I was slowing down) when I switched over to VB.Net, because the conventions were different. I had to spend some time learning VB.Net syntax and semantics. I was used to the C# way of doing things. What kind of compensated for it is VB.Net brought back pleasant memories of when I used to program in Basic all the time in high school. Even with the loss in productivity I didn't regret using VB.Net for that purpose. If I had used C# I would've felt more comfortable and efficient in the act of writing code, but I would've felt less productive in terms of creating the final solution, because it would've required more work (more lines of code, and repetitive code) to get it done. So in terms of creating a more understandable, concise, and I would say more maintainable body of code, VB.Net was the way to go for that part of it. In terms of getting it done fast it may have not been the best choice (though I still managed to get the solution done within schedule constraints).

I don't consider this the best example for the higher level idea I was discussing, but it's going in that direction. I think they are somewhat linked.

I wonder if perhaps a barrier is the way programmers are trained. I have no concrete idea what an alternative would be, but maybe if programmers could be trained to focus more on architecture as opposed to the surface features of languages it might make it easier to switch languages.

I talked with Alan Kay a couple years ago about his concept of programming, and while he wasn't willing to commit to a solid definition, he said that what's important about programming is architecture/design. He said that language syntax and semantics were "building material", and the two (architecture and "building material") are not the same ideas. The language as a whole is an expression of architectural ideas. You can see that from what you discussed with C# and VB.Net: They are two different expressions of the same architecture.

I think you should learn to program in 'english'.

No set syntax or semantics.

Just write out the program as clearly as you can. Most of the basics can be taught without going near a computer never mind a specific language.

The problem is easily illustrated by going in to a book shop and looking at the programming book titles.

Learn how to program with C#

Or

Learn how to program in C#

It's a subtle difference, but a very imporant one.

Gerald Sussman gave a talk in 2001 called "The Legacy of Computer Science" that I think is in line with what you're talking about. You can watch it at http://www.aduni.org/colloquia/sussman/ (click on the link next to "Real Video:" that says "456 MB". I think what he points to is a realistic solution. He goes by it kind of quickly. The overall point of his talk was what computer science has brought to our culture, programming specifically. One of his illustrations jumps off from what you're talking about. He starts out in English, illustrating an algorithm, and then translates it into a formal language (Scheme in this case). The two match each other pretty closely, but Scheme is the more precise version.

One of the things I've heard Chris Crawford talk about is that programming introduces the idea of precise abstraction. English has abstraction, too, but it's "loosey-goosey", as he put it. So English might be good to start with with green beginners, but it's not sufficient to teach real programming. I think learning the idea of precise abstraction is essential for anyone to really get programming. It can still be English-like, but it needs to be understood that every word used and every punctuation has precise meaning. "Precise" doesn't mean that every single thing means only one thing. Things can be redefined or expanded upon, but this happens, again, in very precise ways.

ambiguous to program in and to decribe any complex algorithm in any detail you have to deal with that. That's aside from any technological limit in attempting to deal with ambiguity.
That said I see more and mote programmers who are helpless in another other language, and absolutley knackered by a change in methodology. Functional versus procedural, asynchronous versus lineear etc.

I suggest this is because the way they have been taught proramming is not language agnostic.

To me if you don't understand concurrency, scope, abstraction and encapsulation as base concepts, you'll never be able to express them accurately in any language. Learning them with a specific languge obscures the core concepts.
Best case compromise would be to do all practical exercies in more than one language, and then highlight the core concepts via the differences in implementation.

I program when I'm doing DIY, my garden, a shopping trip, a meal, even sometimes at work. . It's how I think not how I articulate my thinking.

Language is articulation, not thought.

I don't think that language has so much to do with it, at least not in my experience, but the dominant form of programming. I first learned to program in Basic, a top-down, stepwise, strongly typed, imperative language (this is old style with line numbers). Then I moved on to Pascal, which added the concepts of procedures and functions and even stronger types. I went from that to C (K & R) which cared *nothing* for types (types were merely constants for determining how much memory to reserve, and what offsets to set up in memory blocks), and whose major features were pointers and expression evaluation. Each had something for me to adjust to, but they all followed a similar form: there was one entry point, variables had to be declared before they were used (usually), state changes happened in a linear fashion, mixing assignments with other instructions, each had loops of various kinds, branching happened (sometimes with a return point reserved on the stack), but only one branch could occur at a time in a thread, and there was only one execution thread. Broadly speaking this described the architecture of all of them, and so the main challenge was learning the syntax and semantics, and the meaning and implications of a few new features each time.

When I was in college I was introduced to some other languages, including Prolog and Lisp. I had some difficulty with Prolog, but I was able to get some things about it. I remember an exercise we did with it was we set up family relations as rules, and we could do inferencing on that structure.

Lisp utterly confounded me, and that was the first time that happened to me. I think the main reason was it was explained badly, but what I understood of it was that it was a functional language (which it was not in the pure sense). Our teacher wanted us to program in it in the functional style. That was really tough. I had understood recursion as a feature of programming by that point (like I understood looping and conditionals), but I was not used to some foundational concepts of functional programming, like for example that constants are considered functions, and that state changes take place in the stack, not in a linear, top-down flow of the program. Both were critical pieces of knowledge I needed to understand it. I was taught these principles in a later class and then it made more sense to me. We programmed in another language called SML, which is purely functional, and I did fine with that once I understood the principles.

Something I've heard Alan Kay advocate for in college level CS is that students need to learn how to create their own architectures and build their own programming languages, not that that skill is going to be needed for vocational purposes, but rather it teaches some fundamental ideas about computing that are important to the discipline. I've heard Justin refer to the book "Structure and Interpretation of Computer Programs" (SICP) in the past, and from what I've heard that is kind of what it teaches (even though it proscribes building a specific language). I've heard Kay recommend it. He's even gone so far as to say that any CS professor who doesn't know how to write their own language should be fired.

Nowadays the dominant form of programming that students learn is OOP, which still has imperative characteristics, and linear program flow, but what's added are the concepts of encapsulation and polymorphism. It would be nice if the metasystem was also taught, but I doubt that it is.

I think a problem faced in educational settings now is that the languages used aren't educational anymore. When I learned Basic, it was meant to be an educational language (even though the way it was structured wasn't that good). When I learned Logo it was meant to be an educational language. When I learned Pascal it was meant to be an educational language. Java is not an educational language in any sense. It was designed for professional use. I have heard of one effort to create an easy-to-learn layer on top of Java. That might help. There are modern educational languages/programming environments around for kids in K-12 (Squeak/EToys, Scratch, Alice), and for those schools that have a healthy programming curriculum, I hope teachers are aware of them.

I agree that exposure to multiple programming models would be helpful. I think Ruby is kind of a nice language for that. It has OOP as well as functional characteristics. Python is another one. Both offer interactive interpreted environments (Squeak/EToys and Scratch do as well) so students get instant feedback, which I think is great. I remember Apotheon mentioned Berkeley Logo a while ago. That's available on the internet. It's been described as "Lisp with M-expressions" (ie. without parentheses). It's interactive and it still has its graphical capabilities, as would be expected. So the tools are out there.

The higher-order problem is the language agnostic programming paradigm, but when someone knows only one language, that language defines the paradigm even more strictly. For instance, learning Algol was a revelation to me after having only known BASIC and COBOL before, even though they're all imperative languages.

But I most heartily agree with Mark that more of the theory of programming should be taught in school. We need something to make programmers shy away in disgust from 90% of what gets dumped into today's code.

The map is not the territory.

Have you ever seen a tourist in London, look at an underground map, and then use it to walk over ground. I have, except it was a guy who tried to switch from Fortran under VMS, to VB6 under windows. It was awful, because he didn't know the why of Fortran or VB6, he'd been coding by numbers. I guarantee if he'd gone the other way, he would have created just as big a mess.

He didn't even realise how much of an arse he'd made of it. This is a guy with more letters after his name than I've got in mine!

How to teach it right, is something we need to figure out, that we have been teaching it wrong is entirely self evident.

I don't have much time for academics in IT, I mean we are talking about people who invent shelfware, and think the Vienna Development Method works.

When I was intially taught to program, my teacher made us write a lot of psuedocode, and she taught us that it was very important. To this day, when I am faced with a challenging code problem, I break out my pen and paper, and write the psuedocode to the situation, or I draw a flow chart in Visio. Old fashioned? Sure. I haven't seen one of those flow chart stencils on a programmer's desk in over a decade. But there is no technique better for breaking through barriers.

That's actually one thing I *do* appreciate about VB.Net, is that it very closely resembles pseudocode. It also makes it good for code examples, because even if you have never seen it before, it is easy to follow, since it spells everything out in detail. On the flip side, over the last year or so, I've discovered that everyone in the .Net workd can read C# enough to follow an example, so it's a half dozen of one, six of the other situation now...

J.Ja

how good the language is, is irrelevant.

Most of the time in .Net, it's not about VB or C# it's about .net. The framework is so big, the language you use to manipulate it, becomes trivial. Managed C++ would be in the same bracket to me. Now if you wanted to do unmanaged .net and you have a VB only background I see biiiig problems.....

I've never found it all that useful. Maybe it's just that I'm such a language geek, but I find myself creating syntax rules for my pseudocode, so it ends up being just another language. For me, it's easier just to say it in code, and then revise as needed. OK, sometimes if there's a particularly complex section that will need to be figured out later, I'll stick in a comment like
// miracle occurs here

Mine starts out something like the statements we used in top down design. Generally I don't got much further than 'public' method name and maybe parameters.

Some time I don't even bother with it and simply stub out a class. It always been my experience if you can get that far and get all your functionality reasonably well described, you can pretty much do what you like inside.

We all have our design phase, from a bit of thought and few decent names to 3000 pages of UML diagrams. The important bit isn't which abstraction you feel comfortable with, but that you are as far away from code as you can get, when you start.

That's what learn to program with code misses.

is true, and should be in my opinion.

programming should not be easy.

when it is, you get people who lack the patience and discipline programming "because they can" and you end up with bad programs.

I see what you're saying. If programming becomes too easy to enter into you do get people who don't care to write code well, but this is also a function of the wider culture. In business computing the sole focus most of the time is "Get it done fast. I don't care how." So the less knowledgeable programmers, not wanting to lose their jobs, do just that. What results is a steaming pile...

What I see going on with regard to "difficulty" in programming is a kind of self-flagellation: this is difficult because it should be. There is value in having high barriers to keep those people out who are not willing to commit to quality. However, once knowledge of what it means to program well is achieved we don't move beyond languages which hamstring us. That's what I was talking about. It is possible to move beyond this to languages that provide leverage: taking sophisticated ideas that are normally hard to implement in weaker languages and expressing them concisely.

A good language makes it easy for someone who knows what they're doing to accomplish their task, without getting in their way. It doesn't necessarily make it easy for an idiot to crank out 99 copies of the same Visual Crap(tm).

Thanks for expressing it more clearly than I could.

so that they don't try other languages.

I am a VB.Net developer who is transitioning to C# for one simple reason. C# jobs pay more. Why? Because people are stuck on the idea that because C++ was better than VB, C# is better than VB.Net. So long as they think that, they'll pay more for the skill set. And as long as C# developers make more, people will think C# is better...see the circle go round and round?

been arrogant. Not all, of course, but many. To some of them, it seems that the more cryptic and indecipherable their code, the better they believe they are.

Don?t get me wrong. Some of my best friends are C? programmers. Of course, some of my best friends play Bridge and I can say the same about some of them.

Ken

... back when all we had was a C compiler and the Windows SDK -- we have a right to be arrogant, if we're not living in an asylum.

of my switch statements all beginning with cases of WM_ and running on for eternity.

... and you memorized the argument signatures for 50% of the API. SendMessage, BeginPaint, EndPaint, SelectObject, TextOut, BitBlt, etc.

that, you only did things that were worth doing and you did them right.

In the early days, there were a lot of misunderstandings about how things were supposed to work. But Charles Petzold's book Programming Windows was a lifeline in a sea of troubles.

you were just willy nilly slapping things together.

You thought about it.

Code Complete (I think) which is coding the MS way basically.

Lots of good stuff in there, not stuck to a language, but the theory behind it.

I love the "why"

I've seen a lot more shoddy code written in VB.NET than in C# and in my opinion this is because VB.NET is perceived as easier by beginners / non-programmers. They are therefore tempted to use VB.NET rather than C#, hence it is statistically more likely that a piece of VB.NET code was written by a beginner than a piece of C# code.

In my experience it is *really* easy to find a really bad VB.NET programmer, but not so easy to find a really bad C# programmer. Again this is due to the statistical distrubution of skill level being skewed by the perception of ease of use.

So, I always warn my clients off using VB.NET for any project because they'll find it a lot easier to get a bad coder. I do tell them that this is the reason though and not due to any technical differences.

That said I'm a C# programmer and I resent these upstart VB.NET 'programmers' coming over here and stealing our jobs

I hear that all the time and it's a load of fertilizer. First of all, if you want to argue statistical distribution, and others are to be believed, there are many more new C# programmers than VB programmers, so even f the percentage of bad VB programmers is higher, there are likely more bad C# programmers because there are simply more of them.

I, for one, have seen more than my fair share of awful C# code (including code developed by $150/hr consultants). Most schools teach C/C++ or Java and other beginners may pick up more tolerant languages like Perl and PHP, or start out "programming" with tiny bits of JavaScript; all use the C syntax, so it's natural for them to go to C# when they pick up .NET. Frankly, with its more tolerant use of side-effects, C# offers at least a few more places for ugly, obfuscated, and awful, code to function (there is no obfuscated VB contest...there is an obfuscated C contest).

But more to the point of this article, most programmer sins are related to ideas and constructs, not syntax. My favorite was a solitaire game developed in C# that didn't use arrays or loops; each card was a picturebox control and each had its own separate event handler. I can't do justice here to how much copy-and-paste code was in it. The guy didn't get fundamental programming ideas (even after finishing a ComSci degree); he'd be just as lost in any language.

If you're talking purely about self-taught hobby developers just messing around, there might be a tiny nugget of truth. But you've already mentioned warning off clients; what we're talking about here is paid, professional programmers. Newbies in the field will go for what they hear is popular, what their school taught them, or what the first place that hires them uses. Based on (unfortunate) current reputations and programs, that's not nearly as likely to be VB.NET.

OS/desktop programmers treat web programmers like a bunch of them hobbyist types you mentioned.

Personally I could not care less about the language you use. I do think too many folks use one language as their only tool. As the old adage says, "if the only tool you have is a hammer, every problem looks like a nail", or something like that.

doug

you must use OOP

How many features are the C# programmers now enjoying that were written for VB.
Lay off the battle and do what you enjoy doing in the application you feel most confortable with.
Personnally I do not like working with C# although I have to do it from time to time

Are you confusing language, the .Net framework, or Visual Studio features?

can't think of a single one.

I just took a one week class at Interface Technical Training and still have a lot of learning-curve ahead of me. That is because IBM stopped making significant improvements to their AS/400 in the mid to early 90's.

We already knew that the '400 was NOT object-based. But many of us did not complete our transition to Object-Oriented C and C+ that was already available. I was one of them.

We in the former IBM-world are already used to the semi-colon but have a lot of drilling to do to acclimatize to C#'s presentation of Classes and Methods.

I already own and am studying John Sharp's Visual C# 2008 Step by Step. And am re-doing the exercises in "Introduction to Programming Microsoft .NET Applications with MS Visual Studio 2005."

Thanks to my instructor, I am getting a lot of pointers from my instructor at Interface Technical Training (no I am not advertising for them!). Still am looking for more C# books -- not for VB.NET programmers but for main-framers not accustomed to the .DOT framework.

So I am looking for C# books. We have VS 2008 and I already have my first assignment. We are looking to replace an RPG-IV program (2,500 statements - a book) with a few pages of .NET.

Yes, I am struggling, and yes, I am enthused.

Any books, quick starts suggestions?


--John

I understand the feeling of frustration being stuck in a dead-end environment. Our shop just laid off two AS400 guys programming in RPG. This is primarily why I'm learning C#, coming from a background in VB and VB.NET. The book that has been most helpful to me is "Professional C# 2005" by Wrox.

I will get that.

-John

John, I went through what you are going through back in 2002 when I got laid off from my AS/400 RPG job. I got another job in a company that needed some programming done. I chose VB.NET and taught myself the language. There is a transition in thinking when switching to an OO language. The online forums were a big help in that effort. Be sure to look into them. I encourage you to stick with it even if some of the concepts are not easy to grasp at times. It's worth it and you'll be happy in the long run. I went on to learn C# starting about a year ago. Transition from VB.NET to C# was not a great leap.