"A programhiba meg az összes azonos programmal rendelkezõt, ilyen egyszerû" Az ilyen mindegyiket tönkretevõ programhibákat viszont egyszerûen lehet teszteléssel szûrni.
A programozásnak egy része intuitív, ezt sosem fogják tudni automatizálni szerintem. A mechanikus részekre (lásd Access), már vannak egész tûrhetõ megoldások, hogy a rabszolgamunkát csökkentsék.
Nem megfelelõ karbantartás miatt sokkal több katasztrófa van mint hibásan beágyazott rendszer miatt. Egyszerûen azért mert az elsõ közvetlen emberi hiba és nehezebb korlátok között tartani, a másik viszont gépi hiba = közvetett (emberi) hiba mert végül is emberek csinálták, és sokkal könnyebb kezelni, javítani, szem elõtt tartani.
Tökmindegy, hogy melyik vacak, és hogy hosszabb ideig kellett volna nyomni. Egy gyújtáskapcsolót sokkal egyszerûbb elfordítani. És az azonnal kikapcsolja a motort, elektronika ide vagy oda.
Ja. Az autónak is kellett majd 100 év mire olyan "biztonságos" lett mint ma. A tökéletesség túl szigorú elvárás. Nem a gépektõl szigorú hanem saját magunktól. A cikkben említett repülés is idõvel lett biztonságos. Balesetek meg mindig vannak. Mi a különbség aközött hogy nem megfelelõ karbantartás vagy hibásan beágyazott rendszer okozta a katasztrófát?
Azért képezünk ki technikusokat mérnökök mellé, mert nem lehet mérnökökbõl elegendõt képezni és ha lehetne is akkor sincs szükség, hiszen ha hiszed ha nem az kórva sok pénzbe kerül és felesleges egy szívsebészt képezni ki sebek kötésére, a technika is ilyen, vannak feladatok amelyekre mérnöki tudás kell és vannak feladatok amelyeket az nélkül is meg tudunk oldani elfogadható szinten. A Gaussz görbe elkerülhetetlen dolog, mindég lesznek jobb és roszabb szakemberek, különbözõ szinten a fontos, dolog, hogy a munkájuk terméke megfelelõ legyen, hogy gazdaságosan tudjuk elõállítani és, hogy a plusz oldal felülmúlja a minusz oldalt. Az életben minden két vagy több NEM TÖKÉLETES dolog közötti választás, igy van ez a programozásban is. Filozofálhatunk vagy csinálhatunk valamit amit az emberek alkalmaznak és alkalmazni akarnak.
Az automata rendszereknél is ez a kérdés, nem az, hogy túl megbízunk e vagy sem, hanem, hogy mi az alternatíva... és még hasonló erõforrások alkalmazása melett nem tudunk jobb alternatívát felmutatni addig az van ami van, felesleges dumálni és az embereket félelmíteni, ezt tudjuk ma, holnap többet fogunk tudni, ez a fejlõdés, ez az egyetlen út elõre. Vannak kockázatok, vannak tévedések és vannak áldozatok is, de ez nélkül mi emberek olyan lények akik nem ismerik a tökéletességet nem juthatunk el sehová. Fontos dolog, hogy adott esetben a veszélyekre válaszolni tudjunk megfelelõ módon (response capacity >= danger potential).
4. generációs programozási nyelvek... haha látom igazi értéktelen egyetemi képzésben volt részed :) a programozúsi nyelvek nem úgy fejlõdnek ahogy a 80-as években gondolták, új nyelvek általában kutatás céljából születnek, és az ami fontos a meglévõ absztrakciókra való építés. Röviden a modern nyelveknek van némi közük az úgynevezett 4. generációs nyelvekhez olyan szampontból, hogy elfogadják a deklaratív ellemeket az imperatív ellemek mellé, ugyanakkor olyan dolgok jelentek meg amelyekre mondjuk 20 évvel ezelõtt nem igen számítottak (mint pl. a multicore). Ha érdekel a dolog közelebrõl, akkor nézd meg Anders Hejlsberg elõadásait a nyelvek fejlõdésérõl, a C# 4.0-ról és a C# "Next"-rõl.
A fejlõdés óriási, csak éppen az elvárások sok esetben régi és téves alapokon vannak, a fejlõdés és a fejlesztések a valóságból erednek nem pedig valami 30 évvel ezelõtti elképzelésekre. És pl. az Accessban levõ megoldások nem alkalmasak mindenféle feladatra, de azt mondani, hogy nem alkalmasak komoly feladatokra naív dolog, hiszen több tízezer megoldást készítettek és készítenek vele amelyeknek összértéke akár több miliárd dollárt ellenértékü feladatok elvégzésével egyenlõ... én ezt nem nevezném komolytalan feladatoknak.
Milyen elveket szoktál alkalmazni? Nem mintha épp nagy szakértõje lennék a dolognak, úgy 15 éve tanultam én is a Jackson módszerrõl, meg utána olvasgattam a genetikai algoritmusokról, de fogalmam nincs, hogy gyakorló rendszertervezõk ma miket használnak. Van erre is esetleg szoftver? Emlékszem, még akkor rebesgették, hogy még a programozás terhét is leveszik a vállunkról, mert megszületnek a 4. generációs programozási nyelvek, tehát valaki egy varázslóval tud írni mondjuk C nyelvû programot. Hát, ahhoz képest sehol nincs a dolog. Persze, van pl. a Microsoft Accessben adatbázis-varázsló meg ilyenek, de ezek komoly feladatokra nem alkalmasok.
Nem egészen az egy emberre gondoltam, és nem így :) hanem inkább arra pld hogy egy inteligens kamerás megfigyelõ rendszerhez magát a kamerán futó szoftvert megírják mondjuk Izraelben a szerver szolgáltatást megírják mondjuk Indiában majd ezt az egészet mondjuk Münchenben próbálják beleverni valami intleigensnek mondott rendszer egészébe... arról már nem is beszéllek mi van ha valakinek megtetszik a müncheni ötlet és ugyan ezt meg akarja valósítani mondju Rioban
"A problémát sok esetben darabolják amikor a fejlesztõnek már nem is az egész cél lebeg a szeme elõtt, hanem a feladatnak az a része amit ép az orra elé toltak." Azért a legtöbb esetben erre szükség van. 1 ember nem fog oprendszert fejleszteni. A részfeladatokra bontást lehet ésszerûen végrehajtani. Az objektumorientált nyelv sokat segít. Ha pedig a programozó veszi a fáradságot a kivételkezelésre, akkor nincs probléma. A feladat részfeladatokra bontása maga is programozás, csak nem meglévõ utasításokat használsz, hanem újakat, amiket késõbb megvalósítássz. Szóval szerintem ez a részfeladatosdi kb annyira veszéjes mint hogy te nem alacsonyszinten programozol hanem magasabb szinten.
A probléma inkább az hogy ma már elõbb kezd el valaki programot írni és futtatni mintsem hogy tudna programozni. (Saját magam példáján látom.) Elkezdi írni a programot azelõtt hogy tudná mit is akar valójában. Régen az ember átverekedte magát az egyetemi szintû matekon. Közben vagy utána megismerkedett a számítógéppel. Aztán elkezdett programozni. Megírt egy programot. Majd lefuttatta. Tudom hogy régen volt de a lyukkártyás idõben még valahogy kevesebb futásközbeni debugra volt lehetõség.
Egyszó mint száz: A nagy informatikai forradalmunk után ma már programozónak hívják azt is aki nem az.
1. nem honda volt, hanem toyota prius 2. volt benne fõkapcsoló: csak 3 mp-ig nyomva kellett volna tartania az ignition on/off gombot
Persze ez abban a feszült helyzetben nem feltétlenül jut az ember eszébe, lehet, hogy nem is tud róla stb. mindenesetre egy ilyen sajnálatos eset után mindenki megtanulja valózínûleg...
Hát azért mindig kell egy fõkapcsoló, amit le lehet kapcsolni, ha gáz van. Különben úgy járhatunk, mint az a fószer, aki nem tudott megállni a Hondájával a felakadt gázpedállal. Õ sem tudta lekapcsolni a gyújtást, az elektronika nem engedte.
Lámpa nélküli város: éjjellátót mindenkinek! Szerintem a legnagyobb ellenérv a "De olyan hangulatos a város északa kivilágítva." lenne.
Gyakorlatilag én ott látom a hibát hogy nem egy adott célra fejlesztett rendszert használnak nagyon sok esetben hanem már meglévõ rendszereket megoldásokat integrálnak, ami vagy bejön vagy nem, sok esetben nem olyan könnyû megírni egy interfészt mint azt az ember elsõre gondolná. A fejlesztés mint olyan fontos és remek dolog de nagyon kevesen hajlandóak annyi pénzt és idõt rá áldozni amennyi valóban szükséges lenne. A problémát sok esetben darabolják amikor a fejlesztõnek már nem is az egész cél lebeg a szeme elõtt, hanem a feladatnak az a része amit ép az orra elé toltak. A lámpa nélküli városokra csak annyit tudok mondani hogy amíg az emberi tényezõt nem veszik ki vagy legalábbis minimalizálják addig sajnos nagyon nehezen megoldható lenne a dolog. Sok esetben mint tudjuk az embereknek a KRESZ mint olyan csak útmutatás és nem szabály.
Hmm, a légiirányításnál van backup. Valóban nagy gáz van, ha valami kihal, de azért vannak a redundáns rendszerek, hogy valahogy de mûködjenek a dolgok. Ha nagy is a gáz, nem fognak tudni olyan sûrûn repülni, nagyobb rátartásokkal kell dolgozniuk, valószínû lesz pár elirányítás is, de összeütközni jó eséllyel nem fognak.
Mondjuk en pont ezzel foglalkozom, tehat rendszertervezessel. Barki, akik megfelelo intelligenciaval rendelkezik kepes atlatni barmekkora rendszert, csak megfeleloen kell kezelnie a kulonbozo szinteket. A cikknek annyiban igaza van, hogy a legtobb fejleszto tenyleg nem akarja atlatni, hogy mit csinal, csak a neki adott feladatot megoldani. Ez azert van, mert a fejleszto mernokok helyett ujabban fejleszto technikusokat kepeznek mindenutt, ami szerintem hiba.
A lampak nelkuli varoshoz pedig csak annyit, hogy egy automata raktarban sem mennek egymasnak a rakodo robotok. Ezt egy varos szintjen is meg lehetne oldani ugyanezzel a meglevo technikaval, csak sokba kerulne.
Informatika és tudomány
