1. Muze mi nekdo vysvetlit, v cem je vlastne Perl lepsi nez PHP ? Co se tyce vykonu - u Perlu je potreba pouzit
mod_perl, aby se kvuli spousteni nemuselo forkovat, pricemz rada cgi skriptu v Perlu fungovala dela tak, ze se forkovalo a zavadel se X MB prekladac. No, to je dnes uz minulost, ale stejne... why perl ? a jak se vubec lisi ? to me nebyli schopni popsat ani na seslosti prazske Perl User Group - protoze nepouzivaji PHP ;-)
2. To, ze se PHP neuci na ceskych vysokych skolach, jen svedci o tom, ze jsou ceske vysoke skoly zkostnatele byrokraticke instituce, ktere se kazdemu vyucujicimu snazi zajistit aby mohl prednaset nejlepe cely zivot to, z ceho delal diplomku (nebo tak nejak). Nemam teda nic proti Perlu, kdysi jsem v tom byl nucen neco delat, ale jak rikam, PHP si osvojuju postupne, a jsem prekvapen, jak jednoduche je v tom cokoliv napsat. Je to proste Cecko s poradnymi stringovymi operacemi - presne to, co bylo potreba uz davno.
3. Objekty nemam rad obecne, a na webovych strankach zvlaste ne. Moc jsem nepochopil, k cemu by tam byly dobre. Ruzne odporne projekty, ktere vypadaji, jako by po nich prebehlo stado vysokoskolskych profesoru, me v tom utvrzuji. Neni nad prijemne neobjektove ucelove prasarnicky ;-) BTW, ted navic smeruji k uplne jine modularni koncepci, kdy budou filenames jednotlivych PHP modulu ulozeny v SQL databazi - coz umozni rozsirovani projektu aniz by clovek musel JAKKOLIV sahat na ty casti, ktere uz nejak funguji. Proste skriptovani rules, kdyz clovek nepotrebuje spickovy vykon..
4. V PHP se casto programuji nikoliv objektove, ale "obrazovkove orientovane" - ruzne se skace mezi jednotlivymi obrazovkami ktere jsou bud vygenerovane
z MySQL, nebo jsou to formulare, nebo oboje. Objektovy pristup by tam moc platny nebyl.
5. Ta zmena, ze "=" neznamena kopirovani, ale jen vytvoreni pointeru se mi moc nezamlouva, nechapu jeji duvody, dovedu si predstavit, ze bych kopii objektu potreboval (nastesti s nimi ale nepracuji), na druhou stranu temer si nedovedu predstavit, ze bych v tak komfortnim jazyce jako PHP nekdy potreboval takovou "asemblerovstinu" jako je pointer - na to jsem zvykly spis z Cecka. Je mi jasne, ze to vzniklo tak, ze zacatecnici asi meli problem s programovanim spojovych seznamu, nebo tak neco, nicmene ja jsem od te doby co pouzivam kombinaci PHP+MySQL nenaprogramoval jediny spojovy seznam (naopak, uvazuju, ze si udelam nejakou "SQL knihovnu" do Cecka, abych opravdu nemusel uz v zivote sahnout na jediny spojovy seznam ;-)
6. stejne myslim, ze lidi, kteri snazi objektove orientovane programovat CGIcka (=PHPka) vubec nepochopili, pred cim se vlastne vynalezci webu, webovych browseru a hlavne CGI skriptu snazili zdrhnout ;-)
7. cely humbuk okolo objektove orientovaneho programovani slo vyresit tim, ze by se do Cecka (resp. PHPka nebo cehokoliv) pridala konstrukce pojmenovana treba "with", "use" nebo treba "inside" (podobna Pascalskemu With...Do), ktera by uvnitr sveho scope udelala z clenskych prvku struktury lokalni promenne:
misto strukt->prom++; by clovek mohl psat inside(strukt) {prom++;} (coz by samozrejme melo smysl uvnitr funkci, kterym je VSECHNO predavano v pointeru na strukturu, coz je bohuzel casto jedina moznost) a spolu s nejakym operatorem, ktrery by umel kopirovat libovolnou strukturu zname delky "usnadnilo" objektove orientovani v Cecku natolik, ze by nemuselo vzniknout nejake zmatene C++ a nejlepe vubec pojem objektove orientovaneho programovani jako takovy, protoze misto toho by proste stacilo programovat intuitivne ;-)
8. prestante pouzivat mozek misto lopaty a jen tupe kopirovat to, s cim kdo prijde ve svete. chce to nejaky novy napad!!! ja bych napr. rad videl programovaciho jazyk, kde by bylo mozne kazdy program pouzivat bud jako skript, nebo prelozit jako binarku, bez jakychkoliv dalsich uprav... krome toho cela koncepce objektu je scestna, protoze to programovani nijak neusnadnilo, ale naopak zcela neuveritelnym zpusobem zkomplikovalo a zamotalo. Vzdycky kdyz nekdo prijde s nejakou jednoduchou konepci - treba web a CGI skripty, nebo PHP spolupracuji jednoduse s SQL databazi - tak se najdou genialni experti, kteri z toho behem nekolika let opet udelaji neproniknutelny gulas...
9. kdo jste nezacinali s programovanim v Basicu, na Spectru, Sharpovi, Comodorovi, Atarku, nebo tak, tak stejne vubec nechapete, o cem to cely je ;-) Budoucnost
programovani spociva v synteze unixoveho pristupu s atmosferou "urob si sam", ktera panovala na 8bitech ;-)
Budu trochu strucnejsi:
ad 8) ten vysneny jazyk se jmenuje treba perl (nicmene s ostanimi body vam to koliduje ;-) - ne, berte to tak, ze sem si musel rejpnout
ad 9) zacinal jsem na spectru, vim co to je narvat firmware pro '51 do 2kB a tusiz uznavam ze perl je smejd a od zitra prepisuju komplet vsechno do PHP ;-)
Na uvod - myslim, ze jste asi nikdy neudelal vetsi projekt, ktery by po Vas mel navic nekdo precist a pochopit.
Premyslim, jestli ma cenu komentovat Vase slataniny typu 'objektovy pristup je na nic' a 'od doby, co pouzivam SQL jsem nenapsal jedinou slozitou datovou strukturu', ale proc vlastne ne :)
Ad 2) to, ze se PHP na VS neuci jsem nerekl. Rekl jsem jen a pouze, ze ho neuci kantori, kteri si toto osloveni zaslouzi. PHP se myslim na prakticky zamerenych VS uci jako vrchol pokroku ... nicmene napr. na skolach, ktere stoji za to studovat (ctete: ktere Vas nauci vic nez ze programovaci jazyk ma if,while a switch), jej v rozvrhu nenajdete - neni duvod. Pokud totiz nekdo ovlada po teoreticke strance programovani a ma nejakou praxi, neni pro nej problem naucit se dalsi jazyk jak "mavnutim kouzelneho proutku". Premyslim, jaky by asi byl Vas uzas, kdybyste zjistil, ze na techto zkostnatelych institucich vznika spousta uzitecneho software a projektu, ktere by jinde proste vzniknout nemohly (kde vznikl takovy kompilator, pane? a kde treba Linux? hint: stredoskolak ho nenapsal :) ). A mozna by byl ten uzas vetsi v momente, kdybyste zjistil, ze existuje i funkcionalni a logicke paradigma.
Btw, stringove operace ma oproti PHP napriklad Perl aji Ruby _MNOHEM_ lepsi a PHP by se melo stydet za to malo, co poskytuje (a vlastne i zpusob, jakym string ops predvadi - ale to je zase jina kapitola). Pro C samozrejme existuji knihovny, ktere praci se stringy usnadnuji a v C++, svete div se, existuje nativni podpora pro String operace, kterym se PHP muze teoreticky aji rovnat, kdyz primhourim obe oci.
Ad 4) Obrazovkova orientace rozhodne neznamena, ze je nutne delat kod naprosto neprehledny a to nejlepe jako 150 funkci, u kterych si pak clovek musi pamatovat, co ktera vlastne presne dela ... a nedej boze preklepnout se o pismenko. Objektovy pristup se vyplati uz jen pri pristupu do databaze a generovani vystupu, coz ale jako autor webovych prasarnicek neocenite, bohuzel (bohudik?).
Ad 5) Pouziti SQL jako kontejneru pro data je proste uzasne pomale ... chtel bych videt, jak programujete byt jen prohledavani grafu (Dijkstra) pres linked-list v SQL - ta rychlost a elegance musi byt opravdu uzasna. Aneb usnadnim si praci v C tim, ze pouziji SQL, cimz seberu Ccku jeho hlavni (a temer jedinou) vyhodu - rychlost. Kazdy problem ma specifickou domenu, v ramci ktere se ma resit. A Vas napad je presne pripad, jak se to delat nema :)
Ad 7) Vas nazor na objektove programovani a nasledny popis jeho 'nastupce' je tak kraaaaasne zcestny. :) Muzete mi, prosim, prozradit jak se v takovem pripade zaridi napriklad dedicnost? Pripadne zapouzdreni. Premyslim, ze bych Vam mel zaslat alespon jeden kratky OO program a nasledne demonstrovat napriklad znovupouzitelnost kodu, aby Vam doslo, ze mluvite, velmi zjednodusene receno, zcesty. Vase intuitivni programovani vypada asi jako stekani psem:
struct pes {
/* neco */
} alik;
void stekej(struct pes *cim);
stekej(&alik);
/* Napsano v C */
narozdil od objektoveho, a _intuitivniho_ stekani:
class Pes
def stekej
# telo metody
end
# zbytek definice class
end
alik = Pes.new
alik.stekej()
# psano v 'Ruby' (http://www.ruby-lang.org/) - ciste OO jazyk
Ad 8) Hmm, to NECO noveho uz DAVNO existuje, jmenuje se TO napriklad OCaml nebo Haskell. Nicmene - nechci Vas podcenovat, ale asi to na Vas asi bude trosku moc :-)
Btw, kombinace kompilator+interpret urcite existuje i pro jina paradigmata, nicmene momentalne si nevybavuju zadne konkretni jmeno, takze snad priste ;)
Poznamka na zaver:
OO programovani (paradigma) je jednoducha koncepce, jen to, co tu predvadite svedci o naprostem nepochopeni, o cem takove OO je.
Snad nekdy zjistite, ze svet nestoji na CGIckach a PeHaPkach ... ale ze existuje i Java, Ruby, SmallTalk, OCaml, Scheme a dalsi jazyky, ktere se nasazuji v oblastech, kam Vy pro oci nedohlednete ... v oblastech, kde by nasazeni Vaseho pristupu znamenalo rychly a bolestivy pad (na usta).
:)
;-) Tak to s tim, ze jsem neudelal vetsi projekt, to me opravdu pobavilo ;-) aspon vidim, ze jsem nebyl zase takovy exhibik jak jsem si myslel ;-) (pro zajimavost: jmena jako Mirek Fidler nebo Frantisek Fuka vam neco rikaji ? Mikulas Patocka, Martin Mares, Honza Hubicka a dalsi Linuxaci ? Nebo lidi z Illusion Softworks ? Ze ano ? Sakra! porad nepatrim mezi nejslavnejsi ceske programatory ci softwarove firmy ;-) a tak jsem se snazil ;-) (Nicmene uznavam, ze tech asi pet zahranicnich firem, co muj program licencovaly, ho shledalo natolik prasecky napsanym, ze si pak moc nevedely rady, co s tim dal ;-) coz me privedlo k premysleni, jak do budoucna programovat nejak poradne - ale OOP to fakt nebude...
Ad 2) moc rad bych studoval vysokou skolu, kde se uci PHP - mohl bych totiz jit rovnou ke statnici, sbalit diplom a mit od studia pokoj. Bohuzel, ceske vysoke skoly naprosto nezajima, co umim a pripadne jsem schopen vymyslet noveho, ale snazi se mi dokazat, ze jsem blbec, co zatim neumi vubec nic. Tahle nerovnovaha me stve, a rozhodl jsem se zasvetit zivot zpochybneni odbornosti a autority vysokych skol jako takovych. Je to stejne zasadni tema, jakym bylo napr. ve stredoveku zpochybneni autority cirkve...
Zatim vsude, kde jsem se snazil studovat informatiku, me cpou do hlavy akorat mraky matematiky (programatorske predmety mam hotove snad na vsech ceskych VS, vcetne MatFyzu ;-) Nic proti matematice, ale me proste nejde, nebavi, a navic ji pokladam za trochu zastaraly nastroj, ktery byl nahrazen prave pouzitim pocitacu. Prijde mi nefer, ze se za rovnopravne vysoke skoly pokladaji ruzne humanitni obory, kde staci precist si par zabavnych knizek (ktere ctu tak jako tak), zatimco kdyz chci byt vystudovany programator, cpou mi do hlavy matiku.
Ad 4) u vetsiny beznych aplikaci si clovek vystaci s par globalnimi promenymi, jednou databazi s par tabulkami, a pak s promennymi, do kterych vyexpanduje radky tabulky. Nerikam, ze se tak da nebo ma delat vsechno, ale pro bezne webove programovani to fakt staci. OOP by bylo chozeni s delem na vrabce. Navic cim je kod strucnejsi, tim lepe se pak debuguje a udrzuje...
Ad 5) databaze je interne naprogramovana jako spojovy seznam, a pokud je spatne optimalizovana, muze to byt problem. Vtip je v tom, ze zadneho Dijkstru ve skutecnem zivote programovat nepotrebuju. Kombinace C a SQL je prozatim blbost, to uznavam. Jde o to, ze programatori dnes hnidopisky dbaji na optimalizaci nejakeho algoritmu, a pak pul hodiny cekaji, az system prekresli Wokno. Nektere nastroje maji overhead - treba SQL - ale naprosto zanedbantelny proti overheadu, ktere ma treba graficke prostredi...
Ad 7). Ano, to je presne ono. stekej(&alik) se mi libi
daleko vic, nez alik.stekej(). Prave proto nemam rad OOP! Prvni varianta je daleko semanticky prirozenejsi, blizsi mluvenemu jazyku. Pouzivat objekty je jako mluvit pozpatku. Ja ve skutecnosti pri programovani pouzivam "neco jako objekty" - knihovnu funkci nad stejnym datovym typem (strukturou). Misto dedeni jednoduse udelam novou strukturu, ktera obsahuje pointery na tu "zdedenou" - co je na tom spatne? Hlavne ale ve vetsine pripadu je blbost pouzivat nejake struktury. Misto struktury se slozitym popisem atributu fontu je lepsi pouzit treba string, ve kterem je popis fontu v jazyce CSS - a parsovat to az na nejnizsi urovni. Primitivni datove typy maji spoustu vyhod proti strukturam a objektu...
Nahodou, Haskell se bral v logickym programovani, tusim hned za Prologem. Pokud ho clovek vynechal, prolezl za 3, a to je myslim to, o co v tom predmetu slo, ne ? ;-)
Ja nevim, ja se na Haskell trochu dival, a moc me nezaujal, jsou tam uzasne vychytavky pro lidi, co se cely zivot zabyvali studiem matematiky, a na zakazku v zivote nenaprogramovali ani penezni denik pro jednoduche ucetnictvi...
Linus Thorvalds jasne dokazal, ze na vysokych skolach se casto uci neprakticke nesmysly - a vedlejsi produkt jeho snahy potom zrusil cele jedno prumyslove odvetvi komercnich Unixu... a doufejme ted trochu pozlobi i neotresitelny Microsoft ;-) Takhle se to ma delat ;-))
Fuka,Mares,Hubicka: zname firmy.
Napsat browser neznamena byt slavny, pane :)
Ad 2) az na nejake VS budou ucit _jen_ PHP, nebude to VS. Asi nechapete, o cem takova VS je.
Ad 4) Strucnejsi -> lepsi? Ano, Perlovske programy typu "@#%!#^#%^#%^&!^!^$@#$#%$^#^%&^#%%^%" jsou toho jasnym prikladem :)
Ad 5) Databaze je interne delana pres B tree nebo B+ tree, pripadne dalsi "advanced" organizace souboru. Kdyby byla delana pres linked list, asi byste se nacekal.
Ad 7) Kdyz se na to podivam z hlediska prirozeneho jazyka, tak "Aliku, stekej!" je presne a'la objektove programovani alik.stekej()
Btw, Haskell NENI logicky jazyk ... je to funkcionalni jazyk. A mate pravdu, Haskell (a FP obecne) neni na ucetnictvi, ale napriklad Siemens (jestli se nepletu) jej pouziva jako jazyk na skoro-vsechno. :)
>Fuka,Mares,Hubicka: zname firmy.
>Napsat browser neznamena byt slavny, pane :)
To jsem si vsiml, budu muset napsat jeste neco jineho... ale BTW, to ma byt narazka na Twibright Labs, nebo na Arachne Labs ? ;-)
2) nikdo nemluvi o skole, kde by se ucilo jen PHP.
ja bych byl ochoten klidne podstoupit objektove programovani jako takove nutne zlo, misto te matematiky ;-) resp. docela rad bych si naprogramoval nejakou neuronovou sit, misto abych se nazpamet drtil nejaky definice a hloubal nad diferencialnimi rovnicemi. Kde je psano, ze komu delaji problemy diferencialni rovnice, neni schopen se naucit naprogramovat treba prave neuronovou sit ?
5) myslel jsem, ze B tree je taky druh spojoveho seznamu, ale to jsou ty definice. Rikal jsem, ze v mych spojovych seznamech byly snad jen polozky typu ->next ?
a trvam na tom, ze nekteri programatori dnes peclive optimalizuji vsechny svoje mozne a nemozne spojove seznamy, aby pak zavolali nejake obludne GUI, ktere pak pul hodiny swapuje :-( a za to muze tak z 50% objektove programovani, zejmena dedicnost vlastnosti...
7) to teda ani nahodou. Stekat muze ledacos, zatimco v OOP muzou stekat jen objekty, ktere zdedily stekani po psu. Ve skutecnosti neni stekani defanove na psu, ale na tom, cim ten pes steka, a to je prave vyhoda normalniho programovani pred OOP: ve skutecnosti pisu stekej(alik->stekadlo); a muzu stekat jakymkoliv jinym objektem, ktery disponuje stekadlem, a tak to taky chodi ve skutecnem svete - OO programatori se chytili do filosoficke pasti Platona a jeho jeskyne, pricemz kazdy kdo cetl prvni dil Otevrene Spolecnosti a jejich nepratel od Karla Poppera vi, ze Platon byl zavrzenihodny fasista! ;-) Zkratka anarchiste by se meli mit pred OOP na pozoru, a premyslet na tom, proc je Linuxovy kernel napsany v cistem C...
A az prestane existovat PHP (pripustme, ze zanikne, jako spousta jinych jazyku), tak ten diplom zase srulujete zpatky do trubky a pujdete se dal hnipat v neobjektovem Basicu, nebot ten, podobne jako Stalin, je vecny.
Btw. neuronove site toho maji s programovanim pramalo spolecneho, daleko bliz maji k matematice, maticovemu poctu, radam a prave tem diferencialnim rovnicim ;-)
Vymlouvat se nasledne na spatnou defici je moc krasne :) Neco jako 'oops, ja jsem to tak ale nemyslel, promin'.
Jestli nejake GUI swapuje, je to problem jeho programatora a nebo autora OS (to asi predevsim) :)
Ad 7) Ano, budeme stekat stekadlem, nafadlem, ale i knouradlem, aby v tom byl pekny bordel. V dynamicky typovanych jazycich vsak muzeme stekat objektem, ktery ma prislusnou metodu, stejne jako ve skutecnem svete. Asi by bylo vhodne parafrazovat: "Learn, then judge."
PS: Linuxovy kernel je napsan v C kvuli tomu, ze jde o nizkourovnovou zalezitost (a pouziti C++ znamenalo vysoke latence). Nicmene ja netvrdil, ze OO je lek na vse. Ne, neni .. ale ve spouste veci proste znamena rad - coz je presne vec, ktera ve vetsine strukturovanych prasarnach chybi.
Ad 1) OOP není všespasitelné, ale je to velmi dobrá metoda, jak udržet přehledný kód. Ono něco jiného je, když píšete kód pro sebe, ve kterém se nikdo jiný nevyzná. Co pak s tím? Samozřejmě, že jde udělat přehledný kód i bez OOP, ale s OOP to jde mnohem snáze.
Ad 2)Vysoká škola je o něčem jiném, než učňák o PHP. Matematiku jsem v programování ocenil častěji, než bych byl vůbec ochoten sám sobě přiznat. Dnes jsem rád, že jsem se jí učil.
Ad 4) Dělám webové aplikace a OOP tam taky užiji. A jak to zpřehlední a zestruční kód, který se pak lépe debuguje a udržuje...
Ad 5) Databáze určitě není naprogramována jako spojový seznam, to asi ne.
5) tezko rict, treba dBase byla podle me implementovana jako staticke pole ;-) a nemyslel jsem jednosmerne spojove seznamy, a vubec... proste kdyz je databaze pomala, je naprogramovana spatne, tak jsem to myslel. Pokud bude k dispozici dobre naprogramovana databaze, uz ve svych programech nebudu potrebovat jediny seznam, strom, pole... na tom trvam. Dobre naprogramovana databaze totiz neni nic jineho, nez nejaka container class v tom vasem OOP...
Mozna byla dBase implementovana jako staticke pole, ale URCITE mela index.
Vetu 'kdyz je databaze pomala, je naprogramovana spatne' si asi necham zaramovat :)
Ad strom, seznam, pole: mohl bych, prosim, videt porovnani algoritmu 'vyhledavani do sirky' a 'vyhledavani do hloubky' v pripadech:
1) pouziti n-arniho stromu
2) pouziti 'dobre naprogramovane databaze'
?
Pro zacatek bych zvolil dva pripady:
1) hloubka stromu 10_000, arita 20
2) hloubka stromu 100, arita 1_000
Prosim prosim ... zaroven bych prosil aji analyzu casove a prostorove slozitosti.
Ano ano, ja na tom proste trvam. Matematika je samozrejme strasne siroky pojem; je jasny, ze treba bez logiky programator daleko nedojde. Ale mluvim napr. o matematicke analyze, jejich dukazech, apod. Je to obor, na ktery se v minulych staletich kladl prehnany duraz: prevazna vetsina jevu v prirode je stejne nelinearnich, a to, ze obcas zahledneme neco, co je dobre matematicky abstrahovatelne, to jsou spis vyjimky. Podobne pocitace umoznily dokazat spoustu veci, nad kterymi si driv matematici lamali hlavy, proste pouhym prohledavanim stavoveho prostoru. A jsou veci, se kterymi se nic moc jineho nez prohledavani stavoveho prostoru ani delat neda - treba cinnost Turingovych stroju. Resp. vsechno se tam dokazuje sporem, protoze se neda rict nic jinyho, nez ze nevime, zda se Turinguv stroj zastavi. A tom to je - cely vesmir, kvantova fyzika, DNA... turingovy stroje! Zadna analyza neni ve skutecnosti mozna, zadny dukaz. Jsou to vsechno jen aproximace, snaha napasovat nelinearni skutecnost do omezene linearni predstavivosti. Pocitace jsou schopny prochazet neuveritelne rozsahlejsi stavovy prostor, nez mozek, a tim predstavuji zasadne odlisny abstraktni nastroj pro modelovani vesmiru, nez matematika, zejmena nektere jeji odvetvi, ktera se tim padem ocita na zaslouzenem odpocinku v muzeu: byla pouzita jako nastroj pri vyvoji pocitacu, ale ty maji s matematikou uz spolecne max. tak scitani, odcitani a logicke operace. Samozrejme, kdyz do matematiky pocitate teorii grafu, teorii vycislitelnosti, apod., tak je muj vyrok napadnutelny, ale mel jsem na mysli asi opravdu spis analyzu, algebru, apod. V zasade ma "pocitacove" matematika poslecneho s tim, co se uci na vysokych skolach asi tolik, jako zirafa s lisejnikem.
Jinak presne vim, o co jde na vysokych skolach: dokazat studentum, ze jsou uplni idioti. Amputovane sebevedomi studentu je pak pomoci prideloveho systemu postupne rozdelovano v celem akademickem prostredi na podobnem principu, na kterem funguji pyramidalni hry typu "Letadlo"...
Nebejt odstrasujiciho prikladu Billa Gatese, tak se na studium vysoky skoly uz davno vykaslu... :-(
Toto je jiz podruhe, co prevracite sve predchozi vyroky naruby. Zajimavy zpusob.
Jeste bych se rad vratil k 'prog. predmety mam vystudovane snad na vsech VS vcetne MFF'. To je opravdu zasluha! Gratuluji. Prumerne inteligentni opice je zvladne absolvovat bez vetsich problemu tez.
Mate ale absolvovanou tu programatorskou matiku? Slozitost, Logiku, Vycislitelnost, Grafy, Kombinatoriku? Napr. na FI.MU se toto vsechno mate sanci naucit, aniz byste byl primo nucen projit vsechny povinne kurzy (Linearni algebra, Algebra, MatAlyza).
Ja netvrdim, ze jsem o tolik inteligentnejsi nez opice - to ale vypovida spis cosi o inteligenci opic, nez o inteligenci moji, viz Ann Druyn a Carl Sagan: Stiny zapomenytch predku
Vycislitelnost, Grafy a Logiku jsem letos dodelal na SLU v Opave. U grafu jsem se pohadal o jednom dukazu, protoze ja si muzu dokazovat co chci jak chci - hlavne ze tomu rozumim, ze to tak MUSI byt, podle me. Algoritmicky dukaz (nemyslim pruzkum stavoveho prostoru pomoci algoritmu ;-) muze byt stejne zajimavy jako dukaz indukci, navic neni rutini, atd. Ja proti MFF zas tolik nemam, porad to byla daleko sympatictejsi skola nez CVUT nebo VSE, ale SLU nabizi komfortni dalkove studium, posila mi rozvrh postou a shani mi oxeroxovana skripta, coz jde s podnikanim daleko lepe dohromady. Ja preci jenom nechci skoncit jako Bill Gates.... ;-)
OOP je dobre jednak pro lidi, kteri si sami vytvori nejaky mamuti toolkit s hromadou classes (o cemz se me snazil presvedcit treba Mirek Fidler, ktery ted cosi takoveho dokoncuje), jednak je dobre, pokud by cely operacni system byl objektovy (o cemz me kdysi v sahodlouhych debatach vicemene presvedcil Ondra Cada, resp. nase nazory se ponekdu sblizily), a potom pro lidi, kteri jsou schopni memorovat se nazpamet obrovska kvanta informaci, jako treba dokumentace k nejakym hotovym knihovnam objektu, coz jsou schodou okolnosti lide, kteri snadno projdou dnesnim vysokoskolskym systemem.
Jde o to, ze dobry program, ktery pouziva zakladni vseobecne zname datove typy, a funkce/procedury nedefinuje vsude, kde se to programatorovi libilo, ale jen tam, kde to dava z hlediska programu smysl, je dobre citelny, samodokumentujici, programator proste na prvni pohled vidi co to dela, i kdyz je tam obcas treba deset radek kodu s par podminkami a cykly misto nejakeho hlavni_okno.podrbej_se(&levou_nohou,hlavni_okno::za_pravym_uchem)
nebo neco takoveho. Kvuli tomu uz clovek musi sahat
pro manualu. OOP je mozna dobre pro pristup "urob
si sam vlastni Windows" (KDE), obri monoliticke projekty, nebo pro firmy
kde nekdo dlouho dela na jednom projektu, ale v open source programech se chci podivat na zdrojak, a co
nejrychleji jednoduse videt CO TO DELA... mam podstatne lepsi predstavivost nez pamet a ochotu
cist dokumentaci.
Jinak nektere dnesni aplikace se spis odvijeji od
toho "co umoznil OOP pristup ke GUI" nez od toho
"co by bylo pro uzivatele snadno pochopitelne"...
viz obrazovkove orientovane informacni systemy vs. pull-down menu pracujici nad "aktualnim dokumentem"
vs. step-by-step wizardy.... OOP je vyhodne hlavne
pro lidi, co maji radi pull-down menus. (Ja jsem
snad jeste v zivote nenapsal program, ktery by mel pull down menu, BTW ;-)
Mno, ja jsem taky neudelal jediny system, ktery by mel GUI, ale uz jsem udelal radku systemu s TUI a webovych ... a musim rict, ze ty objekty mi _fakt_ usnadnuji praci - a nemusim si pamatovat hromady veci (parametry funkci, ktera kam patri, ...).
Proste z meho uhlu pohledu je zase mnohem jednodussi podivat se na strom tech class a pochopit to z neho, nez byt nucen premyslet nad tim, jak ty roztrousene funkce vlastne funguji. Zaroven mi prijde OOP program opravdu 'samodokumentujici' a jednoduseji udrzovatelny, protoze tak nejak logicky drzi pohromade a kdyz clovek neni prase, tak je mozne vymenit kompletne vnitrek nejake class aniz by to rozdrbalo funkci celeho systemu - cimz odpada hromada prace v pripade strukturovaneho kodu. (nerikam, ze to tam nejde, spis jde o to, ze to tam jde jedine v pripade _mnohem_ vetsi discipliny)
Kazdopadne ad SLU: zajimave :) To by mozna taky nebylo od veci, nicmene mam rad FI.MU ... :)
Cituji:
``Resp. vsechno se tam dokazuje sporem, protoze se neda rict nic jinyho, nez ze nevime, zda se Turinguv stroj zastavi. A tom to je - cely vesmir, kvantova fyzika, DNA... turingovy stroje! Zadna analyza neni ve skutecnosti mozna, zadny dukaz. Jsou to vsechno jen aproximace, snaha napasovat nelinearni skutecnost do omezene linearni predstavivosti.``
Aha, takze dukaz sporem neni dukaz? Smarja, tak v tom pripade se prave sesypala skoro veskera existujici matematika.
``Podobne pocitace umoznily dokazat spoustu veci, nad kterymi si driv matematici lamali hlavy, proste pouhym prohledavanim stavoveho prostoru.``
Ano, to je pravda. Napr. nejlepsim zpusobem, jak faktorizovat cislo je projit vsechny moznosti.
Nerikam ze to neni dukaz, ale je takovej "divnej". Dukaz prohledavanim stavoveho prostoru pomoci pocitace mi prijde daleko silnejsi, a je legracni, ze matematici ho celou dobu neuznavali. Ostatne ja bych se vube nedivil, kdyby treba nas vesmir (resp. kombinace nase vedomi/nas vesmir, protoze jedno bez druheho nelze pozorovat) existoval prave diky tomu, ze je vnitrne rozporny, a ve chvili, kdyby se vsechny logicke rozpory odstranily, by zanikl. Tudiz je existencne dulezite zajistit, ze matematika zustane vnitrne rozpornou a pokud mozno nepochopitelnou ;-) ale to se uz od vysokych skol a objektoveho programovani dostavame nekam jinam (ale nerad bych, aby to bylo chapano jako takticky ustup ;-)