Most olvastam Wigner Jenő Hogyan lettem fizikus? című esszéjét. Volt benne egy bekezdés ami nagyon megtetszett (kiemelések nem az eredetiben):
Mi - valami hatan voltunk - a Hanfordi reaktort terveztük, amit a mi terveink alapján a duPont társaság épített. Így annak a vállalatnak az embereivel - többnyire szintén vegyészmérnökökkel - szoros összeköttetésbe léptünk. Ez számomra különösen érdekes volt, mert így megtudtam, hogy az itteni vegyészmérnökképzés egészen más, mint az Németországban volt, ahol én tanultam. A duPont mérnökök tudták hogy lehet ezt meg azt beszerezni, melyik vállalat gyártja a különböző árukat, de absztrakt kémiát sokkal kevesebbet ismerték mint én. És ez jóvá tette az én kémiai mérnöki tanulásomat - több súlyos hibát követtek volna el, ha én nem óvtam volna őket. Többek között nátrium-bikarbonátot akartak a hűtővízhez adni, hogy ne marja meg az alumíniumcsöveket, amikor a hűtővíz folyik. De a sugárzás által létrehozott hidrogénperoxid redukálná a bikarbonátot és az csapadékot hozna létre, ami az uránoszlopokra rakódna és nagyon csökkentené a meleg folyását belőlük, pedig ez az, ami a víznek a feladata. Így lebeszéltem őket, mert mint vegyészmérnök ezt a bajt előreláthattam, ha beteszik a bikarbonátot és ez jó volt. Így és más hasonló módokon a vegyészmérnöki tudásom hasznos volt - jó volt végeredményképpen ezen, és más alkalmakkal, hogy tudtam kémiát - az apám tanácsa, hogy vegyészmérnökséget tanuljak végeredményképpen hasznos volt - ezen és több más alkalommal is. Ezekből is hálás lehetek iránta, és voltam is és őrzöm emlékét.
Erről eszembe jutott egy másik esszé is, amit még Joel Spolsky írt:
http://www.joelonsoftware.com/articles/ThePerilsofJavaSchools.html
Mivel sokszor előkerülő téma, hogy mennyire rossz a magyar egyetemek elméletorientáltsága (a "gyakorlattal" szemben), ezért kíváncsi lennék, hogy kinek van esetleg Wignerhez hasonló sztorija. Olyan esetről amikor az absztrakt, elméleti képzettség segített egy _nagyon_ gyakorlati probléma megoldásában. [Értelemszerűen programozásban, informatikában felmerült problémára gondolok. :) ]
- 7555 megtekintés
Hozzászólások
visszakanyarodnék az IT-hoz, ha interjún megkérdeznek egy olyan dolgot, ami kódolási gyakorlatban összeszedhető és nem tudok válaszolni, akkor az se ment meg, hogy fejben tudom az Oxford Nagyszótárt NF7-be átalakítani.
Igazából nagy baj nincs az elméletorientáltsággal, de akkor legyen az elmélet tényleg kigyúrva. Amikor idejön egy frissen végzett PTI-s és elkezdi osztani az észt, hogy java-ban(bocs, nem C#-ot vagy php-t mondott) ezt pikpakk megírja az ebédszünetben, mit szopunk vele 3 napja, s _nem tudod neki elmagyarázni_, hogy XP-hez írunk éppen pcie filter drivert (ezt ugye igen nehéz managed/VM-ben futó nyelvben). Ő azt tanulta, hogy van a C, ami nehéz (ezért aki ezt tolja, az hülye), ezért nem is tanulják, van a java meg a c#, amit lehet uml-ből generálni, ami meg elmélet, innentől az elméletorientáltsággal valami baj van.
Eszembe jutott még egy, amikor az igen képzett amerikai villamosmérnök LabVIEW-ban akart olyan programot írni, ami effektíve egy boot menü, webservice-ből lekér egy listát, ebből választasz, ezzel image-eli az egyik partíciót, belépteti domainbe, majd ezt bebootolja. (Aki ismeri az XP-t, tudja, hogy ott még nem lehet reboot nélkül domainbe belépni).
Illetve még egy, amikor hasonlóan kvalifikált egyén akart olyat, hogy generikus interfész egyik típusparamétere generikus interfész, s az interfész egyik metódusának visszatérési értéke a másikból jön. Egy adatgyűjtő drivert akart generalizálni, hogy a típusparamétertől függően a getValue() visszatérési értéke adott típusú legyen.
--
"SzAM-7 -es, tudjátok amivel a Mirage-okat szokták lelőni" - Robi.
- A hozzászóláshoz be kell jelentkezni
Igaza van. :) Oxálsav (is) keletkezik, ami uranil oxalátot képez. Az pedig vizben oldhatatlan csapadék. Biztos, hogy lerontja a hőátadást.
------
3 fajta matematikus létezik. Aki tud számolni, és aki nem.
- A hozzászóláshoz be kell jelentkezni
van a hűtővízben urán? szerintem nincsen. Gondolom Na-karbonát - Na-hidrokarbonát átalakulástól félt, a hidrokarbonát meg elég rosszul oldódik, kicsapódik.
- A hozzászóláshoz be kell jelentkezni
érintkezik a hűtővíz az uránnal?
--
"SzAM-7 -es, tudjátok amivel a Mirage-okat szokták lelőni" - Robi.
- A hozzászóláshoz be kell jelentkezni
A primer kör igen. az előző hozzászóláshoz pedig annyi, hogy a karbonát-hidrokarbonát átalakulás sima termikos "bomlás", és nem redukció.
http://hu.wikipedia.org/wiki/Nyomottvizes_reaktor
------
3 fajta matematikus létezik. Aki tud számolni, és aki nem.
- A hozzászóláshoz be kell jelentkezni
Az energiatermelő reaktorok többségében (a nyomottvizeseknél biztosan) uránium-oxidot alkalmaznak üzemanyagként, nem fémuránt, és az urán-oxid pelletek ráadásul nem magukban vannak, hanem cirkónium csövekben. Tehát a víz nem érintkezik az üzemanyaggal. Ha igen, az nagy baj (hogy akkor milyen reakció zajlik le, ha a nagynyomású víz érintkezésbe lép a 2000 fokos urán-oxiddal, arról fogalmam sincs).
- A hozzászóláshoz be kell jelentkezni
értem, köszi!
--
"SzAM-7 -es, tudjátok amivel a Mirage-okat szokták lelőni" - Robi.
- A hozzászóláshoz be kell jelentkezni
Tényleg. Igazad van tokozzák az urániumot (ill az oxidját). De rég volt már reaktorfizika! Ha jól nézem az urán-oxid nem reagál a vízzel, de savban és lúgban a reaktánstól függően oldódik. Főként uranil vegyületeket képez.
------
3 fajta matematikus létezik. Aki tud számolni, és aki nem.
- A hozzászóláshoz be kell jelentkezni
az U2O is reagál a vízzel, ha valamelyikük több, mint 2000 fokos :)
- A hozzászóláshoz be kell jelentkezni
Az alkálifém karbonátok a Li2CO3-tól eltekintve vízben tökéletesen oldódnak. A nyomottvizes reaktorok hűtőkore desztvizből készül abban nincs Ca, és Mg ion, ahol ez dominál amit írsz. Az Uránium milyen Karbonátot képez azt nem tudom, szerintem elég nehezen, de tévedhetek.
------
3 fajta matematikus létezik. Aki tud számolni, és aki nem.
- A hozzászóláshoz be kell jelentkezni
hidrokarbonátról van szó, ami sima karbonátból alakul át:
Na2CO3 --> NaHCO3
A Na-karbonát (mosószóda) nagyon jól oldódik mind hideg, mind meleg vízben, a Na-hidrokarbonát (szódabikarbóna) hidegebb vízben elég rosszul oldódik, kicsapódhat.
- A hozzászóláshoz be kell jelentkezni
De eleve bikarboátot akartak belerakni.
------
3 fajta matematikus létezik. Aki tud számolni, és aki nem.
- A hozzászóláshoz be kell jelentkezni
off:
Elméletileg nincs különbség az elmélet és a gyakorlat között. Gyakorlatilag van.
(sorry :) )
- A hozzászóláshoz be kell jelentkezni
Informatikai területen, hirtelen nehéz is definiálni magát a kérdést, hiszen pl. a szoftverek tulajdonképpen tekinthetők absztrakt matematikai entitásoknak is, elméleti konstrukcióknak.
Míg a többi szakmában pl. a matematika mint a "valóság" modellezésének eszköze jelenik meg, ezért talán jobban elkülöníthetők - a még mindig szoros összefonodás ellenére természetesen - azok akik "ügyesen formálják a valóságot(gyakorlat)" és azok akik "ügyesen modellezik a valóságot(elmélet)", a programozásban viszont nem egészen a valóságot modellezed, hanem inkább maga a viszonylag szabadon felépített modell VÁLIK valósággá. ;)
A "viszonylag szabadon"-t úgy értem az előző mondatban, hogy vannak korlátok de a korlátok is gyakran matematikaiak(elméletiek), nem anyagiak (pl. lassú a gép).
Persze vannak akik az anyagi korlátokkal harcolnak (lassú gép, kevés ram, lassú net, hülye ügyfél;)), talán ez a része tekinthető szigorúan gyakorlati ágnak a szakmában.
Persze, mondhatjuk azt is - és ez egy más definíció - hogy elméleti konstrukciókon(szoftvereken) végzett FAVÁGÓJELLEGŰ vagy RUTIN munka tulajdonképpen gyakorlati tevékenység, mert szerintem a legtöbb informatikus végül is így érzi...
Nnna. Röviden, szóval a kérdés definíciós válságban szenved szerintem, igazából talán a többi területen is így van ez de mintha az informatikában hatványozottabban így lenne...
- A hozzászóláshoz be kell jelentkezni
"pl. a szoftverek tulajdonképpen tekinthetők absztrakt matematikai entitásoknak is, elméleti konstrukcióknak."
Ezt kifejtenéd?
Nem minden szoftver alapul matematikai konstrukciókon.
Pl. egy fordítóprogram, egy rajzolóprogram, egy számlázó, stb.stb.
Mire gondolsz?
- A hozzászóláshoz be kell jelentkezni
"Nem minden szoftver alapul matematikai konstrukciókon."
Ez a megfogalmazás kábé azon múlik hol végeztél. Progmaton azt mondják minden matematikai probléma. Sok az elméleti programozás.
Infon maga a programozás a cél. Dokumentáció írás, program fejlesztés, tesztelés. Ez inkább az alkalmazott informatika.
Most amiket felhoztál azok pont nem jók ezek szemléltetésére. Pölö a gcc fordító egy nagyon moduláris, iszonyat bonyolult rendszer. Elég annyi ehhez, hogy egy általad definiált nyelvről gépi kódra tud fordítani egy nem létező gépre. Ehhez csak a nyelv szemantikáját kell definiálnod és gép bytecode-ját. És akkor még nem beszéltünk preprocesszről, optimalizációról, etc. Hidd el egy fordító színtiszta matematika.
Rajzolóprogram: én elég sokat dolgoztam Autocad-dal, 100% tiszta matematika benne minden.
Számlázó programon, még nem dolgoztam. De ha belegondolsz, hogy kettős könyvelés és statisztikai számításokat kell végezni adatokkal azok megint csak 100% tiszta matematika.
Szóval ezek rossz példák arra amiben te vitatkozni akarsz. Nagyon egyszerű program kell ahhoz, hogy ne találj benne matematikát. Még egy egyszerű lámpa vezérlő szoftverbe, ami ki-be kapcsolgat egy lámpát is kell végezni logikai műveletet.
--
GPLv3-as hozzászólás.
- A hozzászóláshoz be kell jelentkezni
Egy számlázó program az kiváló példa a topic témájára: elmélet és gyakorlat. Például azért, mert feltételezed, hogy az ügyfélszolgálatos elolvassa, amit kiírsz a képernyőre, értelmezi, majd cselekszik. Ez az elmélet. A gyakorlat meg az, hogy klikkelnek, mint a vakló, utána meg kapard össze az adatbázist. És csak 8 év szigorított kategóriás fenyegetések meg a fél képernyőt kitöltő bazi nagy piros allert sheetek nyomására hajlandók eljutni odáig, hogy olvassanak, mint első általánosban.
Az előfizető a másik jó elmélet-gyakorlat példa. Elméletben minden előfizetőről rögzítetted az adatbázisban, hogy milyen metódussal fizet: kp az irodában, banki átutalás vagy csoportos beszedés. De sok ügyfélnek nincs már pénze a számláján, ezért a csoportos beszedés sikertelen lesz, ha meg felszólítod, esetleg bejön hónap végén kp fizetni. Na ezt vakard össze áfatörvény-helyesen. Olyanról már nem is beszélek, amikor egy testvérpár örökli a lakást és az előfizetést, délelőtt bejön a nővérke, beállíttatja, hogy tőle csoportos beszedéssel szedjük a díjat, délután meg bejön az öcsike és kifizeti kp. Elméletileg milyen rendes ügyfelek, gyakorlatilag meg rohadjon le a keze, aki ennyi plusz munkát csinál.
Elméletileg létezik magyar bankközi pénzforgalomra szabvány, nevezzük röviden gironak. Amely szabványban le van írva, hogy az előfizetőről szóló adatok kódolása cp852. Elméletileg tehát minden adat így jön, gyakorlatilag az első banktól rendszeresen latin2-ben jön sok minden. És nagyon sok string van, amiről lehetetlen automatikusan megállapítani, hogy milyen kódolású.
Ez csak pár ízelítő volt az elméletről meg a gyakorlatról...
- A hozzászóláshoz be kell jelentkezni
Szemléletes példák és valszeg sokunk megélt hasonlót.
Előre elnézést kérek a java-only fejlesztőktől, de az én példám innen ered.
Elméletileg, ha fizikai memória van bőven, nem is foglalkozunk azzal, hogy mit hogyan olvasunk be, meddig tárolunk - csak mielőbb legyen meg -, hanem kiköveteljük az admintól, hogy adjon a jvm-nek nagyobb szuflát, ahogy otthon a sufnipécén is szoktuk.
Aztán jönnek a végtelen GC-ciklusok, és kiderül, hogy jobb lett volna előre meggondolni a méreteket és élettartamokat.
- A hozzászóláshoz be kell jelentkezni
"Pistike odamegy az apjához, és megkérdezi:
- Apa, mi a különbség aközött, hogy 'elméletileg' és 'gyakorlatilag'?
Erre az apja odamegy az anyósához, és azt kérdezi:
- Mondja, Mama, mit csinálna, ha egy kétméteres néger adna magának 5000 dollárt, hogy lefeküdjön vele?
Mire az anyós:
- Fiam, az én koromban az ember ne legyen válogatós, és különben is kell a pénz.
Erre az apa odamegy a feleségéhez:
- Drágám, mit csinálnál, ha egy kétméteres néger felajánlana 5000 dollárt, hogy lefeküdj vele?
Mire a felesége:
- Tudod, hogy szeretlek, de hát a gyereknek kell a cipőre a pénz, és nyaralni is el kéne menni, szóval feláldoznám magam...
Erre az apa odamegy a nagylányhoz:
- Kislányom, mit csinálnál, ha egy kétméteres néger adna neked 5000 dollárt, hogy lefeküdj vele?
Mire a lány:
- Tudod Apa, én már nagykorú vagyok, és szívesen kipróbálnám, főleg, ha ennyi pénzt kapnék érte.
Erre az apa azt mondja Pistikének:
- Látod kisfiam, elméletileg most van 15000 dollárunk, gyakorlatilag viszont három rossz kurvával élünk együtt!"
- A hozzászóláshoz be kell jelentkezni
Kissé közönségesnek tűnő, de remek szemléltetés. Köszönjük. :)
- A hozzászóláshoz be kell jelentkezni
Meg ebben is van matek, ha mas nem, osszehasonlitas:
#include <stdio.h>
int main() {
printf("Hello, world!");
}
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.
- A hozzászóláshoz be kell jelentkezni
Sőt, ebben is ott a matematika:
#include
int main() {
return;
}
...mert ugye a címaritmetika, mint olyan...
:)
- A hozzászóláshoz be kell jelentkezni
Nem minden szoftver alapul matematikai konstrukciókon.
Pl. egy fordítóprogram, egy rajzolóprogram, egy számlázó, stb.stb.
A fordítóprogramok elméletét formális nyelveknek hívjuk, termátíró rendszerek, automaták, nyelvtanok, stb. Eléggé elméleti.
A rajzolóprogramoknál (gondolom Te sem az mspaint32.exe -re gondoltál) igen mély matematika van, gondold csak meg az AutoCAD-ben lévő tárgyrasztereket, raszterkövetés, poligonok, metszések, stb. A vektorgrafikáról ne is beszéljünk, az sem a gyakorlópályán jött létre.
A számlázóprogramok magjában is modellek állnak, bár nem annyira matematikailag, inkább szabályrendszerek által definiáltak.
Szerintem minden szoftverrendszerben van elmélet és gyakorlat. Az, hogy helyesen működjön, jó legyen a modell, a kitűzött feladatot oldjuk meg - (ezt esetleg be is bizonyítod) - az elmélet feladata. Az, hogy karbantartható legyen, hatékony, gyors, szép, és a titkárnő is elolvassa, azt amit az arcába nyomunk, az gyakorlat.
- A hozzászóláshoz be kell jelentkezni
Erősen off:
C:\Users\saxus>mspaint32
'mspaint32' is not recognized as an internal or external command,
operable program or batch file.:)
----------------
Lvl86 Troll
- A hozzászóláshoz be kell jelentkezni
start mspaint?
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.
- A hozzászóláshoz be kell jelentkezni
Na hát innen látszik, mennyit használom. :)
- A hozzászóláshoz be kell jelentkezni
Személyes érzéseim pl. konkrét példán:
Ha mondjuk azon gondolkozom, hogy egy adott célra milyen adatszerkezetet használjak, azt elméleti munkának értékelem, ha meg mondjuk azon, hogy egy adott programot más platformon is futtathatóvá akarok tenni az meg egy gyakorlati probléma, filozófiailag viszont nem biztos hogy ez a különbségtétel jól és egzaktan megfogalmazható...
Talán az a kulcs, hogy a probléma mennyire kötődik a meglévő "környezethez" vagy mennyire tekinthető absztraktnak és "környezetfüggetlennek"?
- A hozzászóláshoz be kell jelentkezni
Az informatika elég érdekes terület. Sok ismerősöm ment el diplomázás előtt dolgozni webet fejleszteni, rendszerüzemeltetni, stb. A kérdés inkább az, hogy az informatika mely területénél kezdődik az a szint, ahol már kell a diploma/elméleti szint.
Én villamosmérnök vagyok, nálunk kicsit más, mert a problémák megértésének nagy részéhez egyszerűen kell az elméleti képzettség. A megoldásban persze már a gyakorlati oldal az erősebb. Mint ahogy Wigner is írja. Ő egyedül az egész melót nem tudta volna megcsinálni, de a különböző szemléletű vegyészek kooperációjából végül minden megoldódott.
- A hozzászóláshoz be kell jelentkezni
Én inkább abba látom a problémát, hogy sok egyetemen egyáltalán vagy nagyon minimális gyakorlat van... Nem egy ember jött hozzánk dolgozni, aki végül haszna vehetetlen volt mert hiába voltak jók az ötletei, gyakorlatban igen lassú volt és sokszor a stílus is gyenge volt. (programozási)
Viszont amiről a kedves hallgatóknak / diplomásoknak kéne leszokni az az, hogy mikor kijön az adott intézmény diploma osztójáról akkor megbotlik a küszöbe és onnantól csak az agyát látom az orrán át... ha értitek mire gondolok... Uram bocsájtsd meg de aki ott ül nálunk hatalmas agy, ugyan nincs diplomája, az egész produkt aljától már velünk van és ismeri minden darabját... az igen csak jogosan akad ki mikor egy ilyen lelkes nap imádó jön és megmondja a "tutit..." :D
Másik kedvenc történetem végzős hallgató jön, hogy akkor már előre kell neki munka... mondja tud jönni 2 nap... mondjuk oké de akkor 12 óra... ja ő nem akar megszakadni... mondom akkor rossz szakmát választott, erre ő nem kell mindenhol megszakadni... meg a pénz is kevés... :D Ugyan ez a hallgató nem tudott bármilyen választható nyelven egy láncolt listát készíteni... :P
- A hozzászóláshoz be kell jelentkezni
Fontos az elmélet is, a gyakorlat is.
A személy legyen képes felmérni hogy adott feladathoz kábé milyen szintű elméleti és gyakorlati tudásra, valamint ezek megszerzésére irányuló mekkora erőfeszítésre és idő befektetésre van szükség(e).
Egyszerűbben kifejezve - legyen képes tényleg megérteni a feladatot, józanul felmérni eleve milyen képességekkel, eszközökkel rendelkezik megoldásához és mivel nem, valamint hogy valóban képes-e a hiányzó dolgokat, tudást beszerezni, elsajátítani elfogadható áron és időn belül.
Véleményem szerint ez a képesség hiányzik legjobban az emberekből.
--
http://opensolaris.org/os/project/indiana/
http://www.opera.com/browser/
- A hozzászóláshoz be kell jelentkezni
Mondjuk amikor a delikvens beirja az SQL-nek, hogy order by random(), akkor illik tudni, hogy ez milyen ordo szerint fog lefutni.
Vagy ha hashmap-alapu index felett akar kisebb-nagyobb kerdeskort implementalni, ez is hirtelen problemakba tud utkozni.
Igaz, a hashmapek legalabb jol parhuzamosithatoak :)
Rengetegszer van az, hogy akar nyelvelmeleti, akar matematikai adatstrukturak, vagy mas elmelet szedi rendbe a kodot.
Mondjuk AUT-os voltam, a tanszek honlapjan regen kinn volt a maxwell-i motto: "Semmi nem olyan gyakorlatias, mint egy jo elmelet". De ez az a gondolkodasmod, ami miatt magasabb fizetest kapok, tobbszoroset akar, mint azok, akik csak a gyakorlatban hisznek.
- A hozzászóláshoz be kell jelentkezni
Na, pont ilyesmikre gondoltam. (ezek hasonlítanak Wigner példájára)
-----------
"Generally, Russian technology assumes dumb machines and smart humans, not the other way around." -- The Russian Tea HOWTO
- A hozzászóláshoz be kell jelentkezni
Az ideális a kettő egészséges aránya lenne. A bolognai rendszerre áttérésnél volt egy nagy esély, amit elaszalasztottak. Szimplán csak ketté vágták, rosszabb esetben lecsupaszították és 3 évbe zsúfolták a korábbi tanterveket, ahelyett, hogy a bsc gyakorlati képzés részét felturbózták volna, hogy elméleti alapozással, és sok-sok gyakorlattal felkészítsen a "tömegmunkára". Utóbbi alatt arra kell gondolni, hogy pl egy gyártást felügyelő mérnöknek nem kell annyira képzettnek lennie, mint aki a terméket tervezi. Vagy egy általános iskolai matektanárnak is teljesen felesleges öt évig analízist meg differenciálegyenleteket tanulnia, hogy a nevelési képzésére ne maradjon idő. MSC két évében ki lehet térni a felsőbb dolgokra, ami extra, és ezért nem is kellene minden bsc-snek tovább lépnie. A leg-legnek meg ott van a doktori.
- A hozzászóláshoz be kell jelentkezni
ahahah, felénk az MSc-n adják le azt az elméleti anyagot, amivel a BSc-t kéne kezdeni :D
Szerinted mekkora a jelentkezési kedv?
--
"SzAM-7 -es, tudjátok amivel a Mirage-okat szokták lelőni" - Robi.
- A hozzászóláshoz be kell jelentkezni
Találtam egy cikket, ami szintén ehhez a témához szól hozzá és egy elég jó érvet fogalmaz meg az egyetemek gyakorlatorientáltsága ellen.
http://cdsmith.wordpress.com/2011/07/17/industry-driven-computer-scienc…
Ha van kedvetek, kommentáljátok.
-----------
"Generally, Russian technology assumes dumb machines and smart humans, not the other way around." -- The Russian Tea HOWTO
- A hozzászóláshoz be kell jelentkezni