I'm relatively new to Clojure development, but I definitely don't think this is the right attitude if we want Clojure to thrive.
Developers are very opinionated about their choice of tools.
I think our answer to critics on Clojure's debugging workflows who might be using tools that don't have first-class Clojure support shouldn't be to try to convince them to ditch their existing tools and force them to use the few tools that already have first-class support for Clojure debugging. This approach of tying the debugging experience to an editor/IDE only works when your community almost exclusively uses a few de-facto IDEs like in the Java world with Eclipse/IntelliJ and in .NET with Visual Studio. This isn't really the case with Clojure's target audience, who come from all kinds of backgrounds and prefer all kinds of different tools.
Instead, I think our answer should be to try to minimize friction for new developers by allowing them to use whatever tools they prefer and still have access to a first-class Clojure debugging experience, by decoupling debugging from editors and building a standalone debugging tool that can be run without any explicit editor support, but can of course be enhanced by editor integrations (and editors can of course still choose to maintain their own debugging mechanism). This approach would be analogous to the approach taken by the JavaScript community with various browser-based debuggers, and is why we don't hear people complain about the state of JavaScript debugging very often, even though very few editors have built-in JavaScript debugging support.
> works when your community almost exclusively uses a few de-facto IDEs like in the Java world with Eclipse/IntelliJ and in .NET with Visual Studio.
According to the latest official state of Clojure survey, large majority of people use only the few best tools: almost 50% use Cider, close to 30% Cursive, and more than 10% Vim + fireplace. Those are tools that have excellent support for Clojure, including fairly good debugging experience (not sure for Vim though). Those are the de-facto IDEs, with around 90% of the market.
I agree with you: newcomers should be able to start quickly and with as little friction as possible. However, I think that it is easier to choose a well-rounded tool that everyone uses and that is already configured to work with minimum friction and start from that until you build enough skill that you can do better than that, than to insist on the tool that was created for another job and will probably lead from one landmine to another.
I do not insist; if someone disagrees with this, they are in right to do what they think is best for them, but is it Clojure's fault if the path that they chose is not as nice as the paths that 90% Clojurists prefer, especially considering that all these tools are built by volunteers and essentially provided as a gift?
Developers are very opinionated about their choice of tools.
I think our answer to critics on Clojure's debugging workflows who might be using tools that don't have first-class Clojure support shouldn't be to try to convince them to ditch their existing tools and force them to use the few tools that already have first-class support for Clojure debugging. This approach of tying the debugging experience to an editor/IDE only works when your community almost exclusively uses a few de-facto IDEs like in the Java world with Eclipse/IntelliJ and in .NET with Visual Studio. This isn't really the case with Clojure's target audience, who come from all kinds of backgrounds and prefer all kinds of different tools.
Instead, I think our answer should be to try to minimize friction for new developers by allowing them to use whatever tools they prefer and still have access to a first-class Clojure debugging experience, by decoupling debugging from editors and building a standalone debugging tool that can be run without any explicit editor support, but can of course be enhanced by editor integrations (and editors can of course still choose to maintain their own debugging mechanism). This approach would be analogous to the approach taken by the JavaScript community with various browser-based debuggers, and is why we don't hear people complain about the state of JavaScript debugging very often, even though very few editors have built-in JavaScript debugging support.