You can learn programming much better with a high-quality compiled language that has excellent debugging support, compared to an immature toy interpreted language which has poor debugging support (e.g. interpreter just dies with segfault, or a message that you have some error somewhere in the script).
There is a potential for interpreted languages to make better learning environments because they can have better introspection, debugging and interactivity. However, implementing those things takes work, and you may find that many developers of interpreted languages duck out of them, because usually those people are after the primary result (the language interpreter executes correct programs as fast as possible) and neglect those other things, which are more difficult to do (backtraces, breakpoints, single stepping, etc.)
For instance, most Unix shells have no debugging means, even though they are interpreted. (There is a Bash debugger written in bash, but it's too slow to be useful.)
Awk interpreters (GNU gawk and classic ones) are another example. No useful debugging, and no "REPL" (read-eval-print interactive loop). You're better off doing C or C++ where you can use a debugger like gdb to step through the code.
So whatever tools you are looking at for learning, you have to evaluate them on a case by case basis, not based on what category they fall into.