[Ozzie_osman]

There's a common argument from craftsmen embedded in here. When something decreases accessibility of something difficult, the people who already know how to do the difficult thing criticize it, because from their eyes, it brings the average quality down. But ease and accessibility always win.

This goes for IDEs, programming languages, frameworks, etc. Think of a language like PHP, which made it so easy to code that countless shitty websites were made, ridden with spaghetti code and security issues. But, I was amongst probably tens of thousands of script kiddies who cut our teeth on PHP and eventually learned how to "properly" build web products. My first startup's MVP was a giant functions.php file and a bunch of templates, FTP'd onto a VPS. Probably wouldn't have gotten into it if instead I had needed to learn something like C++ or Java.

Yes, making something easier to do decreases the quality on average. But even skilled professionals can benefit from better accessibility. And it's hard to quantify the full benefit to those who wouldn't have been able to do the work without the lower barrier.

Personally, yes, I know if I blindly use Github Copilot I'll prob write some shitty code. But it just makes everything easier/faster to do. So I use it and put in a tiny bit of extra effort to make sure I'm not abusing it. And it's game-changing. I'm also sure tools like Copilot will improve at a pace that is much faster than people expect. It will recognize deprecated calls, misused calls, errors, security holes, etc.

[nyanpasu64]

Rust's Send/Sync made multithreading easier, teaches people to write proper multithreaded code, and results in more reliable programs with less data races and race conditions. Rust's dependency managers makes dependencies easier, teaches people to add dependencies and transitive dependencies, and results in programmers not understanding their own programs.

I think that building tools to teach better programming (eg. teaching memory-safe programming or safe languages, teaching patterns immune to SQL injection or parsing exploits) is a great thing. But given the choice between bad and no code, I feel that it's almost better for people to not complete projects, than to release code with serious functional errors (memory leaks and segfaults and dozens of runtime race conditions that each show up every month or so, requiring herculean effort to debug, or more often go unsolved and haunt users indefinitely) or security defects (eg. https://lukeplant.me.uk/blog/posts/wordpress-4.7.2-post-mort...).

It's obviously better to teach good coding than to discourage people doing bad coding, but it's a lot harder (Send/Sync was a non-obvious innovation, and Rust required immense effort to push to 1.0 and build an ecosystem) and I don't think I can do it. And I'm opposed to the principle of trading off your understanding of a program to get more functionality from leaky abstractions (complex languages, optimizing compilers, big library trees, and GPU drivers all leak, whereas out-of-order CPUs and cache hierarchies are a mostly non-leaky abstraction).

[Ozzie_osman]

A more eloquent way of putting this: lowering a barrier to do X will result in lower average quality of X, but more of it. Usually this is good, and lower barriers win. Unless it's like lowering the barrier to becoming a surgeon or something where the risk is high.

[wrnr]

One thing I've learned over 10 years of doing this is how much code is actually required to do anything, having more expressive language is one thing but tools that can help me cram out this stuff are also appreciated.

[couchand]

One thing I've learned over more than 10 years of doing this is how much code actually should be deleted instead of fixed. Thanks for giving me a reliable source of income ;)

[lanstin]

The joke is that a new programmer is happiest when adding code and the senior programmer is happiest when removing code.