5 ms·

I disagree that making setup easier for the uninitiated is good. The uninitiated should begin with a bare-bones text editor and a shell prompt. If you don't un

I disagree that making setup easier for the uninitiated is good. The uninitiated should begin with a bare-bones text editor and a shell prompt. If you don't understand what is happening from that level, you will never understand what is going on in complicated frameworks. You will be the programming equivalent of your grandmother who thinks Facebook is the internet.

freeone3000 5y ago
Okay, but, does that enable you to solve the problems you want to solve using computers? We have to remember that that is the end goal -- spend less time programming computers, and less time solving problems, and more time with a working solution.
- skohan 5y ago
  I would not be as hard-line as the other commenter in terms of suggesting that everyone should start with bash and vim, however I think it is a valid point that learning the principals of computing is valuable, and tools which abstract that away are not always doing you a favor. > We have to remember that that is the end goal -- spend less time programming computers, and less time solving problems, and more time with a working solution. I of disagree that time-to-solution is the true end-goal. It might be, depending on your use case, but there may be other constraints. For instance, let's say I make a piece of software, and I have a choice between choosing an "easy" solution which takes me 100 hours to complete, or a hard version which takes 500 hours. And let's say the easy version allows the user to complete their task in 30 seconds, where the hard version allows them to complete their task in 10 second. That means every time my code is executed, I have saved 20 seconds of the user's time by doing things the hard way. Now let's say my code is executed on average 1000 times per hour. That means every hour my product is out there, I save about 5.5 hours of user time for doing things the hard way. In only 72 hours, that 400 hours of productivity I "lost" is made up for, and for the rest of the lifetime of the product it's pure upside. At the end of the day, programming is about making computer hardware do what you want. If we let ourselves get too far away from the computer, it's hard for us to do that well.
- alpaca128 5y ago
  And the best way to spend as little time as possible solving problems is solving them the right way. Which you can achieve best with some understanding of what's actually going on in the background. If you know the basics you can apply them to any tool. If you only learn to build software using a specific framework, IDE etc. you're probably going to have problems if anything in the setup changes. One day in a simple text editor and a shell taught me more about how Java builds work than years of formal education, because all those years were spent in an IDE and nobody even explained what the classpath is.
ConceptJunkie 5y ago
There's a lot of truth in this. Getting the uninitiated to the point of solving problems is not a bad thing, per se, but too much of that creates cargo cult programmers, and that is a very bad thing. And very common. If your goal to solve a problem, then you should use something that helps you solve that problem quickly. If your goal to learn how to solve problems, then you probably shouldn't. Those are both valid use cases, but they are very different.
- Godel_unicode 5y ago
  This is a false equivalency, you can always go back and learn how the lower layer works. Tons of people learn how to drive, and many of them go on to learn how their car works. Get people excited and empowered, then teach them some arcana.
foldr 5y ago
Although I sympathize with this line of thought, remember that we’re all uninitiated by the standards of a few decades ago. The time was when you were uninitiated if you couldn’t hand assemble your programs to a series of hex digits. Indeed, I own a copy of a book aimed at children that teaches you how to do just that for the BBC Micro and ZX Spectrum. (The publisher released it as a free PDF if anyone is curious: https://yurichev.com/mirrors/machine-code-for-beginners.pdf https://yurichev.com/mirrors/machine-code-for-beginners.pdf)
- grepfru_it 5y ago
  that PDF is awesome and i have never seen it before. i had to teach someone about programming from absolute zero and i followed a very similar approach. starting with what a transistor is, a basic intro into a cpu, what machine code is, low level languages and high level languages which took us into a python hello world. you could see the wheels turning at the end of the session...
  - skohan 5y ago
    That sounds amazing. It makes me want to learn more about transistors, and how CPUs actually work at an EE level. My studies started with registers and machine code as the "ground truth" - but it would be cool to have an intuition about what is actually physically happening inside the CPU and memory.
    - grepfru_it 5y ago
      its all just 0s and 1s. on or off. an electron passing through billions of gates going down a path until it hits its destination.
- skohan 5y ago
  I agree with what you are saying, and probably it is part of the nature of progress to continually move some of the core topics out of the realm of CS common knowledge to make way for the new. However I think not all things are created equal. For instance, I think basically everyone can agree that moving from assembly to C and other high-level languages was basically a strict upgrade, and obviated the need for assembly programming in all but a few specific use cases. By contrast, using the command line and shell programming is every bit as relevant as it was 20 years ago, and I don't see that changing any time soon. Both assembly and the shell are difficult and alienating to newcomers. But learning is mostly academic at this point, while learning the other opens up entire new worlds in terms of what you can do with a computer. In other words, learning assembly is like learning latin. Maybe interesting, but not particularly useful. Learning bash is like learning Chinese. Not particularly easy, but there's a lot you can do with it right now.
coldtea 5y ago
>If you don't understand what is happening from that level, you will never understand what is going on in complicated frameworks. On the other someone could have said the same to your regarding assembly code and so on.

freeone3000 5y ago

Okay, but, does that enable you to solve the problems you want to solve using computers? We have to remember that that is the end goal -- spend less time programming computers, and less time solving problems, and more time with a working solution.

skohan 5y ago
I would not be as hard-line as the other commenter in terms of suggesting that everyone should start with bash and vim, however I think it is a valid point that learning the principals of computing is valuable, and tools which abstract that away are not always doing you a favor. > We have to remember that that is the end goal -- spend less time programming computers, and less time solving problems, and more time with a working solution. I of disagree that time-to-solution is the true end-goal. It might be, depending on your use case, but there may be other constraints. For instance, let's say I make a piece of software, and I have a choice between choosing an "easy" solution which takes me 100 hours to complete, or a hard version which takes 500 hours. And let's say the easy version allows the user to complete their task in 30 seconds, where the hard version allows them to complete their task in 10 second. That means every time my code is executed, I have saved 20 seconds of the user's time by doing things the hard way. Now let's say my code is executed on average 1000 times per hour. That means every hour my product is out there, I save about 5.5 hours of user time for doing things the hard way. In only 72 hours, that 400 hours of productivity I "lost" is made up for, and for the rest of the lifetime of the product it's pure upside. At the end of the day, programming is about making computer hardware do what you want. If we let ourselves get too far away from the computer, it's hard for us to do that well.
alpaca128 5y ago
And the best way to spend as little time as possible solving problems is solving them the right way. Which you can achieve best with some understanding of what's actually going on in the background. If you know the basics you can apply them to any tool. If you only learn to build software using a specific framework, IDE etc. you're probably going to have problems if anything in the setup changes. One day in a simple text editor and a shell taught me more about how Java builds work than years of formal education, because all those years were spent in an IDE and nobody even explained what the classpath is.

ConceptJunkie 5y ago

There's a lot of truth in this. Getting the uninitiated to the point of solving problems is not a bad thing, per se, but too much of that creates cargo cult programmers, and that is a very bad thing. And very common. If your goal to solve a problem, then you should use something that helps you solve that problem quickly. If your goal to learn how to solve problems, then you probably shouldn't. Those are both valid use cases, but they are very different.

Godel_unicode 5y ago
This is a false equivalency, you can always go back and learn how the lower layer works. Tons of people learn how to drive, and many of them go on to learn how their car works. Get people excited and empowered, then teach them some arcana.

foldr 5y ago

Although I sympathize with this line of thought, remember that we’re all uninitiated by the standards of a few decades ago. The time was when you were uninitiated if you couldn’t hand assemble your programs to a series of hex digits. Indeed, I own a copy of a book aimed at children that teaches you how to do just that for the BBC Micro and ZX Spectrum. (The publisher released it as a free PDF if anyone is curious: https://yurichev.com/mirrors/machine-code-for-beginners.pdf https://yurichev.com/mirrors/machine-code-for-beginners.pdf)

grepfru_it 5y ago
that PDF is awesome and i have never seen it before. i had to teach someone about programming from absolute zero and i followed a very similar approach. starting with what a transistor is, a basic intro into a cpu, what machine code is, low level languages and high level languages which took us into a python hello world. you could see the wheels turning at the end of the session...
- skohan 5y ago
  That sounds amazing. It makes me want to learn more about transistors, and how CPUs actually work at an EE level. My studies started with registers and machine code as the "ground truth" - but it would be cool to have an intuition about what is actually physically happening inside the CPU and memory.
  - grepfru_it 5y ago
    its all just 0s and 1s. on or off. an electron passing through billions of gates going down a path until it hits its destination.
skohan 5y ago
I agree with what you are saying, and probably it is part of the nature of progress to continually move some of the core topics out of the realm of CS common knowledge to make way for the new. However I think not all things are created equal. For instance, I think basically everyone can agree that moving from assembly to C and other high-level languages was basically a strict upgrade, and obviated the need for assembly programming in all but a few specific use cases. By contrast, using the command line and shell programming is every bit as relevant as it was 20 years ago, and I don't see that changing any time soon. Both assembly and the shell are difficult and alienating to newcomers. But learning is mostly academic at this point, while learning the other opens up entire new worlds in terms of what you can do with a computer. In other words, learning assembly is like learning latin. Maybe interesting, but not particularly useful. Learning bash is like learning Chinese. Not particularly easy, but there's a lot you can do with it right now.

coldtea 5y ago

>If you don't understand what is happening from that level, you will never understand what is going on in complicated frameworks. On the other someone could have said the same to your regarding assembly code and so on.