Learning C#

C

cuemasterfl

Supreme [H]ardness
Joined
Jul 5, 2001
Messages
4,181
I've been programming in VB.NET for a while, and deem myself to be pretty decent at it. I'd like to get into C#, but I was looking at some books this lunchtime in the local bookstore, and it seems that 95% of pretty much every book (100% in some cases) only deal with the console. I want to write Windows Forms (maybe some WPF) programs mostly, not be stuck writing console programs. Am I missing something here? I looked at the VB.Net books too, and of course they're all Windows Forms based.

Would it be so bad if I just stuck with VB? I'm not planning on writing Starcraft III. I want to concentrate on Windows applications and maybe some 2D games. Thank in advance for your opinions.
 
You can write WinForms and WPF apps in VB.Net as well as C#. Sounds like you're making a decision on a bad sampling of books, or some other fundamental misunderstanding.
 
Yeah I know I can write WPF and WinForms in VB and in C#, but the books I saw focused on the console. I am sure there are better books out there. I'll look tonight when I get home. As far as my last question is concerned though - would it be so bad to stick to VB? I am afraid I'll apply for some programming job somewhere, and they'll say "Oh he only knows VB, forget him...."
 
It's just mostly syntax differences between VB.Net and C#. Objects are the same. This book is worth the read if you're interested in the gritty details, but know that it is becoming dated as the VB and C# teams close the gap. Still a good, quick read.
 
As an Amazon Associate, HardForum may earn from qualifying purchases.
So basically you're telling me that there's nothing wrong with sticking with VB.
 
Having familiarity and experience in both C# and VB.Net would be better; once you have one, the learning curve for the other is considerably shorter.
 
I wouldn't hire a developer who only knew one language, no matter what that language was.
 
If you can deal with windows forms in VB.net you should have no problem doing it with C#. All the property and method names are all the same.

The reason so many deal with console apps is because they are teaching programming fundamentals. Dealing with windows forms stuff is easy-peasy compared to juggling around massive complicated data structures

Just using intellisense should suit you virtually all the time.
 
I'm a professional .NET developer. DON'T waste your time with VB.NET. C# is THE .Net language for now. It's easier to back into VB coming form C# than vice versa if you need to.
 
heatlesssun said:
I'm a professional .NET developer. DON'T waste your time with VB.NET. C# is THE .Net language for now. It's easier to back into VB coming form C# than vice versa if you need to.
Click to expand...

I agree completly. I am also a professional .Net developer. I do both web and winform apps. Personally I find the C# syntax much nicer. In reality there are not a ton of differences in what C# can do that VB can't you are targeting the same framework.

One thing in particular I like is the lambda syntax in C#

e.g. a simle linq query
var model = myDataContext.Orders.Where(x=>x.OrderID.Equals(1)).Select(x=>x);

I don't have the vb code here but it was much uglier.
 
I appreciate the responses guys. When I look at C# code, I see curly braces everywhere and it seems confusing. I see clear code with VB. I do know that C# is faster, but can you really do more with it? What can C# do that Vb can't?
 
i wouldn't necessarily say that c# is faster than vb since it's all compiled to the same whatever that CLR thing is called (if i know anything about .net....)

i'm the opposite of you as far as i look at vb and see a confusing mess :p
 
cuemasterfl said:
I do know that C# is faster, but can you really do more with it? What can C# do that Vb can't?
Click to expand...

That's quite a loaded question. They are both Turing complete languages, so you should be able to solve any solvable problem with either one.

In terms of language constructs, there is very little that C# can do that VB can't. However, there are also a few things you can do in VB that you can't do in C#. Google can help you find the specifics here, since it changes based on which version of .Net that you are using.

Going from VB.Net to C# is easy in terms of environment and concepts, since they are basically the same. The biggest difference between C# and VB.Net is syntax. You should learn C# so you are comfortable reading any C-based language that is full of curly braces and semicolons (C#, C++, Java, etc).

If you want to be a serious programmer, learn C# and then keep learning other new languages. You could take small steps like moving on to Java, Ruby, or Python or dive in with both feet and learn some assembler (x86 or some RISC architecture). Once you know half a dozen fairly different languages, you can pick up most new languages in a few hours to a few days.
 
mikeblas said:
I wouldn't hire a developer who only knew one language, no matter what that language was.
Click to expand...

What would you look for in an applicant fresh out of college?

btw: not suggesting your criteria is wrong at all, just wondering how you'd apply it in that situation.
 
Last edited:
rflcptr said:
What would you look for in an applicant fresh out of college?

btw: not suggesting your criteria is wrong at all, just wondering how you'd apply it in that situation.
Click to expand...

Most computer science degree program use multiple languages across the classes.
 
My current company does not do many entry-level hires, but I'm thinking I'd like to get an apprentice to train and help; I'm just so resource-constrained, it's killing me.

The answer is really situational. There are companies that would hire guys who don't know anything and train them on the job. Most of the companies I work at wouldn't do that; we'd want to see a few languages, and a couple cool multi-person projects. Even if the projects didn't go anywhere or sucked, being able to articulate why they didn't go anywhere, why they sucked, what would've been fixable, what should've been next, or so on, goes a long way towards showing customer and industry knowledge.

Say you're talking to an artist, and he shows you a drawing. The drawing is of a guy who wears leather pants, has owl wings on his back, shoots laser beams from his eyes, and fires missiles from his fingers.

So you ask him: Why did you draw that? Why does this guy have all those features?

He might answer by saying that this guy is a character in a world that he thinks about, where he flies around and zaps criminals and dispatches justice. He has a nemesis, but he didn't draw that guy yet, and he might change from missiles to atom bombs because of some reason that makes this hero a better fit against the nemesis character.

See? He's thought things trough. He's creating something big and interesting. If I ask him why he doesn't have infrared laser eyes instead of visible laser eyes, I should get an answer that shows me the decision wasn't arbitrary.

Most candidates we get, when we ask them why they did a particular free-time project on their resume answer "lol, idk". It's entirely unacceptable. They haven't fit their work into any grand scheme; they're just writing arbitrary code without any goal. Even if the answer was that they didn't know a particular technology and wanted to experiment with it, that's fine -- they're just trying to learn.

It doesn't take schooling or experience to have smarts about deciding what to do. (Experience can help, tho.) It takes common sense. That's something we really look for in all hires, but it's one thing that I expect of entry-level hires because they're not likely to be able to show much else for technology skills.

Think of all the interview cliche questions you've heard of: reversing a linked list, fizz-bin, writing a binary search, and so on. I'd expect an entry-level hire to pass those. They're simple. Doing more involved questions is something more senior guys can do; but being able to code simple idiomatic algorithms on a whiteboard, troubleshoot them, explain them -- that's certainly requisite.

Language doesn't really matter for those things.
 
Mikeblas: great post, and very helpful.

AlienKing: The syntax is what puts me off C#. As I said before, seeing {} everywhere puts me off, and I think the syntax is VB is much easier to understand than in C#.

I do believe that at the end of the day, the most important thing is being able to achieve the objective - regardless of the method. This makes me believe there's nothing wrong with sticking with VB.

Edit: That doesn't mean I'm not going to learn C# too :)
 
Last edited:
Unless the job you are applying for only allows you to tackle that problem via a specific method i.e. language.

Your code tends to exist in the company far longer than you may stay in that position. If you use something different then that means the next guy trouble shooting / working with it has to be able to read it, work with it, understand it, fix it, etc.

Depending on the company, you may not be allowed to tackle it with whatever method/language you want. And often you aren't building the entire product yourself, which appears to be the mindset you are looking at this with, and that means your problem also becomes the guy's your component is trying to interface with. You've got things like XML and such to help you with problems like that, but in the end you are just patching a problem that could have been easily avoided.

My advice: Learn as many languages as you can. It's fine to keep your specialty in VB if you'd like, but at least become familiar with some others. It's helpful to be able to look at code, have a basic understanding of what is going on, and not get tripped up by relatively simple things or curly braces.
 
to the OP: you'll learn to appreciate the curly braces.

When I first started programming, I learned with basic/qbasic eons ago. I eventually learned pascal and using a pirated version of visual studio learned some VB5/6. The curly braces freaked me out at first too, but I learned c/c++, now I do a lot of c/c++, c#, perl, and sometimes java development, and now I can't stand reading VB code.

Bit the bullet, it will do you good.
 
cuemasterfl said:
As I said before, seeing {} everywhere puts me off, and I think the syntax is VB is much easier to understand than in C#.

I do believe that at the end of the day, the most important thing is being able to achieve the objective - regardless of the method. This makes me believe there's nothing wrong with sticking with VB.

Edit: That doesn't mean I'm not going to learn C# too :)
Click to expand...

But the thing is that C sytle syntax is in so many IMPORTANT lanugages like C, C++, Java, Javascript, C# that is a syntax that any professional programmer HAS to know.

As for VB, I made a good living in VB and there's nothing wrong with it per se but its a syntacailly a silo so there's less to leverage when you learn it versus C#. One thing I've noticed is that Microsoft is ignoring VB for Windows 7 Phone development for now at least, there are no VB templates for a Silverlight Phone project in the Windows 7 Phone development tools.

So while there's nothing wrong with VB the fact that Microsoft has decided to igonore it for phones is a BIG hint. VB.NET is just not something that you'll be leverage as well as C#.
 
heatlesssun said:
But the thing is that C sytle syntax is in so many IMPORTANT lanugages like C, C++, Java, Javascript, C# that is a syntax that any professional programmer HAS to know.

As for VB, I made a good living in VB and there's nothing wrong with it per se but its a syntacailly a silo so there's less to leverage when you learn it versus C#. One thing I've noticed is that Microsoft is ignoring VB for Windows 7 Phone development for now at least, there are no VB templates for a Silverlight Phone project in the Windows 7 Phone development tools.

So while there's nothing wrong with VB the fact that Microsoft has decided to igonore it for phones is a BIG hint. VB.NET is just not something that you'll be leverage as well as C#.
Click to expand...
Syntax is just that, and is not indicative alone of a language's robustness. This is especially true with .Net given that it all goes through the same CLR (among other reasons).

C# and VB have very minor differences in what can be done in one versus another. Objects and concepts, however, still remain identical. More importantly, there is not a technical deal-breaking bullet point to sway a developer toward one .Net language versus another.

I will agree that there is an observed push (possibly driven by a marketing angle) toward writing more .Net samples and documentation in C# versus VB.
 
PTNL said:
Syntax is just that, and is not indicative alone of a language's robustness. This is especially true with .Net given that it all goes through the same CLR (among other reasons).

C# and VB have very minor differences in what can be done in one versus another. Objects and concepts, however, still remain identical. More importantly, there is not a technical deal-breaking bullet point to sway a developer toward one .Net language versus another.

I will agree that there is an observed push (possibly driven by a marketing angle) toward writing more .Net samples and documentation in C# versus VB.
Click to expand...

Have to disagree a bit on this simply because as I said C style syntax is so pervasive, it simply CAN'T be avoided in the world of most professional developers and I'd say that C and C++ are about as robust as it gets, almost ALL technically sophisticated software is developed with those languages or syntactically similar variants. Learn it now or learn it later.

And the fact that VB developers are shut out of Windows 7 CE, that's a HUGE bullet point if you plan on using your programming skills on all of Microsoft's platforms, which as a developer you always need to be ready to go. VB just can't be leveraged like C# and that's VB's biggest problem.
 
cuemasterfl said:
I've been programming in VB.NET for a while, and deem myself to be pretty decent at it. I'd like to get into C#, but I was looking at some books this lunchtime in the local bookstore, and it seems that 95% of pretty much every book (100% in some cases) only deal with the console. I want to write Windows Forms (maybe some WPF) programs mostly, not be stuck writing console programs. Am I missing something here? I looked at the VB.Net books too, and of course they're all Windows Forms based.

Would it be so bad if I just stuck with VB? I'm not planning on writing Starcraft III. I want to concentrate on Windows applications and maybe some 2D games. Thank in advance for your opinions.
Click to expand...

get this http://headfirstlabs.com/books/hfcsharp/.

o and VB.NET? come on thats stuff they teach you in college nevermind university. i was taught VB when i was in college(16-18 in UK) .

c# is FARRRRR superior than VB.NET.
 
Last edited:
cuemasterfl said:
As I said before, seeing {} everywhere puts me off,
Click to expand...
You'll need to get over that -- and annoyances that are much more invasive -- if you want to become a software professional.

cuemasterfl said:
I do believe that at the end of the day, the most important thing is being able to achieve the objective - regardless of the method.
Click to expand...
In some few instances, that's true. But in the vast majority of situations, the method has a non-trivial bearing on the technique and the implementation used to attain the desired outcome.

jonneymendoza said:
c# is FARRRRR superior than VB.NET.
Click to expand...
Are you able to articulate why? Because, without any reasoning or elucidation, your post is particularly worthless.

rflcptr said:
Mike, thanks for the very helpful post! :)
Click to expand...
Happy to help -- though I think I didn't actually answer the question about what "know" means. I think that question leads to a very important point.

Someone might say they know something. When I do phone screens, I ask candidates what they know. I ask them to rank themselves on a scale of one to ten in a particular technology -- C++, for instance.

But before they answer, I tell them what my scale means. A ranking of one, on my scale, means that you're wandering around the bookstore trying to find a book on C++. You've heard of it, but you don't know anything about it -- you don't even know which books might be good, which in this case, means you don't even know who the inventor of the language is. On the other end of the scale is ten. People who rank themselves as a 10 in C++ should be people who have participated in standards committee meetings, have written a compiler, or written super-advanced language tools. Maybe they've written seminal papers on techniques for the language, or books about it; or large commercial products that use the language.

That's a wide range, and it might sound silly because there really aren't many people who can be a 10. That's what we want, though: we want to hire the very few people who are truly experts.

There are varying degrees of "know", then. The varying degrees are very wide, as far as employability is concerned: a 1 is probably unemployable -- for that particular skill, anyhow. A 10 is likely very employable, but still might not be a great fit for the particular job which they're applying to.

A student really needs to get past a ranking of 3 or 4 to be employable. You can write code at the whiteboard, as I mentioned before. You understand the language and its tools -- you know about the pre-processor and the compiler, and the linker, and the librarian, and certainly are familiar with the debugger.

Funny thing is, though, once you know the tools, you know them for all the languages. While VB.Net and C# have different syntax, they use the same debugger -- with the expression evaluator's syntax being different, naturally.

A certain inflection happens between competency score 4 and anything higher. It's that the candidate knows what to do when things go wrong, or when the language is abused. Their experience and depth of knowledge tells them where the language and the tools break, what can and can't be done. What's right to do in the language, and what's better off done someplace else.

Past level 7 or 8, a candidate has the ability to avoid those pitfalls on very large systems. They have tons of experience and very deep knowledge about troubleshooting even esoteric problems. They know different products of the same genre, and understand how they're different -- and why they're different. They understand the subtleties of compromise within the framework that the language and tools give them,

Think about a civil engineer who builds bridges. Fresh out of school, a CE could probably find a ditch, measure it, and then write the equations to build a bridge that would let a train of a certain weight pass at a certain speed.

That's great; maybe a three or a four. In real life, nobody's building bridges like that. Instead, there are outside influences. The sonogram says the bedrock under the river isn't stable; what adjustments must be made to the design of the bridge? The rail company says they might buy a train that goes twice as fast and produces four times as much vibration. How can the bridge be re-enforced for that, while keeping the cost under a certain budget? A CE who can answer questions like that is a five or a six.

I have a friend who works as a consultant to airlines and the FAA. His job is to visit crashed airframes and see what should be done with them. Maybe the repairs are simple; replace a few parts and fly it again. Maybe the repairs are complicated; the whole plane needs to be at least partially reassembled. Or, perhaps the vessel can never again be flown, and its parts have can be used as spares. Perhaps the damage is so bad and the integrity of the material so questionable that everything is just scrap metal.

This decision can cost billions of dollars. What if he re-certifies a plane that has some stress cracks, and then flies, and drops the airframe, its cargo, and all the passengers? What if he refuses certification to an airframe that would really be safe to fly, but by his order is replaced -- for $140 million?

This guy is an 9 or a 10. He's doing things that affect your life, every day, and you don't even know it. Similar, a CE who knows what to do with a weathered old bridge with questionable maintenance that's been hit by a barge is also at the top of his game. These guys know their field so well that they are able to evaluate situations that are far out of the norm, that no textbook or academic papers cover. They're furthering technology and knowledge in the field.

It's possible to know a computer language or a technology as well as my airframe inspector friend, or the hypothetical civil engineer, and you should strive to do it if you want a great place in this industry.
 
heatlesssun said:
Have to disagree a bit on this simply because as I said C style syntax is so pervasive, it simply CAN'T be avoided in the world of most professional developers and I'd say that C and C++ are about as robust as it gets, almost ALL technically sophisticated software is developed with those languages or syntactically similar variants. Learn it now or learn it later.
Click to expand...
You missed the point of my post -- syntax alone is not indicative of language robustness (aka performance). There's other reasons for the performance differences, all of which go outside of the scope of this thread. You also added some counter-conjecture about C-style syntax being unavoidable. So when did I state that it could, or especially should, be avoided?

There's just too much to your argument that has nothing to do with the objective points established.


heatlesssun said:
And the fact that VB developers are shut out of Windows 7 CE, that's a HUGE bullet point if you plan on using your programming skills on all of Microsoft's platforms, which as a developer you always need to be ready to go. VB just can't be leveraged like C# and that's VB's biggest problem.
Click to expand...
The fact that MS chooses to shut out one language that runs through the same CLR as other .Net languages indicates MS's preference. And who's to say that Windows CE programming is even of interest to the OP? (You could even assert that the OP has not really dove deep into doing Windows CE development based on the progress of the thread.)


So after all the (arguably unnecessary) diversionary side-threads, what's been established thus far? Heatlesssun loves C#, everyone recommends learning more than one language, some languages share common aspects in syntax structure, and syntax (aka style) alone does not indicate horsepower.



Edit: Like the post, mikeblas!
 
Last edited:
PTNL said:
So after all this (arguably unnecessary) diversionary side-threads, what's been established thus far? Heatlesssun loves C#, everyone recommends learning more than one language, some languages share common aspects in syntax structure, and syntax (aka style) alone does not indicate horsepower.

/thread
Click to expand...

You have valid points and I don't disagree with you entirely but you're missing mine. I'm simply looking at the issue practiaclly with years of experience as my guide. Since C# has syntax in common with other major languages it helps in learning other languages. Also, if you are a .NET developer that means that it's a good idea learn things that you can leverage across the Microsoft portfolio. The OP might not have an interest in Windows CE, a potential employer might however.

So again, it's not a matter of loving C# as much as reality. C# is simply a more marketable skill and those skills are more easily leveraged across other languages and platforms. I've been developing code on Microsoft platforms for 20 years I've never had a problem finding good paying jobs. I'm not saying these things out love for C#, but for the love of staying employed.;)
 
mikeblas said:
Are you able to articulate why? Because, without any reasoning or elucidation, your post is particularly worthless.


.
Click to expand...

  1. Increments/Decrements. a++;a--;
  2. # Error Catching. C# catches a lot more errors than VB.NET, such as uninitialized variables, dead code, etc...
  3. Money: Its a fact that c# developer earn more money.
  4. IMHO, C# is more easier to read and understand than VB.NET
  5. VB.Net does not support pointers.

    O and to sum it all off learning C# first is ALWAYS the better option because it makes learning a large number of other languages MUCH easier.
 
jonneymendoza said:
O and to sum it all off learning C# first is ALWAYS the better option because it makes learning a large number of other languages MUCH easier.
Click to expand...

+1. It's no accident that C# is modeled syntactically after C, it was a design decision made by Microsoft because it of ALL of the other languages that are C syntax based.
 
i would go as far as saying i couldnt tell the difference between a piece of java code to a piece of c# code as they are ridiculously similar
 
jonneymendoza said:
i would go as far as saying i couldnt tell the difference between a piece of java code to a piece of c# code as they are ridiculously similar
Click to expand...

That might be taking a bit too far. The syntax is the same, the classes are TOTALLY different.
 
jonneymendoza said:
  1. Increments/Decrements. a++;a--;
  2. # Error Catching. C# catches a lot more errors than VB.NET, such as uninitialized variables, dead code, etc...
  3. Money: Its a fact that c# developer earn more money.
  4. IMHO, C# is more easier to read and understand than VB.NET
  5. VB.Net does not support pointers.
Click to expand...
Lets see..
1. a+=1, a-=1
2. That has nothing to do with the language. And anyway, you still haven't proved that, because as far as I can tell, Visual Studio (for example) does those things equally regardless of which of the two languages you're using.
3. 86% of all statistics are made up.
4. Which is entirely your opinion.
5. Sure it does, just to a limited degree.

Glad to see you copy and paste half the list from http://www.vbrad.com/article.aspx?id=63 though.
 
Last edited:
heatlesssun said:
That might be taking a bit too far. The syntax is the same, the classes are TOTALLY different.
Click to expand...

AFAIK, Java also has different conventions, but the main reason I'd argue for C# over VB .NET is marketability and similarity to other C-style languages. It's not a huge difference, so really, whatever feels most natural to you is best, but my estimation would say that C# is more popular.

Snowknight26 said:
...
Click to expand...

#6 is quite funny. :p
Also, I do like the regions for good code organization, though I don't know how much of that is in VB .NET.
 
Snowknight26 said:
3. 86% of all statistics are made up.
Click to expand...

I don't know about the money but I've been doing .Net professionally since day one and C# is much more demand from all that I've seen, that's why I learned it. I came from VB started with it from the begining as well, made a lot of money in VB, BASIC was my first language and I was coding in it probably before most of you were born. I would have liked to have seen more people pick up VB but it just hasn't happened simply because it's syntactically like C,C++, Java, Javascript, etc. Sorry guys, you're arguging against the reality of the .Net world. It's written in C# for now.
 
Cyrilix said:
AFAIK, Java also has different conventions, but the main reason I'd argue for C# over VB .NET is marketability and similarity to other C-style languages. It's not a huge difference, so really, whatever feels most natural to you is best, but my estimation would say that C# is more popular.
Click to expand...

That's true about the conventions but those aren't imposed by the language and I've seen Java people use them in C# so it's easy to pick up on them being Java conventions but they are just that, conventions.

And from what I've seen C# is MUCH more marketable than VB. Every large shop I know in my time has kicked VB to the curb, theu either don't allow VB or discourage it. I'm only a fanboy of my wallet in this case. If VB was the way to go with .Net that's what I would have done since I was already a VB COM expert. That's NOT what happened in the real world.
 
Ok, from what I've read, I do believe it's important for me to learn C# for 2 reasons. 1) A lot of employers require it. It may be that "someone" told them it's far superior, and for that reason they demand it, probably without knowing that VB could be used for what they want. But, at the end of the day, if that's what they want, that's what matters as they're the ones signing checks. 2) Learning the C# syntax will benefit me because it's much like other languages such as C++, Javascript, Java, etc.

I appreciate all of the answers and opinions from everyone. My decision is made. I will learn C#!
 
You must log in or register to reply here.
Back
Top