Вы, кажется, не поняли. Спецификация уже есть. ДРАКОН, как, типа, язык программирования, является способом реализации того, что написано в спецификации.
Вы правы, я не понял. Я подумал, что разработка спецификаций — это ваш хлеб.
Поэтому я и сказал, что ДРАКОН как язык спецификаций — это золотое дно.
Прошу высказать ваше мнение по поводу этого предложения:
Я давно присматриваюсь к ДРАКОН-схемам, и есть своё видение в практическом применении их в разработке программ, в планах создать систему написания кода прямо в браузере, чтобы можно было кодить со смартфона, благодаря разделению кода на небольшие куски, вполне удобно это будет делать на небольшом экране.
Сегодня я получил на Хабре в разделе Диалоги письмо-комментарий к нашей дискуссии.
Выкладываю его. Я удалил из письма одно невежливое слово, заменив его точками по соображениям политкорректности.
Кроме того, я удалил фамилию, имя и отчество автора письма-комментария.
Здравствуйте, Владимир Даниелович!
Поражаюсь вамему мужеству в общении с……………………… хабровчанами!
Перестал здесь публиковаться из-за токсичного сообщества, хотя мои статьи чаще всего набирали плюсы, но в других несколько человек полностью разрушают конструктруктивное общение.
Я давно присматриваюсь к ДРАКОН-схемам, и есть своё видение в практическом применении их в разработке программ, в планах создать систему написания кода прямо в браузере, чтобы можно было кодить со смартфона, благодаря разделению кода на небольшие куски, вполне удобно это будет делать на небольшом экране.
Схема будет строиться исходя их обычного исходного кода, при изменении схемы изменяется исходый код, при изменении исходного кода изменяется схема, то есть, не будет специального формата для хранения схемы, как и не будет возможности что-либо двигать на ней, отрисовка автоматически раздвигает узлы как требуется.
В данный момент разрабатываю новый язык разметки, навроде Markdown, но гораздо более мощный по возможностям, и проще в реализации, и в нём сразу заложу возможность создавать ДРАКОН-схемы в виде текстового описания. Это будет как раз стартовой площадкой для реализации редактора кода.
Благодарю Вас за ваш труд по развитию ДРАКОН-схем, это большой шаг в будущее, но большинство ещё этого не поняли, и держатся за старое привычное, так со всеми новшествами всегда было, новое пробивается в мир с трудом.
С уважением, ..................
Прошу высказать ваше мнение по существу вопросов, заронутых в письме.
Тема про логические операторы вызвала много вопросов и замечаний.
У меня предложение. Тема подробно описана в моей книге. Ссылка все та же. Посмотрите, скопируйте и выложите нужные рисунки. Тогда разговор будет наглядным и предметным. А то голыми словами очень трудно объяснять.
Часть 3. Алгоритмическая логика. Математическая логика
в алгоритмах. Визуальная алгебра логики
Глава 12. Логические операции И, ИЛИ, НЕ
Глава 13. Логическая функция И
Глава 14. Логическая функция ИЛИ
Глава 15. Как удалить логические связки из логических выражений
Глава 16. Канонические логические схемы
Глава 17. Логическая функция «исключающее ИЛИ»
Глава 18. Сложные логические функции
«выбрать из БД всех пользователей, которые работали в системе вчера, или хотя бы один раз открыли форму управления за последний месяц, или относятся к группе „менеджер“»
Все написано правильно.
Улучшить эту запись с помощью текста невозможно.
Улучшить эту запись и удалить две логические связки ИЛИ можно только с помощью дракон-схемы.
Нет ровным счетом никакого основания полагать, что полный отказ от логических операторов «И», «ИЛИ» и «НЕ» уменьшит количество ошибок в коде.
Не могу согласиться. Отказ от связок с помощью дракон-алгоритма сделает логические выражения более прозрачными и понятными. И за счет этого сократит число ошибок.
Можно и нужно научить его свободно читать логические выражения, хоть с отрицанием, хоть без.
Это не сложнее, чем школьную алгебру решать.
Не могу согласиться.
Как известно, логическое отрицание представляет определенную трудность для понимания.
В связи с этим Эдвард Йодан советует:
«Если это возможно, избегайте отрицаний в булевых [логических] выражениях. Представляется, что их понимание представляет трудность для многих программистов».
В похожие ловушки часто попадают не только программисты. Трудности испытывают и многие другие люди.
Опасность ошибочного понимания провоцируют не только знаки отрицания, но и другие связки.
Поэтому Йодан расширяет и усиливает свою мысль:
«Избегайте без нужды использования сложных булевых выражений… Даже если нет неоднозначностей, такие выражения обычно с трудом понимают все, за исключением их автора».
Сходные предостережения делает не только Йодан.
Его поддерживает Гленфорд Майерс:
«Распространенным источником ошибок является использование логических операций И и ИЛИ».
Возникает вопрос: можно ли устранить подобные источники ошибок? Существует ли радикальное средство, позволяющее ликвидировать опасные места, спрятанные в логических выражениях и провоцирующие появление ошибок?
Вы гордитесь своим кодом, и это хорошо. Я приветствую чувство гордости.
Но кроме вас существует большой мир — и в этом мире не все благополучно.
Все ваши возможности находятся в рамках мировой ИТ-отрасли, не так ли?
А возможности мировой ИТ-отрасли, увы, ограничены и приводят, как показал инцидент с Боингом, к гибели людей.
Вы считаете такое положение нормальным, а я нет.
ДРАКОН — это первый шаг к осознанию реальных проблем реального мира (мировой ИТ-отрасли) и указание пути, в котором следует двигаться к безошибочному будущему.
Это долгий путь, и ДРАКОН делает первый маленький шаг.
Поэтому я и сказал, что ДРАКОН как язык спецификаций — это золотое дно.
ДРАКОН в спецификациях — это золотой дно. Подумайте. Для вас лично появился шанс — не упустите его.
Число маршрутов в алгоритме велико — это степенная функция от числа икон Вопрос.
Главный маршрут задается для каждой ветки силуэта независимо от остальных веток.
Вставлять дракон-алгоритм в спецификацию — это разумно. Описывать текстом каждый шампур в спецификации нецелесообразно.
Это не дает никаких преимуществ для спецификации
И я благодарен вам за ваши предлоения по совершенствованию ДРАКОНа.
Можете не сомневаться, что они будут тщательно изучены и подвергнуты всесторонней экспертизе сообщества.
Повторяю, если возникнут еще мысли по совершенствованию, милости просим, я буду очень благодарен.
А спецификация тут ни при чем. Пришей кобыле хвост. В огороде бузина, а в Киеве дядька.
Сегодня я получил на Хабре в разделе Диалоги письмо-комментарий к нашей дискуссии.
Выкладываю его. Я удалил из письма одно невежливое слово, заменив его точками по соображениям политкорректности.
Кроме того, я удалил фамилию, имя и отчество автора письма-комментария.
Прошу высказать ваше мнение по существу вопросов, заронутых в письме.
Тема про логические операторы вызвала много вопросов и замечаний.
У меня предложение. Тема подробно описана в моей книге. Ссылка все та же. Посмотрите, скопируйте и выложите нужные рисунки. Тогда разговор будет наглядным и предметным. А то голыми словами очень трудно объяснять.
Часть 3. Алгоритмическая логика. Математическая логика
в алгоритмах. Визуальная алгебра логики
Глава 12. Логические операции И, ИЛИ, НЕ
Глава 13. Логическая функция И
Глава 14. Логическая функция ИЛИ
Глава 15. Как удалить логические связки из логических выражений
Глава 16. Канонические логические схемы
Глава 17. Логическая функция «исключающее ИЛИ»
Глава 18. Сложные логические функции
Все написано правильно.
Улучшить эту запись с помощью текста невозможно.
Улучшить эту запись и удалить две логические связки ИЛИ можно только с помощью дракон-схемы.
Не могу согласиться. Отказ от связок с помощью дракон-алгоритма сделает логические выражения более прозрачными и понятными. И за счет этого сократит число ошибок.
Но. Я говорю не об исключении логических операций.
Я говорю о том, что можно и нужно исключить логические связки.
При этом логические операции остаются в целости и сохранности, но они записываются без логических связок.
Появляются новые логические конструкции:
— конъюнкция без знака конъюнкции;
— дизъюнкция без знака дизъюнкции;
— отрицание без знака отрицания.
Не могу согласиться.
Как известно, логическое отрицание представляет определенную трудность для понимания.
В связи с этим Эдвард Йодан советует:
В похожие ловушки часто попадают не только программисты. Трудности испытывают и многие другие люди.
Опасность ошибочного понимания провоцируют не только знаки отрицания, но и другие связки.
Поэтому Йодан расширяет и усиливает свою мысль:
Сходные предостережения делает не только Йодан.
Его поддерживает Гленфорд Майерс:
Возникает вопрос: можно ли устранить подобные источники ошибок? Существует ли радикальное средство, позволяющее ликвидировать опасные места, спрятанные в логических выражениях и провоцирующие появление ошибок?
К счастью, от этой неприятности можно избавиться.
Но кроме вас существует большой мир — и в этом мире не все благополучно.
Все ваши возможности находятся в рамках мировой ИТ-отрасли, не так ли?
А возможности мировой ИТ-отрасли, увы, ограничены и приводят, как показал инцидент с Боингом, к гибели людей.
Вы считаете такое положение нормальным, а я нет.
ДРАКОН — это первый шаг к осознанию реальных проблем реального мира (мировой ИТ-отрасли) и указание пути, в котором следует двигаться к безошибочному будущему.
Это долгий путь, и ДРАКОН делает первый маленький шаг.
Все ваши возможности находятся в рамках мировой ИТ-отрасли, не так ли?
А возможности мировой ИТ-отрасли, увы, ограничены и приводят, как показал инцидент с Боингом, к гибели людей.
Вы считаете такое положение нормальным, а я нет.