Hlavní navigace

Vlákno názorů k článku Michal Illich: IT vzdělání získáte praxí od Roman Pudil - Pan Illich ma pravdu jen z poloviny. Praxe...

Článek je starý, nové názory již nelze přidávat.

  • 24. 11. 2004 8:48

    Roman Pudil (neregistrovaný)
    Pan Illich ma pravdu jen z poloviny. Praxe je samozrejme velice dulezita, obzvlaste v IT, kde vyvoj jde velice rychle kupredu. Nicmene zakladni teoreticke "kameny" pro pochopeni cele podstaty fungovani poskytnou prave prislusne vzdelavaci instituce.
    On to vlastne pan Illich rekl sam v odstavci, kde se zminuje o nasazovani Jyxo do Madarska a spolupracoval s rodilymi Madary. Predpokladam, ze nespolupracoval s lidmi "z ulice", ale se vzdelanci, kteri vedi, jaka je spravna skladba vety, podmet, prisudek ci prislovecne urceni casu.
  • 24. 11. 2004 9:25

    R. (neregistrovaný)
    A aby tohle vedeli, musi mit za sebou '5' let v nejakem ustavu ? VS vypovida jen o tom, ze dotycny nekde stravil 5+ let zivota, ale uz to nerika PRANIC o jeho kvalitach, nebo neco podobneho.

    U toho jazyka je to tak jako jinde - bud ma clovek vrozeny cit, nebo nema. A pokud nema, nikdy se ho nenauci (treba jako ja :) stejne je to tak u matematiky, IT a dalsich.

    S VS mam prakticky stejne zkusenosti jako autor Jyxa...

    R.
  • 24. 11. 2004 9:28

    Pepa (neregistrovaný)
    Ehmm, nás na katedře aplikované informatiky neučili správnou skladbu věty, podmět, přísudek či příslovečné určení času. To, pokud si dobře pamatuji, jsem naposled probíral na gymnáziu :-)
  • 24. 11. 2004 10:17

    Roman Pudil (neregistrovaný)
    Pokud chteji znat a pochopit teorii o ktere jsem mluvil, tak ano, jestlize netravi noci mezi odbornymi publikacemi, ktere jim tak vlastne to studium nahrazuji... :o)

  • 24. 11. 2004 12:45

    Honza (neregistrovaný)
    vsadim boty, ze pan Illich ma lepsi teoreticke zaklady, nez polovina lidi, kteri na tech skolach VYUCUJI.
    samozrejme ze kvalitni (!) skola cloveku da skvele zaklady. ale imho neni pravda, ze bez skoly se clovek nemuze naucit teorii. a problem vidim hlavne v tom, ze nektere skoly u nas moc kvalitni nejsou - nekdo tady v diskusi narazel na lemply bez vzdelani, kteri by potrebovali skoleni. smutne je, zo tohle se da rici i o mnoha panech inzenyrech.
  • 24. 11. 2004 13:13

    honzik (neregistrovaný)
    s tim musim bohuzel souhlasit. Kvalita vyucujicich je naprosto zalostna.

    Napr. vychazeji z vysokych skol lide, kteri jsou toho nazoru, ze databaze je neco relacniho a SQL nam seslal sam Buh pres Mojzise spolecne s temi prikazanimi. A kdyz takovi lide prijdou do firmy a rekne se jim ze SQL je k nicemu, tak vytahnou skripta nejakyho profesora s tim, ze tam se to prece vychvaluje. A muzete zacit ze skolenim...
  • 24. 11. 2004 15:42

    sax (neregistrovaný)
    To by me take zajimalo. Pracuji pro jednu velkou pojistovnu, kde je cela business logika napsana v PL/SQL (presneji cast systemu, kterou pomaham vyvijet). A nevim nic o tom, ze by se melo nahrazovat necim jinym... take cim? ;-)
  • 24. 11. 2004 16:56

    honzik (neregistrovaný)
    a jake mate zaklday? Kde ma clovek zacit? Co vite z historie SQL. Ma se zacit u SEQUEL v roce 1974? Jak to vypada se znalostmi problematiky pouziti deklarativnich a proceduralnich jazyku ve smisenych programovych prostredich?

    Myslim, ze vase otazka ale velice dobre zobrazuje zde diskutovanou problematiku teorie a praxe. :-)
  • 24. 11. 2004 18:14

    Michal Kára (neregistrovaný)
    To jsme se toho dozvedeli ;-) Me by zduvodneni toho tvrzeni taky zajimalo, zvlast jelikoz je v primem rozporu s mou mnohaletou praktickou zkusenosti :-)

    Muzeme se bavit o tom, ze jsou data, ktera neni vhodne reprezentovat v relacnich databazich. Muzeme se bavit o tom, ze norma SQL (natoz jeho implementace) ma nektere logicke i prakticke nedostatky. Ale tvrdit, ze neco, co se leta siroce a docela uspesne pouziva je "nanic", mi prijde torchu odvazne.
  • 24. 11. 2004 22:29

    honzik (neregistrovaný)
    ...To jsme se toho dozvedeli ...

    Ja taky nejsem zadnej zadarmo skolitel. My tady diskutujeme proc je vysokoskolske studium nutne - na stredni skole by se dozvedeli studenti , ze se SQL pouziva a eventuelne kde a kde treba az tak ne.

    Na vysoke skole by melo byt tematem, proc se nekde pouziva, a proc ne a co hlavne - spravny absolvent-inzenyr by mel byt vychovan k tomu, ze se ve sve budouci praxi bude ptat "je to vsechno jeste tak, jak to platilo vcera ?"

    Samozrejme idealni by bylo, kdyby studoval u nekoho , ktery jenom nepredcita to , co si predtim sam precetl v anglickem casopise a opira se ve sve pedagogicke cinosti o svou vyzkumnou praci - a nekdo takovy by se jiz studentu ptal:
    - jste si jisti, ze se SQL jiz leta uziva USPESNE (znamena hospodarne), jak se vam bude snazit namluvit nejaky programator z pojistovny, ktera si muze dovolit vyhazet penize za to software
    - jak je podporovana vyroba software, ktera neprobiha prave PROJEKCNIM zpusobem
    - znemoznuje pouziti deklarativnich jazyku modularitu softwarovych systemu

    Samozrejme by takovy pedagog upozornil mlade vysokoskolaky na to, ze kdyz je neco vseobecne povazovano za spravne, ze to tak jeste nemusi byt (zeme NENI placata). A takovy pedagog by rekl tem studentum: "neni vam to divne, ze by pro pristup k jakymkoliv datum, v jakekoliv velikosti za jakekoliv situace existovalo jedine reseni a to by bylo to na veky spravne - totiz SQL ?" A studenti by odpovedli - "ano pane profesore, v jakemkoliv oboru lidske cinosti tomu tak neni ale pro pristup k datum je vyvoj jiz ukoncen a bude navzdy provaden pres SQL protoze to se osvedcilo a zatim jsme neslyseli, ze by to melo jedinou chybu"

    je tedy mozno rici, praktik sice muze psat dobre software, ale urcite se nedokaze presunout za tu hranici poznaneho a je mu zatezko nacerpane pravdy podrobit kritice. A proto se nedivim, ze lide reknou "no jak bys to chtel delat jinak - vzdyt to SQL tak delaj vsichni"

    Ach jo, kdyby jste zde nahodou ocekaval nejaky link do internetu, kde stoji ze SQL je k nicemu - tak to vas musim zklamat - to by byla ta stredni skola....
  • 24. 11. 2004 23:16

    Michal Kára (neregistrovaný)
    > Ja taky nejsem zadnej zadarmo skolitel.

    Ja taky nechtel skoleni, jen jsem chtel, abyste podporil svoje tvrzeni (tedy upresnil, zda si myslite, ze relacni model neni vhodny, nebo ze SQL implementuje relacni model naprosto nemozne ;-)

    > Jste si jisti, ze se SQL jiz leta uziva USPESNE (znamena hospodarne).

    To se da tezko rict obecne. Urcite se najdou projekty, kde neni vhodne, a naopak takove, kde vhodne je. To je otazka dostupnych [vhodnych] alternativ.

    > jak je podporovana vyroba software, ktera neprobiha prave PROJEKCNIM zpusobem

    A on dotazovaci (a data definujici) jazyk nejak zavazneji omezuje zpusob vyvoje software???

    > znemoznuje pouziti deklarativnich jazyku modularitu softwarovych systemu

    (Asi to melo byt "a modularitu".) Jelikoz mnoho systemu je modularnich i se SQL, tak ji asi nejak vyrazne [obecne] neomezuje.

    Co si predstavujete pod pojmem "deklarativni jazyky"? Ja si pod tim predstavim treba Prolog (i k tomu jsme se na skole dostali). Coz muze naznacovat, ze delate neco z oblasti umele inteligence; a tam opravdu SQL a relacni model obecne neni moc vhodny, s tim musim souhlasit.

    A take vas mohu ubezpecit, ze jsem uz delal spoustu projektu, kde data nebyla ulozena v relacni databazi - koneckoncu prave ted na jednom takovem pracuji :-)
  • 25. 11. 2004 1:37

    k (neregistrovaný)
    Jste si zcela jisty, ze Vam zadne komunikacni dovednosti nechybi a ze jsou na nic ?

  • 25. 11. 2004 8:17

    ivs (neregistrovaný)
    > a jake mate zaklday?

    FEL + rozdelane PhD + nekolik let praxe (pred i po FELu), vcetne SQL (nepouzivam jen relacni databaze, nicmene pro nektere veci je to proste velmi vhodne, a tam neznam nic komercne vhodnejsiho nez SQL)

    > Kde ma clovek zacit? Co vite z historie SQL. Ma se zacit u SEQUEL v roce 1974?

    historii SQL znam, vcetne Coddova clanku a jeho pohledu na relacni databaze, az po problemy s poslednimi normami SQL. Umel bych matematicky dokazat, proc nektere veci z principu v SQL nejdou (napriklad tranzitivni uzaver, coz doopravdy muze byt problem). Klidne na tom muzete ve sve odpovedi stavet.

    > Jak to vypada se znalostmi problematiky pouziti deklarativnich a proceduralnich jazyku ve smisenych programovych prostredich?

    rekl bych, ze celkem dobre, Prolog jsem pouzil i pro prototyp reseni realneho problemu, s interfacem do Javy (ponecham stranou, ze se to pak prepsalo do neceho jineho - ciste z "udrzovacich" duvodu - kompatibilita apod.), nehlede na plno problemu vyzkumnejsiho charakteru

    > Myslim, ze vase otazka ale velice dobre zobrazuje zde diskutovanou problematiku teorie a praxe. :-)

    Ano, take bych rekl - vy jen placnete "A kdyz takovi lide prijdou do firmy a rekne se jim ze SQL je k nicemu, tak vytahnou skripta nejakyho profesora s tim, ze tam se to prece vychvaluje. A muzete zacit ze skolenim..." - a kdyz se Vas zeptam na detaily, proc je to k nicemu, tak neodpovite. (Rad se necham poucit, denne zjistuji, jak malo toho vim, a odpoved na tuto otazku by me doopravdy zajimala).

    Tj. nyni jiz vite, na cem muzete ve sve odpovedi stavet. Znovu se tedy zeptam:

    Poucte me prosim, proc je SQL k nicemu?
  • 25. 11. 2004 8:22

    ivs (neregistrovaný)
    > Ja taky nejsem zadnej zadarmo skolitel. My tady diskutujeme proc je vysokoskolske studium nutne - na stredni skole by se dozvedeli studenti , ze se SQL pouziva a eventuelne kde a kde treba az tak ne.

    Ano, uroven vysokoskolaka je urcite veci nutna, o tom nemam pochyb (na stredni skole jsem o SQL vedel jen diky vlastni initiative).

    Ale my tady tez diskutujeme nad Vasim vyrokem, ze SQL je k nicemu - proc je k nicemu? :-)

    Mimochodem, proc myslite, ze posledni iniciativy W3C, jako treba RDF (http://www.w3.org/RDF/), se ve svem navrhu mimo jine ridi snadnou serializaci do relacnich databazi? (ktere stoji na SQL, viz historie SQL a treba vyvoj dBase)
  • 26. 11. 2004 12:44

    honzik (neregistrovaný)
    ja se pokusim na ty pripominky od vice kolegu odpoved najednou zde.

    K te historii - SQL nevzniklo jako fundamentalni odpoved na reseni pristupu k datum v nejake databazi nybrz jako INTERAKTIVNI dotazovaci jazyk pro bankovni pracovniky. Predstava, ktera pretrvava dodnes, ze deklarativni jazyky jsou lidem blizsi (protoze blizsi lidske reci) vedla k tomu, ze se i v tomto pripade sahlo k tomuto jazykovemu prosterdku. Ze je tato predstava uchylna o tom svedci konference o databazich plne nejprimitivnejsich otazek k SQL statements. V kazdem pripade se nenachazi v zadnych dokumentech puvodniho vyvoje priznaky, ze by bylo zkoumano, jakym zpusobem se projevi nasazeni takove metody v komplexnich systemech. On to take nikdo ani nechtel, ale nasel se Larry Elison a ten z toho udelal kseft a rozjelo se to jaksi samo od sebe.

    uspesnost systemu - zde se hovori o komlexnich systemech a ne o nejakem primitivnim webu. A me nejsou znamy takove uspesne systemy. Znam interna 20 takovych projektu (banky, prumyslove podniky, obchodni domy) a ani jeden nebyl uspesny. Znam ovsem projekty, kde je na pozadi nejaka relacni databaze ale v systemu se nepouziva zadny SQL statement (firma sd&m, jeji sef je krome jineho velky odpurce jazyku 4 generace z duvodu "antimodularity") - tato firma napr. dela projekty, ktere alespon castecne nekrachuji a ti tvrdi, ze jeden z duvodu je prave ono rigorozni omezeni deklarativnich prvku z uzivatelskych modulu.

    deklarativni jazyky - problemy vznikle soucasnym pouzitim techto prostredku s imperativnimi se nazyva bezne "impedance mismatch" - v literature buhuzel casto zuzen na problematiku zobrazeni realneho sveta na relacni model.
    Zkoumani teto problematiky je teoreticky zaklad pro pochopeni, proc je SQL brzdou modularity.

    SQL versus modularita - to ze modularity je v rozporu s pouzitim SQL ( ve spojeni s relacni databazi) je prakticky dusledek toho 'impedance mismatch" - jevu. Laicky by se dalo rici, ze "deklarativni systemy" potrebuju ke svemu zivotu UPLNOU znalost pravidel systemu, ve kterem funguji. To je ale v rozporu s principem modularity (information hiding), kde je dulezite, aby moduly existovaly samotne se vsim vsudy.
    Priklad:
    V nejakem informacnim systemu je treba zjistit mnozstvi zbozi na sklade. V SQL-sytemech je to reseno tak, ze podle predem stanovenych pravidel se odsadi nejaky SELECT eventuelne se SUBSELECTY v nejake UNION apod. Takovy statement je ale nedelitelny z duvodu sve deklarativnosti. A proto je nemozne aby nejaky submodul (napr stanoveni mnozstvi na konsignacnich skladech) nepsal nejaky programator v Peru, bez toho aniz by obeznamen s tim, jaka VESKERA pravidla v danem systemu plati.
    To je take duvod, proc se takove systemy realizuji v PROJEKTECH. To ze je SQL k nicemu by se zjistilo okamzite, kdyby nekdo zkusil takovy projekt realizovat oddelene.

    poznamka k modularite: pan Kara napsal, ze existuji modularni systemy, ktere pouzivaji SQL - toto neni zcela jiste pravda, ale treba se to tak nekomu jevi , protoze ma rozdilny nazor na to, co modularita je.
  • 26. 11. 2004 13:01

    PaJaSoft (neregistrovaný)
    Zajmave jste pojal historii SQL, tak jen pro ciste vasi informaci, pokud z toho nekdo udelal kseft tak to byla americka armada, kterazto to, z cehoz vznikl product Oracle, financovala...
  • 26. 11. 2004 15:11

    Michal Kára (neregistrovaný)
    Vyborne, konecne jsme se k necemu dobrali (i kdyz z dotazu v SQL konferenci bych spis usuzoval na velky podil laiku mezi IT personalem - obecne tema teto diskuse).

    Ohledne toho, ze SQL se ma podobat prirozene reci - to je pravda, i kdyz mne osobne to nijak zvlast nevadilo, spis mi to prislo podobne jako ukecanost Pascalu.

    Uz konecne chapu, co SQL vytykate, a musim s tim souhlasit. SQL je opravdu "raw" jazyk a ma pramale prostredky pro skryvani implementace. Z toho ale vyplyva spis to, ze je nesmysl, aby se data mezi moduly sdilela pres SQL, ale ze se k nim ma pristupovat jinym zpusobem.

    SQL toto resi castecne pomoci views a slusneji pomoci proceduralnich nadstaveb. Neresil jsem ale s jejich pomoci vetsi projekty, takze vam nemuzu dat priklad ze to jde ;-)

    Moduly chapeme asi oba stejne, jen jste zrejme prilis uzce zamereny na oblast aplikaci, ktere prave delate ;-) Jsou aplikace, ktere maji vice modulu, pricemz jen jeden je abstraktni datova vrstva, a ostatni jsou treba komunikacni, vypocetni, UI atp. a ty komunikuji s datovou vrstvou. Pritom ta vrstva muze jako persistentni viceuzivatelsky sklad data pouzivat prave SQL.

    Coz je to, co SQL poskytuje: Persistentni sklad dat, s viceuzivatelskym pristupem. Mozna se budete divit, ale to je presne to, co spousta aplikaci potrebuje ;-)

    P.S.: To ze sroubovakem hrebik nezatlucete neznamena, ze je sroubovak k nicemu ;-)
  • 29. 11. 2004 14:18

    ivs (neregistrovaný)
    > K te historii - SQL nevzniklo jako fundamentalni odpoved na reseni pristupu k datum v nejake databazi nybrz jako INTERAKTIVNI dotazovaci jazyk pro bankovni pracovniky.

    SQL je "lidstejsi" zapis veci z relacni algebry databazi (pokud tedy vezmeme jen jadro SQL, bez procedur apod.), coz je fundamentalni podstata relacnich databazi. O notaci se muzeme dohadovat, nerikam, ze nic lepsiho nez SQL nemuze byt, dokonce se pouzivaji i jine notace, nicmene na principu relacnich databazi to nic nemeni. Stojim si za tim, ze pro nektere veci (a neni jich malo) jsou relacni databaze velmi vhodne, a pak urcite stoji zato pouzivat SQL.

    > uspesnost systemu - zde se hovori o komlexnich systemech a ne o nejakem primitivnim webu. A me nejsou znamy takove uspesne systemy.

    Priznavam, ze s bankami zkusenost nemam, ale na pomerne slozitem systemu (integrace pozadavku a navrhu z ruznych oblasti, programatori ze tri kontinentu) jsem pracoval. Vespodu bylo SQL, kupodivu to neznamenalo zadne problemy pro vyssi vrstvy - prave diky striktnimu oddeleni. Objektovy interface do datove vrstvy se po pocatecni stabilizaci menil jen po explicitnim souhlasu vsech, a prestoze se ta nejnizsi vrstva nekolikrat zmenila kvuli optimalizaci, nebyl to pro ty vyssi vrstvy zadny problem. Tj. databaze plnila svuj ucel, SQL pro to bylo vhodne, a nikdo si nestezoval, ze by bylo k nicemu.

    O primitivnim webu se asi nebudeme dohadovat - tam jak vidim sam uznavate, ze neplati, ze je SQL k nicemu (a zde se hovori o tom, proc je ci neni SQL k nicemu).

    > Znam ovsem projekty, kde je na pozadi nejaka relacni databaze ale v systemu se nepouziva zadny SQL statement

    a co se tedy pouziva pro rozhrani do teto relacni databaze?

    > deklarativni jazyky - problemy vznikle soucasnym pouzitim techto prostredku s imperativnimi se nazyva bezne "impedance mismatch" - v literature buhuzel casto zuzen na problematiku zobrazeni realneho sveta na relacni model.

    tohle moc nechapu - impedance mismatch se tyka problemu relacnich databazi v objektove orientovanych systemech. Ano, to je samozrejme problem - relacni a objektovy pristup je jiny, a pri spatnem oddeleni vrstev systemu to vede k problemum, ktere popisujete.

    Nechapu ale moc, jak to souvisi s deklarativnimi jazyky. OO jazyky nemusi byt deklarativni (a ty nejznamejsi nejsou). Jinak ja deklarativni jazyky pouzivam na nektere veci rad, a myslim si, ze jsou pro udrzbu lepsi nez imperativni jazyky.
    SQL je pro system brzda asi podobna tomu, ze deklarativni jazyk nakonec prece jen musi zavolat API systemu, aby se s uzivatelem domluvil.
    (Jak to rikal Dijsktra s temi vrstvami? :-))

    > Laicky by se dalo rici, ze "deklarativni systemy" potrebuju ke svemu zivotu UPLNOU znalost pravidel systemu, ve kterem funguji. To je ale v rozporu s principem modularity (information hiding), kde je dulezite, aby moduly existovaly samotne se vsim vsudy.

    Tohle ale vubec neni pravda. Deklarativni systemy se pouzivaji prave proto, ze nepotrebuji uplnou znalost pravidel systemu! (jako je v proceduralnich systemech, zejmena tech nepouzivajicich ani OO pristup, kdyz uz nic jineho).

    > V nejakem informacnim systemu je treba zjistit mnozstvi zbozi na sklade. V SQL-sytemech je to reseno tak, ze podle predem stanovenych pravidel se odsadi nejaky SELECT eventuelne se SUBSELECTY v nejake UNION apod.

    Ano, ve spatne navrzenem systemu to bude presne tak, jak popisujete. V dobre navrzenem systemu zalozenem na SQL se pouziji takzvane pohledy (VIEW), tj. budeme mit ono information hiding, ktere zminujete, bez ohledu na to, jak se v budoucnu zmeni tabulky v databazi. Kdyz se zmeni, je samozrejme treba upravit interface, ale uz nic nad tim - tj. pri zmene modulu nemusim menit nic jineho.

    > To je take duvod, proc se takove systemy realizuji v PROJEKTECH. To ze je SQL k nicemu by se zjistilo okamzite, kdyby nekdo zkusil takovy projekt realizovat oddelene.

    Duvod je ve spatnem navrhu - pokud neni nekdo schopen napsat stabilni modul, ktery interne SQL pouzije, pripadne nedava ven vse (pouziva treba VIEW), pak samozrejme nezbyva nez resit problem projektove (tj. po skonceni projektu nebo po odejiti nekolika programatoru muze zacit misto udrzby dalsi projekt, ktery totez resi znovu).
    Ovsem tato neschopnost nedava duvod k tvrzeni, ze SQL je k nicemu.

    Mimochodem, dekuji za Vasi reakci - myslel jsem, ze neodpovite. Docela by me zajimala odpoved na otazku vyse - tj. co misto SQL pouzivate k pristupu k relacnim databazim.