Ja wykladalem Ade na pewnym amerykanskim uniwersytecie, w
kontekscie pzredmiotu Real Time Programming.
Robiles systemy czasu rzeczywistego ?
| Z tego co widze, Ada'y sie nie uczy nie dlatego, ze Ada jest trudna, ani
| nie dlatego, ze Ada jest malo popularna i nie dlatego, ze Ada jest zlym
| jezykiem, jako jezyk ogolnego przeznaczenia. Ada'y nie uczy sie dlatego,
| ze Ada jest _zarazem_ zbyt malo popularna i zbyt praktyczna.
Ada JEST trudna, i ma te cenna wlasciwosc ze nie mozna jej sie nauczyc
"po kawalku".
Kazdy jezyk, ktorego standard jest tworzony globalnie i dla przemyslu musi
byc skomplikowany. Problemy, z ktorymi wtedy trzeba sie zmierzyc, sa
zupelnie innego kalibru. Zazwyczaj taki jezyk traci tez na regularnosci.
Zobacz np. jak wyglad ANSI CL.
Ada mozna nauczac po kawalku. Przynajmniej ja potrafie sobie wyobrazic jak
to robic (dokladnie tak jak sie robi w kursach i ksiazkach - najpierw
wprowadzamy niewielki podzbior Ada'y, mniej wiecej izomorficzny z tym co
mamy w Pascal'u ; ten podzbior mozna dalej walkowac tyle ile trzeba).
Pozatym, ja mowielem o czyms innym. Ja mowilem, ze powodem nienauczania
Ada'y nie jest jej trudnosc. Wiele uczelni caly czas naucza od C++.
Naprawde, ludzie sa w stanie sie wiele nauczyc... (tu sie o wiele bardziej
liczy skomplikowanie pojeciowe jezyka, niz skomplikowanie iloscia regul).
| Uczy sie Pascal'u,
| bo tak trzeba. Pascal jest do nauki programowania (niewazne, ze nawet sam
| jezyku...).
O.. A gdzie jeszcze uczy sie Pascala?...
Prawie wszedzie. Standard tworza trzy jezyki (w kolejnosci wyboru przez
uczelnie na pierwszy jezyk): Pascal, C, C++. Generalnie ekstrapolujac moje
lokalne obserwacje - Pascal jest na uniwersytetach (UG, UW i wiele innych
mniej znanych, ktore akurat ja znam), C++ na dobrych uczelniach technicznych
(w tym Twojej PW, PG, o ile pamietam PWr), a C na srednich i kiepskich
uczelniach technicznych.
Co nie oznacza, oczywiscie, ze innych jezykow tez sie nie naucza.
I co nie oznacza, oczywiscie, ze nauczanie tych jezykow na wszystkich typach
uczelni jest pozbawione sensu.
Teraz na ogol wszedzie zaczyna sie od Javy... Wspolbieznosc tez
najlepiej nauczac w Javie.
Chyba w Ameryce :-)
I calkiem slusznie nie naucza sie od Java'y. Nie wiem w jaki sposob
mozna mowic o obiektowce na pierwszym wykladzie. I nie wiem w jaki sposob
mowic o Java'ie nie poruszajac pojec natury obiektowej. Pisanie w Java'ie
bez znajomosci podstaw OO to jak jazda samochodem z zawiazanymi oczyma. Moze
i mozna, ale skutki moga byc nieciekawe...
Na dobrych uczelniach naucza sie Java'y szybko i dlugo, ale nie jako
pierwszego jezyka.
| Dlaczego nie nauczac od poczatku Ada'y... ? Po co zasmiecac wyklady
| kwestiami jezykowymi, zamiast skupic sie na meritum... ?
Ada ma OD CHOLERY kwestii jezykowych, znacznie wiecej i bardziej
skomplikowanych niz inny jezyk.
Nie przecze.
Moj zarzut byl inny. Najpierw naucza sie _jednego_ jezyka, dosc
durnego, zreszta, pozniej szybko okazuje sie, ze ten jezyk w ogole nie
wystarcza do kontynuowania nauki, wiec zaczyna sie nauczac _innego_, ten
inny z kolei, choc dosc prosty i ciekawy koncepcyjnie, jest zbyt odlegly od
tego, czego uzywa sie w praktyce i wprowadza sie jezyk _kolejny_.
Przez co spora czesc materialu nauczanego to robienie tych samych rzeczy w
_ten sam sposob_ w kilku roznych jezykach. W ten sam sposob, bo te trzy
jezyki sa z drugiej strony na tyle zblizone, ze proste zadania wykonuje sie
w nich niemal identycznie (a przynajmniej przez tak krotki czas, przez jaki
z owymi jezykami sie obcuje nie jest sie w stanie wykorzystac ich na tyle,
aby wykonywac roznie).
Te trzy jezyki to odpowiednio Pascal, Smalltalk i C++.
Efekt jest taki, ze ludzie nie sa w stanie skupic sie nad problemami jakie
maja rozwiazywac, nad paradygmatami programowania jakie maja poznawac, bo
zmuszani sa, co chwila, do przyswajania sobie kolejnych kwestii jezykowych.
Ja przesadzam z nauczaniem Ada'y. Faktem jednak jest, ze nie ma od czago
nauczac. Albo jezyki sa skomplikowane, albo zbyt odlegle od glownego kanonu
uzywanego przez przemysl.
Gdyby chciec nauczac "we wlasciwy sposob", to Ada jest chyba najblizej tego
jak powinien wygladac "startowy" jezyk programowania. Przy czym nawet nie
wiadomo, czy powinno sie nauczac "we wlasciwy sposob". Ja nie wiem.
Zawsze ciekawilo mnie dlaczego akademia az tak bardzo nienawidzi COBOL'u i,
z az takim uporem stara sie COBOL zniszczyc. Doszedlem do wniosku, ze w
COBOL'u jest cos, co akademie przeraza. Akadamia boi sie tego czegos tak
mocno, ze odruchowo stara sie niedopuscic do siebie calego COBOL'u, a jezeli
tylko COBOL zbyt mocno podejdzie - jak najszybciej usmiercic. Wiekszosc
ludzi z akademii COBOL'u kompletnie nie zna, ale nie przeszkadza im to
COBOL'u nielubic ani wypowiadac sie na jego temat.
Akademie przeraza w COBOL'u, ze jezyk bedacy dokladnym zaprzeczeniem
tego czego sie na akademii uczy, byl przez kilkadziesiat lat
najpopularniejszym jezykiem wykozystywanym przez przemysl, ze ten jezyk
zarobil biliony dolarow, ze programy pisane w tym jezyku, w sposob bedacy
kompletnym zaprzeczeniem tego czego sie uczy na akademii, majace po miliony
linii kodu, przezyly po kilkadziesiat lat - przez kilkadziesiat lat mogly
byc pielegnowane i dostosowywane do kolejnych wymagan.
Jak to mozliwe, ze w tak zlym jezyku, tak zle programy, majace po dziesiatki
milionow linii kodu, daja sie utrzymywac przez dziesiatki lat... ?
A tak w ogole, mniejsza czego nauczac informatykow...
Czego nauczac fizykow ?... czego nauczac matematykow ?...
Wiesz w czym teraz robi sie numeryke ? F90 zabil Fortran prawie kompletnie.
Z tego co sie slyszy, to ludzie albo zostali razem z Fortran'em 77, albo
przeszli na C (glownie), albo na C++. Ah... i najczesciej wspominaja stare
dobre czasy Algol'u (to matematycy), badz Fortran'u (to fizycy).
Matematyk to taki gosciu, ktory nie potrzebuje obiektowki, nie potrzebuje
jakiejs wyrafinowanej abstrakcji, nie potrzebuje nawet zbyt skomplikowanych
struktor danych. Matematyka najczesciej to kompletnie wali (znajdziesz powod
dla ktorego mialo by byc inaczej ?). Matematyk najczesciej chce shakowac
jakas procedure liczaca cos-tam i tyle.
Dla wielu F90 byl zbyt skomplikowany, aby mozna bylo sie w nim swobodnie
poruszac. W Java'ie beda potrafili sie poruszac... ?
BTW: Ja tez nie mam w czym robic numeryki. Moja ostatnia zabawa z C++
(ktorego jeszcze kilka lat temu znalem swietnie) skonczyla sie tym, ze po
kilkudziesieciu minutach zabawy w "gdzie pojechales wskaznikiem, ze program
sie sypie" komputer dostal porzadnego kopniaka, a calosc zostala przepisana
na Matlab.
| Np. na owej Pewnej Uczelni, od kilku lat najwiekszy problem smietanki
| profesorskiej zajmujacej sie obiektowka jest "znalezienie zastosowania
| dla zagniezdzonych klas w Java'ie". AFAIR sa ntt. juz nawet papiery :-)
Jeezzzz.... Przeciez o tym jest w ksiazkach ktore mozna kupic w
ksiegarni...
Nie, zapewniam, ze o czym pisze, jest duzo zabawniejsze.
"Problemem zagniezdzonych klas" jest, ze, w Java'ie, instancje klasy
zagniezdzonej sa zwiazane z instancjami klasy zewnetrznej. Tworzy sie cos w
rodzaju "domkniecia" - takie instancje maja dostep do srodowiska instacji
bedacej "wyzej". Komplikuje sie to wszystko, kiedy dochodzi dziedziczenie.
Glownie komplikuje sie rozstrzyganie jakie rzeczy maja byc dziedziczone i
ktore identyfikatory ktore przeslaniaja. Teoretycznie latwo jest to zrobic
"we wlasciwy sposob". Niestety, ten "wlasciwy sposob" moze prowadzic do
bzdurnych bledow, wynikajacych z przeoczenia czegos, lub czystej niewiedzy
ludzi piszacych, a w szczegolnosci modyfikujacych dany fragment kodu. Np.
identyfikator, ktory znajduje sie "leksykalnie najblizej" wcale nie musi byc
najblizszym identyfikatorem. Powiedzmy, ze mamy:
class A { int x ; } ;
class B {
int x ;
class C extends A { ... } ;
} ;
Odwolanie w srodku klasy "C" do "x" jest odwolaniem do "x" z "A". Wyobraz
sobie, ze klasa "A" jest spora i znajduje sie zupelnie w innym fragmencie
programu, a jakis programista wlasnie dostal zadanie zmodyfikowania "C" w
taki-a-taki sposob...
To nie jest dowod, ze mechanizm zagniezdzonych klas jest zly (choc moim
zdaniem, jest on bardziej skutkiem ubocznym wprowadzenia lokalnych klas niz
zamierzona wlasnoscia). Chce powiedziec o czyms innym.
Mianowicie, mechanizm zagniezdzonych klas sie latwo symuluje - wystarczy
przekazac "wewnetrznej" instancji, instancje "zewnetrzna" - podczas
inicjalizacji (taka transformacja jest lokalna - dziala instrukcja w
instrukcje).
Glowne pytanie jakie sie pojawia, jest takie (abstrachujac juz od jezyka),
"czy zagniezdzone klasy sa naprawde potrzebne ?". Ta odpowiedz w swietle
powyzszego zalezy od tego czy zagniezdzone klasy implementuja jakis istotna
czesc z poziomu pojeciowego (jezeli implementuja to odpowiedz nie jest
jednoznaczna). Ntt. mozna sie zastanawiac i pisac papiery (o ile nie ma tego
juz w ksiazkach :-)).
Ale owa smietanka profesorska zastanawia sie nad samym _mechanizmem_ i
gleboko wierzy, ze jest on czyms wielkim i waznym. Wiec, skoro, mechanizm
jest czyms wielkim i waznym to _trzeba_ znalezc dla niego zastosowanie. Te
poszukiwania, zaowocowaly jak na raziem znalezieniem, chyba, jednego
przykladu gdzie ten mechanizm sie sensownie stosuje (ja wiem o "szukaniu" od
dwoch lat, nie wiem kiedy dokladnie sie owe "poszukiwanie" zaczelo).
Zwroc uwage na sam sposob rozumowania.
Nie jest tak, ze mamy pewna klase problemow, ktore ciezko rozwiazuje
sie za pomoca bierzacych narzedzi, wiec opracowujemy nowe. Jest tak, ze
my mamy narzedzie i problem staje sie dopiero co z tym narzedziem zrobic.
Ktos wymyslil kubek z dziurka na dnie i zbiera sie sztab naukowcow aby
znalezc dla takiego kubka zastosowania (tak fajnie ten kubek wyglada, ze
przecierz _musi_ miec jakies zastosowanie). Po dwoch latach sztab naukowcow
odkryl, ze jak sie wsadzi w ta dziurke palec to
...
więcej »