Tekst jest oparty na mojej prezentacji z konferencji Kariera IT. Pierwsza część wpisu jest dostępna tutaj.
Świat staje się coraz mniejszy. Wszyscy uczymy się angielskiego, a lokalne dialekty odchodzą w zapomnienie. Dlaczego wciąż upieramy się, by z komputerem rozmawiać na tyle różnych sposobów? Ile języków powinien znać programista? Od którego zacząć?
To druga część wpisu na temat współczesnych języków programowania i różnic pomiędzy nimi (pierwsza jest dostępna tutaj). W tej części mówię o różnicy pomiędzy językami kompilowanymi i interpretowanymi i tłumaczę, czym są maszyny wirtualne. Na końcu pokazuję, że języki programowania – tak samo jak języki, za pomocą których ludzie komunikują się między sobą – żyją i zmieniają się z czasem.
Kompilować czy interpretować?
Kolejny podział języków programowania opiera się na sposobie przetwarzania napisanego w nich kodu. Języki bywają dzielone na:
- kompilowane, czyli przed uruchomieniem tłumaczone na kod maszynowy właściwy danej architekturze, zapisywany w osobnym pliku, np. C++, Pascal,
- interpretowane, czyli uruchamiane bezpośrednio w oparciu o kod źródłowy, często wyposażone w interaktywne konsole, np. Perl, Ruby,
- interpretowane przez maszynę wirtualną, tj. kompilowane do kodu bajtowego, jak Java, C#.
Warto wiedzieć:
Ten sam język, w zależności od środowiska, może być kompilowany lub uruchamiany.
Potrzeba kompilacji jest nie tyle cechą języka, co środowiska, z którego korzystamy, choć w praktyce konkretne języki są z reguły konsekwentnie przetwarzane w ten sam sposób.
Oba podejścia mają swoje zalety. Kod skompilowany do postaci maszynowej będzie działał optymalnie w architekturze, dla której jest przeznaczony. Kompilator bywa sprzymierzeńcem programisty – potrafi wytknąć błędy (czasami dość złożone), zanim jeszcze uruchomisz program. Z kolei w środowisku interpretowanym (w którym de facto kolejne instrukcje są kompilowane „w locie”) możesz pozwolić sobie na więcej improwizacji i beztroskich prób bez konieczności tworzenia kompletnego, zamkniętego programu.
Skompilowana wersja tego samego programu będzie wyglądała inaczej w systemie o innej architekturze. Program interpretowany wygląda tak samo niezależnie od tego, gdzie chcemy go uruchomić (o ile celowo nie odwołujemy się elementów istniejących jedynie w konkretnym systemie operacyjnym) – to środowisko (interpreter) musi być w stanie porozumieć się z procesorem.
Jeśli popełnisz poważny błąd w linii numer 100, kompilator w ogóle nie utworzy wykonywalnej wersji programu. Środowisko interpretowane prawdopodobnie bez szemrania wykona linie 1-99 i elegancko wyłoży się na linii 100. Zdecyduj sam, która opcja jest lepsza?
Kompromis pomiędzy wspomnianymi dwoma podejściami stanowią maszyny wirtualne.
Maszyny wirtualne
Poniższy rysunek przedstawia schemat działania maszyny wirtualnej (ang. Virtual Machine, VM).
W przypadku języków z maszyną wirtualną (jak Java, C#) kod jest co prawda kompilowany, ale nie do postaci kodu maszynowego, tylko tzw. kodu bajtowego (ang. bytecode), przeznaczonego dla VM. Dzięki temu skompilowany kod zawsze wygląda tak samo i może być wdrażany w różnych systemach. Maszyna wirtualna właściwa danej architekturze (czyli np. działająca w systemie Windows) jest w stanie w locie tłumaczyć kod bajtowy do postaci kodu maszynowego – instrukcji dla procesora.
Warto wspomnieć, że niektóre maszyny wirtualne (np. JVM, czyli Maszyna Wirtualna Javy) są obecnie tak dojrzałe i wydajne, że twórcy nowych języków (jak w tym wypadku Scala, Clojure) decydują się na kompilowanie tych języków do kodu bajtowego, by skorzystać z optymalizacji wprowadzanych przez daną maszynę wirtualną.
Wydajność języka a wydajność programisty
Być może zwróciłeś uwagę na to, że kilka razy w tym wpisie pojawiły się słowa „wydajny” lub „optymalny”. Języki programowania można porównywać i w ten sposób. Ruby (czytaj: kod napisany w Ruby, uruchomiony w odpowiednim środowisku) działa wolniej niż Java, Java jest wolniejsza od C.
Skoro tak, to dlaczego więc wszyscy nie piszemy w C? Nie wolno zapomnieć o tym, że wydajności języka i wydajność programisty to dwie różne rzeczy.
Program powinien działać szybko, to jasne. Programy są jednak pisane i poprawiane przez ludzi. Ogromne znaczenie mają więc także:
- czas potrzebny do stworzenia działającego programu,
- czas potrzebny do naprawienia błędu przez autora kodu,
- czas potrzebny do naprawienia błędu przez innego programistę.
Jeśli chodzi o szybkość tworzenia programu od zera (1) – w ekstremalnej sytuacji prototyp tworzy się w jednym języku, a – jeśli pomysł chwyci – później w tle przepisuje się kod na inny, wydajniejszy język.
W kwestii naprawiania błędów (2), ale też szybkości kodowania, rozważ proszę następujące dwa fragmenty kodu.
C++
|
1 2 3 4 5 |
int *x = new int[10]; // tablica 10 elementów typu int // ... (operacje) // pora zwolnić pamięć delete[] x; |
Java
|
1 2 3 4 5 |
int[] x = new int[10]; // tablica 10 elementów typu int // ... (operacje) // nie musimy zwalniać pamięci, zajmie się tym Odśmiecacz (Garbage Collector) // ... ale nie wiadomo kiedy |
Oba przykłady robią to samo: tworzą tablicę przechowującą 10 elementów typu całkowitego. W przypadku C++ musisz ręcznie zwolnić przydzieloną pamięć. Można uznać to za zaletę – masz pełną kontrolę nad pamięcią. Jeśli wiesz, że obiekt nie będzie już potrzebny, możesz się go natychmiast pozbyć. W Javie pamięć zwolni Odśmiecacz (ang. Garbage Collector) po wykryciu, że do zmiennej nie ma już odwołań. Tyle tylko, że zrobi to, kiedy będzie mu wygodnie… Może wcale.
Z ogromną dozą pewności pozwolę sobie napisać to:
Każdemu programiście języka C++ zdarzyło się co najmniej raz zapomnieć operatora
delete.
Przykłady kodu są zabawkowe. Gdyby jednak taki kod znajdował się w pętli, gdyby tablica zawierała obiekty zamiast wartości int – mielibyśmy poważny problem.
Co do poprawiania błędów przez innych developerów (3): znana maksyma głosi, że kod jest czytany dużo częściej niż pisany. Warto zadbać o jego przejrzystość i strukturę. To, czy kod jest czytelny czy nie, nie zależy jedynie od wyboru języka, ale także od stosowania konwencji (nazw, formatu kodu) i abstrakcji (jak wzorce projektowe).
Języki programowania ewoluują!
Wiesz już (niekoniecznie ode mnie), że to, czy język się kompiluje czy interpretuje nie jest rdzenną cechą samego języka, ale środowiska, w którym ma działać Twój kod.
Wiesz, co jeszcze może ulegać zmianom? Sama składnia!
Język naturalny, czyli język, którym ludzie porozumiewają się między sobą, ewoluuje. Pojawiają się nowe słowa, stare zyskują nowe znaczenia. Uparcie powtarzane błędy w końcu wchodzą do kanonu (czy zastanawiałeś się kiedyś, dlaczego w wielu językach najczęściej używane czasowniki odmieniają się nieregularnie?)
Nie inaczej jest w przypadku języków programowania. W nowych wydaniach pojawiają się konstrukcje pozwalające w bardziej zwięzły sposób wyrazić te same treści. Dopuszczane są elementy innych paradygmatów (np. popularne ostatnio wyrażenia lambda, związane z programowaniem funkcyjnym).
Dla ilustracji, dwa fragmenty kodu w języku Java:
|
1 2 3 4 5 |
//Java 5, 6 Map<String, List<String>> retVal = new HashMap<String, List<String>>(); //Java 7 Map<String, List<String>> retVal = new HashMap<>(); |
Obie wersje tworzą mapę (tablicę asocjacyjną), w której kluczami są łańcuchy znaków, a wartościami – listy zawierające łańcuchy znaków. Czyli, na przykład, na podstawie nazwiska mogę pobrać listę numerów telefonu przypisanych do danej osoby.
Druga, nowsza wersja jest wyraźnie krótsza. Dlaczego? Otóż dlatego, że programiści Javy od lat dostawali białej gorączki przez ostrzeżenia kompilatora na temat nieznanego typu podczas tworzenia kolekcji, mimo że typ można było jednoznacznie wywnioskować na podstawie deklaracji zmiennej. Ich skargi wreszcie dotarły gdzie trzeba, i oto efekt.
Dlaczego podałam numery wersji od 5 w górę? Ponieważ w wersji 4 nie można jeszcze było stosować uogólnień (ang. generics) – w efekcie nie mogłabym w ten sposób określić typu danych przechowywanych w kolekcji.
W następnej części
- Języki wyspecjalizowane – R
- Nie tylko dla dzieci – programowanie graficzne
- Który do czego?
- Który da mi pracę?
- Quiz!
- Polecane lektury
