COBOL v5 – A ‘Brave’ New World

[Dmitry67]

Почитал кстати про кобол.
Чего стоят "особый смысл" уровней 66 и 77 )))
Или мины, котоыре провидят неизвестно к чему
В общем язык провоцирует написание монолитного кода

[iDesperado]

Кодировать надо интерфейсы, а не реализацию.

[ARARAT.]

Без готовых функций просто никак не могут, постоянно где-то "сдирают" готовые куски кода/фукции.

Это кстати правильный, современный подход. Кодировать надо интерфейсы, а не реализацию. Реализации щаз пруд пруди и проще нагуглить, да и готовый код надежней.
Что херовые языки уродуют мозг согласен. С тем же согласен, что правильные языки правильно форматируют и настраивают на позитивный лад.

Вся проблемма, что кем-то написанный код преследует кем-то заложенную задачу и кем-то заложенные ограничения на етот код...
Kак он себя поведет в твоей задаче, а самое главное за пределами твоей задачи(например значения входных данных выйдет за "расчетные"(да и какие они были ети "расчетные" у первоначального кодеписателя), памяти необходимой не окажется, необходимого процессорного времени не окажется, I-O "застрянет", net застрянет, синронизация с другими частями нарушится и т.д, да елементарно логические условия выйдут за пределы, а он их всех не описал(забыл, не знал, у него не вылезло)) только однoму богу известно, поскольку даже изначальному кодописателю ето может быть не известно.
Не твой код, не ты ето писал, отлаживал и тестировал...
Kак такое можно в production пускать я не понимаю, поетому и сидят они на нем в режиме "механиков" 24х7, так как он слетает в етом же режиме.

[OtherSide]

Без готовых функций просто никак не могут, постоянно где-то "сдирают" готовые куски кода/фукции.

Это кстати правильный, современный подход. Кодировать надо интерфейсы, а не реализацию. Реализации щаз пруд пруди и проще нагуглить, да и готовый код надежней.
Что херовые языки уродуют мозг согласен. С тем же согласен, что правильные языки правильно форматируют и настраивают на позитивный лад.

Вся проблемма, что кем-то написанный код преследует кем-то заложенную задачу и кем-то заложенные ограничения на етот код...
Kак он себя поведет в твоей задаче, а самое главное за пределами твоей задачи(например значения входных данных выйдет за расчетные, памяти необходимой не окажется, необходимого прецессорного времени не окажется, синронизация с другими частями нарушится и т.д.) только однoму богу известно, поскольку даже изначальному кодописателю ето может быть не известно.
Не твой код, не ты ето писал, отлаживал и тестировал...
Kак такое можно в production пускать я не понимаю, поетому и сидят они на нем в режиме "механиков" 24х7, так как он слетает в етом же режиме.

Грамотно написанный код гибкий и достаточно абстрактный, что бы решать максимальный круг задач. Работа современных программистов это грамотно скрутить готовые куски кода, а не писать что-то свое.
Сложность проектов возрасла на порядки, и изобретать велосипеды просто нет возможности

[ARARAT.]

Без готовых функций просто никак не могут, постоянно где-то "сдирают" готовые куски кода/фукции.

Это кстати правильный, современный подход. Кодировать надо интерфейсы, а не реализацию. Реализации щаз пруд пруди и проще нагуглить, да и готовый код надежней.
Что херовые языки уродуют мозг согласен. С тем же согласен, что правильные языки правильно форматируют и настраивают на позитивный лад.

Вся проблемма, что кем-то написанный код преследует кем-то заложенную задачу и кем-то заложенные ограничения на етот код...
Kак он себя поведет в твоей задаче, а самое главное за пределами твоей задачи(например значения входных данных выйдет за расчетные, памяти необходимой не окажется, необходимого прецессорного времени не окажется, синронизация с другими частями нарушится и т.д.) только однoму богу известно, поскольку даже изначальному кодописателю ето может быть не известно.
Не твой код, не ты ето писал, отлаживал и тестировал...
Kак такое можно в production пускать я не понимаю, поетому и сидят они на нем в режиме "механиков" 24х7, так как он слетает в етом же режиме.

Грамотно написанный код гибкий и достаточно абстрактный, что бы решать максимальный круг задач. Работа современных программистов это грамотно скрутить готовые куски кода, а не писать что-то свое.
Сложность проектов возрасла на порядки, и изобретать велосипеды просто нет возможности

Дело не в велосипедах совсем, дело в желании быстренько стряпать что-то "на коленке", тот самый "коленочный подход"...
От него все беды с несконечными updates и исправлениями.
Фундаментальности около нуля, зато желание что-то по быстрому "рубануть" и "сплавить" хоть отбавляй...
И потом еще сидят "всю жизнь" на его поддержании(как механики) в полу-рабочем состоянии.

[Komissar]

Работа современных программистов это грамотно скрутить готовые куски кода, а не писать что-то свое.

А как же job security?!!

[OtherSide]

Дело не в велосипедах совсем, дело в желании быстренько стряпать что-то "на коленке", тот самый "коленочный подход"...
От него все беды с несконечными updates и исправлениями.
Фундаментальности около нуля, зато желание что-то по быстрому "рубануть" и "сплавить" хоть отбавляй...

Вы так говорите, как будто в желании по быстрому рубануть и сплавить есть что-то плохое.
На самом деле сложность ПО за последние 20-30 лет выросла на порядки.
Если Билла Гейтса сделал миллионером бейсик, созданный за полтора месяца, то сейчас месяц будут только вебморду на бумаге рисовать. Потратят несколько миллионов, что бы потом пользователь еще носом крутил, что дескать че за дела, в бесплатный софт рекламу вставили, он такое пользовать не согласен

[ARARAT.]

Дело не в велосипедах совсем, дело в желании быстренько стряпать что-то "на коленке", тот самый "коленочный подход"...
От него все беды с несконечными updates и исправлениями.
Фундаментальности около нуля, зато желание что-то по быстрому "рубануть" и "сплавить" хоть отбавляй...

Вы так говорите, как будто в желании по быстрому рубануть и сплавить есть что-то плохое.
На самом деле сложность ПО за последние 20-30 лет выросла на порядки.
Если Билла Гейтса сделал миллионером бейсик, созданный за полтора месяца, то сейчас месяц будут только вебморду на бумаге рисовать. Потратят несколько миллионов, что бы потом пользователь еще носом крутил, что дескать че за дела, в бесплатный софт рекламу вставили, он такое пользовать
не согласен

Не сложность выросла, а ее "выросли" вот такими подходами к программированию...
Стабильность ужастная, постоянные updates и исправления, стоимость огромная просто в long run, поетому и стоимость прoдукта огромна.
Вроде поначалу стоимость "изготовления" небольшая, а что наняли таких кодописателей, они натаскали куски быстренько что то стряпали, там подкрутили, здесь подтянули, вроде как-то заработало, после первого удачного прогона пустили, а потом всю жизнь сидят на его поддержании. И все ето входит в стоимость продукта в конечном итоге и в головные боли пользователей и их затраты кстати...
А так нечего конечно...

PS Кстати, и при етом ети кодописатели требуют зарплат "врачей" почему то...? Одни учатся десятилетиями и ответственность огромная, а у других "два класс образования младшей школы"(еквивалент научиться код писать) и чужие куски кода "под рукой" с нулем ответственности...

[OtherSide]

1 Не сложность выросла, а ее "выросли" вот такими подходами к программированию...

2 Стабильность ужастная, постоянные updates и исправления, стоимость огромная просто в long run, поетому и стоимость прoдукта огромна.
Вроде поначалу стоимость "изготовления" небольшая, а что наняли таких кодописателей, они натаскали куски быстренько что то стряпали, там подкрутили, здесь подтянули, вроде как-то заработало, после первого удачного прогона пустили, а потом всю жизнь сидят на его поддержании. И все ето входит в стоимость продукта в конечном итоге и в головные боли пользователей и их затраты кстати...
А так нечего конечно...

1 Что за ерунду вы пишите. Ну взять игры хотя бы. Дум написала комманда из 5 человек за несколько месяцев. Сейчас игры пишут по 5 лет 300 человек за 100 млн долларов. Тоже самое по другим отраслям. 6 версия 1С без слез не взглянуть - уровень курсовой работы, а на этом продукте выросла одна из ключевых русских IT компаний

2 Стабильность как раз ужасная у тех, кто пишет на коболе, где возможность повторного использования кода минимальная, все свои велосипеды городят, в этом все зло

[Helmsman]

Странные вещи Вы пишете. Повторное использование кода не имеет ни малейшего отношения к языку. Просто кобол часто используется в таких задачах, где reuse в принципе не нужен/невозможен.

[flip_flop]

А вот какая эволюция Кобола за все 100 лет его развития? Ну, например ФОРТРАН изменился сильно, сейчас у него и все структурные элементы и динамические массивы и ООО и Visual, вообщем любо дорого смотреть: и работу делает и мозги не калечит При этом эффективность осталась и даже выросла для его задач. Такой динозавр как Кобол тоже должен был бы быть адаптирован под современные нужды, нет?

[zVlad]

....Иногда приходится изголяться, сильно использовать "service calls"(вызов системных функций, a OpenVMS имеет просто гиганскую библиотеку их, охнереть просто, вот у меня книжек по библиотекам OpenVMS штук едак 30-50 на полке лежат рядом, там блин все что хочешь можно найти), часть писать непосредственно на DCL(batch язык OpenVMS), комбинировать, работать вплотную с самой OpenVMS(процессы, I-O, память, стреамс и прочее) что-бы что-то сделать едакое(неподвластное самому Коболу) на нем, но все решаемо вообщем то...
И кстати очень интересно, все ети связки, комбинации очень хорошо, мне именно ето больше всего нравится!!!
Мозги временами "вскипают", отлично просто!!!

PS C кстати тоже самое, сам язык довоьно простой(операторы языка и их применние), остальное и самое главное ето именно библиотeки, так и здесь диназавр язык Кобол и огромные библиотеки самой OpenVMS OS. Поетому я наверно и прижился на Коболе...

Пораспросил нашего кобол програмиста (хотя знал и сам что он скажет) насчет "книжек по библиотекам" нашей системы, которая zOS. Их у него нет ни одной и он никогда не занимается, в своем програмировании, "процессами, I/O, памятья, streams" ничем таким кроме управления запросами в DB2.
Дело в том что всем этим занимается CICS, в котором его Кобол програмы выполняются, и сама система. Кроме того, проложение наше имеет так называемые архитектурные модули написанные вендором и выполняющие определенные функции полезные для этого конкретного приложения. Доступ к DB2, например, управление профаилами конечных пользователей, управление диалогом, и т.п.. Но и эти модули написаны с минимальным вовлечением "system calls" большенство из которых это CICS calls, не zOS. В конечном счете, eсли что не так то подключаемся мы, системщики и помогаем либо с CICS, либо с zOS в зависимости от проблемы. Я так понимаю что в zOS/CICS системные функцию работают само по себе, их не надо просить, звать, направлять используя "service calls". Не надо думать что их вообще нет. Они есть, и их много, они документированы. Но они в основном используется внутри, например, CICS, или DB2. Или если вы хотите что-то такое запрограмировать, особенное. Например, я предлагал запрограмировать "single sign-on" без необходимости сначала логиниться в свой work station, и потом в приложение. Как видите это шло от системщика, не от наших програмистов на коболе. В это состоит большое отличие даже между двумя, казалось бы однотипными - mainframe, платформами.
Программисты Кобол на zOS занимаются только Коболом как таковым и проблемами Кобола, которых, как я понимаю, совсем не много.

Что касаемо "динозаврами". Часто используют это слово просто потому что не имеют ничего толкового, конкретного сказать. А из Вашего, ARARAT, конкретного рассказа (который было интересно читать) становится понятным что "динозавром" является не Кобол, а OpenVMS с его библиотеками, которые надо использовать.

[Helmsman]

А вот какая эволюция Кобола за все 100 лет его развития? Ну, например ФОРТРАН изменился сильно, сейчас у него и все структурные элементы и динамические массивы и ООО и Visual, вообщем любо дорого смотреть: и работу делает и мозги не калечит При этом эффективность осталась и даже выросла для его задач. Такой динозавр как Кобол тоже должен был бы быть адаптирован под современные нужды, нет?

Что такое "современные нужды"? Навскидку, добавилась возможность OOP, и, может, ещё какие-то мелочи. Но и это всего лишь инструмент, которые далеко не всегда нужен.

[zVlad]

А вот какая эволюция Кобола за все 100 лет его развития? Ну, например ФОРТРАН изменился сильно, сейчас у него и все структурные элементы и динамические массивы и ООО и Visual, вообщем любо дорого смотреть: и работу делает и мозги не калечит При этом эффективность осталась и даже выросла для его задач. Такой динозавр как Кобол тоже должен был бы быть адаптирован под современные нужды, нет?

http://www-03.ibm.com/software/products ... coboforzos" onclick="window.open(this.href);return false;

P.S. http://www-03.ibm.com/software/products ... -z-systems" onclick="window.open(this.href);return false;

[flip_flop]

А вот какая эволюция Кобола за все 100 лет его развития? Ну, например ФОРТРАН изменился сильно, сейчас у него и все структурные элементы и динамические массивы и ООО и Visual, вообщем любо дорого смотреть: и работу делает и мозги не калечит При этом эффективность осталась и даже выросла для его задач. Такой динозавр как Кобол тоже должен был бы быть адаптирован под современные нужды, нет?

http://www-03.ibm.com/software/products ... coboforzos" onclick="window.open(this.href);return false;

P.S. http://www-03.ibm.com/software/products ... -z-systems" onclick="window.open(this.href);return false;

А можно своими словами, без ИБМ и без zOS? Их читать я не буду точно Или Кобол в принципе не может быть отвязан от МФ? Говорим Кобол, подразумеваем МФ?