3 ms·
> Nearly all the programmers out there Ah yes. Those very precious programmers, who can’t be expected to configure a non-proprietary tool, because they are too
by xk_id 3y ago
> Nearly all the programmers out there
Ah yes. Those very precious programmers, who can’t be expected to configure a non-proprietary tool, because they are too busy making another dopaminergic app at their corporate job. The medium is the message, I guess.
- kamaal 3y agoTwo options- 1. Solve the problem using a tool. 2. Solve problems that a tool has. It should not be a surprise people pick 1.
- iLemming 3y agoEvery single tool has problems. There's no application that has no bugs, no limitations. There's nothing wrong with wanting to use specialized tools to perform specific tasks and most people choose to do that. The main point you're missing is that at some point in your career, inevitably, you'll collect so many tools in your toolbelt that you might become overwhelmed. There are tools for debugging, searching, formatting, converting, documentation, device control, synchronization, networking, databasing, containerization, security, etc. Most tools operate with data. And most of the time that data doesn't stay in the context of the same tool - you have to pass it somewhere else. The common approach of unexperienced devs is to become "a copy-n-paste programmer". No, not someone who grabs the code from StackOverflow. I don't know if SO has much value in 2024, I stopped using it a source of valuable knowledge long ago, I do occasionally find clues there, rarely complete answers, perhaps the complexity of my questions has changed, but I'm going off the rails here... So, anyway, at some point you'd become more efficient in enabling tools to exchange data. Experienced Vimmers use terminal tools with piping, etc. Some of them develop really neat and powerful mini-automation workflows. Emacs is another amalgamating medium that can be used for the same purpose. People with shallow understanding of Emacs often get grumpy for Emacsers wanting to do "everything in Emacs". Matter of fact, it's not about doing everything in Emacs, but rather doing everything _through_ Emacs. And that can be quite effective too. So tell me, why is it so difficult for you to accept that Emacs is just another tool, not a replacement for some other specialized single-purpose tool, and that it is quite good at what it does - that is to work as a "glue" to orchestrate many other tools? Maybe VSCode is truly better in that aspect than Emacs. I don't know. I have yet to find out. So far, people have been claiming that it just works better as a code editor in specific languages, but I haven't heard it being used as a "tactical unionizer" that can talk to many other tools in a way that Emacs does.