facevalue писал(а):
нужно разбираться еще и в этом софте. Он и сейчас не для новичков. Подход Дракона многое бы изменил.
Давайте различать сложность инструмента и сложность решения задачи с его помощью.
Дополнительная сложность, вносимая инструментом, есть безусловное зло. Однако в когнитивном плане не всё так страшно - это разовые затраты.
Имеет ли здесь ДРАКОН преимущества? Не очень корректный вопрос, потому что непонятно, что именно и как сравнивать.
О сложности решения задачи в зависимости от языка - ниже.
Цитата:
ЮМЛ... Потом кодится... Переделывается...
Какое вообще отношение плохо организованный процесс имеет к вопросу?
Боюсь, что это просто констатация очевидного бардака.
Но если мы говорим о user friendly софте, который позволяет пользователю решать специфическую задачу, не нужен UML, а нужен DSL (domain specific language), который в максимальной степени оберегает пользователя от дополнительной, не свойственной задаче сложности, выражается на понятном пользователю языке, направляет и поддерживает надёжный (безошибочный) процесс разработки.
Это, так сказать, общие требования, ТЗ.
Цитата:
логика построения ЮМЛ не помогает, а способствует допущению ошибок.
Что характеризует эклектичность набора инструментов, неадекватность инструмента решаемой задаче.
Цитата:
Если что-то в алгоритме не продумано до низкого уровня (вопрос - ответ да/нет), это видно сразу.
Агащаз.
Это в таблице решений непродуманные моменты видны сразу, а ДРАКОН тут практически ничего не даёт по сравнению с классическими блок-схемами.
Цитата:
Благодаря этому же принципу идеи и наработки появляются в процессе работы над БС, а не над кодом.
БС - это и есть код. Просто языки разные, перевод требуется.
А уже степень автоматизации этого перевода - качественная характеристика инструмента (IDE, например), но никак не самих языков.
Цитата:
и программист СРАЗУ написал РАБОЧИЙ ИЗНАЧАЛЬНО код.
См. выше. По-моему, совершенно неуместно восхищаться очевидным (почти) тождественным преобразованием.
Но я таки опять не понял, о разработке чего именно здесь идёт речь? Конкретного торгового алгоритма, который в идеале надо бы строить из кубиков DSL и не заморачиваться с трансляцией в код и т.п.?
Цитата:
Обычное ПО статичное, квадратное. Его можно разработать на бумажке, и оно будет работать. Биржевое ПО имеет дело с постоянно меняющимися данными.
Это шутка, непонимание или некорректный пиар?
Никакого принципиального отличия биржевого ПО от "всего прочего" нет и быть не может.
Огромное количество софта, управляющее оборудованием, технологическими процессами, полётами, мобильной связью и т.д. и т.п. - всё это имеет дело с постоянно меняющимися данными.
Цитата:
В больших высоких небоскребах эта проблема решается брутфорсом - много-много программистов.
В ответственных приложениях (каковыми занимаются многие из здесь присутствующих) количеством программистов легче убить проект, чем решить задачу путём брутфорса!
Цитата:
Это одна из проблем "евангелизации" - все думают, что ничего нового.
Нифига.
Просто есть специалисты, которые адекватно оценивают плюсы-минусы инструмента, а есть те, которые евангелия пишут
Цитата:
Этот ряд исключает допущение ошибок.
Нифига.
Синтаксические ошибки никому не интересны - сегодня есть множество способов борьбы с ними вплоть до невозможности их совершения.
Основные ошибки всегда в семантике, а здесь "серебряной пули" нет.
Цитата:
Function Block Diagram? Напоминает упрощенный ЮМЛ... Или ошибаюсь?
FBD описывает структуру динамической системы (в которой протекает физический процесс).
В этом смысле FBD - первична, как первично дифференциальное уравнение, описывающее динамическую систему.
Здесь выражена суть системы.
Но вы постоянно говорите об алгоритмическом слое. А он вторичен. Он всего лишь даёт один из способов решения (расчёта процессов в системе).
И алгоритм не отображает сути процесса. В этом его ущербность (как в философском, так и в весьма практическом смысле).
И отношение между ними однозначное: из структурной схемы процесса выводится алгоритм его моделирования (или управления), причём МНОГИМИ способами. Но никак не наоборот!
Вы сначала строите матмодель процесса (дифуры etc.), а потом применяете алгоритмы, чтобы эту матмодель обсчитать (выполнить нужные действия по преобразованию потоков данных).
И никто по алгоритму дифуры (структуру системы) не восстанавливает.
Потому какие новые идеи могут вообще прийти в голову при работе с алгоритмами? Разве что технические (оптимизация самого алгоритма).
Цитата:
Алгоритмический язык нужен для построения логики, для единого обмена информацией между разработчиками алгоритмов и программистами.
Что делают разработчики алгоритмов и зачем вообще здесь нужны программисты?
Нормальный DSL не требует промежуточных прослоек!
...
Что-то не срастается - движок пишет "Достигнут максимальный общий размер ваших вложений". Что бы это значило?
Попробую остальное отдельным сообщением.