The original Pascal did compile to p-code for a virtual machine. But it was clearly a compiler because the behaviour from the users side was that of a copmiler with all source code processing up-front.

There are very few "real" interpreters out there. Almost all of them do have at least one foot in the compiler land. Either becayse they do just-in-time compilation or because they make use of some form of virtual machines or tokenizers etc.

Traditional basic interpreters did not work with any text file. They contained the line editor used to enter the program, so they tokenized the lines directly when entered. But being interpreted means it wasn't until the program was run that they would find out if a goto to line referenced a line not existing.

PHP is an example of a interpreted language, where the data is tokenized/compiled to a virtual machine one source file at a time. So gramatical error in the source file will be caught directly. But not until the code is run will there be errors that the code calls functions that are unknown or that unknown variables are accessed. And depending on how the code is written, failures to include other source files can result in errors firts when the code is run.

Interpreted languages do have advantages in "quick to start" but it really is frustrating to get all the extra runtime errors that a real compiler would hae caught instantly. Some interpreted languages have extra tools similar to lint, that can walk through the code base and try to figure out potential errors for all potential code paths, while real programs may almost never take some branches.

The big advantage allowed with many interpreted languages (and also one of their disadvantages since the correctness can't be known before the code is run) is that they can often create "self-modifying" code on-the-fly. They often have something like a "exec" function that can take a text string containing expressions or statements, and execute them as if they had been part of the original source file. So many of the interpreted languages can not be compiled fully into native code - anyone creating a JIT compiler for them must either combine the JIT compiler with the original virtual machine, or allow the JIT compiiler to create temporary binary modules that are dynamically linked in and then are thrown away after use.

With todays fast computers, we can normally get away quite fine with compiled languages - especially if we build without optimization. For a PC, where there is no "download" time needed, programs can compile and run almost instantly up to quite significant sizes. If the programs are larger, then it isn't normally the compiler that is the limit but the disk - so an SSD or RAM-disk can quicken the builds.