8 ms·

I think there's a difference between giving you powerful, easy to use tools to solve your problems with, and solving your problems for you.

by skohan 5y ago

rg111 5y ago
They are not forcing you to use their solution. You can go your always go your own way. I am primarily a vim user with VS Code as my secondary editor. I have never ever used their one-click solutions. I have seen someone choosing "Yes" to everything VS Code said after installation, and in no time their machine was filled with bloat that they would never ever need. But I see this as a good thing. It is making programming set up easier for the uninitiated, which is good.
- throwawayboise 5y ago
  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.
- skohan 5y ago
  See I disagree that it's a good thing. I think accessibility is a good thing, but I would rather see it in the form of better development stacks from the ground up. Just building more tooling to cover up pain points by wrapping them in more and more layers of bloat is just making a mess. You wind up needing a super complex system to do simple things, which nobody really understands, and which uses a ton of unnecessary resources. If you extend that strategy ad infinitum, you need Moore's Law to persist just to keep performance stable while running more and more layers of VSCode plugins. I also don't necessarily think some barriers to entry are always a bad thing. Things like notebooks are great for giving people access to a simple programming environment which is easy to set up. But if someone is going to be committing code to a serious project I'm working on, I don't mind if they have to know enough about computers to at least run a few commands in the terminal.
  - sailingparrot 5y ago
    It seems to be me you are arguing against the very nature of complex systems, and the way we have built the entire computing stack for the last 80 years. Lower level technologies need to be more flexible to allow usage in many different cases. On top of that we build different abstractions that are suitable for only a restricted number of uses cases, but that make them much simpler to think about and work with. By thinking at this higher level we are able to build much more complex logics than we would have before. I certainly wouldn't want to be stuck in a world where we still have to do everything in assembly because we were too afraid to embrace the compiler.
    - skohan 5y ago
      I'm not against abstraction in principal, but in my opinion it should be intentional and measured. Progress isn't only about building and endlessly taller stack of abstractions such that we eventually can't see the computer underneath. Sometimes it's about looking at the stack we have, and building a smaller and smarter one based on the lessons we learned along the way.
coldtea 5y ago
Yes, in the sense that "solving your problems for you" sounds even better.
- skohan 5y ago
  The problem is in becoming dependent on a toolchain you don't understand, and couldn't be productive without.
jolux 5y ago
Not at the margin, no. If you can solve a problem by clicking a button, why the hell would you spend more time doing it any other way? Some sort of principle? Seems poorly justified.
- yissp 5y ago
  It should still be possible to solve the problem manually, though. Inevitably someone will run into some special case where clicking the button doesn't work and more control is needed.
  - jolux 5y ago
    Arguments that more powerful tools should exist are not arguments that having a button for things is bad. It would be better if more things were just buttons.
- kovac 5y ago
  If they know how that btn click solves the problem, then that's fine. But if they are an engineer and they don't know what the btn does, then they aren't really an engineer in that sense. While that btn click may help them solve that problem, knowing how that works is important to motivate solutions for other problems that are analogous to it which is the job of an engineer. If they're an enduser, btn click is exactly what they should use. If they are an engineer, and clicking btns is all they know, then they are going to be a very limited engineer. This too is fine and there is a place for that. But, if such an engineer starts to think that they are a great engineer because they solve all the problems quickly whenever there are btns, they are going to be a liability for teams when there aren't any btns to click. Because they are going to be too arrogant to listen to those who might know how to solve them which aren't necessarily btn clicks (because to them all solutions must be btn clicks). You see, it's more than a matter of principle. It's about the calibre of the engineer you want to produce.
  - jolux 5y ago
    This is a whole chain of assumptions not rooted in anything I said. I'm not saying you don't need to learn anything. I'm saying there's no sense in making trivial tasks harder than they need to be. Of course you need to understand how to fix problems when there isn't a button to click. That doesn't mean more buttons to fix things is bad.

I think there's a difference between giving you powerful, easy to use tools to solve your problems with, and solving your problems for you.

by skohan 5y ago

I think there's a difference between giving you powerful, easy to use tools to solve your problems with, and solving your problems for you.

rg111 5y ago

They are not forcing you to use their solution. You can go your always go your own way. I am primarily a vim user with VS Code as my secondary editor. I have never ever used their one-click solutions. I have seen someone choosing "Yes" to everything VS Code said after installation, and in no time their machine was filled with bloat that they would never ever need. But I see this as a good thing. It is making programming set up easier for the uninitiated, which is good.

throwawayboise 5y ago
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.
skohan 5y ago
See I disagree that it's a good thing. I think accessibility is a good thing, but I would rather see it in the form of better development stacks from the ground up. Just building more tooling to cover up pain points by wrapping them in more and more layers of bloat is just making a mess. You wind up needing a super complex system to do simple things, which nobody really understands, and which uses a ton of unnecessary resources. If you extend that strategy ad infinitum, you need Moore's Law to persist just to keep performance stable while running more and more layers of VSCode plugins. I also don't necessarily think some barriers to entry are always a bad thing. Things like notebooks are great for giving people access to a simple programming environment which is easy to set up. But if someone is going to be committing code to a serious project I'm working on, I don't mind if they have to know enough about computers to at least run a few commands in the terminal.
- sailingparrot 5y ago
  It seems to be me you are arguing against the very nature of complex systems, and the way we have built the entire computing stack for the last 80 years. Lower level technologies need to be more flexible to allow usage in many different cases. On top of that we build different abstractions that are suitable for only a restricted number of uses cases, but that make them much simpler to think about and work with. By thinking at this higher level we are able to build much more complex logics than we would have before. I certainly wouldn't want to be stuck in a world where we still have to do everything in assembly because we were too afraid to embrace the compiler.
  - skohan 5y ago
    I'm not against abstraction in principal, but in my opinion it should be intentional and measured. Progress isn't only about building and endlessly taller stack of abstractions such that we eventually can't see the computer underneath. Sometimes it's about looking at the stack we have, and building a smaller and smarter one based on the lessons we learned along the way.

coldtea 5y ago

Yes, in the sense that "solving your problems for you" sounds even better.

skohan 5y ago
The problem is in becoming dependent on a toolchain you don't understand, and couldn't be productive without.

jolux 5y ago

Not at the margin, no. If you can solve a problem by clicking a button, why the hell would you spend more time doing it any other way? Some sort of principle? Seems poorly justified.

yissp 5y ago
It should still be possible to solve the problem manually, though. Inevitably someone will run into some special case where clicking the button doesn't work and more control is needed.
- jolux 5y ago
  Arguments that more powerful tools should exist are not arguments that having a button for things is bad. It would be better if more things were just buttons.
kovac 5y ago
If they know how that btn click solves the problem, then that's fine. But if they are an engineer and they don't know what the btn does, then they aren't really an engineer in that sense. While that btn click may help them solve that problem, knowing how that works is important to motivate solutions for other problems that are analogous to it which is the job of an engineer. If they're an enduser, btn click is exactly what they should use. If they are an engineer, and clicking btns is all they know, then they are going to be a very limited engineer. This too is fine and there is a place for that. But, if such an engineer starts to think that they are a great engineer because they solve all the problems quickly whenever there are btns, they are going to be a liability for teams when there aren't any btns to click. Because they are going to be too arrogant to listen to those who might know how to solve them which aren't necessarily btn clicks (because to them all solutions must be btn clicks). You see, it's more than a matter of principle. It's about the calibre of the engineer you want to produce.
- jolux 5y ago
  This is a whole chain of assumptions not rooted in anything I said. I'm not saying you don't need to learn anything. I'm saying there's no sense in making trivial tasks harder than they need to be. Of course you need to understand how to fix problems when there isn't a button to click. That doesn't mean more buttons to fix things is bad.