Vlákno názorů k článku
Jak je na tom Česko s IT odborníky?

Ona bude, hned co se prestane filtrovat matematickou analyzou na oborech, kde neni NAPROSTO nutna pro budouci obor (a ne tedy predevsim pro ego ucitelu) - statistika kolik SS odeslo z VS diky matalyze a ted se IT zivi, by urcite bodla :)

Coz je ovsem podruzny duvod, vuci hlavnimu - tedy nutnosti ziskat 300 kreditu v ruznych obskurnich predmetech, z nichz jen maloktery ma cosi spolecneho s dnesni urovni IT, natozpak aby specializace skutecne pripravovala na budouci povolani.
Kazdy kdo nejde na VS primo z gymnazia si pak snadno odvodi, o co vsechno za tech pet let prijde a co za ne ziska - a to je hodnoceni, ktere ceske skolstvi vyhrat nemuze (vyjimek specializaci, na ktere dokaze pripravit, je pomalu).

Na druhou stranou je zas desive, co dokazi produkovat soukrome "vysoke skoly IT".

Z tebe vylozene cisi zapsklost jednoho z tech vyrazenych na analyze...

Nerikam, ze vsechny povinne predmety maji smysl (ano, a nektere jsou tam skutecne jen proto, aby nekteri teoretici pracovnici meli co prednaset), ale zas na druhou stranu si myslim, ze vetsina vysokoskolskych kantoru MA v tomto vyrazne kvalifikovanejsi nazor nez ja, nez ty a nez 100% dalsich kafrajicich studentu...

nejlepsi IT skola je stejne ,,vysoka jednorozecka''! ;-]

Mi stačila fráze - nejvíce odborníku je v Praze...
To jo, ale otázka je odborníků na co? Tak dobře jsem se už dlouho nezasmál.

Oni nemysleli odborník ale "odborník". Odborník dělá odbornou práci, "odborník" bere hodně peněz za "odborné" řeči. ;-)

Oni to mysleli spíš tak, že v Praze je nejvíce pracovních míst, nejlépe placených, největší možnost vzdělávání. Také je Praha nejlidnatější město s největším počet škol a s největší průměrnou vzdělaností. Tak nějak z toho taky vyplývá, že tu musí být i nejvíce specializovaných lidí v IT, což také je (proč by taky velké IT firmy dělaly pobočky v horní dolní, když můžou být v hlavním městě). Ale jak řekl Jára Cimrman: "Můžeme s tím nesouhlasit, můžeme proti tomu protestovat, ale to je asi tak jediné, co proti tomu můžeme dělat",

A teď prosím dokázat tato tvrzení: "V Praze je největší možnost vzdělávání" a "Praha je město s největší průměrnou vzdělaností". Neříkám, že to nemusí být pravda, ale nevěřím tomu, že to tak je.

A proc? Vzdyt je to snad jedno ne? To ze v Praze je nejvic pobocek velkych IT firem je fakt..a muze to byt indicie..nicmene stejne si myslim ze to je jedno :)

A vy myslíte, že to souvisí se vzdělaností? Nehraje tam spíš roli poloha, infrastruktura a rekurze - jinými slovy to, že v tom místě je nejvíc poboček jiných velkých IT firem?

Nevím jestli je Praha v nějakém směru nej, ale z IT škol je tu například solidní MFF UK a ČVUT.

Nejvice popelaru je v Praze

Programátor by ale měl základy matematiky umět. Bezpodmínečně, ať si každý říká co chce. Algoritmizace se bez základů matematické analýzy nedá dělat. Argument, že spousta lidí, kteří matematiku neabsolvovali a v IT pracují, je dost vetchý, ono je programátor a programátor...

+1

programator koder to fakt umet nemusi. Toho ani nemuzete k zadne odbornejsi praci pustit protoze to zprasi. Prumerny programator koder ma problemy i s psanim testu, codestyle a komentaru. Musi nad nim nekdo stat a delat mu nad commity code review, bez toho ho ani neni mozne nechat pracovat.

Zajimavy je ale ze admini (pokud nespadaji do kategorie reset boy, kde se musi davat bacha jestli se nehadaji se zakazniky nebo se naopak moc neflakaji) tenhle bejbysiting nepotrebuji. Ja bych byl velice rad kdyby se tenhle dozor delat nemusel, ale smutnym faktem je ze vetsina lidi neni schopna pracovat samostatne. Pri nejblizsi prilezitosti se hned zacne flakat. Proto je potreba je neustale mlatit po hlave a klidne jim jeden commit vratit 6x, coz chudak koder velice spatne nese a poklada to za buzeraci shora.

Pravda zalezi v cem dela, mainframe cobol koder u nas zacina na 12 papirech, lamp patlal konci u dvou litru (rusko, indie, china). Neni pravda ze amik lamp matlal je lepsi nez lamp matlal z indie. je jen drazsi.

S tím vaším přístupem také dobré programátory nikdy mít nebudete. To vyžaduje výběr talentů a hlavně dobré odborné vedení. A po nějakém tom roce můžete mít pár dobrých programátorů. Že admini tenhle "bejbysiting" nepotřebují je dáno tím, že jim stačí znalosti, které mohou načerpat v knihách - zatímco programátor potřebuje ještě pořádný kus praxe. V dobách sálových středisek - blahé paměti - byly elévové vychováváni pod bedlivým zrakem šéfprogramátora a starších kolegů, kteří jim předávali znalosti. Dnes je každý samouk, protože managoři (podle vzoru magoři) na výchovu kašlou a sbírají lidi na ulici. Pak se ovšem nemohou divit. Někde dobrý programátor vyrůst musí a u vás to evidentně nebude.

Ono hlavně, pokud má management k programátorům takový despekt, tak jako důsledek budou mít ti programátoři stejný despekt i k managementu. I kdyby se tam náhodou nějaký schopný programátor přihlásil, tak poté, co zjistí Leninův přístup, tak se z něj stane taky flákač a nebo odejde.

To i ten Ballmer k nim má větší úctu, když vykřikuje "developers, developers, developers!" :)

Opravdu schopni lide jsou i moralne na vysi a jsou silni. Nejsou to takovy slabosi, kterym vratite commit 6x a 6x mu zopakujete coding style a oni se z toho podelaji a jejich sebevedomi je v hajzlu. Mysleli si ze jsou supermani, ale holt nejsou. Pritom supermani ani byt nemusi, staci jen kdyz budou poslouchat nadrizene do te doby nez se neuci tyhle zasady dodrzovat bez toho aby je nekdo neustale mlatil po hlavach.

Tihle ti lidi kdyz jim pak neco vysvetlujete tak vas vubec neposlouchaji a mysli si jak jim ten sef ublizuje ze musi to nadavani (vyklad code style) holt nejak prezit, pak odejdou ale chybu nenapravi. Co s nima? Odpadky na ulici maji vetsi cenu nez oni.

Na schopneho programatora tohle delat nemusite. Tomu proste jeho nadrizeny vysvetli jak to chceme a on to podle toho taky tak udela a k zadnym konfliktum tu nedochazi. Kdyz se mu rekne ze ma zamykat zaznamy, tak to dela a nezamyka cele tabulky.

Já tedy mám spíš opačné problémy. Ale diplomaticky řeknu, že schopný programátor znalostně, prakticky i morálně na výši by potřeboval také stejně schopného nadřízeného. Ono je strašně hezké, že tu metáte programátory jako s póvlem, ale napadlo Vás taky někdy přemýšlet, kolik nadřízených je skutečně na výši?

Já jsem pracoval v jedné firmě, kde nadřízení slíbili naprosto nesmyslný termín. Protože firmě šlo tehdy o hodně, v podstatě o existenci, nabídl jsem se, že po nějaký čas budu na tom dělat i o svém volnu, sobotách a nedělích. Nepotřeboval jsem nikoho na asistenci - byl to práce, která spadla na mě - a víte, že nadřízeného ani nenapadlo, že když jsem mu vyšel vstříc, že třeba by mohl na čas upustit od požadavku být v kanceláři a ušetřit mi tři hodiny dojíždění denně a když už na mě kašle, aspoň urychlit projekt o tento čas? Když jsem mu to později říkal, prostě řekl ne, a že mě chce vidět sedět v kanceláři (opravdu jenom vidět, nic ode mě nechtěl, já od něj též ne).

Projekt jsem dodělat a namísto děkuji jsem dostal kritiku, že jsem použil efektivnější postup pro programování, než po mě žádal (znovu připomínám, šlo o čas a termín, a šlo o finanční bytí a nebytí firmy, bylo to drsné).

Nakonec jsme odešel, a po čase jsem se doslechl, že firma práci všech programátorů kromě mě musela zahodit, protože ačkoli to bylo psaní v souladu s nadřízeným, nikdo to nikdy neuvedl do stavu, kdy by to bylo aspoň trochu bez chyb, a udržovat už se to nedalo vůbec. Všichni zákazníci nakonec odstoupili od smluv. Jediné, co živí firmu je to, cojsem tehdy naprogramoval já, je to perfektně udržovatelné, a funguje to na 100% se vším všudy.

Občas by i šéfové nemuseli být kreténi.

Pracovat o sobotach a nedelich pro firmu ktera neni vase je pitomost. Taky musite nekdy odpocivat. Kdyz to od vas nadrizeny vyzadoval tak jste mu s tim mel flaknout a jit jinam kdyz vam nechtel vyjit vstric.

Proc se starate o to zda firma krachne nebo ne? Neni vase tak o co jde. Kdyz udela management spatne rozhodnuti a projekt chybne naplanuje tak za to holt zaplati. Takovy je zivot.

Výborně, takže nestojíte ani o obětavé zaměstnance. ;-)

presne tak. Ja si svych kvalitnich zamestnancu vazim a nikdy bych si je nedovolil honit do prace o sobotach a nedelich. Chci aby si od prace odpocinuli. Byznys je sice hodne dulezity, ale nezijeme proto abychom dreli jak kone.

Pokud se projekt nestiha, tak v pripade krize nektere casti outscorujeme IT firmam, kde mame majoritni balik akcii a tutiz muzeme kontrolovat vyrobni proces a mame jistotu ze budou dodrzeny nase vyrobni standardy.

To je snad poprvé, co s vámi souhlasím. Úplně miluju, když u nás ve firmě vedoucí projektu oznámí, že se nestíhá termín a okamžitě doplní, že to budeme muset řešit přesčasovou prací (se kterou mají obrovské problémy s ochotou jí zaplatit).

OT: Nepracujem v IT, ale kedze aj u nasich managorov zacinaju prevladat taketo nazory (a pokial viem takato situacia je vseobecne platna v EU), preto radim skontrolovat stav UPS a mnozstvo nafty v dieselagregatoch (pripravte sa skor radovo na dni ako na hodiny).

Musim rict ze na cele diskuzi k tomuto clanku mne zaujal nejvice fakt, ze tenhle prispevek byl jako jediny z mych prispevku moderovan down.

fesaku uz te ctu nejakou dobu - a ty tvy vylevy sou fakt neuveritelny - nevim co si o sobe myslis (asi dost) ale podle tech sracek bych te tipoval na peknyho dementa - strc si sve kod konvence doprdele a nesud ostatni - takovejm jako ses ty to rozhodne neprislusi

YF

+1...!

Každá práce chce svoje. O tom se nemá cenu bavit. Někdo nepochopí, že poté co dva dny procházíte desítky cizojazyčných web-stránek i stránek tištěných knih, pak potřebujete další dva dny na praktické vyzkoušení celého "připravovaného postupu" a jeho "pochopení". Opravdu dobrým se stejně stanete až při dalším "vyřešení toho stejného problému", kdy si jednak zafixujete postup a opravdu pochopíte to podstatné a uvědomíte si souvislosti ...

V této fázi by bylo nejvhodnější zkušenost předat zbytku týmu a naopak se od kolegů naučit něco nového, co vám zjednoduší život a práci. Ale jak jsem psal v jiném příspěvku dnes je to jen utopie ...

Tenhle nazor slycham dost casto.

vychovavat programatory je velice ekonomicky neefektivni proces. Investujete do nej nemalo prostredku a neni tu vubec zarucena jejich navratnost, protoze se clovek proste muze nechat zdarma vytrenovat a pak jit proste delat jinam kde dostane vic. Musime ho platit nejakou dobu po te co se vytrenuje mene, aby se nam vratili nase investice do nej. To lidi dost nelibe nesou a nechapou to. Kdybychom meli platit tolik, co je na danou pozici obvykle tak v tomto pripade je si lepsi najmout jiz hotovou pracovni silu, coz taky preferujeme. Vyjde to casove i financne lepe. Proc investovat penize nekam kde neni zarucena jejich navratnost?

Kazdy clovek je odpovedny za svoji karieru. Nehazejte laskave odpovednost na management. Pokud nechce u nas clovek delat nadosmrti kodera, tak se musi sam snazit aby si zvysoval svoji odbornost. Poradame za timto ucelem placena skoleni. Placena byt musi, protoze si toho pak lidi mnohem vice vazi a snazi se naucit co nejvice, aby postoupili na vyssi pozice a vratili se jim investovane prachy do skoleni. Jinak vam tam lidi budou chodit jen aby se ulili z prace a navic tam budou jeste delat bordel a otravovat prednasejiciho.

Dam vam priklad:

V dnesni dobe se mnozi pocet absolventu VS kteri jsou vystudovani programatori, ale nikdy nic nedelali krome cviceni. Nic nekodili pro sebe behem prazdnin nebo studia na SS/VS.
Kdyz se jich ptam proc, ptaji se proc by to delali. Na pocitaci si hraji hry misto toho aby si tam treba nainstalovali oracle, WAS a neco malo s tim zkouseli delat.

Temhle lidem nemuzu sverit zadnou praci, protoze to podelaji a jejich nadrizeny by z nich dostal psotnik a stejne by je po tydnu vyrazil. Jediny co by se jim mohlo sverit je lamp hnuj (protoze resetboy pozici by asi nevzali), kde se na kvalitu moc nekouka, jenze oni ani ten lamp neumi. To ze umi teorii kompilatoru? No ale my si kompilatory nedelame, my si je normalne kupujeme jako zbytek sveta.

Jsem odpovedny za to ze si tenhle odpad podelal svoji karieru a u nas pak dostal kopacky?

Napriklad http://leviathan.xf.cz/?p=78 tenhleten clovek ma pro mne mnohem vetsi cenu nez vyse zmineni experti. Tohodle bych hned zamestnal s nastupnim platem $4k a po mesici by se uvidelo.

Napriklad http://leviathan.xf.cz/?p=78 tenhleten clovek ma pro mne mnohem vetsi cenu nez vyse zmineni experti. Tohodle bych hned zamestnal s nastupnim platem $4k a po mesici by se uvidelo.

"...protože si myslím, že mi to prospěje na vejšce, kde se snad v jiném vyšším jazyku ani nedělá."

ROFL, you've made my day! :-D

Takoveho cloveka bych v zivote nezamestnal a myslete si co chcete, proste to neni pro me ani koder... (Tedy podle toho jak se vyjadruje na zacatku clanku, pak jsem totiz ztratil chut cist dale ... :-( )

ja bych ho zamestnal jako admina na i5/os. To neni tezka prace pokud prekonate ruzne psychologicke problemy zpusobene strachem z mainframe technologii a s tim by leviathan urcite problem nemel kdyz zvladnul hezky ten solac, ktery taky neznal.

To má být kvalifikace? Já si zase rozchodil VM/370, CMS, XEDIT... "Hezky zvládnul?" Cvičenou opici vám skutečně může dělat kdekdo. To IMHO není důvod jásat nad tím, že jeden jouda si umí nainstalovat domácí písíčko.

cvicena opice je na pozici resetboy nebo porizovacka. Na vsechny ostatni pozice potrebujete ruzne kvalifikovane lidi. Myslite si ze by tu administraci i5/os nezvladnul? Jasne ze jo.

"V dnesni dobe se mnozi pocet absolventu VS kteri jsou vystudovani programatori, ale nikdy nic nedelali krome cviceni."

Ještě za mě byl na matfyzu povinný předmět "softwarový projekt", kde tým 4-8 lidí musel za rok až dva napsat větší program. Pak se jeho povinnost zrušila, protože lidi breptali, že to bylo moc těžké :-(

To je pravda, tyhle tymove projekty jsou uzasne. Par takovych jsem na vysce absolvoval a delal praci nekolikrat za 2 lidi, jednou za 4. Proc? Protoze zbytek tymu to neumel a ja ten predmet potreboval udelat... Opravdu uzasny system.

Ale takhle to může bejt i v reálu, takže ses aspoň naučil, jak to chodí :) U našeho projektu to tak naštěstí nebylo.

Ne, takhle to v realu nemuze byt (resp. nemelo by). Pokud delam projekt za 4 lidi v stejnem terminu, tak si za to uctuji uplne jine castky nez pokud delam 1/4 prace v pohodovem terminu.

Souhlasim s tebou, ze je dobre si timto projit, clovek muze i takhle pri studiu ziskat dost cenne zkusenosti. Ale vysledna realita je uplne jina, cely predmet je pak pro vetsinu lidi o tom, zda narazi na cloveka, co tomu rozumi (nebo je alespon takove natury, ze vi, ze musi a udela to- to se stalo kamaradovi). A ani mne nepomohlo lidi z takovychto projektu vyhazovalo, vysledek byl stejny, jenom s tim zadostiucinenim, ze se nesvezli lidi, co se nesnazili - prace zustala stejna... Navic mi zavani principem kolektivni vinny (resp. kolektivniho hodnoceni - misto individualniho). Coz neni dvakrat dobry system pro hodnoceni na VS.

Tak ses aspoň naučil, jaké lidi nemáš najímat. Pokud si ve své firmě najmeš nemakačenky, tak si taky budeš muset nakonec projekt napsat sám (nebo zkrachovat) :-)

S tou kolektivní vinou to tak v reálu opravdu je, zákazníka nezajímá, že to není proto, že máš v týmu blbé zaměstnance, toho zajímá, jestli to je a funguje nebo jestli to není. Na MFF aspoň nebyl časový limit na dodělání, v reálu máš navíc i ten.

Takové projekty jsme (taky povinně) dělali dvakrát na základce v Baltíkovi. Bavilo nás to a nikoho takhle nenapadlo reptat. No jo, VS...

Velmi pěkně řečeno. Dokonce si myslím, že to už došlo tak daleko, že lidé se z důvodů "zachování své potřebnosti pro firmu" snaží nepředat nic co nemusí.

Také proč, nikdo to stejně neocení. Mladí dostanou rozum až časem a už v jiné firmě. Manageři chtějí jen aby firma funguvala, byly peníze a šéf na ně neřval. Nebo naopak schvalovat každý krok, i kterému nerozumí (ale harmonogram musí sedět). Takže proč bych já pokud mi to přímo neulehčí život se měl namáhat. Nejčastěji navíc zadarmo. Navíc, popravdě i vy nejlepší, pro vedení takových firem budete vždy jen "ten jedem z ulice" ...

Za úplně nejhorší však považuji to, že stejná situace je dnes v Česku prakticky ve všech oborech, ne jen v oblasti IT!

Už to chápu. :-) Lenin se bojí o křeslo, proto ty kecy o reset boyích... :-D

no ja jim nekdy fakt zavidim. Makam jak sroub a oni si pari na nasi GBitove siti gamesy. No ale platime jim prakticky nic, tak at si hraji.

to je smesne :)

Pro zajimavost: Co je to za firmu?
Ja jen abych vedel, komu se mam veeeeelkym obloukem vyhybat

nejses nahodou jeden z tech rychlokvasenych managerum, co si nakresli do microsoft projectu hady a moc to nevychazi?

Chi chi. Vystizne!!!

Vráť mu 6x commit, rob mu to častejšie a jeho sebavedomie bude po mesiaci na bode mrazu. Po dvoch mesiacoch ti ten chlapík dá výpoveď. V krčme sa tým nezabudne "pochváliť", a budeš sa čudovať prečo vám vo firme ubúda zamestnancov a noví nie a nie prísť. Kontrola programátorov je OK, ale každá mica má dve strany.

Pokud manager dovoli programatorum commitovat chybny kod z toho duvodu, ze kdyby jim to vratil tak ze by to chudinky coderi spatne nesli, tak dostane padaka. V kazde fabrice se kontroluje vyroba na zmetky a zmetky se musi vyradit. Pri vyrobe softwaru to plati rovnez. My nekvalitni software delat nemuzeme, protoze nas soft povetsinou zpracovava prachy.

Ano nekteri lide tuto kontrolu nevydrzi. S temi je treba se rozloucit. Takovy je zivot.

Náš software takisto spracúvava citlivé údaje. A chyby boli sú a budú. Problém je v tom, že máš na všetko absolútne pravdivú odpoveď. Skvele zapadáš ku našim koaličným lídrom ;-)

A chyby boli sú a budú.

Jsou metody jak snizit vyzkyt chyb v software na naproste minimum. Unit testy procedur, funkcionalni testy, lock order testy, testy unit testu, call tree testing a mnoho dalsich. Neni neobvykle ze zakaznik plati za mesicni praci naseho software developer teamu treba i $200k a to je opravdu hodne penez. Ve vyslednem produktu proste ty chyby byt nesmi, ten software zpracovava stamiliony dolaru rocne pokud se jedna treba o soft pro fabriku.

A jestli je mozne udelat software prakticky bezchyb? Ano, mozne to je, jen je to dost drahe protoze to vyzaduje metodiku ktera je narocna na cas (krom toho ze ji musi vas team umet).

Jak by se vam libilo kdyby vam banka rekla, no poslal jste si na ucet par tisicovek ale to vite naz soft ma nejake races a tak se ta platba ztratila, to vite musime dovolit coderum komitovat zmetky jinak to ti lide spatne nesou a my chceme mit klid na pracovisti. Asi byste ten ucet u ni dost rychle zrusil.

Podnikani v high endu je narocne. To je realita, zadarmo vam nikdo velke baliky penez neda a kdyz vam je da tak pak pozaduje opravnene zaruky. Ja jsem si zkusil zadat cvicne par zakazek u vetsich ceskych firem delajicich SW abych zjistil tak to tady v cechach vedete a ty smlouvy co mi nabizely ty byly opravdu smesne - dejte nam prachy, za nic nerusime, zdrojaky nedostanete ani za extra penize, pokud chcete aplikaci dat nekomu kdo neni z vasi firmy (reseleri), tak to nesmite. Kdybych nabidnul ja stejne podminky svym zakaznikum, tak bych u nich skoncil.

"Unit testy procedur, funkcionalni testy, lock order testy, testy unit testu, call tree testing"... a k tomu ty super drahe metodiky! Vsechno to jsou jenom siditka! Dobre tak pro opice, ktere toho o programovani moc nevi. Az budete delat k tem super bajecnym, bezpecnym, nejrychlejsi, nejvetsim programum formalni dukazy spravnosti, tak si pindejte! Ale pochybuju o tom, ze ve vasi firmu bude clovek, ktery to umi a pokud by byl, tak uz tam radsi neni, protoze je to prece jenom opice a budiz k nicemu.

> Az budete delat k tem super bajecnym, bezpecnym, nejrychlejsi, nejvetsim programum formalni dukazy spravnosti, tak si pindejte!

Povinny citat: "Beware of bugs in the above code; I have only proved it correct, not tried it." -- D. Knuth

Pokud ten formalni dukaz proveri pocitac, tak tam pak chyba urcite neni, protoze pocitace se nikdy nemyli. (mineno napul vazne, napul ironicky)

unit testy nejsou siditka. nevim na cem si kdy delal, ale velkej soft se bez metodiky delat neda.

Delal jsem toho dost na to, abych vedel, ze unit testy odhali maximalne nejvetsi krpy, jakekoliv dalsi rafinovanejsi souvislosti a s nima spojene chybove stavy jsou na ne prilis. Zajimalo by me co si pod metodikou predstavujes: "bichle na tema-neprogramujte jako hovada" nebo "programujte si jak chcete hlavne, kdyz u toho nakreslite moc obrazku a popisete co nejvic papiru"... tu prvni vec opravdovy programator nepotrebuje a tu druhou taky. Je tu rozdil, ze ta prvni "metodika" mozna nekomu pomuze. Osobne proti metodikam nic nemam, je naprosta samozrejmost, ze se ve firme pouzivaji nejake postupy, ktere se osvedcily. To bych se tu zachvilku mohl chlubit, ze nasi zamestnanci se denne sprchuji, proto je nas software lepsi!

takze rozumim vam spravne ze vy chcete delat u vseho formalni dukazy spravnosti a odsuzujete vsechny ostatni bezbe pouzivane testovaci metody? i.e. unit testy

A jak chcete jinak overit, ze ty penize skutecne dojdou? Nebo to vase opicky neumi? A co vasi dobre placeni odbornici?

To si rovnou muzete poridit par set opic, koupit psaci stroje a zacit vydavat noviny a laskavym ctenarum tvrdit: sice to pisou opice, ale nebojte se mame vyborny spell checker.

On je neodsuzuje, on pouze říká, že nefungují.

Současný způsob psaní SW připomíná řízení prozovu na jednokolejné trati pomocí obsluhy. Bohužel lidé dělají chyby, a občas to nevyjde. Metodika je tu k tomu, abychom popsali, jak nastavovat praporky, a možná i to, že se řidiči mají před každou jízdou osprchovat, protože pak dělají méně chyb :). Samozřejmě Software Model Checking jednou poskytne o řád lepší výsledky. Zatím je třeba technologii dopracovat, a uvést do praxe. Bohužel je smutným faktem, že jazyk C obsahuje řadu nebezpečných konstrukcí, které model checking prakticky vylučují. No a to se dostáváme k tématu "v .NETu je to jinak", kde se řada lidí začne zvedat ze židle, a tvrdit, že tudy cesta nevede :)

Pokud přirovnáváte programování k řízení provozu na trati, tak z toho neplyne nic jiného, než že absolutně nevíte, co to programování je.

Uvědomte si všichni už konečně, že psaní webových stránek NENÍ PROGRAMOVÁNÍ! Vytváření modelových databázových aplikací NENÍ PROGRAMOVÁNÍ! (ve FoxPro se tomu říkávalo "generování aplikací" a bylo to z velké části automatizované, i když ne tak, jako dnes) Když někdo napíše skriptík na zautomatizování nějaké činnosti, tak to NENÍ PROGRAMOVÁNÍ! Takové věci dělávaly operátorky na letištích už před dvaceti lety a nikdo je nenazýval programátorkami.

Programování je tvůrčí činnost. A stěžovat si na jakési "nebezpečné konstrukce jazyka" - to je jako by si řezbář stěžoval, že se může dlátkem pořezat nebo neopatrným zacházením zkazit celou svou práci.

KDYŽ S TÍM NEUMÍTE, TAK S TÍM NEDĚLEJTE! Ale neházejte svou neschopost na svoje "nářadí". Tak jako dobrý řezbář je schopen udělat hodnotné dílko i s pomocí zavíracího nožíku, tak schopný programátor dokáže napsat dobrý program i v Assembleru.

To je jako by se každý člověk, který se naučil obsluhovat samohrajky CASIO považoval za klavíristu ale nadával by na koncertní křídlo, protože mu umožňuje zahrát jakýkoliv akord, i ten, co nezní. Ale chyba nebude v tom koncertním křídle, jak asi každý tuší...

Přirovnání programování k řízení provozu na jednosměrné trati má opodstatnění. Ne ve vlastní činnosti, ale v tom, že lidé dělají chyby, a nedá se tomu zabránit. Dají se ale vymyslet způsoby, jak četnost chyb snižovat. V tom je ta paralela.

Psaní webových stránek, DB aplikací apod. JE programování. Programování je psaní DB engine, file systému, i knihovničky domácího videa. Nemusíte mi říkat, že programovat v ABAPu a programovat v C jsou dvě výrazně odlišné věci; velmi dobře to vím.

Když to neumíte, tak s tím nedělejte. No, to je právě ten problém. KDO tedy "umí"? Autoři komerčních unixů zjevně neumí, protože unixy byly v 80. letech postiženy velikou vlnou buffer overflow problémů. Autoři MSIE, FireFoxu, Windows, Linuxu, KDE, Adobe Readeru a hromady dalšího SW zjevně také neumí, protože ve všech těch SW se objevují každým rokem hromady chyb, včetně bezpečnostních. Jestli ono to nebude tím, že lidé dělají chyby, jak jsem psal v prvním odstavci. Pokud připustíte, že lidé chyby dělají (byla by chyba to nepřipustit), tak je otázka, jak ty chyby řešit. Já bych byl pro používání jazyků, které nesvádějí k chybám, a minimalizují jejich následky. Ne jako C, které k chybám vyloženě svádí, a v případě chyby často dojde k přepsání čehosi nesouvisejícího v paměti, a aplikace jede dál (a chová se divně, nebo zhavaruje na něčem nesouvisejícím, nebo to celé "jen" vede k exploitu).

Chápu, že vás baví programovat. Možná si mylíte, že to "pravé" programování je v C nebo ASM. Jenže to je zásadní omyl. Nepleťte dohromady své pocity uspokojení z určitého stylu programování s potřebami zákazníků (a potažmo IT průmyslu).

Je ve vasi firme bezny ze manager kontroluje kazdej commit nebo se tak nudis? V normalnich firmach maj na starosti odhalovani chyb v prvni rade unit testy a v dalsi testeri. Na technickej dohled sou team leadri a manazeri delaj planovani. U vas to takhle nefunguje? Mozna je nekde neco spatne...

ale jo, funguje.

Říkám si co chci - programování už dávno není jenom o psání algoritmů. Ve některých oblastech nenarazíš na pořádný algoritmus celý rok. Proč taky, když obrovský boom zažívají frameworky a jazyky jako Ruby se svým principem "fast enough". Ve spoustě oblastí se stává hlavní prioritou "mít to rychlE" a ne "mít to rychlÉ". HW je levný, čas programátorů drahý a spustit službu za 6 nebo 12 měsíců může znamenat rozdíl mezi úspěchem a fiaskem. Fiktivní rozhovor s uchazečem o práci potom klidně může vypadat "Matematická analýza? To je určitě zajímavé, ale orientaci na zákazníka byste tam neměl?" :-)

Ono hodně zkazilo povědomí o programování to, že webové "programování" se považuje vůbec za programování. V zásadě je programátor a programátor. Webové programování je opravdovým programováním jen zřídka. A docela rád bych vás viděl, jak byste se svěřil třeba lékařskému přístroji naprogramovanému programátorem "orientovaným na zákazníka" a neznající ani slabě základy matematiku. A pokud ano, pak jste opravdu hodně věřící.

A co si tak Kefalín představujete pod pojmem "opravdové programování"? Záleží to na použitém jazyku (třeba horní polovina v klasickém dokumentu programátorské hierarchie? Nebo na tom musí záviset zdraví minimálně 5 lidí, případně celoživotní úspory minimálně 100 lidí? Nebo opravdoví programátoři jsou ti, kteří dokáží bezchybně rozdělit programátory na "opravdové" a "ostatní", protože ti "ostatní" vlastně ani neví, že jsou druhá liga? Nebo se opravdoví programátoři vyznačují tím, že nedokážou pochopit nadsázku (pro jistotu zdůrazněnou smajlíkem, žel pořád málo) a nerozumí slovu MŮŽE? :-) Pro jistotu - to znamená, že existují obory, jako třeba vývoj SW pro lékařské přístroje, kde ten rozhovor bude probíhat úplně jinak.

Návrh uživatelského rozhraní, nebo lepení již hotových předpřipravených komponent bez ničeho dalšího - to je "programování". Nic proti tomu nemám, a je to samozřejmě také potřeba - není to nic méněcenného. Ale mě přijde úchylné se bavit o tom, jestli takové "programování" potřebuje matematickou analýzu, když odpověď je nad Slunce jasná! Takové "programování" totiž nejenže nepotřebuje matematickou analýzu, ona je tam zbytečná i ta vysoká škola. Na to stačí poměrně jednoduché zaučení a nic víc není potřeba - možná víc grafický cit a ta orientace na zákazníka, než nějaké znalosti.

Prosím abyste odhlédl od Vašeho mylného výkladu, že opravdové programování je něco, čím se kdo povyšuje. Ale v každém povolání jsou prostě dělníci u pásu, stejně tak jako tvůrčí lidé. Obojí je potřeba a jedno bez druhého nemůže existovat. A pro to dělání na pásu opravdu nepotřebujete ani vysokou školu, ani matematickou analýzu.

Všechna nedorozumění tu vznikají z toho, že vezmete "programátorského dělníka na pásu" - a začnete se hádat, jestli potřebuje mat. analýzu. Nepotřebuje, samozřejmě, že ne. Ale programátor, který je tvůrčí se bez matematiky neobejde, za tím si stojím.

A právě u složitějších úkolu v programátořině je dobrá znalost matematiky něco, co
za a) umožňuje to celé mít hotové mnohonásobně rychleji, než bez znalosti matematiky, za b) často je podmínka vůbec aby se dal program udělat, za c) často je to podmínka toho za c) abyste na následné údržbě programu poté neprodělali majlant kvůli nedostatečně zvládnuté implementaci. Taktéž z matematicky vzdělaného člověka, jak se v praxi projevuje lezou obvykle spolehlivější programy.

Návrh uživatelského rozhraní, nebo lepení již hotových předpřipravených komponent bez ničeho dalšího - to je "programování"

Ono programování webové aplikace ale přeci není jen lepeni hotových komponent. Programátoři business logiky v takové aplikaci by měli být docela na úrovni.

A právě u složitějších úkolu v programátořině je dobrá znalost matematiky něco, co za a) umožňuje to celé mít hotové mnohonásobně rychleji, než bez znalosti matematiky, za b) často je podmínka vůbec aby se dal program udělat, za c) často je to podmínka toho za c) abyste na následné údržbě programu poté neprodělali majlant kvůli nedostatečně zvládnuté implementaci. Taktéž z matematicky vzdělaného člověka, jak se v praxi projevuje lezou obvykle spolehlivější programy.

S ani jedním bodem nemohu souhlasit, přesto že jsem MA prošel. Matematika obvykle stačí středoškolská, důležitější je mít abstraktní myšlení, znát OOP, AOP a podobné techniky, umět pracovat v týmu, zvládat návrhové vzory, umět dobře chápat UML diagramy, být spolehlivý a svědomitý, snažit se neustále se vzdělávat atp. To, že z matematicky vzdělaného člověka lezou obvykle spolehlivější programy je takový výkřik do tmy. Samozřejmě určité typy algoritmů vyžadují hluboké znalosti matematiky, ale takových lidí stačí ve větší firmě pár.

To je pravda. Ono zmyslom tej analýzy a podobných predmetov nie je naučiť informatikov integrály, zmyslom je naučiť ich abstraktne myslieť.

....ono je to - ci snad To - napsane na kazdem rohu,
ne ze vetsina lidi nechape, jen bych rad vedel, jestli
lidi co maji za sebou fcionalni analyzy a stochasticke integraly
nerikaji ano a lidi z analyzou, pripadne SS matikou, nerikaji ne
hm??

Zkus to prelozit do cestiny. Takhle asi nikdo nechape dotaz ... pokud tam tedy nejaky je.

Dvojitá dávka kombinatoriky je podle mě pro programátora užitečnější než kombinace kombinatoriky a analýzy.

No myslim, ze ani s tou kombinatorikou by se to nemuselo prehanet. Spis bych volil kombinaci kominatoriky, algebry, pravdepodobnosti a statistiky.

Hezky řečeno, stačí pak dodat že pravděpodobnost a statistika je z valné části vystavěna na matematické analýze. A jsme doma:-)

A co takový programátor spojitých výpočtů, fyzikálních simulací a tak? Ani tomu není analýza užitečná? ;-)

Tam to ovšem není věcí IT, ale věcí jeho další kvalifikace. Kdo píše ekonomické systémy, musí něco vědět o managementu, účetnictví, HR apod. Má proto každý student IT oborů studovat pár semestrů ekonomiky a managementu?

Osobne si myslim, ze tak uplne o veci by to nebylo.
Ber to takhle: Pokud budes dobry, tak drive ci pozdeji povedes svuj tym. A budes, chca nechca, sestavovat rozpocet, rozdelovat ukoly, ... (s)prosty management a ekonomika. A v tom okamziku se to bude sakra hodit. Ver mi, ze mluvim z vlastnich zkusenosti.

"S ani jedním bodem nemohu souhlasit, přesto že jsem MA prošel. Matematika obvykle stačí středoškolská, důležitější je mít abstraktní myšlení, znát OOP, AOP a podobné techniky, umět pracovat v týmu, zvládat návrhové vzory, umět dobře chápat UML diagramy, být spolehlivý a svědomitý, snažit se neustále se vzdělávat atp. To, že z matematicky vzdělaného člověka lezou obvykle spolehlivější programy je takový výkřik do tmy. Samozřejmě určité typy algoritmů vyžadují hluboké znalosti matematiky, ale takových lidí stačí ve větší firmě pár."

Možná uvedu pár fakt: Já jsem ve svém programování velmi dobře využil vysokoškolskou matematiku, a to nedělám nic extra. Jsem starší ročník, neučil jsem OOP, AOP, UML ani další - ale každou z těchto zkratek jsem v pohodě pochopil a vzal za své během max. několika dní. Ono totiž jde o v podstatě primitivně jednoduché věci - na které opravdu nepotřebujete školu, a není třeba z toho dělat bůhvíco. S návrhovýma vzorama je ta sranda, že dříve nebyly, a že když se objevily jako super novinka, tak jsem s úžasem zjistil, že už tak dávno programuji. Prostě máte-li cit pro programování, spoustu dobrých věcí děláte, aniž byste o tom musel číst.

Navíc přiznejte si, že spolehlivost, svědomitost, schopnost práce v týmu - to jste úplně vedle, to totiž nejsou znalosti, ale osobní schopnosti člověka, a pokud se bavíme o potřebných znalostech programátora, tak jenom zbytečně uvádíte věci mimo téma.

Znovu říkám, na lepení komponent nepotřebujete žádnou extra programátorskou teorii znát. Je to stejné jako ten, kdo skládá počítače nepotřebuje znát podrobněji elektroniku, přestože s elektronikou dělá. A těch pár zkratek kolem lepení komponent se snadno zaučíte - pak je skoro zbytečné jít na školu.

Možná uvedu pár fakt: Já jsem ve svém programování velmi dobře využil vysokoškolskou matematiku, a to nedělám nic extra.

Nějaký konkrétní případ na to využití vysokoškolské matematiky by byl? Já za poslední 2-3 roky nevyužil vůbec nic. Samozřejmě pokud je na pořadu dne počítačová grafika (a její algoritmy) nebo matematický a podobný software, pak prosím.

Jsem starší ročník, neučil jsem OOP, AOP, UML ani další - ale každou z těchto zkratek jsem v pohodě pochopil a vzal za své během max. několika dní. Ono totiž jde o v podstatě primitivně jednoduché věci - na které opravdu nepotřebujete školu

Školu nepotřebujete na spoustu věcí, ale to neznamená, že je to lehké. Pochopit základní princip OOP opravdu nic těžkého není. Ale vytvořit dobrý design s UML diagramy tak, aby byl srozumitelný a formálně správný, to už nějaké znalosti chce. A chce to také hlavně zkušenosti.

Navíc přiznejte si, že spolehlivost, svědomitost, schopnost práce v týmu - to jste úplně vedle, to totiž nejsou znalosti, ale osobní schopnosti člověka, a pokud se bavíme o potřebných znalostech programátora, tak jenom zbytečně uvádíte věci mimo téma.

Samozřejmě to nejsou znalosti, ale vlastnosti, nicméně i ty lze časem získat (i to se dá naučit). Každopádně jsou přibližně stejně důležité jako ty znalosti. Možná i důležitější, protože znalosti se dají získat asi i snadněji. Mimo téma mi to rozhodně nepřipadá.

Znovu říkám, na lepení komponent nepotřebujete žádnou extra programátorskou teorii znát. Je to stejné jako ten, kdo skládá počítače nepotřebuje znát podrobněji elektroniku, přestože s elektronikou dělá. A těch pár zkratek kolem lepení komponent se snadno zaučíte - pak je skoro zbytečné jít na školu.

Ona to není tak úplně pravda. Na lepení komponent je nejlepší znát i ty komponenty uvnitř velmi dobře. Často dojde k situaci, že ladíte chybu a musíte rozumět tomu, jak se může projevovat a kde jí opravit. To bez znalosti komponent dáte dohromady těžko. A že studovat dneska na vysoké škole informatiku jen proto, abyste mohl jít někam programovat, je zbytečné, je myslím známý fakt. Trochu to shrnu - dobrý programátor dneska nemusí mít extra vzdělání, ale měl by mít ty výše popsané vlastnosti.

"Nějaký konkrétní případ na to využití vysokoškolské matematiky by byl? Já za poslední 2-3 roky nevyužil vůbec nic. Samozřejmě pokud je na pořadu dne počítačová grafika (a její algoritmy) nebo matematický a podobný software, pak prosím."

Nedávno jsem dělal zobrazovač hodnot k jednomu hw. Nic než jendoduché čtení a zobrazování jednoho hw zařízení. Uživil jsem tak zadání povolených mezí tabulkou (= interpolace), zobrazení grafu (= proložení bodů křivkou), odfiltrování šumu (= digitální filtr odfiltrovávající vyšší harmonické ve Fourierově řadě). Samozřejmě jsem matematiku používat nemusel - ale jednak bych to programovat několikrát déle, a jednak by to vypadalo hůř. Ač to nebyl záměr, program se zadavateli a hlavně kvalita výstupů a přesnost tak líbil, že ho dal jakožto reklamu na svojí firmu jako zařízení s mým program na Havajskou univerzitu, což mě těší. Matematika mi umožnila zkrátit dobu vývoje několikanásobně, za cenu vyšší kvality programu, vyšší odměny, zlepšení jména atd. atd. atd.

"Školu nepotřebujete na spoustu věcí, ale to neznamená, že je to lehké. Pochopit základní princip OOP opravdu nic těžkého není. Ale vytvořit dobrý design s UML diagramy tak, aby byl srozumitelný a formálně správný, to už nějaké znalosti chce. A chce to také hlavně zkušenosti."

Co opravdu nesnáším je nedržení se tématu. Konkněte jsou ZNALOSTI a ZKUŠENOSTI. OOP i UML jsou směšně jednoduché věcičky, které se v zásadě naučíte velmi velmi snadno. Na tom nic nezměníte, tak to prostě je - a že se z prdu dělá kulička, na tom nic nezmění.

Na to, abyste dobře navrhnul cokoli, dobrý design - a neřku-li dokonce nadčasový design (a nejenom s UML), který nebude příliš zprasem ani následující přehršlí dalších budoucích požadavků - to chce jednak ty znalosti, a jednak praxi a jednak mnohaleté zkušenosti (ne ovšem pouze s UI, nebo lepením komponent - to chce aktivně tvořit). Právě znalého a zkušeného člověka poznáte tak, že se podíváte jak jeho design dopadl po pár letech.

Právě proto se dřív z ostřílených, teoretickými i praktickými znalostmi bohatě vybavených programátorů stávali analytici - tedy návrháři designu. Protože to už chce nejen teorii, nejen praxi, ale také TALENT a CIT. To totiž nedokáže každý, i kdyby se rozkrájel a učil já nevím co a já nevím jak dlouho. Je to smutné, ale je to tak.

"Samozřejmě to nejsou znalosti, ale vlastnosti, nicméně i ty lze časem získat (i to se dá naučit). Každopádně jsou přibližně stejně důležité jako ty znalosti. Možná i důležitější, protože znalosti se dají získat asi i snadněji. Mimo téma mi to rozhodně nepřipadá."

Už zase mixujete párky s hruškama. Samozřejmě, že osobnost člověka je velmi důležitým faktorem, ale to není specifická věc v programování. Koneckonců je to důležité i pro partnerství a pro jakýkoli obor. Jsme prostě lidi, jasně, že je to důležité, ale tady jsme na tenkém ledě. Jsou lidi, kteří jsou sebedisciplinovaní od narození, a nemusí se nic osobnostně, morálně učit (pak ta Vaše věta, že znalosti se získávají snadněji jim zní jako byste spadl z višně). Ale konekonců do hodnocení ZNALOSTÍ, zdůrazňuji potřebných ZNALOSTÍ programátora, což je téma o kterém je tu řeč, to moc nepatří. Co takhle rovnou do toho přibrat, zda je pro programátora dobré mít postel na sever, nebo na jih a úloha tlouštěk žížal před domem programátora na jeho práci?

"Ona to není tak úplně pravda. Na lepení komponent je nejlepší znát i ty komponenty uvnitř velmi dobře. Často dojde k situaci, že ladíte chybu a musíte rozumět tomu, jak se může projevovat a kde jí opravit. To bez znalosti komponent dáte dohromady těžko. A že studovat dneska na vysoké škole informatiku jen proto, abyste mohl jít někam programovat, je zbytečné, je myslím známý fakt. Trochu to shrnu - dobrý programátor dneska nemusí mít extra vzdělání, ale měl by mít ty výše popsané vlastnosti."

Na lepení komponent není potřeba až tak moc dobře ty komponenty znát vnitřně. Už také proto, že vnitřek komponent se může naprosto radikálně měnit verze od verze. Jediné, co je stabilní je interface (API), a koneckonců Vy jakožto velký zastánce předůležitosti OOP (kteréžto se zapouzdřením a dalšími atributy "černé skříňky" chlubí) asi víte. Naopak, lidi musí brát komponenty tak, že co není v interface a co není v dokumentaci je NEZARUČENO! Jinak se nestačí divit, že v příští verzi komponent, systému, apod.. program blbne!

Myslím, že špičkový programátor bez vzdělání (nebo alespoň hlubokých teoretických znalostí získaných mnohem složitěji jinde) se vylučuje. To je oxymoron.

Vy budete asi solidní nervák.

Co opravdu nesnáším je nedržení se tématu. Konkněte jsou ZNALOSTI a ZKUŠENOSTI. OOP i UML jsou směšně jednoduché věcičky, které se v zásadě naučíte velmi velmi snadno. Na tom nic nezměníte, tak to prostě je - a že se z prdu dělá kulička, na tom nic nezmění.

A kde vidíte pořád to vaše debilní matematicko znalostní téma? Článek se zabýval stavem IT odborníků v ČR. Vidíte tam někde, že by se týkal matematiky a znalostí? Matematiku tu nadhodil ten první příspěvek v diskusi. Já pouze dodávám, že znalosti nejsou vůbec ta nejdůležitější složka, kterou musí dobrý programátor mít.

Nedávno jsem dělal zobrazovač hodnot k jednomu hw. Nic než jendoduché čtení a zobrazování jednoho hw zařízení. Uživil jsem tak zadání povolených mezí tabulkou (= interpolace), zobrazení grafu (= proložení bodů křivkou), odfiltrování šumu (= digitální filtr odfiltrovávající vyšší harmonické ve Fourierově řadě). Samozřejmě jsem matematiku používat nemusel - ale jednak bych to programovat několikrát déle, a jednak by to vypadalo hůř. Ač to nebyl záměr, program se zadavateli a hlavně kvalita výstupů a přesnost tak líbil, že ho dal jakožto reklamu na svojí firmu jako zařízení s mým program na Havajskou univerzitu, což mě těší. Matematika mi umožnila zkrátit dobu vývoje několikanásobně, za cenu vyšší kvality programu, vyšší odměny, zlepšení jména atd. atd. atd.

To je přesně místo, kde se trocha matematiky hodí. Ale dá se poměrně snadno nastudovat. Mimoto podobný program není nic, co by uživilo tým 20 programátorů na půl roku. Z hlediska trhu je to drobnůstka.
Každopádně bych měl pár poznámek:
zadání povolených mezí tabulkou = interpolace - co je tohle za blábol
zobrazení grafu = proložení bodů křivkou - tohle je příklad interpolace
Matematiku zde však potřebujete ne k samotnému programování (na všechny tyto operace máme dnes knihovný), ale k tomu, abyste věděl, že něco takového vůbec existuje, a kterou metodu použít pro daná data.

Co takhle rovnou do toho přibrat, zda je pro programátora dobré mít postel na sever, nebo na jih a úloha tlouštěk žížal před domem programátora na jeho práci?

Proč ne. Já se věcem zavánějícím nadpřirozenem nebráním ;) . A psychická pohoda programátora je také velmi důležitá.

Na lepení komponent není potřeba až tak moc dobře ty komponenty znát vnitřně. Už také proto, že vnitřek komponent se může naprosto radikálně měnit verze od verze. Jediné, co je stabilní je interface (API), a koneckonců Vy jakožto velký zastánce předůležitosti OOP (kteréžto se zapouzdřením a dalšími atributy "černé skříňky" chlubí) asi víte. Naopak, lidi musí brát komponenty tak, že co není v interface a co není v dokumentaci je NEZARUČENO!

Nemluvil jsem pouze o komponentách frameworku, ale i o komponentách, které vytovořili jiní lidé v týmu a které daný člověk spojuje a často také oživuje. Ono když vám nějaká komponenta vyhodí podivnou výjimku a vy nebudete vůbec vědět, která bije, tak toho asi moc neuděláte. Nemyslel jsem tím znalost každé řádky komponenty. Spíše důkladnou znalost funkčnosti a požadavků dané komponenty. Nevím, kde jste sebral to, že jsem velký zastánce OOP. OOP má svoje limity a na některé situace se vůbec nehodí.

A co že to všechno ještě nesnášíte? :) A pozor na infarkt

Vidím, že jste vstal levou nohou a potřebujete si na někom vylít špatnou náladu a zrovna nebyl nikdo po ruce, co?

Levá noha je o malý kousek blíž k srdci (u většiny lidí), tak to špatnou náladou možná nebude. Podívejte se zpátky do diskuse, co všechno nesnášíte. Na hrubý pytel hrubá záplata.

Zalezi co delas, kdyz programujes cidlo na jednocipu, je ti OOP AOP a C++ uplne k nicemu, zel musis byt zbehly v HW, analogarine a assembleru.

Kdyz programujes pro aerospace, medical a nebo vojacky, zase musis byt dobry jinde nez .net, nezalezi za rychlosti kodovani, ale na robustnosti a odolnosti.

Vetsina novych zajemcu, co se u nas uchazi o praci umi nakodit rychle aplikaci, ale neumi naprogramovat vyrobek :(. Rozumny cas, nez se zauci, je cca 1 rok u tech opravdu dobrych, az tri roky u slabsich.

Ponkraci, Ponkraci...

S abstraktnim myslenim muzes jit leda tak modelovat aplikace z predpripravenych komponent, nebo vynest smeti. Jakych komponent? Tech napsanych skutecnymi programatory. Narozdil od tebe zpravidla maji mysleni logicke, bez ktereho by samozrejme pred nejakymi 30-ti lety nemohli psat v ASM a fortranu a pokud nevis o tom, ze v CR je takovych mene nez 5%, tak si dopln znalosti a svetove spicky hledej v USA v IBM, odtamtud totiz vzesla soucasna architektura PC a 99% vseho s ni spojeneho.

Vážený připostrašený anonyme, který se nechceš ani podepsat, myslím, že na jste v blbosti příspěvku předstihl i toho nejfundovanějšího politika. Dál na to reagovat nehodlám, protože holt, když někdo vaše slovní průjmy neposlouchá v okolí, tak se hojíte jinde. Ale jo, nějak sebevědomí nahonit musíte.

Hodně vtipný je napsat část o nepovyšování se a hned v další větě rozdělit programátory na "dělníky u pásu" a "tvůrčí lidi" :-) Jenže tohle je oboustranný - existuje spousta projektů, kde tvůrčí člověk bude ten, který vymyslí a vyzkouší jak budou komponenty slepené a dělničina jsou právě ty složitější algoritmy. A jelikož zaměstnání "lepič komponent" neexistuje, tak mu všichni budou říkat programátor (programovat samozřejmě umí, i když quicksort z hlavy nedá), protože z pohledu lidí zvenku programuje a že to dělá lepením komponent? To nikoho nezajímá, stejně jako nikoho nezajímá jestli pekař připravuje těsto ručně nebo jestli si pořídí stroj, který to udělá za něj.

Tahle snaha o rozdělování mi přijde komická, protože 99% lidí v tom neuvidí rozdíl.

Hodně vtipný - problém je, že když už to rozdělím, tak se najde někdo, kdo v tom najde, že jednou skupinou pohrdám. Mimochodem, Vy jste to v mém textu "objevil" (sice nevím kde), a neustále to vytahujete. Zbytek je jen slovíčkaření z Vaší strany.

Ono je jedno, že to tak lidi nerozdělují, ani v tom nevidí rozdíl, on tam prostě je. Ono totiž u pravdy vůbec nezáleží na tom, kolik procent lidí to vidí, nebo ne.

Pardon, ale při použití slov "dělník" a "tvůrčí" je jasné "kdo je víc", aniž by muselo jít o pohrdání :-) Ale teď jsem si všiml, že jsem úplně odběhl - zkrátka tvrdím, že nic jako "opravdové programování" neexistuje a že je spousta oblastí, kde supr-dupr algoritmy nikoho nezajímají, kde se bez matematiky obejdete a kde "lepič komponent" je mnohem cennější programátor. Že definice tohohle je tak nereálná, že to může být max. něčí názor a nikdy ne pravda. Co když použiju jednu komponentu, je to ok? Nebo můžu použít dvě? Počítají se dvě malé jako jedna velká? A co když mi vedení zakáže něco vytvářet, protože není čas, ale já bych to přesto zvládl (lépe, jak jinak)?

Rozdíl mezi programátory samozřejmě je, ale v tom co dělají, ne jestli to jsou programátoři nebo "programátoři". V jednu chvíli lepíte komponenty a v druhé se moříte nad složitostí algoritmu.

Hezký den, jdu lepit svoje komponenty a nezapomenu tohle vysvětlit všem lidem, kteří si myslí (úplně chybně), že jsem programátor :-)

Jenom k poslední větě - chybně si to myslí i podle mě :-)

Holt nemůžu za to, že "podle sebe soudím Tebe" se u Vás projevuje víc, než naplno. Ale jak už jsem psal, vy diskutujete o slovíčkách namísto o významu toho co bylo napsáno. Měl jste být politikem, to by Vám šlo. Vlastně, když sleduji Vaše klouzání po slovech a ne po podstatě, vůbec se nedivím, že máte i na programování názory jaké máte.

Svět není černobílý - snažíte se vytvořit dojem, který není. Myslím, že jste naprosto jediný, kdo pochopil, že programátor s dobrou matematikou nesmí použít a nalepit komponenty. A tak dále. Zároveň nenápadně demagogicky podsouváte, že programátor s matematickými základy nedokáže použít komponenty - také dokáže. To, že je někdo teoreticky vybavený odborník neznamená, že si vše musí od mrtě programovat sám. Vůbec se přiznám, že Váš první odstavec mě přijde víc jako snůška emocí, než něčeho, co by reálně existovalo.

Rozdíl mezi programátory je v tom, jestli jsou to "programátoři" a programátoři. Tady se budu hádat, že ten rozdíl je přímo vidět. Jednoduché věci zvládnou obě sorty programátorů, složitější už jen ten programátor bez uvozovek. A v tom je jediný rozdíl.

Pekne vysvetleno. Souhlas.

Upresnuji: Souhlas s p. Miloslavem Ponkrácem. :-)

Návrh uživatelského rozhraní, nebo lepení již hotových předpřipravených komponent bez ničeho dalšího - to je "programování".

Bohužel musím říct, že i toto je v některých regionech problém. Na Rychnovsku (kraj HK) nejsme schopni již dva roky sehnat nikoho, kdo by byl schopný za rozumný čas alespoň slepit pár těch komponent k sobě a udělat z toho funkční okno.

Pravda, zaměstnávali jsme jednoho člověka, ale ten nám utekl, protože druhý semestr mu nevyšel rozvrh... :-( A dávat někomu, kdo pracuje dva dny z pěti rozpracovat komponentu, je nereálné, už prostě proto, že napsat si jí sám za týden je lepší, než čekat na ni měsíc...
Bohužel ani takoví "programátoři" tu nejsou natož potom programátoři...

Bohudíky, zrovna včera se u nás zastavil člověk s dlouholetou praxí, tak snad se alespoň tak trochu někam pohneme...

proc jsou java programatori podle diagramu temer uplne dole a maji podstatne vetsi plat nez lidi delajici v lamp?

Třeba proto, že se nad nikoho nepovyšujou (vyjma programátorů v pascalu a html). Ta šipka v tom grafu neznamená "je lepší", ale znamená "považuje se za lepšího".

Ale zas můžou mít ti weboví programátoři jiné kvality --- vysoké komunikační a prezentační dovednosti, které se jim můžou hodit nejen ve firmě, ale i v osobním životě --- viz třeba zde:

http://www.jikos.cz/~mikulas/komix/FREESOFT.GIF

LOL

Orientace na zákazníka je přístup, kdy se problémy a nedostatky, které zákazník neuvidí ihned při předávání produktu, neřeší. Až zákazník problém za pár měsíců zjistí, tak ho přesvědčíme, že to vlastně není naše chyba, ale nový zákazníkův požadavek, a necháme si od něj za opravu zaplatit. "Orientace na produkt" je starý přístup k programování, kdy se snažíme vytvořit funkční produkt, "orientace na zákazníka" je nový přístup, kdy se snažíme vytvořit produkt, o kterém si zákazník v momentě, kdy platí, myslí, že je funkční.

Čili to není žádná ctnost, je to newspeak pro trik, jak ze zákazníků vytáhnout víc peněz na úkor kvality programu a prodloužení vývoje.

Tomuhle přístupu se říká amatérismus a lajdáctví, orientace na zákazníka je trochu něco jiného.

Mně jeden člověk (co programuje u firmy dělající databázové aplikace na míru), popisoval orientaci na zákazníka přesně takhle. Jasně, že ne všechny bugy jdou svést na orientaci na zákazníka (např. kdyby to smazalo data, tak asi zákazníkovi dojde, že je to chyba dodavatele), ale pokud např. dodavatel ví, že za půl roku bude potřeba nějaká featura, která nebyla ve specifikaci, tak ji do návrhu nedá, a nechá si za ni zvlášť zaplatit. Předělávání té aplikace, aby se tam ta featura dostala, je časově delší i dražší, než tam tu featuru udělat při prvním návrhu --- ale o to právě jde, aby to bylo dražší.

Možná to u jiných firem znamená něco jiného. Co konkrétně ty máš na mysli?

Víš, BLACK.u, zákazníci nejsou až takoví pitomci, jak se zdá. Ono jim to dříve či později dojde, že je někdo ojebává. U normálního zákazníka brzo, u zmrdifirem později, ale i tam na to přijdou.

S jednou takovou firmou "orientovanou na zákazníka" mám zkušenosti. V roce 2000 rozjeli "big business" a dlouho takhle srali lidem na hlavu. Dnes mají tak mizernou pověst, že mají velké problémy sehnat zakázky. Navíc se s nima pár lidí soudí za zprasené dodávky.

Taková perlička z jejich práce - dělali jeden inzertně fakturační systém pro nejmenované vydavatelství. Po jednom update inzertní části na započítávání bonusů to změnilo vystavené! faktury za tři roky zpátky. A ještě měli tu drzost tvrdit, že to není bug, ale feature.



Orientaci na zákazníka si představuju tak, že daná firma nejdřív skutečně pečlivě zjišťuje potřeby zákazníka, projdou si sami celý proces, kde má být nový sw použit a myslí dopředu - tedy i buď tu tvou fíčuru předem udělají (i kdyby si ji nechali zaplatit zvlášť), nebo na ni alespoň upozorní. Naštěstí jsem se setkal častěji s těmito firmami. Nejsou bezchybnaté, ale aspoň své chyby neházejí na zákazníka a problémy se snaží řešit.

Mr. anonyme - potiz je, ze zakaznici zpravidla JSOU dostatecni pitomci, a plati ze cim vetsi firma-zakaznik, tim vetsi pitomec je jako celek.

Chyby v dodavce jsou schopni rozpoznat delnici u pasu, ale nez report projde tichou postou manageru, projektovych manageru, obchodniku atd, tak se urcite hrany obrousi ("oni rikaji A, ale mne se to nezda, prece to vypada tak dobre, podam to radeji kulantne") a nektere zcela ztrati.

Sikovny marketak (ktery MA zamer zakaznika zblbnout) pak zakaznikova obchodnika opije rohlikem - nez obchodnik preda info "niz" a verifikuje to co mu marketak nakecal uplyne dost dlouha doba (plus ticha posta smerem dolu a nahoru).

Pokud mas nejake osobni standardy kvality, tak musis byt navic EXTRA dobry, abys takove vykuky (kteri samozrejme dodavaji "kvalitni vyrobek" za konkurenceschopne ceny dane odflaknutosti vyvoje) pretlacil.

Navic se "pretlacovani" zpravidla deje ve fazi vyberu dodavatele, kdy je vsechno vaporware v zadavacich dokumentech a nastrelu analyzy a skutecna prace neni videt - pak uz je zakaznik "locked in" a bariera na vyhozeni dodavatele oknem se vyrazne zvysuje.

Ver tomu, ze to v realu BOHUZEL funguje. Osobne takovou "orientaci na zakaznika" neschvaluji, ale tak se dnes dela business.

+1 Toto je presne ze zivota, kdyz upozornuju ze dodavatel dodava smejd, tak managori maji kecy ze prehanim ..... a kdyz si to konecne koupej a ja jim reknu "nefunguje, smula, zaplatte si upravu" tak maj pro zmenu milion kecu, proc sem jim to nerek ....

Jsa poucen, davam takovy informace zasadne pisemne, aby bylo nasledne dotycnemu namagorovi co omlatit o hlavu pred jeho sefem.

Viz. pan anonym - buď to člověk, který ti to popisoval, myslel ironicky nebo ve skutečnosti popisoval "orientaci na zákazníkův bankovní účet".

Psaní webových stránek je až ne malé procento případů programování dost vzdálené, nicméně i tam je algoritmizace důležitá. Algoritmus to není jen quicksort nebo já nevím jak si to představujete. Ať napíšete cokoliv (pokud to není statická webová stránka) tak tam nějaký algoritmus bude, a když bude zprasený, tak z toho bude víc problémů než užitku.

IMHO jsou uzitecnejsi teoreticke predmety pro programatora nez matalyza - napriklad Slozitost, Algebra ... Matalyza jde mozna uz trochu moc do teorie. Osobne jsme pres matalyzu prolezl, ale na muj vkus na ni skoncilo pomerne dost lidi (holt Holicky se vyradil :)

Je tady jeste nekdo, kdo pmatuje zkousky u demona (Demutha)?

+1

ja mam matik 5, ale abych rekl pravdu, vubec nechapu k cemu mi to pri programovani je:(

Bud ti ta matika nic nedala, nebo jsi odolaval ty, se nad tim jen nezamyslel, nebo to nevidis v programovani. Cokoli z toho je spatne a bude lepsi, kdyz se na chvili zastavis a ujasnis si to :-). Uz tu nekdo mluvil o abstraktnim mysleni apod...

Ne všechna VŠ matematika rozvíjí abstraktní myšlení. Nebo aspoň te tu část, která je potřebná pro algoritmizaci a lepení komponent.

to je snad trosku ftip ze abstraktni mysleni maj jen matematici:DDD
trebas filozofove jsou preci taky experti prez abstrakci a zajimalo by me jak by se lidi divali na to, ze budouci programatori na skole absolvuji filozfii 1-5 plus par doplnkovych predmetu odvozenych od filozofie;)

vůbec by jim nějaké dva semestry klasické filosofie a rétoriky neškodily...

Vaše dedukce je z matematického hlediska chybná. Nikdo tu netvrdil to, co tu říkáte (jde o typickou chybu nematematika - domýšlení si i obrácené implikace k dané implikaci; je zajímavé, že podobný druh chyb v programech páchají právě ti matematikou nezasažení "lepiči", což má za následek, že program někdy funguje a někdy ne, podle toho, když ta neplatící obrácená implikace zrovna náhodou vyjde; oni sami takovou chybu prakticky nejsou schopni objevit, zatímco člověka s "matematickou deformací" praští do očí téměř okamžitě).

A pokud jde o ty filosofy, tak jsem toho názoru, že většině z nich by matematika jen prospěla. Protože většina z nich v současnosti ve skutečnosti žádné abstraktní myšlení nepředvádí (leda tak "abstraktní plácání o ničem"). Ostatně spousta významných filosofů, troufám si říci, že těch nejvýznamnějších, byla v první řadě matematiky a teprve pak filosofy!

Matematika je dle mého názoru nejlepší známý stimulátor a tester abstraktního myšlení, kterým musí projít každý, kdo se chce živit čímkoliv, co abstraktní myšlení ve větší míře vyžaduje. Což o programování, ať už jakémkoliv, platí vždy.

Tak s tímto souhlasím. Většina dnešních filozofů na školách ve skutečnosti tvrdě potlačuje jakékoli myšlení. Fungují stylem "10 let jsem studoval Aristotela". Pozor! Nemám nic proti filozofii samotné!

U matematiky je hlavně ta věc, že je exaktní, tudíž plané plácání je jasně vidět a původci to neprojde.

vy si souhlaste s cimkoli, matika je, podle toho co sem tu cetl, asi vas zivot, ale pro programatora ti hadi s koleckama v brisku opravdu potreba nejsou
pouzitelnejsi veci (kdybych treba delal na grafickejch hejblatcich) se ucili v jinejch predmetech;)

Tak já už vážně nevím... Rozumíte alespoň psaném textu, když už nerozumíte matematice?
Vy si stále dokola melete tu svou nesmlyslnou "svou"... Vždyť vy sám na sobě demostrujete, že lidé jako pan Ponkrác mají naprostou pravdu.

s cim mate problemek? nerozumite snad vyrazu hadi s koleckem v brisku?:) a matiku uz asi fakt neumim, par let po skole a vsechny ty vyraziva se z hlavy vymazali, protoze to tam kupodivu nejsou potreba (v hospode se uz o matice dlouho nebavime;) a psany text nevnimam protoze je osklivy a urazi me

ps: nemelu nic, nemam mlynek

Ponekud pozapominate, ze ty "jine predmety" matematiku take pouzivaji - vcetne tech hadu s koleckama :-)

vase odpoved je scestna, ja nic nerikal ja to psal:)

MA a nepotrebna? ano, pokud clovek bude chtit delat kancelarskej soft, kde rozhazuje buttonky a pise velmi jednoduchou funkcionalitu ... Nedokazu si predstavit, ze clovek bez znalosti MA by byl schopnej programovat treba 3D grafiku ... (samozrejme myslim tu aspon trosku low level v DX, openGL, atp., ne pres XAML :D) a najde se dalsich x dalsich vyuziti matematicky analyzi, kterou by rozhodne mel kazdy vysokoskolak v oboru umet, jsou to zaklady ... (ted mne jeste treba napada programovani fyziky bez toho umet pocitat diferencialni rovnice muze byt obcas taky problem ... - zase nepocitam pouziti hotovyho enginu, kterej samozrejme stejne nekdo musel napsat a ten to musel umet ... :])

Ano, většina lidí si tu mylně plete programování s návrhem uživatelského rozhraní plus pošolíchání pár řádků kódu. Webové aplikace (až na výjimky) a návrh formulářů programováním sice formálně je, ale de facto tohle opravdu zvládne zaučený člověk. Na to ani není potřeba vysoká škola, natož analýza.

Jakmile se ale chcete dostat k jen trochu zajímavé programátorské práci, tak bez matematiky se opravdu nedá obejít. A dost často i velmi ostré matematiky.

Já jsem třeba hrál Carmageddon a matematiky a fyziky tam bylo fakt dost :) Na svou dobu měl nejlepší fyzikální model ze všech 3D her. A ještě je to hra vhodná pro psychopaty.

carmageddon 1,2,3(2000), to je presne me mladi :)

Jsou obrovské oblasti programování, kde skutečně matematické věci nepotřebujete. Vezměte si třeba jádro, glibc. S výjimkou správy paměti a pár podobných míst vůbec nepotřebujete matematické vzdělání.

Zato velmi potřebujete za každým řádkem kódu představu o tom, jak v tom okamžiku bude vypadat obraz paměti, co je na zásobníku, kam vedou ukazatele, které zámky nyní program drží a které mohou držet jiné části kódu, co provede přerušení v kterémkoliv místě kódu, jaký signál je na kterém drátu a jak se mění v čase, kolik nanosekund budu mít ještě sběrnici pro sebe, či rozhodnout, zda je v daném místě lepší přidat pár bajtů kódu nebo pár bajtů dat.

To jsou znalosti, které vyžadují opět úplně jiný typ myšlení, než dává matematická analýza. To, že z ní někdo na VŠ vyletěl, vůbec neznamená, že z něj nemůže být excelentní programátor kernelu.

Je mnoho dalších oborů, kde práce nespočívá v počítání složitosti sofistikovaných algoritmů, analýze dat ani fyzikálním modelování, ale v nesmírně pozorném skládání v podstatě triviálních kusů kódu.

Studium matfyzu mi k tomu dalo důležitý poznatek: Jsou kusy kódu, pro které půjdu za odborníkem, pro kterého je daná oblast matematiky nebo fyziky denním chlebem. Pokud jsem to před 20 lety slyšel na přednášce, a od té doby nikdy nepoužil, je to zdaleka nejefektivnější postup.

Víte jak se pozná člověk bez matematiky? Že v glibc není schopen naprogramovat výpis 100% fungující výpis reálného čísla. Stejně tak funkce jako errfc, nebo besselovy funkce určitě v glibc naprogramoval člověk bez znalosti matematiky :-)

Moje poznání je, že dobrá znalost matematiky je obrovská výhoda pro programování, a to i tam, kde byste to nečekal. Samozřejmě, že může být excelentní programátor kernelu. Samozřejmě, že bez matematicky se objedete na mnoha místech - není to nutná podmínka. Nicméně už jsem se často v praxi setkal s tím, že s použitím matematiky je program hotov třeba za hodinu, zatímco bez ní je to měsíční práce (zdůrazňuji mluvím o běžných široce prodávaných komerčních programech, nic akademického).

S posledním odstavce souhlasím na 20%. Pokud se jedná o kusy kódu zakládající se na čisté syntetické matematice, pak není co řešit. Ale naprostá většina kódu, kde je potřeba nějaká matematika chce většinou i programátorskou dovednost, případně znalost jiného oboru - a pak je kolikrát efektivnější si to zhusta opravdu napsat sám, než akademickému matematikovi vysvětlit všechny potřebné detaily kolem oboru a kolem sw věcí.

Ono je tak, že programování je široký pojem - a nelze ho řešit najednou. Návrh uživatelského kabátu, většina webových aplikací, či jednoduché slepení pár komponent není nic, co by nezvládl člověk po zaučení.

Kolega měl ještě jiný příklad:

Když skupině středoškoláků zadáte algoritmicky neřešitelný problém, všichni do jednoho přinesou za týden řešení. Ani ve snu je nenapadne, že něco není v pořádku.

Na přednášce (před 20 lety) se o přibližných algoritmech zmínili. A také se zmínili o matematicích, co pak na takové algoritmy dělají testy, aby dokázali odhadnout, jak často to selže, jak jednoduché je vytvořit malá vstupní data s extrémně dlouhým řešením…

Pokud bych jako programátor řešil nějakým přibližným algoritmem algoritmicky neřešitelný problém, měl bych přinejmenším tušit, že mohou nastat problémy, a být na ně připraven. Jinak se mohu ošklivě divit, když mi někdo pošle nenápadná vstupní data, která se budou zpravovávat v čase 2^(2^n), nebo budou chtít alokovat 2^(n!) paměti.

I spojené počítače jsou zase jen Turingův stroj. Ono „napasování“ není nic víc než matematická obezlička: Pokud dokážeme, že problém nelze vyřešit (v matematickém smyslu tohoto slova, tedy nad jakýmikoliv vstupními daty) na Turingově stroji, pak jej nelze vyřešit na žádném algoritmickém stroji.

Směrování IP datagramů JE ALGORITMICKY ŘEŠITELNÝ problém v pohodě. Pouze nalezení NEOJPTIMÁLNĚJŠÍ cesty pro směrování datagramů je nechutně složitý algoritmický problém - nicméně v praxi to není potřeba, a proto se to tak neřeší.

Někdy jediné slovíčko může podstatně změnit celý smysl - a špatné pochopení slovíčka vyplodí pak nesmyslu ve stylu příspěvku na který reaguji.

Slovo NEJOPTIMÁLNĚJŠÍ je nesmysl, to jen tak na okraj...

Slovo nejoptimálnější není nesmysl. Pokud máte matematickou funkce jakožto měřítko optimality, tak slovo nejoptimálnější má význam maxima/suprema této funkce. Zde je slovo nejoptimálnější velmi smysluplné.

Pokud je reseni optimalni => nejlepsi po vsech strankach, nemuze uz byt zadne optimalnejsi reseni. To ze je to mozne rici mluvnicky jeste neznamena, ze to ma smysl i logicky.

+1
Jistý pan Bokr by ho naučil. Jen nechápu, že člověk obhajující tolik matematiku nepochopí význam slova optimální. Optimální už totiž v sobě to maximum obsahuje ;) Do myšlenky zda by místo slova maximum mohlo být i supremum se raději pouštět nebudu.

Slovo "nejoptimálnější" smysl rozhodně má - identifikuje nejlepší ze všech neoptimálních řešení. Pokud vám vadí, že je z gramatického hlediska ve třetím stupni z pohledu češtiny (a "super třetím" z pohledu latiny), tak byste se měl také pozastavovat nad tím, že "vyšší budova" je ve skutečnosti menší, než "vysoká budova" apod... A pokud vám vadí to skloňování, tak mám takový pocit, že přídavná jména jako "dokonalý", "nulový" aj. ze sémantického hlediska jsou také sama o sobě ve třetím stupni, ačkoli gramaticky jdou ještě dále stupňovat.

Slovo "nejoptimálnější" smysl rozhodně má - identifikuje nejlepší ze všech neoptimálních řešení.

Slovo optimální znamená: nejlepší, nejlépe vyhovující. Žádné nejlepší z neoptimálních řešení. Smysl proto nemá. To že se dnes poměrně běžne používá nic neomlouvá. Neoptimální řešení také logicky nemůže být nikdy nejoptimálnější.

tak byste se měl také pozastavovat nad tím, že "vyšší budova" je ve skutečnosti menší, než "vysoká budova" apod...

A když vedle sebe bude stát vysoká budova a vyšší budova? :)

A pokud vám vadí to skloňování, tak mám takový pocit, že přídavná jména jako "dokonalý"

Dokonalejší je podle mého názoru stejný nesmysl jako optimálnější. Nulovější jsem ještě nikdy neslyšel.

Je docela možné, že jedna z příčin vzniku takových slov je neuvádění celé skutečnosti. Často se stává, že se nalezne nějaké optimální řešení. Ale je nutné dodat, že to řešení je optimální v daných podmínkách - tedy například poměr cena/výkon, s danými materiály, vlivem na životní prostředí a podobně. Následně se podmínky změní a mění se i řešení. To se potom označí jako optimálnější. Ve skutečnosti se však změnily podmínky a tedy i kritéria určující optimálnost a nové řešení může být znovu nanejvýše optimální.

Podobný nesmysl je i uvádět spojení typu: maximálně optimální

Ach jo. nechtel jsem se do te diskuse vkladat, ale pletete se vy. Proste v mnoha ulohach v matematice existuji parametry, a ty se povazuji za konstantni pri reseni ulohy, ale presto je reseni obecne natolik, aby se daly snadno zmenit. V takovem pripade "nejoptimalnejsi" smysl ma, protoze pak jde o optimalni reseni v zavislosti na optimalne zvolenych parametrech.

"Dokonalejsi" ma smysl take, protoze ma smysl "zdokonalit" neco (tedy zlepsit neco, o cem jsme si mysleli, ze uz je to dokonale), a tim se to stane dokonalejsim. Zase tu mate, podobne jako vyse, parametr - cas, a ta vec byla dokonala v kazdem okamziku, ale ze zpetneho pohledu historicky dokonala nebyla.

Pokud se změní parametry, jedná se o jinou situaci a proto je nutné vypočítat nové optimum. Nové optimum bude (nejspíš) jiné než to předchozí. Ale v podstatě ho nelze s tím původním srovnávat - situace je jiná, změnily se podmínky. Ano, pokud se jedná neustále o stejné rovnice, pak lze říct, že třeba spotřeba paliva na ujetý kilometr je nižší než byla dříve. Ale nedá se vůbec použít věta, že motor je optimálnější.

A pokud jsem dobře pochopil váš příklad, myslel jste vlastně dvoufázový výpočet: 1) stanovení vhodných parametrů 2) výpočet řešení. Potom pro vás nejoptimálnější je takový výsledek, kdy byly zvoleny nejlepší parametry. Ale takový výsledek je "pouze" optimální. Vůbec nezáleží na tom, jak se k němu dostaneme.

Slovo dokonalejší je pro mě tenký led. Pokud rozumím dobře slovu dokonalý, pak i dokonalejší a zdokonalit je nesmysl, který se však používá o něco déle než optimálnější

"A stejně se blbci matematici pokoušejí všechny počítače napasovat na Turingův stroj, nevěda (asi už 30 let), že stroje se mohou propojovat a spolupracovat."

Zajímavé, ničeho podobného jsem si nevšiml. Ty ostatní abstraktní výpočetní stroje byly zrušeny? Kdy?

Chyba ale není v absolventech analýzy, ale v učitelích (hlavně z MFF), kteří se odmítají naučit něco jiného než kalkulus matematické ananlýzy.

Týýýjo, to znamená, že mám imaginární kamarády...protože na MFF se přeci učí jen matematická analýza, tak nemůžou být reální, když byučují třeba teorii grafů nebo další diskrétní matematiku... Člověče, byl jste někdy vůbec na MFF? Myslíte, že třeba morfeo.centrum.cz se naprogramovalo integrálama? A ta zmínka o Wordu je obzvláště trapná. :-)

Jeden kolega se chtěl přednášejícího Počítačových sítí (bohužel dost encyklopedická přednáška zaměřená hlavně na historii) zeptat, jestli se tam také dozví, jak sesíťovat Turingovy stroje, aby mu to jako teoretickému informatikovi k něčemu bylo :D

K modelovani pocitacovych siti slouzi tusim Petriho site. A vim, ze skripta pro FEL Pocitacove site o nich mluvi.

I znalost svych mezer ve vzdelani muze byt zasadni - ty vis, kdy mas jit za odbornikem, kdezto fura lidi zacne neco bastlit na kolene. Kazda znalost nebo alespon povedomi o znalosti se muze hodit. Jinak programovani je spis sofistikovanejsi remeslo - neco jako hodinar, jde taky hodne o zkusenostech, osobnich kvalitach, moznosti se uplatnit - je toho vic.

Sorry že se vám pletu do diskuse, ale opravdu si _všichni_ myslíte že matematika = matematická analýza???

Třeba taková diskrétní matematika a teorie grafů mi přijde jako mnohem užitečnější (koneckonců je to programování nejblíže). Nebo pravděpodobnost a statistika. To jsou oblasti, které programátor znát musí - nezávisle na tom co programuje.

a nepletete se vy? "Programování je činnost, která zahrnuje tvorbu algoritmu a programu. Algoritmem rozumíme obecný postup řešení dané úlohy. Program je zápis algoritmu ve zvoleném programovacím jazyce."

takze programovani neni jen vedecka cinost;)

Začal jsem, před léty při práci, dělat aplikovanou informatiku na VŠB skončil jsem po prvním semestru na matice a materiálech. Matika byla velmi zajímavá a to jsme jen začali, člověk se až diví, co všechno se dá spočítat. Ty materialy sice neměli s IT nic společného, ale taky to byla vcelku zajímavá chemie.
Škoda, že jsem na to neměl tenkrát více času a nebo, že jsem se lépe neučil ve škole. :-)

Ale je pravda, že všichni programátoři tohle nemusí znát a můžou si koupit hotové knihovny.

Matematická analýza na 3D grafiku? To je spíš záležitost lineární algebry, ne? U fyzikálních simulací je využití derivací a integrálů jasné, ale u té 3D grafiky mě nenapadá žádné využití...

Kupříkladu firma PIXAR vybízí autory procedurálních shaderů a TDs, aby psali analyticky antialiasované shadery. Tím se v PRManu omezuje potřeba stochastického vzorkování na minimum. Viz třeba Ian Stephenson, Essential Renderman Fast, pasáž "Analytical Anti-Aliasing". Za tímto účelem algoritmus kromě UV souřadnic získává také jejich derivace podle prostoru obrazu, jestli se nepletu. Stejně tak by se určitě našlo uplatnění i u vizualizací trojrozměrných datasetů a podobně.

Pokud máte pocit, že vám vysoká škola nic nedá a je pouze zdržováním vašeho nástupu na trh práce, pak na ní nechoďte. Vysoká škola vás má naučit logicky uvažovat. Na to, aby vás učila sezóní záležitosti typu Ajax nebo RoR, opravdu zaměřena není. Máte si z ní odnést univerzální znalosti.

Matematika je krásná, a je to zřejmě nejkrásnější věc, co kdy dali lidé dohromady.

Na druhé straně buďme upřímní: opravdu absolvent IT oboru VŠ potřebuje ke své práci matematiku? No, nepotřebuje. Samozřejmě tu 100x čtu, že matematika pomáhá rozvíjet logické myšlení. To jistě ano. Ale podobně memorování latinských textů pomáhá zlepšovat paměť. Přitom latinu ani matematickou analýzu, člověk pracující v oboru IT nakonec potřeboval nebude.

Další námitka je "programátoři vs taky-programátoři". Zastávám názor, že nemá smysl dělat tu samou práci dokola. Chcete snad u každé aplikace znovu a znovu implementovat třídění a vyhledávání? Vždyť je to zbytečná otrava, a hlavně to výrazně prodlužuje (a tedy prodražuje) projekt. Nemáme ani dostatek lidí, kteří by takovým způsobem kód byli schopni psát. Je daleko jednodušší a praktičtější psát na nejvyšší úrovni, která je pro danou úlohu k dispozici.

A nakonec námět k zamyšlení. Víte, co je pro studenty MFF UK největší strašák? Je to softwarový projekt. I Johanka nám tu poutavě popisovala, jak jsou matfyzáci na projektu tragičtí. Jak je možné, že jim léta buší do hlavy matematiku, která má s jejich budoucím povoláním řekněme velmi volný vztah, a nepřipraví je kvalitně na SW projekt, který je naopak těžištěm jejich oboru? Nezvrtlo se nám tu něco?
http://www.root.cz/clanky/zemljanka-commander/

"Ale podobně memorování latinských textů pomáhá zlepšovat paměť. Přitom latinu ani matematickou analýzu, člověk pracující v oboru IT nakonec potřeboval nebude."

A tady bych se ohradil. Latinská morfologie procvičí analytické myšlení (mně kdysi na konci základky naučila základním "technikám polního lingvisty") a vzhledem k vazbám a vlivům latiny na současné evropské jazyky se ani ta slovní zásoba nedá brát jako vyložené memorování, spíš jde o zasazování již tušených střípků na správná místa, No a pokud jde o "memorování textů", tak pak už je jedno, jestli je to latina nebo Máchův Máj.

A navrhujete tedy, aby studenti informatiky v rámci procvičovní paměti memorovali latinské texty, nebo raději Máchu? Ještě připadá v úvahu seznam velikánů historie IT (jméno, příjmení, narození, úmrtí), s odříkáním v lexikografickém pořadí (a reverzně), dle zvoleného kritéria (třeba podle křestního jména sestupně).