Как стать автором
Обновить

Комментарии 57

офтоп
по КДПВ можно подобрать пароль

Какой пароль вы собираетесь подбирать и зачем? Это управляющий компьютер стенда балансировки карданных валов. Между прочим весьма известный компьютер.

По «чистым» клавишам видно, какие чаще используются. Но загвоздка определённо присутствует из-за отсутствия пароля и, как следствие, — необходимости его подбирать.
По «чистым» клавишам видно, какие чаще используются.
Парольные клавиши используются чаще только в том случае, когда кроме пароля на клавиатуре ничего больше не вводят (как на домофонах например). У тех же геймеров WASD совсем по другим причинам самые популярные клавиши.
В каком смысле известный? Чем прославился это польский стенд для балансировки? Или имеется ввиду известная модель компа?

Это самый старый комп этой модели который до сих пор эксплуатируется по назначению.

Где почитать про этот коммодор?
Спасибо!
Так из-за чего скрипт-то начал вылетать? Что-нибудь связанное с представлением даты/времени?
да никто уже и не узнает из-за чего. Такие скрипты даже обычно и не чинят, их переписывают рядом с нуля
НЛО прилетело и опубликовало эту надпись здесь
Я просто оставлю это здесь:
COBOL

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


Кстати, о коболе. Когда пишут вот все эти кобольные жутики, меня всегда удивляет следующее — сначала описывают сам кобол. Пишут, что это древний язык, который специально спроектирован настолько простым, чтобы любой чувак с улицы за пару недель мог научиться на нём лабать. А потом пишут, что кобол-программеры крайне ценный и вымирающий вид. У меня когнитивный диссонанс — в 60-е годы по улицам ходили крайне умные чуваки, которые могли быстро научиться коболить, а теперь они перевелись?

Была такая гипотеза, что если сделать язык программирования отдалённо напоминающий естественный язык, то программировать будет легче. Не подтвердилась. SQL — вроде бы последний живой из этого ряда.

Ну это смотря что считать программированием. Если называть программой комбинацию компьютерных инструкций и данных, позволяющая аппаратному обеспечению вычислительной системы выполнять вычисления или функции управления (стандарт ISO/IEC/IEEE 24765:2010) тогда SQL это не вполне язык программирования, потому что через него не все аппаратные функции доступны. А если подразумевается, что программа это синтаксическая единица, состоящая из определений и операторов или инструкций, необходимых для определённой функции, задачи или решения проблемы (стандарт ISO/IEC 2382-1:1993), тогда даже фраза: «Алиса, поставь будильник на семь утра, радио Шансон!» может считаться программой.

Генерация текстов, которые можно распарсить, используя стандартные техники: рекурсивный спуск, LL, LR, LARL, и прочие парсеры без использования методов из области ИИ.

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

Тут недавно пролетала сортировка пузырьком на коболе :). Более нечитаемого языка трудно себе представить.


Не подтвердилась.

Ну, как вам сказать...


SQL — вроде бы последний живой из этого ряда.

Что вы! Разных DSL наделали навалом и они вполне успешно применяются. И реально облегчают. Участвовал в проекте по написанию тестового фреймворка на Cucumber — там даже нанимали специального нейтива, чтобы он привёл в порядок язык, которым тесткейсы писались с тем, чтобы реально не программирующие тестеры могли на всём этом писать. И писали довольно успешно.

По-моему, тут ключевое слово "реально не программирующие". Чтобы быстро начать делать что-то domain specific, внешняя похожесть на синтаксис естественного языка может и помочь. Но когда начинается реальное программирование и понимаешь, что естественные языки и языки программирования выполняют совершенно разные функции, то многословность начинает мешать.

Если код хорошо задокументирован, то большинства проблем можно избежать.
И непонятно о чём статья, сначала написано, что проблемы старого ПО лечатся его постоянным обновлением, а в конце
«Не чини то, что не сломано»

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

В смысле "давайте победим старость отстрелами достигших 30 лет"?

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

Ну как не согласиться насчёт баланса?
Я немного не согласен с "меньше усилий чем сделать переделать".


Тут такая штука — в статье кроме смены поколений ПО (мы как-то слишком сейчас на ней сконцентрировались), есть еще банальная некомпетентность. Не та, где "соискатель не продемонстрировал знание современных парадигм проектирования" а намного более важная — способность разобраться в проблеме. Вот смотрите:


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

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


И, что НАМНОГО хуже — не имеет чёткого представления о предметной области.
Человек не понимает какую проблему решает программа, поэтому не может и не хочет разобраться в том, как она это делает. Отсюда уверенно накидывает о гнили, протухлости и прочей ерунде.


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


В статье речь идет о плановом устаревании. С точки зрения производителя — отличная штука. Но покупатель с этим не всегда согласен.

Тут такая штука — в статье кроме смены поколений ПО (мы как-то слишком сейчас на ней сконцентрировались), есть еще банальная некомпетентность. Не та, где "соискатель не продемонстрировал знание современных парадигм проектирования" а намного более важная — способность разобраться в проблеме.

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


И восстанавливать компетенции часто сильно дороже чем просто сделать с нуля. Более того люди просто не хотят их восстанавливать потому что это потребуется разово. И такое наблюдается не только в ИТ.


К примеру найти людей которые вам могут настроить карбюратор в автомобиле и вообще хотят этим заниматься даже за деньги все меньше. Почему? Потому что современная инжекторная система им понятнее и лучше поддается диагностике.

Мы говорим о разных вещах. Есть естественная смерть продукта — та самая промышленная археология. Когда ПО не компилируется, когда инжектор оказывается дешевле карбюратора. Когда логичнее купить новый автомобиль, чем поддерживать старый.


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

Про одно и тоже. Просто ПО оно разное. Есть ПО у которого требования не меняются как результат само ПО не меняется и остается только поддержка. В это случае гнет окружение. А есть ПО у которого требования меняются. Это как раз вот то что дворники не дают орошения и сигнал скучный. И в этом случае само ПО гниет, так как перестает соответствовать требованиям.


Первое ПО как правило не работает напрямую с пользователем, а второе работает, по этому и активнее меняется.


Пример первого ПО какой нибудь grep или какая нибудь программа типа вон стенда для балансировки карданов. Изменять там что-то не требуется, а вот сопровождать придется. Причем проблемы можно получить на ровном месте. К примеру вам нужно перенести ПО на более свежий компьютер. Тут выясняется что и ОС не может там работать. Ну окей исходники же есть! И документация! И тут выясняется что компилятор уже не запускается на новой ОС и собрать софт нельзя.


И тут у вас диллема или переделывать софт чтобы он мог взлететь на новом окружении или написать заново. Иногда дешевле и лучше сделать новое окружение. Именно по этой причине тот же fortran жив и под него есть свежие компиляторы. Потому что переписывать весь тот объем кода для математики выйдет дороже чем сделать компилятор fortran.

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

И, что НАМНОГО хуже — не имеет чёткого представления о предметной области.
Человек не понимает какую проблему решает программа, поэтому не может и не хочет разобраться в том, как она это делает. Отсюда уверенно накидывает о гнили, протухлости и прочей ерунде.


Я вот, простите, вижу человека, который не очень умеет читать. Историю об упавшем скрипте, который до этого не падал никогда, автор основного текста цитирует, поэтому называть того, кто написал процитированный вами кусок, «автор» — несколько некорректно. Понимаете, это два разных человека. Один («автор») говорит про гниение софта, а другой («эксперт») рассказывает страшную историю, которая кончилась хорошо.

«Автор» использует этот пример, чтобы довести до нас очень простую идею: разрушается всё. То, что скрипт десятилетиями правильно работал, совершенно не даёт гарантий, что он будет работать и дальше. Рано или поздно АБСОЛЮТНО ВСЁ упадёт, перестанет работать, сгниёт.

К «эксперту» как-то странно высказывать претензии. Он — как раз тот человек, который понял, что случилось, и исправил скрипт. Конечно, были другие специалисты, которые сделать это не смогли, именно поэтому и пришлось обращаться к «эксперту».

Так что если кого и обвинять, то не «автора» и не «эксперта», а тех специалистов, которые без «эксперта» не справились. Вы как-то очень легко бросаетесь обвинениями: «не понимает какую проблему решает программа», «не умеет и не хочет читать чужой код». Ну-ну. Вообще-то люди действовали под сильным давлением и в условиях отчаянной нехватки времени — а ситуация была очень, очень нетривиальной. Скрипт работал каждый день десятилетиями. В него никто никогда не заглядывал, его никто никогда не проверял, потому что он никогда не ломался.
Им ещё и не повезло очень сильно. Сломаться может только то, что менялось, а как раз накануне — злое такое совпадение — было выведено в продуктив некоторое изменение порядка запуска скриптов. Образно говоря, вчера лампочка зажигалась, вчера же вы выключатель поменяли, и сегодня она не зажигается.
Конечно, люди предположили, что виновато именно изменение, и откатили его. Идея очень логичная: сначала починим, а уже потом будем разбираться, что пошло не так.
И стало сильно хуже, потому что на самом деле поломалось не окружение скрипта, а текущая дата. Скрипт заглядывает в будущее на 20 лет, а дело происходило 20 января 2018 года. И если на основании этой информации вы поняли, что именно поломалось — мои искренние поздравления. У специалистов такой подсказки не было (то есть вся эта информация у них была, конечно, но никто для них не поставил её рядом).

Так что я бы поостерёгся и этих специалистов обвинять. Не думаю, что не справились с проблемой они по недостатку желания или умения читать чужой код. Оно бы, кстати, и не особо помогло, потому что в скрипте-то никакой ошибки не было.

Ух. Не трогаем специалистов. Они молодцы и вообще справились.
Если вы намекаете на 32-битный unixtime — во-первых снимаю шляпу, во-вторых вы совершенно правы — такого рода ошибки решаются крайне сложно даже оригинальными разработчиками.


Я резко прокомментировал вот эти строки цитируемые в статье:


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

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


Есть соблазн объявить: "Ничего понять нельзя, плохой код, давайте перепишем". Не решить проблему, а просто отложить её решение, сбежать в зону комфорта.


И навык (именно навык) преодоления этого дискомфорта, умения сначала разобраться с тем, что другой разработчик ХОТЕЛ сделать и уже потом с тем, как он это делал и что у него получилось, мне кажется одним из самых недооцененных.


Дальше по тексту (цитата из цитаты из статьи):


Заметив, что из первой программы из-за её вылета нет выходных данных, она восприняла эту ситуацию как «все вклады равны 0». Разумеется, она должна была вести себя совершенно иначе. Но никто не знал, что она будет действовать так

Я понимаю почему написано именно так. Но всё равно "разумеется, она должна была" и "никто не знал, что она будет" в одном абзаце звучат странно. Как описание непостижимого черного ящика внутри черного ящика непостижимости.


Ощущение, что за пару десятилетий не нашлось ни одного человека, который бы заглянул туда из простого любопытства.


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

Там написано, что это искушение, но не написано, что ему надо подчиняться. Скорее наоборот.
Попробуйте прочитать внимательно.
По мне статья из разряда «хорошие намеренья, которые непонятно как применять на практике» Проблема ведь не в разрабочиках, а владельцах продуктов и их менеджерах.
Приходит такой разраб к менеджеру и говорит «А давайте наш продукт с JDK 8 на 11 переведем! И в ответ » А зачем? Какие проблемы это решит?". И ему «Чтоб через n -лет были живые люди, которые смогут разобраться в этом коде!» Только какое дело менеджеру, что там будет n-лет?
«Мы, разработчики ПО, стремимся создавать надёжные системы без багов»
Сейчас на хайпе другая парадигма — «Сделать за две недели минимально работоспособный прототип, который сможем впарить заказчику»
А будут ли люди осуществившие перевод «с JDK 8 на 11» разбираться в коде так же, как те, кто этот код сделал?
Приходит такой разраб к менеджеру и говорит «А давайте наш продукт с JDK 8 на 11 переведем! И в ответ » А зачем? Какие проблемы это решит?".

Ппффф изи. JDK 8 скоро снимут с поддержки и если мы будем тянуть то придется переносить в спешном порядке, лучше заложить это сейчас. И все. Фраза снимут с поддержки действует магически.

А менеджер отвечает, что у конторы договор с ораклом о расширенной поддержке jdk8 до 2031 года

Отлично значит, он берет на себя риски и не надо забивать себе голову.

Либо он не планирует оставаться столько лет на этом месте! «Либо ишак либо падишах помрет»

От этого контракт никуда не денется.

Что вы там переводить куда собрались? Золотое правило: «Работает — не трогай!»
Только когда оно перестаёт работать, придётся всё с нуля переписывать как раз. И лучше начинать это делать, когда старое ещё работает, чтобы проще мигрировать было.

Что-то может перестать работать только если поменялось окружение, структура входных данных или что-то в таком духе. Если среда не меняется — оно будет работать вечно, пока живо железо (или его эмуляция) для которого это написано.


То есть — пока функция выполняется, пока на это тратится разумное время и в обозримом будущем изменений не предвидится — просто нет смысла что-то менять.


Пример из жизни — у моего клиента есть софт который рассылает счета клиентам, там есть примитивные шаблоны и гибкая конфигурация, он работает со старой базой откуда собственно и берёт данные. Этот софт был писан ещё на первых версиях Perl 5 (25 лет назад), но работает и по сей день — причём хорошо работает. Он пережил (без изменений кода — всё в шаблонах и конфигурации) переименования фирмы, изменения налогов, изменения в продукции фирмы и ещё массу всяких мелочей, и на данный момент у него всего два недостатка — работа со старой базой (но это легко решается) и несколько архаичный текстовый вид счетов — собственно всё.


С учётом того что всё это сейчас работает в виртуалке, я даже не могу представить ситуации почему оно может вдруг перестать работать — если уж исправно это делало как минимум 20 лет (в первые 5 лет были правки, но потом всё стабилизировалось).

что будет делать ваш клиент, когда вы помрете, а на хосте виртуалки вылетит диск?

perl5 и сейчас работает отлично. Плюс это интерпретатор и найти людей которые умеют в perl вполне реально. Но переносить систему на более свежую ОС надо.

Если вылетит диск — он восстановит его из бэкапа, как это ни странно — и продолжит им пользоваться (уже случалось).


Я к этому проекту вообще отношения не имею — просто знаю о нём (спрашивали насчёт его переписывания на чём-то более современном — поэтому смотрел внутрь), в поддержке он совсем не нуждается, работает и всё.

НЛО прилетело и опубликовало эту надпись здесь
Вот как раз на современных, благодаря контейнерам, очень даже запустить.
НЛО прилетело и опубликовало эту надпись здесь

Что ж они такого специфического для JDK8 использовали, что не переносится на 11?

НЛО прилетело и опубликовало эту надпись здесь

То есть проблем не описано.

Постоянное переписывание требует наличие дорогого сотрудника на каждые N тысяч строк. Если программист с зарплатой 10 работников напишет код который заменит 10 работников. Но после этого осядет до конца дней своих на шее работодателя занимаясь лишь переписыванием этого кода, то зачем вообще нужен такой программист? Дешевле раз в 30 лет переписывать ПО.
— ну не в 30 лет, а так я видел примеры когда и через 3 года уже концов не найти.
— ну и опять же как правило находятся полезные доработки которые пилятся этим программистом непрерывно, жизнь-то меняется
Насколько все помнили, эта пакетная задача никогда раньше не вылетала.
Написавший её человек умер уже 15 лет назад

То есть программа пережила автора на 15 лет?
Вот прямо завидую.

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

Я без претензий! и в то же время задам вопрос, — как откат изменений к предыдущему релизу могу усугубить проблему? типа в БД уже успели внестись кривые данные или как?

а по-моему лучше идти в ногу со временем и всё периодически обновлять
ВСЁ — это что??
На деле к сожалению всё оказывается по другому, если всё работает сейчас-то и проблем нет((
Не важно, что программа работает, всё-равно надо обновлять, добавлять вес, добавлять баги, чтобы было, что исправлять,…
Что это такое, все обновляются, а оно тут само работает, непорядок. Вот и повод нашелся — вдруг через двадцать лет сломается, а, что будете делать, ведь никто уже не умеет так писать?

Мне думается, по здравому смыслу, правильнее таки хорошо писать, а не заталкивать всех в очередную модную концепцию вечных обновлений.
В своё время я сподвиг руководство компании, в которой я работал приходящим программистом, перейти с 1С Предприятия 7.7 на 1С Предприятие 8 в контуре оперативного учета.

Хотя функционал, разработанный лично мной в одиночку, всех устраивал и база данных могла бы проработать ещё не один десяток лет.

Аргументация была такова: программисты для 1С Предприятие 7.7 «вымирают», через N лет на рынке труда не найти будет ни одного.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий