Z informatycznej opresji wybawił mnie student Akademii Rolniczej

Czy każdy musi (na)uczyć się programowania?

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ę.

Borland C++ Builder, przykład środowiska typu RAD

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 CourseraedX. 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:

  1. 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.
  2. 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.
  3. 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.

 

Komentarze

6 myśli nt. „Czy każdy musi (na)uczyć się programowania?”

  1. Może i nie każdy powinien się uczyć programować, ale jeszcze nigdy próg wejścia w programowanie nie był tak niski. Dlatego raczej warto zapytać, dlaczego ktoś mógłby nie chcieć nauczyć się programować. A takich osób wciąż jest wiele. O ile barista nie ma zamiaru zmieniać ścieżki kariery nie widzę powodu dla którego miałby poświęcać czas na naukę programowania.
    Gdy zaczynałem swoją przygodę z programowaniem w pobliskiej księgarni była dostępna tylko jedna książka o tej tematyce: „Pascal – nawet Ty możesz programować”. Później musiałem zdobyć kompilator ściągając go przez modem telefoniczny i już mogłem walczyć z brakującymi średnikami i niedomkniętymi nawiasami oraz niezliczonymi błędami niezgodności typów. Gdy już nauczyłem się składni mogłem zacząć pisać proste programy działające w konsoli, a i tak byłem lata świetlne od napisania czegoś naprawdę użytecznego. Dzisiaj początkujący programista może od razu zacząć tworzyć interaktywne programy działające w przeglądarce lub na telefonie nie zdając sobie nawet sprawy że buduje na szczycie wielkiej piramidy oprogramowania zbudowanej dla jego wygody przez setki innych ludzi. I to jest wspaniałe! łatwiej jest zacząć jeśli cel, który nowy programista chce osiągnąć – np. stworzenie strony internetowej, napisanie prostej aplikacji mobilnej – nie jest wcale tak odległy, a efekty nauki i pracy widać dość wcześnie.

    Kiedyś zastanawiałem się również jaki język poleciłbym osobie chcącej rozpocząć naukę programowania. Jeśli ktoś chciałby zacząć naukę programowania gier i jest zdecydowany, że właśnie po to uczy się programować bez chwili namysłu powiedziałbym, żeby zaczął uczyć się obsługi Unity oraz programowania w C#. W tym środowisku prawie natychmiast można sprawdzić efekty wpisania kolejnych linijek kodu, a jak słusznie zauważyłaś bardzo istotne jest żeby początkujący programista widział efekty od razu.
    Dla zastosowań ogólnych również poleciłbym Pythona, ale tylko dlatego, że jest mniejszym złem niż JavaScript.

    Co do zalety obiektowości, którą wymieniłaś – analogię obiektów ze światem rzeczywistym – to programowanie funkcyjne również takową posiada. Programy tu są tworzone jak np. samochód na linii produkcyjnej. Na każdej kolejnej stacji dodawany jest jeden element, który buduje ogólną funkcjonalność i złożoność samochodu. Jednak zgodzę się, że łatwiej jest wyjaśnić działanie pętli for niż myślenia w kategoriach rekursji pierwotnej. Albo porównać program do przepisu na ciasto niż do rachunku lamba.

  2. Napiszę jeszcze jeden komentarz, bo tamten był długi, a chciałem się jeszcze podzielić przemyśleniem na temat pracy z początkującym programistą 🙂

    Od niedawna pracuje dla nas młody chłopak (wyrzucony z pierwszego roku informatyki UW), który potrafił już programować w Pythonie. W kilka tygodni nauczył się pisać kod w C# w ramach większej całości stworzonej przeze mnie i Szymona. Na pewno nie można mu odmówić entuzjazmu i chęci do nauki nowych rzeczy jednak ma bardzo duże braki jeśli chodzi o zarządzanie złożonością kodu. Ma tendencje do tworzenia bardzo silnie powiązanych klas a zamiast korzystać z polimorfizmu tworzy wielkie struktury warunkowe.

    Mimo to wiele razy mnie zaskoczył wykonując jakieś zadanie szybciej niż myślałem. A nawet szybciej niż zrobiłbym je sam. W czasie gdy zastanawiałbym się jakich struktur danych użyć, albo jak ułożyć strukturę klas on już miał gotowe rozwiązanie zrobione przy pomocy warsztatu, który posiada.

    Myślę, że również doświadczeni programiści mogą się czegoś nauczyć od początkujących. Przy ograniczonych zasobach gotowy kod jest lepszy niż idealny.

    1. Oczywiście ostatnie wydarzenia okołowyborcze każą jeszcze raz przemyśleć temat 😉

      Wielkie dzięki za takie uzupełnienie!

      Z ciekawości: jaki jest Twój pomysł na rozwiązanie problemu ze złożonością kodu? Sama praktyka? Lektura Bandy Czterech? …?

  3. Czołem!

    Pogadamy we wtorek, ale wrzucę już teraz kilka moich spostrzeżeń.

    1. Jako fan Lispa nie mogę nie zauważyć, że Racket też świetnie się nadaje dla początkujących. Ma rozsądne biblioteki, pozwala na zabawę grafiką, co jest cenne z uwagi na natychmiastowy feedback dla uczącego się, są do niego materiały dydaktyczne, no i w końcu to Lisp;-).

    2. Kontynuując w tym duchu, zacytuję Stallmana (wiem, to wariat, ale czasem zdarza mu się napisać coś rozsądnego):

    When large numbers of nontechnical workers are using a programmable editor, they will he tempted constantly to begin programming in the course of their day-to-day lives. This should contribute greatly to computer literacy, especially because many of the people thus exposed will be secretaries taught by society that they are incapable of doing mathematics, and unable to imagine for a moment that they can learn to program. But that won’t stop them from learning it if they don’t know that it is programming that they are learning!

    Istotnie, pisząc nawet małe funkcje wspomagające pracę w Emacsie, można się sporo nauczyć, a przy tym (co bardzo istotne z punktu widzenia motywacji) te małe funkcje mogą robić coś użytecznego dla uczącego się, rozwiązywać jego konkretne problemy.

    3. Do czego zmierzam? Oczywiście, Emacs i Lisp są dość niszowe (jak większość rzeczy dobrej jakości), ale idea jest następująca: jeżeli znajdziemy środowisko, w którym jest rozsądny język programowania (Emacs Lisp to nie jest szczyt marzeń, ale nie jest zły) i które pozwala na takie „tinkering”, czyli „dłubanie”, pisanie małych kawałków kodu, które coś sensownego robią, może to bardzo pomóc się uczyć: przy stosunkowo niewielkim wysiłku widać wtedy konkretne efekty (coś działa, i nie jest to kolejny program liczący rekurencyjnie liczby Fibonacciego…). Czy jest więcej takich środowisk? Pewnie Lego Mindstorms, o których pisałaś; przypuszczam, że niektóre gry ze skryptami w Lua (też fajnym języku) mogłyby się też dobrze nadawać.

    4. Wreszcie, kontrowersyjny temat: programowanie obiektowe. Zgadzam się, że programowanie funkcyjne na początek to raczej tylko dla hardkorowych geeków, ale z drugiej strony, pytanie, czy narzut składniowy i terminologiczny związany z obiektami nie będzie zbyt duży. Z jednej strony, jest to faktycznie chyba intuicyjne (ale czy na pewno dla laików?), z drugiej strony, klasyczne programowanie strukturalne jest chyba prostsze. Warto pamiętać o Logo, które było chyba dużym sukcesem dydaktycznym (jaka szkoda, że nie ma fajnych, darmowych środowisk do zabawy z Logo…). Miało „instant feedback” (żółw!), można było programować strukturalnie (chyba nawet funkcyjnie! choć nie za bardzo obiektowo), a metafora żółwia, któremu wydawało się polecenia, była bardzo „namacalna”. (Z drugiej strony, można by to samo zrealizować obiektowo, i to nawet dość naturalnie…)

    5. Wreszcie temat, który zasygnalizowałem wyżej: składnia. Jest jasne, że uczenie laików Pascala (oldskulowo) czy Javy (nowocześniej) raczej skończy się klapą – zasną, zanim zadeklarują potrzebne im zmienne. Nie wiem jednak, czy Python jest optymalny – na pewno jest blisko ideału, ale rozważałbym też Lua, no i oczywiście Lispa (dla początkujących pewnie Scheme’a). Lisp jest jak mistrz Yoda: jest strasznie stary, używa dziwacznej składni, ale ma wielką moc;-). Zauważ jednak, że chyba nie ma języka, który miałby tak prostą składnię jak Lisp: w zasadzie (niemal) wszystkie konstrukcje języka mają tę samą składnię! Nie ma rozróżnienia między „statements” i „expressions” – wszystko jest wyrażeniami, nie ma różnicy między operatorami a funkcjami, wywołania funkcji, definicje funkcji, struktury kontrolne też mają tę samą składnię… Nawet Python nie jest tak prosty – masz jednak nie tylko wcięcia, ale też choćby te nieszczęsne dwukropki, o których tak łatwo zapomnieć początkującemu. A jako bonus w Lispie masz możliwość programowania strukturalnego, funkcyjnego i obiektowego w ramach tego samego języka. Czy znasz „Structure and Interpretation of Computer Programs” Abelsona i Sussmana? Ich wykłady na wideo (http://ocw.mit.edu/courses/electrical-engineering-and-computer-science/6-001-structure-and-interpretation-of-computer-programs-spring-2005/video-lectures/) mają prawie 30 lat, ale są znakomite! Zaczynają od kompletnych podstaw, pokazują kilka paradygmatów programowania (łącznie z programowaniem w logice á la Prolog), piszą zabawkowy program do różniczkowania symbolicznego (to było w czasach, kiedy każdy inżynier znał matematykę;-)), a na koniec pokazują, jak działa interpreter i kompilator. W dodatku robią to z niezwykłą swadą, urokiem osobistym i klimatycznymi fryzurami z lat osiemdziesiątych;-).

    6. Á propos Bandy Czterech i design patterns: przekornie wrzucę cytacik z Paula Grahama (którego bardzo cenię, choć w tym konkretnym przypadku jest możliwe, że nie ma racji – ale zawsze warto wysłuchać, co ma do powiedzenia):

    If you try to solve a hard problem, the question is not whether you will use a powerful enough language, but whether you will (a) use a powerful language, (b) write a de facto interpreter for one, or (c) yourself become a human compiler for one.
    […]
    This practice is not only common, but institutionalized. For example, in the OO world you hear a good deal about „patterns”. I wonder if these patterns are not sometimes evidence of case (c), the human compiler, at work. When I see patterns in my programs, I consider it a sign of trouble. The shape of a program should reflect only the problem it needs to solve. Any other regularity in the code is a sign, to me at least, that I’m using abstractions that aren’t powerful enough […]

    Jak się zdaje, Graham nie jest odosobniony: http://www.norvig.com/design-patterns/, jest też dyskusja na Wiki (w sensie: na oryginalnym wiki;-)): http://c2.com/cgi/wiki?AreDesignPatternsMissingLanguageFeatures .

    That said, zainspirowany tą dyskusją, kupiłem sobie książkę o design patterns (cena książki GoF to jakiś żart, ale znalazłem coś innego). Poczytam, pomyślę, spróbuję sobie wyrobić opinię. (Trochę szkoda, że przykłady są tylko w Javie i jakimś C-coś-tam, chyba C#, bo akurat w tych językach składnia raczej zaciemnia niż rozjaśnia przez masę nieistotnych szczegółów – przyznaję, Python byłby o wiele lepszy. Musze przyznać, że jest jedna rzecz, której nigdy nie udało mi się pojąć. Kiedy rozmawiałem z Javowcami i pytałem ich, po co taka przegadana składnia, te wszystkie „ASuperCoolMultiWordCamelCaseType mySuperCoolInstance = new ASuperCoolMultiWordCamelCaseType()” itd. – odpowiadali mi, że przecież nie muszą tego pisać, IDE za nich pisze. No to ja się pytam, jak to jest, że IDE potrafi, a kompilator nie? 😉 Poza tym to generuje chyba spory narzut intelektualny przy czytaniu kodu, już choćby dlatego, że mniejszy fragment mieści się na ekranie…)

    No, to się rozpisałem. A chciałem krótko;-).

  4. Cześć! To wielki zaszczyt i jednocześnie wielka trwoga trafić na komentarze dłuższe od oryginalnego wpisu. Dziękuję za taką ilość opinii i inspiracji!

    Do kilku rzeczy chcę się odnieść.

    2. „Programmable editor”. Obawiam się, że to są pobożne życzenia. Ile znasz osób, które zawodowo nie zajmują się programowaniem i jednocześnie piszą „funkcje wspomagające pracę w Emacsie”? Popatrz na ludzi korzystających z edytorów tekstu, albo wpisujących dane w Excelu… Przecież większość nie potrafi – i niespecjalnie chce się nauczyć – efektywnie wyszukać fragmentu tekstu.

    4. Żółw. Ha! Mieliśmy w podstawówce zajęcia z Logo. Przez jeden nędzny rok informatyki programowaliśmy żółwia i klęliśmy bez opamiętania, bo chcieliśmy tylko grać w Doom w pracowni informatycznej 🙂 Pamiętam, że zupełnie nie rozumieliśmy, dlaczego się tego uczymy. Dopiero z perspektywy widzę wartość tego przedsięwzięcia. Co do fajnych, darmowych środowisk do zabawy z Logo – znalazłam nawet parę przeglądarkowych – oczywiście wszystko zależy od definicji słowa „fajne”.

    5. Składnia. Hm, w kodzie maszynowym też nie widać rozróżnienia pomiędzy statements i expressions 😉 A zupełnie poważnie, wielkie dzięki za link do wykładów. Właśnie skończyłam duży kurs na Courserze, teraz popatrzę sobie na to.

    6. Rozumiem wątpliwości związane z wzorcami projektowymi. Czasami to wytaczanie armaty na mrówkę. Jednak w dużych projektach wspólne abstrakcje są zaletą nie do przecenienia.

    7. Co do „ASuperCoolMultiWordCamelCaseType mySuperCoolInstance = new ASuperCoolMultiWordCamelCaseType()” – proszę Cię, we wszystkim trzeba zachować umiar 🙂 Bo ja na przykład miałam do czynienia z 20-letnim kodem w Prologu, gdzie funkcje nazywały się gp1 i gp6. Oddałabym wtedy wszystko za ASuperCoolMultiWordCamelCaseType.

    Dziękuję i pozdrawiam 🙂

    1. Hej, i dzięki za miłe słowa (i za wykład!)!

      Re 2: jasne, że życzenia (i to niekoniecznie pobożne) – w końcu to RMS. 😉

      Z drugiej strony, są tacy ludzie. (Bastien Guerry, na ten przykład – przez pewien czas główny deweloper Org-mode’a, z wykształcenia filozof.) Ale, oczywiście, to epsilon, jak mawiamy w analizie;-).

      Re 4: hm, może podeślesz linki? (Choć „przeglądarkowość” raczej skreśla takie narzędzie, przynajmniej dla mnie – przeglądarka jest jednak bardzo nieergonomiczna i powolna. Ale chętnie zobaczę.)

      Re: Logo: czytałaś „Mindstorms” S. Paperta? Ja uczyłem się Logo z książeczki, której tytułu już nie pamiętam; było to chyba pod koniec lat 80-tych, studiowałem ją „na sucho”, bo jeszcze nie miałem komputera (dopiero później dostałem C-64…). Nie wiem, jak to powiedzieć po polsku – Amerykanie powiedzieliby „it blew my mind”. Kiedy doszedłem do funkcji, która dostawała nazwę i listę poleceń, i definiowała nową funkcję z podaną listą poleceń jako „ciałem”, musiałem wydać z siebie wielkie „wow”. No i na wiele lat zostałem z problemem (teoretycznym), co będzie, jeśli napiszę funkcję, która przedefiniowuje sama siebie;-). (Oczywiście, teraz już wiem – ale potrzebowałem na to ponad 20 lat…)

      Re 5: He, he. W kodzie maszynowym chyba w ogóle nie ma „expressions” (przynajmniej tak było, kiedy ja się troszkę uczyłem asemblera – ale to było wiele generacji procesorów temu…).

      A mówiąc serio: naprawdę jest dużo ładniej, jeśli są tylko wyrażenia (ewentualnie z efektami ubocznymi). I nie tylko ładniej, ale i praktyczniej – można wtedy robić rzeczy w stylu „print (if odd(n) ‚nieparzysta’ else ‚parzysta’)” (wiem, głupi przykład); bez tego jest jednak troszkę mniej zręcznie.

      Wykłady będą dla Ciebie oczywiście bardzo łatwe – one są dla początkujących. Ale ja np. troszkę się z nich nauczyłem, a nawet, gdy niczego nowego się z danego wykładu nie dowiedziałem, z wielką przyjemnością je oglądałem. No, i wykład o metacircular evaluator to majstersztyk.

      Re 6: zgadzam się, nawet nie tylko w dużych projektach. Zdanie o „wspólnych abstrakcjach” mocno mnie przekonuje, choć oczywiście w tym momencie już od języka zależy, czy to będą bardziej wzorce projektowe, czy po prostu idiomy danego języka – ale w tym momencie to już szczegół.

      Nie brałem nigdy udziału w dużym projekcie programistycznym, ale brałem udział w paru średnich/dużych projektach innej natury, i nie spodziewam się, żeby (przynajmniej niektóre) różnice były bardzo duże. Główny problem, jak się zdaje, można streścić uroczym porzekadłem: „trochę człowieka, i technika zaraz się gubi”… Domyślam się też, że wzorce projektowe są tylko częścią procesu budowania czy tworzenia wspólnych abstrakcji.

      I jeszcze a propos dużych (i niekoniecznie dużych) projektów: cytat niekoniecznie bardzo związany z tematem, ale przypomniał mi się, i jest uroczy (i prawdziwy):
      Any software project is a collaborative project. It has at least two developers, the original developer and the original developer a few weeks or months later when the train of thought has long left the station. (http://who-t.blogspot.com/2009/12/on-commit-messages.html)

      7. Jasne, to było trochę sarkastyczne. Ale nawet, jeśli klasa nazywa się krócej, jednak jest tu pewien problem, czyli duplikacja. Sytuacja, w której człowiek musi dwa razy wpisać to samo niemal zawsze oznacza, że coś jest nie tak. (Oczywiście, w praktyce pewnie robią to IDE czy jakiś system „snippetów” czy coś tam. Ale znów: skoro tak, to czemu nie kompilator?) Chociaż oczywiście, mając do wyboru to i gp1 i gp6, wolę to (mimo mojej szczerej niechęci do CamelCase’u, który jest strasznie mało czytelny – a przynajmniej ja nie umiem go czytać).

      Pozdrawiam

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *