Чому зневажають КОБОЛ? [зачинено]

Коли люди згадують про COBOL, це зазвичай або зустрічається зі снудом, або стогін. Я мало знаю про COBOL, але я бачив деякі програми, написані в ньому. Я можу бачити, що це багатослівно, і для необізнаних очей, таких як моє, незрозуміле. Але насправді, чи не всі мови програмування є повним шахрайством для непростої людини?

Я розумію, що це працює, добре працює і досі широко застосовується в галузях, для яких він був розроблений. Хіба це не ознаки доброї мови? Що так погано в COBOL?

COBOL була однією з перших мов, які я навчився - якщо ви проігноруєте незліченну кількість базових, трьох-чотирьох мов асемблера та варіант Forth, то це було в моїх перших п'яти, і я вивчив одночасно з Pascal. IOW, я відповідаю з особистого досвіду, використовуючи мову.

EDIT Я повинен сказати стародавній досвід. Я ніколи не використовував мову після кінця 80-х, хоча я придбав нову книгу (замінивши стару, яку я відкинув огидою), щоб мені було на що посилатися, щоб мої страшилки не надто перекрутили. Але я поняття не маю, як мова розвивалася принаймні за останні 20 років.

Очевидно, що для багатьох людей, це просто , що «старий погано» вид , що jonsca вже описав - а також набагато більше третини рук пас мене вниз відносини річ. Але в основі цього лежать реальні проблеми.

Занадто багатослівний - це справжня проблема - занадто багато неполадок у розумінні коду. Це, безумовно, найбільше питання. Люди , які дивляться на MOVE, ADDі MULTIPLYт.д. заяви в жаху мають кілька перебільшене уявлення про це, правда - COMPUTEтвердження ближче до завдань на інших мовах. Але у всіх тих підрозділах та секціях все ще багато неспокою. Одне з перших речей, які я дізнався в COBOL, - це завжди починати з копіювання стандартної сторінки SKELETON.COB, розміщеної на форматі A4.

COBOL робить деякі цікаві функції, але ці функції (наприклад, PICріч) , як правило, речі, які в даний час більш частиною СУБД , а не мова програмування, і мені здається, як правило , бути краще , щоб відокремити ці обов'язки. Також деякі бібліотеки іншими мовами використовують щось порівнянне PIC(наприклад, printf та scanf у стандартній бібліотеці C). Можливо, найкраще було збережено, але найгірше випало.

Крім того, на кожну приємну особливість була принаймні одна нестерпна. Наприклад, якою б тривіальною не була петля, вам доведеться перемістити тіло в окрему процедуру. PERFORM ... UNTIL ...І подібні заяви є поодинокі заяви - НЕ блокових структур. У певному сенсі, COBOL був смак структурованого програмування від структурного програмування до того було винайдено - там булоGO TO , але його використання не заохочувалося (принаймні , коли я використовував COBOL), але цикл , зокрема , просто не був оброблений , що добре.

Насправді мовою, якою я користувався після COBOL, яка мені найбільше нагадала про це, була ... dBase. Як і в Ashton-Tate dBase III +. У наші дні люди, швидше за все, пам’ятають усіх мертвих або вмираючих клонів (Clipper, FoxPro тощо), що призвели до загальної назви xBase - а в xHarbour ще живе живий нащадок. Справа в тому, що це були мови баз даних, але нічого подібного до SQL.

Навіть тоді, коли кожна програма COBOL, що працює на певній базі даних, повинна містити копію специфікації цієї бази даних (а копії можуть бути непослідовними), це не так у xBase, де база даних знає, що це власна структура.

Враховуючи це, COBOL не такий страшний, якщо ви приймаєте його таким, яким він є. Але те, що це не так , це мова для написання структур даних. Це може бути причиною того, що COBOL сильно постраждав у часи святих воєн C проти Паскаля - обидві сторони могли погодитися, що COBOL не був корисним для того, щоб ще раз винайти бінарне дерево.

О - і одне, що я ніколи не забуду - це те, як мій перший навчальний посібник COBOL не описав SORTкоманду, кажучи, що це виходить за рамки книги - мабуть, або автор не впорався з ідеєю сортування, або вважав, що це більше, ніж крихітні розуми студентів COBOL могли впоратися з [див. редагування наприкінці]. Такі речі дуже ускладнили серйозну сприйняття COBOL.

Незвичайним аспектом цього було Структурне програмування Джексона, яке я також був змушений вивчити приблизно в той же час, і спеціально для використання з COBOL. Частиною цього було складання структурної діаграми для вводу, потім структурна діаграма для виводу, потім складання діаграми проміжних структур для коду. Очевидно, що сортування було вже вирішеною проблемою - таким чином не можна було вивести алгоритм сортування. Отож, дивним підручником із підручників було дивно сказати, що вся концепція сортування була поза моїм крихітним розумом, і в той же час викладали щось на зразок десятка різних алгоритмів сортування та того, як їх реалізувати в Pascal.

Проблеми, з якими може вирішуватися JSP, є, мабуть, хорошим посібником щодо тих речей, які COBOL може зробити досить добре. Але навіть тоді це не обов'язково означає, що або JSP, або COBOL є хорошими способами вирішення цих проблем.

EDIT 30 липня 2014 року

Я просто отримав від цього підвищення репутації, нагадуючи, що вона тут. Як це буває, завдяки деякому накопиченню ностальгією старовинних книг, я тепер можу виправити точку WRT SORTкоманди.

Книга, яку я спочатку використовувала як рекомендований текст під час вивчення COBOL, була "Методичне програмування в COBOL" Рея Велленда. Це не стосується COBOL 85 (хоча там було пізніше видання "Методичне програмування в COBOL-85", якого я досі не бачив).

kindall зазначає нижче, що "Ви повинні були сортувати вхідні файли перед читанням або сортувати вихідний файл після його генерації, використовуючи утиліту сортування, що постачається з ОС". З моєї відповіді на це я пропустив пункт "прийшов з ОС". Kindall запропонував щось подібне до філософії Unix AFAICT: COBOL використовується для бітів, що це добре, утиліти ОС, такі як утиліта сортування, яка використовується для деяких інших речей, і, імовірно, використовуючи пакетну / сценарійну / оболонку мову, щоб склеїти біти разом. Це має набагато більше сенсу в стародавньому світі, де інтерактивне програмне забезпечення було рідкісним для неіснуючого, тому ви все одно будете надсилати партії роботи (отже, "пакетної мови").

Далі цитується на сторінці 165-166 "Методичного програмування в COBOL" ...

Використання впорядкованих послідовних файлів означає, що необхідно мати засоби сортування записів у файлі за певним порядком за ключем. Більшість великих комп'ютерних систем мають утиліту для сортування, яка буде сортувати файл за положенням, типом та розміром кожного з елементів даних, що утворюють ключ.

Існує також можливість сортування записів у рамках програми COBOL, але це виходить за межі цієї книги з двох причин:

(a) інтерфейс до операційної системи часто досить складний і змінюється від системи до системи,

(b) модуль сортування є необов'язковою частиною COBOL ANS '74 і не може бути реалізований в системах COBOL для менших комп'ютерів.

Тому буде прийнято вважати, що існують засоби для сортування файлів у визначеному порядку і буде розглянута проблема оновлення таких файлів.

Коротше кажучи, kindall правильний - припущення було, що звичайно сортування проводиться поза COBOL. Можливо, навіть було справжнє виправдання для виключення сортування з мови програмування близько 1974 року для невеликих комп'ютерів.

Те, що я говорив вище, було в основному тим, що ви отримуєте приблизно через 20 років, коли не зможете перевірити факти через викидання книги.

Я все ж повинен зазначити, що я офіційно вивчав COBOL з цієї рекомендованої книги, яка охоплювала стандарт 1974 року (а не стандарт 1985 р.) У 1988 та 1989 рр. Третє видання "COBOL для студентів" (Паркін, Йорк, Барнс) - Перше видання, що охоплює COBOL 85 - не було опубліковане до 1990 року. Я не впевнений, але я вважаю, що видання "Методичне програмування" COBOL 85 виходило не раніше 1994 року.

Але це не обов'язково представляє світ COBOL, що тягне свої ноги - ну, не так вже й багато. Прийняття нових стандартів вимагає часу для будь-якої мови, навіть зараз.

Провівши більшу частину сьогодні, пишучи COBOL, я думаю, що можу дати деякий поточний внесок.

Спочатку BAD речі: -

• Немає викликів функцій. Сучасний COBOL має деякі вбудовані функції, але це серйозна інженерна робота - написати власне.
• Немає перевірки типу дзвінків підпрограми. Ви можете передавати (або не передавати) що-небудь під час виклику підпрограми; викликана підпрограма буде припускати, що він має правильні параметри, і немає способу виявити відсутні або недійсні параметри.
• Без бібліотек. Жодного нульового пшику. Ні стандартних бібліотек, ні широко використовуваних легко доступних бібліотек. Ви в кінцевому підсумку кодуєте загальнодоступні завдання вручну і знову.
• Все реалізується як ключове слово. Оскільки автори мови не мають поняття бібліотеки, кожна нова функція закінчується реалізацією нових ключових слів, наприклад PARSE та RENDER для підтримки XML.

Нерозумілими, тобто тими закидами, які зазвичай прирівнюються до дорогої старої мови, які є недійсними або неактуальними.

• Багатослівність. Отже, ви набираєте кілька зайвих символів! Це несерйозне питання. У багатьох випадках COBOL менш багатослівний, ніж, наприклад, Java.

• "ФАЙЛИ КОБОЛУ" Ви бачите, що цей термін обмежений навколо. Немає такого поняття, що COBOL може працювати з будь-яким файловим форматом і з будь-якою організацією файлів.

• Немає багаторізкових різьб. У середовищах, де процвітає COBOL, багатопотокова передача зазвичай залишається контейнерам додатків, таким як CICS або IMS, які в цьому хороші, а не програмістам, які в цьому погані.

І хороший матеріал - деякі аспекти COBOL перевершують інші мови: -

• Структури даних COBOL має стислий та гнучкий синтаксис для визначення складних структур даних та непарних типів даних.
• Десяткова арифметика. Він має вбудовану підтримку десяткової арифметики, тобто арифметики, як розуміють бухгалтери, з належним округленням тощо.
• Переїзд з Times. Деякі аспекти COBOL напрочуд сучасні. Вбудована підтримка XML, підтримка OO-програмування, можливість використання класів Java тощо.
• Інтеграція з DB2, CICS тощо. Це стосується лише основної системи IBM COBOL (але це, безумовно, найбільший фрагмент COBOL, який все ще працює), але інтеграція з DB2, CICS та іншими середовищами mainframe полегшує кодування речей, таких як резервна база даних веб-сервіси, ніж у будь-якому іншому середовищі.
• Обробка екрана. Стандартна обробка екрана, реалізована на AS / 400 та MicroFocus Cobol, відмінна.
• Продуктивність. Протягом багатьох років компілятори COBOL виробляли дуже високу продуктивність. Лише рідний C та нативний Assembler обіграли COBOL на мейнфреймі IBM.

Так що загалом це робиться досить добре для того, що було складено комітетом у 1950-х. Якщо наявна програма реалізована в COBOL і виконує завдання, немає підстав для її повторного написання. Однак, якщо немає дійсно вагомих причин, я не бачу жодних виправдань для нових проектів використання COBOL.

Це, мабуть, аж до Джикстра. Джикстра заявив, що "використання COBOL калічить розум; тому його вчення слід розглядати як злочин". Кобола розглядали як наївного, неструктурованого та багатослівного. З умінням самостійно змінювати код (практика, яка відлякує навіть серед кобольських програмістів), це було важко відладжувати або дотримуватися.

Тоді виникає питання великої несумісності і між версіями.

Я б запропонував прочитати розділ критики та захисту у Вікіпедії для мови - http://en.wikipedia.org/wiki/COBOL#Criticism_and_defense

Це вік і багатослівність - це типово те, що змушує людей стогнати.

Здається, я згадую, що головна мета для IBM при розробці COBOL полягала в тому, щоб він "повинен дозволити менеджеру банку написати програму". Ця мета, очевидно, мала глибокий вплив на спосіб розробки мови, і тепер вона розвивалася.

Мабуть, у дикій природі більше COBOL, ніж будь-яка інша мова. Однак, працюючи в ІТ майже 20 років (15 в галузі банківської справи), я ніколи не стикався з єдиною системою, яка в ній була впроваджена.

Що так погано в COBOL?

Нічого.

Я думаю, що люди мають заздалегідь уявлення про те, що старе - це погано, "найновіше - це найкраще" Він ще дуже використовується, і я впевнений, що роботи з обслуговування коду буде достатньо ще півстоліття.

У 1997 році Gartner Group повідомила, що 80% світового бізнесу працює на COBOL з наявністю понад 200 мільярдів рядків коду та приблизно 5 мільярдів рядків нового коду щорічно. (через wikipedia )

При кодуванні завжди слід вибирати найкращий інструмент для роботи, а для певних галузей, які одружені з певним обладнанням, мова є оптимальною. Я ніколи не працював у банківській справі, де чув, що це було популярно, але відповідь Шона вказує, що це не так.

Якщо проблема із застарілим кодом виглядає старовинним, якщо ви можете заштрихувати інтерфейс користувача або веб-інтерфейс перед ним, більшість користувачів навіть не знають різниці.

Люди не люблять COBOL, оскільки він має обмежене застосування. Він був розроблений для бізнесу, фінансів та адміністративних систем для компаній та урядів.

Що усього цього спільного? Дані. Багато і багато даних.

Здогадаєтесь, хто був призначений для стискання даних і має багато файлів на сніданок? Чи можете ви сказати COmmon, орієнтовану на бізнес ?

50 років тому COBOL була найкращою справою для великих організацій, що мали багато даних. Сьогодні існують кращі способи управління великим обсягом даних, тому COBOL вже не є актуальним. Або це?

Розглянемо уряди. Які дані потрібно відстежувати уряду? Ідентифікатори людей, свідоцтва про народження, медичні записи, податки (о ... так ... податки) тощо. І т. Д. І вони повинні зберігати ці відомості нескінченно, як сьогодні, так і 50 років тому.

Люди також дали відгуки банкам у деяких відповідях, і справді банки є великим користувачем COBOL. Чому? тому що, на відміну від інших типів компаній, банки зазвичай мають свою історію. Деякі існують сотні років ( як, наприклад, цей ).

Це означає, що деякі дані за 50 років досі повинні бути з нами сьогодні, 7 жовтня 2011 року. Зараз у нас є SQL Server і C # або Oracle і Java, але 50 років тому було COBOL і файли.

З плином часу дані про державні установи та банки ставали все більшими та більшими, і мігрувати системи було все дорожче. Це означає, що вони повинні залишатися в COBOL і постійно підтримуватись та розвиватися в міру розвитку бізнесу. Деякі банки повільно мігрують, тоді як інші просто притримують приємний інтерфейс Web2.0 перед мейнфреймом (в основному використовуються c # та Java). Чи можете ви сказати застарілий код? (COBOL йде рука об руку з (екстремальним) застарілим кодом, який доторкнувся великою кількістю людей протягом десятиліть існування - інша річ, яку ми не любимо програмістам: D).

А тепер у вас є ніша активності. COBOL зараз має обмежене застосування, і ваш досвід впливає .

І люди, які потрапляють в COBOL, врешті-решт виявляють, що ви робите те саме і знову і знову, рік за роком, і до того часу, коли вони прокидаються, вони вже не є конкурентоспроможними на ринку, тому що люди хочуть PHP, Java, C # , REST, jQuery і лише банки шукають людей COBOL.

У цей момент попит нижчий, ніж пропозиція, і ті, хто не робить скорочення, повинні перейти на щось інше. І вони повинні початись як юніори, оскільки COBOL дійсно калічить розум (повірте, що це не Copy-Paste - це основний стиль розвитку COBOL і пояснює велику його велику продуктивність), і тепер вони проклинають день, коли вони взяли COBOL і не роблять ' не втрачаю жодного приводу розповісти про це свої страхіття :). Але ти можеш розповісти ті історії про будь-яку стару пердецьку мову, яка сьогодні вже не затребувана, але ти - нещасна людина, яка зачепилася за неї. Ну добре ...

PS та COBOL погані з усіх інших причин, про які згадували інші :)

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.Дійсно? І як день це міряв? Чи пішли вони робити кожну компанію словом і запитували їх, скільки у них рядків COBOL чи що?

Дві особливості.

• Заява ALTER - це чисте зло. Хоча рідко використовується в більш сучасних програмах COBOL, він широко використовувався в "старі часи", оскільки він був більш ефективним, ніж еквівалентна структура "IF-GOTO". Коли комп'ютери мали лише 32 Кб оперативної пам’яті, кожна інструкція мала значення. Він змінив оператор GOTO, щоб мати інше призначення.

  Це зробило якийсь код непрозорим, оскільки сам код мав стан.

• Заява REDEFINES у структурі даних (як unionin у C) - це вічна проблема. Термін "вільний союз" - тобто накладені структури даних без дискримінатора - це спосіб узагальнити проблему. Два Псевдоніми ПОВЕРНЕНО не можна тривіально розрізнити за даними; лише широке читання програмної логіки могло визначити значення двох альтернативних інтерпретацій байтів.

  Це зробило багато структур даних непрозорими, оскільки їх неможливо зрозуміти без коду.

Читання англійського синтаксису було переможене цими двома конструкціями.

[Мене попередили модератори, що короткі відповіді не відповідають вашому важливому і цікавому питанню. Якщо ви вважаєте це зневажливим, ви можете запитати подробиці. Або позначте його, щоб модератори могли його видалити.]

Я програмував у COBOL кілька хороших років. Його синтаксис простий порівняно з сучасними мовами, і вам не потрібно багато теорії, щоб навчитися йти. COBOL дуже добре співпрацював з CICS IBM (система он-лайн управління транзакціями), і програмісту потрібно не зазначати в коді, щоб масштабувати кількість користувачів додатків від 1 до декількох тисяч. CICS забезпечив інтерфейс на основі символів, який працював із екраном як одиницею відображення (без вікон). Ви можете відображати діаграми за допомогою (GDDM IBM) в мейнфреймі. COBOL може спілкуватися з індексованими файлами (VSAM та ISAM), а також DB2 (реляційними на основі SQL), а також IMS. COBOL / CICS - це дуже міцне середовище, і ви можете навчитися цьому за кілька тижнів. Це означає, що ви зосереджуєтесь на бізнесі, а не на технології, тому ви працюєте 7 із 8 годин над кодуванням, а не вивчаючи MVM, JavaScript тощо.

Проблема з COBOL - це поганий маркетинг, який призводить до відсутності зацікавленості сторонніх розробників інструментів та середовищ програмування для нього. Крім того, його відсутність підтримки інтерфейсу Windows, що призвів до зниження його популярності після 1993 року. Вартість мейнфрейму змусила клієнтів шукати альтернативи та компілятори для COBOL, які були доступні в UNIX та DOS. Мова C притягувала велику частину світла, оскільки вона могла бути більш портативною і мала прямий доступ до функцій ОС, що у COBOL було дуже мало.

Такі мови, як VB, DBase, FoxPro та Clipper, мали кращі способи доступу до "баз даних" на ПК, ніж порівнянні з COBOL в DOS, тому COBOL втратив. CICS довго не дешевився в DOS або UNIX, тому його значення в цих середовищах не було.

Сьогодні COBOL підтримується .NET, але я думаю, що він програв битву на всіх платформах, крім мейнфрейму (і, можливо, AS / 400), де він все ще є через величезну кількість критично важливих програм, які повністю залежать від це.

Хе, я пішов до коледжу на початку 80-х, і люди тоді були презирливі COBOL. Я думаю, що найбільша проблема - це його багатослів’я - просте "Привіт, світ!" у COBOL, мабуть, понад п’ятдесят ліній, 95% з яких потрібні котельнями. Це просто не дуже елегантна чи приваблива мова. Він також був розроблений для вирішення вчорашніх проблем, і насправді не піддавався парадигмам розвитку, розробленим після 1970 року. Це досить гарна мова створення звітів - до тих пір, поки ваші звіти нескінченні стовпці номерів із заголовками та колонтитулами. Якщо ви хочете десь наклеїти графік або логотип, забудьте про це. Я думаю, що це все ще найшвидша мова для завдань типу "обробка даних" (візьміть файл фіксованого формату з трансакціями 5M банкоматів і зробіть просту коригування балансу для кожної), але скільки розробників такі речі вже роблять? І сьогодні багато систем використовують XML або JSON, мені б не хотілося думати про спробу проаналізувати щось подібне з COBOL (насправді, мені б не хотілося думати про розбір взагалі в COBOL!)