IT в России и мире в реалиях мирового кризиса
1,283,842 7,813
 

  Oleg K. ( Слушатель )
14 апр 2020 22:52:07

США из-за коронавируса срочно ищут знатоков COBOL. И не могут найти.

новая дискуссия Новость  631

ЦитатаВласти американского штата Нью-Джерси начали поиски программистов, знающих язык COBOL, из-за возросшей в связи с коронавирусом нагрузки на старые ПК в американской системе занятости. Как пишет The Register, специалистам потребуется обновить программное обеспечение на мейнфреймах 40-летней давности, которые перестали справляться с нагрузкой, резко выросшей на фоне увеличившегося числа безработных из-за пандемии CoVID-19.
Проблема нехватки знающих COBOL программистов затронула не только Нью-Джерси. В штате Коннектикут власти тоже ищут специалистов по этому языку, притом в этом случае поиск ведется совместно с чиновниками еще трех штатов. Tom’s Hardware пишет, что их усилия, как и в Нью-Джерси, к успеху пока не привели. https://www.tomshardware.com/news/new-jersey-cobol-coders-mainframes-coronavirus
Согласно опросу Computer Business Review (https://www.cbronline.com/news/cobol-code-bases) , проведенному в I квартале 2020 г., с проблемой необходимости модернизации ПО в настоящее время сталкиваются 70% компаний, по тем или иным причинам до сих пор использующим программы, написанные на COBOL. Точное количество таких предприятий неизвестно, но, по информации Reuters, во всем мире в 2020 г. используется 220 млрд строчек кода этого языка.
COBOL активно применяется не только в системах занятости, но и в финансовых организациях. На 61-летнем языке написано 43% приложений, используемых в банковских сферах, и 95% банкоматов по всему миру в тех или иных масштабах используют созданное с его помощью ПО.
К числу причин, по которым организации не спешат отказываться от COBOL и переходить программы, созданные при помощи актуальных языков программирования – это дороговизна обновления. На своем примере это доказал Банк содружества Австралии, решившийся на полную замену всех приложений, написанных на COBOL.
Представители банка сообщили, что переход на новое ПО занял пять лет – он проходил в период с 2012 по 2017 гг. Размер затрат на это крупномасштабное мероприятие известен – апдейт обошелся банку почти в $750 млн.

https://www.cnews.ru…onadobilis
Интересно, заставит ли коронавирус их отказаться от COBOLа?Улыбающийся
Как раз и люди будут - переписать систему на сильных-модных-молодежных технологиях. Всяко лучше, чем "дороги строить".
  • +0.00 / 0
  • АУ
ОТВЕТЫ (37)
 
 
  Explorer-2000 ( Слушатель )
14 апр 2020 23:21:05

Ну ответ очевиден, собственно он в вашем же сообщении про австралийский банк. Силами самих компаний это уже просто не возможно сделать.
  • +0.03 / 2
  • АУ
 
  adolfus ( Слушатель )
21 апр 2020 21:46:00

Слабо верится, что можно переписать "240 миллиардов строк кода" с кобола за обозримое время на языки другой парадигмы програмирования.
И не просто строк кода, а строк кода управления данными. А сам язык достаточно прост и специально заточен именно на эффективную работу с данными. Существенная часть этой работы выполняется на мейнфрейме с помощью сервисов, функциональных аналогов которым вне мейнфреймов не существует. Это CICS и прочий мелкий сугубый ISAM. Переписать эту часть с помощью бродячих музыкантов непонятно каких программистов даже в среднесрочной перспективе нереально. Можно переписать клиентский терминальный софт, но только теоретически. Без того, чтобы разобраться с кодом, а для этого нужно владеть коболом, знаниями о инфраструктуре его среды исполнения, о структуре данных и деталях транзакций на сервисах мейнфрейма, это сделать не получится. А уж если с этим разобрался, то пропадает всякий смысл переписывания на современные технологии – проще написать на коленке транслятор с кобола в ассемблер.
По коболу в части терминального софта есть нормальное решение – транслятор с кобола в байт-код явы. Другая сторона вопроса - что делать со старыми мейнфреймами. Тут самым очевидным выходом будет создание в рамках корпорации IBM подразделения, которое займется решением проблемы для всех, кто десятилетиями оттягивал свой конец и таки попал. А само решение будет таким, чтобы сохранить  всех клиентов IBM и, возможно, привлечь новых. То есть, напишут свой транслятор с кобола на яву и децел утилит для конвертирования данных со старых мейнфреймов в облако или на сервер с DB/2. Ну, или вдруг что-нибудь сдохнет в лесу и IBM выпустит мейнфреймовские сервисы в виде промежуточного слоя для DB/2.
Другого выхода нет – из кобола выход только в кобол.
Кстати, сервера, где можно найти курсы и прочую инфу по коболу, повально лежат по 503 – все мечтают побыстрее стать кобол-программерами.


Пару дней назад на хабре выложена статья "Заложники COBOL и математика". В частности, цитата из нее
ЦитатаКогда речь заходит о языке программирования COBOL — первый вопрос, который всплывает у всех в голове, всегда выглядит так: «Почему человечество всё ещё использует этот язык во множестве жизненно важных областей?». Банки всё ещё пользуются COBOL. Около 7% ВВП США зависит от COBOL в деле обработки платежей от CMS. Налоговая служба США (IRS), как всем хорошо известно, всё ещё использует COBOL. В авиации тоже используется этот язык (отсюда я узнала одну интересную вещь на эту тему: номер бронирования на авиабилетах раньше был обычным указателем). Можно сказать, что множество весьма серьёзных организаций, идёт ли речь о частном или государственном секторе, всё ещё используют COBOL.
  • +0.15 / 9
  • АУ
 
 
  qurvax ( Слушатель )
22 апр 2020 14:12:37

А в чем по сути проблема с коболом то? Какая религия мешает написать интерпретатор кобола для х86/АRМ/ещечето?
  • +0.01 / 2
  • АУ
 
 
 
  ivan2 ( Слушатель )
22 апр 2020 14:24:50

Суть проблемы в том, что он у них там сертифицирован для "деньги считать". Нет замены.
  • +0.03 / 1
  • АУ
 
 
 
 
  qurvax ( Слушатель )
22 апр 2020 14:27:20

Ну так и ок, пусть и дальше на нем считают. Мэйнфреймы древние - ну так родите новые. Или пишите интерпретаторы и обвес под существующие современные платформы. Непонимаю, в чем такая уж проблема. Небось только лишь в том, что кобол-програмисты не хотят работать за банан, как ява-макакиУлыбающийся
  • +0.04 / 3
  • АУ
 
 
 
 
 
  adolfus ( Слушатель )
23 апр 2020 05:07:42

Мейнфреймы гораздо новее, чем многим кажется. Уж что касается железа, то вообще, безусловно и во все времена.
Интерпретаторы – это несерьезно для бизнес-приложений. Назовите хоть один, за которым стояли бы ANSI, ISO, OpenGroup или еще какие-нибудь серьезные организации.
Так называемые "современные платформы" сосут по всем статьям у мейнфреймов, и особенно по стоимости транзакций.
Кобол-программисты даже в голодные 90-е на просторах СНГ получали от двух штук баксов белыми. Просто сейчас они повывелись.
  • +0.02 / 1
  • АУ
 
 
 
 
 
 
  qurvax ( Слушатель )
23 апр 2020 07:39:52

Т.е. им перестали платить ("соптимизировали)? Ничего другого реалистичного в голову чето не приходит.
Это ваше "сосут" надо б обосновывать хоть как-то, или уточняйте что имелось в виду. "Современные платформы" тоже разные бывают. Кстати, что имеется в виду под словом "транзакция" в контексте упомянутых систем, тоже понятно не только лишь всем.
  • +0.00 / 0
  • АУ
 
 
 
 
 
 
 
  adolfus ( Слушатель )
23 апр 2020 21:12:36

1) Конечно перестали – мертвым не платят, а живые съехали. К началу 2000-х на просторах СНГ их практически не осталось. На EC ЭВМ стоял компилятор кобола и он достаточно активно использовался. По крайней мере, в середине 80-х каждый третий из моих знакомых программистов с ним имел дело на регулярной основе. Последний из тех, кого я знал, уехал в начале 2000-х. До этого он десять лет работал "на удаленке" через представительство IBM в Минске. Модем хайес аккура + америка онлайн = 9600 бод. Как только дети школу закончили, так он всей семьей и уехал.
3) Что такое "транзакция"? Это атомарно выполняемая инструкция (команда или операция, если хотите) любого уровня, который выше архитектуры набора инструкций (ISA). Например, захват мютекса. Или поперечная ACID-транзакция СУБД, обновляющая все потомки в первичном ключе и все чвязанные с этим вторичные ключи. Или элементарная продольная, вычисляющая какой-нибудь агрегат, типа статистики. Или бекап/восстановление всей БД. Или гарантированная передача пакета. По шине, по сети... Многое из этого транзакцией не называют, тем не менее, понятно что это такое – что угодно, изменяющее состояние вычислительной системы, какой бы она не была, не нарушающее  принципа ACID в отношении этой самой системы (соответсвенно, и задействованной подсистемы, какой бы она не была) в целом. Очень перегруженное понятие, тем не менее, абсолютно идентифицируемое на любом из уровней, где это понятие имеет смысл. 
В отношении обмена ресурсами, если грубо посмотреть, это атомарное списание некоторого количества ресурса с одного счета и зачисление этого количества на другой таким образом, что время на эту процедуру  во временном пространстве соотвествующего бизнеса равно нулю. У одного хевисайд упал, у другого поднялся, причем одно и другое совершилось в один и тот же момент времени.

2) Если быть точным, то соременные платформы – это, в том числе, и мæйнфреймы. Но Вы, как я понимаю, за "современные" держите исключительно те, что имеют архитектуру набора команд x86. Ну хорошо, есть не последние x86_64 сервера Supermicro c инфинибэндом и SAS-дисками. Или что-то есть лучшее? Скорее всего все это лучшее – такое же.  Однако между железом и приложениями есть прослойка в виде сами понимаете чего. Миддлварь, называется. Именно эта прослойка чут менее, чем полностью определяет юзабилити всей системы, в том числе и стоимость этой самой транзакции. Ну там еще есть и такой параметр, как полная стоимость владения технологическим решением ... например, в течение сорока лет. Так уж случилось, что эта самая миддлварь в приличном с точки зрения бизнес-затрат виде имеется в наличии только у IBM, как и то, что у них стоимость владения технологическим решением на круг самая низкая. Банкиры не дадут соврать.

Вы спросите – а что же будут кушать программисты для платформ с пятидлетним сроком существования, а также их  IT-пастухи, если руководство решит, что нужно спланировать на 40 лет вперед и закупиться IBM System z? Тридцать лет назад некто Sosha, автор двухпанельника Norton Commander, сказал  - они будут есть картофельные очистки.
  • +0.07 / 4
  • АУ
 
 
 
 
 
 
 
 
  qurvax ( Слушатель )
24 апр 2020 08:32:48

Платить не перестали, а они сами уехали. "Самонасралося", пнятно. А в штатах тоже "уехали"?



Очень интересно, но ничего не понятно. Упоминалась некая "цена транзакции", которая "меньше" у "мейнфреймов", чем у "других". Вот я и спрашиваю, "цена" чего именно. Чтобы уяснить, а не для спора.


Неверно понимаете. Я вполне осознаю, что х86 не везде оптимален, и его основной плюс - наличие туевой хучи кода под него написаного. А остальное - минусыУлыбающийся "Современные" в моей понимании и есть "современные", т.е. выпускаются, поддерживаются производителями, у которых есть для этого специалисты, которые, в свою очередь, магическим образом не закончатся как только помре Петрович.


Меня угораздило работать в местах "побогаче". Впрочем, железки не показатель богатства. Вот акамай, нопример, для своих CDN-кешей не заморачивается крутожелезками, а юзает откровенный шлак, которому и до супермикро как раком до китая. И ниче. Как так можо? Да просто - за счет архитектуры собственно системы выползают. Лохи не лохи, а отгрохали вона какой CDN'чик.


МдаУлыбающийся Ну мы не настолько богатые. Хотя стремимся. А про банки - тоже разные бывают. Я вот знаю более двух, где междельмаш имеет место быть лишь во влажных мечтах тамошних админов.


СистемЗю в каждую хату? Я только заУлыбающийся Где записаться на светлое будущее?
  • +0.01 / 1
  • АУ
 
 
 
  adolfus ( Слушатель )
23 апр 2020 04:49:06

А зачем нужен интерпретатор кобола, если есть трансляторы? Проблема не в коболе, а в том, что программистов нет.
  • +0.03 / 1
  • АУ
 
 
  Oleg K. ( Слушатель )
23 апр 2020 21:15:57

А что мешает взять и выкинуть эти миллиарды строк кода, заменив системы полностью? Три вещи: лень, коррупция и страх.
  • -0.05 / 2
  • АУ
 
 
 
  TAU ( Слушатель )
23 апр 2020 21:18:08

Нет. Мешает разум и умение считать. Читайте внимательнее мое сообщение выше!
  • +0.03 / 1
  • АУ
 
 
 
 
  Oleg K. ( Слушатель )
23 апр 2020 21:31:08

Прочитал и ответил. Ну что ж - у нас несколько разные взгляды на исходные причины. Вот вам, видимо, не кажется странным, что только кобол "сертифицирован" для бизнес-операций (правда я не знаю, действительно ли это так), а мне - кажется. И на засилье одного языка в течении полувека всегда есть причины, обычно никак не связанные с его потребительскими характеристиками.
  • -0.05 / 2
  • АУ
 
 
 
 
 
  adolfus ( Слушатель )
23 апр 2020 21:43:58

Кобол сертифицирован не для бизнес-операций, а просто сертифицирован. Сертифицирован, как язык, обеспечивающий стабильное поведение написанных на нем программ и переносимость в рамках стандарта. Этих языков всег четыре – ada, c, cobol и fortran. Все остальное создано не для тех, кто использует программы, а для тех, кто их пишет. Т.е. они нарушают основной принцип организации технических систем – выбирается главное свойство, которое нужно обеспечить, и оно возводится в абсолют, а все остальное по остаточному принципу.
  • +0.05 / 3
  • АУ
 
 
 
 
 
 
  Oleg K. ( Слушатель )
23 апр 2020 21:51:07

А почему Java с её Languave Specification (довольно подробной и качественной) не в этом списке? Хотя, наверное, её скоро постигнет та же самая участь, что и КОБОЛ.
Обилие КОБОЛа в системах - это особенность исторического развития программных систем в США. Аналогичное обилию узкоспециализированного ПО только под windows.
Это не связано с потребительскими свойствами самих языков почти никак. Просто, кто раньше встал - того и тапки.
Вообще говоря, нельзя заменить одного монстра на другого (большую систему на КОБОЛе на другую такую же большую систему на С). Да и не нужно это. Жаловаться на протяжении 20 лет на нехватку специалистов для серьезных крупных компаний - это лишь оправдание собственной некомпетентности и нежелания брать ответственность за возможные проблемы. "Работает - не трогай, ничего не делай, ничего не меняй".
  • -0.05 / 2
  • АУ
 
 
 
 
 
 
 
  adolfus ( Слушатель )
23 апр 2020 23:02:08

У java и ее инфраструктуры проблема с патентами, поэтому ей принципиально не светит попасть в список сертификации.
Второе – потребительские свойства языка полностью определяются потребительскими свойствами программ, на них написанных, а не мнениями, желаниями и умениями программистов. Как сказал, забыл кто, "если вы не можете выразить идею в прграмме на языке высокого уровня, пишите ее на ассемблере, если и на ассемблере у вас есть проблемы с задачей, пишите прямо в машинных кодах (db, dw, dd  в секции .text)? Ну уж если и это вам не помогает, то скорее всего вы неправильно сформулировали задачу".
В документе о переносимости, где четко упоминаются четыре сертифицированных языка, есть раздел, как следует (will) выбирать языки, технолгии и даже компоненты третьих сторон (если это разрешено) при работе над проектом. Там два разделы – один, что учитывается, а второй, что учитываться не должно. В частности, на решение об используемых языках не должны влиять факторы, связанные с существующими навыками и предпочтениями членов коллектива. Зато там упоминается такие факторы, как возможность формальной верификации корректности кода и возможность пошаговой символьной отладки. Т.е. если язык не императивный, вы его не можете использовать для программирования приложений. Достаточно, чтобы при пошаговой отладке была возможность пропустить хоть маленький кусочек кода, чтобы язык был исключен из рассмотрения (привет вам, конструкторы/деструкторы языка C++).
  • +0.03 / 1
  • АУ
 
 
 
 
 
 
 
 
  Oleg K. ( Слушатель )
24 апр 2020 00:54:28

Наверное, вы правы.

Категорически не согласен. Из-за чего программа для пользователя обязана быть удобной и быстрой в настройке, если она написана на "удобном и быстром в настройке" (для программиста) языке программирования?

А можно этот документ где-то посмотреть? 
P.S. Если подразумевать под пошаговой отладкой реальное исполнение - то формальная верификация исполняемого кода закончилась давным давно - сначала её пошатнул защищённый режим, а потом добили регистры управления виртуализацией. Байт код джавы точно так же можно спокойно просматривать под микроскопом, исполнять пошагово и всё остальное. Но по ней спор закончили - она вся в патентах. Пусть будет С.
  • -0.03 / 1
  • АУ
 
 
 
 
 
 
 
 
 
  Andrew Carlssin ( Слушатель )
24 апр 2020 02:14:41
Сообщение удалено
Andrew Carlssin
16 май 2022 04:27:30
Отредактировано: Andrew Carlssin - 16 май 2022 04:27:30

  • +0.05
 
 
 
 
 
 
 
 
 
 
  Oleg K. ( Слушатель )
24 апр 2020 15:55:46

Ну примерно про это я тоже и говорю - пока петух не клюнет - причин переходить на другое ПО нетУлыбающийся
Причем в целом такой подход правилен и выгоден. Просто если долго "затягивать" (по-моему - больше 20 лет в ИТ оставаться на одной платформе - это "долго").
Никто не предлагает гнаться за модой и два раза в день менять платформу разработки, но в остальном... Наши компании, у которых серьезная часть документооборота прибита к 1С может постичь аналогичная участь.
P.S. В крупной компании того, кто предложит что-то там обновить в ПО заклюют сразу, проект сделать ему не дадут и выживут из компании, поэтому - "дураков нет", никто таскать каштаны из огня не будет. Таковы реальные законы развития крупных компаний.
  • +0.00 / 0
  • АУ
 
 
 
 
 
 
 
 
 
 
 
  Explorer-2000 ( Слушатель )
24 апр 2020 16:38:56

Ну это не верно, в крупных компаниях постоянно переписывают и обновляют ПО, проблемы с программами на COBOL в западных компаниях в том что они были разработаны очень давно (хотя есть до сих пор системы на мэйнфреймовском ассемблереПодмигивающий) тогда не то что интернета не было, но даже индусов ещё не былоВеселый, поэтому переписывать  их не имеет смысла ни на каком языке, нужно делать совсем другую систему с нуля ну а тут вон пример австралийского банка 5 лет и около миллиарда долларов, руководство компаний понимает, что надо что то делать, но подумают, посмотрят на ценник и понимают что это не подъёмная задача, ну и не надо забывать вопрос а кто будет это делатьНепонимающий, собрать команду в одной компании для решения такой масштабной задачи пожалуй уже не возможно.
  • +0.00 / 3
  • АУ
 
 
 
 
 
 
 
 
 
  adolfus ( Слушатель )
25 апр 2020 02:15:37

Программа, выполняемая на уровне пользователя, ничего "не знает"  ни о виртуализации, ни о том, что она выполняется в многозадачном режиме, ни о том, что она выполняется под отладчиком. Поэтому все это перечисленное никак на возможность формальной верификации не влияет. Просто есть языки, отладка которых сопряжена с большими трудностями, либо невозможна в принципе.Такие языки, какие бы они не были красивые, удобные и модные, никогда не войдут в список сертифицированных, есть ли у них проблемы с патентами и правами собственности или нет.

Проблема с пошаговой отладкой и существует у тех языков и технологий, которые допускают неявное исполнение неконтролируемого кода на прикладном уровне. В их число, кстати,  попадает язык c++ с его дурацкими конструкторами/деструкторами по умолчанию, виртуальными методами, перегрузкой, полиморфизмом и обработкой исключений. И пока в языке будет существовать хоть что-нибудь неявное, чего невозможно избежать, ему не светит попасть в сертифицированные.
С конструкторами/деструкторами в C++ проблема решается просто и скорее всего мы это скоро увидим в стандарте. Т.е. все конструкторы объектов должны (will) объявляться d программе явно. Остальное, к счатью, реализуется только при явном его использовании и может быть заложено в требования как "не допускается использование ...".
Что касается явы, то там еще более страшное присутствует – невозможность из программы управления кучей.
  • +0.01 / 1
  • АУ
 
 
 
 
 
 
 
 
 
 
  Oleg K. ( Слушатель )
25 апр 2020 10:35:37

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

Сейчас динамическое управление памятью практически везде - самая сложная задача. Управляет ли ей сам программист (malloc / free) или же "сборщик мусора" (привет, Java, Go, python или какой-нибудь ещё язык программирования). И в сложных системах всё равно проскакивают ошибки (вроде той же use after free). Конечно, несколько удивительно мне слышать о том, что ни один такой язык/среда исполнения в принципе не может быть сертифицирован. Тем интереснее взглянуть на документ. Время на его поиски есть - дискуссия эта не вчера началась и не завтра закончится. Сам я сразу попробовал что-нибудь подобное найти в поисковике, но потерпел неудачу.
Если рассуждать в целом - то просто надо разделять системы на составляющие - что является критичным, что - важным, а на что можно почти не обращать внимания. И в разных подсистемах просто использовать разные средства - композиционные системы всегда будут более конкурретноспособными по сравнению с однообразными в изменяющемся мире. Если всё вокруг стабильно - картина другая.
  • +0.00 / 0
  • АУ
 
 
 
 
 
 
 
 
 
  adolfus ( Слушатель )
25 апр 2020 02:53:59

Интересный вопрос. Попробую поискать в своих авгиевых конюшнях. В начале 2000-х документ и его изменения всегда попадали в верхнюю десятку выдачи поисковика ftpsearch.com по запросу "program portability requirements and certification". Документ лежал на серверах правительства США и был обязателен к использованию в любых работах для государственных институтов и организаций федерального уровня. Сегодня поиск по ftp пришел в полный упадок и документ не ловится.
Но попробую поискать в бекапах и был еще  печатный экземпляр. Быстро не обещаю – в связи с пандемией появляюсь на рабочем месте раз в неделю
  • +0.02 / 1
  • АУ
 
 
 
  adolfus ( Слушатель )
23 апр 2020 21:34:25

И кто же напишет эти миллиарды новых строк для полностью новой системы? Пушкин?
 
  • +0.03 / 1
  • АУ
 
 
 
 
  Oleg K. ( Слушатель )
23 апр 2020 21:41:26

Не обязательно необходим миллиард строк на другом языке, чтобы переписать миллиард строк на коболе.
  • -0.05 / 2
  • АУ
 
  TAU ( Слушатель )
23 апр 2020 21:08:26

Нет. Не заставит отказаться от КОБОЛа. Слишком накладно. Даже коронавирусу не под силу.


Знаете принцип "работает - не лезь!". Принцип, используемый там, где применяются сложные системы. А это унаследованное ПО - действительно сложная штука. Причем эти миллиарды строчек исходных текстов программ отлажены, "вылизаны до блеска" за десятилетия эксплуатации. Будешь писать заново - наступишь на старые грабли, пойдут ошибки. А ошибка в банковском ПО или в алгоритме работы страховой компании может быть весьма и весьма дорогостоящей в прямом смысле слова.


Причем замена потребует перехода - а значит, в какой-то момент остановки работы. А на КОБОЛе написано ПО транснациональных корпораций, банков, и пр., работающее круглосуточно, минута простоя может обернуться огромными убытками.
  • +0.03 / 2
  • АУ
 
 
  Oleg K. ( Слушатель )
23 апр 2020 21:27:07

У меня был опыт работы со старыми, "вылизанными до блеска". Обычно в этих программах полно багов, которые все вокруг уже лет 10 называют "особенностями поведения".
Носятся с этими системами, как с писаной торбой. Ну и флаг им в их "сертифицированные" рукиУлыбающийся
Я не исключаю того, что на КОБОЛе много действительно хороших и качественных систем. Но причина его распространенности не в этом, а трёх пунктах из моего предыдущего сообщения. Если бы на нем было действительно легко и просто разрабатывать ПО - на нём создавали бы и новые системы.

Вот язык С до сих очень широко распространен, и на это есть причины. Причем он уже был "старым", когда я был ещё маленьким...
  • -0.03 / 4
  • АУ
 
 
 
  TAU ( Слушатель )
23 апр 2020 21:39:41

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

Причины здесь как раз, думаю - косность и инерция мышления.
  • -0.03 / 1
  • АУ
 
 
 
 
  Oleg K. ( Слушатель )
23 апр 2020 21:44:02

Ну вот есть "безопасный" язык Java. Вы думаете, что на нем меньше ошибок допускают? Единственное отличие - ошибка на С приводит к сегфолту и падению всего приложения, а на Java - к ошибке в обработке одной операции. Вокруг всех языков программирования всегда строят леса и ставят флажки, чтобы максимально обезопасить программу от ошибок. И в С, и в Java, и в других языках.
  • -0.03 / 1
  • АУ
 
 
 
 
 
  TAU ( Слушатель )
23 апр 2020 22:09:16

1. Да, уверен, что меньше.
2. Нет, не единственное отличие.
3. Нет, не "вокруг всех" и не всегда.
P.S. Молодой человек, позволю себе пару слов, чтобы зуда писать чушь с "умным видом" было поменьше. Я учебник по языкам программирования написал, сейчас вот презентацию готовлю на тему "Языки программирования - прошлое, настоящее, будущее" для не самой маленькой аудитории в не самой маленькой компании страны.
  • +0.00 / 0
  • АУ
 
 
 
 
 
 
  Oleg K. ( Слушатель )
23 апр 2020 22:25:19

Качество программы в первую очередь зависит от программиста, и только потом - от технологий (есть такие, на которых очень сложно разрабатывать).
И adolfus судя по всему согласен с тем, что и на С можно писать сложные программы (вряд ли он 30 лет "привет, мир" пишет).
Вы можете что-нибудь сказать, что есть в КОБОЛе, чего нет в С, Java или каком-нибудь другом языке программирования? Кроме того, что на для него когда-то был хороший, сертифицированный компилятор и в своё время (именно в нужное время) он был действительно удобен для разработки.


И не надо с аппломбом здесь писать о своём величии - аргументация в стиле "по моему опыту" в приличных спорах - моветон.
Я тоже могу сказать: "Я книжек по программированию не писал - я сами программы пишу, для бизнеса. И написал их немало, поэтому знаю, о чем говорюУлыбающийся". И как это должно влиять на сам предмет спора? Так что давайте не будем продолжать в этом духе.
  • -0.03 / 1
  • АУ
 
 
 
 
 
 
 
  TAU ( Слушатель )
23 апр 2020 23:06:34

1. Да, запросто. И это будет всего одна небольшая особенность. Читайте, просвещайтесь. Да, и даже здесь другие участники обсуждения приводили выше примеры.


2. Видите ли, вы, "написавший немало", не замечаете за деревьями леса. И, увы, не знаете, о чем говорите. Демонстрируя, увы, воинствующее невежество. Чтобы судить по праву о разных языках и сравнивать их, нужно бы для начала испробовать:
- разные ассемблеры
- Фортран, желательно "посконный", изначальный
- Форт
- Лисп
- Хаскель
- Смоллток
- наследников APL - К и/или J
- Пролог
- Рефал
- скриптовые вещицы вроде Tcl/Tk, PHP и пр.
- неплохо бы Рапиру
- систему ПРИЗ с языком Утопист
- Алмир/Аналитик
- С/С++ в его развитии вплоть до современных стандартов
- обязательно визуальные языки, например, система Р-схем, Графсет и HiAsm
- Бефунг и Трефунг (будьте осторожны, нервных просят не читать!)
- Пиет (я предупреждал)
Я уж не говорю об Аде (особенно Ада12), Алголе 68, Эйфеле, Обероне, Эрланге, и прочая, и прочая, и прочая...

Успехов в изучении материалов по ссылкам! Без шуток, много найдете необычного, расширяющего горизонты и взгляды на многие вещи.


Эх, навеяли воспоминания. Немного лирики. Лично я уже после пятого класса школы писал на ассемблере К580ИК80А, Фортране, Бэйсике и Рапире. Позже самому пришлось приложить руку к реализации трех проблемно-ориентированных языков. На первом курсе на PDP-11 совместимом ассемблере написал игру Super Pacman, преподавать приходилось предметы "Спецкурс по С++", "Логическое программирование", "Языки программирования", "Основы программирования", "Машинно-ориентированное программирование", "Компьютерная алгебра" в не самых худших университетах страны. Зарабатывать программированием начал со школьной скамьи, помню первые деньги от продажи своих игр - "Каратека" и "Удав" для БК-0010. После - автоматизация деятельности самых разных организаций, и в качестве программиста, и "мастера на все руки" - сетевика/сисадмина/консультанта, и руководителя проектов разработки ПО для коммерческих и госконтор, и ИТ-директора. Помню, собственную оконную систему по образу TurboVision я накропал тоже на младших курсах в 1989, когда автоматизировал бухгалтерию одной конторки малого бизнеса... Не забуду и первое знакомство с Питоном в стартапе в Силиконовой Долине в 2000, где меня привлекали к проекту создания IDE под Linux...
  • +0.04 / 2
  • АУ
 
 
 
 
 
 
 
 
  Oleg K. ( Слушатель )
24 апр 2020 00:42:35

И вы ошибочно (как и автор) предполагает, что в Java всё ограничивается типом данных double? Деньги вообще не обрабатывают алгоритмами с плавающей точкой при фиксальном учете.

В этих "миллиардах строк на КОБОЛе" не банальные расчеты сумм и налогов по ним + документооборот, а сплошь да рядом вычисления рекурретного соотношения мюллера. Зачем натягивать сову на глобус? Что, в России слабая автоматизация процессов? И где же этот ваш хвалённый язык - что-то я по нему не вижу вакансий. Так что ваш аргумент здесь не играет. А вот в пользу моего аргумента "в нужное время" - обратите внимание на платформу 1С и в скольких компаниях она используется. И это не смотря на серьезные сложности с разработкой (отсутствие модульности, хранение исходных кодов в бинарном виде), от которых они сейчас постепенно избавляются (пытаются).

И снова вы пытаетесь взлететь на воздух возвыситься над спором. Давайте лучше вернемся к предмету спора - "незаменимый и великий (здесь можно подставить любой язык программирования на ваше усмотрение)". Итак, КОБОЛ.
  • -0.03 / 1
  • АУ
 
 
 
 
 
 
 
 
  пОМиДор ( Слушатель )
24 апр 2020 07:25:39
Сообщение удалено
пОМиДор
24 июл 2023 07:35:51
Отредактировано: пОМиДор - 24 июл 2023 07:35:51

  • -0.03
 
 
 
 
  adolfus ( Слушатель )
23 апр 2020 21:52:47

Вы просто рассмешили. Я программирую на си почти тридцать лет и не вспомню уже, когда у меня была хоть какая-нибудь ошибка из тех, котороые относят к небезопасным. Простой язык, качественные компиляторы, ясно изложенный стандарт, великолепные отладчики, куча утилит, помогающих контролировать проблемы с использованием памяти – ну где там можно совершит ошибку? Может проблема в умении программировать?
  • +0.07 / 4
  • АУ
 
 
 
 
 
  TAU ( Слушатель )
23 апр 2020 22:12:31

1. Смех без причины - ...
2. Вы - исключение, вот и все. Да, дело и в умении программировать. Но не все умеют программировать без ошибок, скорее - наоборот. Особенности языка напрямую влияют на возможность совершить ошибку в программе, надеюсь, не будете отрицать очевидное. В среднем число ошибок в программах одинаковой сложности на Си у средних программистов выше, чем на языках, где больше внимания уделено безопасности.
  • -0.03 / 1
  • АУ
 
 
 
 
 
 
  Oleg K. ( Слушатель )
23 апр 2020 22:28:12

Ошибок меньше там, где процесс грамотнее организован. И начинается процесс разработки ПО не с int main(... а с аналитической работы.
При хорошей организации даже от начинающих программистов ошибок не сильно много доходит до промышленной эксплуатации.
  • +0.00 / 0
  • АУ
 
<< Производство электроники
BCG вакцина >>