>>Неужто проверками во время выполнения программы? >Во время компиляции DSL.
У вас два DSeL. Как они стыкуются?
>Я уже как-то писал развернутое мнение по этому вопросу, не помню только где. >CL отлично(идеально) подоходит для создания больших и сложных систем. Лушче всех других языков общего назначения.
За исключением, как я полагаю, тех, что подходят лучше.
>Собственно, постинг как раз об этом - сложность программных систем в будущем будет только расти, и CL или, подобные ему языки, будут восприниматься индустрией все больше и больше.
Вы наверное слышали о необходимости вносить изменения в программу в связи с изменениями в техзадании? Это основная проблема современного ПО - как поменять так, чтобы упало минимальное число возможностей.
Статическая проверка типов подходит для этой задачи. Типы представляют собой контракты, изменение которых определяется практически сразу. С этой точки зрения типы можно рассматривать, как систему контроля требований.
Системы контроля требований, кстати, весьма живая область, не только в индустрии ПО.
Как контролировать распространение изменений в Лиспе? Если это невозможно, то он не подходит для больших систем со множеством взаимосвязанных требований.
>Я думаю, CL довольно плохо подходит для одноразовых мелких задач(для скриптования), и для, естественно, низкоуровневого программирования, так как базовый рантайм CL, абстрактная виртуальная коммонлисп-машина, довольно жирный и высокоуровневый.
no subject
Date: 2011-11-02 12:11 pm (UTC)>Во время компиляции DSL.
У вас два DSeL. Как они стыкуются?
>Я уже как-то писал развернутое мнение по этому вопросу, не помню только где.
>CL отлично(идеально) подоходит для создания больших и сложных систем. Лушче всех других языков общего назначения.
За исключением, как я полагаю, тех, что подходят лучше.
>Собственно, постинг как раз об этом - сложность программных систем в будущем будет только расти, и CL или, подобные ему языки, будут восприниматься индустрией все больше и больше.
Вы наверное слышали о необходимости вносить изменения в программу в связи с изменениями в техзадании? Это основная проблема современного ПО - как поменять так, чтобы упало минимальное число возможностей.
Статическая проверка типов подходит для этой задачи. Типы представляют собой контракты, изменение которых определяется практически сразу. С этой точки зрения типы можно рассматривать, как систему контроля требований.
Системы контроля требований, кстати, весьма живая область, не только в индустрии ПО.
Как контролировать распространение изменений в Лиспе? Если это невозможно, то он не подходит для больших систем со множеством взаимосвязанных требований.
>Я думаю, CL довольно плохо подходит для одноразовых мелких задач(для скриптования), и для, естественно, низкоуровневого программирования, так как базовый рантайм CL, абстрактная виртуальная коммонлисп-машина, довольно жирный и высокоуровневый.
Большое спасибо.