Так а в чем аморальность? Вот вы пользуетесь системой, имеющей уязвимость. Человек эту уязвимость нашел. И вас предупредил. И разработчиков систему предупредил. И все сообщество…
Вы боитесь, что до его предупреждения хакеры не знали, а теперь вот узнали? Скорее всего все немного не так. На черном рынке достаточно большое предложение 0-day уязвимостей, а это значит, что весьма вероятно уязвимость во всю используется… Наоборот — сообщив о ней открыто, человек причинил некоторое неудобство Майкрософт, которая теперь должна поторопиться с закрытием, иначе у пользователей могут возникнуть вопросы.
Вообще, на самом деле в каком-то смысле более «аморально» — сообщать компании и только компании! ) На это можно посмотреть как на покупку компанией молчания пен-тестера. Т.е. пользователи все это время подвергались опасности (т.к. их системы были уязвимы), возможно уже понесли издержки из-за ошибок в проектировании, но они об этом могут и не узнать, если пен-тестер тихо сообщит, компания тихо исправит и как будто так и было!) Да, на самом деле большинство уязвимостей публикуется после выхода патча и я несколько сгущаю краски. Но… Не знаю.
несколько — это сколько? ;) 5 хватит? Если у вашего недоброжелателя есть четверо знакомых, готовых, ради него подставить незнакомого человека, или просто вас многие не любят, то в принципе они смогут сравнительно легко заблокировать ваш номер?
Интересная мысль… Т.е. все эти СОРМ легко и непринужденно нейтрализуются цифровой телефонией, доступной любому желающему? СОРМ ведь не на стороне абонента работают. Да, я не смогу подменный номер отличить от настоящего, но у оператора с эти получше должно быть, не?
Или все эти системы для оперативно-розыскных мероприятий — они только от честных людей работают? Нафиг они тогда нужны?
А в чем свинья? Предупрежден — значит вооружен! То, что об этой уязвимости узнали script kiddies — значительно меньшее зло, чем то, что о ней узнали системные администраторы, производители антивирусов и собственно — Майкрософт (заметьте — совершенно бесплатно!). 0-day в данном случае значит ранее НЕ ОПУБЛИКОВАННАЯ. Это не значит — не известная хакерам. Есть вполне реальная вероятность, что Насери нашел ее далеко не первым. Просто у всех остальных нашлись предложения поинтереснее 1000$ и ни разу не от Микрософт, а морали и идеализма оказалось поменьше…
Из всех утюгов говорят о том, что если переболел — прививаться надо не раньше чем через полгода. А еще говорят о «защитном титре антител», что-то типа выше 300. Только почему-то «болел» — это значит официально получил диагноз, а титры антител никого вообще не волнуют!
Ты не можешь получит QR-код на основании титров антител. Ты не можешь попасть под ревакцинацию, не смотря на антитела, если у тебя нет ОФИИАЛЬНОГО диагноза… Будь добр — фигачь обе дозы, хотя это увеличивает риски по аутоиммунным реакциям типа той же тромбоэмболии (слишком высокие титры антител, когда уже не сотни, а тысячи — где-то я встречал, что повышают риски образования тромбов).
В конце-концов никто не признает прививку импортными вакцинами (мне иногда кажется, что антитела-то не признают, именно из-за этого: что бы ты там втихаря не привился буржуйской вакциной) — только отечественное, только хард-кор!
На этом фоне надеяться, что государство задумается о судьбе тех, кто, мерзавец этакий, купил сертификат, а теперь одумался… Ну как-то не приходит на ум.
>>> они никак не помогают от ковида, но могут применяться для профилактики сопутствующих бактериологических заболеваний.
Конечно. Я не имел ввиду, что они помогают от ковида. Просто когда начинается деструктивный процесс в легких — для бактериальной инфекции это весьма плодородная почва. И антибиотики чаще всего нужны. Не от ковида, а чтобы не допустить осложнений. Я просто к тому, что в комментарии, на который я отвечаю было буквально следующее: «как минимум „не сделать хуже“ — история с горчиником, антибиотиками и пр», конец цитаты… Вот я пишу, что антибиотиками можно конечно сделать хуже, если принимать их горстями, долго и бесконтрольно, но в базовую «антиковидную» терапию они часто входят — от сопутствующих проблем.
С антибиотиками все не так однозначно… Зависит от многих факторов. Есть масса примеров, когда именно прием антибиотиков на ранней стадии был в тему (но это кажется невозможно решить самому, и кажется это не должны быть ТОЛЬКО антибиотики). В общем — тут не получится почитать в интернете и все сделать правильно — нужна консультация врача и хорошая диагностика.
Тут вот многие писали, что сбивать температуру надо было все-таки хотя бы после 38… Очень вероятно. Тот же Нимесил — сильное противоспалительное, но ведь надо же понимать, что само по себе воспаление — это иммунный ответ организма, и он не на пустом месте берется. Например, при ревматоидном артрите (аутоиммунном заболевании, когда иммунная система ошибочно атакует собственный организм) противовоспалительные очень нужны, но если воспаление имеет объективные причины, то не факт, что его надо глушить (хотя я не медик — тут все непросто). В общем есть ощущение, что топикстартер на ранних этапах очень сильно забил именно аутентичный иммунный ответ, и по факту дал вирусу очень хорошо развиться… Но это не точно.
Меня тоже это всегда поражало: вроде отслеживание номеров давным-давно отработано, везде и всюду говорят о том, как легко вычислить человека, если у него есть сотовый. Однако теневые «колцентры» продолжают работать, причем по общему мнению они организованны прямо на зонах, а значит как минимум не без содействия администрации…
Т.е. на самом деле все и исполнители и организаторы вероятно известны, просто «Это нога — кого надо нога!»(с).
Google Chrome и Chromium — не одно и то же. И Яндекс и Микрософт сделали как бы свой продукт на базе Chromium и это все-таки какие-никакие альтернативы хрому…
Проблема только в том, что тот же яндекс, вместо того, что бы бороться с помощью удобства и юзабилити с засилием хрома начал наворачивать на свой броузер маркетинговые примочки. В итоге сделали очередной никому не нужный клон (хотя я тут даже поставил себе — погонять их систему перевода видео на лету!). А новый Edge вполне даже юзабелен в принципе, но… Но как бы ничем особенно не лучше Хрома.
В общем конкуренцию создать сложно больше не из-за технического решения, а из-за экосистемы (поисковик/ютуб/почта/вход через google-аккаунт на сторонние сайты и тп.).
Блин, я последний раз этим вопросом занимался лет 5 назад, сча не найду файлы — без конкретики мы с вами на разных я зыках говорим. ;)
Конечно блок-схема лучше псевдокода! Причем для всех. Да — для разработчика свой, и в некотором роде даже чужой код на знаком языке высокого уровня иногда предпочтительней в силу компактности, но все равно — правильная блок-схема обычно нагляднее (просто потому, что выделяются только смыслообразующие элементы, а весь технический обвес остается за кадром). А уж для непрограммиста что псевдокод, что не псевдо — одинаково нечитаем.
Собственно проверено на бухгалтерах: тот же 1с почти псевдокод, но если там что-то большее чем «хелло ворлд» — тоска и уныние. ДРАКОН однозначно проще для восприятия.
>>> Сомневаюсь, что высокоуровневое поведение можно напрямую скомпилировать в код, т.к. низкоуровневые детали важны, какая-нибудь предварительная подготовка данных типа кэширования испортит понятность схем, а её отсутствие — испортит скорость сайта.
Вы не совсем поняли: ДРАКОН в данном случае, два в одном! ) Еще раз: у вас есть визуальный элемент, а есть его содержимое, которое может быть или вложенной схемой или непосредственно кодом. И нет в общем строгих ограничений, как компоновать код в эти визуальные элементы за исключением того, что логика высокоуровневых связей будет сохранена. Т.е. в блок-схеме у вас могут быть крупные блоки действий «подготовка данных» — «формирование элементов интерфейса» — «открытие страницы», а может быть один блок «подготовка и открытие страницы», но при этом каждый блок — это много кода (либо еще вложенные блок-схемы). Т.е. ДРАКОН тут по сути — верхний уровень абстракции над языком.
А код там получается по очень простым правилам же — не бином ньютона транслировать циклы/условия/действия в единый код (этот момент следовало бы больше проработать, а то некоторые вещи я смог реализовать фактически только через аналог goto, но это частности). Т.е. вы из листа ДРАКОН получаете исполняемый код на нужном вам языке…
>>> По моему опыту, экспертам лучше писать формулы, а программистам оставить написание алгоритмов.
Ну… Мой опыт говорит несколько иное. Блок-схемы, если они не излишне перегружены вполне доступны людям без ИТ-подготовки и однозначно лучше воспринимаются, чем псевдо-код. Применяются абсолютно независимо в самых разных презентациях/диаграммах опять-таки людьми от программирования далекими. Я вполне допускаю кейс разработки, когда логику некоего процесса в ДРАКОН накидает технолог/менеджер/эксперт предметной области, а код к блокам напишет уже программист — вполне годный пайп-лайн разработки.
Сейчас такое во всю используется, например, в геймдеве: нодовые редакторы есть для шейдеров, игровой логики, анимаций и тп. Просто надо понимать: это все хорошо работает зачастую не ВМЕСТО, а ВМЕСТЕ с кодом. Повышает читаемость и наглядность высокоуровневой логики.
ДРАКОН мог бы стать действительно великолепным проектом, будь он опенсорс, на современном движке, соберись вокруг него хорошее комьюнити (ну потому, что банально многие вещи, которые в нем есть требуют серьезного развития и проработки, которую автор в одно лицо по понятным причинам не вытягивает и вытягивать не может!). В существующем виде непрактичен конечно… Но любопытен!
>>> Алгоритм с цикломатической сложностью 100 на ДРАКОНе будет не менее нечитаем, чем в виде текста.
Теоретически автор говорил про декомпозицию. ДРАКОН не язык в строгом понимании этого слова. Проект любой сложности вы можете представить в виде функциональной схемы из крупных блоков, каждый из которых может быть так же детализирован при необходимости. Каждый блок может быть как вложенной ДРАКОН-Схемой, так и, теоретически, кодом произвольной сложности (можно его рассматривать при этом, как библиотечную функцию). Другое дело, что такой подход не слишком способствует нахождению ошибок в том смысле, как это понимают программисты: это не отладка и не дебаг.
>>> Зачем вообще презентовать алгоритмы тем, кто не в теме?
Потому, что заказчик/постановщик задач/эксперт в предметной области это не то же самое, что разработчик! Я там выше привел примеры: расчет себестоимости, закрытие бухгалтерских счетов, например. Если Бухгалтер хочет сам убедится, что у вас все правильно, для понимания диаграммы ДРАКОН, ему будет достаточно здравого смысла. При этом эта диаграмма может быть конвертирована в рабочий код. Да там, где будет написано Закрытие счета ХХ на счет YY, будет подставлен реальный код 1С и проблема его правильности остается на программисте, но бухгалтер способен проконтролировать общую логику — порядок действий, правильность условий, сами счета. Он может увидеть не только и не столько ошибку программиста, но и косяк в исходном ТЗ, который для программиста уж точно не очевиден. То же самое актуально, если программист автоматизирует секвенирование генома, расчет баллистики и прочие вещи, где нужна внешняя экспертиза…
С типичным интернет магазином — ОЧЕНЬ хороший вопрос! Конечно можно! Можно построить на ДРАКОНЕ внешнюю логику связи страниц, общую компоновку интерфейса. При необходимости (если это почему-то важно) — логику работы с базой данных и другими внешними источниками. При этом все технические детали будут внутри блоков и в общем останутся на совести разработчика. Но заказчик — может увидеть, что предложение заказать сопутствующие товары не появляется или появляется не в том момент… В общем логику ПОВЕДЕНИЯ сайта, а не низкоуровневый код.
>>> Пожалуйста, скажите ваше мнение, что ДРАКОН не является средством для сокращения числа ошибок на чем основано?
Давайте определимся с тем, что вы понимаете под «ошибкой». Ошибка в логике верхнего уровня, то что может увидеть человек, глядя на схему — эти ошибки никогда или почти никогда не бывают проблемой. Это предсказуемые ошибки, видные «невооруженным» глазом!
Основную проблему представляют два других класса ошибок: непредсказуемые и неочевидные. Первые появляются в результате стечения обстоятельств, которые разработчики не предполагали, а вторые вообще не ошибки в рамках логики системы исполняющей код.
Например, языки со слабой типизацией пропустят ошибку там, где языки с сильной выдадут ошибку типов — это обычно считается плюсом языков с сильной типизацией с точки зрения сокращения числа ошибок.
Или поддержка юнит тестирования является сильной стороной в том случае, если система разрабатывается так, что каждый элемент выполняет совершенно конкретную функцию, работоспособность которой легко проверить автоматическим тестом. Это уже относится к паттернам проектирования, позволяет обновлять очень сложные системы с массой зависимостей.
Все это — серьезные шаги вперед к написанию кода с меньшим числом ошибок. ДРАКОН в этом смысле отстал примерно лет на 30 — вы говорите о проблемах, которые были актуальны для проектов с кодовой базой в пару сотен строк!
Поймите — у вас ХОРОШИЙ продукт. Я могу себе представить Дипломный проект, научную работу, презентацию расчета показателей себестоимости на совете директоров — все те вещи, где нужно доступно показать что собственно происходит без погружения в технические дебри кодовой базы…
Но не там, где речь идет о надежности кода и тем более — безопасности людей. Там проблема уже не в читаемости. Там нужны уже совсем другие вещи.
Немножко о моей практике в ДРАКОНе… Нет, я не использовал его в реальной разработке. я пробовал с помощью него сделать работающее алгоритмы для 1С(буквально пару обработок, которые УЖЕ работали до того без ДРАКОНа), луа (применительно к роботам в майнкрафте — для детей), некоторую автоматизацию на питоне.
Получилось красиво. ;) Не очень практично, но если бы мне нужно было бы показать семилетнему сыну, как робот рубит деревья или копает железо, или пожилому отцу, далекому от программирования, как работает камера с детектором движения на RaspberryZero, или бухгалтеру, как сейчас закрывается себестоимость по счетам — это было бы неплохо. И кстати — может быть бухгалтер указал бы мне на какую-то ошибку в этом закрытии… Так что да в случае, если автоматизацией занимается кто-то, кто не очень в теме предметной области — ДРАКОН тоже может помочь в плане ошибок. Но только одного очень специфичного класса…
На самом деле он не вполне «визуальный» (как тот же scratch или blueprints в UE). Это мост между кодом и «инфографикой». Проверка условий, циклы, блоки инструкций могут содержать довольно много кода на произвольном языке, что позволяет после определенных «танцев с бубном» генерировать рабочий код из читаемой неспециалистом блок-схемы. Т.е. уровень абстракции может быть весьма высок (именно это, как я понимаю, автор имеет ввиду под декомпозицией) и достаточно сложный проект на разных уровнях может все еще выглядеть читаемо и понятно даже тем, кто не владеет кодовой базой.
Но… Блин. Эта конкретно заметка статья — ужасна. ( Безошибочность кода достигается только покрытием тестами. Визуальная проверка общей логики может выявить только совсем уж грубые нарушения СМЫСЛА ТЗ, а не сложно выявляемые баги. Ну не предназначен ДРАКОН для этого. Совсем.
Подобный продукт может быть актуален там, где убеленный сединами научрук согласует аспиранту проект на очередном навороченном фреймворке, вникать в который столпу академической науки абсолютно не с руки. ;) И ошибки отлавливать так же не его задача — пускай аспирант мучается, дело молодое. НО увидеть общую конву проекта, крупно, широкими мазками — это да. Это ДРАКОН позволяет очень хорошо!
Примерно то же можно сказать о презентациях продукта руководству. Понятно, что вы не будете показывать код — кому он нужен. Можно все накидать в Visio, но… Во-первых, по многим параметрам схемы ДРАКОНа просто визуально лучше (хотя это конечно дело вкуса), но главное не это. Все-таки в ДРАКОНЕ есть прямая корреляция между схемами и кодом. Т.е. еще раз: из схемы ДРАКОН можно получить компилируемый исходник и запустить его.
В общем везде, где вам нужно презентовать работу тем, кто не в теме — ДРАКОН норм. Это упрощение, визуализация кода. Но никак не средство написания «безошибочных алгоритмов»…
Слушайте, а там никому в голову не пришло, что «средняя» и «нормальная» — это принципиально разные термины? Если взять 10 здоровых человек и у семи из них будет 36.6, ау трех оставшихся, например, ниже, то нормальной будет 36.6, т.е. температуру которую имеет большинство здоровых людей, а не среднее арифметическое, которое будет ниже. Если взять среднее, то у большинства получится температура пусть незначительно, но повышенная, что плохо, с точки зрения диагностики. Шутка про «среднюю температуру по больнице» возникла не просто так. Средняя не показательна — это температура которой нет НИ У КОГО.
У меня сложилось стойкое впечатление, что все эти исследования строятся без учета этого момента — чисто по средней… Но тогда это просто шнобелевская премия! И последние 200 лет падает не температура тела, а IQ исследователей… ;)
В последнее время зачастили всевозможные «проверяльшики» — то счетчики, то газовое оборудование… И у всех как на подбор и форма и удостоверение. И что характерно — ни одного настоящего (я потом специально выяснял).
Если бы у каждого из них был QR-код на одежде, который я мог за 10 секунд проверить в общей базе — все бы значительно упростилось.
>>> почему при взлёте спроса нет новостей "{forbesName} нашёл {awesome count} денег"?
Почему нет? Регулярно проходят новости, что личное состояние такого-то такого-то увеличилось на очередной дохулиард в результате роста стоимости таких-то акций… А уж про рост капитализации компаний — так прямо-таки каждый день.
Вы боитесь, что до его предупреждения хакеры не знали, а теперь вот узнали? Скорее всего все немного не так. На черном рынке достаточно большое предложение 0-day уязвимостей, а это значит, что весьма вероятно уязвимость во всю используется… Наоборот — сообщив о ней открыто, человек причинил некоторое неудобство Майкрософт, которая теперь должна поторопиться с закрытием, иначе у пользователей могут возникнуть вопросы.
Вообще, на самом деле в каком-то смысле более «аморально» — сообщать компании и только компании! ) На это можно посмотреть как на покупку компанией молчания пен-тестера. Т.е. пользователи все это время подвергались опасности (т.к. их системы были уязвимы), возможно уже понесли издержки из-за ошибок в проектировании, но они об этом могут и не узнать, если пен-тестер тихо сообщит, компания тихо исправит и как будто так и было!) Да, на самом деле большинство уязвимостей публикуется после выхода патча и я несколько сгущаю краски. Но… Не знаю.
Или все эти системы для оперативно-розыскных мероприятий — они только от честных людей работают? Нафиг они тогда нужны?
Из всех утюгов говорят о том, что если переболел — прививаться надо не раньше чем через полгода. А еще говорят о «защитном титре антител», что-то типа выше 300. Только почему-то «болел» — это значит официально получил диагноз, а титры антител никого вообще не волнуют!
Ты не можешь получит QR-код на основании титров антител. Ты не можешь попасть под ревакцинацию, не смотря на антитела, если у тебя нет ОФИИАЛЬНОГО диагноза… Будь добр — фигачь обе дозы, хотя это увеличивает риски по аутоиммунным реакциям типа той же тромбоэмболии (слишком высокие титры антител, когда уже не сотни, а тысячи — где-то я встречал, что повышают риски образования тромбов).
В конце-концов никто не признает прививку импортными вакцинами (мне иногда кажется, что антитела-то не признают, именно из-за этого: что бы ты там втихаря не привился буржуйской вакциной) — только отечественное, только хард-кор!
На этом фоне надеяться, что государство задумается о судьбе тех, кто, мерзавец этакий, купил сертификат, а теперь одумался… Ну как-то не приходит на ум.
Конечно. Я не имел ввиду, что они помогают от ковида. Просто когда начинается деструктивный процесс в легких — для бактериальной инфекции это весьма плодородная почва. И антибиотики чаще всего нужны. Не от ковида, а чтобы не допустить осложнений. Я просто к тому, что в комментарии, на который я отвечаю было буквально следующее: «как минимум „не сделать хуже“ — история с горчиником, антибиотиками и пр», конец цитаты… Вот я пишу, что антибиотиками можно конечно сделать хуже, если принимать их горстями, долго и бесконтрольно, но в базовую «антиковидную» терапию они часто входят — от сопутствующих проблем.
Тут вот многие писали, что сбивать температуру надо было все-таки хотя бы после 38… Очень вероятно. Тот же Нимесил — сильное противоспалительное, но ведь надо же понимать, что само по себе воспаление — это иммунный ответ организма, и он не на пустом месте берется. Например, при ревматоидном артрите (аутоиммунном заболевании, когда иммунная система ошибочно атакует собственный организм) противовоспалительные очень нужны, но если воспаление имеет объективные причины, то не факт, что его надо глушить (хотя я не медик — тут все непросто). В общем есть ощущение, что топикстартер на ранних этапах очень сильно забил именно аутентичный иммунный ответ, и по факту дал вирусу очень хорошо развиться… Но это не точно.
В общем да. Запилить можете. И возможно эта тема даже наберет свою аудиторию на хабре. Хаб «Здоровье» — он как раз на эту тему.
Т.е. на самом деле все и исполнители и организаторы вероятно известны, просто «Это нога — кого надо нога!»(с).
Проблема только в том, что тот же яндекс, вместо того, что бы бороться с помощью удобства и юзабилити с засилием хрома начал наворачивать на свой броузер маркетинговые примочки. В итоге сделали очередной никому не нужный клон (хотя я тут даже поставил себе — погонять их систему перевода видео на лету!). А новый Edge вполне даже юзабелен в принципе, но… Но как бы ничем особенно не лучше Хрома.
В общем конкуренцию создать сложно больше не из-за технического решения, а из-за экосистемы (поисковик/ютуб/почта/вход через google-аккаунт на сторонние сайты и тп.).
Конечно блок-схема лучше псевдокода! Причем для всех. Да — для разработчика свой, и в некотором роде даже чужой код на знаком языке высокого уровня иногда предпочтительней в силу компактности, но все равно — правильная блок-схема обычно нагляднее (просто потому, что выделяются только смыслообразующие элементы, а весь технический обвес остается за кадром). А уж для непрограммиста что псевдокод, что не псевдо — одинаково нечитаем.
Собственно проверено на бухгалтерах: тот же 1с почти псевдокод, но если там что-то большее чем «хелло ворлд» — тоска и уныние. ДРАКОН однозначно проще для восприятия.
>>> Сомневаюсь, что высокоуровневое поведение можно напрямую скомпилировать в код, т.к. низкоуровневые детали важны, какая-нибудь предварительная подготовка данных типа кэширования испортит понятность схем, а её отсутствие — испортит скорость сайта.
Вы не совсем поняли: ДРАКОН в данном случае, два в одном! ) Еще раз: у вас есть визуальный элемент, а есть его содержимое, которое может быть или вложенной схемой или непосредственно кодом. И нет в общем строгих ограничений, как компоновать код в эти визуальные элементы за исключением того, что логика высокоуровневых связей будет сохранена. Т.е. в блок-схеме у вас могут быть крупные блоки действий «подготовка данных» — «формирование элементов интерфейса» — «открытие страницы», а может быть один блок «подготовка и открытие страницы», но при этом каждый блок — это много кода (либо еще вложенные блок-схемы). Т.е. ДРАКОН тут по сути — верхний уровень абстракции над языком.
А код там получается по очень простым правилам же — не бином ньютона транслировать циклы/условия/действия в единый код (этот момент следовало бы больше проработать, а то некоторые вещи я смог реализовать фактически только через аналог goto, но это частности). Т.е. вы из листа ДРАКОН получаете исполняемый код на нужном вам языке…
>>> По моему опыту, экспертам лучше писать формулы, а программистам оставить написание алгоритмов.
Ну… Мой опыт говорит несколько иное. Блок-схемы, если они не излишне перегружены вполне доступны людям без ИТ-подготовки и однозначно лучше воспринимаются, чем псевдо-код. Применяются абсолютно независимо в самых разных презентациях/диаграммах опять-таки людьми от программирования далекими. Я вполне допускаю кейс разработки, когда логику некоего процесса в ДРАКОН накидает технолог/менеджер/эксперт предметной области, а код к блокам напишет уже программист — вполне годный пайп-лайн разработки.
Сейчас такое во всю используется, например, в геймдеве: нодовые редакторы есть для шейдеров, игровой логики, анимаций и тп. Просто надо понимать: это все хорошо работает зачастую не ВМЕСТО, а ВМЕСТЕ с кодом. Повышает читаемость и наглядность высокоуровневой логики.
ДРАКОН мог бы стать действительно великолепным проектом, будь он опенсорс, на современном движке, соберись вокруг него хорошее комьюнити (ну потому, что банально многие вещи, которые в нем есть требуют серьезного развития и проработки, которую автор в одно лицо по понятным причинам не вытягивает и вытягивать не может!). В существующем виде непрактичен конечно… Но любопытен!
Теоретически автор говорил про декомпозицию. ДРАКОН не язык в строгом понимании этого слова. Проект любой сложности вы можете представить в виде функциональной схемы из крупных блоков, каждый из которых может быть так же детализирован при необходимости. Каждый блок может быть как вложенной ДРАКОН-Схемой, так и, теоретически, кодом произвольной сложности (можно его рассматривать при этом, как библиотечную функцию). Другое дело, что такой подход не слишком способствует нахождению ошибок в том смысле, как это понимают программисты: это не отладка и не дебаг.
>>> Зачем вообще презентовать алгоритмы тем, кто не в теме?
Потому, что заказчик/постановщик задач/эксперт в предметной области это не то же самое, что разработчик! Я там выше привел примеры: расчет себестоимости, закрытие бухгалтерских счетов, например. Если Бухгалтер хочет сам убедится, что у вас все правильно, для понимания диаграммы ДРАКОН, ему будет достаточно здравого смысла. При этом эта диаграмма может быть конвертирована в рабочий код. Да там, где будет написано Закрытие счета ХХ на счет YY, будет подставлен реальный код 1С и проблема его правильности остается на программисте, но бухгалтер способен проконтролировать общую логику — порядок действий, правильность условий, сами счета. Он может увидеть не только и не столько ошибку программиста, но и косяк в исходном ТЗ, который для программиста уж точно не очевиден. То же самое актуально, если программист автоматизирует секвенирование генома, расчет баллистики и прочие вещи, где нужна внешняя экспертиза…
С типичным интернет магазином — ОЧЕНЬ хороший вопрос! Конечно можно! Можно построить на ДРАКОНЕ внешнюю логику связи страниц, общую компоновку интерфейса. При необходимости (если это почему-то важно) — логику работы с базой данных и другими внешними источниками. При этом все технические детали будут внутри блоков и в общем останутся на совести разработчика. Но заказчик — может увидеть, что предложение заказать сопутствующие товары не появляется или появляется не в том момент… В общем логику ПОВЕДЕНИЯ сайта, а не низкоуровневый код.
Давайте определимся с тем, что вы понимаете под «ошибкой». Ошибка в логике верхнего уровня, то что может увидеть человек, глядя на схему — эти ошибки никогда или почти никогда не бывают проблемой. Это предсказуемые ошибки, видные «невооруженным» глазом!
Основную проблему представляют два других класса ошибок: непредсказуемые и неочевидные. Первые появляются в результате стечения обстоятельств, которые разработчики не предполагали, а вторые вообще не ошибки в рамках логики системы исполняющей код.
Например, языки со слабой типизацией пропустят ошибку там, где языки с сильной выдадут ошибку типов — это обычно считается плюсом языков с сильной типизацией с точки зрения сокращения числа ошибок.
Или поддержка юнит тестирования является сильной стороной в том случае, если система разрабатывается так, что каждый элемент выполняет совершенно конкретную функцию, работоспособность которой легко проверить автоматическим тестом. Это уже относится к паттернам проектирования, позволяет обновлять очень сложные системы с массой зависимостей.
Все это — серьезные шаги вперед к написанию кода с меньшим числом ошибок. ДРАКОН в этом смысле отстал примерно лет на 30 — вы говорите о проблемах, которые были актуальны для проектов с кодовой базой в пару сотен строк!
Поймите — у вас ХОРОШИЙ продукт. Я могу себе представить Дипломный проект, научную работу, презентацию расчета показателей себестоимости на совете директоров — все те вещи, где нужно доступно показать что собственно происходит без погружения в технические дебри кодовой базы…
Но не там, где речь идет о надежности кода и тем более — безопасности людей. Там проблема уже не в читаемости. Там нужны уже совсем другие вещи.
Немножко о моей практике в ДРАКОНе… Нет, я не использовал его в реальной разработке. я пробовал с помощью него сделать работающее алгоритмы для 1С(буквально пару обработок, которые УЖЕ работали до того без ДРАКОНа), луа (применительно к роботам в майнкрафте — для детей), некоторую автоматизацию на питоне.
Получилось красиво. ;) Не очень практично, но если бы мне нужно было бы показать семилетнему сыну, как робот рубит деревья или копает железо, или пожилому отцу, далекому от программирования, как работает камера с детектором движения на RaspberryZero, или бухгалтеру, как сейчас закрывается себестоимость по счетам — это было бы неплохо. И кстати — может быть бухгалтер указал бы мне на какую-то ошибку в этом закрытии… Так что да в случае, если автоматизацией занимается кто-то, кто не очень в теме предметной области — ДРАКОН тоже может помочь в плане ошибок. Но только одного очень специфичного класса…
На самом деле он не вполне «визуальный» (как тот же scratch или blueprints в UE). Это мост между кодом и «инфографикой». Проверка условий, циклы, блоки инструкций могут содержать довольно много кода на произвольном языке, что позволяет после определенных «танцев с бубном» генерировать рабочий код из читаемой неспециалистом блок-схемы. Т.е. уровень абстракции может быть весьма высок (именно это, как я понимаю, автор имеет ввиду под декомпозицией) и достаточно сложный проект на разных уровнях может все еще выглядеть читаемо и понятно даже тем, кто не владеет кодовой базой.
Но… Блин. Эта конкретно
заметкастатья — ужасна. ( Безошибочность кода достигается только покрытием тестами. Визуальная проверка общей логики может выявить только совсем уж грубые нарушения СМЫСЛА ТЗ, а не сложно выявляемые баги. Ну не предназначен ДРАКОН для этого. Совсем.Подобный продукт может быть актуален там, где убеленный сединами научрук согласует аспиранту проект на очередном навороченном фреймворке, вникать в который столпу академической науки абсолютно не с руки. ;) И ошибки отлавливать так же не его задача — пускай аспирант мучается, дело молодое. НО увидеть общую конву проекта, крупно, широкими мазками — это да. Это ДРАКОН позволяет очень хорошо!
Примерно то же можно сказать о презентациях продукта руководству. Понятно, что вы не будете показывать код — кому он нужен. Можно все накидать в Visio, но… Во-первых, по многим параметрам схемы ДРАКОНа просто визуально лучше (хотя это конечно дело вкуса), но главное не это. Все-таки в ДРАКОНЕ есть прямая корреляция между схемами и кодом. Т.е. еще раз: из схемы ДРАКОН можно получить компилируемый исходник и запустить его.
В общем везде, где вам нужно презентовать работу тем, кто не в теме — ДРАКОН норм. Это упрощение, визуализация кода. Но никак не средство написания «безошибочных алгоритмов»…
У меня сложилось стойкое впечатление, что все эти исследования строятся без учета этого момента — чисто по средней… Но тогда это просто шнобелевская премия! И последние 200 лет падает не температура тела, а IQ исследователей… ;)
В последнее время зачастили всевозможные «проверяльшики» — то счетчики, то газовое оборудование… И у всех как на подбор и форма и удостоверение. И что характерно — ни одного настоящего (я потом специально выяснял).
Если бы у каждого из них был QR-код на одежде, который я мог за 10 секунд проверить в общей базе — все бы значительно упростилось.
Почему нет? Регулярно проходят новости, что личное состояние такого-то такого-то увеличилось на очередной дохулиард в результате роста стоимости таких-то акций… А уж про рост капитализации компаний — так прямо-таки каждый день.
Вчера буквально эта тема всплывала в обсуждении Raspberry Pi OS .