4 ms·

> glue together some massively bloated thing that they have absolutely no understanding of Welcome to the world of npm and supply-chain hell

busterarm 3y ago
Java and Golang aren't any different.
quectophoton 3y ago
To be fair, I would also say the mainstream IDEs have contributed to this situation to a certain extent, since they lower barrier of entry. That's a very good thing, but also sometimes bad. Here's what I mean. There's a difference between: * Using an IDE knowing what you want to do but you just like the convenience. You know what the IDE is doing for you, but you want your tool to do it for you quickly and get out of the way. If the IDE does something you don't know, you try to learn what this was. * Using an IDE because you literally can't work without one. Not knowing your programming language and depending 100% on autocomplete to do most stuff. Not even knowing how to write the files that the IDE automatically updates when doing certain things. It's a subtle difference, but the former is more likely to leave better comments in a web-based code review ("pull request") than the latter. And if a project consists only of the latter type, it's unlikely that there will be comments like: * "Use this other class with the same name but different package because this one is buffered" (because depending on autocomplete without knowing the language prevented them from even caring about which import to use, or the difference between those, as long as it works). * "Would this change affect this other file that's not in the PR but calls this function a thousand times per request?" (because not knowing their own projects general structure due to depending on their IDE for navigation, so they're more likely to NOT notice a file that's not mentioned in the PR). So if a project has only people that depend on an IDE (instead of using an IDE for convenience), it's easy to end up with stuff that technically works, but copies 40MB of strings around multiple times, and thrashes your performance due to reading one character at a time without buffering. Granted, this technically is not related to IDEs, but in my experience (emphasis on "my"), most of the people I've worked with that use an IDE, are of the "can't program without it" type, and not the "I use it because it's convenient" type. Not all of them. But most. Even if there's a learning curve at play here, I'd say there's usually overlap between "use IDE because convenient" and "actually bothering to put an effort into learning". I understand this is an inevitable consequence of lowering the barrier of entry and making programming more accessible, and it doesn't matter if we're talking about npm, IDEs, programming languages, or anything.
- doix 3y ago
  > I understand this is an inevitable consequence of lowering the barrier of entry and making programming more accessible, and it doesn't matter if we're talking about npm, IDEs, programming languages, or anything. Pretty much this. Anybody new to the field will be using an IDE, it's extremely unlikely that someone new will be using vim/emacs. So IDE users will be a mix of newbies and experienced people, but since the field grew so much in recently, the number of newbies using IDEs will outnumber the experienced people using them. In contrast, people using vim/emacs will consist mostly of people with a lot of experience at this point. So the average IDE user will be less experienced than a non-IDE user, but I don't think it has anything to do with the fact that they are using an IDE. I wouldn't attempt to pre-judge anyone's ability based on if they use an IDE or not.
  - JohnFen 3y ago
    > I wouldn't attempt to pre-judge anyone's ability based on if they use an IDE or not. Neither would I, but I will certainly judge them as lacking if they can't write a nontrivial program without using code completion or looking things up on SO/Github/etc.
    - lsaferite 3y ago
      > without using code completion or looking things up on SO/Github/etc. Does this arbitrary bar extend to language and library documentation as well?
      - JohnFen 3y ago
        Of course not, and the bar isn't arbitrary. That you ask this tells me that I was insufficiently clear as to my stance. My stance is that programmers should understand how to write programs, not just copy/paste them together.
        lsaferite 3y ago
        Thanks for the clarification. I certainly have way too much in my head to remember every nuance of several languages. As such, I lean heavily on multiple sources of external documentation to help me recall the specifics. That being said, this would in no way replace actual software development expertise, so I agree with your clarified stance. I find using a good IDE with code completion and navigation is essential to efficient use of my time. I _also_ use vi constantly and perform most every other operation from the command line. I know I can get the same from properly setting up vi with the right plugins, but I find the ergonomics less appealing for my habits.
intelVISA 3y ago
good time for APTs though!

busterarm 3y ago

Java and Golang aren't any different.

quectophoton 3y ago

To be fair, I would also say the mainstream IDEs have contributed to this situation to a certain extent, since they lower barrier of entry. That's a very good thing, but also sometimes bad. Here's what I mean. There's a difference between: * Using an IDE knowing what you want to do but you just like the convenience. You know what the IDE is doing for you, but you want your tool to do it for you quickly and get out of the way. If the IDE does something you don't know, you try to learn what this was. * Using an IDE because you literally can't work without one. Not knowing your programming language and depending 100% on autocomplete to do most stuff. Not even knowing how to write the files that the IDE automatically updates when doing certain things. It's a subtle difference, but the former is more likely to leave better comments in a web-based code review ("pull request") than the latter. And if a project consists only of the latter type, it's unlikely that there will be comments like: * "Use this other class with the same name but different package because this one is buffered" (because depending on autocomplete without knowing the language prevented them from even caring about which import to use, or the difference between those, as long as it works). * "Would this change affect this other file that's not in the PR but calls this function a thousand times per request?" (because not knowing their own projects general structure due to depending on their IDE for navigation, so they're more likely to NOT notice a file that's not mentioned in the PR). So if a project has only people that depend on an IDE (instead of using an IDE for convenience), it's easy to end up with stuff that technically works, but copies 40MB of strings around multiple times, and thrashes your performance due to reading one character at a time without buffering. Granted, this technically is not related to IDEs, but in my experience (emphasis on "my"), most of the people I've worked with that use an IDE, are of the "can't program without it" type, and not the "I use it because it's convenient" type. Not all of them. But most. Even if there's a learning curve at play here, I'd say there's usually overlap between "use IDE because convenient" and "actually bothering to put an effort into learning". I understand this is an inevitable consequence of lowering the barrier of entry and making programming more accessible, and it doesn't matter if we're talking about npm, IDEs, programming languages, or anything.

doix 3y ago
> I understand this is an inevitable consequence of lowering the barrier of entry and making programming more accessible, and it doesn't matter if we're talking about npm, IDEs, programming languages, or anything. Pretty much this. Anybody new to the field will be using an IDE, it's extremely unlikely that someone new will be using vim/emacs. So IDE users will be a mix of newbies and experienced people, but since the field grew so much in recently, the number of newbies using IDEs will outnumber the experienced people using them. In contrast, people using vim/emacs will consist mostly of people with a lot of experience at this point. So the average IDE user will be less experienced than a non-IDE user, but I don't think it has anything to do with the fact that they are using an IDE. I wouldn't attempt to pre-judge anyone's ability based on if they use an IDE or not.
- JohnFen 3y ago
  > I wouldn't attempt to pre-judge anyone's ability based on if they use an IDE or not. Neither would I, but I will certainly judge them as lacking if they can't write a nontrivial program without using code completion or looking things up on SO/Github/etc.
  - lsaferite 3y ago
    > without using code completion or looking things up on SO/Github/etc. Does this arbitrary bar extend to language and library documentation as well?
    - JohnFen 3y ago
      Of course not, and the bar isn't arbitrary. That you ask this tells me that I was insufficiently clear as to my stance. My stance is that programmers should understand how to write programs, not just copy/paste them together.
      - lsaferite 3y ago
        Thanks for the clarification. I certainly have way too much in my head to remember every nuance of several languages. As such, I lean heavily on multiple sources of external documentation to help me recall the specifics. That being said, this would in no way replace actual software development expertise, so I agree with your clarified stance. I find using a good IDE with code completion and navigation is essential to efficient use of my time. I _also_ use vi constantly and perform most every other operation from the command line. I know I can get the same from properly setting up vi with the right plugins, but I find the ergonomics less appealing for my habits.

intelVISA 3y ago

good time for APTs though!