Slo-Tech - Eden najstarejših in najrobustnejših programskih jezikov, ki še danes poganja na tisoče produkcijskih sistemov, je COBOL. Jezik je bil dovolj zgoden in zmogljiv, da se je trdno zasidral zlasti v banke in podobne inštitucije, sedaj pa ga je zob časa že pošteno načel. A jezik se je ohranil dlje kot večina njegovih avtorjev in programerjev, zato imajo danes podjetja velikanske težave z vzdrževanjem. Strokovnjakov je malo, njihove cene pa zasoljene. Koda se krpa, dokler je to možno, a dolgoročno bi jo želeli migrirati na kaj modernejšega, recimo Javo. IBM se je odločil problem napasti z umetno inteligenco. Proti koncu letošnjega leta bo dostopenwatsonx Code Assistant for Z, ki bo namenjen migraciji COBOL-ove kode na mainfraimih Z na Javo. Ocenjujejo, da po svetu teče še okrog 800 milijard vrstic kode v COBOL-u. Novi Watsonov pomočnik bo pomagal pri njeni migraciji, česar ne bo zmogel sam brez človeškega nadzora, bo pa bistveno pospešil postopek. Nova koda bo objektno orientirana in bo interoperabilna s preostalo COBOL-ovo kodo.
O kakovosti kode bomo lahko presojali, ko bo orodje na voljo. Nekatere raziskave kažejo, da programerji z uporabo orodij umetne inteligence pišejo manj varno kodo. IBM je svoj watsonx.ai natreniral na 115 jezikih in je pravi poliglot. Videli pa bomo, kako natančen je.
Bravo iz enega zastarelega jezika bojo skonvertirali v drug že skoraj zastarel jezik.
S tem, da iz Cobola mogoče AI še spravi v Javo, iz Jave pa je ne bo nihče več nikoli spravil v kaj modernejšega.
Na factorijih factory factoryov in kilometrih boilerplata se še za silo mentalno zdravi osebi začne blest, če na taka jajca naženeš AI bo najprej sebe restrukturiral do samozavedanja, pobil človeštvo in si rekel "Te so bili zmešani, delo opravljeno."
Dobro no sej Java je zastarela ampak še vedno bo lažje potem preptvorit v karkoli. Še vedno se je vsaj ena generacija na Javi učila programirat, vsaj v Slo :)
Jasno, da je AI supported koda manj varna, ker po liniji najmanjšega odpora samo kopira vrstice, in če dela, dela. Gremo naprej. Isti štos je kot za reči iz githuba. Če dela, dela. Ne sprašuj se preveč.
Lažje je v .Net pretvorit, ampak pri IBM imajo raje javo.
Pa saj so že imeli nekoč podobne ideje in so imeli orodja, da je samo pisalo kodo, ti si moral samo specificirat določene stvari. Pa se ni izšlo, ker je bilo kar nekaj nakvačkano skupaj. Tako kot bo tukaj.
Milčinski je napisal butalce kot prispodobo in ne kot priročnik!!!
Svuda u svijetu ima budala ali je izgleda kod nas centrala!!!
Še vedno se je vsaj ena generacija na Javi učila programirat, vsaj v Slo :)
Naučila se je komplicirat, ne programirat, kar je tudi sicer rak-rana celotnega javanskega ekosistema. Več kot je boilerplata večji car si in bolj kot je koda narejena za popolnoma specializiran task, ki ga rešiš enkrat in nikoli več, bolj reusable jo bojo naredili, pa še kakšen generator zraven, da bo žur večji. Vsakdo, ki pa jo bo podedoval, bo potem za spreminjanje minornih detajlov porabil 5x več časa, kot če bi jo spisal na novo. Kar pa ne sme narediti, zaradi pedigreeja. Na koncu dobiš akademske-ravioli-špageti-lazanje. Zavozlano in zainterfejsano.
In, ko dobiš takega v projekt, ki uporablja kakšen drug jezik, ga bo probal prilogoditi, da bo lahko spet interfacal, factoryal in boilerplatal. Za bruhat.
Jasno, da je AI supported koda manj varna, ker po liniji najmanjšega odpora samo kopira vrstice, in če dela, dela. Gremo naprej. Isti štos je kot za reči iz githuba. Če dela, dela. Ne sprašuj se preveč.
Ne? Če imaš v podjetju code review proces, veš katero kodo se daleč najbolj splača reviewat? 3rd party.
Za lokalno spisano kodo imaš ob sebi verjetno avtorja ali pa, če ti je pobegnil, vsaj nekoga, ki nekaj ve o njej. Za 3rd party dependancie je nujno, da to znanje pridobiš, sploh, če je zadeva nekaj obskurnega. Pač boost ne boš šel reviewat pa stl tudi ne, ker boš prebil naslednjih 20 let ob njem. Neko potencialno sranje iz githuba... JA SEVEDA, NUJNO!
Seveda, se ne bom slepil, da to kdorkoli, ki flika lastno neznanje (ne leti nate) z downloadanjem nečesa iz interneta, velja. Zato pa je ves software piece of shit.
Neki se pizdite cez Javo, ampak nihce pa ne razume da je to stratesko popolnoma neumen projekt.
Celoten razlog zakaj teh stvari niso prepisali v kak drug jezik, celoten claim to fame od Cobola, je da je nemogoce to prepisat brez napak, in to so oh in sploh najbolj pomembni sistemi (lol), in da je povsem nesprejemljivo, da bi v Javo prepisana koda imela kako napako.
Seveda ta idiotski projekt se v tem smislu povsem nic ne razlikuje cloveskega prepisovanja v Javo, samo cenejsi bo. AI bo naredil ravno enako stevilo lukenj, saj gre za stohasticen proces napovedovanja naslednjega znaka.
In v vsaki stari kodi so kaki koscki ki so ostanki od kakih zacasnih resitev in podobno in te bo AI veselo prepisal.
Te Cobol aplikacije bi ze davno morali na novo sprogramirati iz nule.
Celoten razlog zakaj teh stvari niso prepisali v kak drug jezik, celoten claim to fame od Cobola, je da je nemogoce to prepisat brez napak
Da. To je osnovni razlog, zakaj Cobol koda danes še obstaja. Način operacij s plavajočo vejico je nezdružljiv z drugimi jeziki (in deluje odlično, da ne bo pomote). So bili poizkusi, da bi se naredilo php/python/java knjiznice, ki simulirajo način delovanja ampak hudič je v podrobnostih.
Če ni način zaokroževanja identičen, v nulo, potem bankam ne štimajo poslovne knjige, ki so jih zakonodajno zahtevano prisiljeno voditi. Ni šans, da bo rezultat v X jeziku kakorkoli drugačen kot je bil prej v Cobolu. In to se je izkazalo, za tako velik problem, da se bolj splača vzdrževati cobol (zaradi managmenta in njihovih nagrad za letni revenue), kot investirati ogromno denarja in simulirati cobol "v nulo".
Celoten razlog zakaj teh stvari niso prepisali v kak drug jezik, celoten claim to fame od Cobola, je da je nemogoce to prepisat brez napak
Da. To je osnovni razlog, zakaj Cobol koda danes še obstaja. Način operacij s plavajočo vejico je nezdružljiv z drugimi jeziki (in deluje odlično, da ne bo pomote). So bili poizkusi, da bi se naredilo php/python/java knjiznice, ki simulirajo način delovanja ampak hudič je v podrobnostih.
Če ni način zaokroževanja identičen, v nulo, potem bankam ne štimajo poslovne knjige, ki so jih zakonodajno zahtevano prisiljeno voditi. Ni šans, da bo rezultat v X jeziku kakorkoli drugačen kot je bil prej v Cobolu. In to se je izkazalo, za tako velik problem, da se bolj splača vzdrževati cobol (zaradi managmenta in njihovih nagrad za letni revenue), kot investirati ogromno denarja in simulirati cobol "v nulo".
To kar pises gotovo ne more biti res: 1. Vsako operacijo s floating pointi lahko emuliras v kateremkoli jeziku, potem pac v kodi ne uporabljas vgrajenih operaterjev kot so * / itd ampak posebne funkcije. To je trivialno. Isto je z zaokrozevanjem, trivialno resljiv problem. 2. Ce bi bilo res kar pravis, potem IBM ne bi prepisoval kode v Javo, saj ti trdis, da je to v osnovi obsojeno na propad zaradi floating point operacij
Poleg tega ni nobenega razloga, zakaj bi moral program uporabljati ravno Cobolovo logiko. Lepo se napise program iz nule, zaokrozevanje je pa definirano glede na domeno (torej kakor banke hocejo). Verjetno hocejo even-up zaokrozevanje, trivialno za to zrihtat.
Eni še kar v cobolu pišemo zadeve. Pa so nam probal vsilit generator cobola, pa razne transformerje, ampak nič ne dela tako kot če napišeš program sam in ga še fajn optimiziraš.
Milčinski je napisal butalce kot prispodobo in ne kot priročnik!!!
Svuda u svijetu ima budala ali je izgleda kod nas centrala!!!
Jaz tudi dvomim v to magičnost Cobola. Dokler ne vidim kakšnega bolj resnega problema od zaokroževanja, ne morem verjeti, da obstaja tak problem. Tako da prosim na plan z dejanskim konkretnim problemom, pa da najdemo rešitev.
Ni nobene magičnosti. Dokler je ceneje vzdrževati, kot pa prepisat vse v drugio kodo, bodo tako delali. Problem je tudi ker programerjev v cobolu počasi zmanjkuje.
Milčinski je napisal butalce kot prispodobo in ne kot priročnik!!!
Svuda u svijetu ima budala ali je izgleda kod nas centrala!!!
Jaz tudi dvomim v to magičnost Cobola. Dokler ne vidim kakšnega bolj resnega problema od zaokroževanja, ne morem verjeti, da obstaja tak problem. Tako da prosim na plan z dejanskim konkretnim problemom, pa da najdemo rešitev.
Saj ni samo magičnost Cobola. Je tudi magičnost mašin. Pazi, zadaj je za miljarde posla, prepričan sem, da jih boš ti dobil, ker vsem ostalim smrdijo. Saj ni problema, samo ušteti se ne smeš niti za miljardinko. Tako preprosto je, da do danes cel svet še ni iznašel alternative, go for it. Misliti si ne moreš, kako nepopisno boš bogat.
Jaz tudi dvomim v to magičnost Cobola. Dokler ne vidim kakšnega bolj resnega problema od zaokroževanja, ne morem verjeti, da obstaja tak problem. Tako da prosim na plan z dejanskim konkretnim problemom, pa da najdemo rešitev.
Saj ni samo magičnost Cobola. Je tudi magičnost mašin. Pazi, zadaj je za miljarde posla, prepričan sem, da jih boš ti dobil, ker vsem ostalim smrdijo. Saj ni problema, samo ušteti se ne smeš niti za miljardinko. Tako preprosto je, da do danes cel svet še ni iznašel alternative, go for it.
Sej v to dvomim, da neka java ali katerikoli drugi programski jezik ni dovolj dober za ozračune v milijardinkah. Moraš mi pokazati primer izračuna, ki ga Cobol izračuna po tvoje natančno, nek drug programski jezik pa ne. Ker jaz temu ne morem verjet.
Jaz tudi dvomim v to magičnost Cobola. Dokler ne vidim kakšnega bolj resnega problema od zaokroževanja, ne morem verjeti, da obstaja tak problem. Tako da prosim na plan z dejanskim konkretnim problemom, pa da najdemo rešitev.
Saj ni samo magičnost Cobola. Je tudi magičnost mašin. Pazi, zadaj je za miljarde posla, prepričan sem, da jih boš ti dobil, ker vsem ostalim smrdijo. Saj ni problema, samo ušteti se ne smeš niti za miljardinko. Tako preprosto je, da do danes cel svet še ni iznašel alternative, go for it.
Sej v to dvomim, da neka java ali katerikoli drugi programski jezik ni dovolj dober za ozračune v milijardinkah. Moraš mi pokazati primer izračuna, ki ga Cobol izračuna po tvoje natančno, nek drug programski jezik pa ne. Ker jaz temu ne morem verjet.
Ja, saj imaš na wikipediji, cel svet jo bere, alternative še vedno ni. Go for it. COBOL @ Wikipedia
Vse kar rabiš je, da so prejšnji izračunu 100% komaptibilni s tvojimi. Samo to. Ne 99.9999999999999%. 100%. Mala malca.
Jaz tudi dvomim v to magičnost Cobola. Dokler ne vidim kakšnega bolj resnega problema od zaokroževanja, ne morem verjeti, da obstaja tak problem. Tako da prosim na plan z dejanskim konkretnim problemom, pa da najdemo rešitev.
Saj ni samo magičnost Cobola. Je tudi magičnost mašin. Pazi, zadaj je za miljarde posla, prepričan sem, da jih boš ti dobil, ker vsem ostalim smrdijo. Saj ni problema, samo ušteti se ne smeš niti za miljardinko. Tako preprosto je, da do danes cel svet še ni iznašel alternative, go for it. Misliti si ne moreš, kako nepopisno boš bogat.
Le kako obstajajo banke, ki zadaj nimajo COBOL-a???
Banka ima SW stack napisan v Javi, ki teče (je teklo?) na SPACR + Solaris. Vprašanje pa ali je SPARC + Solaris še aktualno ali je to sedaj že x86 + Linux. To pa nevem, ker nimam več opravka z njimi.
Jaz tudi dvomim v to magičnost Cobola. Dokler ne vidim kakšnega bolj resnega problema od zaokroževanja, ne morem verjeti, da obstaja tak problem. Tako da prosim na plan z dejanskim konkretnim problemom, pa da najdemo rešitev.
Saj ni samo magičnost Cobola. Je tudi magičnost mašin. Pazi, zadaj je za miljarde posla, prepričan sem, da jih boš ti dobil, ker vsem ostalim smrdijo. Saj ni problema, samo ušteti se ne smeš niti za miljardinko. Tako preprosto je, da do danes cel svet še ni iznašel alternative, go for it.
Sej v to dvomim, da neka java ali katerikoli drugi programski jezik ni dovolj dober za ozračune v milijardinkah. Moraš mi pokazati primer izračuna, ki ga Cobol izračuna po tvoje natančno, nek drug programski jezik pa ne. Ker jaz temu ne morem verjet.
Ja, saj imaš na wikipediji, cel svet jo bere, alternative še vedno ni. Go for it. COBOL @ Wikipedia
Vse kar rabiš je, da so prejšnji izračunu 100% komaptibilni s tvojimi. Samo to. Ne 99.9999999999999%. 100%. Mala malca.
ne pravim daje mala malca, želel sem konkretno pojasnitev, zakaj do tega prihaja s kakšnim konkretnim primerom, pa tega ne dobim, grem brat, mogoče je kaj na netu, ampak dvomim
evo mi je pomagal chatgpt, za tiste ki jih vsaj malo zanima..
Tu je nekaj ključnih vidikov stroge številčnosti v COBOLu:
Decimalno aritmetično natančnost: COBOL omogoča izvajanje aritmetičnih operacij na decimalnih številih z visoko natančnostjo. To je pomembno pri izračunih finančnih zneskov, kjer je zaželeno, da se izognemo zaokroževalnim napakam, ki bi lahko vplivale na natančnost rezultatov.
Nadzor nad decimalnimi vejicami: COBOL omogoča natančen nadzor nad pozicijami decimalnih vejic v številih. To je zelo pomembno pri obdelavi denarnih zneskov, kjer je običajno potrebno slediti posebnim standardom za poravnavo decimalnih vejic.
Nadzor nad formati števil: COBOL omogoča določitev posebnih formatov za prikaz števil, vključno z uporabo ločilcev tisočic, desetin in drugega oblikovanja. To je pomembno pri prikazu finančnih zneskov v poročilih in izpisih.
Preprečevanje napak pri zaokroževanju: COBOL ima mehanizme za preprečevanje napak pri zaokroževanju številk. To je ključno pri izračunih obresti in drugih finančnih operacijah, kjer se zahteva doslednost in natančnost.
Podpora za numerične formate: COBOL omogoča delo z različnimi numeričnimi formati, vključno s fiksnimi in plavajočimi vejicami. To omogoča obdelavo različnih vrst številčnih podatkov, kot so celoštevilski zneski, decimalna števila in znanstveni zapis.
Strogo številčnost, ki jo omogoča COBOL, bi se teoretično dala prevesti v druge jezike, vključno z Javo, vendar pa bi bil ta prehod lahko precej kompleksen in bi zahteval precej prilagoditev in premisleka. Obstaja več izzivov, s katerimi bi se srečali pri prenosu stroge številčnosti COBOLa v druge jezike:
Decimalna natančnost: COBOL omogoča visoko natančnost pri decimalnih izračunih, medtem ko mnogi drugi jeziki, vključno z Javo, uporabljajo standardne dvojne plavajoče vejice za obdelavo števil. Ta razlika v predstavitvi in obdelavi decimalnih števil bi zahtevala posebno pozornost pri prenosu, da bi se ohranila enaka natančnost.
Zaokroževanje in formati: COBOL omogoča natančen nadzor nad zaokroževanjem in formatiranjem številk, kar ni vedno enostavno dosegljivo v drugih jezikih. Pri prenosu bi bilo treba razmisliti o tem, kako ohraniti enake zaokroževalne prakse in oblikovanje številk.
Biblioteke in funkcionalnosti: COBOL pogosto vključuje specifične knjižnice in funkcionalnosti za finančne izračune. Pri prenosu bi bilo treba poiskati ustrezne knjižnice ali razviti nove funkcionalnosti v ciljnem jeziku.
Natančnost pri obdelavi: Prehod iz COBOLa v drug jezik bi zahteval natančen pregled obstoječih aplikacij, da se zagotovi, da se vsi izračuni pravilno prevedejo in da se ohrani enaka natančnost pri obdelavi podatkov.
Obvladovanje napak in zaokroževanj: Pri prehodu bi bilo treba natančno preučiti, kako se ravna z napakami pri zaokroževanju in druge napake v izračunih, da se zagotovi doslednost z obstoječimi COBOL aplikacijami.
Prenos stroge številčnosti COBOLa v druge jezike bi zahteval skrbno načrtovanje, prilagoditve in testiranje, da bi se zagotovila enaka natančnost in doslednost pri obdelavi številk. Pri tem bi bilo treba sodelovati s strokovnjaki za obe platformi (COBOL in ciljni jezik), da bi preprečili morebitne napake ali neustrezno obdelavo podatkov.
Pogledal wiki članek, nič posebaj ne omenja načina računanja z decimalnimi števili ?
Predvidevam da ni po standardu IEEE 754, ampak to ne pomeni da tega istega načina decimalnih števil ne gre uspešno implementirati v drugih jezikih. V končni fazi mora cobol ta svoj standard za plavajoča števila softwersko implementirati na x86, ker x86 ima native float opercije po IEEE 754 standardu. In če ima COBOL to drugače mora to imet implementirano v HW.
kot jaz to razumem, bi se vse dalo, samo se zaradi stroškov temu izogibajo, ker je vzdrževanje "zaenkrat" še cenejše, niso pa drugi jeziki omejeniv tem smislu, da se nebi dalo stvari prepisat v njih
Strogo številčnost, ki jo omogoča COBOL, bi se teoretično dala prevesti v druge jezike, vključno z Javo, vendar pa bi bil ta prehod lahko precej kompleksen in bi zahteval precej prilagoditev in premisleka. Obstaja več izzivov, s katerimi bi se srečali pri prenosu stroge številčnosti COBOLa v druge jezike:
Decimalna natančnost: COBOL omogoča visoko natančnost pri decimalnih izračunih, medtem ko mnogi drugi jeziki, vključno z Javo, uporabljajo standardne dvojne plavajoče vejice za obdelavo števil. Ta razlika v predstavitvi in obdelavi decimalnih števil bi zahtevala posebno pozornost pri prenosu, da bi se ohranila enaka natančnost.
Zaokroževanje in formati: COBOL omogoča natančen nadzor nad zaokroževanjem in formatiranjem številk, kar ni vedno enostavno dosegljivo v drugih jezikih. Pri prenosu bi bilo treba razmisliti o tem, kako ohraniti enake zaokroževalne prakse in oblikovanje številk.
Biblioteke in funkcionalnosti: COBOL pogosto vključuje specifične knjižnice in funkcionalnosti za finančne izračune. Pri prenosu bi bilo treba poiskati ustrezne knjižnice ali razviti nove funkcionalnosti v ciljnem jeziku.
Natančnost pri obdelavi: Prehod iz COBOLa v drug jezik bi zahteval natančen pregled obstoječih aplikacij, da se zagotovi, da se vsi izračuni pravilno prevedejo in da se ohrani enaka natančnost pri obdelavi podatkov.
Obvladovanje napak in zaokroževanj: Pri prehodu bi bilo treba natančno preučiti, kako se ravna z napakami pri zaokroževanju in druge napake v izračunih, da se zagotovi doslednost z obstoječimi COBOL aplikacijami.
Prenos stroge številčnosti COBOLa v druge jezike bi zahteval skrbno načrtovanje, prilagoditve in testiranje, da bi se zagotovila enaka natančnost in doslednost pri obdelavi številk. Pri tem bi bilo treba sodelovati s strokovnjaki za obe platformi (COBOL in ciljni jezik), da bi preprečili morebitne napake ali neustrezno obdelavo podatkov.
COBOL mora imeti to strogo številčnost implementirano v prevajalniku oz. runtime knjižicah, ker večina procesorjev dela po standardu IEEE 754. Torej če so to implementirali za COBOL, lahko implementirajo tudi za druge jezike. Java ima že sama nekaj podobnega, podatkovni tip DECIMAL.
P.S. Pa preden me napade kak COBOL fanatik, ne pravim da je smiselno prepisovat cobol kodo v javo. Samo pravim, da ni ničesar magičnega okoli cobola in decimalnih števil.
kot jaz to razumem, bi se vse dalo, samo se zaradi stroškov temu izogibajo, ker je vzdrževanje "zaenkrat" še cenejše, niso pa drugi jeziki omejeniv tem smislu, da se nebi dalo stvari prepisat v njih
Jaz tudi dvomim v to magičnost Cobola. Dokler ne vidim kakšnega bolj resnega problema od zaokroževanja, ne morem verjeti, da obstaja tak problem. Tako da prosim na plan z dejanskim konkretnim problemom, pa da najdemo rešitev.
Saj ni samo magičnost Cobola. Je tudi magičnost mašin. Pazi, zadaj je za miljarde posla, prepričan sem, da jih boš ti dobil, ker vsem ostalim smrdijo. Saj ni problema, samo ušteti se ne smeš niti za miljardinko. Tako preprosto je, da do danes cel svet še ni iznašel alternative, go for it. Misliti si ne moreš, kako nepopisno boš bogat.
Le kako obstajajo banke, ki zadaj nimajo COBOL-a???
Banka ima SW stack napisan v Javi, ki teče (je teklo?) na SPACR + Solaris. Vprašanje pa ali je SPARC + Solaris še aktualno ali je to sedaj že x86 + Linux. To pa nevem, ker nimam več opravka z njimi.
Pa AIX na POWER. Še vedno IMB ampak daleč od Z mainframe-ov.
Ja tudi meni se on chatGPT opis ne zdi nič drugega kot decimal tip - lahko pa da se motim in da obstajajo primeri, kjer decimal ne zna pravilno delat (čeprav mislim, da ni tega).
Ce za nasvete o Cobolu sprasujete ChatGPT, potem verjetno niste kompetentni, da bi presojali kako enostavno je nekaj portati iz Cobola v Javo. Kaj sele, da bi presojali kaj se bankam izplaca in kaj ne.
Kaj so sploh tisti razlogi, da bi radi šli stran od COBOLa? Porabi 2x več računske moči? Rabijo posebne custom čipe za ga poganjat? Al samo nočejo več plačevat programerjev in mislijo da če gredo na 'shiny new thing', bodo lahko plačali par študentov z 'izkušnjami', da jim bodo programirali?
Uf! Uf! Je rekel Vinetou in se skril za skalo,
ki jo je prav v ta namen nosil s seboj.
Kaj so sploh tisti razlogi, da bi radi šli stran od COBOLa? Porabi 2x več računske moči? Rabijo posebne custom čipe za ga poganjat? Al samo nočejo več plačevat programerjev in mislijo da če gredo na 'shiny new thing', bodo lahko plačali par študentov z 'izkušnjami', da jim bodo programirali?
Predvsem to zadnje. Pa skrb da čez X let ne bo sploh nikogar ki bi znal cobol oz. se ga bi bil pripravljen naučit.
Tako dobro so plačani, pa nobenega ki bi se bil pripravljen priučit? Does not compute :).
Pomoje je problem v bankah samih. Podobno kot pa pred kratkim, ko se niso strinjali, da bi dali pol milijarde za pomoč ljudem, ki so jih prizadele poplave. Po moje sploh nočejo plačevat te cobol programerje ustrezno in pošteno.
Sicer pa, katere banke pa še uporablajo cobol? Na googlu berem, da je cobol osnova za 43% bančnih transakcij. Se pravi manj kot pol :).
Evo scenarij: 1. nekako se bo počasi migriralo v javo (z a.i. ali brez) 2. v nekem trenutku bo prišlo do spora z Oraclom 3. pospešeno pisanje programov na novo v nekem drugem jeziku, mogoče celo nazaj v cobol
(ta scenarij je dal skozi že SAP pred leti)
"If we were supposed to talk more than listen
we would have been given two mouths and one ear"
- Mark Twain
Evo scenarij: 1. nekako se bo počasi migriralo v javo (z a.i. ali brez) 2. v nekem trenutku bo prišlo do spora z Oraclom 3. pospešeno pisanje programov na novo v nekem drugem jeziku, mogoče celo nazaj v cobol
Očitno bankirji vedo za korak 2 in 3, pa zato ostajajo na Cobolu.
Milčinski je napisal butalce kot prispodobo in ne kot priročnik!!!
Svuda u svijetu ima budala ali je izgleda kod nas centrala!!!
ne pravim daje mala malca, želel sem konkretno pojasnitev, zakaj do tega prihaja s kakšnim konkretnim primerom, pa tega ne dobim, grem brat, mogoče je kaj na netu, ampak dvomim
evo mi je pomagal chatgpt, za tiste ki jih vsaj malo zanima..
Tu je nekaj ključnih vidikov stroge številčnosti v COBOLu:
Decimalno aritmetično natančnost: COBOL omogoča izvajanje aritmetičnih operacij na decimalnih številih z visoko natančnostjo. To je pomembno pri izračunih finančnih zneskov, kjer je zaželeno, da se izognemo zaokroževalnim napakam, ki bi lahko vplivale na natančnost rezultatov.
To zna vsak jezik ki ni totalen shit (JavaScript). Pac uporabis java.math.BigDecimal.
Nadzor nad decimalnimi vejicami: COBOL omogoča natančen nadzor nad pozicijami decimalnih vejic v številih. To je zelo pomembno pri obdelavi denarnih zneskov, kjer je običajno potrebno slediti posebnim standardom za poravnavo decimalnih vejic.
Nadzor nad formati števil: COBOL omogoča določitev posebnih formatov za prikaz števil, vključno z uporabo ločilcev tisočic, desetin in drugega oblikovanja. To je pomembno pri prikazu finančnih zneskov v poročilih in izpisih.
Preprečevanje napak pri zaokroževanju: COBOL ima mehanizme za preprečevanje napak pri zaokroževanju številk. To je ključno pri izračunih obresti in drugih finančnih operacijah, kjer se zahteva doslednost in natančnost.
Podpora za numerične formate: COBOL omogoča delo z različnimi numeričnimi formati, vključno s fiksnimi in plavajočimi vejicami. To omogoča obdelavo različnih vrst številčnih podatkov, kot so celoštevilski zneski, decimalna števila in znanstveni zapis.
To zna spet vsak sodoben jezik.
Radi bi nas preprical da so 60 let nazaj izumili nekaj neponovljivega. I don't buy that. Lahko pa kdorkoli izvoli podati kake primere izracunov ali izpisov, ki jih v drugih jezikih ne moremo delat, se vedno cakamo na konkretne primere.
"Eden najstarejših in najrobustnejših programskih jezikov, " Robusten jezik menjavat za Javo je vprašljivo. Vsaj jz ne vidim Jave kot robustnega jezika?
Ahm... Sem delal revizijo računovodskega programa, ki je na 12 decimalk računal. Ali pa 8, nima veze. Pri milijonih knjižb podatki niso skupaj zlezli nikakor. Decimalke v financah so na koncu stotini. S tako natanćostjo gre v knjige. Problem je v tem, da knjigovodskega stanja ne moreš (ali pa si glup) na več kot toliko decimalk zapisovati, kot jo monetarna valuta pozna. Če izračuna strošek (ker imamo decimalke na decimalke, kajne) 0,00356 EUR, je to pač 0,01 EUR. In v tretje bo pa 0 EUR. (no, glih ne bo, ker bo kje pri večji količini tisti cent napraskalo). Programerji niso računovodje in nimajo pojma, kako je prav. Na srečo se najde kdaj kak pameten računo/knjigovodja, ki dopove programerju, kako mora vse skupaj delati.
Pa saj še zdaj Mercatorji in Merkurji, tudi T2, ne znajo prav sestaviti računa in specifikacije DDV. Ja, za tri artikle še prav izpade, imaš pa primere, ki je lahko razlike skoraj evro. Ali pa FURS, ki obračuna dohodnino po lestvicah na (12?) decimalko natačno, potem pa nazaj(!) preračuna procente (?) dohodnine in iz tega izračuna še enkrat znesek. Itak da je zastriglo za en cent. In seveda sem pisal pritožbo. In seveda nisem dobil pametnega odgovora. In že tretje leto še vedno narobe izdajajo odločbe. Najbrž so to prišli seniorji iz COBOL sveta povedat, kako je prav. Ker COBOL zna izpise delati. Seveda jih je znal, ker je izpisane cifre stackal, da jih je potem nazaj nekam zapisal. Ker so programerji točno to delali. Cel izračun je vrgel v "izpis" temeljnice, od koder jo je nazaj prebral. In morda je bilo to še best practice, glede na zdajšnje "rešitve". Na fakin dve decimalki banke laufajo. Pri kreditih pa dvanajsta decimalka pri obroku ne pomeni prav nič. Pa če je to bilijon. Ja, sem imel stranko, ki je želela imeti do zadnje podložke (tisoč jih je vrednih pol centa) natančno vodenje stroška. Na pet decimalk je bila na koncu zahteva. Nastal je problem, ko tega mikroskopskega sveta enostavno ni dojela. Kje zaokroči navzgor, pa navzdol, pa zakaj... Ure pregovarjanj. Zaradi 10 EUR stroška v celem letu. Kot da bi centimetre selotejpa pri pakrianju obračunaval.
Eh na koncu bo ai povedala, da naj uporabljajo lasten tip za števila, ki pri konverziji V pomnoži z veliko konstanto, pri konverziji IZ pa deli z isto konstanto?
Kolkr jaz razumem problem bančništva je, da imaš na primer milijardo transakcij, na vsako obešene neke procente, na vsako se nekaj zaokroži, input in output morata bit na tisti dve decimalki enaka, ampak če zaokroževanje ni dobro narejeno, ti to striže in naenkrat imaš evre, ki so prišli 'iz zraka'.
Uf! Uf! Je rekel Vinetou in se skril za skalo,
ki jo je prav v ta namen nosil s seboj.
Do prve velike pi*da*ije, ko bo spet kakšna banka slab mesec stala. No, potem pa ne bo več AI to delal.