Automatikusan kijavítja a programhibákat a MIT új szoftvere
2015-06-30T09:10:39+02:00
2015-07-06T12:49:32+02:00
2022-07-19T02:07:38+02:00
  • Fordítva sokkal több értelme lenne a dolognak: egy olyan algoritmusnak ami a kód alapján megírja a unit tesztet egy átlag cégnél sokkal több haszna lenne - ez esetben legalább lenne unit teszt.

    Ha a teszt van előbb, akkor ahhoz úgy íródik a program, hogy azt tesztelni lehessen, illetve megfeleljen a tesztnek, fordítva viszont ez nem igazán fog működni minden esetben. Szóval nem azért nincs ilyen program, mert nem egyszerű kifejleszteni, hanem alapvetően ma már nem így fejlesztünk programokat.
    Mutasd a teljes hozzászólást!
  • Véleményem szerint ennek esetleg úgy lehetne valódi előnye, ha nem ismert a forráskód.

    Például (figyelem TRUE STORY) készítek egy OpenGL -lel működő kis alkalmazást, elfelejtek egy contextet inicializálni, ami kiesik 3 kiloval + 5 unittal arrébb egy virtuális metódusban.
    Konkrétan tudok a hibáról, látom, hogy mi a baja.
    Hogyan mondom meg a bináris EXE-ből, hogy ezt a contextet ott valahol inicializálni kell ( mert ugye egy ilyen egyszerű kódot leírok és még meg is mondom neki ezt rakd be), DE HOVÁ?

    Nem a lázadás a célom az ilyen programok ellen, sőt szerintem szükség is van rá, de nem tudom, hogyan tudnának igazán hatékonyan működni, kisebb hibatűréssel, mint egy ember (habár végül a cél nem teljesen ez feltételezem).
    Mutasd a teljes hozzászólást!
  • A nézetkülönbség abból adódik, hogy elvileg a lego kódjavító elemek csak piciny építőkockák lehetnek.
    Nem valószínű, hogy pl. egymást valósan kiváltó komplett osztályokat találsz más-más kódokban.
    Ez csak rutinfeladatra jöhet elő, pl. stream beolvasás vagy rendezés stb.
    Ez a könnyebb eset, de ezek az ezerszer áttesztelt (tipikusan gyári vagy külső-nyilvános-sokak által használt) osztály.

    Ha nem egy komplett osztályt akarunk kilegózni, hanem csak egy részét... na innen gondok vannak.
    A kivülről jól definiált (publikus interface) osztály helyett egy ezer belső függőséggel rendelkez(het)ő függvényt cseréljünk.
    Nehezen látom át a biztonságos csere lehetőségét.
    A hagyományos C kódolással szólva sok a Global Variables használat, mivel a (legózandó) osztály tagfüggvény pont nem erőlteti a lokális változók és paraméterekkel átadások elvét.
    A C-ben ugye függvény szinten akartunk interface-t definiálni, hogy kisebb legyen a függőség a környezettől. 
    Osztály szinten ez a "réteg" magasabbra került... de most megint egy globális függőségekkel terhelt függvény cseréjéről beszélünk.

    Szóval ez is inkább olyan mint a programíró program.
    Inkább a hírverés, a marketing az erősebb ok, nem a hasznosság. [Egy egyetemnek is el kell adnia magát.]
    Egyetemi project, én inkább kutatási témának fogom fel.... majd ha a MS, Ora, G, FB hozza ki ezeket az eszközöket, ne adj isten fizetős termékként jelenik meg... na akkor kevésbé kételkedem a hatékonyságában.
    Mutasd a teljes hozzászólást!
  • Az elméleted teljesen hibás - kár volt ennyi betűt pazarolni rá. Azért hibás, mert az alaphelyzet az, hogy van egy hiba, amiről tudjuk hogy van, és tudjuk, hogy mi a lényege, és ki kellene javítani. Innentől kezdve viszont tudunk tesztet is írni rá, méghozzá célzottan.

    Nyilván csak az az "apróság" kerülte el a figyelmed, hogy itt nem egy hibakereső, hanem egy hibajavító eszközről van. Ami nem megkeresi a hibát (és így nem tud elsikalni sem felette), hanem "csak" automatikusan és önállóan kijavítja, illetve megszünteti azt, ha amúgy a hiba lényege, természete valamilyen módon már korábban ismertté vált.
    Mutasd a teljes hozzászólást!
  • Tapasztalataim szerint alapvetően három főbb probléma szokott hibát okozni:

    1. A fejlesztő nem értette meg a specifikációt, vagy rosszul értette, vagy figyelmen kívül hagyott valamit. Ez esetben a unit teszt amit ír centire ugyanolyan rossz lesz mint a program.

    2. A rendszer részei között nincs megfelelő kapcsolat, vagy a fejlesztő nem érti azt. Pl. egy információt három táblából kellene összeszedni, de ő csak kettőt vesz figyelembe. Vagy nem a megfelelő függvényt hívja. Vagy nem megfelelő sorrendben.

    3. Olyan technikai hibák amikkel a fejlesztő nem számolhatott. Pl. hiba egy külső komponensben ami csak egy ritka csillagegyüttállás esetén jön elő, de az élet kihozta.

    Ezek mindegyike olyasmi, amit a unit teszt nem fog kiszűrni. Ergo az ellenőrző csodaprogram sem.

    Vannak ezen kívül olyan dolgok, mint a paraméterek rossz sorrendje, a hiányzó paraméterek, Stb, de ha jó az architect aki a rendszert tervezte akkor ezek nagy részét a statikus fordítás és a szigorú típusrendszer kiszűri, úgy hogy ezek általában már nem jutnak el a fordításig sem, a mai IDE-k már szerkesztéskor jelzik hogy hülyeséget akarsz csinálni.

    Ráadásul, ha véletlenül nem teljesen tökéletes a unit teszt, akkor csúnya dolgok történhetnek: a rendszer kreálhat neked egy olyan kódot ami ugyan a teszten átmegy, de ha kiteszed az ügyfélhez akkor katasztrófát okoz. Márpedig unit teszt oldalról sokkal körülményesebb leírni egy folyamatot (és persze hosszabb is) mint kód oldalról. Ezért is van az, hogy a cégek legszívesebben a unit teszteket hagyják el - ugyanis elég húzós költség a kifejlesztésük, legalább annyi mint a kódé de ha igazán alapos a teszt akkor több is lehet, az end-user pedig nem látja hogy van-e.

    Másrészt, egy átlag alkalmazásban az algoritmusok 99%-a többé-kevésbé egyedi. Ha te írsz egy quicksort implementációt, vagy egy bináris keresést, írsz rá egy fullos unit tesztet, akkor ezzel az algoritmussal simán meg lehet találni benne a hibát a neten keringő számos más buborékrendezés alapján. De ha te írsz egy üzleti logikát ami leír egy olyan folyamatot ami eddig még soha nem létezett, akkor a kereső igazából egyetlen forráskódnak tudja hasznát venni az egész interneten: a unit teszt forráskódjának... Azt viszont simán el tudom képzelni, hogy egy tökéletes unit teszt alapján meg lehessen írni a forráskódot, bár tekintve hogy egy ilyen unit test megírása általában jóval nagyobb meló mint magának a kódnak a kifejlesztése, ettől jelentősen nem fog előre lépni a szakma. Fordítva sokkal több értelme lenne a dolognak: egy olyan algoritmusnak ami a kód alapján megírja a unit tesztet egy átlag cégnél sokkal több haszna lenne - ez esetben legalább lenne unit teszt. De azért egy ilyen kifejlesztése sem annyira egyszerű móka, nem véletlenül nincs ilyen (én legalábbis nem tudok róla).
    Mutasd a teljes hozzászólást!
  • Csak a programozásban ez nem a teljes paletta. Sok standard feladatot kódolunk, ahol lehet találni olyan 'cseredarabot', ami funkcionálisan megfelel.
    De közel sem minden ilyen!

    Ha ez így van, akkor ezen esetben ez a módszer nem alkalmazható. Ugyanakkor millió másikban viszont igen, ahol érdemes lesz alkalmazni. Ez lett elmondva az előbb az utolsó bekezdésben. Ti. hogy önmagában az, hogy egy eszköz nem mindig és nem mindenre használható, az nem érv az eszköz használata ellen. Főleg, hogy gyakorlatilag nincs is olyan eszközünk soha, ami tényleg mindig, mindenre és minden szempontból jó vagy tökéletes lenne.

    Csak nem is tud róla, hogy milyen kopás, törés és hőterhelés előírások vonatkoztak az adott alkatrészre.

    De ezeket nem is kell tudnia. Mert hogy a tesztelés (ti. amivel az eszköz megállapítja, hogy megfelelő -e a "cseredarab") vagy vizsgálja ezeket is - és akkor az eredményében benne lesz ezek megfelelősége is, és emiatt az ezen elvárásoknak meg nem felelő cseredarabot az eszköz nem fogja a kódba beépíteni, illetve a tesztelés erejéig beépítést követően benne hagyni. Vagy a program tesztje nem vizsgálja ezeket a paramétereket, mert lényegtelenek - és akkor meg tök mindegy lesz, hogy mi a kopás-, törés- és hőállósága a cseredarabnak, mert nem lesz elvárás vele szemben, hogy bármelyik vonatkozásában is előre elvárt értékeket teljesítsen.

    Tehát az eszköz mindig csak a valóban létező elvárásoknak megfelelő cseredarabbal fogja a hibás kódot helyettesíteni a folyamat végén, függetlenül attól, hogy ő maga nem fogja tudni, hogy mik ezek az elvárások - és nem is kell tudnia vagy értelmeznie ezeket az elvárásokat. Ez ugyanis nem az ő, hanem annak a tesztnek a feladata, amivel a program megfelelőségét (helyességét, és az elvárásoknak megfelelőségét) vizsgálja az "operáció", illetve a "szerviz" során. Amely tesztet amúgy szintén készíthet humán felhasználó vagy akár egy hasonló, automatikus szoftvereszköz is pl. a specifikáció alapján - ha azt tudja valahogy értelmezni.

    Persze ez (ti. hogy ki vagy mi is készíti a teszteket) megint olyan faktor, ami a módszer és a hibajavító eszköz használhatósága szempontjából teljesen irreleváns. Mint ahogy az is, hogy a beültetett cserekódot eredetileg ember vagy gép állította -e elő.

    A repülő (hogy legyen zavarosabb a példa), meg jól lezuhan az óceán felett, mert a cserélt darab kifáradt.

    Ha ez így történik, akkor rosszul írták meg a tesztet, amivel a cseredarab megfelelőségét vizsgálta az eszköz. Mert, hogy ugye - a repülővel szemben - egy szoftvert mindig lehet úgy is tesztelni (illetve úgy kell megírni, hogy akkor is lehessen tesztelni), hogy közben ezzel nem kell kockáztatni nem, hogy életeket és vagyontárgyakat, de adatok épségét sem. Tehát egy szoftver esetében kockázat nélkül kideríthető lehet az, hogy mi történne vele az óceán felett X km megtett út, X óra üzemidő, X fok hőmérséklet mellett. Ennek vizsgálata a tesztek feladata.
    Mutasd a teljes hozzászólást!
  • Látom te nem érted a dolgot. 

    Ha valóban egy szabványos fődarabcsere és kész, akkor rendben is lenne a dolog.

    Csak a programozásban ez nem a teljes paletta. Sok standard feladatot kódolunk, ahol lehet találni olyan 'cseredarabot', ami funkcionálisan megfelel.
    De közel sem minden ilyen!

    Hogy a gk. alkatrész hasonlatoddal éljek:
    A 'robot' megállapítja, hogy méreteiben és formájában tökéletesen cserélhető az alkatrész (interface teszt), és ki is cseréli.
    Na brááávó.
    Csak nem is tud róla, hogy milyen kopás, törés és hőterhelés előírások vonatkoztak az adott alkatrészre.
    A repülő (hogy legyen zavarosabb a példa), meg jól lezuhan az óceán felett, mert a cserélt darab kifáradt.
    Mutasd a teljes hozzászólást!
  • Mármint nincs különbség a mechanikus, (de mégiscsak véges számú szabállyal támogatott) sémák alapján és az emberi intelligenciával megtámogatott javítás között?

    A kérdéseből arra következtetek, hogy te egyszerűen nem érted hogyan működik ez a dolog. Itt szó sincs véges számú szabály és séma követéséről a gép részéről. Illetve, amit te a "javítás" alatt értesz, azt egyik esetben sem valami mechanikus szoftver állítja elő, hanem az emberi intelligencia.

    A különbség a két eset között csak abban van, hogy - egy autós hasonlattal élve - mi történik a hibásnak bizonyult fődarabbal. Az egyik esetben a szaki elkezdi szétszedni, megnézni, hogy mi törött vagy kopott el benne, majd ha szükséges megpróbálja meghegeszteni, újrazsírozni az alkatrészt, vagy kicserélni valami apró bizgányt benne, és visszarakni a helyére. Amely megoldási módszerrel az a baj, hogy egyrészt igencsak hozzértő szakembert kíván (amiből kevés van és akit jól meg kell fizetni), másrészt amely folyamat (lévén emberektől beszélünk) sok időbe tellik, nem mindig azonos minőséget eredményez, stb.

    A másik esetben meg egy robot fogja és kicseréli a fődarabot egy másik autóban talált hasonló fődarabra. Persze mivel buta robot, ezért nem tudja biztosra, hogy a másik autóból származó fődarab az jól fog -e működni az új helyén - akár azért, mert nem illeszkedik oda, akár azért, mert esetleg az újonnan beépített fődarab maga is hibás. De ezt (ti. hogy megfelelő és jól működik -e) egy gyors teszttel kideríti. És ha az új fődarab sem jó, akkor fogja, és egy harmadik autóból származó fődarabbal próbálja meg kicserélni. Ha meg az sem jó, akkor jön a negyedik jelölt. És így tovább, egészen amíg jó nem lesz. Mindezt persze villámgyorsan csinálja, és így sok esetben jóval gyorsabban tud végezni "butasága" ellenére is a javítással, mint ahogy a szaki egyáltalán csak szétszedné a fődarabot és elkezdené kutatni a hiba okát benne.

    Ugyanakkor mindkét esetben közös, hogy a fődarabokat eredetileg emberi intelligencia alkotta, nem pedig a gép. Ő legfeljebb csak a cserét végzi, kompletten. Amihez ugye sok ész vagy intelligencia nem kell. Annyi legalábbis biztosan nem, ami a fődarab belső működésének megértését - vagy pláne megjavítását - megkívánná.

    Viszont a másik oldalon elmondható az is, hogy ha az új fődarab tökéletesen működik az új helyén a tesztek szerint, akkor egyébként is tök irrelevánssá válik az, hogy azt ki alkotta meg és hogyan. Mert hogy működik - és csak ez számít. Innentől akár lehetne gép vagy egy majom is az adott darab alkotója, mert ez nyilván a helyes működésén nem változtatna, ha utóbbi már bizonyításra került.

    A szokásos a csapda. A mai korban ezerszer bebizonyosodott.
    Egy határig a számítógép nyers ereje és hihetetlen mennyiségű adata, amit feldolgozhat lenyomja az embert is... aztán egyszer elérünk egy határvonalat, ahonnan csak az emberi intelligencia ad megoldást.

    Semmilyen csapda nincs. Ha csapda lenne, akkor nem használnánk számítógépeket, mert kiderült volna, hogy semmire sem jók. De használunk. Mert az derült ki, hogy bár nem minden feladatot tudnak átvenni tőlünk, de sokat igen, és azokat sokkal jobban tudják ellátni, mint mi.

    Na, pontosan ugyanez a helyzet egy ilyen automatikus hibajavító rendszerrel is. Ami nem feltétlenül tud minden hibát kijavítani, új szoftvert meg pláne nem tud írni. Viszont ettől még rengeteg hibajavítást tényleg elvégezhet automatikusan, emberi segítség nélkül is, ráadásul esetleg sokkal gyorsabban és hatékonyabban, mint ahogy azt egy emberi fejlesztő tudná megcsinálni.
    Mutasd a teljes hozzászólást!
  • nem állítható fel bármilyen egyértelmű minőségi reláció egy-egy humán programozó és a CodePhag által eszközölt javítás között



    Mármint nincs különbség a mechanikus, (de mégiscsak véges számú szabállyal támogatott) sémák alapján és az emberi intelligenciával megtámogatott javítás között?

    A szokásos a csapda. A mai korban ezerszer bebizonyosodott.
    Egy határig a számítógép nyers ereje és hihetetlen mennyiségű adata, amit feldolgozhat lenyomja az embert is... aztán egyszer elérünk egy határvonalat, ahonnan csak az emberi intelligencia ad megoldást.
    Mutasd a teljes hozzászólást!
  • Lenne egy fogadásom, a látszólagosan megoldott probléma a mélyben ketyegő bombát rejthet kellemetlenül nagy százalékban.

    Csak akkor, ha a teszt nem megfelelő. Ugyanakkor ha a teszt(elés) nem megfelelő, akkor bármilyen - akár humán programozók által megírt - programkód is tele lehet "mélyben ketyegő" bombákkal. Vagy akár teljesen felszínesekkel is.

    Ha nincs MI mögötte (márpedig nem lehet, mert ez elvezet a programot megíró programig), akkor a mechanikus javítás vagy valódi megoldás vagy nem.

    Ez egyrészt nem az MI függvénye. Bármilyen úton létrehozott kódról elmondható, hogy vagy azt csinálja amit kell, vagy nem. Ezt csak a tesztelés derítheti ki, és az is csak addig a mértékig, ameddig az maga is helyes, illetve amilyen mélyen vagy széles körben az vizsgálja egyáltalán a helyességet.

    A lényeg ugyanakkor az, hogy ha a teszt megerősíti (egy adott vonatkozásban), hogy a kód azt csinálja amit kell, akkor teljesen irreleváns, hogy a kód milyen úton jött létre, mert a lényeg: hogy az (legalábbis az adott vonatkozásban) azt csinálja amit kell.

    A másik oldalon bármilyen kód, amit ez az eszköz beépít a programba jó eséllyel korábban nem hogy egy magasszintű MI, hanem konkrétan humán programozók által lett létrehozva. Csak éppen egy másik programban - de ott valószínűleg ugyanaz, vagy legalábbis nagyon hasonló probléma megoldására, mint amilyennel az új helyén kell megbirkóznia.

    De a lényeg, hogy előbbi miatt megint csak egyértelműen kijelenthető, hogy nincs, illetve nem szükségszerű, hogy egyértelmű minőségi különbség legyen az eredeti és a beépített kódok között. Mert hogy mindkettőt ugyanolyan értelmes (vagy éppen ugyanolyan kutyaütő) emberi programozók hozhatták létre anno.

    Ahogy nem lehet bizonyítani a programhelyességet, úgy azt sem lehet bizonyítani, hogy a beillesztett lego kódrészlet valóban kiváltja ill. helyettesíti (teljes funkcionalitásában) a kívánt feladatot vagy csak a teszttel lefedett, mechanikusan feltételezett részét.

    Lásd fent. Ez a humán programozók által létrehozott kódokra is éppen annyira igaz. Tehát ez csak annyira ellenérv, mint amennyire érv is. Illetve ez alapján egyértelmű, hogy nem állítható fel bármilyen egyértelmű minőségi reláció egy-egy humán programozó és a CodePhag által eszközölt javítás között.

    A kódcserés javítás csak standard, valóban sokszor felmerülő és sokszor megoldott típus feladatokra működhet.

    Minden eszköz csak bizonyos helyzetekben használható hatékonyan. Amitől az adott eset kezelését, megoldását még nagyságrendekkel hatékonyabbá teheti. Tehát ezzel megint nem mondtál semmi negatívumot erről, és pláne nem bizonyítottad azt, hogy ne lenne érdemes esetleg alkalmazni ott, ahol lehet.
    Mutasd a teljes hozzászólást!
  • Lenne egy fogadásom, a látszólagosan megoldott probléma a mélyben ketyegő bombát rejthet kellemetlenül nagy százalékban.

    Ha nincs MI mögötte (márpedig nem lehet, mert ez elvezet a programot megíró programig), akkor a mechanikus javítás vagy valódi megoldás vagy nem.

    Ahogy nem lehet bizonyítani a programhelyességet, úgy azt sem lehet bizonyítani, hogy a beillesztett lego kódrészlet valóban kiváltja ill. helyettesíti (teljes funkcionalitásában) a kívánt feladatot vagy csak a teszttel lefedett, mechanikusan feltételezett részét.

    A kódcserés javítás csak standard, valóban sokszor felmerülő és sokszor megoldott típus feladatokra működhet.
    De nem minden algoritmus ilyen, léteznek egyedi algoritmusok, amik csak abban az egy programban, csak arra az egy problémára készülnek... nincs mivel kilegózni. Ha meg mégis kilegózták, na akkor az nagy gáz, mert nem felel meg a kapott javítás az eredeti specifikációnak, célnak [ami gyakran le sincs írva, csak a programozó fejében és a kód függőségeiben létezik, a legjobb esetben is csak a forrásban egy kommentben].
    Mutasd a teljes hozzászólást!
  • Pedig ez a módszer bizony igenis az okot, a hibát magát javítja ki. Csak nem intelligensen, a probléma megértésén keresztül, hanem mindössze már jól működő megoldások szolgai másolásával, illetve nyers erőből teszi ezt. Tegyük hozzá: a mai fejlesztők legnagyobb része is ugyanezt teszi, csak sokkal több erőforrásból és sokkal lassabban.
    Mutasd a teljes hozzászólást!
  • Ott nem alkalmaznám, de ha működne, akkor bevállalnék pár másodállást, távmunkában.
    Mutasd a teljes hozzászólást!
  • Igen, kábé így működik. Azzal a különbséggel, hogy a pénzt nem te kapod meg, hanem téged kirúg a főnök és helyetted megtartja magának azt.
    Mutasd a teljes hozzászólást!
  • Vagyis feltalálták a "gépi patkolást". 

    Tulajdonképpen jó megoldás, ha kézzel is csak megpatkolnák a programot.
    Ez még megoldás is lehet, ha nem lehet leállni, mennie kell a dolognak.

    De komoly(!) cégnél legfeljebb addig megy a patkolás, amíg egy értelmes programozó meg nem keresi az OKOT és nem javítja azt.
    Mutasd a teljes hozzászólást!
  • Igen, pont erről van szó: van amikor a fejlesztő is így javít hibát. Ha már van neki egy jól működő, általa ismert komponense a feladatra, gyorsabb, ha erre cseréli le a rossz kódrészletet, mintha elkezdi bogarászni a rosszat, megpróbálja megérteni, átírni, stb.

    Az meg, hogy elveszi az emberek munkáját: hát, egyszer majd lehet, de én ilyen munka után nem sírnék. :) Annyi szakma megszűnt/megszűnik, miért pont a tesztelés lenne kivétel? Ha egyszer jól automatizálható...
    Mindig lesz olyan tevékenység, amit az emberek csinálhatnak, csak meg kell keresni, aktuálisan éppen mi az.
    Mutasd a teljes hozzászólást!
  • Tehát ha jól megfogalmazom a teszteket és egy üres képernyővel és projekt struktúrával otthagyom éjszakára, akkor reggelre megírja helyettem a programot? Ha én kapom érte a pénzt, akkor jöhet:)
    Mutasd a teljes hozzászólást!
  • Ahhoz, hogy egy ilyen eszköz értelmesen és megbízhatóan müködjön értenie kellene azt a folyamatot amit leprogramoztak.

    Abszolút nem kell. A program helyességét ugye nem önállóan ellenőrzi, hanem egy kvázi külső teszt mondja meg neki ezt. Tehát a helyesség megállapításához semmiféle intelligenciára nincs szüksége. Nem, hogy mesterségesre, de szó szerint semmilyenre, hiszen gyakorlatilag csak igaz-hamis bemenetként kapja.

    A helyettesítő kódok megkereséséhez pedig szintén nincs szükség szuperfejlett MI-re, hanem egyszerű részleges műveleti mintaegyezés alapján, heurisztikával fel tudja kutatni ezeket. Na, most utóbbi nyilván önmagában nem működne tökéletesen, de nem baj ha hibázik, mert a hamis pozitívakat (tehát amikor az eszköz olyan kódrészletet próbál transzplantálni, ami szerinte jó helyettesítője lehetne az eredetinek a heursztika alapján, de valójában nem az) a tesztelés kiszűri.

    Hiszen ha tényleg nem tudja jól helyettesíteni az eredeti kódot a frissen beillesztett idegen kód, akkor a teszteken ismét hibásnak bizonyul majd (az immár vegyes kódokból álló) hibrid program, és az eszköz megy tovább és keres másik - talán már tényleg transzplantálásra alkalmas - kódokat. Végül pedig meg fogja találni azt az egy vagy több kódot, ami tényleg alkalmas az eredeti helyettesítésére, és annak hibáival sem rendelkezik. Feltéve persze, hogy van ilyen kód a donorok között - mert ha ugye nincs, ő maga nem fogja leszintetizálni.

    Vagy legalábbis nem egészben. Mert ugye elegendően kicsi részfeladatokra bontva a teljeset, és azok mindegyikére ráeresztve ezt az eszközt igazából teljesen újnak tekinthető kódhalmazokat is képes lehet összeeszkábálni máshonnan származó részletekből. Ahogy azt mellesleg egy humán fejlesztői is teszi, aki általában végső soron szintén korábban már millió másik helyen és programban is felhasznált algoritmusok és minták egymáshoz illesztésével és csiszolásával írja meg az úgymond vadi új kódjait, programjait is.
    Mutasd a teljes hozzászólást!
  • Ahhoz, hogy egy ilyen eszköz értelmesen és megbízhatóan müködjön értenie kellene azt a folyamatot amit leprogramoztak. Ehhez olyan MI kellene ami ha megvalósul, bármilyen más munkakör kiváltására is képes (orvos, jogász, történész, matematikus, stb).
    Mutasd a teljes hozzászólást!
  • Érted már, mi a bajom? Munkák szűnnének meg az ilyen szoftverektől. Most még lehet, hogy nagy a kereslet programozói állások terén, de mi lesz 10-20-30 év múlva?

    Ettől, hogy valami másolgat valahonnan nem fog megszűnni semmi, mert alább már erre írtam azt, hogy azt amit másol is valakinek meg kell írnia. Most, hogy itt Magyarországon pályázatokra felveszik a pénzt és a project erejéig felvesznek egy csapatot aztán kidobják és a csapat is megszűnik már meg se említsük, mert nagyon sokszor ilyen is van. Szóval az, hogy üzletileg mi lesz és emiatt milyen munkahely szűnik meg rengeteg más összetevőből áll. Szerintem annyi lesz, hogy pistike gányolja a programot tovább és időnként, ha holnapra kész kell lenni valamivel, akkor beveti a cserélgetős programot és nem virraszt reggelig. Ahol pedig a minőség a lényeg ott marad továbbra is a hagyományos fejelsztés.
    Mutasd a teljes hozzászólást!
  • bocs, nem debug, bugkereső.
    Mutasd a teljes hozzászólást!
  • Mutasd a teljes hozzászólást!
  • A bevétel, igen, ez esetben a munkaadó ellenfele a munkavállaló. Ha egy szoftvertesztelőt leváltanak egy debug-ra hajlamos eszközzel, ami nyilván olcsó mulatság, akkor bekövetkezne az, amit az első hozzászólásomban mondtam.

    Érted már, mi a bajom? Munkák szűnnének meg az ilyen szoftverektől. Most még lehet, hogy nagy a kereslet programozói állások terén, de mi lesz 10-20-30 év múlva? Itt ez a kérdés...
    Mutasd a teljes hozzászólást!
  • A legutóbbi ilyenben az volt, hogy én csak elkezdem beírni a programot, az AI felismeri, hogy mit akarok, és automatikusan befejezi... szóval ez most visszalépés. Persze ez a mostani kezdeményezés is lehetetlen és értelmetlen, de ez nem ellenérv, sőt, a mai világban inkább előny.
    Mutasd a teljes hozzászólást!
  • Ez egy mai jellemzően Java/.NET/Javascript környezetben nem jelent semmit, gyakorlatilag a kód/bináris oda-vissza fordítható.

    BigW: Nagy baj van, pont ezért érne aranyat egy ilyen eszköz. Zömében így dolgoznak pedig a szoftvercégek, hogy csak kész legyen valami és akár évekig/évtizedekig így görgetik a projekteket. Csak a bevétel a lényeg, semmi más.
    Mutasd a teljes hozzászólást!
  • Szerintem ez nem egy általánosan használható hibajavító program (egyelőre), hanem speciális környezetekben (MIT, hadsereg) a hibajavító program működéséhez szükséges nyelv(ek), fordító(k) és sablonok rendszerében képes működni.
    Mutasd a teljes hozzászólást!
  • Tehát nem a forrásszöveget javítja.


    Ez - ha lehet - még rosszabbul hangzik. El tudod képzelni, hogy egy olyan programot debuggolsz, ahol a gépi kód (vagy bytekód) nem következik egyértelműen a forrásból?
    Mutasd a teljes hozzászólást!
  • Egy apró részlet elkerülte  a figyelmeteket:

    méghozzá úgy, hogy ehhez azok forráskódjára sincs szüksége.

    Tehát nem a forrásszöveget javítja.
    Mutasd a teljes hozzászólást!
  • A való világban szükség lehet újraimplementációra jogi okok miatt is, de szerintem ez nem az ideális állapot, hanem egy megoldandó probléma.


    Nem csak jogi okok-ból lehet szükség újraimplementálásra. A teljesség igénye nélkül az alábbi okok jutnak hirtelen eszembe:
    - A meglévő implementáció hatékonysága nem elégséges. (Akár nem triviális, platformfüggő okoknál fogva.)
    - A meglévő implementációból olyan feature-ök hiányoznak, amelyek nehezebben integrálhatók, mint amennyi enerrgiát a teljes újraimplementálás emésztene fel.
    - A meglévő implementáció nem felel meg valamely nem szigorúan vett programozási okból (pl. Nem illeszkedik a cég kódolási sztenderjeihez.) és az újraimplementálás gyorsabb és kényelmesebb megoldás mint a meglévő implementáció refaktorálása.
    - Új technológiai és/vagy tudományos vívmányok megjelenése amelyek gyorsabb teszik a feladat végrehajtását és/vagy olvashatóbbá a forráskódot. (Pl. egy teoretikus fraktális rendezőalgoritmus, ami konstans idő alatt képes rendezni egy listát.)
    Mutasd a teljes hozzászólást!
  • Na most mi a különbség a között, hogy a rosszat átírom jóra, vagy bemásolok egy eleve jót? A végeredmény szempontjából semmi, max. a programozó gyakorlottab lesz tőle, meg legyezgeti kicsit az egóját (az ÉN kódom van ott, nem másnak a kódja).

    Igazából szerintem egy ideális programozó munka az lenne, amikor az ember új problémákkal, új feladatokkal szembesül. Ha valaki már megírta az adott kódrészletet, és az működik, akkor igazából az újból, nulláról megírására már nincs szükség. Kivétel a tanulási céllal történő újraimplementáció, de annak meg nem feltétlen kéne a production kód létrehozásával kapcsolatban lennie.

    (A való világban szükség lehet újraimplementációra jogi okok miatt is, de szerintem ez nem az ideális állapot, hanem egy megoldandó probléma.)
    Mutasd a teljes hozzászólást!
abcd