The criticism doesn't really apply to Python and JavaScript though. Not to say that Python and JavaScript don't have their own issues, but dependence on an IDE tightly coupled to the language semantics is not one of them.

I can't speak for Python but the JavaScript community has been investing heavily in TypeScript, and the desire for a more integrated IDE experience is a huge driver for that growth.

Definitely true, though I think the problem is less severe with regard to TS because open source language-servers afford TypeScript IDE features universal availability which is not the case in JVM land. Also, consider the trend towards Kotlin in the Java world where a part of Jetbrain's business model relies on the fact that they created and maintain the language while also selling the IDE that makes the language practical to use (Kotlin being an amazing language notwithstanding).

Typescript: Putting the Java™ in Javascript

Last time I worked with Python or JavaScript I was using a very basic text editor. I'm not sure I'd be quite so brave with Java.

I don't know about JS, but my python work is done in a repl like ipython in conjunction with a text editor. It gets me half of what I wanted from an IDE.

I confirm this. I rename classes and move them around, and without a refactoring tool that renames files and changes imports automatically, life would be very hard. Before refactoring tools got to this level, I was running pytest to see what import statements got affected during my refactors.

Uh. Question. Why are you executing tests to get the compiler to tell you what was effected instead of doing a top level recursive grep to identify any classes or configs with an explicit symbolic dependency?

I mean, you get the same result, sure, but I find I can hardly ever rely on test coverage alone as an accurate safety net to clearly indicate whether I've reached an actual stopping point for a full refactor.

This is one of the ways in which Java excels, in that that loop is fully accommodated for in most major IDE's.

You can still get caught by surprise at runtime, but I've found that for a strongly typed language like Java, the syntax, and necessity of boilerplate makes most bugs obvious until you start getting overly dependent on frameworks you don't understand.

I am not executing tests to perform import error detection. That was before refactoring tools got better. I was executing tests to check for import errors because it doesn't rely on full coverage on every method. It relies on all modules being imported by tested modules. That is easy to do even if you are too lazy to test every module. Just put an empty test function in all of them and pytest will detect them recursively. Given all that, I would avoid executing manual grep commands. However, you have a valid point for configuration files. Especially log configs need to be checked.

Would the language described in the article (Unitliy) be harder to refactor? Why?

Python is not static typed, it won’t refactor as easily.