• We’re currently investigating an issue related to the forum theme and styling that is impacting page layout and visual formatting. The problem has been identified, and we are actively working on a resolution. There is no impact to user data or functionality, this is strictly a front-end display issue. We’ll post an update once the fix has been deployed. Thanks for your patience while we get this sorted.

12 year old son wants to learn programming

What is the best programming tutorial to start him off with ? He has already done a little before learning it himself.

What is the most popular and most used programming language today ?
 
He probably has some goal in mind or some problem to solve. I haven't met anyone who sat down and thought "you know what, I want to learn programming" without thinking "I want to learn how to do x or solve y or learn how to make z."

Personally, I'd have him start of in C++, despite what some naysayers around here think. Pick up some beginner book (I don't know if there is a Headfirst C++ edition, but that series is pretty good for beginners from what I've seen) then tell him to start reading and to enjoy it, because he is going to have to do a lot of reading.
 
He probably has some goal in mind or some problem to solve. I haven't met anyone who sat down and thought "you know what, I want to learn programming" without thinking "I want to learn how to do x or solve y or learn how to make z."

Personally, I'd have him start of in C++, despite what some naysayers around here think. Pick up some beginner book (I don't know if there is a Headfirst C++ edition, but that series is pretty good for beginners from what I've seen) then tell him to start reading and to enjoy it, because he is going to have to do a lot of reading.

Thank you.
 
OP- Hands down, http://learnpythonthehardway.org/

I second C or C++; kids that age are very clever (given that they're interested) and there is no reason to start them off with a dumbed-down language, especially if the parent is there to help them get started.

Java and Python are 'dumbed down'? Hardly. There's just certain realities of computing that for the vast majority of tasks, are no longer relevant. Simply managing another layer (memory) doesn't make you a better programmer. Any anecdotal evidence leading to this idea is no doubt correlation, not causation.

Java brought a great garbage collector with the JVM. Someday we'll have a 'GC' for threading. Like garbage collection, it will simply free up resources to more relevant problems of the day (better logic, better code, solving more real, applicable problems in more domains).

Manually managing memory on a local machine is already pretty quaint. We're looking into the present and future with multinode processing. 10, 40, 1000 machines processing together. That's the future, not the past.
You can choose to be one of those guys, writing massively parallel and fault tolerant programs that are on the cutting edge solving new problems.. or you can go manage memory like it's 1983 still. There's nothing WRONG with that.. but it is the cutting edge in 1978. There's more out there than thinking that's the peak of computer science.

My advice to the OP on comments like yours.. learn any programming language, doesn't really matter. At which point you can go into something even many amazing programmers don't really do much of: low level programming. Or, you can spend your time stepping up to something a little more interesting and relevant going forward- functional programming, artificial intelligence, fault tolerant multinode programming. A number of things other than programming cellphone firmware. <- As thrilling as that may sound.
 
OP- Hands down, http://learnpythonthehardway.org/



Java and Python are 'dumbed down'? Hardly. There's just certain realities of computing that for the vast majority of tasks, are no longer relevant. Simply managing another layer (memory) doesn't make you a better programmer. Any anecdotal evidence leading to this idea is no doubt correlation, not causation.

Java brought a great garbage collector with the JVM. Someday we'll have a 'GC' for threading. Like garbage collection, it will simply free up resources to more relevant problems of the day (better logic, better code, solving more real, applicable problems in more domains).

Manually managing memory on a local machine is already pretty quaint. We're looking into the present and future with multinode processing. 10, 40, 1000 machines processing together. That's the future, not the past.
You can choose to be one of those guys, writing massively parallel and fault tolerant programs that are on the cutting edge solving new problems.. or you can go manage memory like it's 1983 still. There's nothing WRONG with that.. but it is the cutting edge in 1978. There's more out there than thinking that's the peak of computer science.

My advice to the OP on comments like yours.. learn any programming language, doesn't really matter. At which point you can go into something even many amazing programmers don't really do much of: low level programming. Or, you can spend your time stepping up to something a little more interesting and relevant going forward- functional programming, artificial intelligence, fault tolerant multinode programming. A number of things other than programming cellphone firmware. <- As thrilling as that may sound.

You know, I often disagree with your points in this forum, but this time, I think you hit the nail right on the head.
 
OP- Hands down, http://learnpythonthehardway.org/



Java and Python are 'dumbed down'? Hardly. There's just certain realities of computing that for the vast majority of tasks, are no longer relevant. Simply managing another layer (memory) doesn't make you a better programmer. Any anecdotal evidence leading to this idea is no doubt correlation, not causation.

Java brought a great garbage collector with the JVM. Someday we'll have a 'GC' for threading. Like garbage collection, it will simply free up resources to more relevant problems of the day (better logic, better code, solving more real, applicable problems in more domains).

Manually managing memory on a local machine is already pretty quaint. We're looking into the present and future with multinode processing. 10, 40, 1000 machines processing together. That's the future, not the past.
You can choose to be one of those guys, writing massively parallel and fault tolerant programs that are on the cutting edge solving new problems.. or you can go manage memory like it's 1983 still. There's nothing WRONG with that.. but it is the cutting edge in 1978. There's more out there than thinking that's the peak of computer science.

My advice to the OP on comments like yours.. learn any programming language, doesn't really matter. At which point you can go into something even many amazing programmers don't really do much of: low level programming. Or, you can spend your time stepping up to something a little more interesting and relevant going forward- functional programming, artificial intelligence, fault tolerant multinode programming. A number of things other than programming cellphone firmware. <- As thrilling as that may sound.

Agree with douglasb, this is dead on.
 
What is the best programming tutorial to start him off with ? He has already done a little before learning it himself.

What is the most popular and most used programming language today ?

C. It's the most widely used and every modern programming language is based on it.
 
Simply managing another layer (memory) doesn't make you a better programmer.

If you're using so much memory that it needs to be managed, then yes, it's best not to automate it. If you've got a script that's pinging a list of servers, then go nuts.

Java brought a great garbage collector with the JVM.

Garbage collectors are garbage. Show me a stable Java program that uses more than a few tens of megabytes memory.

Manually managing memory on a local machine is already pretty quaint.

You can't be serious. That's like saying you don't need to manage your time or money. You don't want to teach someone to be a lazy programmer.

writing massively parallel and fault tolerant programs that are on the cutting edge solving new problems..

And they're not written in Python.

In the case where you have memory to throw away, fine, but to say that programmers don't need to learn memory management is a dangerous assumption.
 
Last edited:
You can't be serious. That's like saying you don't need to manage your time or money. You don't want to teach someone to be a lazy programmer.

I've been working as a professional software developer for twenty years, across many industries and on projects as diverse as web applications, shrink-wrapped .net apps, iOS and Android mobile apps, scripts, database apps, etc. The last time I had to manage memory manually using an API designed for that purpose was in C++ around 1995. The last time I had to think about memory management in general was three years ago and that was an iOS app using Objective C.

I'm not saying that there aren't niches remaining where manual memory management is required, but they are few and growing fewer. The average developer interviewing for a mid-level position these days will not be asked about manual memory management, for the simple reason that the people doing the asking don't know anything about it either.
 
Garbage collectors are garbage. Show me a stable Java program that uses more than a few tens of megabytes memory.

Your statement is subjective and over-broad. Not surprisingly, a lot of research has been done in this area. See, for example, http://cs.canisius.edu/~hertzm/gcmalloc-oopsla-2005.pdf, or http://www.cs.utexas.edu/~mckinley/papers/mmtk-sigmetrics-2004.pdf.

The general conclusion is that the efficiency and performance of garbage collection algorithms degrades rapidly in memory-constrained environments. In environments where ram is abundant and fast, the performance differences (measure in terms of execution speed and efficiency at freeing space) are in the +/- 5-10% range vs. explicit memory management. That price is more than affordable given the engineering benefits. For embedded systems and other applications where memory remains constrained explicit memory management techniques will always yield better results. However, the population of memory constrained environments/applications is going to continue to grow smaller over time, as devices have more and more ram available to them.

Lastly, this statement from the 2004 paper linked above is interesting:

"The software engineering bene&#64257;ts of garbage collection over explicit memory management are widely accepted, but the performance trade-off in languages designed for garbage collection is unexplored. Section 5.3 shows a clear mutator performance advantage for contiguous over free-list allocation, and the architectural comparison shows that architectural trends should make this advantage more pronounced. The traditional explicit memory management use of malloc() and free() is tightly coupled to the use of a free-list allocator&#8212;in fact the MMTk free-list allocator implementation is based on Lea allocator [32], which is the default allocator in standard C libraries. Standard explicit memory management is thus unable to exploit the locality advantages of contiguous allocation. It is therefore possible that garbage collection presents a performance advantage over explicit memory management on current or future architectures."
 
I've been working as a professional software developer for twenty years, across many industries and on projects as diverse as web applications, shrink-wrapped .net apps, iOS and Android mobile apps, scripts, database apps, etc. The last time I had to manage memory manually using an API designed for that purpose was in C++ around 1995. The last time I had to think about memory management in general was three years ago and that was an iOS app using Objective C.

I'm not saying that there aren't niches remaining where manual memory management is required, but they are few and growing fewer. The average developer interviewing for a mid-level position these days will not be asked about manual memory management, for the simple reason that the people doing the asking don't know anything about it either.

QFT....the OP you quoted I have a problem with as well.

I don't think they understand TODAY.
 
What is the most popular and most used programming language today ?

Don't worry about this. Let your son learn how to learn. By the time he enters the workforce, there'll be many more programming languages.

For now, just let him continue down the path that he enjoys. Just search for "<whatever language he's using now> tutorial" on your favorite search engine and go from there.

-M
 
I'd start with Java. It's popular now, and it's not something that requires a lot of technical thinking, in many instances. Most-importantly is that popularity, because you'll find LOADS of tutorials and resources online without even trying. That, and Java shares a lot of concepts with C++ (and C, really), so the syntax and thinking of Java can help translate to learning those languages well (not sure too much with Python, as I have a VERY-limited knowledge of it).

There's also always Scratch, which we actually used in college. It's meant for teaching kids about coding concepts through something comparable to Legos--it basically using building blocks of code, and the whole setup's really simple.

scratch.mit.edu
 
Your statement is subjective and over-broad. Not surprisingly, a lot of research has been done in this area. See, for example, http://cs.canisius.edu/~hertzm/gcmalloc-oopsla-2005.pdf, or http://www.cs.utexas.edu/~mckinley/papers/mmtk-sigmetrics-2004.pdf.

The general conclusion is that the efficiency and performance of garbage collection algorithms degrades rapidly in memory-constrained environments. In environments where ram is abundant and fast, the performance differences (measure in terms of execution speed and efficiency at freeing space) are in the +/- 5-10% range vs. explicit memory management. That price is more than affordable given the engineering benefits. For embedded systems and other applications where memory remains constrained explicit memory management techniques will always yield better results. However, the population of memory constrained environments/applications is going to continue to grow smaller over time, as devices have more and more ram available to them.

Lastly, this statement from the 2004 paper linked above is interesting:

"The software engineering bene&#64257;ts of garbage collection over explicit memory management are widely accepted, but the performance trade-off in languages designed for garbage collection is unexplored. Section 5.3 shows a clear mutator performance advantage for contiguous over free-list allocation, and the architectural comparison shows that architectural trends should make this advantage more pronounced. The traditional explicit memory management use of malloc() and free() is tightly coupled to the use of a free-list allocator—in fact the MMTk free-list allocator implementation is based on Lea allocator [32], which is the default allocator in standard C libraries. Standard explicit memory management is thus unable to exploit the locality advantages of contiguous allocation. It is therefore possible that garbage collection presents a performance advantage over explicit memory management on current or future architectures."

Don't get me wrong. I'm currently using java and not worrying about memory is pretty nice.

However, I think that C++ gets the short stick because it has manual memory management. The thing is, modern C++ pretty effectively solves the problem of memory leaks (unique_ptr and shared_ptr), but more importantly, It has solve the issue of resource leaks as somewhat of a side effect of solving its memory management problems.

I feel like the problem of resource management is often overlooked by GC languages. Sure, they soak up memory, but do they properly handle closing a database connection? Not really. The same thing that bites you with C++ will bite you in other GC languages.

The C++ Destructor pattern has a certain level of elegance to it. You reliably know that when the object is moved out of scope or destroyed, the connection is closed. That is a big win IMO. All the sudden, a properly written object handles both memory management AND resource management. Something no other GC language can really claim.

Sure, there are nasties all over the place with C++, but I don't think that memory management is as big an issue with it as people make it out to be (especially C++11 and on).

I wouldn't suggest C, just because it has no real benefit today. C++ solves a lot of C problems and honestly, the worst part about C++ is that it started out as C. As soon as it sheds its #include<roots.h> it will be a much better language (and it will, C++17 is promising to come with real module support, oh goodie!)
 
Back
Top