C # and C ++ learning curve

[Peter@POLKO]

Hi Complete ass here trying to get his feet wet in .NET programming. I want
to start easy, understanding what is talked about. Which of these two would
be a better choice, if same, which one is consider easier to learn first?
Thanks for any advice

 

[Bruce Wood]

I agree with Mike. C++ is an excellent language that gives you
tremendous control over what is going on inside the machine. Perhaps
too much control for beginners: too many picky details to keep track
of. You'll learn much more about foundational stuff programming in C++,
but you may find it very difficult and not a bit frustrating.

C# takes care of a lot of the details for you (particularly memory
management and pointers, which are particularly tricky). I would start
there, if I were you, but do learn C++ at some point: it will open your
eyes to what is "really going on" inside the machine.

 

[Philip Daniels]

C# is a much easier language to learn. So from that stand point it's the best
one to learn. It is also a purely .Net language while C++ can have native
code that does not use the CLR and is not managed. From an acedemic stand
point you will learn more about low level programming by learning C++. It
supports things like points and memory allocation that occur behind the
scenes in C#. So if you want to get a good understanding of what is going on
beind the scenes then study C++. If you just want to get up and running in
.Net C# is a much better choice.

Mike

Echo what Mike said, plus I would add the fact that the C# compiler is
v. v. fast, which helps a lot in turnaround when you are trying to
learn/debug something.

 

[DeveloperX]

I'll side with everyone else (well it is a c# group). C++ is great, but
I can't see the point of learning it over c# for dotnet development.
Outside of dotnet, it's still popular with game developers, certain
financial institutions, Linux developers, etc. Again though I'm seeing
a move away from C++ and Java in finance to c#. Games developers still
predominantly use C++ but do use C# for building tools and I can
imagine a transition to C# for the AI and scripting portions of games
in the not too distant future if not the graphics just yet. Linux
stuff, you really need C/C++ skills although mono is coming along
nicely.

If you want to give it a try Microsoft have the freely available Visual
studio express which comes in editions supporting C#, C++, j# and
VB.net (I'd say avoid VB.net and j# at any cost). There's a web version
as well and SQL Server Express.

They also have the XNA version which allows you to develop games for
windows or the 360 (the latter costs money, the former is free).

Finally there's an open source IDE called SharpDevelop (? I think)
which is impressive, I don't use it though so can't comment in detail.
The express versions of VS are slightly cut down from the base
commercial VS but I don't think that will hurt you at this point.

If you prefer Linux over windows take a look at Mono, dotnet for Linux,
probably before the MS implementation as it misses some features at the
moment.

 

[POLKO]

Thank You all for help. I,ll start as you advised with C#, digging later
into C ++. One more question, Developer said to avoid VB, I was planning to
do it next, why should I avoid it?
Thanks again

 

[Bruce Wood]

Thank You all for help. I,ll start as you advised with C#, digging later
into C ++. One more question, Developer said to avoid VB, I was planning to
do it next, why should I avoid it?

Well, first be aware that there's an anti-VB sentiment in the C# crowd
(I admit that I share it). Mostly it's for historical reasons, but
those reasons are still valid. C# was born out of the C, C++, Delphi
line of languages, which encourage rigour and precise specification of
exactly what it is you want to do. VB.NET was born out of VB and VBA,
which are much looser languages, the latter being an interpreted
scripting language. VB, historically, has not bothered with things like
precise definitions of types (or even precise typing at all) or
explicit type conversions. Historically, VB has encouraged programmers
to just write some code and the compiler (or interpreter) will do its
best to figure out what you meant. C, on the other hand, never cut you
any slack: you had to say _precisely_ what you wanted or the compiler
would kick your butt.

The general philosophies that underly the two camps are that C# (and C
/ C++ / Delphi) people tend to plan more carefully and be more
detail-oriented. They're into stuff like test-driven development. In
fact, it's mostly this camp that talks about programming as an
engineering discipline, and is concerned with development processes and
how to ensure correct code.

The VB camp is more concerned with rapid prototyping: throw something
together quickly and see if it works. The prejudice that we C-type
people hold regarding VB programming is that it encourages sloppy
development. The perjorative term that you'll see here from time to
time is "script kiddies": toss something together, try it out a few
times, then throw it to the users to see if it flies.

With the advent of VB.NET, there is little or nothing left in the
language, per se, that precludes careful, engineering-style
development. It's more the history behind the language and, as a
result, the types of programmers who are attracted to it (out of
familiarity) that continue its fast-and-loose reputation.

 

[RobinS]

At this point, there's not a lot of difference between C# and VB;
it's just a prejudice that C# programmers have. What Bruce said about
earlier versions of VB is true, although a good programmer would make
sure his or her code was done the right way in any language.

Being completely anal-retentive, my old VB6 code had everything
typed specifically and was not sloppy in any way, shape or form.
Sure, there are sloppy programmers, but they exist in any language,
although some languages (like the prior versions of VB) allowed more
people to be sloppier than necessary.

I think VB.Net is easier to read and program in, but I also think
there are more jobs in C#.

Robin S.
---------------------------------------

 

[DeveloperX]

I should of qualified my dislike of vb.net, so I'll do so now.

I'm a huge fan of vb6. Some truly heroic software has been developed
with it, but it did not transition well to the dotnet platform.
the c# syntax is cleaner than the vb.net syntax and it doesn't need to
make consessions to backwards compatability that vb.net has. For
developers moving from vb6 to dotnet I'd say go for c# because it will
help annex your vb6 knowledge and embrace a better way of progamming.
You get the RAD benefits of VB6 with the power of C++. You do need to
stop thinking in VB6 though and going vb.net does not help that.
Another good reason to avoid vb.net is a bit more scary. I'm aware of a
number of companies who have converted vb6 code into vb.net code using
the MS sponsored tools (Sorry I forget the names). All I can say is try
and avoid working on any project developed this way. The code generated
is painful.

 

[Cor Ligthert [MVP]]

into C ++. One more question, Developer said to avoid VB, I was planning
to
do it next, why should I avoid it?

Because developerX does not know anything about it.
By instance he wrote that VB.Net did take things from the past. So did C#.

Where VB.Net got a library to enhance the performance did C# inherit unsave
code.

Both are absolute not important for 99% of the developers.

We can see you are biased on C languages, so take C#.

Just my idea,

Before you understand me wrong, I use both languages and while busy I almost
don't aware the difference.

Cor

 

[Bruce Wood]

Because developerX does not know anything about it.
By instance he wrote that VB.Net did take things from the past. So did C#.

If you are looking strictly at the language syntax and semantics, it
makes little difference which one you choose.

In my opinion the big difference between working in the languages is
the programmer culture, and, as DeveloperX pointed out, the kind of
code you run across.

True, there is some awful C# code out there. There's awful code in
every language.

VB.NET, however, has the unfortunate distinction of fostering bad code
for historical reasons. As DeveloperX pointed out, there's some
auto-converted code from VB6. Auto-converted code almost always sucks,
particularly from a non-OO language to an OO language. Just run
screaming from that mess. As well, there's the mental disconnect
problem: lots of programmers who wrote procedural code in VB6 have
moved to VB.NET and continue to write in the same style, thus making a
mess. The worst code I've ever read in my life came from programmers
who moved from one language they knew well to another language they
didn't know and, rather than learning the new idioms, just used their
old programming style in the new language. (Ever seen C written as
COBOL? I have, complete with comments saying "/* WORKING STORAGE
SECTION */" and "/* PROCEDURE DIVISION */". Gross.) Unfortunately,
VB.NET encourages this.

True, the C to C# transition would be the same, but most C programmers
moved to C++ first, made an ugly mess there, and so by the time they
made it to C# they'd made most of their blunders already.

Again, there's nothing about the two languages per se that would make
VB.NET "worse" than C#. With LINQ it even sports some cool new features
that can make it even more readable than C#. The problem is more the
culture thing, which I believe will work itself out over time.
Disciplined programmers will write good code in either language. Hacks
will write bad code in either language. The difference is that, at
present, IMHO, there are more hacks writing in VB.NET than in C#.

 

[Deckarep]

One thing I like about C# is the fact that if and when you need to jump
into other languages they are many that look/feel like c#.

For example Java, ActionScript( Flash ), JavaScript, PHP and others.

They all borrow from the family of C languages but more languages like
C# are offering memory managed environments therefore making C# (in my
opinion) the better choice.

I have the utmost respect for any true C++ programmer and I can only
wish that I understood the hardware and memory aspect of things like
they do but the fact is, it's becoming more specialized.

Companies are looking for rapid development over speed and control. I
mean, imagine programming a Web Application in c++. Of course it can
be done but the C# team will pump it out faster. True, they may not
understand data structures, hardware, and memory management as much as
a c++ programmer would but in many settings rapid development is
favored over those things then if need be performance is squeezed out
by moving to the lower level (read: c++).

I'm sure I might get people who would argue this fact but all you need
to do is look at the market. Like I said I give it up to c++ coders
but I'll stick with my managed world until the need arises and the
ground opens up and eats me alive. Which I know will happen someday.

Haha,

-Ralph

Sidenote: The only reason I say that some people may not understand
data structures, hardware and memory management is for some obvious
reasons and some not so obvious. I love the fact that the .net
framework has all these built in classes ready to go. But the downside
is unless I truley delve into these classes and figure out in detail
how they work I may not understand them as effectively as someone who
has to build these structures from scratch. True story: a programmer
interviewed for this company. He was asked when he would use some data
structures over others. His argument was that it was all user
preference. Meaning they all did the same thing...but you just had to
choose what you preferred. Nevermind having to worry about sorting,
lookup speed, hash collisions, etc. Forget about O notation...he just
figured it was all preference and that all data structures performed
the same. Unfortunately this is common in the managed, framework world
of developers. I'm guilty of it sometimes too. People can have a
tendancy to not really understand why different classes exist in the
first place.

 

[MrAsm]

One thing I like about C# is the fact that if and when you need to jump
into other languages they are many that look/feel like c#.

For example Java, ActionScript( Flash ), JavaScript, PHP and others.

To be honest, Java, JavaScript, PHP, etc. were all invented *before*
C#.
(However, C# has several improvements over Java.)

They all borrow from the family of C languages but more languages like
C# are offering memory managed environments therefore making C# (in my
opinion) the better choice.

Java offered garbage-collector memory management *before* C#.
If I recall correctly, also Visual Basic 6 offered automatic memory
management (but I'm not sure about this).

Companies are looking for rapid development over speed and control. I
mean, imagine programming a Web Application in c++. Of course it can
be done but the C# team will pump it out faster.

I like C and C++, but you're absolutely right here.

Languages are tools, and one must choose the best tools for the given
job.

For web apps, I think the way to go is C#.
(And for some web development, also PHP would be OK, and PHP is much
simpler than C#.)

True, they may not
understand data structures,

C++ has STL, so also a C++ programmer "may not understand data
structures".

But I think that basic understanding of data structures (lookup speed,
sorting, etc.) should be a common denominator of all programmers
(whether they use C# or C++ or other languages)

hardware, and memory management as much as
a c++ programmer would but in many settings rapid development is
favored over those things then if need be performance is squeezed out
by moving to the lower level (read: c++).

Moreover, the WWW and Internet have some latency, so some clock cycles
that a C++ .exe may save on a local machine are absolutely irrelevant
in this context.

And there is the problem of security: it is possible to cause buffer
overflows with C++ arrays (not if one use std::vector with at()
method, however). While C# (and Java) arrays are bounds-checked. This
is very important to build secure software.


MrAsm

 

[RobinS]

Anybody using the MS tools to convert a VB6 app to VB.Net has
serious stupidity issues, and if they had a converter to
convert to C#, they would use that, too.

The entertaining thing about this whole discussion is that if
someone posted the same question in the VB newsgroup, they
would have just as many reasons to use VB over C# as the
C# newsgroup does for using C# over VB.

So maybe we could all just agree that if you're a good programmer,
either language will work, and both languages have features that
work better in some cases than the other one.

Robin S.
-----------------------------------------