Мир зависит от кода 60-летней давности, о котором больше никто не знает

Цитата (Trespasser65 @ 4.12.2023 - 16:56)

Цитата (XanderBass @ 04.12.2023 - 15:39) Я прошу прощения, дело в том, что я по привычке называю байт-кодом именно машинный код. Понимаю, это неверно. Потому что байт-кодом называют код именно под виртуальную машину. Но привычка есть привычка. И разница между машинным кодом, скомпилированным с тех же "плюсов", и скомпилированным с "кобола" будет минимальна, КМК, если алгоритм один и тот же. Другой вопрос, что программистов на тех же "плюсах", чтобы независимо от ОС, сейчас тоже немного. Что-то мне подсказывает, что старое ПО на COBOL работает не под "форточками". Очень странная привычка, ибо байт-код появился позже машинного. Я бы понял, если бы вы ассемблером называли машинный код. Таких встречал. А разница может быть огромной, даже для одного исходника, под разные целевые платформы, в зависимости от ключей компиляции, даже при одном компиляторе. А уж для разных языков AST (абстрактное синтаксическое дерево) чтобы подобное порождалось- это только для хелловорлдов можно представить можно, и то, не с первого раза.

Ну, положим, машинный код состоит из байтов. Иногда я называю исполняемые файлы исполняемыми бинарниками. Впрочем неважно.

Насчёт платформы не спорю. Но я сильно сомневаюсь, что на одной и той же платформе исполняемый файл, скомпилированный из исходника на тех же "плюсах", будет как-то сильно хуже исполняемого файла, скомпилированного из исходника на COBOL, при условии, что оба исходника реализуют один и тот же алгоритм. Может быть, "плюсы" потеряют буквально десяток-другой процессорных тактов в производительности. Но при нынешних мощностях, IMHO, это несущественно даже для критичных с точки зрения производительности систем.

Цитата (Shikotanvasa @ 4.12.2023 - 11:04)

Цитата (VampirBFW @ 4.12.2023 - 08:58) Если работает, нехуй лезть. Слова не мальчика, но мужа сис. админа!!! А по факту, все языки программирования по факту и результату похожи. Все описывают как действовать компьютеру/процессору по какому алгоритму решать задачу.

все люди одинаковые. две руки две ноги и голова. никакого разнообразия.

Чатгпт в критическую инфраструктуру ... превосходно.
Размещено через приложение ЯПлакалъ

Цитата (danwer @ 4.12.2023 - 09:07)

Цитата (VampirBFW @ 4.12.2023 - 08:58) Если работает, нехуй лезть. Проблема в том, что изменения неизбежны. Мир не статичен, появляются новые законы, принципы взаимодействия, которые должны быть учтены, в ПО. А внесение этих изменений стоит всё дороже и дороже из-за отсутствия специалистов. Изучить Кобол сейчас - можно хорошие деньги иметь, но это как учить древневавилонский

А таблицу умножения невозможно выучить в принципе, она древнее Вавилона.

Цитата (Bob54 @ 4.12.2023 - 10:00)

Недавно Бидон ляпнул что он владеет кодом с помощью которого он может уничтожить весь мир... Может он имел ввиду что он знает КОБОЛ? Рухнет вся финансовая система и точно весь мир в труху...

Не, он просто собирается на ноль поделить если что.

До сих пор на ХР сижу.. Только яйца крепче!

программисты могут обьяснить, почему на спектруме 48к я играл легко и с удовольствием, а теперь надо железо каждые полгода обновлять? мне графика нафиг.мне смысл главное! болдердаш сейчас наверное сервер снимать уже надо?

Цитата

Но я сильно сомневаюсь, что на одной и той же платформе исполняемый файл, скомпилированный из исходника на тех же "плюсах", будет как-то сильно хуже исполняемого файла, скомпилированного из исходника на COBOL, при условии, что оба исходника реализуют один и тот же алгоритм.

Мне это тоже было любопытно лет 30 назад, когда я подумывал перейти с Паскаля на Си. Простейший код вывода того самого "Hello world". Отличался дичайше.
Потом попробовал простейшие циклы без вывода данных (посмотреть, какие машинные коды герируются для чисто математических операций). Разница тоже была огромной.
И еще существенней она стала, когда я написал тот же цикл непосредственно машинными кодами. То, что скомпилированные программы делали около минуты, самописный машинный код делал за долю секунды.
Единственный путь приблизиться к эффективности машинного кода - это ассемблер. Любой язык более высокого уровня будет намного менее эффективен, ЕСЛИ только он не заточен под определенную сферу, и определенные функции в нем реализованы программистами на уровне хотя бы ассемблера, а не высокоуровневых раздутых библиотек.
Вот поэтому мне и кажется, что специальный язык для бизнес-задач вполне может оказаться гораздо эффективнее для решения этих задач, чем современные универсальные языки программирования.

Цитата (Frenger @ 05.12.2023 - 09:11)

Мне это тоже было любопытно лет 30 назад, когда я подумывал перейти с Паскаля на Си. Простейший код вывода того самого "Hello world". Отличался дичайше. Потом попробовал простейшие циклы без вывода данных (посмотреть, какие машинные коды герируются для чисто математических операций). Разница тоже была огромной. И еще существенней она стала, когда я написал тот же цикл непосредственно машинными кодами. То, что скомпилированные программы делали около минуты, самописный машинный код делал за долю секунды. Единственный путь приблизиться к эффективности машинного кода - это ассемблер. Любой язык более высокого уровня будет намного менее эффективен, ЕСЛИ только он не заточен под определенную сферу, и определенные функции в нем реализованы программистами на уровне хотя бы ассемблера, а не высокоуровневых раздутых библиотек. Вот поэтому мне и кажется, что специальный язык для бизнес-задач вполне может оказаться гораздо эффективнее для решения этих задач, чем современные универсальные языки программирования.

Можете огласить предметную область и примерную сложность алгоритма, где ВАШ ассемблерный код исполняется доли секунды, а "скомпилированный" (я полагаю, что нормально написанный на внятном ЯВУ, и скомпилированный профессиональным компилятором)- минутами.
И C и плюсы позволяют писать код, вполне себе эффективный. И loop unroll, и инлайнинг, и исключение неиспользуемого кода, и регистровая оптимизация- всё это уже лет как 15 вполне работает.
Размещено через приложение ЯПлакалъ

Цитата

То, что скомпилированные программы делали около минуты, самописный машинный код делал за долю секунды.

Ох бро, чето ты преувеличиваешь. Примеры можно?

Цитата (ParazitN @ 4.12.2023 - 09:23)

Цитата (ГостьСЮга @ 4.12.2023 - 10:12) Обычная практика в компаниях, которые продержались на рынке более 5-10 лет куча старого софта который с каждым днем поддерживать все труднее, но хозяева не желают вкладываться в переписывания софта. Ведь работает же. И не только у американцев, про которых написана статья, там да автоматизация банков проходила в 70е -  80е годы и последователи в 90е писали на том же что и лидеры. Вспомните как носились с проблемой 2000 года. Просто многие родились уже после неё и не помнят этой проблемы и истерией с ней связанной. В РФ с этим проще, много программ написано позже и проблема стоит не так остро ноя я боролся в 2022 году с программой написанной на досовском фокспро и успешно работающей и хозяин не желал уходит с неё, поддержка строила копейки (около 1000 рублей с компьютера в месяц), но требовала специфического железа и драйверов отсутствующих в компьютерах моложе 10 лет. Еле переехали. и это в розничной аптеке, а представьте что происходит в корпорациях типа старинных (из 90х) банках, какой там антиквариат в в основе основ вертится. Какие там драйвера в Фоксе ДОСовском? Дрова - проблема операционки, но не как не среды программирования. Чот ты свистишь маленько, коллега программер, ибо я писал и на Фоксе под ДОС и на вижуал фоксе и даже за Клиппере (тож под ДОС) и с дровами проблем ни разу не было.

Видимо программа была каким-то образом оптимизирована под принтер на лпт порту, или кассу с компортом, или какое другое периферийное устройство. Кто писал на фокспро, уже на пенсии, а молодежь кроме как мышкой кликать ничему не научилась.

Есть знакомая тётка за 60, она этот Кобол знает и писала когда-то на нем - надо сказать ей что мильёны может рубить если вспомнит это дело и к амерам переедет!

Цитата (sn000pi @ 4.12.2023 - 15:22)

Цитата (ЕгорИ @ 4.12.2023 - 12:47) А вообще с фоксом особых проблем не было. Без особого напряга перевел досовский Фокс в свое время на Визуал - там основная проблема была только окна перерисовать. Рефокс - наше всё! ))) Были забавы по молодости...) Угу, особенно с печатью из досФокса на USВ или IP-принтера из всратой ОКИ или ВРОТХЕРА. В качестве контрольного выстрела в ногу - с морды терминального сервера.

нормально всё работает, решений множество, от софта, до создания кастомного local port штатными средствами оси.
работал как-то в одной древней конторе, у них софт еще на клиппере написан, пытались перейти на 1С но по факту оказалось что 1С работает на порядок медленнее чем их старьё.

Готов на хтмл переписать
Бейсик уже подзабылся
Это сообщение отредактировал DMDK - 5 дек 2023 в 10:19

Цитата (Trespasser65 @ 5.12.2023 - 09:45)

Цитата (Frenger @ 05.12.2023 - 09:11) Мне это тоже было любопытно лет 30 назад, когда я подумывал перейти с Паскаля на Си. Простейший код вывода того самого "Hello world". Отличался дичайше. Потом попробовал простейшие циклы без вывода данных (посмотреть, какие машинные коды герируются для чисто математических операций). Разница тоже была огромной. И еще существенней она стала, когда я написал тот же цикл непосредственно машинными кодами. То, что скомпилированные программы делали около минуты, самописный машинный код делал за долю секунды. Единственный путь приблизиться к эффективности машинного кода - это ассемблер. Любой язык более высокого уровня будет намного менее эффективен, ЕСЛИ только он не заточен под определенную сферу, и определенные функции в нем реализованы программистами на уровне хотя бы ассемблера, а не высокоуровневых раздутых библиотек. Вот поэтому мне и кажется, что специальный язык для бизнес-задач вполне может оказаться гораздо эффективнее для решения этих задач, чем современные универсальные языки программирования. Можете огласить предметную область и примерную сложность алгоритма, где ВАШ ассемблерный код исполняется доли секунды, а "скомпилированный" (я полагаю, что нормально написанный на внятном ЯВУ, и скомпилированный профессиональным компилятором)- минутами. И C и плюсы позволяют писать код, вполне себе эффективный. И loop unroll, и инлайнинг, и исключение неиспользуемого кода, и регистровая оптимизация- всё это уже лет как 15 вполне работает.

Я проверял на двух вещах.
1. Вложенные циклы с прибавлением единички к значению переменной.
Точных цифр уже не вспомню.
2. Попиксельное заполнение экрана. Тут разница была визуально наглядной. Скомпилированная программа реально заполняла так, что я видел, как бежали строки пикселей. Машинный код просто менял цвет экрана мгновенно, хотя написан был именно как попиксельное заполнение.
Я ж упоминал, что дело было около 30 лет назад, когда я в универе учился. Возможно, сейчас все иначе. Но я уже давно не программист, так что просто предполагаю на основе прошлого опыта, что узко специализированное должно быть эффективнее продукта общего назначения.

P.S. Насчет минуты на заполнение может и преувеличил. Может быть секунд 3-5. Но в любом случае разница с моментальным изменением цвета была настолько впечатляющей, что запомнилась мне навсегда.
Это сообщение отредактировал Frenger - 5 дек 2023 в 11:03

Цитата (Jus @ 4.12.2023 - 08:57)

Большая часть мировых деловых и финансовых систем работает на COBOL, и лишь небольшое сообщество программистов знает об этом.

Не "работает на COBOL" а скорее "где-то в дальнем углу проекта лежит что то кобольное, которое всем лень выкинуть, чтобы не разбираться".

Все новое в последние лет наверное 15 в здравом уме никто на коболе не пишет. А старое работает ровно до тех пор, пока в него не требуется доработки вносить.

Цитата (Frenger @ 5.12.2023 - 10:55)

Я проверял на двух вещах. 1. Вложенные циклы с прибавлением единички к значению переменной. Точных цифр уже не вспомню. 2. Попиксельное заполнение экрана. Тут разница была визуально наглядной. Скомпилированная программа реально заполняла так, что я видел, как бежали строки пикселей. Машинный код просто менял цвет экрана мгновенно, хотя написан был именно как попиксельное заполнение. Я ж упоминал, что дело было около 30 лет назад, когда я в универе учился.

1. Современный компилятор скорее всего выкинет оба цикла и присвоит конечный результат.
2. Тоже разницы не будет, упрется в производительность видеопамяти.

как хобби я все еще умею и помню руками писать на ассемблере.
Но в продакшене за последние 25 лет применял всего раза два

1) руками с использованием всяких SSE алгоритм Тарьяна, предварительно набросанный на С++ и допиленный для решения логистических задач по очень объемным картам из openstreetmap.
Ускорение раза в 3-4. Но это все x86-64 с его костыльной системой команд, под которую компиляторам сложно оптимизировать автоматически.
Под Arm система команд простая и красивая, и выиграть у компилятора руками больше чем 1.5х скорости вряд ли получится. Очень редко больше, если в какой-то критичной функции получилось все впихать в регистры там, где компилятор использовал стек.
Под MIPS компилятор скорее всего будет лучше человека, там мозголомная система команд, но при этом удобная компиляторам.

2) при впихивании веб-сервера для настроек железки в эту железку на stm32 с 16кб оперативки и 128кб флеш (реально меньше, и большая часть уже занята под основной функционал железки). Там был важен объем кода и используемой памяти, а не скорость, вариант чисто на С не очень впихивался.

Но это все редкая экзотика, на практике сегодня большая часть задач пишется на C#, Pуthon и Java, вопросы производительности решаются покупкой дополнительных ресурсов в кубернетсе. Еще процедурки на Oracle/Posgres PL/SQL. Cobol за последние 25 лет вживую не видел нигде, и в банках в том числе.

Цитата (alef78 @ 5.12.2023 - 11:08)

Цитата (Jus @ 4.12.2023 - 08:57) Большая часть мировых деловых и финансовых систем работает на COBOL, и лишь небольшое сообщество программистов знает об этом. Не "работает на COBOL" а скорее "где-то в дальнем углу проекта лежит что то кобольное, которое всем лень выкинуть, чтобы не разбираться". Все новое в последние лет наверное 15 в здравом уме никто на коболе не пишет. А старое работает ровно до тех пор, пока в него не требуется доработки вносить.

Может там просто сертифицирован не сам алгоритм, который можно на любом языке повторить, а сертифицирована программа, написанная сто лет назад. Что-то типа цифровой подписи, или верификации транзакции. А уже вокруг этого программного модуля всякая обвязка в виде банковского ПО.
И что бы теперь сменить этот клочок кода, требуется провести колоссальную работу юристам, программистам, да и много кому еще.
Это сообщение отредактировал mangus - 5 дек 2023 в 11:46

Цитата (mangus @ 5.12.2023 - 11:44)

И что бы теперь сменить этот клочок кода, требуется провести колоссальную работу юристам, программистам, да и много кому еще.

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

Навскидку знаю одну программу, которую реально поддерживают и патчат больше 45 лет, это прошивка вояджеров)

Цитата (moshiko @ 04.12.2023 - 12:32)

пойду писать на асемблере если заплатят в 2,3 раза больше за страдание надо платить.

Согласен))
Размещено через приложение ЯПлакалъ

Цитата (XanderBass @ 04.12.2023 - 18:53)

Ну, положим, машинный код состоит из байтов. Иногда я называю исполняемые файлы исполняемыми бинарниками. Впрочем неважно. Насчёт платформы не спорю. Но я сильно сомневаюсь, что на одной и той же платформе исполняемый файл, скомпилированный из исходника на тех же "плюсах", будет как-то сильно хуже исполняемого файла, скомпилированного из исходника на COBOL, при условии, что оба исходника реализуют один и тот же алгоритм. Может быть, "плюсы" потеряют буквально десяток-другой процессорных тактов в производительности. Но при нынешних мощностях, IMHO, это несущественно даже для критичных с точки зрения производительности систем.

Потому всякая хуйня и тормозит на хорошем железе, что рождаются такие инженеры. Выблядки.
Размещено через приложение ЯПлакалъ

Цитата (plintus @ 4.12.2023 - 12:24)

Цитата (ParazitN @ 4.12.2023 - 09:23) Какие там драйвера в Фоксе ДОСовском? Дрова - проблема операционки, но не как не среды программирования. Чот ты свистишь маленько, коллега программер, ибо я писал и на Фоксе под ДОС и на вижуал фоксе и даже за Клиппере (тож под ДОС) и с дровами проблем ни разу не было. и при этом не помнишь вопроса локализации того зоопарка принтеров и esc-последовательности? вот уж где свист.

Под ESC вообще-то у мну были всякие отдельные библиотечки или PRG-шники однажды написанные и таскаемые из задачи в задачу, которые прилинковывались к проге или проекту, ну а там да, самый смак был, но он одноразовый, потом просто в конфиге указываешь, чо у тя за принтер и вперед с песнЯми. Рядовая задача и никакой особой ебатни.

Цитата (ParazitN @ 4.12.2023 - 09:23)

Цитата (ГостьСЮга @ 4.12.2023 - 10:12) Обычная практика в компаниях, которые продержались на рынке более 5-10 лет куча старого софта который с каждым днем поддерживать все труднее, но хозяева не желают вкладываться в переписывания софта. Ведь работает же. И не только у американцев, про которых написана статья, там да автоматизация банков проходила в 70е -  80е годы и последователи в 90е писали на том же что и лидеры. Вспомните как носились с проблемой 2000 года. Просто многие родились уже после неё и не помнят этой проблемы и истерией с ней связанной. В РФ с этим проще, много программ написано позже и проблема стоит не так остро ноя я боролся в 2022 году с программой написанной на досовском фокспро и успешно работающей и хозяин не желал уходит с неё, поддержка строила копейки (около 1000 рублей с компьютера в месяц), но требовала специфического железа и драйверов отсутствующих в компьютерах моложе 10 лет. Еле переехали. и это в розничной аптеке, а представьте что происходит в корпорациях типа старинных (из 90х) банках, какой там антиквариат в в основе основ вертится. Какие там драйвера в Фоксе ДОСовском? Дрова - проблема операционки, но не как не среды программирования. Чот ты свистишь маленько, коллега программер, ибо я писал и на Фоксе под ДОС и на вижуал фоксе и даже за Клиппере (тож под ДОС) и с дровами проблем ни разу не было.

До сих пор поддерживаю программы написанные на этих языках. Клиппер не очень удобен, так как нет отладчика. Приходится ставить точки останова в предполагаемых местах ошибок и смотреть результат. ФоксПро классный язык для работы с базами и таблицами. Работает без прокладок ОДБС напрямую. Как и Клиппер.
Это сообщение отредактировал Michail007 - 11 дек 2023 в 11:55