Niebezpieczne Java-Szkoły

Immortal84

Oryginalny artykuł: The Perils of JavaSchools

Autor: Joel Spolsky

Tłumaczenie: Marek Stój (z www.devblogi.pl)

Leniwe dzieciaki.

Gdzie się podział kult ciężkiej pracy?

Niewątpliwą oznaką mojego starzenia się jest biadolenie i zrzędzenie, jaka to beznadziejna jest "ta dzisiejsza młodzież". Jeśli coś wymaga od nich wysiłku, to im się nie chce albo nie potrafią.

"Byłeś szczęściarzem. My to przez trzy miesiące musieliśmy mieszkać w pojemniku septycznym wyściełanym zwykłym kartonem. Musieliśmy wstawać o szóstej rano, czyścić karton, jeść twardy jak kamień chleb i gonić do pracy przy młynie, dzień w dzień, po czternaście godzin, a gdy wracaliśmy do domu, ojciec tulił nas do snu przy pomocy paska." — Latający Cyrk Monty Pythona, Four Yorkshiremen

Gdy ja byłem dzieckiem, uczyłem się programować na kartach perforowanych. Jeśli zdarzyło Ci się popełnić jakiś błąd, nie miałeś do dyspozycji żadnych nowoczesnych ficzerów, takich jak na przykład klawisz Backspace. Musiałeś wyrzucić kartę i zacząć od nowa.

Gdy w roku 1991 zaczynałem przeprowadzać rozmowy kwalifikacyjne z programistami, zazwyczaj pozwalałem im wybrać język programowania, w którym chcieliby rozwiązać postawiony przed nimi problem. 99% z nich wybierało język C.

W obecnych czasach wybierają Javę.

Nie zrozumcie mnie źle: Java, jako język stosowany w praktyce, jest całkiem w porządku.

Chwila, chciałbym inaczej sformułować tę myśl. Nie twierdzę wcale, w tym konkretnym artykule, że z Javą, jako językiem stosowanym w praktyce, jest coś nie tak. Z Javą wiele rzeczy jest nie w porządku, ale to musi poczekać na kolejny artykuł.

Twierdzę natomiast, że Java, generalnie, nie jest wystarczająco trudnym językiem, by móc go użyć do odróżnienia programisty przeciętnego od wybitnego. Być może jest to język, w którym wygodnie się pracuje, ale nie to jest dzisiejszym tematem. Mógłbym nawet pójść dalej i powiedzieć, że to, że Java jest stosunkowo łatwym językiem, to ficzer, a nie bug. Ale nie zmienia to faktu, że problem, o którym wspomniałem, wciąż istnieje.

Być możę zabrzmię trochę arogancko, ale moje skromne doświadczenie nauczyło mnie, że na uczelniach, na których wykłada się informatykę, tradycyjnie są dwa zagadnienia, ktorych wiele osób nigdy nie będzie w stanie w pełni pojąć: wskaźniki i rekurencja.

Na studiach dosyć szybko zaczynasz mieć do czynienia ze strukturami danych -- listami połączonymi, tablicami haszującymi itp. Bez wskaźników ani rusz. Tego typu przedmioty często służą do selekcji pierwszoroczniaków: są tak trudne, że każdy, kto nie jest w stanie podjąć umysłowego wyzwania, w końcu się poddaje. I dobrze. Jeśli sądzisz, że wskaźniki są trudne, poczekaj, aż przyjdzie Ci udowodnić coś w teorii punktu stałego.

Historia wielu dzieciaków, którym w liceum dobrze szło programowanie w BASICu kolejnych wersji Ponga, jest taka, że po pójściu do koledżu, zapisaniu się na przedmiot CompSci 101 (struktury danych) i zetknięciu ze wskaźnikami, ich mózgi zwyczajnie eksplodują. Nawet się nie spostrzeżesz, gdy okazuje się, że decydują się jednak skończyć nauki polityczne, bo ten kierunek wydaje im się lepszym pomysłem. Widziałem wiele statystyk pokazujących liczbę studentów, którzy rezygnują ze studiów informatycznych. Zazwyczaj oscylują one w granicach 40% - 70%. Uniwersytety mają skłonność do widzenia tego jako jakiejś straty; Ja z kolei uważam, że to po prostu niezbędny odsiew ludzi, którzy nie byliby szczęśliwi, bądź nie odnieśliby sukcesu, jako programiści.

Innym przedmiotem, sprawiającym wiele trudności młodym studentom informatyki, był ten przedmiot, na którym uczono programowania funkcjonalnego (również programowania rekurencyjnego). MIT postawiło wysoką poprzeczkę, tworząc obowiązkowy kurs (6.001) i wydając podręcznik (Structure and Interpretation of Computer Programs, Abelson & Sussman). Na wielu topowych uczelniach informatycznych używano ich jako de facto wprowadzenia do informatyki. (Masz możliwość, i powinieneś, obejrzeć online starszą wersję tych wykładów.)

Poziom trudności tych kursów jest zdumiewający. Na pierwszym wykładzie poznajesz właściwie wszystko na temat języka Scheme i przedstawiają Ci funkcję z punktem stałym, która na wejściu bierze inną funkcję. Gdy sam walczyłem z tym przedmiotem na Uniwersytecie w Pensylwanii, widziałem jak wielu, jeśli nie większość, studentów po prostu nie dawała rady. Materiał był za trudny. Napisałem wtedy długiego, rzewnego maila do profesora, w którym żaliłem się, że to Nie W Porządku. Ktoś na uniwersytecie musiał mnie posłuchać (albo jednego z innych narzekających), ponieważ teraz, przy prowadzeniu tego kursu, używa się Javy.

Żałuję, że posłuchali.

Myślisz, że się nadajesz? Sprawdź się!

W tym tkwi problem. Lata narzekań leniwych studentów wraz z zarzutami ze strony przemysłu, jak to mało jest absolwentów informatyki, dały się we znaki i w ostatniej dekadzie spora liczba dobrych uczelni całkowicie przerzuciła się na Javę. Super, rekruterom, którzy używają "grepa" do filtrowania życiorysów, to się podoba, i, co najlepsze, żaden aspekt Javy nie jest na tyle trudny, by można było odsiać tych programistów, którzy nie posiadają części mózgu odpowiadającej za wskaźniki i rekurencję, więc statystyki rezygnacji są niższe, a wydziały informatyki mają więcej studentów, wyższe budżety, i wszystko idzie dobrze.

Tym szczęściarzom z Java-Szkół nigdy nie będzie dane zobaczyć dziwnych segfaultów podczas próby implementacji tablic haszujących za pomocą wskaźników. Nigdy nie będą rwać sobie włosów z głowy podczas prób upakowania czegoś w jak najmniejszej liczbie bitów. Nigdy nie będą musieli wytężać swoich umysłow, aby zrozumieć jak to jest, że w czystym języku funkcjonalnym, wartość zmiennej nigdy się nie zmienia, a jednak zmienia się cały czas. Paradoks!

Nie potrzebują tej części mózgu, aby dostać 4 z obrony.

Czy nie jestem przypadkiem jednym z tych staroświeckich maruderów, jak w Four Yorkshiremen, przechwalających się, jakim to twardym trzeba było kiedyś być, żeby to wszystko przetrwać?

Cholera, w roku 1900 łacina i greka były obowiązkowe w koledżu, nie dlatego, że były do czegoś potrzebne, ale dlatego, że uważało się ich znajomość za całkiem oczywistą wśród wykształconych ludzi. W pewnym sensie moje argumenty nie róźnią się niczym od tych przedstawianych przez zwolenników łaciny (wszystkich czterech). "[Łacina] ćwiczy umysł. Ćwiczy pamięć. Rozszyfrowywanie łacińskich zdań jest doskonałym ćwiczeniem myślenia, prawdziwą intelektualną zagadką, oraz dobrym wprowadzeniem do logicznego myślenia.", pisze Scott Barker. W dzisiejszych czasach ciężko jednak znaleźć jakiś uniwersytet, na którym nauka łaciny byłaby wymagana. Czy wskaźniki i rekurencja są łaciną i greką informatyki?

Przyznaję, że programowanie z użyciem wskaźników nie jest potrzebne w 90% kodu pisanego w dzisiejszych czasach, byłoby to wręcz niebezpieczne w kodzie produkcyjnym. W porządku. A programowania funkcjonalnego nie używa się za wiele w praktyce. Zgoda.

Jednakże są to rzeczy ważne, gdy chce się brać udział w niektórych z najbardziej ekscytujących projektów programistycznych. Przykładowo, bez wskaźników nigdy nie będziesz w stanie pracować nad jądrem Linuksa. Nie zrozumiesz nawet jednego wiersza kodu Linuksa (ani żadnego innego systemu operacyjnego) bez dogłębnego zrozumienia wskaźników.

Bez zrozumienia programowania funkcjonalnego nie wymyślisz MapReduce, algorytmu, który sprawia, że infrastruktura Google jest tak skalowalna. Pojęcia Map i Reduce pochodzą od Lispa i ogólnie od programowania funkcjonalnego. Koncepcja MapReduce, patrząc z perspektywy czasu, powinna być trywialna dla każdego, kto ze studiów pamięta, że programy napisane w czystym języku funkcjonalnym nie mają efektów ubocznych i dzięki temu łatwo da się je zrównoleglić. Sam fakt, że to w Google, a nie w Microsofcie, wynaleziono MapReduce, po części tłumaczy, dlaczego Microsoft wciąż męczy się z implementacją najprostszych funkcjonalności dotyczących wyszukiwania, podczas gdy Google zajął się już kolejnym problemem: budową SkynetuHHHHHH - największego na świecie równoległego superkomputera. Sądzę, że Microsoft nie zdaje sobie sprawy, jak daleko jest w tyle.

Poza dostrzegalnym na pierwszy rzut oka znaczeniem wskaźników i rekurencji, ich prawdziwą wartością jest to, że sama nauka o nich daje Ci pewną elastyczność umysłową, niezbędną, aby budować duże, skomplikowane systemy; Wymagają tej mentalnej postawy, która sprawia, że udaje Ci się uniknąć odsiewu na pierwszym roku studiów. Wskaźniki i rekurencja wymagają umiejętności rozumowania, abstrakcyjnego myślenia oraz, co najważniejsze, spojrzenia na problem na wielu poziomach abstrakcji równocześnie. Tak więc zdolność rozumienia wskaźników i rekurencji jest bezpośrednio skorelowana ze zdolnością bycia ponadprzeciętnym programistą.

Fakt ukończenia Java-Szkoły nie ma w sobie nic, co pozwoliłoby od razu rozpoznać absolwentów, którym brakuje umysłowej zwinności pozwalającej zajmować się tymi koncepcjami. Jako pracodawca zauważyłem, że Java-Szkoły zaczynają produkować wielu absolwentów, którzy nie są na tyle bystrzy, by móc pracować w zawodzie programisty nad czymkolwiek bardziej skomplikowanym niż Kolejna Javowa Aplikacja Dla Księgowości, chociaż udało im się jakoś prześlizgnąć przez ten nowy, mocno uproszczony program studiów. Tym studentom nigdy nie udałoby się przetrwać kursu 6.001 na MIT czy CS 323 na Yale, i szczerze mówiąc, jest to jeden z powodów, dla którego ja, jako pracodawca, znacznie bardziej cenię dyplom z MIT czy Yale niż z Duke, które ostatnio całkowicie przerzuciło się na Javę, czy Penn, gdzie na kursie, który nieomal zabił mnie i moich znajomych (CSE121), języki Scheme i ML zastąpiono Javą. To nie tak, że nie chcę zatrudniać bystrzaków z Duke czy Penn -- chcę -- ale jest mi zdecydowanie trudniej ocenić, którzy to są. Kiedyś mogłem ich odróżnić, ponieważ Ci bystrzy potrafili przeanalizować rekurencyjny algorytm w kilka sekund albo zaimplementować funkcje operujące na listach połączonych tak szybko, jak tylko umieli pisać na tablicy. W przypadku absolwenta Java-Szkoły, nie wiem, czy nie radzi on sobie z tymi problemami dlatego, że jest niedoedukowany, czy też może dlatego, że nie posiada on tej wyjątkowej części mózgu, której potrzebuje, by móc ponadprzeciętnie wykonywać swoją pracę jako programista. Paul Graham nazywa ich Blub Programmers.

Fakt, że Java-Szkoły nie odsiewają tych studentów, którzy nigdy nie będą znakomitymi programistami, jest wystarczająco przygnębiający. Uczelnie mogą powiedzieć, że to nie ich problem. Przemysł, a przynajmniej rekruterzy, będący zwolennikami grepa, wydają się być zadowoleni z tego, że uczy się Javy.

Ale Java-Szkoły odnoszą także porażkę, nie ćwicząc umysłów studentów, by byli oni na tyle biegli, sprawni i elastyczni, by dobrze projektować oprogramowanie (i nie mam tutaj na myśli projektowania obiektowego, gdzie spędzasz niezliczone godziny na przepisywaniu kodu, aby przetasować hierarchię klas albo zamartwiasz się fałszywmi "problemami" w rodzaju has-a vs. is-a). Potrzebujesz treningu w myśleniu na wielu poziomach abstrakcji równocześnie, taki rodzaj treningu jest właśnie tym, co pozwoli Ci tworzyć znakomite architektury oprogramowania.

Być może zastanawiasz się, czy nauka programowania obiektowego (OOP - Object-Oriented Programming) jest w stanie zastąpić wskaźniki i rekurencję pod względem zdolności odsiewowej. Szybka odpowiedź: nie. Nie wdając się zbytnio w szczegóły, programowanie obiektowe nie jest wystarczająco trudne, aby odsiać przeciętnych programistów. Nauka programowania obiektowego w szkołach sprowadza się zazwyczaj do wkuwania pojęć w rodzaju "enkapsulacja" czy "dziedziczenie" i rozwiązywania testów wielokrotnego wyboru na temat różnic pomiędzy polimorfizmem i przeciążaniem. Będąc niewiele bardziej wymagającym niż zapamiętywanie znanych dat i nazwisk na lekcjach historii, programowanie obiektowe nie stanowi adekwatnego wyzwania umysłowego, aby odstraszyć pierwszoroczniaków. Gdy męczysz się z jakimś problemem z dziedziny programowania obiektowego, twój program ciągle działa, może jedynie być trudniejszy w utrzymaniu. Powiedzmy. Ale gdy walczysz ze wskaźnikami, a Twój program powoduje błąd segmentacji, nie masz pojęcia, czym to jest spowodowane, dopóki nie zatrzymasz się, nie weźmiesz głębokiego oddechu i naprawdę nie postarasz się zmusić swojego umysłu do pracy na dwóch różnych poziomach abstrakcji równocześnie.

A tak na marginesie, specjalnie ośmieszam tutaj rekruterów korzystających z grepa. Nie spotkałem nigdy nikogo, kto znałby Scheme, Haskella i C, a kto nie potrafiłby opanować Javy w dwa dni i tworzyć w niej lepszy kod niż ludzie z pięcioletnim doświadczeniem w Javie, ale spróbuj wytłumaczyć to przeciętnemu trutniowi z HR.

Co w takim razie z misją wydziałów informatyki? To nie są zawodówki! Ich celem nie powinno być nauczanie ludzi, jak pracować w przemyśle. To zadanie szkół pomaturalnych albo programów rządowych dla pracowników zmuszonych do przekwalifikowania się. Uczelnie powinny oferować studentom podstawowe narzędzia na całe życie, a nie przygotowywać ich do pracy przez kilka pierwszych tygodni. Prawda?

cs1.png

Informatyka to dowody (rekurencja), algorytmy (rekurencja), języki (rachunek lambda), systemy operacyjne (wskaźniki), kompilatory (rachunek lambda) -- chodzi mi o to, że taka Java-Szkoła, na której nie wykłada się C ani Scheme, tak naprawdę nie uczy również informatyki. Jakkolwiek bezużyteczne w prawdziwym świecie może wydawać się pojęcie rozwijania funkcji (ang. function currying), to jego znajomość powinna być oczywistym wymogiem dla absolwentów informatyki. Nie mogę zrozumieć, dlaczego profesorzy, którzy biorą udział w ustalaniu programu studiów, zgodzili się na takie uproszczenia, które w rezultacie sprawiają, że uczelnie nie są w stanie produkować programistów zdolnych do wykonywania swojego zawodu. Co więcej, nie są nawet w stanie wyprodukować absolwentów, którzy podejmą studia doktoranckie a w przyszłości powalczą o tytuły profesorskie. Chwila. Nieważne. Może jednak rozumiem.

Właściwie to jeśli cofnąć się w czasie i przyjrzeć dyskusjom toczonym w środowiskach akademickich podczas Wielkiego Przewrotu Javowego, można zauważyć, że największym zmartwieniem było to, czy Java jest wystarczająco prostym językiem, aby używać go w celach dydaktycznych.

Mój Boże, pomyślałem, oni chcą pójść jeszcze dalej z tym upraszczaniem programu studiów! Może powinniśmy podawać studentom wszystko na tacy? Niech asystenci zdają za nich egzaminy. Jak ktokolwiek ma się czegoś nauczyć, jeśli program studiów został starannie zaprojektowany w taki sposób, aby uczynić wszystko łatwiejszym niż jest? Zdaje się, że w planach jest nawet utworzenie specjalnej grupy zadaniowej, której celem miałoby być opracowanie podzbioru Javy, którego używano by do nauczania studentów i stworzenie dokumentacji ukrywającej cały ten bajzel EJB/J2EE przed ich wrażliwymi umysłami, dzięki czemu nie musieliby zaprzątać swoich małych główek tymi wszystkim klasami, niepotrzebnymi do rozwiązania i tak coraz łatwiejszych zadań informatycznych.

Najzabawniejszym wytłumaczeniem, dlaczego wydziały informatyki są tak skłonne do upraszczania swoich programów nauczania, jest to, że dzięki temu mają więcej czasu na naukę naprawdę istotnych koncepcji informatycznych, że nie muszą marnować dwóch wykładów na wyjaśnianie studentom różnicy między javowym słowem kluczowym int a klasą Integer. Cóż, jeśli istotnie tak jest, to kurs 6.001 ma dla nich idealną odpowiedź: Scheme, dydaktyczny język tak prosty, że bystrym studentom można wyłożyć go w ciągu 10 minut; potem cały semestr można poświęcić na teorię punktu stałego.

Heh.

Wracam do zer i jedynek.

(Miałeś jedynki? Szczęściarz z ciebie! My mieliśmy tylko zera.)


Jeśli spodobał Ci się ten artykuł, zajrzyj na www.devblogi.pl, gdzie regularnie zamieszczamy tłumaczenia najpoczytniejszych blogów o tworzeniu oprogramowania.

Wszelkie prawa do zamieszczonego tłumaczenia są zastrzeżone; prawa autorskie do tłumaczenia zachowuje tłumacz.

Pozdrawiam,
Marek Stój


7 komentarzy

Czy ja wiem czy wskazniki to cos trudnego? albo reukrencja? a co tu trudnego? chyba gorzej ugotowac obiad niz zrobic funkcje do np obliczania silni :) pozatym wszystko mozna zrobic w basicu i tylko tacy MISZCZOWIE powinni nauczac na studiach :) np Przegladarka internetowa napisana w basicu pod dzialajaca np na comodore :P

@koziolek: Tak, masz całkowitą rację, nawet co do tego, że moje podejście jest pod wieloma względami złe. Nie stwierdzam, że korzystanie z gotowców jest niepoprawne (wiem - tak to zabrzmiało w poprzednim komentarzu), ale bardziej chodzi mi o to, że wieeelu ludzi używa gotowców nie mając nawet pojęcia jak dokładnie działają dane funkcje (a to moim zdaniem podstawa - jak czegoś nie rozumiesz, to tego nie używaj) i od razu uważają się za programistów, a tak naprawdę program robi za nich większość (problem w tym, że nie mają pojęcia że coś takiego ma miejsce). Poza tym kolejny problem jest taki, że wiele programów przez to powstaje w Javie w miarę szybko i ich autorzy nie mając pojęcia co naprawdę napisali wypuszczają to do użytku publicznego, bo uważają, że zrobili coś dobrego (a jak wspomniałem wcześniej - nie mają o tym pojęcia i nie potrafią tego ocenić, czy to dobre czy złe).
Co do korzystania z gotowców, to jasne, że używam takowych (chociażby podstawowe biblioteki c++ lub api windowsa czy opengla), ale nie robię tego tak, że coś działa "na słowo honoru" (chyba, że w grę wchodzi zaliczenie przedmiotu:P).

PS: A co do tego, że nie język czyni programistę, to zgadzam się z Tobą w 100%, ale i ze stwierdzeniem z powyższego tekstu "Nie spotkałem nigdy nikogo, kto znałby Scheme, Haskella i C, a kto nie potrafiłby opanować Javy w dwa dni i tworzyć w niej lepszy kod niż ludzie z pięcioletnim doświadczeniem w Javie". Nie twierdzę, że doświadczenie kogoś, kto pisze w Javie jest nic nie warte - raczej twierdzę, że chodzi tu o kogoś, kto zna Javę, a nigdy nie miał do czynienia z innymi językami. No ale to może być moje subiektywne odczucie co prawda, bo wcale za jakiegokolwiek programistę się nie uważam.
Pozdrawiam.

@Dannte, tylko, że artykuł nie jest o Javie jako takiej. Artykuł porusza problem kształcenia informatyków i dążenia do ilości nie jakości. Zaręczam ci, że to nie język czyni programistę i w przypadku Javy "pisanie skryptów" jak sam to nazwałeś też jest sztuką. Na nieszczęście dla wielu ludzi pisanie oprogramowania stało się przemysłem i sercem innych gałęzi przemysłu. Java jest obecnie jednym z najlepszych narzędzi, które wykorzystujemy.
Swoją drogą jeżeli cały swój kod opierasz tylko i wyłącznie na własnej działalności i nie wykorzystujesz gotowego kodu bibliotecznego, w co nie wierzę, to raczej źle świadczy o twoim podejściu do programowania (tu ja jestem złośliwy). Jakość kodu potwierdzona testami, jego przejrzystość, skalowalność i co najważniejsze możliwość powtórnego wykorzystania, po to by nie tracić czasu na wymyślanie koła od nowa to zadania jakie stawia przed każdym programistą współczesny świat.
Jeżeli chodzi o matematykę to popatrz na inżynierów i informatyków zatrudnionych w przemyśle. Wykorzystują oni gotowy kod. Biblioteki numeryczne, biblioteki fizyki i chemii. Wszystkie one są elementami, które odpowiednio wykorzystane pozwalają na szybsze tworzenie oprogramowania. Wykorzystywanie czyjejś pracy, gotowego kodu, jest dobre ponieważ pozwala nam skupić się na zadaniu, a nie na walce z kolejnym mało istotnym aspektem gdzieś głęboko w systemie.

Zresztą jeżeli mowa o wykorzystaniu czyjejś pracy to należy tu wspomnieć, że jedną z głównych myśli przyświecających ruchowi wolnego oprogramowania było właśnie współdzielenie się kodem. Richard Stallman rozumiał, że jedynie taka działalność pozwoli na przeniesienie informatyki do przemysłu i biznesu na szeroką skalę. Pozwoli na dostarczanie rozwiązań, które będą w całkowity i doskonały sposób pokrywać zapotrzebowanie klienta.

Pojęcie Java-Szkoły dotyczy szkoły, która produkuje techników-programistów. Przedstawicieli zapomnianego zawodu z którego rozkwit przypada na okres od połowy lat sześćdziesiątych do początku lat osiemdziesiątych. Zajmowali się oni przenoszeniem na karty perforowane algorytmów opisanych za pomocą schematów blokowych. Później pojawiły się narzędzie takie jak edytory kodu i "ludzie dziurkacze" przestali być potrzebni.
Język Java stał się swoistą "ofiarą" autora ponieważ zaczął być nauczany na kierunkach nieinformatycznych jako najprostsze narzędzie pozwalające na programowanie komputera.

Na zakończenie dodam, że przenoszenie pomysłu biznesowego na algorytm jest samo w sobie nadal skomplikowanym zadaniem, które pochłania czas, a tym samym pieniądze, i należy dążyć do osiągnięcia jak największej wydajności w jego realizacji. W przeciwnym wypadku komputery przestaną być potrzebne, gdyż będą generować koszty nie przynosząc żadnych zysków.

Jeden z najlepszych artykułów jakie czytałem na 4p! Polecam każdemu przeczytanie :)

Ogólnie całe devblogi jest niezłe, polecam! :-)

Dzięki za wyłapanie tego linka. Ja znalazłem coś takiego: http://jtf.acm.org/rationale/rationale.pdf Można tam przeczytać to, o czym pisał Joel, a mianowicie:

"The Task Force issued a request last spring to the SIGCSE community
seeking feedback on the problems people have encountered in teachin
Java and the solutions they have developed in response. We spent t
remainder of the year (and the first month of this one) reviewing
those suggestions and using them to guide the design of a small set
of packages intended to simplify the use of Java in introductory
courses."

:]

Super artykuł! Cieszę się, że jest ktoś, kto podziela moje zdanie nt. Javy. Kiedyś znalazłem też taki fajny artykuł na temat Java vs C i było tam takie ciekawe stwierdzenie, że "C jest sztuką, natomiast Java tylko rzemiosłem" :)
Poza tym dodałbym do tego, że w skład informatyki wchodzi także matematyka (przede wszystkim przy liczeniu złożoności algorytmu, co w Javie jest zupełnie nieważne, bo liczy się fakt w jak krótkim czasie napiszesz program - albo sam się za ciebie tak naprawdę napisze - a nie to w jak krótkim czasie będzie on działał (to samo ze zużyciem pamięci)).
Ja czasem (albo po prostu w większości wypadków) sobie myślę, że nie ma czegoś takiego jak programista Javy, bo według mnie to nie jest programowanie tylko pisanie skryptów (tutaj akurat celowo jestem złośliwy), bo nie pisze się nic własnego tylko wykorzystuje gotową funkcjonalność, a własna jest tylko struktura klas. Ale prawda jest taka, że napisanie czegoś miłego dla oka w C zajmuje więcej czasu niż w Javie, jednakże zanim przewalisz się przez CZYJĄŚ dokumentację zanim coś napiszesz w Javie trwa odpowiednio dłużej, więc nie wiem kto wymyślił stwierdzenie, że Java jest lepsza pod tym względem od języków takich jak C?

No dobra wyżaliłem się trochę :D Ale artykuł przedni, naprawdę. Pozdrawiam.

PS: Ten link o grupie zadaniowej http://www.sigcse.org/topics/javataskforce/java-task-force.pdf nie działa.