9

Is there a possibility that someone who has learned all the key aspects of C++ and knows the fundamentals of the language very well, will learn other languages (such as, Python, Perl, Java) faster and easier?

l..
  • 207
  • 2
  • 2
  • I too would like to know this. People have been praising C++ (as a programming skill) more than any other language I've heard of. – Alternatex Jan 08 '15 at 15:53
  • 9
    I'd argue that C++ is different enough from most other languages to make it _more_ confusing to pick up something else (if it's the only language you know). Many languages share the syntax of C++, but few have evolved in quite the same direction. C++ has a lot of historical cruft that is specific only to C++. Your best bet for quickly picking up new languages is to just focus on learning different languages from different paradigms. The more paradigms you become familiar with, the faster you will be to pick up other things from those paradigms. – KChaloux Jan 08 '15 at 15:54
  • 3
    I do not think that knowing C++ gives you an advantage for learning other languages in general. It really depends what other languages you are going to learn. My programming languages professor used to say that we should concentrate on understanding general concepts: this will definitely make learning individual languages much easier. – Giorgio Jan 08 '15 at 16:00
  • 9
    Learning one language in depth is a good start towards learning programming in general, except that you might confuse language-specific know-how with general knowledge. Modern C++ is a great language, but once you've advanced to an intermediate level you'll profit massively from getting to known other perspectives – maybe take a look at OCaml and Ruby even if you'll never use those seriously. Once you're a steady programmer and can differentiate between language-specific and general things, getting productive in new languages comes fairly easy, though mastery always takes time. – amon Jan 08 '15 at 16:11
  • 1
    Compared to what? Learning another language well, knowing C++ well but not deeply, knowing nothing at all? – Telastyn Jan 08 '15 at 16:19
  • depends on how like C++ the other languages are. The more they deviate the less helpful it will be. – GordonM Jan 08 '15 at 16:54
  • 2
    Yes, but also the other way round. Knowing Ocaml or Scheme makes a lot of C++11 new features easier to understand – Basile Starynkevitch Jan 08 '15 at 17:29
  • 1
    @BasileStarynkevitch: Knowing *any* modern language makes a lot of C++11 new features easier to understand. (Except maybe Java. Does it have closures yet?) :P – Mason Wheeler Jan 08 '15 at 18:41
  • 1
    Note that "all" of C++ is a *lot*, more than most other languages. – pjc50 Jan 08 '15 at 19:00
  • NO, assembler does! – Emilio Garavaglia Jan 08 '15 at 20:13
  • 1
    Since it probably takes a decade to learn all the key aspects of C++, then yes, because a programmer with ten years experience is usually better at picking up new languages. – Gort the Robot Jan 09 '15 at 00:17

7 Answers7

12

In General Terms

Profound knowledge of any programming language is likely to help you with picking up other languages quicker. That is so partially because programming is a way of thinking more than it is learning syntax. Most programming practices would be true of most other programming languages. That is why people say that you always learn the second programming language quicker than the first.

In Specific Terms

C++ is a language which allows for a much greater 'control' than other languages. This can be both good and bad. For example a real gun is better than a air gun when you go in the forest (because you can actually shoot something down with it), but it is also more dangerous for you and those around you. C++ has concepts such as memory management, which you don't need to worry about in most other languages. Having a firm grasp of these concepts however is far from pointless even when working with auto memory management languages. You can also perform bitwise operations and go much lower down to the 'metal' with a language like C++. Even a basic understanding in those areas can help you a lot as a programmer in any language.

Personal Opinion

I personally learned Java first for nearly 3 years before learning C++, and I should say that I sort of regret it (uni course...). This made learning C++ (i'm still learning - far from 'profound' knowledge :D) not as straightforward as i'd like it. If I had done it the other way around I would say that it would have been much easier for me. Especially when you know WHY something is done in a specific way, and not just rest assured on the auto-magicness of the language. If I am allowed to give an opinion I would suggest: C (for basic and universal programming paradigms) -> C++ (for basic understanding of OOP along with memory management) -> Then you can go into any 'real' OOP language with a good foundation or you can continue with more advanced topics in C++, all depending on what you're planning on doing.

G.Rassovsky
  • 400
  • 1
  • 6
  • I wouldn't characterize C/C++ as giving *freedom*, they give *control* over the machine. Control isn't always freedom - languages with garbage collection *free* you from having to worry about allocating and deallocating memory correctly when the problem you're solving has nothing to do with allocating and deallocating memory. I would also argue that learning to think abstractly is both easier and more useful to a beginner than learning the minutiae of the machine's inner workings, and in that sense tackling programming from the "bottom" up is counterproductive. – Doval Jan 08 '15 at 16:45
  • There's plenty of time to learn about how language constructs map to machine code after the basics of writing clear, concise, modular code have been nailed down. – Doval Jan 08 '15 at 16:47
  • 3
    I'm glad that my university had us start with pascal. Then we progressed to C (for the memory management and bit operations part) and finally advanced to java for oop (although this could of course had been any other oo-language). To be honest, I find it quite disturbing how many universities _start_ with java. You will inevitably learn java (and more importantly, OOP) wrong, since real OOP is too complicated for beginners that are still struggling with the difference between `OR` and `AND` – Lovis Jan 08 '15 at 16:48
  • @Giorgio Yes, but that is just part of it. Due to the nature of C++ - it is backwards compatible with C, and adds on top of that concepts such as OOP and Meta, with the ability to manage your own memory = you can do almost anything that you want (and that you don't want too :D). – G.Rassovsky Jan 08 '15 at 16:49
  • @Doval I agree "control" is a better choice of wording it. Will edit. – G.Rassovsky Jan 08 '15 at 16:50
  • +1 for the fact that syntax is easy, logic/technique is hard. I can pick up just about any programming language and use it after a minute, do something useful with it after an hour, and be moderately productive with it after a week. Mastery of the quirks of the language takes much longer, but it is the knowledge of the concepts which is the important part. – Jon Story Jan 08 '15 at 17:04
  • 2
    @Doval: Garbage collection gives you *the illusion of* not having to worry about memory management. Just look at how frequently managed-code programs get memory leaks because some reference remained valid in an unexpected place (collections are a perennial offender) to see just how illusory this truly is. – Mason Wheeler Jan 08 '15 at 18:40
  • @MasonWheeler I never said it frees you from not worrying about memory usage in general. I said it frees you from worrying about allocating and deallocating. You won't allocate memory of the wrong size, in the wrong place, with the wrong alignment, free it before all references to it are unreachable, or stomp over another object's data. There is no illusion, just promises no one ever made. – Doval Jan 08 '15 at 18:49
  • 1
    @Doval: Wrong size, place, alignment: how exactly does one do any of these things in an object-oriented language when the proper size is known to the compiler and the allocator handles placement and alignment? Freeing early: this is exactly what GC is supposed to prevent, so saying it's not relevant to this discussion is just straight-up not true. But it does so [at the cost of turning every allocation into a memory leak.](http://programmers.stackexchange.com/questions/129530/#129555) And not stomping other objects' data is a *bounds checking* issue, not a garbage collection issue. – Mason Wheeler Jan 08 '15 at 18:55
  • @MasonWheeler "Early" as in "while there are still references to it". My CS theory isn't very strong but I imagine finding an equivalent program that uses the least amount of memory and frees it as soon as possible is undecidable; never mind the fact that you can trade CPU time for memory and vice-versa, so even if you could do that deciding whether you *should* is yet another problem... – Doval Jan 08 '15 at 19:02
  • 2
    C++ demands so much learning that's C++ implementation specific but will never be used outside of C++ because of the endless quirks of it, it's libraries, and various systems. In my experience everyone who writes C++ basically agrees all C++ is poorly written and full of quirks and oddities that are mostly C++ specific. Learning your way around that minefield won't make for anything useful in other languages when most languages lack most the problems C++ has. – Jimmy Hoffa Jan 08 '15 at 19:03
  • @MasonWheeler ...So I consider it misleading to characterize holding on to a reference for longer than necessary as a leak; that's an inefficient program. To me a leak is requesting memory and then having the process lose track of it, such that you couldn't return it to the OS even if you wanted to. I.e. losing all references yet having no way to detect the garbage. – Doval Jan 08 '15 at 19:03
  • 2
    @Doval: Yes, that's my whole point: *these things are algorithmically undecidable in the general case*, which is why they need to be handled by an intelligent person, not an algorithm, to be handled correctly. And saying "that's not a leak, it's an inefficient program" is just semantical hair-splitting; to an outside observer, the behavior of the program is the same as that of a program that is leaking memory, especially in the context of multitasking systems where memory squeezes under load can cause severe problems. – Mason Wheeler Jan 08 '15 at 19:22
  • @MasonWheeler The outside observer will also fail to distinguish the most memory-efficient program from a leaking program if the working set is bigger than system memory, since both will eventually exhaust all memory. You can claim *any* program leaks that way. Static variables are also a leak by that definition since it's not always needed; you could be stack or heap-allocating that data and freeing it as needed instead. If that costs you more time, is the program then leaking cycles? – Doval Jan 08 '15 at 19:43
  • @Doval, c++11 has built-in shared and unique pointers that free you from ever worrying about freeing your memory, so the GC point is moot nowadays unless you want to discuss reference counting vs GC... – Rado Jan 10 '15 at 05:37
9

Unfortunately, no. This is actually a big problem when teaching C++ in programming classes, especially beginner-level classes: you can learn programming principles, or you can learn the C++ language, but the C++ language has too many pitfalls and stupid little gotchas to learn both effectively within the scope of a one-semester class!

There are many things that were tried in C++ and eventually became idiomatic in the language through sheer inertia, that pretty much every other language since has looked at and rejected because it turned out to be a huge mistake. The major ones are C++'s Templates and C++'s object model (objects as value types is never a good thing, because it breaks Liskov substitution and thous OOP itself.)

So if you get a deep knowledge of C++ first, and then you want to learn other programming languages, there's going to be a whole lot of harmful and counterproductive crud you'll have to unlearn in order to be effective at other programming languages.

Mason Wheeler
  • 82,151
  • 24
  • 234
  • 309
  • 4
    There are reasons Java and C# have a strictly weaker template-system, but that's because they need full meta-data about everything. And I would be interested in an explanation how objects as values break things. Especially considering that there are references... – Deduplicator Jan 08 '15 at 17:18
  • 3
    @Deduplicator: Java and C# have a *completely different generics system*, because experience shows that templates cause all sorts of serious problems, many of which arise because the Templates system was not well-planned-out in the first place. (Turing-complete *by accident*, to give one obvious example!) And objects as values break Liskov substitution because if you have a class Derived whose parent is Base, and it overrides a virtual method on Base, and you pass it by default passing to a function that takes a Base and calls the virtual method, it will not invoke the Derived version. – Mason Wheeler Jan 08 '15 at 18:38
  • 2
    @MasonWheeler: Ah, you're referring to [slicing](http://stackoverflow.com/q/274626/10077). – Fred Larson Jan 08 '15 at 18:42
  • 2
    @FredLarson: I should have guessed such a prevalent, pernicious problem would have a specific name for it. (And, this being C++, a silly name at that. When a programmer outside the C++ world hears "slicing," he's likely to think of [array slicing](http://en.wikipedia.org/wiki/Array_slicing)! :P – Mason Wheeler Jan 08 '15 at 18:49
  • 2
    Well, if you use a copy where a reference should go, what do you expect? And yes, it's turing-complete by accident, and it should be far nicer, but neither Java nor C# generics are any kind of improvement. They are lacking too much. – Deduplicator Jan 08 '15 at 19:24
  • @Deduplicator: I expect copies to not exist because *references "should go" everywhere.* Liskov substitution demands it, and that's the *sine qua non* of OOP. You can have inheritance, or value types, but not both on the same type. – Mason Wheeler Jan 08 '15 at 19:33
  • 4
    Though I agree to many things you wrote, I think you have a very biased point of view ;-) IMHO learning C++ does not make people dumber. – Doc Brown Jan 08 '15 at 19:54
  • 1
    @DocBrown: I didn't say it makes people dumber; I said it would give people ideas that need to be unlearned. – Mason Wheeler Jan 09 '15 at 00:40
  • As I wrote, I agree to many things, especially to what you wrote about "unlearning". But IMHO that does not outweigh the fact that when you have learned all the key aspects of C++, you must have at least ~3 years of programming experience. And that will definitely make you faster in learning other languages (compared to a person with no programming experience). The few pieces one has to "unlearn" may drive the teachers to madness, of course, but I am convinced it will slow one down only a little bit. – Doc Brown Jan 09 '15 at 07:54
8

No. Knowing C++ well will make it easier to learn other languages which are like C++. But that would be boring. Why would you want to know two languages which are the same? That doesn't buy you anything. (Note that this isn't specific to C++. It applies to any language. Compare with natural languages: learning Italian will not make it easier to learn other languages. It will make it easier to learn Spanish, French or Portuguese, and learning three of those will make it easier to learn the fourth, but even learning all Romance languages will not help you one bit learning Finnish, Chinese, Hindi, Hebrew, Arabic, Pashtu, Greek, etc.)

Programming languages implement paradigms. Peter van Roy has collected a poster of the 34 principal programming paradigms.

Paradigms, in turn, are composed of concepts. That poster lists about 18 concepts.

All paradigms (or at least the ones in the poster) are composed from those concepts. All languages implement one or more paradigms composed of those concepts. So, if you learn those concepts, you will (in some sense) learn every programming language at once.

There are of course still lots of language-specific quirks (syntax among them). Also, that poster completely ignores typing, and there is of course a significant difference between a System F<:ω-style type system, a Scala-style type system, or a dynamic duck-typed type system, let alone a dependent type system à la Idris, Agda, Coq, Guru, or ATS.

Jörg W Mittag
  • 101,921
  • 24
  • 218
  • 318
  • _Hindi_, not _Hindu_. **Nothing** at all will help you in "learning Hindu", let alone Italian or C++ ;-) +1. – PKG Jan 08 '15 at 18:52
  • Actually, learning different languages, although really similar, still broaden your mind and thus help you slightly for further away languages. – dyesdyes Jan 09 '15 at 10:15
  • I'd have to disagree with the comparison to natural languages as C++ is a multi-paradigm language unlike natural languages. Also, learning a language feature in detail, you would know the design decisions for that feature and most likely understand the pros and cons of other implementations. For example, try learning c++ templates indepth without learning their benefits and drawbacks vs dynamic generics. Even if you don't stumble upon any mentions of C# (difficult nowadays), u'd still know what dynamic generics are and instantly know C# generics limitations when learning about them afterwards – Rado Jan 10 '15 at 06:05
5

I would say that knowing any programming language deeply will help with learning others, at least other languages in the same family. For example, C++ knowledge won't help much with LISP or Haskell, but for object oriented procedural languages, it will. My approach has been to try and learn a language from each of the different families (procedural, functional, object oriented, etc.) of languages well, then that knowledge can carry over into other languages in that family. On the other hand, a deep knowledge of APL won't help with anything else...

Jim Nutt
  • 497
  • 3
  • 5
  • 3
    I have seen what Self or Smalltalk or Ruby code written by someone who learned C++ as a first language looks like. I actually would say, knowing C++ is rather harmful to learning OO. I think Self or Newspeak would be much better suited for that. BTW, a deep knowledge of APL will at least help with languages like J and K. It will also help in thinking about higher-level collection abstractions and liftig, which will probably help with MapReduce or Hadoop-style programming, and also thinking about Functors, Applicatives, Monads, and Categories. – Jörg W Mittag Jan 08 '15 at 16:18
  • 1
    @JörgWMittag: It's well known one can write COBOL in any language... what's the point? – Deduplicator Jan 08 '15 at 17:19
  • @Deduplicator If your first language is COBOL, you're much more likely to write COBOL in other languages. – Doval Jan 08 '15 at 17:22
  • Actually, I have to agree with the COBOL thing. I had a guy working for me years ago that wrote COBOL in Pascal... – Jim Nutt Jan 08 '15 at 17:47
5

I'm going to take a different interpretation here.

C++ is a good language for learning about memory and data structures, since it forces you to think carefully about concepts like object ownership and lifespan. And learning about memory and data structures is one of the essential parts of any software engineering curriculum.

But you have to be learning about data structures. If you just "learn C++," you won't really gain very much, and it may slow down the process of learning other languages in the short run.

When I was in college, Data Structures was a required freshman-level course, taken after CS1 (which at least half the class had placed out of). It was hard. The format of the course was basically "Here's a data structure you've never seen before [e.g. a leftist heap]. Implement it in C++ in a week and make your output match our expected output exactly, byte-for-byte, so we can grade it automatically." Then, next week you'd get a new data structure and a new assignment. I probably learned more in that one course than I did in all of my other courses combined.

That's the kind of learning you need to be doing for C++ to be valuable.

Kevin
  • 2,668
  • 2
  • 15
  • 23
2

Every language you learn makes the next one easier to learn, especially within the same paradigm. They borrow from each other heavily, and after a while you get to the point where a new language looks like merely a collection of features from other languages, with a few unique twists.

I don't think C++ is better or worse than any other language in that regard. It is one of the more verbose languages I know, and makes some things hard that are easy in most other languages, but that doesn't necessarily translate into making the next language easier to learn. It does generally make the next language feel easier to use, though. There's a difference.

Karl Bielefeldt
  • 146,727
  • 38
  • 279
  • 479
0

No. A profound knowledge of C, or of the subset of C++ that is "basically C", will help when learning other languages, at least when picturing what their implementations have to be doing. A profound knowledge of C++, on the other hand, will mostly be information that is confusing or irrelevant when learning other languages; if you learn C++'s object orientation at more than a surface level, for example, when you move on to Perl/Python/Ruby you'll spend more time un-learning what you know than using it, since objects in those languages are implemented in a completely different way than in C++. The same thing is true to a greater or lesser extent for most other languages, and for other language features (for example, C++ templates and Haskell polymorphism are basically the same feature, with, again, completely different implementations). So deep knowledge of C++ is mostly going to be C++-specific.

Jonathan Cast
  • 217
  • 3
  • 10
  • this post is rather hard to read (wall of text). Would you mind [edit]ing it into a better shape? – gnat Jan 16 '15 at 06:53