On Wed, 9 Aug 2017 13:31:16 -0700 (PDT), "M.M." <m...@g...com>
wrote:
> Jeśli zawęzimy tylko do przypadków sensownych, to i podzia=
> ł na
> kompilowane i interpretowane ma sens, bo inaczej projektuje się
> język pod kompilowanie i inaczej pod interpretowanie.


Jeszcze raz. Tym razem będzie nie o rowerach.

Setki lat uważano że elektryczność bursztynu i magnetyzm to zupełnie
dwie różne rzeczy. A tu nagle kaboom: Amper, Faraday i Maxwell. I
nagle nie ma możliwości oddzielenia magnetyzmu od elektryczności. Jak
nie wierzysz, sprawdź rachunki młodego Einsteina. Dlatego upieranie
się że potarty bursztyn wytwarza wyłącznie pole elektrostatyczne jest
błędem - wystarczy inny układ odniesienia i będzie pole magnetyczne.

Przez kilkadziesiąt lat języki dzielone na kompilowane i
interpretowane. Ale to nie ma dziś sensu. Bo język to gramatyka, a
nie kompilator/interpreter. Ba! Można wyobrazić sobie język
programowania który nie ma jeszcze implementacji. Np. na jakimś
wczesnym etapie projektowania. Albo taki jak w podręczniku Knutha.

Ok. Może być tak, że coś da się łatwo zrobić interpreterem, a w kij
trudne przy kompilacji do natywnego. Ale nie ma znaczenia
trudne-łatwe. Przykładem nowe maszyny Javy dla Androida. Mają nie
tylko robić JIT, ale także generować natywny. No łatwe to nie jest.
Ale biorąc po uwagę tzw. potrzeby ludzkości ma to sens.


Tyle że bebechy implementacji to akurat nic a nic nie powinny wpływać
na składnię. Bo język przyzwoicie wysokiego poziomu to nie Asembler.

Kolejna rzecz to features które nie są potrzebne w pewnym kontekście,
czy przy pewnym stylu programowania. Na przykład - z mojego punktu
widzenia - operator += jest redundantny. Ale nie obrażam się na
języki w których on jest. Podobnie wskaźniki. Można lubić. Można nie
lubić. Jednak domaganie się aby nie było ich w C to trochę spóźnione
jest. Gdzieś tak o pół stulecia.