17
-
philcsy #17 "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. -
#16
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. -
BlackRose #15 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. -
teddybear #14 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. -
teddybear #13 A nem megfelelő karbantartás csak azt az egy gépet teszi tönkre, amelyikről szó van.
A programhiba meg az összes azonos programmal rendelkezőt, ilyen egyszerű. -
philcsy #12 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? -
BlackRose #11 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). -
BlackRose #10 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.
http://channel9.msdn.com/posts/adebruyn/TechDays-2010-Developer-Keynote-by-Anders-Hejlsberg/
http://channel9.msdn.com/posts/matthijs/C-40-and-beyond-by-Anders-Hejlsberg/
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. -
#9
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.
-
Sith #8 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 -
philcsy #7 "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. -
moikboy #6 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... -
teddybear #5 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. -
philcsy #4 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. -
Sith #3 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. -
bakagaijin #2 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. -
kvp #1 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.