Dlaczego pogarda dla COBOL? [Zamknięte]

Kiedy ludzie wspominają o języku COBOL, zwykle jest to albo prychnięcie, albo jęk. Niewiele wiem o języku COBOL, ale widziałem w nim napisane programy. Widzę, że to jest męczące, a dla niewtajemniczonych, takich jak moje, niezrozumiałe. Ale tak naprawdę, czy wszystkie języki programowania nie są dla ludzi świeckich bełkotem?

Rozumiem, że działa, działa dobrze i nadal jest szeroko stosowany w branżach, dla których został zaprojektowany. Czy to nie są cechy dobrego języka? Co jest tak złego w COBOL?

COBOL był jednym z pierwszych języków, których się nauczyłem - jeśli zignorujesz niezliczone wersje języka Basic, trzy lub cztery języki asemblera i wariant Fortha, to był on w moich pierwszych pięciu i uczył się równolegle z Pascalem. IOW, odpowiadam z własnego doświadczenia w posługiwaniu się językiem.

EDYCJA Powinienem powiedzieć starożytne doświadczenie. Nigdy nie używałem tego języka po latach 80., ale kupiłem nową książkę (aby zastąpić starą, którą odrzuciłem z niesmakiem), aby mieć coś, o czym mógłbym się odnieść, aby moje horrory nie były zbyt zniekształcone. Ale nie mam pojęcia, jak ten język ewoluował w ciągu ostatnich 20 lat.

Oczywiście, dla wielu ludzi jest to, że „stary jest zły” pogląd, który jonsca już opisała - a także, o wiele bardziej, podejście polegające na przekazywaniu mi z trzeciej ręki. Ale leżą u podstaw prawdziwe problemy.

Bycie zbyt pracowitym to prawdziwy problem - zbyt wiele bałaganu w sposobie rozumienia kodu. To zdecydowanie największy problem. Ludzie, którzy spojrzeć na MOVE, ADDi MULTIPLYetc oświadczenia grozy mają nieco przesadzone widok tego, prawda - COMPUTEstwierdzenie jest bliżej do zadań w innych językach. Ale wciąż jest mnóstwo bałaganu we wszystkich tych działach i sekcjach. Jedną z pierwszych rzeczy, których nauczyłem się w języku COBOL, było rozpoczęcie od kopiowania standardowego pliku SKELETON.COB o długości A4.

COBOL ma kilka ciekawych funkcji, ale te funkcje (np PICrzecz) wydają się być rzeczy, które są teraz bardziej częścią DBMS zamiast języka programowania, a wydaje mi się zwykle być lepszy sposób, aby oddzielić te obowiązki. Ponadto niektóre biblioteki w innych językach używają czegoś porównywalnego PIC(np. Printf i scanf w standardowej bibliotece C). Prawdopodobnie najlepsze zostały zachowane, ale najgorsze spadły.

Ponadto, dla każdej fajnej funkcji, istniała co najmniej jedna niedopuszczalna. Na przykład, bez względu na to, jak banalna jest pętla, musisz przenieść ciało do osobnej procedury. PERFORM ... UNTIL ...I podobne wypowiedzi są pojedyncze wypowiedzi - nie blokować struktur. W pewnym sensie, COBOL był smak programowania strukturalnego od programowania strukturalnego zanim wynaleziono - nie byłoGO TO , ale to wykorzystanie zniechęcił (przynajmniej kiedy użyłem COBOL), ale zapętlenie w szczególności po prostu nie było traktowane tak dobrze.

W rzeczywistości językiem, którego użyłem po języku COBOL, który najbardziej mi to przypominał, był ... dBase. Jak w Ashton-Tate dBase III +. W dzisiejszych czasach ludzie są bardziej skłonni do zapamiętania wszystkich martwych lub umierających klonów (Clipper, FoxPro itp.), Które doprowadziły do ​​ogólnej nazwy xBase - a xHarbour nadal ma żyjącego potomka. Chodzi o to, że były to języki baz danych, ale nic podobnego do SQL.

Nawet wtedy, gdy każdy program COBOL działający na konkretnej bazie danych musi zawierać kopię specyfikacji tej bazy danych (a kopie mogą się skończyć niespójne), tak naprawdę nie dzieje się tak w przypadku xBase, gdzie baza danych zna swoją własną strukturę.

Biorąc to pod uwagę, COBOL nie jest tak straszny, jeśli zaakceptujesz go takim, jakim jest. Ale to nie jest język do pisania struktur danych. Być może dlatego COBOL bardzo ucierpiał w czasach świętych wojen C vs. Pascal - obie strony mogły się zgodzić, że COBOL nie był dobry do ponownego opracowania drzewa binarnego.

Aha - i nigdy nie zapomnę tego, że mój pierwszy podręcznik COBOL nie opisał SORTpolecenia, mówiąc, że wykracza to poza zakres książki - najwyraźniej albo autor nie poradziłby sobie z pomysłem sortowania, albo uważał, że jest to coś więcej niż małe umysły studentów COBOL-u, z którymi można sobie poradzić [patrz edycja na końcu]. Takie rzeczy bardzo utrudniały poważne traktowanie COBOL.

Dziwnym aspektem tego było programowanie strukturalne Jacksona, którego również musiałem się uczyć mniej więcej w tym samym czasie, a konkretnie do używania z COBOL. Częścią tego było narysowanie schematu struktury dla danych wejściowych, następnie schematu struktury dla danych wyjściowych, a następnie narysowanie schematu struktury pomiędzy kodem. Wyraźnie oczekiwano, że sortowanie będzie już rozwiązanym problemem - nie można w ten sposób uzyskać algorytmu sortowania. W zalecanym podręczniku było dziwne, że cała koncepcja sortowania była poza moim małym umysłem, a jednocześnie nauczono czegoś w rodzaju kilkunastu różnych algorytmów sortowania i sposobu ich implementacji w Pascalu.

Problemy, z którymi JSP może sobie poradzić, są prawdopodobnie dobrym przewodnikiem po rzeczach, które COBOL może zrobić stosunkowo dobrze. Ale nawet wtedy niekoniecznie oznacza to, że JSP lub COBOL są dobrym sposobem na rozwiązanie tych problemów.

EDYCJA 30 lipca 2014 r

Właśnie zyskałem dzięki temu reputację, przypominając mi, że już tu jest. Tak się składa, że ​​z powodu gromadzenia dawnych książek, napędzanych nostalgią, mogę teraz poprawić punkt WRT SORTpolecenia.

Książka, której pierwotnie użyłem jako zalecanego tekstu podczas nauki języka COBOL, brzmiała „Programowanie metodyczne w języku COBOL” autorstwa Ray Welland. Nie dotyczy to COBOL 85 (chociaż była późniejsza edycja „Programowanie metodyczne w języku COBOL-85”, której wciąż nie widziałem).

uprzejme komentarze poniżej: „Miałeś posortować pliki wejściowe przed ich odczytaniem lub posortować plik wyjściowy po jego wygenerowaniu, używając narzędzia sortującego dostarczonego z systemem operacyjnym”. Od mojej odpowiedzi na to pytanie przeoczyłem punkt „przyszedł z systemem operacyjnym”. Kindall sugerował coś podobnego do filozofii uniksowej AFAICT, z COBOL-em używanym do bitów, do których jest dobry, narzędziami systemu operacyjnego, takimi jak narzędzie sortujące używane do niektórych innych rzeczy i prawdopodobnie używając języka wsadowego / skryptowego / powłoki do sklejenia bitów. Ma to o wiele większy sens w starożytnym świecie, w którym oprogramowanie interaktywne rzadko bywało nieistniejące, dlatego i tak należy przesyłać partie pracy (stąd „język wsadowy”).

Poniższy cytat znajduje się na stronach 165-166 „Programowania metodycznego w języku COBOL” ...

Korzystanie z uporządkowanych plików szeregowych oznacza, że ​​konieczne jest dysponowanie środkami do sortowania rekordów w pliku w określonej kolejności według klucza. Większość większych systemów komputerowych ma narzędzie sortujące, które posortuje plik, biorąc pod uwagę pozycję, typ i rozmiar każdego z elementów danych tworzących klucz.

Istnieje również możliwość sortowania rekordów z programu COBOL, ale wykracza to poza zakres tej książki z dwóch powodów:

(a) interfejs do systemu operacyjnego jest często dość złożony i różni się w zależności od systemu,

(b) moduł sortowania jest opcjonalną częścią COBOLU ANS '74 i nie może być zaimplementowany w systemach COBOL dla mniejszych komputerów.

Dlatego należy założyć, że istnieją możliwości sortowania plików w określonej kolejności i zostanie rozważony problem aktualizacji takich plików.

Krótko mówiąc, kindall jest poprawny - założono, że zwykle sortowanie odbywa się poza COBOL. Być może istniało prawdziwe uzasadnienie wyłączenia sortowania z języka programowania około 1974 r. Dla małych komputerów.

To, co powiedziałem powyżej, było w zasadzie tym, co otrzymujesz po około 20 latach niemożności sprawdzenia faktów z powodu wyrzucenia książki.

Nadal jednak muszę podkreślić, że formalnie studiowałem COBOL z tej zalecanej książki, która obejmowała standard z 1974 r. (Nie standard z 1985 r.) W 1988 i 1989 r. Trzecie wydanie „COBOL dla studentów” (Parkin, Yorke, Barnes) - pierwsze wydanie obejmujące COBOL 85 - zostało opublikowane dopiero w 1990 roku. Nie jestem pewien, ale myślę, że wydanie „Metody programowania programistycznego” COBOL 85 zostało opublikowane dopiero w 1994 roku.

Ale to niekoniecznie oznacza, że ​​świat COBOL ciągnie się nogami - cóż, i tak nie tak bardzo. Przyjęcie nowych standardów wymaga czasu dla dowolnego języka, nawet teraz.

Wydaje mi się, że spędziłem większość dzisiejszego dnia na pisaniu COBOL-a.

Najpierw ZŁE rzeczy: -

• Brak wywołań funkcji. Współczesny COBOL ma kilka wbudowanych funkcji, ale jest to poważne zadanie inżynierskie, aby napisać własne.
• Brak sprawdzania typu w połączeniach podprogramów. Możesz przekazać (lub nie przekazać) dowolne wywołanie podprogramu, wywoływany podprogram beztrosko przyjmuje, że ma poprawne parametry i nie ma możliwości wykrycia brakujących lub niepoprawnych parametrów.
• Brak bibliotek. Brak zero zilch. Brak standardowych bibliotek, brak powszechnie używanych, łatwo dostępnych bibliotek. Końcowe zadania związane z kodowaniem kompilują się w kółko.
• Wszystko jest zaimplementowane jako słowo kluczowe. Ponieważ autorzy języków nie mają koncepcji biblioteki, każda nowa funkcja kończy się implementacją nowych słów kluczowych, np. PARSE i RENDER do obsługi XML.

Niezrozumiane, tj. Krytyka powszechnie wypowiadana przeciwko drogiemu staremu językowi, które są nieprawidłowe lub nieistotne.

• Gadatliwość. Więc wpisujesz kilka dodatkowych znaków! To nie jest poważny problem. W wielu przypadkach język COBOL jest mniej szczegółowy niż Java.

• „PLIKI COBOL” Często widujesz ten termin. Nie ma czegoś takiego, że COBOL może obsłużyć dowolny format pliku i dowolną organizację plików.

• Bez wielowątkowości. W środowiskach, w których COBOL dobrze się rozwija, wielowątkowość jest zwykle pozostawiana kontenerom aplikacji, takim jak CICS lub IMS, które są w tym dobre, a nie programistom, którzy są w tym źli.

I dobre rzeczy - niektóre aspekty COBOL są lepsze od innych języków: -

• Struktury danych. COBOL ma zwięzłą i elastyczną składnię do definiowania złożonych struktur danych i nieparzystych typów danych.
• Arytmetyka dziesiętna. Ma natywną obsługę arytmetyki dziesiętnej, tj. Arytmetyki rozumianej przez księgowych, z odpowiednim zaokrągleniem itp.
• Poruszanie się z duchem czasu. Niektóre aspekty COBOL są zaskakująco nowoczesne. Wbudowana obsługa XML, obsługa programowania OO, możliwość korzystania z klas Java itp.
• Integracja z DB2, CICS itp. Odnosi się to tylko do COBOLu na komputerze mainframe IBM (ale jest to zdecydowanie największa część COBOL-a nadal działającego), ale integracja z DB2, CICS i innymi środowiskami mainframe ułatwia kodowanie takich rzeczy, jak kopia zapasowa bazy danych usługi sieciowe niż w jakimkolwiek innym środowisku.
• Obsługa ekranu. Standardowa obsługa ekranu zaimplementowana w AS / 400 i MicroFocus Cobol jest doskonała.
• Występ. Od wielu lat kompilatory COBOL produkują pliki wykonywalne o bardzo wysokiej wydajności. Tylko natywny C i natywny asembler pokonały COBOL na komputerze mainframe IBM.

Podsumowując, radzi sobie całkiem dobrze z czymś, co komitet opracował w latach 50. XX wieku. Jeśli istniejąca aplikacja jest zaimplementowana w języku COBOL i wykonuje zadanie, nie ma powodu, aby ją ponownie pisać. Jednak chyba, że ​​istnieje naprawdę dobry powód, nie widzę żadnego uzasadnienia dla nowych projektów do korzystania z COBOL.

To prawdopodobnie zależy od Djikstry. Djikstra stwierdził, że „stosowanie COBOL kaleczy umysł; dlatego jego nauczanie należy traktować jako przestępstwo”. Kobol był postrzegany jako naiwny, nieuporządkowany i gadatliwy. Dzięki możliwości samodzielnego zmieniania kodu (praktyka odradzana nawet wśród programistów cobol) było postrzegane jako dość trudne do debugowania lub śledzenia.

Jest też kwestia dużej niezgodności między wersjami.

Proponuję przeczytać sekcję krytyki i obrony w Wikipedii dotyczącą języka - http://en.wikipedia.org/wiki/COBOL#Criticism_and_defense

Wiek i gadatliwość to zwykle rzeczy, które sprawiają, że ludzie narzekają na to.

Wydaje mi się, że głównym celem IBM przy projektowaniu COBOL było to, że „powinno ono pozwolić menedżerowi banku na napisanie programu”. Cel ten miał oczywiście głęboki wpływ na sposób zaprojektowania języka i teraz ewoluował.

Najwyraźniej na wolności jest więcej COBOL niż w jakimkolwiek innym języku. Jednak po prawie 20 latach pracy w IT (15 w bankowości) nigdy nie spotkałem ani jednego systemu, który został w nim wdrożony.

Co jest tak złego w COBOL?

Nic.

Myślę, że ludzie mają z góry założone przekonanie, że stare jest złe, „najnowsze są najlepsze”. Nadal jest w użyciu i jestem pewien, że będzie wystarczająca ilość prac konserwacyjnych nad kodem, które można będzie wykonać przez kolejne pół wieku.

W 1997 r. Gartner Group podała, że ​​80% światowej działalności prowadzonej było w oparciu o COBOL, z ponad 200 miliardami linii kodu i około 5 miliardami linii nowego kodu rocznie. (przez wikipedia )

W kodowaniu należy zawsze wybrać najlepsze narzędzie do pracy, a w przypadku niektórych branż powiązanych z określonym sprzętem język jest optymalny. Nigdy nie pracowałem w bankowości, gdzie słyszałem, że jest popularna, ale odpowiedź Seana wskazuje, że tak nie jest.

Jeśli występuje problem ze starszym kodem, który wygląda na stary, o ile można uderzyć interfejsem użytkownika lub interfejsem sieciowym przed nim, większość użytkowników nawet nie zauważy różnicy.

Ludzie nie lubią języka COBOL, ponieważ ma on ograniczone zastosowanie. Został zaprojektowany dla systemów biznesowych, finansowych i administracyjnych dla firm i rządów.

Co łączy je wszystkie? Dane. Dużo danych.

Zgadnij, kto został zaprojektowany do kruszenia danych i ma dużo plików na śniadanie? Czy możesz powiedzieć COmmon Business-Oriented Language ?

50 lat temu COBOL był najlepszą rzeczą dla dużych organizacji z dużą ilością danych do zarządzania. Obecnie istnieją lepsze sposoby zarządzania dużą ilością danych, więc COBOL nie jest już istotny. Albo to jest?

Rozważmy rządy. Jakie dane potrzebuje rząd do śledzenia? Identyfikatory osób, akty urodzenia, dokumentacja medyczna, podatki (och ... tak ... podatki) itp. I muszą przechowywać te informacje w nieskończoność, dziś i 50 lat temu.

Ludzie również opisywali banki w niektórych odpowiedziach i rzeczywiście banki są intensywnym użytkownikiem COBOL. Dlaczego? ponieważ w przeciwieństwie do innych rodzajów firm banki zwykle mają swoją historię. Niektóre istnieją od setek lat ( jak na przykład ten ).

Oznacza to, że niektóre dane z 50 lat muszą być nadal z nami, dziś, 7 października 2011 r. Teraz mamy SQL Server i C # lub Oracle i Java, ale 50 lat temu było COBOL i pliki.

W miarę upływu czasu dane rządów i banków stawały się coraz większe, a migracja systemów była coraz droższa. Co oznacza, że ​​muszą pozostać w języku COBOL i być stale utrzymywani i ewoluować wraz z rozwojem biznesu. Niektóre banki powoli migrują, podczas gdy inne po prostu przyklejają ładny interfejs Web2.0 przed komputerem mainframe (najczęściej używane są c # i Java). Czy możesz powiedzieć starszy kod? (COBOL idzie w parze z (ekstremalnym) starszym kodem, niektórym dotkniętym przez wiele osób przez dziesięciolecia istnienia - kolejna rzecz, której programiści nie lubimy: D).

A teraz masz niszę działalności. COBOL ma teraz ograniczone zastosowanie i wpływa to na twoje doświadczenie .

A ludzie, którzy wchodzą w COBOL, w końcu odkrywają, że robisz to samo w kółko, rok po roku, a kiedy się budzą, nie są już konkurencyjni na rynku, ponieważ ludzie chcą teraz PHP, Java, C # , REST, jQuery i tylko banki szukają osób COBOL.

W tym momencie popyt jest niższy niż podaż, a ci, którzy nie robią cięcia, muszą przejść do czegoś innego. I muszą zacząć jako juniorzy, ponieważ COBOL naprawdę kaleczy umysł (wierzcie, że nie kopiowanie i wklejanie jest głównym stylem rozwoju w COBOL i odpowiada za jego dużą wydajność), a teraz przeklinają dzień, w którym wzięli COBOL i nie nie tracę okazji do opowiadania o tym swoich horrorów :). Ale możesz opowiedzieć te historie o jakimkolwiek starym języku fartów, który obecnie nie jest już pożądany, ale jesteś niefortunną osobą, która go tkwi. No cóż ...

PS i COBOL są złe z wszystkich innych powodów wymienionych przez innych :)

PS2. In 1997, the Gartner Group reported that 80% of the world's business ran on COBOL with over 200 billion lines of code in existence and with an estimated 5 billion lines of new code annually.Naprawdę? A jak mierzył to dzień? Czy poszli zrobić każdą firmę na świecie i zapytali ich, ile mają linii COBOL lub co?

Dwie funkcje.

• Oświadczenie ALTER jest czystym złem. Chociaż rzadko stosowany w bardziej nowoczesnych aplikacjach COBOL, był intensywnie wykorzystywany w „dawnych czasach”, ponieważ był bardziej wydajny niż równoważna struktura „IF-GOTO”. Gdy komputery miały tylko 32 KB pamięci RAM, każda instrukcja miała znaczenie. Zmodyfikował instrukcję GOTO, aby mieć inne miejsce docelowe.

  To spowodowało, że kod stał się nieprzejrzysty, ponieważ sam kod był stanowy.

• Klauzula REDEFINES w strukturze danych (jak unionw C) jest problemem wiecznym. Termin „wolny związek” - tj. Nakładające się struktury danych bez dyskryminatora - jest sposobem na podsumowanie problemu. Dwa aliasy REDEFINES nie mogą być trywialnie rozróżniane przez dane; tylko obszerne czytanie logiki programu może określić znaczenie dwóch alternatywnych interpretacji bajtów.

  To spowodowało, że wiele struktur danych stało się nieprzezroczystych, ponieważ danych nie można zrozumieć bez kodu.

Czytelność angielskiej składni została pokonana przez te dwa konstrukty.

[Moderatorzy ostrzegają mnie, że krótkie odpowiedzi lekceważą twoje ważne i interesujące pytanie. Jeśli uważasz to za lekceważące, możesz poprosić o szczegóły. Lub oflaguj go, aby moderatorzy mogli go usunąć.]

Przez kilka dobrych lat programowałem w języku COBOL. Jego składnia jest prosta w porównaniu do dzisiejszych języków i nie trzeba wiele teorii, aby nauczyć się, jak zacząć. COBOL bardzo dobrze współpracował z IBM CICS (system do zarządzania transakcjami on-line), a programista musi zrobić to, aby w kodzie przeskalować liczbę użytkowników od 1 do kilku tysięcy. CICS zapewnił oparty na znakach GUI, który działał z ekranem jako jednostką wyświetlania (bez okien). Możesz wyświetlać wykresy za pomocą (IBM GDDM) na komputerze mainframe. COBOL może komunikować się z plikami indeksowanymi (VSAM i ISAM), a także z DB2 (relacyjny oparty na SQL), a także IMS. COBOL / CICS to bardzo solidne środowisko, którego możesz się nauczyć w ciągu kilku tygodni. Oznacza to, że skupiasz się na biznesie, a nie na technologii, więc pracujesz 7 z 8 godzin na kodowaniu, a nie na nauce MVM, JavaScript i tym podobnych.

Problemem z COBOL jest zły marketing, który prowadzi do braku zainteresowania stron trzecich tworzeniem narzędzi i środowisk programistycznych. Ponadto brak obsługi interfejsu podobnego do systemu Windows spowodował spadek jego popularności po 1993 r. Koszty komputerów mainframe skłoniły klientów do poszukiwania alternatyw i kompilatorów dla języka COBOL dostępnych w systemach UNIX i DOS. Język C przyciągnął wiele światła, ponieważ był bardziej przenośny i miał bezpośredni dostęp do funkcji systemu operacyjnego, czego COBOL miał bardzo mało.

Języki takie jak VB, DBase, FoxPro i Clipper miały lepsze sposoby dostępu do „baz danych” na PC niż porównywalny COBOL w DOS, więc COBOL stracił. CICS przez długi czas nie był tani w systemach DOS i UNIX, więc jego wartość nie była obecna w tych środowiskach.

Dzisiaj COBOL jest obsługiwany przez .NET, ale myślę, że przegrał bitwę na wszystkich platformach oprócz mainframe (i prawdopodobnie AS / 400), gdzie wciąż tam jest ze względu na ogromną liczbę krytycznych aplikacji, w pełni zależnych od to.

Heh, poszedłem do college'u na początku lat 80., a ludzie pogardzali COBOL-em jeszcze wtedy. Myślę, że największym problemem jest jego gadatliwość - proste „Witaj, świecie!” w języku COBOL jest prawdopodobnie ponad pięćdziesiąt wierszy, z których 95% to wymagana płyta kotłowa. To po prostu niezbyt elegancki lub atrakcyjny język. Został również zaprojektowany, aby poradzić sobie z wczorajszymi problemami i tak naprawdę nie nadaje się do paradygmatów programistycznych opracowanych po około 1970 roku. Jest to całkiem dobry język generowania raportów - o ile raporty są nieskończonymi kolumnami liczb z nagłówkami i stopkami. Jeśli chcesz gdzieś nakleić wykres lub logo, zapomnij o tym. Myślę, że wciąż jest to najszybszy język do zadań typu „przetwarzanie danych” (weź plik o stałym formacie z 5-milionowymi transakcjami w bankomatach i dokonaj prostej korekty bilansu dla każdego z nich), ale ilu programistów robi takie rzeczy? I wiele systemów korzysta obecnie z XML lub JSON, nie chciałbym myśleć o próbowaniu parsowania czegoś takiego w COBOL (właściwie nie chciałbym myśleć o parsowaniu w ogóle w języku COBOL!)