Justyna Walkowska - Programista, tłumacz, doktor informatyki. Zawodowo zainteresowana przetwarzaniem języka naturalnego, a ostatnio również krzewieniem wiedzy informatycznej w środowiskach tradycyjnie od niej odciętych. Najbardziej lubi Javę, uważa jednak, że warto być programistycznym poliglotą. Prowadzi bloga http://namiekko.pl/ – głównie o informatyce, ale także o tym, co akurat zdenerwuje autorkę.

---

Ś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ąć? Postaram się krótko opowiedzieć o współczesnych językach programowania i różnicach pomiędzy nimi. Dla porządku zacznę od (króciutkiego!) rysu historycznego. Dalej będzie z górki! :)

Pierwszy programista (nie róbmy z tego tajemnicy: chodził w spódnicy)

Jako pierwszego na świecie programistę często wymienia się Adę Lovelace. Ada była córką poety, Lorda Byrona. W latach 1842-1843 (!) przetłumaczyła z francuskiego rozprawę poświęconą „maszynie analitycznej” Charlesa Babbage’a. Tłumaczenie opatrzyła notatkami, w których znalazł się pierwszy na świecie opis algorytmu przeznaczonego do wykonania przez maszynę (algorytm wyznaczał kolejne liczby Bernoulliego). Działający egzemplarz takiej maszyny udało się zbudować dopiero w 1991 roku. Dokonało tego Muzeum Nauki w Londynie, przy użyciu materiałów dostępnych w czasach Babbage’a. Wyrazami uznania dla pracy Ady Lovelace są między innymi język programowania Ada stworzony na początku lat osiemdziesiątych oraz nagroda Ada Award przyznawana „wybitnym dziewczętom i kobietom w sektorach cyfrowych”.

Odrobina kontekstu: kamienie milowe historii programowania

To nie jest wpis o historii programowania, dlatego wypunktuję tylko kilka przełomowych wydarzeń:

• 1936: Alan Turing opisuje Maszynę Turinga, hipotetyczny „komputer” złożony z głowicy oraz nieskończonej taśmy, który może wykonywać algorytmy i stanowi teoretyczny model obliczeń.
• 1943-1945: Powstaje ENIAC, powszechnie uważany za pierwszy komputer.
• 1940-1960: Dominują języki niskopoziomowe. Na ich tle wWyróżnia się FORTRAN, język wyższego poziomu z własnym kompilatorem.
• 1960-1970: Powstają stosowane do dzisiaj języki i paradygmaty: język C, Smalltalk (obiektowy), Prolog.
• 1990-…: Internet staje się ogólnodostępny. Dominuje paradygmat obiektowy. Pojawia się sporo języków funkcyjnych i skryptowych.
• 2010-…: Zwrot w stronę programowania funkcyjnego, metaprogramowanie i mechanizm refleksji, nacisk na wielowątkowość.

 

Z głową w chmurach: języki niskiego i wysokiego poziomu

Jeśli – chcąc nauczyć się nowego języka programowania – zaczniesz szukać informacji na jego temat w Internecie, prawie na pewno natkniesz się na informację o tym, że „X to język programowania wysokiego poziomu, który …”. Jeden za drugim, którego byś nie sprawdził, wszystkie są wysokopoziomowe. Co to znaczy? Spójrz na fragmenty kodu w poniższej tabelce.



Każdy z przedstawionych fragmentów kodu (wzięłam je z Wikipedii; wystarczył mi jeden semestr z Asemblerem żeby wiedzieć, że nigdy więcej nie chcę go dotykać) robi to samo: wyznacza n-ty wyraz ciągu Fibonacciego.

Po lewej mamy kod maszynowy – kolejne liczby (zapisane szesnastkowo) to rozkazy procesora i ich argumenty. Kod taki jest nieprzenośny, tj. zależny od architektury. Przykładowy kod jest przeznaczony dla 32-bitowej maszyny x86. Programowanie w tym języku wymaga zapamiętania numerów poszczególnych instrukcji, lub korzystania z rozbudowanej ściągi (słownika). Jest to kod absolutnie niskopoziomowy.

Środkowa kolumna to Asembler (ang. Assembly language). To również język niskopoziomowy. Wygląda inaczej niż kod maszynowy, jednak w rzeczywistości stanowi odwzorowanie „jeden do jeden” instrukcji procesora, tyle że w sposób łatwiejszy do zrozumienia i zapamiętania przez człowieka. W przykładowym kodzie widać odwołania do rejestrów procesora x86 oraz do stosu.

Po prawej stronie język C. Kod różni się od przykładów po lewej stronie brakiem odwołań do architektury maszyny, na której działa. Wartości będą w końcu pobierane ze stosu, ale nigdzie nie oznaczamy, w jaki sposób ma się to odbyć. Funkcja ma zwrócić wartość, ale nigdzie w kodzie nie określamy mechanizmu jej przekazania. Wprowadzamy własne abstrakcje – zmienne lokalne wewnątrz instrukcji warunkowych oraz pętli – i nie przejmujemy się sposobem ich obsługi na docelowej maszynie.

Na podstawie powyższego możesz logicznie wywnioskować, że C jest językiem wysokiego poziomu. Jednak gdy podzielisz się tą opinią z zaprzyjaźnionymi programistami, większość z nich z niedowierzaniem pokręci głową. Dzisiaj C jest uznawany za, w najlepszym razie, język „średniego poziomu”. Wprowadza sporo użytecznych abstrakcji, ale jednocześnie (czego w naszym przykładzie akurat nie widać) pozwala na bezpośrednie odwołania do pamięci – nie do pomyślenia w większości języków wysokopoziomowych.

Możesz jeszcze natknąć się na określenie super high level language, czyli język bardzo wysokiego poziomu. Tym terminem określa się najczęściej języki dziedzinowe, zwiększające produktywność programisty poruszającego się na co dzień po specyficznym, zamkniętym obszarze. Z reguły są tą jednak tylko (?) nakładki na istniejące języki programowania wysokiego poziomu.

Rozkazuję ci… Języki imperatywne i deklaratywne

Kolejny ważny podział wśród języków programowania to rozróżnienie na paradygmat imperatywny i deklaratywny. • Program imperatywny zawiera ciąg instrukcji, zmieniających stan programu. Wydajemy komputerowi „rozkazy”: zwiększ wartość x o 5, zwróć wynik. Przykłady języków imperatywnych to Perl, Python, Java oraz wszystkie języki przedstawione w tabelce w poprzednim podrozdziale. • Program deklaratywny nie mówi komputerowi, jakie kroki ten ma wykonać. Zamiast tego, programista opisuje warunki, jakie musi spełniać rozwiązanie. Ważne i pożądane cechy języka deklaratywnego to bezstanowość i determinizm. Te same dane wejściowe zawsze prowadzą do uzyskania tego samego wyniku, nie wpływa na nie żaden wewnętrzny „stan”. Przykłady języków deklaratywnych to Haskell, Erlang i Prolog.

Świat imperatywny: klasy i prototypy

Jeśli chodzi o programowanie imperatywne, od dawna już (co najmniej od początku obecnego wieku) dominuje programowanie obiektowe, które wyparło mniej ustrukturyzowane programowanie proceduralne. W ścisłym ujęciu program obiektowy to program, którego wykonanie sprowadza się do przesyłania komunikatów pomiędzy obiektami. Nie wszyscy jednak wiedzą, że programować obiektowo można w dwóch „smakach”: przy użyciu klas lub paradygmatów.

Sytuację dobrze ilustruje ten oto obrazek (mojego autorstwa, wreszcie mogę się popisać!), inspirowany slajdem z prezentacji na temat zaskakujących elementów języka JavaScript:



W podejściu klasycznym (nazwa jest tym bardziej odpowiednia, że to podejście dominuje – np. Java, C++) opisujemy świat za pomocą klas. W praktyce klasą może być „Okno Przeglądarki” albo „Ramka”, jednak w zastosowaniu edukacyjnym lepszym przykładem będzie nieśmiertelna klasa „Zwierzę”. Klasa Zwierzę ma pewne atrybuty: liczbę nóg lub umiejętność wydawania pewnego dźwięku. Klasa ta może mieć podklasę, na przykład Słoń. Słoń ma wszystkie atrybuty klasy Zwierzę, ale może definiować własne – na przykład trąba i jej długość :)

W oparciu o klasy tworzymy obiekty, czyli konkretne instancje (egzemplarze) poszczególnych klas. I tak Dumbo i MamaDumbo to dwa różne obiekty tej samej klasy Słoń. Klasy możemy podzielić na konkretne (które mogą mieć instancje) i abstrakcyjne (bardziej ogólne, pełniące tylko rolę szablonów).

Alternatywą jest podejście prototypowe, dostępne na przykład we wspomnianym już tutaj języku JavaScript. Jeśli programujemy z prototypami, całkowicie wyzbywamy się klas. Wszystko jest obiektem. Zwierzę to obiekt. Słoń to obiekt, dla którego obiekt Zwierzę jest prototypem. Dumbo to kolejny obiekt, wzorowany na Słoniu. Koneserzy tej wersji przekonują, że dopiero przy takim podejściu, gdzie wszystko jest obiektem, możemy mówić o programach prawdziwie obiektowych.

Jaka jest praktyczna różnica? Prototypy, jako obiekty, można modyfikować w czasie wykonania. Klasy są usztywnione – jeśli powiemy, że słoń ma cztery nogi, nie będziemy gotowi do obsłużenia egzemplarza z pięcioma. Ma to jednak swoją cenę. Większość języków prototypowych jest typowana dynamicznie. Oznacza to, że typ obiektu jest określany dopiero w czasie wykonania. Dla takich języków o wiele trudniej jest tworzyć dobre IDE (zintegrowane środowisko programistyczne). W przypadku statycznie definiowanych klas, edytor może nam sporo pomóc: np. podpowiedzieć, jakie funkcje da się wywołać na danym obiekcie.

Ograniczenia wprowadzane przez stosowanie klas stają się jednak coraz mniej uciążliwe z powodu rozbudowanych mechanizmów refleksji (zmiany istniejącego kodu w czasie wykonania) w nowoczesnych językach programowania.

Świat deklaratywny: języki funkcyjne i programowanie w logice

Języki funkcyjne przeżywają obecnie prawdziwy boom popularności. Główną przyczyną tego stanu (sic!) rzeczy jest ich bezstanowość i brak skutków ubocznych – cechy te ułatwiają programowanie współbieżne. Jest to istotne, ponieważ w roku 2014 dobiegamy do kresu prawa Moore’a, wieszczące (w uproszczeniu) wykładniczy wzrost szybkości układów scalonych. Zamiast coraz szybszych procesorów mamy teraz procesory z większą liczbą rdzeni i coś z tym fantem trzeba zrobić.

Program napisany w języku funkcyjnym sprowadza się do wartościowania (ewaluacji) funkcji matematycznych. Unikamy przy tym przechowywania i modyfikowania stanu. Do dyspozycji mamy języki czysto funkcyjne, jak Haskell (z dość dużym progiem wejścia, uwielbiane przez snobistycznych doświadczonych developerów), oraz nieco bardziej przystępne (acz kojarzące się z potworem Frankensteina) języki mieszane, jak Scala, które pozwalają na łamanie części zasad, przy jednoczesnej praktycznej dostępności pewnych silnych stron tego paradygmatu (jak wygodne wykonywanie funkcji na wszystkich elementach kolekcji).

Programowanie funkcyjne to duży temat, któremu zamierzam w przyszłości poświęcić osobny wpis.

Inny rodzaj programowania deklaratywnego to programowanie w logice, szczególnie przydatne przy problemach zahaczających o zagadnienia sztucznej inteligencji (rozumienie języka naturalnego, rozwiązywanie łamigłówek). W tym podejściu, zamiast szukać algorytmów,, musimy zdefiniować zależności i ograniczenia (ang. constraints) obowiązujące w danej dziedzinie. Interpreter języka logicznego, takiego jak Prolog, podejmie następnie próbę rozwiązania problemu „za nas” w oparciu np. o rachunek predykatów pierwszego rzędu.

Pierwsze doświadczenia z programowaniem w logice bywają bolesne. O ile w większości języków możemy napisać coś w stylu

X = 1; X = X + 1;

i spodziewać się odpowiedzi 2, o tyle Prolog w podobnych okolicznościach może zaskoczyć nas krótką i konstruktywną odpowiedzią NIE (X nigdy nie będzie równe X+1). Po co w ogóle pchać się w te cudaczne rejony?

Ano chociażby dlatego, że w Prolog pozwala na rozwiązanie bardzo skomplikowanych problemów (kostka Rubika, Sudoku) w zaskakująco niewielkiej liczbie linii kodu.

Poniżej kompletny kod rozwiązujący Sudoku o rozmiarach 9×9, napisany w Prologu. Program pochodzi z bloga Programmable Life, tam też znajdziesz kompletne objaśnienie.

W następnych częściach

- Kompilować czy interpretować?
- Maszyny wirtualne
- Wydajność języka a wydajność programisty
- Języki programowania ewoluują!
- Języki wyspecjalizowane – R
- Nie tylko dla dzieci – programowanie graficzne
- Który do czego?
- Który da mi pracę?
- Quiz!
- Polecane lektury

PS. Zdjęcie w nagłówku

Zdjęcie przedstawia kartę perforowaną z zapisem kodu w języku Fortran. Kart perforowanych po raz pierwszy użyto w roku 1725 do sterowania pracą krosna.

W 1889 roku Herman Hollerith opatentował nowoczesną postać karty (oraz taśmy) dziurkowanej do zapisu danych. Zainspirował go system stosowany przez konduktorów amerykańskich kolei, którzy za pomocą dziurek kodowali na biletach wygląd pasażera („wysoki, niebieskie oczy”), który się danym biletem posługuje (żeby pasażerowie nie wymieniali się biletami).

Karty perforowane były szeroko stosowane do zapisu danych i programów aż do lat osiemdziesiątych XX wieku. Ich ostateczny upadek miał miejsce w roku 2000, gdy przez resztki papieru pozostałe w otworach kart nie wszystkie głosy zostały policzone poprawnie i w efekcie trzeba je było zliczyć ręcznie.