<p>I would say that you need to learn a completely different (old fashioned, perhaps archaic) programming paradigm, non-interactive coding.  In Ye Olden Ancient days, a programmer would often write out a complete program (or at least large parts) on paper, before even going near a computer (or punch card machine).</p>

<p>Try it as an exercise.  See how much code (how many lines) you can write (on paper, or into a plain text editor), and have it run correctly when first compiled and run.  You might learn to think more about certain aspects of the code, before typing, and perhaps end up a better programmer (even after going back to helpful interactive IDEs).  Compared to coders who only know how to compose within fast feedback loops.</p>

<p>This will also prevent learning the bad habits from randomized hack-and-slash trial-and-error coding (that, while possibly helpful in certain exploratory and learning situations) which can become a problematical practice within many high quality/reliability coding paradigms (those that don't include 100% provable unit test coverage).</p>

CC BY-SA 4.0
2019-01-10T21:54:09.950Z
Hmmm. Perhaps as a thought experiment, but not in the real world. I lived in the time of 24 hour turn-around and coding on a key-punch. No one should have to do anything like that. Fast turn around is a universally good thing for learning, but you need different techniques today, such as Test First. I've done it both ways. Don't even think about going back.  That said, I don't use a REPL, not because it is too fast, but because it keeps an insufficient record of my work.
Buffy
CC BY-SA 4.0
2019-01-10T22:30:28.717Z
Since you programmed in the time of key-punches, you've already learned those lessons, and don't need to go back.
hotpaw2
CC BY-SA 4.0
2019-01-10T22:31:30.367Z
But I don't program "like that" in the modern age. I actually _learned_ something in the modern world.
Buffy
CC BY-SA 4.0
2019-01-10T19:36:54.353Z
2019-01-10T19:36:54.353Z
hotpaw2
<p>You can find REPLs for C++ with an online search, but my advice would be different. I do the following with Java, but equivalent tools for C++ exist. </p>

<p>First, I use a sophisticated IDE (Eclipse) that, among other things, does error highlighting as I type. A typed language like C++ permits many errors to be caught early, normally in the compiler, but they can be pushed back into the development environment prior to formal compilation. That works for most syntax errors and for many structural errors, such as omitting a declaration. </p>

<p>Second, I use <em>Test Driven Development</em> to build serious code. I just JUnit, which is tailored for Java, of course, but there are equivalent "units" (TDD frameworks) for most languages. The rule here is "no code without a failing test". The idea is that before you write any code you write a test for it based on the specification you have or that you create on the fly. The test captures your intent directly. You write the test for a function before you begin to write the function. It fails of course, since it can't even compile. But the IDE can automatically insert the stub for the function into the code. You then provide the function body and run the test again. If it fails you need to think again. </p>

<p>But TDD is even better than that, since when you run the "test" you are actually running <em>all of the tests</em>; the test <em>suite</em>. So, if something used to work and now an earlier test breaks you get immediate feedback on it and, since the only thing you changed is that one method body, the source of error is usually pretty obvious. Moreover, tests are run independently of each other so that a failure of one test doesn't cascade into other failures that obscure the problem. </p>

<p>This is a workflow quite different from that of a REPL, so it takes some practice. But the IDE can do many things for you in addition to what is described here. The best of them have a plugin architecture in which you can easily add additional tools as needed. </p>

<p>Two additional notes. First, is that I use the same tools and techniques when programming Python and Ruby. </p>

<p>Second, having built many compilers, you should understand that the actual difference between a processor for a compiled language and an interpreted one is surprisingly small. The processing for the interpreted language has everything but the final stage code generator. But if it is to be efficient, it still creates an intermediate form of the program, possibly a tree or even an abstract assembler language version. Some of the optimization can be omitted, but only the late-stage optimizations, normally. So, an IDE for an interpreted language isn't so odd. </p>

CC BY-SA 4.0
2019-01-12T04:30:36.883Z
Your point about TDD is well taken. It is hard, however, for a newcomer to begin writing tests when one doesn't know very much about how the language works.
Allen Wang
CC BY-SA 4.0
2019-01-12T20:33:42.477Z
You have to teach test writing, of course, preferably with in-class demonstrations. Initially the tests can't be very sophisticated, but they shouldn't be in any case. Prefer lots of simple tests over a few complex ones. This makes them easier to write and more useful as they give fine-grained error reporting. Note that tests are run as suites, not individually. The tests in a suite are independent of one another. In Eclipse, if you have a test for a non-existent method, the IDE will write the stub for you, so it makes things simpler.
Buffy
CC BY-SA 4.0
2019-01-07T11:46:30.897Z
2019-01-07T12:32:24.227Z
2019-01-07T12:32:24.227Z
Buffy
<p>Your question deserves a long discussion, but I will try to narrow it down to few points.</p>

<p>First, remember that you are dealing not just with a "compiled language" such as Java or C# (that could be <em>much</em> easier targets for you), you are dealing with C++ that was designed with backward compatibility with C as a killer feature, and C was created in late 70s. It means that C++ indeed implements <em>numerous</em> design decisions that look archaic/obsolete/strange for a modern learner. Say, the whole system of header files is a hacky substitute for a proper package management. Thus it would be good for you to study carefully major language features and understand the true reason why they exist. In many cases you'll find newer and better alternatives to old tools (such as <code>std::vector</code> objects vs. arrays)</p>

<p>Second, use a good IDE. For instance, if you place a cursor under <code>printf()</code> (or any other library function) in MS Visual Studio and hit <code>F1</code>, it will jump to the extensive online manual, so this is not an issue. Also you will get autocomplete features similar to those available for Python (e.g., type a variable name, then a dot, and see a list of member functions).</p>

<p>Third, think of a compiler as of a subsitute for REPL (and there are true REPL environments for C++, such as the one available at <a href="https://repl.it/languages/cpp" rel="nofollow noreferrer">repl.it</a>). When you type a Python program, you don't know anything about its correctness until you run it. In C++ you can catch many errors just by compiling. So by the time of the first run you will already eliminate all syntax errors and many other errors related to type mismatching. I was learning Python <em>after</em> C++, and for me a source of constant annoyance was to make sure that <em>every single line of code</em> is executed before I could even <em>hope</em> it is correct.</p>

<p>Thus your typical session will look like "type some lines -> compile -> type some lines -> compile -> run"). Since you are asking about "fast feedback loops", I can tell that really good C++ programmers invest considerable effort in the type system used in their code. They don't use <code>int</code> everywhere even if they can. They use incompatible types for incompatible entities, declare member functions as <code>const</code> if they shouldn't modify objects, and add <code>static_assert</code> statements where possible, and avoid type casting. In other words, they make the compiler do the job. In the best case, if such code compiles, it works correctly. So the real feedback loop is concentrated on the stage of compilation.</p>

<p>In any case, remember that C++ is a complex hardware-oriented language with long history (just look at the sheer size of Stroustup's <a href="https://rads.stackoverflow.com/amzn/click/0321958322" rel="nofollow noreferrer">definitive guide</a>), so approach it with patience. Mastering it takes time, indeed, be persistent and don't expect fast results.</p>

CC BY-SA 4.0
2019-01-12T04:26:39.253Z
I really appreciate your answer, I've been looking for awhile for a discussion like this one but haven't seemed to come across a good one. Your points are really insightful, all three of them. I really like your first point especially, that c++ has a long history and that it makes sense to "study carefully major language features and understand the true reason why they exist". I also didn't realize that experienced c++ programmers spend so much time thinking about types. Do they use typedef very often?
Allen Wang
CC BY-SA 4.0
2019-01-12T08:52:53.737Z
One thing I forgot to mention is unit tests: if you write them, this is an additional mechanism for fast feedback loop. Typedefs are useful indeed, but in practice they are less useful since they don't introduce new types. Even if you say "typedef int MyInt;", you still can mix int and MyInt everywhere, so here compiler won't help to find inconsistencies.
rg_software
CC BY-SA 4.0
2019-02-19T07:32:45.663Z
@AllenWang typedef isn't very common because it *only* creates a new name for a type. This can be useful as a mneumonic device, but the compiler won't catch mistakes. If you need a new type, define it as a class or a struct with the proper member functions. Also: look into templates. Templates are far more powerful than generics in Java, and they preserve type information (so you can call overloaded functions). In many cases templates can completely replace the need for an inheritance heirarchy
Alecto
CC BY-SA 4.0
2019-01-09T13:14:11.363Z
2019-01-09T13:14:11.363Z
rg_software
<p>I have experience with Python and now am learning C++, I am finding the lack of an interpreter or a repl to be a serious hinderance when learning the language, as well as the ability to type <code>help(func)</code> in the interpreter when I get stuck. </p>

<p>What changes to the development environment, or to my approach to learning, can I make to increase my speed of learning?</p>

<p>(Is there a typical development flow that compiled language programmers use that make them efficient?)</p>

<p>How do they create fast feedback loops between code edits and results?</p>

CC BY-SA 4.0
2019-01-06T09:26:01.220Z
See: [Stack Overflow question](https://stackoverflow.com/q/16088295/7412956) and CERN's notes on [Clink](https://root.cern.ch/cling). You can have a REPL for C++.
Gypsy Spellweaver
CC BY-SA 4.0
2019-01-07T09:40:09.220Z
@GypsySpellweaver I thought this site is for both **teaching and learning** strategies.
ctrl-alt-delor
CC BY-SA 4.0
2019-01-07T16:46:27.113Z
@ctrl-alt-delor The site is as you say, basically. The Q originally was about development strategies. It still seems more developer-oriented than education-oriented, to me, and could benefit from more "focus".
Gypsy Spellweaver
CC BY-SA 4.0
2019-01-07T16:53:19.390Z
I disagree.  REPLs are extremely useful teaching tools. Java now has jshell, and I find this tool to be extremely helpful.
ncmathsadist
<self-learning><programming><c++>
How to learn to program compiled languages efficiently when coming from an interpreted language?
# How to learn to program compiled languages efficiently when coming from an interpreted language?

(Asked by: username_0 on 2019-01-06)

I have experience with Python and now am learning C++, I am finding the lack of an interpreter or a repl to be a serious hinderance when learning the language, as well as the ability to type `help(func)` in the interpreter when I get stuck.

What changes to the development environment, or to my approach to learning, can I make to increase my speed of learning?

(Is there a typical development flow that compiled language programmers use that make them efficient?)

How do they create fast feedback loops between code edits and results?

**Tags:** self-learning, programming, c++

> **Comments:**
> **username_1**: See: [Stack Overflow question](https://stackoverflow.com/q/16088295/7412956) and CERN's notes on [Clink](https://root.cern.ch/cling). You can have a REPL for C++.  
> **username_2**: @GypsySpellweaver I thought this site is for both **teaching and learning** strategies.  
> **username_1**: @username_2 The site is as you say, basically. The Q originally was about development strategies. It still seems more developer-oriented than education-oriented, to me, and could benefit from more "focus".  
> **username_3**: I disagree.  REPLs are extremely useful teaching tools. Java now has jshell, and I find this tool to be extremely helpful.  

---

## 3 answers

### Answer by username_6 on 2019-01-09. Score: 4 | Accepted answer

Your question deserves a long discussion, but I will try to narrow it down to few points.

First, remember that you are dealing not just with a "compiled language" such as Java or C# (that could be *much* easier targets for you), you are dealing with C++ that was designed with backward compatibility with C as a killer feature, and C was created in late 70s. It means that C++ indeed implements *numerous* design decisions that look archaic/obsolete/strange for a modern learner. Say, the whole system of header files is a hacky substitute for a proper package management. Thus it would be good for you to study carefully major language features and understand the true reason why they exist. In many cases you'll find newer and better alternatives to old tools (such as `std::vector` objects vs. arrays)

Second, use a good IDE. For instance, if you place a cursor under `printf()` (or any other library function) in MS Visual Studio and hit `F1`, it will jump to the extensive online manual, so this is not an issue. Also you will get autocomplete features similar to those available for Python (e.g., type a variable name, then a dot, and see a list of member functions).

Third, think of a compiler as of a subsitute for REPL (and there are true REPL environments for C++, such as the one available at [repl.it](https://repl.it/languages/cpp)). When you type a Python program, you don't know anything about its correctness until you run it. In C++ you can catch many errors just by compiling. So by the time of the first run you will already eliminate all syntax errors and many other errors related to type mismatching. I was learning Python *after* C++, and for me a source of constant annoyance was to make sure that *every single line of code* is executed before I could even *hope* it is correct.

Thus your typical session will look like "type some lines -> compile -> type some lines -> compile -> run"). Since you are asking about "fast feedback loops", I can tell that really good C++ programmers invest considerable effort in the type system used in their code. They don't use `int` everywhere even if they can. They use incompatible types for incompatible entities, declare member functions as `const` if they shouldn't modify objects, and add `static_assert` statements where possible, and avoid type casting. In other words, they make the compiler do the job. In the best case, if such code compiles, it works correctly. So the real feedback loop is concentrated on the stage of compilation.

In any case, remember that C++ is a complex hardware-oriented language with long history (just look at the sheer size of Stroustup's [definitive guide](https://rads.stackoverflow.com/amzn/click/0321958322)), so approach it with patience. Mastering it takes time, indeed, be persistent and don't expect fast results.

> **Comments:**
> **username_0**: I really appreciate your answer, I've been looking for awhile for a discussion like this one but haven't seemed to come across a good one. Your points are really insightful, all three of them. I really like your first point especially, that c++ has a long history and that it makes sense to "study carefully major language features and understand the true reason why they exist". I also didn't realize that experienced c++ programmers spend so much time thinking about types. Do they use typedef very often?  
> **username_6**: One thing I forgot to mention is unit tests: if you write them, this is an additional mechanism for fast feedback loop. Typedefs are useful indeed, but in practice they are less useful since they don't introduce new types. Even if you say "typedef int MyInt;", you still can mix int and MyInt everywhere, so here compiler won't help to find inconsistencies.  
> **username_7**: @AllenWang typedef isn't very common because it *only* creates a new name for a type. This can be useful as a mneumonic device, but the compiler won't catch mistakes. If you need a new type, define it as a class or a struct with the proper member functions. Also: look into templates. Templates are far more powerful than generics in Java, and they preserve type information (so you can call overloaded functions). In many cases templates can completely replace the need for an inheritance heirarchy  

---

### Answer by username_4 on 2019-01-10. Score: 1

I would say that you need to learn a completely different (old fashioned, perhaps archaic) programming paradigm, non-interactive coding. In Ye Olden Ancient days, a programmer would often write out a complete program (or at least large parts) on paper, before even going near a computer (or punch card machine).

Try it as an exercise. See how much code (how many lines) you can write (on paper, or into a plain text editor), and have it run correctly when first compiled and run. You might learn to think more about certain aspects of the code, before typing, and perhaps end up a better programmer (even after going back to helpful interactive IDEs). Compared to coders who only know how to compose within fast feedback loops.

This will also prevent learning the bad habits from randomized hack-and-slash trial-and-error coding (that, while possibly helpful in certain exploratory and learning situations) which can become a problematical practice within many high quality/reliability coding paradigms (those that don't include 100% provable unit test coverage).

> **Comments:**
> **username_5**: Hmmm. Perhaps as a thought experiment, but not in the real world. I lived in the time of 24 hour turn-around and coding on a key-punch. No one should have to do anything like that. Fast turn around is a universally good thing for learning, but you need different techniques today, such as Test First. I've done it both ways. Don't even think about going back.  That said, I don't use a REPL, not because it is too fast, but because it keeps an insufficient record of my work.  
> **username_4**: Since you programmed in the time of key-punches, you've already learned those lessons, and don't need to go back.  
> **username_5**: But I don't program "like that" in the modern age. I actually _learned_ something in the modern world.  

---

### Answer by username_5 on 2019-01-07. Score: 1

You can find REPLs for C++ with an online search, but my advice would be different. I do the following with Java, but equivalent tools for C++ exist.

First, I use a sophisticated IDE (Eclipse) that, among other things, does error highlighting as I type. A typed language like C++ permits many errors to be caught early, normally in the compiler, but they can be pushed back into the development environment prior to formal compilation. That works for most syntax errors and for many structural errors, such as omitting a declaration.

Second, I use *Test Driven Development* to build serious code. I just JUnit, which is tailored for Java, of course, but there are equivalent "units" (TDD frameworks) for most languages. The rule here is "no code without a failing test". The idea is that before you write any code you write a test for it based on the specification you have or that you create on the fly. The test captures your intent directly. You write the test for a function before you begin to write the function. It fails of course, since it can't even compile. But the IDE can automatically insert the stub for the function into the code. You then provide the function body and run the test again. If it fails you need to think again.

But TDD is even better than that, since when you run the "test" you are actually running *all of the tests*; the test *suite*. So, if something used to work and now an earlier test breaks you get immediate feedback on it and, since the only thing you changed is that one method body, the source of error is usually pretty obvious. Moreover, tests are run independently of each other so that a failure of one test doesn't cascade into other failures that obscure the problem.

This is a workflow quite different from that of a REPL, so it takes some practice. But the IDE can do many things for you in addition to what is described here. The best of them have a plugin architecture in which you can easily add additional tools as needed.

Two additional notes. First, is that I use the same tools and techniques when programming Python and Ruby.

Second, having built many compilers, you should understand that the actual difference between a processor for a compiled language and an interpreted one is surprisingly small. The processing for the interpreted language has everything but the final stage code generator. But if it is to be efficient, it still creates an intermediate form of the program, possibly a tree or even an abstract assembler language version. Some of the optimization can be omitted, but only the late-stage optimizations, normally. So, an IDE for an interpreted language isn't so odd.

> **Comments:**
> **username_0**: Your point about TDD is well taken. It is hard, however, for a newcomer to begin writing tests when one doesn't know very much about how the language works.  
> **username_5**: You have to teach test writing, of course, preferably with in-class demonstrations. Initially the tests can't be very sophisticated, but they shouldn't be in any case. Prefer lots of simple tests over a few complex ones. This makes them easier to write and more useful as they give fine-grained error reporting. Note that tests are run as suites, not individually. The tests in a suite are independent of one another. In Eclipse, if you have a test for a non-existent method, the IDE will write the stub for you, so it makes things simpler.  

---

