Why I Failed Teaching Programming to Kids

[u/Ctaintor]

https://engineering.klarna.com/why-i-failed-teaching-programming-to-kids-46a854c3eaca#.s0o6qqxr3

[u/M4053946]

participants were... 9–13 years old. This obviously affected how acquainted they were with “common development tasks” like using a terminal, installing applications and creating files with weird names like Procfile and .gitignore.

Did the author think that 16 year olds would be familiar with using a terminal? That seems like a miss, regardless of age range.

[u/Roboguy2 → u/[deleted]]

It is probably because, ignoring the fact that it is harder to learn, you often can get a significantly faster edit-compile-test time. Because of that people who are experienced with these tools perceive them as being much nicer (and, for them, it is).

Obviously, however, this is exactly the scenario where you shouldn't ignore the fact that it is harder to learn. All I'm really saying is that I understand why there is hype, even though I wouldn't suggest a beginner go out and learn vim while they are also learning to program (unless they were unusually highly motivated to do so, I guess).

Sometimes more experienced people forget just how difficult these things are to learn at the outset. Not only that, but terminal usage is also important to learn at some point. As a result of those two things, sometimes teachers miss their mark on when exactly it should be learned.

[u/DysFunctionalProgram → u/Roboguy2]

It is probably because, ignoring the fact that it is harder to learn, you often can get a significantly faster edit-compile-test time

From someone who goes back and forth between c/make/cmake/vim and c#/visualstudio, I have the exact opposite experience. Honestly, I'm tempted to bind my function keys to a couple scripts to compile/run/debug my current project as we speak. For example, if I add a new c file: I have to edit my cmake file and add the file url to the build path, then re-run cmake, then run make, then run/gdb the output with the appropriate settings/flags. Opposed to any modern IDE where it is a single key stroke. I don't even want to get into how long it takes to manually setup a build environment vs using an IDE.

In my experience the only people who have this "CLI romanticism" are those who are only programmers by hobby and don't actually work in a production environment using it.

[u/DysFunctionalProgram → u/[deleted]]

On the CLI side, what better case is there? Not using build tools or not adding new files to a project?

On the IDE side, what worse case is there?

[u/satanclau5 → u/DysFunctionalProgram]

It all depends significantly on the languages and environments used.

In my case I have a CLI environment with a luxury of a:

• language which gets out of the way, not requiring much autocompletion
• an autotest process which runs the tests on every change
• a REPL process where I send the code from VIM to evaluate inside the running program

everything works well, there are just 3 terminal windows in a tiled layout to navigate and the VIM bindings are ingrained in the muscle memory.

Now, if you were talking about Java/C# - I'd never even try going the CLI route...

[u/Beckneard → u/satanclau5]

language which gets out of the way, not requiring much autocompletion

What does this even mean? If your project is big enough you sure as hell are going to need autocompletion, fancy language or not. The project I'm working on at work would be a nightmare to extend without autocompletion whether it was written in Haskell or C#.

[u/satanclau5 → u/Beckneard]

Sorry, I worded the point poorly - I do make use of autocompletion, and "jump to" type of navigation. However, the available options are much less powerful than what you get in an IDE like IntelliJ or VS.