Jako dziadek grzebiący kiedyś w asemblerze na zx80 pod cpm, a od dawna w C/C++/Javie, rzuciłem okiem na tutorial Kotlina 2.0, co trwało jakieś pół godziny, więc moja opinia jest absolutnie powierzchowna.
Widzę, że ten kto projektował Kotlina bardzo lubił kiedyś koncepcję Niklausa Wirtha i jego Pascala bo składnia Kotlina, to najkrócej ujmując (i bez znajomości bibliotek) koncepcja Javy ze składnią Pascala plus składnia lambd. Wygląda to dla mnie ciekawie. Dziwną rzeczą jest dla mnie przywrócenie liczbowych typów unsigned w języku z którego wyrzucono typy proste. Może mi ktoś wyjaśnić sens tego podejścia? Oszczędność jednego bita w języku, w którym wszystko przydzielane jest przez stertę, a najmniejszy przydział, to 8 lub 16 bajtów dla każdego obiektu?
Olamagato napisał(a):
Jako dziadek grzebiący kiedyś w asemblerze na zx80 pod cpm, a od dawna w C/C++/Javie, rzuciłem okiem na tutorial Kotlina 2.0, co trwało jakieś pół godziny, więc moja opinia jest absolutnie powierzchowna.
Widzę, że ten kto projektował Kotlina bardzo lubił kiedyś koncepcję Niklausa Wirtha i jego Pascala bo składnia Kotlina, to najkrócej ujmując (i bez znajomości bibliotek) koncepcja Javy ze składnią Pascala plus składnia lambd. Wygląda to dla mnie ciekawie. Dziwną rzeczą jest dla mnie przywrócenie liczbowych typów unsigned w języku z którego wyrzucono typy proste. Może mi ktoś wyjaśnić sens tego podejścia? Oszczędność jednego bita w języku, w którym wszystko przydzielane jest przez stertę, a najmniejszy przydział, to 8 lub 16 bajtów dla każdego obiektu?
Typy unsigned nie są wprowadzone z powodu oszczędności miejsca, ale z powodu poprawności. (MYLIŁEM się -> patrz dyskusja poniżej)
Gdybyś np. chciał zrobić, tak że nie można mieć ujemnego wzrostu.
Kotlin się mocno różni od javy - nie jest to java ze składnią pascala. Ma choćby takie rzeczy jak natywny typ funkcyjny (X->Y), lambda receivers i inaczej działają generyki (declaration site variance) - nie da się tego prosto przełożyć (mimo, że niby IntelliJ ma taką opcję -ale to dekompresja stratna). To zupełnie inny język - wiecej ma wspólnego ze Scalą, a jedynie jest tak zaimplementowany, żeby współpraca z javą była w miarę prosta i efektywna (przy czym jak kompilujesz kotlina do native albo do JS to i tak się nie uda).
Nawet w javie nie wszystko jest faktycznie alokowane na stercie z punktu widzenia programisty to sterta, z punktu widzenie faktyczniej implementacji to kwestia "optymalizatora". W kotilnie może i w języku nie masz typów prostych, ale normalnie już na poziomie bytecode masz. JIT robi kolejne optymalizacje, choć akurat w typach prostych to niewiele może. Potrafi natomiast obiekty prostych klas umieścić w całości w rejestrach i na stosie - zamiast faktycznie coś alokować na stercie - normalka.
Świat poszedł mocno do przosu od czasów z80 i nawet x86 - myślenie asemblerem się nie sprawdza, często prowadzi do niepotrzebnie skomplikowanego kodu, a czasem nawet do mniej wydajnego.
jarekr000000 napisał(a):
Typy unsigned nie są wprowadzone z powodu oszczędności miejsca, ale z powodu poprawności.
Gdybyś np. chciał zrobić, tak że nie można mieć ujemnego wzrostu.
Mógłbyś podać źródło tej informacji?
And, Or, Xor, Not i shift left działa tak samo na int co unsigned int.
Shift right - jedyna różnica w Java nie ma znaczenia bo są 2 operatory >>> i >>.
O poprawności tutaj nie może być mowy bo int to 4B, czyli wzorzec bitowy. Nie jest walidowany w żaden sposób. Wzrost 0 cm też nie ma sensu.
Jako że podział na signed/unsigned występował już w starym C, należy się spodziewać że chodziło po prostu o oszczędność pamięci. Jeżeli liczba była z przedziału 0 - 64k to miejściła się w unsigned short a więc można było zaoszczędzić 2B (vs 4B gdy użyjemy int'a).
Z pewnością dla pewnych wartości jak rozmiar (size_t) typy unsigned mają większy sens. Niemniej znów - jakby nikomu nie zależało na pamięci można by użyć po prostu long long i dodatkowo mieć wartość -1 na błędy typu ERR_INVALID_SIZE.
Na koniec pewnie są też architektury komputerów gdzie obliczenia na singed/unsigned trwały inne ilości cykli (czy raczej były takie w latach 70s).
Cały podział pochodzi więc z ery gdzie każdy bit miał znaczenie, a różnych architektur CPU było od groma. Zapewne miało to wtedy głęboki sens.
Może mi ktoś wyjaśnić sens tego podejścia?
https://kotlinlang.org/docs/unsigned-integer-types.html#use-cases
bo składnia Kotlina, to najkrócej ujmując (i bez znajomości bibliotek) koncepcja Javy ze składnią Pascala
Serio? No to faktycznie jedynie, co mozna o tej opinii powiedziec, to "powierzchowna". Chociaz jak dla mnie, nawet powierzchownie, to z Pascalem nie ma nic wspolnego. Musisz chyba bardziej sie zaglebic
Riddle napisał(a):
Mógłbyś podać źródło tej informacji?
Ewidentnie się myliłem.
Wyciągnąłem wnioski z innych języków - a faktycznie jak wskazuje link od @stevens
https://kotlinlang.org/docs/unsigned-integer-types.html#use-cases
jednak poprawność nie była celem :-(
Odpowiadając na główne pytanie - bo Java to hegemon działający na 8kkkk urządzeń a Kotlin to ciekawostka i zabawka dla ex programistów JS
Niewygodna prawda jest taka ze po prostu java jest lepsza. Łatwiej w niej znalezc pracownika do tego jest uniwersalna więc nie ma problemu z przechodzeniem miedzy zespołami jeśli jest taka potrzeba. Jest dostatecznie czytelna, pozwala na duża elastyczność itd.
Mam doczynienia z java od wersji chyba 1.0 ale ostatnio bawiłem się kotlin multiplaform i powiem że tylko z powodu tego powodu że po bożemu potraktowano problem nulla mógłbym się przesiąść. Nie cierpię tej protezy w postaci Optional. Ale ofert pracy jak na lekarstwo i robi się zamknięte koło
Bo java jest dużo prostsza.
W projekcie mieliśmy jeden mikroserwis napisany w kotlinie, okazało się że kotlina znała tylko jedna osoba z javowców i po jej odejściu drapali się po głowach i nie potrafili nic tam zmodyfikować. Ostatecznie przepisali na javę.
undsame napisał(a):
Mam doczynienia z java od wersji chyba 1.0
Moim zdaniem wycierpiałeś już wystarczająco.
stivens napisał(a):
Serio? No to faktycznie jedynie, co mozna o tej opinii powiedziec, to "powierzchowna". Chociaz jak dla mnie, nawet powierzchownie, to z Pascalem nie ma nic wspolnego. Musisz chyba bardziej sie zaglebic
Zagłębiłem się. Składnia dla mnie ewidentnie jest inspirowana Pascalem. Turbo Pascala używałem trochę przez wiele lat bo miał fajniejsze IDE niż C, który miał wtedy właściwie tylko kompilator i notepada (dużo później dostał IDE Borlanda i lepszy kompilator). Odwrotna notacja typów po dwukropku, to i downto, val zamiast const (chociaż znacznie szersze możliwości), słowa kluczowe in oraz when, zakresy - czyli literały typu 1..4 lub 4 downto 1. Wiele rzeczy mi wskazuje, że inspiracja Pascalem w Kotlinie była. I wcale by mnie to nie dziwiło bo w czasach gdy Sergey Dmitriev, Oleg Stepanov i Maxim Shafirov byli dzieciakami i gdy się uczyli dopiero coś odpalać, to królował TurboPascal jako jedyny IDE i język pozwalający z palca odpalić działający program w jednym kroku. Oczywiście są nowsze elementy, które na pewno inspirowane były nowszymi językami. Niewiele innych języków widziałem z podobną składnią. Obecnie większość ma składnię inspirowaną C tak jak Java, C# i wiele innych.
Nie mam nic przeciwko językowi i jak napisałem sama składnia jest dla mnie wręcz nostalgiczna. Przypuszczam, że gdybym dzisiaj chciał w Idei odpalać na szybko jakieś programiki pisząc w kotlinie, to czułbym się chyba podobnie jak kiedyś w Turbo.
Wtrącając tylko swoje 3gr do tej dyskusji i na temat, to sytuacja z Kotlinem i Javą na Adroidzie od Google przypomina mi dawną sytuację z Javą i J++ Microsofta na Windowsie. Wtedy też na siłę promowano nowszy język (z założenia lepszy) przez utrudnianie działania starszego w systemie, którego twórca miał monopol. Takie coś nigdy nie ma dobrego PR i siłą rzeczy nawet jeżeli Kotlin, to świetny język i środowisko, to jest to na pewno pewien zgrzyt i sytuacja w której niektórzy (ludzie, a ludzie mają też emocje) mogą czuć opór przed używaniem czegoś co monopolista w swoim środowisku promuje niezbyt czystymi zagraniami. A pamiętamy jak się skończyło z J++. Czy ktoś jeszcze używa tego języka, albo środowiska Microsofta?
No właśnie.
Niektórzy nawet nie wiedzą, że istniał.
mogą czuć opór przed używaniem czegoś co monopolista w swoim środowisku promuje niezbyt czystymi zagraniami
Ej, ej ale zarzucasz cos, co nie ma absolutnie pokrycia w rzeczywistoci. Taki stan rzeczy w Androidzie jest spowodowany sprawa sadowa Google LLC v. Oracle America, Inc.
To nie Google zaczelo promowac Kotlina nieczysto, tylko Oracle strzelilo sobie w stope w tym ekosystemie i wytoczylo batalie sadowa o API Javy. I Google nie jest tworca Kotlina
Wiele rzeczy mi wskazuje, że inspiracja Pascalem w Kotlinie była. I wcale by mnie to nie dziwiło bo w czasach gdy Sergey Dmitriev, Oleg Stepanov i Maxim Shafirov byli dzieciakami i gdy się uczyli dopiero coś odpalać, to królował TurboPascal jako jedyny IDE i język pozwalający z palca odpalić działający program w jednym kroku.
No to sprawdzmy...
https://kotlinlang.org/docs/faq.html#is-kotlin-hard
Kotlin is inspired by existing languages such as Java, C#, JavaScript, Scala and Groovy.
Nigdzie tutaj Pascala nie wymienieja ;) Skladnia Kotlina jest raczej bezposrednio inspirowana Scalą! I odwrocona notacja, to jest wlasnie - wspolczesnie - taka prawie, ze domyslna notacja i wiekszosc jezykow, ktore powstaja to adaptuja taka skladnie. Czyli te wszystkie Rusty, Swifty, Nim-y itd.
Nawet ten potworek Go stosuje taka notacje typow.
Jak myślicie czy jest jeszcze miejsce na zupełnie nowy język programowania napisany pod wirtualną maszynę JVM/GraalVM?
Ludzie często mylą programowanie funkcyjne z programowaniem funkcjonalnym.
Możesz rozwinąć, o co chodzi?
czy jest jeszcze miejsce na zupełnie nowy język programowania napisany pod wirtualną maszynę JVM
To chyba rynek decyduje, a nie my programiści. W czym miałby pomóc nowy język, a w szczególności na JVM, która jest z założenia mocno ograniczona?
Tak więc czy potrzebny jest nowy język w pełni obiektowy poprawiający Javę […] wszystko jest obiektem?
Tego akurat na pewno nie potrzebujemy. Ja nie jestem obiektem.
ArchitektSpaghetti napisał(a):
Ludzie często mylą programowanie funkcyjne z programowaniem funkcjonalnym.
Możesz rozwinąć, o co chodzi?
czy jest jeszcze miejsce na zupełnie nowy język programowania napisany pod wirtualną maszynę JVM
To chyba rynek decyduje, a nie my programiści. W czym miałby pomóc nowy język, a w szczególności na JVM, która jest z założenia mocno ograniczona?
Tak więc czy potrzebny jest nowy język w pełni obiektowy poprawiający Javę […] wszystko jest obiektem?
Tego akurat na pewno nie potrzebujemy. Ja nie jestem obiektem.
Ja mam podobnie, ciągle mi się myli te programowanie funkcyjne czy funkcjonalne.
Niby wiem, że trzeba nie mutować zmiennych, bo jak wiele wątków zmutuje ten sam stan to można różnych błędów dostać, trzeba mutexy i inne mechanizmy blokujące zrobić, żeby do tego nie doszło jak ciągle tworzysz nowe to nie musisz o takie coś się martwić, ale nie o tym mówię.
Nigdy nie miałem okazji z kimś lepszym programować to nigdy się niczego nie nauczyłem.
ArchitektSpaghetti napisał(a):
Ludzie często mylą programowanie funkcyjne z programowaniem funkcjonalnym.
Możesz rozwinąć, o co chodzi?
Myślę, że zwyczajnie bredzi.
Fakt, że do lat 90tych nie było ustalone polskie nazewnictwo i nazywano to często "programowaniem funkcjonalnym", co brzmiało dwuznacznie. Dlatego zmieniono polską nazwę na "funkcyjne". Tymniemiej, to dokładnie jedno i to samo "functional programming".
Java się wydaje łatwiejsza, a tak nie wiem kotlin też fajny jest, ale to programista wybiera w czym chce pisać.
Z zewnątrz to może być głupia decyzja, ale wewnątrz to mogło być najlepsze rozwiązanie, np. nikt nie umiał kotlina.
stivens napisał(a):
Ej, ej ale zarzucasz cos, co nie ma absolutnie pokrycia w rzeczywistoci. Taki stan rzeczy w Androidzie jest spowodowany sprawa sadowa Google LLC v. Oracle America, Inc.
Ok, nie znałem szczegółów.
To nie Google zaczelo promowac Kotlina nieczysto, tylko Oracle strzelilo sobie w stope w tym ekosystemie i wytoczylo batalie sadowa o API Javy. I Google nie jest tworca Kotlina
Cóż, ok rozumiem jedną i drugą stronę. Faktycznie Oracle strzeliło sobie w stopę, ale z drugiej strony trzeba pamiętać, że Oracle tak jak wcześniej Sun ma alergię na robienie brancha Javy niekompatybilnej z dotychczasową. Zapewne chodzi o kontrolę i pieniądze. Duże pieniądze. Myślę, że Oracle już wycofuje się z tego błędu ponieważ jak się doczytałem najnowsze wersje JDK od Oracle znowu są na darmowej licencji. Widocznie odcinanie Javy od Androida trochę zabolało Oracle'a.
Co do samego tematu, to Java ma wciąż wiele naleciałości z wcześniejszych lat wynikające z założeń, które jak się okazało w trakcie ostatnich lat były błędne. Na przykład dziedziczenie powinno się stać raczej wyjątkiem niż regułą. Co prawda Java wywaliła dziedziczenie wielobazowe z C++ skracając do jednobazowego, ale i to okazało się zbyt błędotwórcze, więc trzeba to jeszcze ograniczyć - być może w przyszłości każda klasa konkretna w Javie będzie domyślnie typu final. Mogę sobie wyobrazić takie zmiany w przyszłych wersjach. A i są kolejne kolejne zmiany wraz trendami wynikającymi z odkryć jak najlepiej unikać błędów.
Sam przez ostatnie lata nie miałem większej motywacji do nauczenia się innych języków opartych na JVM takich jak np. Scala właśnie dlatego, że nie widziałem większego powodu. Wystarczyło mi na swój prywatny użytek napisanie swojego własnego drzewa kontenerów pozbawionego wszystkich naleciałości poprzednich wersji Javy - czegoś podobnego właśnie do standardowych kontenerów Kotlina. Tym bardziej nie mam więc zbyt dobrego powodu do zastąpienia Javy przez Kotlina. Pewnie w Kotlinie też prędzej czy później pojawią się problemy wynikłe z potrzeby korekty języka bo i tu może się okazać, że jakieś założenia przy jego tworzeniu okazały się niewygodne lub sprawiające problemy. Myślę, że nie bez powodu Jetbrains oznaczył aktualnego Kotlina numerkiem 2.0. Pewnie za jakiś czas będzie też 3.0 bo nie ma języka wiecznego jeżeli jest on żywy, a to wynika przecież z potrzeb.
Olamagato napisał(a):
Oracle tak jak wcześniej Sun ma alergię na robienie brancha Javy niekompatybilnej z dotychczasową.
a czy którekolwiek korpo rozwijające swój język akceptuje niekompatybilne zmiany w tym języku wprowadzane przez inne korpo, na tyle duże i poważne, żeby zagrozić jednorodności rynku i potencjalnie zrobić rozłam? dawny microsoftowy klon javy był niekopatybilny z javą, bo chociażby wprowadzał alternatywne sposoby integracji z bibliotekami natywnymi i to już sprawiało, że wiele programów javowych zaczynało być windows-only. to jest oczywiste zagrożenie dla twórców oryginalnej javy, w przypadku gdy windows jest monopolistą na rynku pecetów.
oracle dzisiaj ma graalvma, który umożliwia odpalanie kodu w różnych językach i ogólnie ułatwia implementację różnych języków. oracle mogłoby spokojnie pokusić się o zrobienie częściowej i nie do końca kompatybilnej implementacji .neta latającej na graalvmie, ale nie ma zamiaru tego robić. można się domyślać czemu, ale ja jestem pewien, że jednym z głównych powodów jest nieuchronna batalia sądowa, którą wytoczyłby microsoft.
poza tym implementacji javy jest wiele https://en.wikipedia.org/wiki/List_of_Java_virtual_machines i jestem pewien, że większość z tych darmowych ma duże problemy z kompatybilnością, ale oracle ich nie ściga, bo nie powodują rozłamu na rynku.
Java i C++ będą do końca przestarzałymi językami programowania i nikt tego nie zmieni taka ich filozofia i naleciałość lat. Chcesz nowych języków wybierz Kotlin lub Swift. JVM jest dalej tworzone w starym i niebezpiecznym dla pamięci języku C++ dlatego zaraz po C, PHP to Java ma najwięcej wycieków pamięci. Nikt nie będzie przepisywał JVM z C++ na inny bezpieczny język.
W 2024 nikt by nie tworzył maszyny wirtualnej tylko zwykły kompilator jak w Rust.
Dlang mógł być dobrym zamiennikiem ale szybko się zestarzał patrząc na Zig czy Rust.
@rodeo to prawdopodobnie stały bywalec 4p, który tworzy sobie nowe konta, narzeka na języki programowania, a potem szybko swoje konto usuwa. mimo wszystko odpowiem.
rodeo napisał(a):
Java i C++ będą do końca przestarzałe języki i nikt tego nie zmieni taka ich filozofia i naleciałość lat. Chcesz nowych języków wybierz Kotlin lub Swift.
każdy język, który stawia na silną kompatybilność wsteczną, będzie kiedyś przestarzały (albo chociażby mocno trącił myszką).
JVM jest dalej tworzone w starym i niebezpiecznym dla pamięci języku C++ dlatego zaraz po C, PHP to Java ma najwięcej wycieków pamięci.
- podaj źródło. czy ktoś zrobił analizę tych wycieków pamięci?
- wycieki pamięci nie naruszają bezpieczeństwa pamięci. rzadko kiedy wycieki są problemem (czyli, inaczej mówiąc, czasem są problemem, ale ogólnie rzadko :) ), bo zwykle są szybko naprawiane albo są bardzo powolne i niewiele psują. tymczasem używanie (zarówno modyfikowanie jak i odczyt) pamięci, do której nie powinno się mieć dostępu jest dużo większym problemem (także problemem bezpieczeństwa) i ogólnie dużo trudniejszym do namierzenia i naprawienia.
Nikt nie będzie przepisywał JVM z C++ na inny bezpieczny język.
java jest już od dawna przepisywana na javę. patrz: graalvm. nie wiadomo kiedy (i czy w ogóle) całkowicie zastąpi pisanego w c++ hotspota, ale tak czy siak oraclowi raczej się z przesiadką nie spieszy. w końcu java ma już jakieś 30 lat i nie zapowiada się by w przewidywalnej przyszłości straciła na znaczeniu.
rodeo napisał(a):
Java i C++ będą do końca przestarzałymi językami programowania i nikt tego nie zmieni taka ich filozofia i naleciałość lat. Chcesz nowych języków wybierz Kotlin lub Swift.
No Dobrze, załóżmy, że Java też się tak zestarzeje, że żadne nowe edycje języka nic nie zmienią. Ale to będzie dotyczyć również Kotlina czy innych języków. Na dzisiaj może jest super, chociaż pewnie nie bez ważnego powodu Kotlin jest już reklamowany jako 2.0. Ale mi jako kogoś kto "wychował" się na C (ale także Pascalu) składnia C/Java jest wystarczająco czytelna, a skomplikowane konstrukcje żonglujące danymi są raczej podobnie trudne na pierwszy rzut oka jak w Kotlinie czy innych językach.
JVM jest dalej tworzone w starym i niebezpiecznym dla pamięci języku C++ dlatego zaraz po C, PHP to Java ma najwięcej wycieków pamięci. Nikt nie będzie przepisywał JVM z C++ na inny bezpieczny język.
Przecież Kotlin też działa na JVM, ale i pewnie teraz na Dalviku - chcesz powiedzieć, że ten sam kod źródłowy będzie inaczej działał na jednej maszynie wirtualnej niż na drugiej?
Poza tym zdaje mi się, że niemała część kompilatora javac oraz maszyny wirtualnej Javy jeszcze od Suna (a potem Oracle'a) została przepisana do Javy.
Przyglądam się wielkości Oracle Java 17 dla Windozy i kod maszynowy w exe/dll zajmuje 45MB, a pozostałych modułów bez dokumentacji i śmieci (głównie modułów Javy), to 246MB. Podejrzewam więc, że te 45MB jest zależne bezpośrednio od systemu i CPU (np. źródła napisane w C/C++), a pozostałe raczej niezależne (czyli źródła napisane raczej w Javie bo w czym innym?).
Myślę, że część napisana w C/C++ jest tak mała jak to możliwe i specyficzna dla systemu. A pisanie niskopoziomowego kodu zazwyczaj opłaca się robić właśnie w tych językach bo wystarczy, żeby fizyczna maszyna miała kompilator C do kodu maszynowego, i już będzie można skompilować JVM na tę maszynę zapewne bez potrzeb żadnych lub większych zmian w kodzie wyższego poziomu w JDK.
W 2024 nikt by nie tworzył maszyny wirtualnej tylko zwykły kompilator jak w Rust.
Dlang mógł być dobrym zamiennikiem ale szybko się zestarzał patrząc na Zig czy Rust.
Dzięki. Rzucę okiem. Pierwsze co mi się rzuciło w oczy to to:
https://bulldogjob.pl/readme/programowanie-w-rust-the-good-the-bad-and-the-ugly
czy mi się wydaje czy nikt tu o C# (błe) nie napisał ?
ao R, gdzie programiści R ? ;)
Nowa dla mnie ciekawostka:
https://www.geeksforgeeks.org/how-to-convert-kotlin-code-to-java-code-in-android-studio/?ref=oin_asr2
Szczególnie na końcu:
"Advantages of Java Over Kotlin:
Operator overloading is not possible.
Classes written in Java are not made final by default.
More readable syntax.
Use of static methods and variables."
Chyba Java się jednak jakoś broni przed zastąpieniem jej Kotlinem...
Może działa zasada Kopernika dla języków programowania? 
Using COBOL over Java can have several advantages, particularly in certain contexts:
Legacy System Integration: COBOL is deeply entrenched in legacy systems, especially in industries like banking, insurance, and government. It seamlessly integrates with these systems without the need for extensive rewrites.
Proven Reliability: COBOL has been used for decades in mission-critical applications. Its reliability and stability are well-documented, making it a trusted choice for systems where failure is not an option.
Performance in Batch Processing: COBOL is optimized for large-scale batch processing and high-volume transaction processing, which is common in financial and administrative systems. It can handle these tasks more efficiently than Java in some cases.
Maintenance of Existing Codebases: Given the vast amount of COBOL code already in use, maintaining and extending existing COBOL systems can be more straightforward and cost-effective than rewriting them in Java.
Specialized for Business Applications: COBOL was specifically designed for business data processing. Its syntax and structure are well-suited to tasks involving large-scale data processing, like payroll, billing, and financial record-keeping.
Less Complex Syntax for Business Logic: COBOL's syntax is designed to be readable and understandable by non-programmers, particularly those with a business background. This can make it easier for business analysts to work directly with the code.
Long-Term Stability: COBOL's design has changed little over the years, which can be an advantage for organizations looking for long-term stability and minimal disruption.
Minimal Runtime Overhead: COBOL programs often have minimal runtime overhead compared to Java, which requires a JVM (Java Virtual Machine). This can result in more predictable performance, particularly on older hardware.
Lower Risk for Certain Updates: For organizations already using COBOL, making small updates or changes in COBOL can carry less risk than migrating to a new language like Java, which might introduce compatibility or integration issues.
Experienced Workforce in Specific Sectors: In sectors like finance and government, there is a significant pool of experienced COBOL programmers, and many organizations have established processes and tools for COBOL development and maintenance.