4 ms·

The way you learn C++

10 points by snmf 12y ago

neikos 12y ago
I don't think the points raised are valid. There are /many/ great tutorials online on learning C++. It is not the job of the tool to try and guess what its user wants to do.
- snmf 12y ago
  Indeed, there are many sources where you can learn C++, but I think most of them fail to convince a beginner that it's worth trying to learn the language. When you see the results immediately, it encourages you to learn how it works.
  - neikos 12y ago
    Something I have been struggling with is the non formal approach to computer programming. Lately I find myself more and more convinced that if I had learned Programming in a more formal context I would have seen results faster than not. While I agree that seeing results is important to the learning loop I think that correctly learning is the way to do that. Programming produces code, solutions to problems produce results. So if you want to see results you will have to first find a problem and solve it without thinking on how to program it. Sure 'outputting text' is a valid problem, however not very useful. "Reading a text file" might be a bit more on par and will immediately give you several tutorials on how to achieve that. And the way to go is to solve problems and not to 'program' you will just find yourself in a corner, unsure on what to do next. One could e.g. search on how to pass over a parameter to a program, how c++ handles file inputs, I/O Streams.
    - snmf 12y ago
      Different approaches to learning lead to different results. The approach I recommend is more about Get Things Done manner, hoping that it will create enough incentives to delve in "theory" of the language after you got some results.
techjuice 12y ago
Some things of top quality and value are not noticed immediately. Just because someone tells you a Lamborghini, Buggati or Rolls Royce are top of the line and like no other car you have experienced you will not be able to comprehend what they are saying until you have learned to drive the car and have experienced it for yourself. The favorite languages and operating systems of many are built in C and/or C++ because of many of their exceptional qualities for the jobs they are being used for. Instead of saying it is hard it is better to choose the right tool for the job or what you are capable of learning for what you want to do. You do not learn C or C++ if your goal is to become a regular Joe developer and you are not heavily focused on high performance and security. If you are more focused on security and performance there is a good chance you learned C and C++ so you could create modules for the web server, middle ware, operating system, etc. that you are using to improve performance and or security. You also need to know C and C++ to troubleshoot bugs or performance issues that may occur which will require you to go under the hood and review the source code for the language which is normally in C or C++, and if your using a debugger you will need to know some assembly from time to time. It is always ill advised and frowned upon to become another copy paster and not understand what you are doing especially when using a programming language with full access to everything the operating system has to offer. It is like going to a job interviewing saying you know C++ and have never programmed any production quality code in C++ and the only thing you have done is some tutorials online. When some tough problems come up you will not be able to troubleshoot the problem first and be on hold waiting for someone to update your question online with something you hope is correct but you will unfortunately not be able to trust and verify the solution. It is always the best course of action to take something you see as hard and take it as a challenge to learn it and become proficient so you are at least at an intermediate stage and are not struggling with the basics of the language. This will give you the ability to talk with others on a more professional level to solve any problems that will come up so the conversation will be constructive. It also feels good when you look back at something you thought was so hard and develop highly secure and high performance applications that you thought were not possible when you wrote your first few lines of code.
akersten 12y ago
> why on Earth I must know what parameters should I have for compilation from the very beginning if just want to print something? Herein lay the trouble of learning higher-level languages first, which hide all of the complexity and real work from the programmer. I'm not sure the author recognizes how much goes on under-the-hood while "just" printing something, and it's out of order to blame C++ for exposing the complexity when C++ is a language specifically designed to allow for complex, close-to-the-metal programming.
nvader 12y ago
I found this a very personal and honest explanation about the limitations of one approach to learning a programming language or framework. Without prejudice, lets call it the "agile approach" to learning-> you want to get started quickly and then iterate to a better place. In my own experience, I've always been dissatisfied with this approach. It builds too slowly, and you either reinvent the wheels that already exist in the language, or fail to take full advantage of transformational abilities of the language. Assuming you already know how to program in language X, you end up "Writing X in Y" (as in, "writing Java in Ruby"). I do prefer the alternative, which is to spend some time reading the language manual and references, fully understand the language before going off to do some damage. Learning is process that is never completed; however the "RUP" approach to learning gives you a much more strongly connected belief network on which to hang concepts you'll be introduced to in the future. This is opposed to having to take new lessons as standalone facts to be memorised: see the article's confusion regarding pointers and references. However, we often don't get to spend that time upfront learning things. Sometimes the project deadline requires you to pick up that new framework and get something working -right now-. Alternatively sometimes I need to work with something that I don't want to spend all that energy learning, and it's easier to just hack along, rather than actually commit to a deep learning of the framework. There are two questions this raises for me. 1) As an engineer who claims to value craftsmanship, how do I reconcile with the fact that I don't really know at least a few of the tools I use? Is the right action to actually invest my own time in learning new frameworks, no matter how skeptical I might be of their value outside this one project? This risk-reward calculus is especially exacerbated in an ecosystem with a lot of churn in frameworks and libraries. In such a situation, what is the right approach for me? 2) As a producer of knowledge tools for other developers (libraries, APIs, maybe one day programming languages), how should I define my interfaces knowing that some of my users will not bother to learn them? Do I have a responsibility towards them? Slightly more speculatively, I wonder how this would affect language design? One of pg's aphorisms is that tools designed for use by people the designers consider inferior will generally be poor quality. However, that doesn't stop such tools from being popular. I don't think we've truly plumbed the depths of a language "designed for lazy and/or sloppy people", and I'm willing to bet that executed well, such a language could be very popular.
- 12y ago

10 points by snmf 12y ago

I don't think the points raised are valid. There are /many/ great tutorials online on learning C++. It is not the job of the tool to try and guess what its user wants to do.

snmf 12y ago
Indeed, there are many sources where you can learn C++, but I think most of them fail to convince a beginner that it's worth trying to learn the language. When you see the results immediately, it encourages you to learn how it works.
- neikos 12y ago
  Something I have been struggling with is the non formal approach to computer programming. Lately I find myself more and more convinced that if I had learned Programming in a more formal context I would have seen results faster than not. While I agree that seeing results is important to the learning loop I think that correctly learning is the way to do that. Programming produces code, solutions to problems produce results. So if you want to see results you will have to first find a problem and solve it without thinking on how to program it. Sure 'outputting text' is a valid problem, however not very useful. "Reading a text file" might be a bit more on par and will immediately give you several tutorials on how to achieve that. And the way to go is to solve problems and not to 'program' you will just find yourself in a corner, unsure on what to do next. One could e.g. search on how to pass over a parameter to a program, how c++ handles file inputs, I/O Streams.
  - snmf 12y ago
    Different approaches to learning lead to different results. The approach I recommend is more about Get Things Done manner, hoping that it will create enough incentives to delve in "theory" of the language after you got some results.

techjuice 12y ago

Some things of top quality and value are not noticed immediately. Just because someone tells you a Lamborghini, Buggati or Rolls Royce are top of the line and like no other car you have experienced you will not be able to comprehend what they are saying until you have learned to drive the car and have experienced it for yourself. The favorite languages and operating systems of many are built in C and/or C++ because of many of their exceptional qualities for the jobs they are being used for. Instead of saying it is hard it is better to choose the right tool for the job or what you are capable of learning for what you want to do. You do not learn C or C++ if your goal is to become a regular Joe developer and you are not heavily focused on high performance and security. If you are more focused on security and performance there is a good chance you learned C and C++ so you could create modules for the web server, middle ware, operating system, etc. that you are using to improve performance and or security. You also need to know C and C++ to troubleshoot bugs or performance issues that may occur which will require you to go under the hood and review the source code for the language which is normally in C or C++, and if your using a debugger you will need to know some assembly from time to time. It is always ill advised and frowned upon to become another copy paster and not understand what you are doing especially when using a programming language with full access to everything the operating system has to offer. It is like going to a job interviewing saying you know C++ and have never programmed any production quality code in C++ and the only thing you have done is some tutorials online. When some tough problems come up you will not be able to troubleshoot the problem first and be on hold waiting for someone to update your question online with something you hope is correct but you will unfortunately not be able to trust and verify the solution. It is always the best course of action to take something you see as hard and take it as a challenge to learn it and become proficient so you are at least at an intermediate stage and are not struggling with the basics of the language. This will give you the ability to talk with others on a more professional level to solve any problems that will come up so the conversation will be constructive. It also feels good when you look back at something you thought was so hard and develop highly secure and high performance applications that you thought were not possible when you wrote your first few lines of code.

akersten 12y ago

> why on Earth I must know what parameters should I have for compilation from the very beginning if just want to print something? Herein lay the trouble of learning higher-level languages first, which hide all of the complexity and real work from the programmer. I'm not sure the author recognizes how much goes on under-the-hood while "just" printing something, and it's out of order to blame C++ for exposing the complexity when C++ is a language specifically designed to allow for complex, close-to-the-metal programming.

nvader 12y ago

I found this a very personal and honest explanation about the limitations of one approach to learning a programming language or framework. Without prejudice, lets call it the "agile approach" to learning-> you want to get started quickly and then iterate to a better place. In my own experience, I've always been dissatisfied with this approach. It builds too slowly, and you either reinvent the wheels that already exist in the language, or fail to take full advantage of transformational abilities of the language. Assuming you already know how to program in language X, you end up "Writing X in Y" (as in, "writing Java in Ruby"). I do prefer the alternative, which is to spend some time reading the language manual and references, fully understand the language before going off to do some damage. Learning is process that is never completed; however the "RUP" approach to learning gives you a much more strongly connected belief network on which to hang concepts you'll be introduced to in the future. This is opposed to having to take new lessons as standalone facts to be memorised: see the article's confusion regarding pointers and references. However, we often don't get to spend that time upfront learning things. Sometimes the project deadline requires you to pick up that new framework and get something working -right now-. Alternatively sometimes I need to work with something that I don't want to spend all that energy learning, and it's easier to just hack along, rather than actually commit to a deep learning of the framework. There are two questions this raises for me. 1) As an engineer who claims to value craftsmanship, how do I reconcile with the fact that I don't really know at least a few of the tools I use? Is the right action to actually invest my own time in learning new frameworks, no matter how skeptical I might be of their value outside this one project? This risk-reward calculus is especially exacerbated in an ecosystem with a lot of churn in frameworks and libraries. In such a situation, what is the right approach for me? 2) As a producer of knowledge tools for other developers (libraries, APIs, maybe one day programming languages), how should I define my interfaces knowing that some of my users will not bother to learn them? Do I have a responsibility towards them? Slightly more speculatively, I wonder how this would affect language design? One of pg's aphorisms is that tools designed for use by people the designers consider inferior will generally be poor quality. However, that doesn't stop such tools from being popular. I don't think we've truly plumbed the depths of a language "designed for lazy and/or sloppy people", and I'm willing to bet that executed well, such a language could be very popular.

12y ago