Opisałam ostatnio 7 powodów, dla których warto zostać programist(k)ą. Nadal obstaję przy tym, że warto, jednak dla pełni obrazu zamieszczam uzupełnienie: listę niedogodności, którym na co dzień musimy stawiać czoła.
1. Ciągle jesteś uczniem.
Programowanie to zawód wymagający nieustannego rozwoju. Wspominałam już, że informatyka nie jest moją życiową pasją. Po godzinach pracy wolę zajmować się czymś innym. Jednak od czasu do czasu muszę przeczytać branżową książkę lub czasopismo, albo przejść kurs w portalu Coursera. Języki programowania ewoluują. Jedne zastępują drugie. Warto dbać o to, żeby być na bieżąco.
Podobno istnieje coś takiego jak „expert programmer”, który wszystko wie, ale ja do końca w to nie wierzę 🙂
2. Nic nigdy nie jest gotowe.
Myślę teraz o największych projektach, w które byłam zaangażowana w życiu zawodowym i na uczelni. Wiele godzin planowania, projektowania, implementacji. Terminy znane z góry, a z reguły i tak przesuwane. A jednak tuż przed wydaniem bądź prezentacją programiści rytmicznie przygryzają ze zdenerwowania wargi i paznokcie, licząc na to, że klient nie wciśnie tej jednej wadliwej kombinacji klawiszy, o której wiadomo, że wysadzi wszystko. Albo tej drugiej.
3. Zabierasz pracę do domu.
Nie chodzi nawet o powyższe. Pomijając czasy studenckie i ewentualnie krótkie okresy przed oficjalnymi wydaniami, zasadniczo nie pracuję po godzinach. Niestety, praca programistyczna ma brzydką tendencję do wychodzenia z biura razem z nami i przypominania o sobie w najmniej pożądanych momentach. Programowanie to rozwiązywanie problemów. Jeżeli do końca dnia jakiegoś problemu nie zdążyłam rozwiązać (a najlepiej jeszcze tego rozwiązania przetestować), to temat ten będzie rozbrzmiewał w tyle (w najlepszym przypadku) mojej głowy. Czasami to dobrze – gdy okazuje się, że podczas snu wszystkie elementy poprzesuwały się na swoje miejsca i rano potrafię naprawić błąd, choć nie włożyłam świadomego wysiłku w te przemyślenia. Jednak rzędy cyfr przelatujące mi przed oczami o trzeciej w (bezsennej) nocy potrafią sprawić, że kwestionuję swój wybór ścieżki zawodowej.
4. Dysproporcje płciowe.
Powiedziano i napisano na ten temat wiele. Ja sama powiedziałam i napisałam wiele, a pewnie wiele jeszcze przede mną. Wersja, której się trzymam, jest następująca: najlepsza jest równowaga. Większe dysproporcje to zarzewie konfliktów, nieważne w którą stronę nie byłaby przechylona szala. Wiem, co mówię: w mojej licealnej klasie kobiet było 80%, w obecnej pracy programistki stanowią na pewno mniej niż 20%.
5. Cudzy kod
No tak… Programowanie to rozwiązywanie problemów. Niestety nierzadko problemem jest totalny chaos w głowie naszego poprzednika. Wycieczki do wnętrza cudzego mózgu bywają męczące, niebezpieczne i mogą przyprawić o szaleństwo. Do tego czasem okazuje się, że to jednak nie był cudzy mózg…
Jeszcze w czasie studiów, gdy w jakimś barze potencjalny adorator pytał mnie o kierunek studiów, wiedziałam, że mogę spodziewać się jednej z dwóch najpopularniejszych reakcji: brzydkiego przekleństwa lub „a nie wyglądasz”.
Teraz wcale nie jest dużo lepiej. Na jednej z imprez konferencyjnych w lokalu, który nie został na tę okazję zamknięty, usłyszałam następującą kwestię: „Wychodzimy, tu są sami informatycy”.
W obecnej chwili nie jest tak źle, ponieważ „kultura geeków” zrobiła się dość popularna. IT Crowd (ekhem, „Technicy-magicy”) i The Big Bang Theory („Teoria wielkiego podrywu”) trochę oswoiły nieznane. A jednak mało który zawód (ksiądz? 🙂 ) narzuca na człowieka taką siatkę stereotypów i oczekiwań. Jako programista uwielbiający muzykę (nie klasyczny metal), literaturę (nie tylko science-fiction) i inne przejawy sztuki odczuwam tę automatyczną klasyfikacją bardzo wyraźnie.
7. Brak dress code w wersji diabelskiej.
Napisałam wcześniej, że jedną z zalet w pracy programisty jest brak tzw. dress code. Mogę przyjść do pracy w jeansach lub sukience, w trampkach lub na obcasach. A jednak ten brak reguł potrafi się zemścić, zwłaszcza latem. Gdyż zdarza mi się oglądać takie oto widoki:
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).
Zasada działania maszyny wirtualnej (na przykładzie JVM)
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++
C++
1
2
3
4
5
int*x=newint[10];
// tablica 10 elementów typu int
// ... (operacje)
// pora zwolnić pamięć
delete[]x;
Java
Java
Java
1
2
3
4
5
int[]x=newint[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).
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.
Tekst jest oparty na mojej prezentacji z konferencji Kariera IT
Ś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.
Kod maszynowy
Asembler
C
TeX
1
2
3
4
8B54240883FA007706B800000000C383
FA027706B801000000C353BB01000000
B9010000008D041983FA0376078BD98B
C84AEBF15BC3
Assembly (x86)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
fib:
movedx,[esp+8]
cmpedx,0
ja@f
moveax,0
ret
@@:
cmpedx,2
ja@f
moveax,1
ret
@@:
pushebx
movebx,1
movecx,1
@@:
leaeax,[ebx+ecx]
cmpedx,3
jbe@f
movebx,ecx
movecx,eax
decedx
jmp@b
@@:
popebx
ret
C
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
unsignedintfib(unsignedintn)
{
if(n<=0)
return0;
elseif(n<=2)
return1;
else{
inta,b,c;
a=1;
b=1;
while(true){
c=a+b;
if(n<=3)returnc;
a=b;
b=c;
n--;
}
}
}
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.
Prototypy kontra klasy, ujęcie biologiczne, Gratka dla fanów mojej kreski (są tacy!)
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.
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.
Tekst jest oparty na mojej prezentacji z konferencji Polyconf
Zastanawiałam się ostatnio nad tym, kim jest dzisiaj programista. Czy umiejętność programowania przydaje się na co dzień, w normalnym życiu? Czy wszyscy powinni ją w jakimś stopniu opanować?
Mam trochę doświadczenia w uczeniu informatyki. Prowadziłam zajęcia z dziećmi, ze studentami i z seniorami. Ci ostatni co prawda nie zostali programistami, ale część z nich nauczyła się wysyłania grających maili ze slajdami w załącznikach (jeśli dostajecie coś takiego od Waszej babci – z całego serca przepraszam).
W pracy miałam okazję zetknąć się z bardzo dobrymi programistami, którzy skończyli zupełnie nietechniczne studia.
A jednak kroplą, która przepełniła czarę i skłoniła mnie do przygotowania tekstu, było coś zupełnie innego…
Popsuty komputer
Parę tygodni temu popsuł się mój komputer. Pracowałam w domu, nad głową miałam termin. Wyszłam do kuchni po kawę, a po powrocie zastałam w pokoju martwą ciszę – brakowało bzyczenia wentylatora. Komputer nie reagował na nerwowe wciskanie wszystkich po kolei guzików. Sprawdziłam korki, listwę zasilającą i psa (ruszał się, czyli nie przegryzł żadnego kabla), po czym skierowałam podejrzenia na zasilacz. Rozważałam wycieczkę do sklepu po nowy, ale co, jeśli przyczyna jednak tkwi gdzie indziej? Skonsultowałam się z mężem – również programistą („na 90% to zasilacz”). Nie podjęłam ryzyka zmarnowania kilku godzin i zadzwoniłam po profesjonalną pomoc.
Pomoc przybyła po godzinie, w osobie, jak się okazało, studenta Uniwersytetu Przyrodniczego (nie dajcie się zwieść – do niedawna była to Akademia Rolnicza!). Kiedy zawstydzona wyznałam swoją profesję, chłopak podniósł spojrzenie znad sterty śrubek i powiedział: „to mnie nie dziwi, co chwilę naprawiam komputery programistów”.
I to natchnęło mnie do rozważań.
A winowajcą faktycznie był zasilacz.
„Za dziesięć lat programiści nie będą już potrzebni”
Na początek przypomniałam sobie przepowiednie wykładowców z czasów, kiedy byłam studentką. Wtedy nie zdawałam sobie z tego sprawy, ale zaczęłam studia chwilę po tym, jak pękła słynna „bańka internetowa” (dot-com bubble). Nastroje nie były tak dobre, jak teraz, firmy nie wpraszały się na uczelnię, by rekrutować świeży narybek, a część profesorów głosiła nasz rychły koniec. Twierdzili, że narzędzia do wytwarzania programów stają się tak proste w obsłudze i tak dużo robią za nas, że za parę lat programować będzie mógł każdy. Miało to położyć kres zawodowi programisty.
Jakie narzędzia mieli na myśli? Nic innego niż narzędzia typu RAD (Rapid Application Development, czyli „szybkie tworzenie aplikacji”), w których pracę zaczyna się od rozmieszczenia przycisków na formatce. W dalszej kolejności programujemy ich obsługę.
Kilkanaście lat później ciągle wiążemy koniec z końcem. Sytuacja na rynku pracy dawno nie była tak korzystna dla programistów. Do tego stopnia, że firmy są gotowe zatrudniać nawet osoby bez studiów, gotowe się przekwalifikować. Pracy jest dużo: w korporacjach, rodzinnych biznesach, start-upach, R&D. Nie brakuje możliwości pracy zdalnej.
Wiedza techniczna nigdy nie była tak łatwo dostępna
Większy popyt na rynku pracy zbiegł się w czasie z udostępnieniem szerszej publiczności zasobów wiedzy, o jakich jeszcze parę lat temu można było jedynie pomarzyć.
Po pierwsze, pojawiły się (i szybko zyskały ogromną popularność) kursy typu MOOC (massive open online courses, czyli masowe otwarte kursy online) . Najpopularniejsze to Coursera i edX. Dają możliwość uczestniczenia w zajęciach prowadzonych przez najlepsze światowe uniwersytety i najsłynniejszych profesorów (często autorów znanych podręczników). Kursy najczęściej składają się z zestawu wykładów oraz pytań do nich. W kursach informatycznych często dochodzą jeszcze zadania programistyczne, sprawdzane automatycznie lub na zasadzie peer-review (każdy uczestnik musi ocenić zadania domowe kilku innych osób, żeby otrzymać komplet punktów za dany tydzień).
Po drugie, istnieje kilka ciekawych produktów kierowanych przede wszystkim do dzieci. Jednym z nich są roboty Lego Mindstorms. Napisałam artykuł na ich temat na poprzednim blogu, zamierzam zaktualizować go i wrzucić także tutaj. Mindstorms to zestaw klocków Lego zawierający prosty komputer („kostkę”), kilka silniczków, czujniki (odległości, dźwięku, dotyku, koloru) oraz typowe klocki z serii Lego Technic. Robota można programować na kilka sposobów – za pomocą prostych obrazków wyświetlanych na samej kostce („do przodu”, „wydaj dźwięk”, „powtórz”), w rozbudowanym środowisku graficznym na komputerze (czynności i odczyty robota układamy na dużej planszy, możemy dodawać warunki logiczne oraz pętle) lub w tradycyjnym języku programowania (natywny język zbliżony do C lub, po wymianie oprogramowania, Java). Inny przykład z tej kategorii to KANO – projekt sfinansowany ze środków zgromadzonych przez platformę Kickstarter. Pierwsza partia komputerków opartych na Raspberry Pi oraz Linuksie Ubuntu została już dostarczona do inwestorów. Dzieci najpierw budują komputer z dostarczonych (dużych) elementów. a następnie krok po kroku, przez zabawę, uczą się modyfikować i tworzyć programy.
Warto wspomnieć także o inicjatywach społecznościowych. W większych miastach działają liczne grupy takie jak PyLadies, zachęcające do nauki programowania i prowadzące warsztaty. Często, ale nie zawsze, kierują swoją ofertę do osób reprezentujących mniejszości w świecie IT.
Naprawdę mam się tego uczyć?
Czy każdy powinien nauczyć się programować? Opinie na ten temat są podzielone. Zdaniem twórcy Linuksa, Linusa Torvaldsa:
Nie uważam, że każdy koniecznie powinien podjąć naukę programowania. To dość wyspecjalizowana umiejętność, której nie oczekuje się od większości osób. To nie to samo, co umiejętność czytania i pisania czy wykonywanie prostych rachunków.
Dla kontrastu, oto opinia Marka Guzdiala, profesora na Georgia Tech:
Jesli ktoś planuje karierę pracownika umysłowego, lub zamierza podjąć pracę wymagającą stopnia licenjata, to powinien być w stanie czytać przydatne mu fragmenty kodu i wprowadzać w nich zmiany.
Zdecydowanie bliżej mi do drugiej opinii. Uważam, że każdy powinien nauczyć się programowania – ale w różnym stopniu! Programowanie wymaga określonego zestawu umiejętności, które przy okazji wzmacnia:
myślenie logiczne,
algorytmika i strukturyzacja,
planowanie.
Jest to zestaw bardzo przydatny w „normalnym” życiu. Przygotowując ten tekst przepytywałam znajomych, którzy zajęli się programowaniem na późniejszym etapie życia. Jeden z nich powiedział mi, że frustruje go obserwacja znajomych ze studiów, którzy do ważnych życiowych problemów i decyzji podchodzą w sposób chaotyczny (tzw. algorytm gołębia – jeden krok do przodu, dwa w bok, trzy do tyłu). Jako przykład podał szukanie pracy. Można potraktować to jako problem algorytmiczny: zebranie danych, przygotowanie CV, rozesłanie CV, przygotowanie do rozmowy, wybór najlepszej oferty… A można na oślep wysyłać coraz to inne CV, gdy akurat między prysznicem a zakupami przypomni nam się, że nie mamy pracy.
Dodatkowym plusem nauki programowania jest to, że osoby, które rozumieją, jak działa program komputerowy, automatycznie stają się mniej podatne na różne brzydkie internetowe sztuczki. Być może staranniej zastanowią się, zanim klikną w link w mailu i wprowadzą dane logowania na stronie tylko pozornie należącej do zaufanego banku.
Jestem głęboko przekonana, że pierwsze lekcje programowania należy przeprowadzać jeszcze w szkole podstawowej.
Nauka programowania to nauka myślenia. Oczywiście, w pierwszej fazie powinna odbywać się przez zabawę, jak modyfikowanie kolorów w prostej, zabawnej grze komputerowej. Wczesne wprowadzenie takich zajęć pozwoli dodatkowo na wczesnym etapie wykryć utalentowane osoby, które w innym wypadku mogłyby nigdy nie mieć okazji przekonania się o swoich predyspozycjach do tej dziedziny. Myślę tu głównie o dziewczynkach, często zniechęcanych komentarzami nauczycieli i rodziców do zainteresowania przedmiotami ścisłymi. Być może podczas pierwszych lekcji programowania warto byłoby powstrzymać się od ocen, lub oceniać głównie zaangażowanie (nie próbuje – próbuje – wybitny).
Przy okazji, ostatnio ktoś podesłał mi bardzo ciekawe wystąpienie Stephena Wolframa, który przekonuje, że na wczesnym etapie należy połączyć nauczanie matematyki i informatyki – na czym zyskają obie dziedziny.
Kiedy jest za późno?
Czy na naukę programowania może być za późno? Posłużę się kolejnym cytatem. Jens Skou jest laureatem Nagrody Nobla z chemii. Urodził się w roku 1918, a w roku 1997 powiedział:
W roku 1988 przeszedłem na emeryturę (…) i zacząłem badać za pomocą komputera modele kinetyczne pompy sodowo-potasowej. W tym celu musiałem nauczyć się programować. To ciekawe i wprost niewiarygodne, co można uzyskać przy pomocy komputera, jeśli chodzi o przetwarzanie nawet bardzo złożonych modeli.
Łatwo policzyć, że w chwili rozpoczęcia nauki programowania profesor miał 70 lat!
Moim zdaniem, nigdy nie jest za późno na naukę programowania. Jeśli jednak myślisz o przekwalifikowaniu się na zawodowego programistę, najpierw odpowiedz sobie na kilka pytań:
Czy próbowałeś już programować? Czy sprawiło Ci to przyjemność?
Czy jesteś gotów dokształcać się w swoim wolnym czasie?
W pracy możesz spotkać osoby znacznie od Ciebie młodsze. Czy jesteś gotów:
Pracować z nimi w zespole?
Uczyć się od nich?
Przyjmować od nich polecenia?
Czym się ostatnio zajmowałeś? Jak wygimnastykowany jest Twój mózg? Jak u Ciebie z koncentracją?
Czy jesteś w stanie przeżyć parę lat z wynagrodzeniem młodszego programisty?
(nieobowiązkowe) Czy znalazłeś sobie mentora?
Od polonisty do programisty – jak i czego uczyć?
Istnieją dziesiątki języków programowania. Niektóre są bardzo ogólne, inne wykorzystuje się tylko w ściśle określonych sytuacjach. Jedne da się zastąpić innymi, inne są obowiązkowe, jeśli chcemy rozwiązać problem z danej dziedziny. Od którego zacząć?
Postuluję, żeby pierwszy język programowania spełniał następujące warunki:
Oferował natychmiastową informację zwrotną. A więc powinien to być język interpretowany, a nie kompilowany. Najlepiej wyposażony w interaktywną konsolę, w której można przetestować proste operacje (np. mnożenie liczb) zanim jeszcze uczeń zda sobie sprawę z tego, że to, co robi, to już programowanie.
Był obiektowy. Programowanie proceduralne jest dobre na sam początek, ale nie wymusza przemyślanej struktury i dobrych praktyk. Programowanie funkcyjne przeżywa dzisiaj renesans, ale może tylko odstraszyć większość początkujących. Kilka osób próbowało mnie przekonać, że wybieram programowanie obiektowe jedynie dlatego, że sama byłam tak uczona (co zresztą nie jest nawet zgodne z prawdą). Jedna z tych osób powiedziała mi „Ja też sądziłem, że programowanie funkcyjne to jakiś koszmar, ale po sześciu miesiącach nauki wiem bez wątpienia, że to najlepszy wybór”. Hm, początkujący programista raczej nie da nam takiego kredytu zaufania. Widziałam również kurs programowania dla początkujących oparty o programowanie sterowane zdarzeniami (zgodnie ze słuszną poniekąd ideą, że dobrze jest szybko pokazywać wyniki nauki, kurs opierał się na programowaniu gier). Zapewniam, że uczestnicy kursu nie mieli bladego pojęcia, kto, skąd i dlaczego do nich strzelają. Programowanie obiektowe ma tę ogromną zaletę, że łatwo przełożyć je na język otaczającego nas świata. Zwierzę to klasa. Pies to podklasa zwierzęcia. Pralka w Twoim domu to obiekt, który ma atrybuty i funkcje. To naprawdę działa.
Pozwalał na programowanie bardzo różnych rzeczy. Kiedy uczysz kogoś programowania, nie masz pewności, czy nie poprzestanie na pierwszym języku, jaki pozna. Dlatego warto pokazać mu język, który daje duże możliwości. Dobrze, żeby pozwalał na tworzenie następujących typów aplikacji:
praca w konsoli i operacje na plikach,
proste okienka,
aplikacje internetowe.
Przykładem języka, który spełnia wymienione tu kryteria, jest Python. Uważam, że to cudowny pierwszy język.
Bonus: czego się spodziewać w pracy z neoprogramistami? Przecież oni imprezowali, kiedy ja liczyłam całki!
Na swojej drodze zawodowej spotkałam kilka osób, które zostały programistami, mimo że skończyły studia humanistyczne. W tej części chciałabym podzielić się z Wami obserwacjami na temat mocnych i słabszych stron takich inżynierów.
Plusy
Ogromny entuzjazm! Sama po pracy w miarę możliwości staram się trzymać z daleka od informatyki. Dla osób z tej grupy informatyka to cudowne nowe hobby, które chcą uprawiać i którym chcą się dzielić.
Znajomość najnowszych frameworków. Zapytana, deklaruję, że znam C++. Prawda jest jednak taka, że ostatni raz napisałam coś większego w tym języku jeszcze na studiach. Tymczasem jeśli ktoś przychodzi „na świeżo” i nauczył się języka z pasji, to z dużym prawdopodobieństwem będzie miał aktualną wiedzę na temat tego, co dzieje się w języku, jakie panują mody i w którym kierunku dany język zmierza.
Wiedza dziedzinowa. Większość programistów nie działa w oderwaniu od rzeczywistego świata. Piszemy aplikacje dla kogoś. Jeśli klientem są księgowi, musimy albo zatrudnić eksperta dziedzinowego, albo ktoś z nas musi nauczyć się podstaw księgowości. Zatrudniając neo-informatyka, w pakiecie dostajemy jego wiedzę z dziedziny, z której wyrósł. To bardzo cenne.
Gotowość do wykonywania zadań, którymi starzy wyjadacze gardzą. Trochę powtarzalne, mało rozwojowe? Bezpieczne? Jak najbardziej.
Minusy
Brak dobrych praktyk, zwłaszcza w dziedzinie testowania. Oznaczanie jako „zrobionych” zadań, które nie zostały poddane podstawowym testom. W których nie sprawdzono przewidywalnych warunków brzegowych. Które, co prawda, zapaliły wszystkie lampki w ciągłej integracji na czerwono, ale programista spieszył się do domu, więc nie poczekał na wyniki. Tego obszaru trzeba po prostu starannie dopilnować.
Luki w wiedzy matematycznej. To nie koniec świata – większość programowania i tak opiera się na stosowaniu rozwiązań wymyślonych przez kogoś innego (Zajmujesz się uczeniem maszynowym? Rozumiesz dogłębnie zasadę działania SVM?). Największe niebezpieczeństwa czyhają w obszarze złożoności obliczeniowej – tę wiedzę koniecznie należy uzupełnić.
Krótkie podsumowanie
Jeszcze nigdy w (niedługiej, przyznaję) historii zostanie programistą nie było tak proste jak dzisiaj. Mamy dostęp do nieograniczonych zasobów wiedzy technicznej: kursy online, ciekawe produkty uczące przez zabawę, wsparcie lokalnych społeczności. Rynek obfituje w oferty pracy dla programistów.
Początkujący programiści i osoby pochodzące z innych dziedzin nie powinny mieć wielkich kompleksów. Dzisiejsze czasy wymagają specjalizacji. Większość programistów i tak zna na wylot tylko najbliższe sobie działki – tę opinię chciałam przekazać moją przydługą opowieścią o popsutym komputerze.
Czy tak dobra sytuacja się utrzyma? Nie wiadomo…
Patrząc na indeks NASDAQ, nie sposób nie zauważyć, że znajdujemy się w obszarze niebezpiecznie zbliżonym do bańki internetowej z 2000 roku. Globalizacja i centralizacja usług sprawiają, że osoba z dobrym pomysłem może w krótkim czasie zarobić miliony. Z drugiej strony, raz rozwiązany problem jest rozwiązany na dobre, co może pozbawić pracy mnóstwo mniejszych, lokalnych firm.
Pełna historia indeksu NASDAQ
Mimo wszystko, Internet i informatyka odgrywają coraz większą rolę w naszych życiach, więc należy się spodziewać, że ten sektor będzie zatrudniał więcej i więcej osób. Na pewno warto dodać programowanie do programu nauczania szkoły podstawowej – gdzieś obok matematyki i techniki.
Gdybym miała wskazać pierwszy język programowania dla dorosłej osoby, która chce sprawdzić swoje siły w tej dziedzinie, wybrałabym język Python: interaktywny, obiektowy, uniwersalny. Łatwo wyszukać w Internecie kursy dla początkujących – na przykład ten, oferowany przez Uniwersytet Michigan.
Milsza strona programowania
Ta strona korzysta z ciasteczek. Możesz zablokować je w opcjach przeglądarki, jeśli nie wyrażasz na nie zgody. Rozumiem