which to learn: C# or C++?

[Kntx]

well I don't know much about vb, but what I do know is that every vb program I've used is extremely slow and usually badly written/buggy

Napster was written in VB.

And no I don't know what my point is.

 

[dpopiz]

I know what your point is. that surprises me that napster was written in vb, because it was much faster and better written than any hother vb prog I've seen

 

[Nothinman]

Does anyone still have Napster to verify that? It was a very long time ago, but I don't remember it needing the VB runtimes.

 

[Descartes]

It depends on what your immediate requirements are: to derive as much knowledge as possible, or to derive as much productivity as possible? If the former, then I would start with C++. C++ will provide you with a more solid foundation of knowledge for which to derive more abstract concepts; however, you will be less functional. Many people starting with programming are more worried about creating an aesthetically palatable GUI and not about learning about the core fundamentals of computer-science and programming. If you start with C++, it's almost impossible to ignore them; with C#, it is not. C# abstracts A LOT of what is otherwise a lot of tedium for the C++ programmer, but those who know what constitutes the tedium will derive more benefit from .NET.

I learned C a long time ago, and every day I'm reminded of the benefits of doing so. In talking with new .NET developers, the disparity between their knowledge and mine with respect to fundamentals is very clear, and I'm simply more empowered to solve problems than they for this lack of knowledge.

Originally quoted by: manlyCool, now we just need to wait for Descartes' obligatory "C# and the CLR are ISO standard technologies embraced by MS, Ximian, et al" post.

I'm a bit late to this thread, and it looks like others have regurgitated that for me . I just hope the cross-platform story for .NET becomes longer.

Originally posted by: Nothinman

As far as buying 3rd party controls, that is up to the programmer. Buy 'em or make 'em. Choice is yours.

Yes and making them is a PITA because of all the hoops you have to jump through to get access to the Win32 API.

I don't mind a good debate about the pros/cons of respective languages/platforms, but you have admitted (and show) that you don't know VB, so why criticize it? Simply declaring a function/sub in VB, analogous in function to a C function declaration, is not jumping through hoops. The data types and calling convention of one language might not be congruous with that of another, so you might need to create a declaration. The only way to avoid this redeclaration of a method when consumed in another language is to abstract the languages and type system a la Java and .NET.

Java doesn't exactly make it easy to consume native libraries through JNI, and you still need an extern declaration in .NET.

[edit]Although it doesn't sound like it from the above, I'd start with C# if I were starting over [/edit]

 

[Nothinman]

but you have admitted (and show) that you don't know VB, so why criticize it?

Because I used to know VB and I still feel scarred from the experience, I hope to save others from making the same mistakes I did =)

Simply declaring a function/sub in VB, analogous in function to a C function declaration, is not jumping through hoops. The data types and calling convention of one language might not be congruous with that of another, so you might need to create a declaration

Using a declaration isn't a big deal, no, but finding out what declaration you needed wasn't always easy and then you had to deal with data-types that weren't always easily exchangable. And IIRC debugging was made more difficult when using those APIs, but maybe my memory is clouded now that I have the source for everything I'm using now =)

Maybe I never was any good at it, who knows, but lord knows lack of knowledge never stopped anyone else from voicing their opinion so why should it stop me, but either way VB makes it real easy to get into bad programming habits, just like I wouldn't recommend perl as a learning language I wouldn't recommend VB.

If he's gonna buy VS anyway and has a choice between VB and C#, why should he choose VB?

 

[lameaway]

If you want to learn programming, I'd say C++. With C and C++ you have heaps of stuff availible to you... most all of open-source apps, tons of libraries and plenty of sample code to hack around with, not to mention the enormous number of people with knowledge in these languages. The way I see it, these are the things that really matter to the beginning programmer... it'll open you up to areas of coding that are a lot more fun than playing around in Microsoft's sandbox. You can always screw around with proprietary languages later.

 

[Armitage]

Originally posted by: Kntx

You don't care about other platforms now ... but why tie yourself to what will likely be effectively a single platform language? And subject to Microsoft's whims as far as compatibility of future versions. C++ runs almost anywhere and has alot more R&D behind it then C# ikely ever will.

Bear in mind, programs written in C++ will vary wildy depending on the platform they are targeted for.

You can write single-platform apps in any language, but only a few restrict you to that by definition.

 

[manly]

Originally posted by: Nothinman

If he's gonna buy VS anyway and has a choice between VB and C#, why should he choose VB?

What's wrong with a wolf in sharp's clothing?

The funny thing about .NET is that from what I saw when the multi-language hype machine was being cranked up by MS, almost all of the languages were essentially no different from C#, even if the syntax can vary a good deal. The best simple description I read was "skinnable languages", emphasizing that while the syntax varied, there wasn't much distinction between one .NET language from another (largely by design). While I'm still not a .NET convert, information I later read seemed to indicate managed C++ is the most divergent from the others in the family of MS .NET languages. I can't speak for 3rd party languages, some of which do break out of the general C# language paradigm.

So in this regard, choosing VB.NET arguably isn't really any worse than C# or J# or whatever.

On a similar note, if you're choosing between C# and managed C++, then IMO they are very similar (Descartes will probably correct me based on first-hand experience). Again, I'd argue C# is more syntactically clean (while managed C++ is a bit more flexible) but from an applications development standpoint, the difference beyond syntax is negligible since you're really writing code for the same .NET framework. Which begs the question, why not choose C# if you need to choose one of the .NET languages? (besides familiarity or other bias)

Now if you're comparing C# to an MFC-based C++ application, then that's why I originally suggested C# in the first place. You want as rich, convenient and productive a runtime as possible; there's plenty of time to be a C/C++ systems programming expert in the long run if you so choose. In this regard, I flatly feel the people recommending C++ from a nuts & bolts, power language standpoint simply have a flawed argument. That's like recommending the proverbial hammer for every task.

 

[Descartes]

Originally posted by: manly

Originally posted by: Nothinman

If he's gonna buy VS anyway and has a choice between VB and C#, why should he choose VB?

What's wrong with a wolf in sharp's clothing?

The funny thing about .NET is that from what I saw when the multi-language hype machine was being cranked up by MS, almost all of the languages were essentially no different from C#, even if the syntax can vary a good deal. The best simple description I read was "skinnable languages", emphasizing that while the syntax varied, there wasn't much distinction between one .NET language from another (largely by design). While I'm still not a .NET convert, information I later read seemed to indicate managed C++ is the most divergent from the others in the family of MS .NET languages. I can't speak for 3rd party languages, some of which do break out of the general C# language paradigm.

So in this regard, choosing VB.NET arguably isn't really any worse than C# or J# or whatever.

You're correct, although language wars still seem to find their way into .NET discussions. I've been a long proponent of VB when it makes sense, but I can't see any reason to make VB.NET your primary language unless you are coming from a strictly VB background. Conversations with my local .NET user group members seem to indicate that many VBers simply cannot grok C-derived syntax. Largely you'll find the converse is not true; C# developers can grok VB.NET syntax.

On a similar note, if you're choosing between C# and managed C++, then IMO they are very similar (Descartes will probably correct me based on first-hand experience). Again, I'd argue C# is more syntactically clean (while managed C++ is a bit more flexible) but from an applications development standpoint, the difference beyond syntax is negligible since you're really writing code for the same .NET framework. Which begs the question, why not choose C# if you need to choose one of the .NET languages? (besides familiarity or other bias)

Correct again. Probably the best way I can describe languages with respect to .NET is this:

Each language of .NET has its own perception of the facilities available to the CLR (Microsoft's commercial implementation, keep that in mind). VB.NET's perception of the CLR is that it does not support operator overloading; however, C#'s perception is that it does (and indeed, it does). Managed C++ has a much broader perception of the facilities than that of VB.NET or C#, and it is the only language that amalgamates unmanaged and managed code in the same translation unit (via pragmas). Managed C++ is also more performant (I don't care if that's not a word ): you have access to interior garbage collection pointers, you can control boxing operations, and the compiler is a full optimizer. Unfortunately, use of those facilities make the codebase rather abstruse compared to a functionally analogous C# one, so most people stick with C# unless they need absolute control.

The only language available in .NET that has a 100% accurate perception of the CLR (i.e. access to all available facilities) is IL. Luckily, IL is surprisingly easy to read.

Now if you're comparing C# to an MFC-based C++ application, then that's why I originally suggested C# in the first place. You want as rich, convenient and productive a runtime as possible; there's plenty of time to be a C/C++ systems programming expert in the long run if you so choose. In this regard, I flatly feel the people recommending C++ from a nuts & bolts, power language standpoint simply have a flawed argument. That's like recommending the proverbial hammer for every task.

True. I believe .NET facilitates an unprecedented level of productivity for good developers, especially when VS.NET is involved. I do think knowledge of the nuts and bolts are extremely valuable, however. Of course, this is merely my opinion, and many developers feel they don't need to know that which is abstracted from them. Here is a good article I've referenced before on such abstractions.

 

[fishbreath]

Having invested twelve years in C++ I would like to say that C++ (managed or unsafe) is by far the best language. True it's still the defacto standard for many applications, especially in the real-time arena, device drivers etc.. True it is fast, flexible and generic across many platforms, embedded systems and single-chip hardware systems.

However, C# is simply better. Here's why:

1) No support for multiple inheritance. Ever tried debugging a class with 32 inherited superclasses? I have.
2) An Interface mechanism which provides a MUCH higher degree of native polymorphism and also helps provides standard interfaces to components. This largely obviates a core need for multiple inheritance
3) A namespace convention which is easy to use, flexible and (ironically) similar to what I've seen under Unix development as well as XML
4) Class instance call backs implemented through a mechanism called delgates
5) Metadata associations which allow you to dynamically test an object to determine which class it belongs to - this largely but not entirely obviates the need for complex and confusing templates
6) Goodbye to header files! Hooray! No more time wasted maintaining complex class declarations
7) Objects are held in memory pool rather than stack space (necessary for the wonderful garbage collection service), so goodbye to a host of related problems
8) Auto-garbage collection! (although you are given a dispose method to ensure resources are deallocated in a deterministic manner)
9) Much closer mapping between C# and development nomenclature/tools like UML/Rational Rose (I have a dream that one day we won't be writing code any longer and C# is a small but righteous step in that direction)
10) Nice stuff like conditional attributes makes writing debug code simple and easier to maintain

Actually the list is much longer that this, but suffice to say I've done things with C# which would've been hugely more difficult with C++ (AI applications).

For sheer productivity, reduced instances of serious program errors leading to a crash, and for the pure fun of the language, C# gets my vote anyday.

And remember. I'm 46. If an old dog like me can warm to a new language, it might be worthy of consideration!

 

[Descartes]

Great pros of C# and .NET in general, fishbreath.