7 ms·

I'm generally weary of MS having too much influence over open source with Github and VSCode, particularly due to their history. My creep alarm went off a bit w

by skohan 5y ago

I'm generally weary of MS having too much influence over open source with Github and VSCode, particularly due to their history. My creep alarm went off a bit when I recently started a project to test the waters with TypeScript. I was asking on a forum how to deal with native JS dependencies without types, and he answer I got was "Are you using VSCode? It will just find the community maintained type packages for you". It seems to me that VSCode's "just click the button to solve my problem" style of UX makes it very easy for developers to become reliant on proprietary workflows without even realizing it. If one were to pursue an EEE strategy, this would not be a bad way to start.

selectodude 5y ago
> It seems to me that VSCode's "just click the button to solve my problem" style of UX makes it very easy for developers to become reliant on proprietary workflows without even realizing it. Certainly “making a better product that’s easier to use” isn’t something we should be discouraging.
- 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.
  - 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.
- thayne 5y ago
  But if typescript requires you to use a specific editor to be easy to use, that is a problem.
  - joshmanders 5y ago
    All that VSCode is doing under the hood is `npm install --dev @types/<package-name>` it is not requiring you to use VSCode to get those types.
    - Phileosopher 5y ago
      Yes, but that's an abstraction that VS Code removes. I envision, with all this no-code babble, that the future "average coder" of 10 years from now will be a click-monkey. Sadly, most people like not knowing things. I theorize that it empowers them to keep their brain free of potentially useless clutter.
      - snicker7 5y ago
        You are describing the web developer today.
        Phileosopher 5y ago
        I guess I've overestimated today's web devs. Shame on me.
- dredmorbius 5y ago
  If that also puts a single entity in charge of determining what features go into, and/or what fixes remain out of, that "better product", then there is a very real control issue. Look at the case of the Web, HTML+CSS+JS standards and specifications (Drew DeVault triggered DDoS measures simply trying to access documentation), and the inability of even G-MAFIA scale companies from being able to sustain their own independent browser engine cores (Microsoft and MSIE). Control is the ability to determine the options of others. A single entity providing an overwhelmingly appealing programmatic interface is a locus of control.
dizzy3gg 5y ago
I don’t think it actually does though, I think the defaults give you a hint to run npm i
- skohan 5y ago
  How does it know which packages to install for a given un-typed package?
  - noahtallen 5y ago
    Pretty much all community types come from a single repository with a consistent naming scheme. For example, if you use “lodash”, types are available via “@types/lodash” from DefinitelyTyped (the DT repo is now maintained by the typescript team). This is even tracked on npm. VS code can just see if “@types/$package” exists and then prompt you to add it
foldr 5y ago
VSCode is open source, so relying on it isn’t relying on something proprietary. (The standard builds do contain some closed source telemetry stuff IIRC.)
- nyanpasu64 5y ago
  When you open a Python project, the recommended Python extension is Microsoft's proprietary Python extension with Pylance which refuses to run on VSCodium or Linux distribution builds of vscode-oss. I refused to install it, so I didn't test whether you can enable the older open source LSP instead. And I couldn't find any other Python extensions sadly.
  - skohan 5y ago
    Yeah I think this is just one example of how VSCode can serve to blur the lines of what are OSS dependencies, and what are proprietary ones. It takes a certain amount of vigilance to have a truly open source development workflow on VSCode.
  - foldr 5y ago
    Ah, that is interesting. I admit that I was unaware that so many of Microsoft’s extensions were proprietary.
  - Qem 5y ago
    Related: https://www.quora.com/What-should-Microsoft-do-to-embrace-extend-and-extinguish-Python?ch=15&oid=83611133&share=2a6d4fdc&srid=u15ybb&target_type=question https://www.quora.com/What-should-Microsoft-do-to-embrace-ex...
bayindirh 5y ago
> makes it very easy for developers to become reliant on proprietary workflows without even realizing it. Most young developers don't care due to inexperience and coolness factor. As code becomes more sophisticated, build reproducibility starts to become a problem. And, Microsoft is trying to own the toolchain's strategic points this time, making reproducing a build almost impossible without their tools.
- skohan 5y ago
  Yes exactly. And a lot of this stuff is open-in-name-only. Like I tried to implement an LSP for a language I am working on using Sublime and nvim as test benches, and the documentation is so bad and some of the interfaces are so convoluted that it seems like it's basically impossible to do without starting with their VSCode starter project or reverse-engineering an exiting LSP. And with the push towards remote development, I can see things moving toward a world where the default is not even running things locally. Lines get blurred, and sooner or later you're depending on proprietary Azure services without even realizing it.
  - bayindirh 5y ago
    On the other hand, Eclipse is still steadily improving. They're already very good in remote development. Lately they've implemented "build into docker". Concerning containers are a more open technology (many runtimes, open standards, etc.), there are still very good real IDEs with very rich features. Moreover, Eclipse has LSP support too. Maybe these should be made more visible.
    - skohan 5y ago
      How is eclipse doing in terms of performance these days? I used it maybe 10 years ago for some C++ and Java development, and it was quite capable, but it had the feeling of being a lurching behemoth.
      - bayindirh 5y ago
        It's much faster now. It's starting in ~10 seconds flat, and it's using less memory than an Electron app. I use it for C++, XML and python mostly.
mattferderer 5y ago
That's been a huge & awesome improvement in VS Code & Visual Studio with package managers. I think there are plenty of items to be worried about but I don't think this is one. It's a nice feature. I say this as someone who had to search through a crazy large GitHub repository of community Types back in the day all the time. Then you end up having to send some PRs & wait for them to get approved if you hope to use the types in a larger team or as part of a build process. You could also create your own fork until they're approved & then go back & update the package.json.

by skohan 5y ago

selectodude 5y ago

> It seems to me that VSCode's "just click the button to solve my problem" style of UX makes it very easy for developers to become reliant on proprietary workflows without even realizing it. Certainly “making a better product that’s easier to use” isn’t something we should be discouraging.

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.
- 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.
thayne 5y ago
But if typescript requires you to use a specific editor to be easy to use, that is a problem.
- joshmanders 5y ago
  All that VSCode is doing under the hood is `npm install --dev @types/<package-name>` it is not requiring you to use VSCode to get those types.
  - Phileosopher 5y ago
    Yes, but that's an abstraction that VS Code removes. I envision, with all this no-code babble, that the future "average coder" of 10 years from now will be a click-monkey. Sadly, most people like not knowing things. I theorize that it empowers them to keep their brain free of potentially useless clutter.
    - snicker7 5y ago
      You are describing the web developer today.
      - Phileosopher 5y ago
        I guess I've overestimated today's web devs. Shame on me.
dredmorbius 5y ago
If that also puts a single entity in charge of determining what features go into, and/or what fixes remain out of, that "better product", then there is a very real control issue. Look at the case of the Web, HTML+CSS+JS standards and specifications (Drew DeVault triggered DDoS measures simply trying to access documentation), and the inability of even G-MAFIA scale companies from being able to sustain their own independent browser engine cores (Microsoft and MSIE). Control is the ability to determine the options of others. A single entity providing an overwhelmingly appealing programmatic interface is a locus of control.

dizzy3gg 5y ago

I don’t think it actually does though, I think the defaults give you a hint to run npm i

skohan 5y ago
How does it know which packages to install for a given un-typed package?
- noahtallen 5y ago
  Pretty much all community types come from a single repository with a consistent naming scheme. For example, if you use “lodash”, types are available via “@types/lodash” from DefinitelyTyped (the DT repo is now maintained by the typescript team). This is even tracked on npm. VS code can just see if “@types/$package” exists and then prompt you to add it

foldr 5y ago

VSCode is open source, so relying on it isn’t relying on something proprietary. (The standard builds do contain some closed source telemetry stuff IIRC.)

nyanpasu64 5y ago
When you open a Python project, the recommended Python extension is Microsoft's proprietary Python extension with Pylance which refuses to run on VSCodium or Linux distribution builds of vscode-oss. I refused to install it, so I didn't test whether you can enable the older open source LSP instead. And I couldn't find any other Python extensions sadly.
- skohan 5y ago
  Yeah I think this is just one example of how VSCode can serve to blur the lines of what are OSS dependencies, and what are proprietary ones. It takes a certain amount of vigilance to have a truly open source development workflow on VSCode.
- foldr 5y ago
  Ah, that is interesting. I admit that I was unaware that so many of Microsoft’s extensions were proprietary.
- Qem 5y ago
  Related: https://www.quora.com/What-should-Microsoft-do-to-embrace-extend-and-extinguish-Python?ch=15&oid=83611133&share=2a6d4fdc&srid=u15ybb&target_type=question https://www.quora.com/What-should-Microsoft-do-to-embrace-ex...

bayindirh 5y ago

> makes it very easy for developers to become reliant on proprietary workflows without even realizing it. Most young developers don't care due to inexperience and coolness factor. As code becomes more sophisticated, build reproducibility starts to become a problem. And, Microsoft is trying to own the toolchain's strategic points this time, making reproducing a build almost impossible without their tools.

skohan 5y ago
Yes exactly. And a lot of this stuff is open-in-name-only. Like I tried to implement an LSP for a language I am working on using Sublime and nvim as test benches, and the documentation is so bad and some of the interfaces are so convoluted that it seems like it's basically impossible to do without starting with their VSCode starter project or reverse-engineering an exiting LSP. And with the push towards remote development, I can see things moving toward a world where the default is not even running things locally. Lines get blurred, and sooner or later you're depending on proprietary Azure services without even realizing it.
- bayindirh 5y ago
  On the other hand, Eclipse is still steadily improving. They're already very good in remote development. Lately they've implemented "build into docker". Concerning containers are a more open technology (many runtimes, open standards, etc.), there are still very good real IDEs with very rich features. Moreover, Eclipse has LSP support too. Maybe these should be made more visible.
  - skohan 5y ago
    How is eclipse doing in terms of performance these days? I used it maybe 10 years ago for some C++ and Java development, and it was quite capable, but it had the feeling of being a lurching behemoth.
    - bayindirh 5y ago
      It's much faster now. It's starting in ~10 seconds flat, and it's using less memory than an Electron app. I use it for C++, XML and python mostly.

mattferderer 5y ago

That's been a huge & awesome improvement in VS Code & Visual Studio with package managers. I think there are plenty of items to be worried about but I don't think this is one. It's a nice feature. I say this as someone who had to search through a crazy large GitHub repository of community Types back in the day all the time. Then you end up having to send some PRs & wait for them to get approved if you hope to use the types in a larger team or as part of a build process. You could also create your own fork until they're approved & then go back & update the package.json.