środa, 13 października 2010

Przyczyna całego zła

Dziś kolejny post z serii geek humor.

Prawdopodobnie odkryłem przyczynę całego zła w projektach, bałaganu, złego designu modelu obiektowego i naszego ulubionego kodu spaghetti.

Jest nią najprawdopodobniej totalnie niezrozumienie polimorfizmu!

Tutaj znajdziemy oświecenie: http://www-users.mat.umk.pl/~grzegorz/polymorphism.pdf
.. gdyby tak każdy programista się z nim zapoznał, to świat byłby lepszy;)

//===============================

Jeżeli macie jakieś ciekawe materiały edukacyjne to wklejajcie w komentarzach.

23 komentarze:

Irek Matysiewicz pisze...

woow, to rozwiązuje wszystkie moje problemy! :-)

Unknown pisze...

>Tutaj znajdziemy oświecenie: >http://www-users.mat.umk.pl/~grzegorz>/polymorphism.pdf

Aaaa! No właśnie! Cały czas mi coś w tej obiektowości nie grało!

Czujnik pisze...

No i wszystko jasne :)
Swoją drogą to bardzo przypomina moją pracę magisterską. Wzory, wnioski,... a na końcu i tak nikt nie wie po co to komu. Ciekawy sposób na "naprawienie świata"

kolegazroku pisze...

http://mathfail.com/2010/05/quick-joke.html

pawelstawicki pisze...

Już chciałem stać się lepszy, a tu link nie działa :( Może ktoś pobrał i mógłby gdzieś udostępnić?

Irek Matysiewicz pisze...

Jest kopia: http://web.archive.org/web/20061130074915/http://www-users.mat.uni.torun.pl/~grzegorz/polymorphism.pdf

Koziołek pisze...

Boskie... swoją drogą czy my już zapominamy, że za informatyką... wróć... programowaniem stoi tak naprawdę matematyka i to, że dziś używamy języków wysokiego poziomu ma swoje źródła w takich właśnie rozważaniach?

Jakub Kurlenda pisze...

O to to to ;) W końcu prosto, przejrzyście i na temat!

Sławek Sobótka pisze...

@koziołek
Generalnie tak - podobno:)
Przynajmniej tak twierdzą Ci, którzy chcą się "podczepić" pod intratną branżę:P
Na tyle na ile orientuję się w matematyce (tej wyższej) to zawsze znajdziemy sobie w niej jakiś byt, który da się "kształtem" dopasować do bytów realnych. Np. w fizyce przybliżanie świata równaniami jest po prostu praktyczne i użyteczne do jakiś celów. Co prawda nie mamy pojęcia np. co tam w środku sobie faluje (w sensie esencji), ale mamy równania, które w miarę dokładnie opisują zjawisko ilościowo.

Ale czasem bywa tak, że gdy matematyk weźmie się za coś konkretnego to owszem, zawsze sobie jakiegoś potworka do dopasowania znajdzie w przestrzeni swoich bytów. Pytanie tylko po co? Ichni onanizm?

Co do OO konkretnie, to z opowieści Uncle Boba wynika, ze chłopaki chcieli się po prostu pobawić w trzymanie zmiennych na stercie:) Na początku wcale nie było żadnych zbiorów omega.

http://art-of-software.blogspot.com/2009/11/geneza-i-ograniczenia-oo.html

Koziołek pisze...

@Sławek, "Ale czasem bywa tak, że gdy matematyk weźmie się za coś konkretnego to owszem, zawsze sobie jakiegoś potworka do dopasowania znajdzie w przestrzeni swoich bytów. Pytanie tylko po co? Ichni onanizm?"

Tak. Po prostu oni są dziwni.

"Co do OO konkretnie, to z opowieści Uncle Boba wynika, ze chłopaki chcieli się po prostu pobawić w trzymanie kodu na stercie:) Na początku wcale nie było żadnych zbiorów omega."
Tylko, pewno ktoś chciał się poonanizować intelektualnie.

Zresztą tak jest z wieloma rzeczami. Diagramy Feynmana też zostały wymyślone by obliczyć ruch latającego po akademickiej stołówce talerza.

To jest właśnie innowacyjność.

Irek Matysiewicz pisze...

Wszelkie abstrakcje (definicje, twierdzenia, dowody, ...) wprowadza się po to, by rozwiązać problemy, które trudno by było rozwiązać bez abstrakcji. Tu facet wprowadził abstrakcje opisujące polimorfizm, ale żadnych rzeczywistych problemów nie rozwiązał.

Irek Matysiewicz pisze...

Zresztą pomijając sam artykuł, jest to dobra lekcja dla programistów: czasami każdy potrafi "przeprojektować", wprowadzając np. zbyt generyczne rozwiązania tu gdzie nie są potrzebne a jedynie komplikują kod.

Anonimowy pisze...

O mój profesor ze studiów :)

Sęk w tym, że wcale to co napisałeś nie musi być żartem.

Ten tekst jest dość zjadliwy, jeśli tylko wyściubi się czasami nosa poz javę, obiektowość i 'dziedziczenie'. Nie cały świat składa się z języków obiektowych, nie każdy problem najlepiej opisać bytami jakim są obiekty.

Czasami lepsze są rozwiązania i podejścia. A jak się okazuje polimorfizm nie jest cechą wrodzoną języków obiektowych.

To co tutaj jest opisane to polimorfizm parametryczny, prawie w dokładnie takiej samej postaci jaką mamy od jakichś 20 lat w Haskellu czy 30 w OCamlu, czy od 5 w... scali. I tak... to jest podstawą sporej klasy języków. I te języki istnieją ponieważ ktoś kiedyś odrobił zadanie takie jak powyższe (i kilka bardziej złożonych). Nie każdy język ma budowę cepa jak się okazuję, i działa z podobną gracją :->

Kiedyś Stefan Banach powiedział:

"Good mathematicians see analogies. Great mathematicians see analogies between analogies"

Ale wracając do tematu. ADT (algerbaic data types), parametric polimorphis (opisane w tym dokumencie) to nie jest abstrakcja. To jest coś co jest podstawą Haskella czy OCamla.

Warto czasami rozglądnąć się poza nasz ogródek i odkryć, że ludzie już dawno rozwiązali problemy z jakimi dzielnie jeszcze walczy java.

Sławek Sobótka pisze...

@Artur
1. Dzięki za abstract tekstu - teraz jest bardziej zjadliwy.

2. Masz rację co do Javy. Składania jest prosta, wręcz prymitywna, ale znając historię i założenia można uznać, że taka właśnie miała być. Co do wsparcie dla konstruktów rzeczywiście jest ubogie - ale jest to język przemysłowy - więc znowuż taka była intencja.

Co do polimorfizmu parametrycznego to czasem odczuwa się jego brak. Ale tylko czasem... chociaż to może skutek nabytych nawyków myślenia. Co prawda można go emulować wzorcem Visitor i robi się to np we frameworkach. Natomiast w przemyśle enterpise daje się i bez tego przeżyć;P

3. Banach - tak... piękny cytat. Ja bym go uogólnił na każde zajęcie wymagające myślenia abstrakcyjnego.

4. Co do żartu to przyznaję, że jak zwykle: wyśmiewamy to czego nie rozumiemy:P
Dalej jednak nie przekonuje mnie czy aby na pewno powstawanie użytecznych składni jest wynikiem "odrabiania lekcji", o których piszesz, czy może raczej lekcje są "dorabiane" po tym jak ktoś "zauważy" coś pożytecznego. Pisząc "zauważy" mam na myśli nieuświadomione-bo nie operujące na symbolach, "intuicyjne" i "kojarzeniowe"-procesy myślowe, które zachodzą gdzieś w "prawej" półkuli.

Artur Karazniewicz pisze...

To co napisał Jarzembski jest w gruncie rzeczy dość proste, choć przyznaję, że może być lekko ezoteryczne ze względu na użyty język. Ale to podstawa podstaw do np. algorytmu Hindleya-Milnera, jak najbardziej praktycznego - podstawy całej klasy języków i takiej 'drobnostki' jak type inference. Bez tego i 'śmiesznego' języka matematyki nie byłoby Haskella, OCamla, F# czy scali. To już jest całkiem praktyczne. To na pewno nie jest kolejny 'freakout' na miarę antynobla.

A przy okazji artykuł pokazuje jeszcze jedną ciekawą cechę, o której pisałem przez przypadek całkiem niedawno na grupie WJUG: 'expression problem' (http://en.wikipedia.org/wiki/Expression_Problem), świetnie opisany tutaj: http://journal.stuffwithstuff.com/2010/10/01/solving-the-expression-problem/

Okazuje się, że kiedy zdefiniujemy typy (danych) tak jak pokazano w tym dokumencie jako ADT (algebraic data type) oraz polimorfizm jako (\omega, \sigma, sch) to mamy za darmo rozwiązany problem opisany jako: W jaki sposób możemy dodawać nowe operacje do istniejących typów? W językach z ADT jest to naturalne (pisałem o Haskellu i przykładzie w scali tutaj: http://j.mp/9QtjJ0). Ale czy to pytanie nie brzmi trochę znajomo? Oczywiście... bo to jest.. Visitor. Okazuje się, że w całej klasie języków, to z czym walczymy dzielnie w javie i innych językach bez ADT, za pomocą bardziej lub mniej pokracznych sztuczek, mamy za darmo. Świetna dyskusja na ten temat (case classes w scali to w przybliżeniu ADT) jest tutaj: http://j.mp/b1kebO . Najciekawsza jest wypowiedź Oderskyego (tak, autora scali i autora javac):

"Let me relate my experience to you: As you know I wrote the javac compiler with visitors and various ad-hoc solutions and I wrote most parts of the scalac compiler with case classes everywhere. The difference needs to be experienced to be believed. I would never, ever go back to a language that did not have case classes (or some equivalent) and pattern matching. Not if I wanted to write a compiler, or any other software that analyzes and transforms symbolic information."

Warto czasem rozglądnąć się w okół. Może się okazać, że walecznie wojujemy z problemami które stwarzają nasze narzędzia. A zamiast szukać ich rozwiązania to raczej szukamy nowych problemów dla nich. Trochę na zasadzie:

"When your hammer is C++|java|C#, everything begins to look like a thumb"

Ale zaraz... z tym młotkiem to szło chyba jakoś inaczej, nie? :D

Sławek Sobótka pisze...

Heh, właśnie tylko i wyłącznie o ten ezoteryczny język chodzi. Na pewno nie pomaga młodym adeptom w zrozumieniu clue problemu ani nie zwiększa ilości absolwentów, którzy mają intuicję do czego ADT służy i co wnosi.
Dla odmiany Ty na przykład opowiadasz (właśnie opowiadasz!) o tym samym, ale jednak jakoś inaczej:)

"When your hammer is C++|java|C#, everything begins to look like a thumb"
To się zgadza.
Ba, zakładam, że czytelnicy tego bloga raz na jakiś czas odrywają nos od ziemi, podnoszą głowę i rozglądają się wokół:P

Anonimowy pisze...

Arturze K.

Grzegorz J. to również mój profesor ze studiów, były profesor. Na szczęście bo te zajęcia jak i wiele innych na kierunku zwanym "informatyka" to tylko wypełniacze etatów dla matematyków na szybko przekwalifikowanych na wykładowców przedmiotów informatycznych. Przedmiotów które obłudnie w swojej nazwie mają wkomponowane słowo "programowanie" - tylko niestety po wejściu do sali prowadzący rozpoczyna pierwszy wykład od słów "rozważmy relację..." żeby pod koniec semestru zakończyć rozważania zdaniem "co należało wykazać".

Tutaj wcale nie chodzi o Javę i to że wszystko ma się kręcić wokół języków obiektowych.
Chodzi o to żeby studenta zapoznać z obecnymi trendami w projektowaniu i wytwarzaniu oprogramowania, zarówno rzeczy małych jak i systemów enterprise. Żeby nauczyć go myślenia i rozwiązywania rzeczywistych problemów. To tak w maksymalnym uproszczeniu.

Tymczasem jak jest każdy widzi. Ten cały skostniały mikrokosmos akademicki tworzy coś, co dla studenta jest magią uprawianą przez wtajemniczonych członków wydziałowego Towarzystwa Wzajemnej Adoracji. Następnie tej magii uczy się student zupełnie nie wiedząc po co, bo nikt nie podaje rzeczywistego przykładu zastosowania tych wszystkich zaklęć np. z algebry. Absolwent nie potrafi potem w pracy zastosować 90% rzeczy których musiał się nauczyć bo nie wie do czego służyły i w czym w rzeczywistości mogłyby pomóc. Ale gdyby tak zbudzić go w nocy to założę się że z pamięci wyrecytuje o co chodzi w dualnym algorytmie Symplex, czym są gramatyki bezkontekstowe, czym jest domknięcie Kleenego itp. To co jest potrzebne, musi nauczyć się sam od nowa i dopiero po studiach otwierają się oczy jakie to nieprzydatne głupoty zaprzątały umysł. Przykład rzeczywisty: przychodzi kandydat na rozmowę kwalifikacyjną, pada pytanie czy słyszał o czymś takim jak postać normalna bazy danych - oczywiście że słyszał, wie nawet jaka jest definicja którą przytoczy z pamięci, tylko że nie wie jak pokazać ją na przykładzie. Bo jej nie rozumie i tylko wyklepał na pamięć.

Ja również przebrnąłem przez Haskella i inne tego typu wynalazki z programowania równościowego i funkcyjnego, oraz szereg innych rzeczy z dorobioną ideologią do kierunku "informatyka", które nigdy mi się nie przydały. Większość przedmiotów określanych mianem "matematycznych podstaw informatyki" ma niewątpliwie znaczenie dla twórców kompilatorów lub podwalin nowych języków - ale czy jest ich tak dużo po studiach, żeby niczego nie zmieniać w programie nauczania? Stąd potem takie kurioza jak pisanie pracy magisterskiej z algebry na informatyce a na pytanie do promotora:
- panie profesorze, czy to o czym piszę gdzieś się wykorzystuje?
student słyszy:
- Żeby być szczerym, to chyba nigdzie.
To jest dopiero dramat.

Sławek Sobótka pisze...

Anonim poruszył dwa ważne zagadnienia:
- zrozumienie wiedzy
- przydatność wiedzy


Odnośnie zrozumienia, przekazywanej wiedzy to jest to ogólny problem - chyba każdy przyzna.
Problem pojawia się nawet na MIT: http://www.youtube.com/watch?v=WwslBPj8GgI Materiał trwa 80 minut ale zapewniam, że nie będziecie żałować.

Swoją drogą: kto spotkał nauczyciela/wykładowcę, który bazuje choćby na podstawach psychologii uczenia się i bierze pod uwagę, że "odbiorca" może mieć inne strategie kognitywne niż "nadawca"?

Nie każdy ma to szczęście aby dysponować specjalnymi uwarunkowaniami typu lekki autyzm, które pomagają we wchłanianiu przekazu niedostosowanego do profilu odbiorcy;)


Odnośnie przydatności wiedzy to wg mnie wciąż nie rozwiązano dylematu: jaka jest rola/misja placówek edukacyjnych?
Niektórzy chcieliby aby uniwersytet był wyrafinowaną szkołą zawodową, inni aby kształcił kadrę naukową... Jaka jest odpowiedź? Nie ma! Dla każdego coś miłego...

Wolny i całkowicie prywatny rynek edukacji pozwoliłby każdemu kupić sobie takie produkt na jaki ma ochotę. Dodatkowo wymusiłby utrzymanie odpowiedniego poziomu usługi przez dostawcę. A student zaciągający kredyt aby kupić sobie wiedzą dwa razy by się zastanowił czy aby na pewno chce "wchodzić w ten interes":)
Przy okazji zniknęłyby wylęgarnie bezrobotnych magistrów bawiących się przez 5 lat za nasze pieniądze:P

Anonimowy pisze...

@Sławek
Piszesz o rynku edukacji który "Dodatkowo wymusiłby utrzymanie odpowiedniego poziomu usługi przez dostawcę."

Podpisuję się pod tym. Tylko czy zdajesz sobie sprawę jaki to byłby przewrót na skostniałych uczelniach? Nagle okazałoby się, że co najmniej połowa tych obecnie "arcyciekawych inaczej" przedmiotów nikogo już nie interesuje i wykładowcy są zbędni. Przecież nikt przy zdrowych zmysłach nie płaciłby za buble, tylko wymagałby konkretów - mało tego, konkretów które interesują tego który płaci. Wtedy wiedza byłaby zrozumiała i przydatna (przynajmniej wg tego co za nią płaci).

Koziołek pisze...

@Sławek, nie zgodzę się, ze stwierdzeniem, że całkowicie wolny rynek edukacji jest taki fajny.
Niestety najlepszym przykładem jest to co stało się ze szkolnictwem zawodowym. Nikt nie otwierał "prywatnych zawodówek", ponieważ:
1. grupy docelowej nie było by stać na taką szkołę i to niezależnie czy dostawaliby te 30% "złodziejskich podatków" więcej czy nie.
2. koszty takiej szkoły są bardzo wysokie. Głupia tokarka kosztuje kilka tysięcy złotych i na jednej się nie skończy, a jak chcesz puszczać na rynek ludzi, którzy coś potrafią to musisz nauczyć ich pracy zarówno na starym jak i nowym sprzęcie. Jednocześnie zyski są niskie i niepewne, bo prestiż niski.
Dziś brakuje fachowców, a nadal nikt nie otwiera prywatnych szkół zawodowych.
Kiedyś o tym pisałem. Musi istnieć coś takiego jak edukacja publiczna, nawet MIT dostaje dotacje publiczne (ponad ich 50% budżetu!), bo bez niej nie będziemy kształcić pewnej grupy specjalistów, której nie opłaca kształcić się prywatnie.

Kolejna rzecz to celowość studiowania. Nadal wiele osób studiuje dla papieru. I sposób finansowania studiów nic nie zmieni. W masie studenckiej są hobbyści, którzy uczą się dla siebie i są goście, którzy chcą mieć papier. Dlatego ważne w procesie rekrutacji stało się weryfikowanie praktycznych umiejętności.

Ech... znowu muszę pisać na blogu...

Anonimowy pisze...
Ten komentarz został usunięty przez autora.
Anonimowy pisze...

@Anonimowy

Ciekawa się z tego wywiązała dyskusja. Masz zapewne sporo racji jeśli chodzi o typ wiedzy przekazywanej na studiach. Tak już jest - rozdźwięk na linii academics - practitioners. Świetny wykład na ten temat miał kiedyś Ted Neward (http://www.youtube.com/view_play_list?p=73C82CFC58AD6832 ). Warto posłuchać... i dowiedzieć się, że tak jest wszędzie. Że informatyka jest jednym z nielicznych kierunków, gdzie wykładowcy często nigdy lub kilkadziesiąt lat temu zrobili cokolwiek praktycznego. W odróżnieniu do wielu innych nauk. Żeby zostać profesorem medycyny należy zwykle mieć znaczące sukcesy, być doskonały chirurgiem, neurologiem... i informatyki? Ale czy to źle? Zależy od spojrzenia. Ja bym nie chciał aby na studiach uczono "praktycznego podejścia do problemów, rozwiązań korporacyjnych". Czemu? Bo to nie ma sensu. Nie da się "nauczyć" "systemów enterprise" na sucho. Tak jak nie da się nauczyć pływania na sucho. Przepracowałem wiele lat i stworzyłem wiele takich systemów aby wiedzieć o tym więcej niż lepiej. Co zatem lepsze, aby profesorowie uczyli teorii, którą znają doskonale; czy praktyki, której nie znają i znać nie mogą? Dla mnie odpowiedź jest oczywista. studia to taki czas, którego nie będziesz miał już nigdy. Na uczenie się abstrakcji, logiki, czasami bardzo, bardzo teoretycznej. Ale taki poligon, szkoła przetrwania dla mózgu. Poligon, który nigdy później się nie zdarzy. Namawiam każdego aby wykorzystał ten czas. Na pewno się opłaci. A... nudne "systemy enterprise"... jeszcze nadejdą i... wiele razy staną się nudne. Cholernie nudne. To moja perspektywa :).

Co do Haskella to mam tutaj bardzo silną opinię. Haskell to jeden z najlepszych i najbardziej zaawansowanych języków jakie są. Trzeba się go nauczyć aby to zrozumieć. Ale trzeba się go nauczyć aby dobrze rozumieć inne języki... i ich ograniczenia. Śmiem twierdzić, że poznawanie np. Scali bez znajomości Haskella może prowadzić do frustracji. Z Haskellem Scala ma o niebo więcej sensu.

Anonimowy pisze...

@Artur K.

A czy Arturze nie lepiej by było gdyby profesorowie poznali w końcu również wiedzę praktyczną i tę przekazywali studentom zamiast tych wszystkich wypełniaczy które tylko zajmują miejsce w pamięci?
Nie wierzę że nie da się nauczyć logicznego myślenia i rozwiązywania rzeczy praktycznych. Dlaczego? Bo jeśli są profesorowie którzy potrafią nauczyć studenta samodzielnego i rozumnego przeprowadzenia wielostronicowego dowodu, to znajdą się też profesorowie którzy w ten sposób przekażą jakże bardziej potrzebną wiedzę praktyczną.

Zgadzam się że studia to okres poligonu dla mózgu. Rozumiem też że taki poligon jest ważny żeby wyrobić w człowieku zdolności uczenia się. Ale na litość boską nie przez 5 lat za pomocą różnych dziwacznych przedmiotów wrzucanych do wora "informatyka". Niech to trwa pierwszy rok, drugi, ale nie więcej.

Co do Haskella to nigdy w pracy zawodowej nie miałem okazji go użyć, więc dla mnie pozostaje on ciekawostką ze studiów którą musiałem poznać - coś jak Fortran dla chłopaków z astronomii.