Ich komme da wieder mit BASIC.
QBASIC und Visual Basic (6.0) hatten beides. Einen Zeileninterpreter und einen Compiler.
In der Entwicklungsumgebung wird halt der Zeileninterpreter benutzt. Zusätzlich hat man die Möglichkeit, mit einem Compiler eine Anwendung zu compilileren.
Allerdings benötigt ein Programmierer nicht unbedingt einen Zeileninterpreter. Bei größeren Projekten wird eh alles in Modulen aufgeteilt. Ein Programmerierer arbeitet dann nur an seinem derzeiten Modul. Er braucht somit gar nicht die anderen Module seiner Kollegen, um sein Modul zu testen. Auch wäre es ziemlich unsinnig, immer das komplette Programm zu starten, nur um eine Sache zu testen. Stell dir vor, du arbeitest an einer Office Software bastelst an der Schnittstelle für den Drucker. Da wäre es doch idiotisch, immer wieder die Office Software zu starten und dann im Menü durchzuklicken, bis du endlich die Druckereinstellung erreichst. Da schreibt man kurz ein kleines Testprogramm, mit dem man dann sein Modul testet. Auch gibt es sog. Unit Tests, die automatisiert ein Programm testen können.
Erst zum Schluss, wenn alles fertig ist, werden die Module zusammengesetzt und evtl. noch ein wenig angepasst. Dann geht es in die sog. Alpha Phase.
Ein Compiler übersetzt ja auch nicht bei jedem Compilieren das Programm komplett neu. Er merkt schon, wenn bestimmte Programmteile sich nicht verändert haben. Dann werden die Teile auch nicht neu compiliert. Also dauert es nur beim ersten Mal ein wenig länger. Wenn man dann nur eine Zeile ändert, übersetzt er dann auch nur diese Zeile neu.
Ein Zeileninterpreter hat auch das Problem mit der Geschwindigkeit. Oftmals will man schon während der Entwicklung feststellen, ob ein Algorithmus schnell genug ist, wenn man einen komplexen Algorithmus basteln muss. Da kann es schon vorkommen, dass der Zeileninterpreter viel zu langsam ist.