Wpływ rodzaju translacji na język programowania

Witam,
Szukam odpowiedzi na pytanie zawarte w temacie. Wiadomo, że mam dwa główne rodzaje translacji:

• kompilację
• interpretację
• plus oczywiście dodatkowo coś pomiędzy - czyli wirtualną maszynę javy, oraz .NET.
  Jednak jakie możliwości dają nam interpretery z punktu widzenia programisty? Np. w Php zmienne nie muszą mieć z góry określonych typów. To jedna z cech interpreterów wnikająca z jego zasadzi działania. Znacie jeszcze jakieś inne różnice z punktu widzenia pisania samego kodu (nie chodzi mi o zasadzę działania, mobilność, czy czas wykonywania)?

wydaje mi się, że to czy typizacja jest silna czy słaba nie ma związku z tym czy język jest kompilowany czy interprtowany, tylko jest to cecha konkretnego języka...

Adam napisał(a)

Np. w Php zmienne nie muszą mieć z góry określonych typów. To jedna z cech interpreterów wnikająca z jego zasadzi działania.

Istnieją statycznie typowane języki interpretowane jak i dynamicznie typowane języki kompilowane, w tym do kodu natywnego. PHP jest "c**** typowany" (nawet obiekty są zamaskowanymi stringami) bo to pierwotnie nie był język programowania, jedynie prymitywny system szablonów + aplikacja w Perlu/C. Rozdmuchiwanie systemu szablonów do postaci języka programowania nie mogło skończyć się dobrze.

notexists ma rację. Java, ECMAScript, Python, itp startowały jako języki tylko i wyłącznie interpretowane, a dzisiaj mają maszyny wirtualne (Sun HotSpot, Google V8, PyPy).

Generalnie sprawa jest taka, że łatwo zrobić (tzn w wielu przypadkach, nie liczę np C++) kompilator do języka statycznie typowanego oraz trudno zrobić maszynę wirtualną (kompilującą równolegle do wykonywania) do języka dynamicznie typowanego.

Zapewne macie rację, a o php mam to samo zdanie, ale powtarzam pytanie zadane w temacie:

• Jakie możliwości programistyczne dają nam interpretery, na które na pozwolą nam kompilatory i odwrotnie? Poza mobilnością i czasem działania, co jest oczywiste.

Różnic w możliwościach nie powinno być żadnych. Różnicę za to robi forma dystrybucji programu - dystrybując kod źródłowy czy kod pośredni (zawierający odpowiednio dużo informacji) jesteśmy go w stanie poprzerabiać za pomocą specjalizowanych narzędzi. Z binarkami natywnymi jest to często niemożliwe, gdyż z kodu natywnego zwykle (tzn w binarkach produkcyjnych, a nie do debugowania) usuwa się informacje niepotrzebne przy wykonywaniu kodu.

Rozumiem, że interpreter patrzy na kod linia po linii a kompilator na cały plik i właściwie poza czasem obliczeniowym nie powstają inne bariery, jeśli piszemy dla tej samej maszyny/urządzenia?
Czytałem że maszyna javy interpretuje kod (oczywiście może być wspierana przez JIT), podczas gdy CLR kompiluje go. Dlaczego więc Microsoft nie poszedł tropem twórców JRE?

MS korzysta z techniki AOT - Ahead Of Time Compiling, tzn umieszcza w pliku binarkę natywną + bajtkod. Binarka jest po to, aby przyspieszyć ładowanie programu. JVM na początku interpretuje kod, równocześnie zbierając dane do profilowania (te dane zresztą cały czas chyba zbiera i przeprofilowuje jak trzeba), a interpretacja jest nawet kilkadziesiąt razy wolniejsza. Instrukcja z bajtkodu jest kompilowana dopiero gdy zostanie wykonana odpowiednią ilość razy (np 1000 razy albo 100000 razy, zależy od konfiguracji, czasochłonności kompilacji, itd).

Wadą rozwiązania MS jest większy rozmiar plików wykonywalnych oraz to, że czasem te binarki są niepotrzebne zupełnie użytkownikowi - załóżmy, że w pliku wykonywalnym jest bajtkod + kod natywny na x86 i x64, a użytkownik odpala program na PowerPC, to wtedy te binarki są bezużyteczne i tylko marnują miejsca na dysku/ pasmo przesyłowe sieci komputerowej. Z drugiej strony .NET jest używany praktycznie tylko i wyłącznie na x86 i x64, więc można w miarę bezpiecznie zawęzić się do tych architektur.

Dziękuję za wszystkie odpowiedzi.