Re: Стабильная система?
Vladimir Zhbanov -> debian-russian@lists.debian.org @ Fri, 16 Oct 2015 23:29:10 +0300:
>> >> Я иногда тоже хочу параметров по умолчанию, но сильно подозреваю, что
>> >> это пережиток языков с duck typing. На практике, учитывая, что язык
>> >> компилируемый, всегда можно либо добавить пару параметров и поменять все
>> >> (найденные компилятором) вхождения вызовов, добавив туда дефолтные
>> >> значения, либо, что чаще, одновременно со вводом дополнительных
>> >> параметров переименовать функцию, а старое имя определить как
>> >> каррирование нового.
>> VZ> А что если параметров десяток-два?
>>
>> Тогда кто-то что-то делает не так.
VZ> Ожидаемый общий ответ. Типичный пример про кучу параметров, например, в
VZ> документации guile, он про графическое иксовое окошко, написанное хз на
VZ> чём, ну, скажем, на gtk, которое имеет кучу параметров только иксовых.
VZ> Или, например, взять тот же xrandr. Что если кто-то захочет сделать его
VZ> функцией для использования в модуле для какой-то графической хрени. Я не
VZ> буду приводить свои более спицфицкие примеры, но вот это -- такое
VZ> использование -- неправильно? Ты считаешь, правильно делать кучу функций
VZ> для каждой отдельной ерунды? Или таки вызвать 'такое окошко шириной
VZ> столько-то и высотой столько-то, со всеми остальными параметрами по
VZ> умолчанию' допустимо на твой взгляд? (Не, сразу оговорюсь, я здесь ни
VZ> разу не хочу спорить о том, кто должен решать размер окна, юзер или wm,
VZ> это о другом, есличо.)
Ну, такое я на хаскеле делаю регулярно. Это один _комплект_ параметров,
под него заводится тип записи, у нее есть дефолтное значение, и ему при
необходимости модифицируются поля.
>> VZ> И, прошу прощения за невежество, что в языках с duck typing хуже по
>> VZ> сравнению с языками со статической типизацией, если не считать размер
>> VZ> объектного кода из-за проверок типа? Не знаю за другие языки (и даже за
>> VZ> другие лиспы), дюже не пробовал, но в guile scheme (который я пытаюсь
>> VZ> начать осваивать в последние пару лет) вопрос размера объектного кода
>> VZ> сейчас во многом решается на этапе прекомпиляции (если я правильно понял
>> VZ> одного из авторов), причём работа в этом направлении идёт масштабная.
>>
>> Основная проблема заключается в том, что почти любая проблема выявляется
>> только в рантайме. Как раз размер объектного кода чем дальше, тем
>> меньше важен. А вот время на разработку...
VZ> Ага, понял, спасибо. Таки ты считаешь си++ лучше лиспов в отношении
VZ> времени на разработку (из-за статической типизации; не говорю про
VZ> обычный си, искал, но не нашёл его в списках языков ни с динамической,
VZ> ни со статической типизацией; каюсь, ленивый, смотрел только в
VZ> "авторитетной" википедии)? Или сие касается только Haskel vs 'все
VZ> остальные'?
Говоря "почти любая", я имею в виду все-таки высокоуровневый язык с
богатой системой типов. C++ слишком низкоуровневый, чтобы сравнивать
его с лиспом. То есть в смысле статической проверки типов он да, лучше,
но его оверхед на выражение мысли возвращает его обратно к ассемблерам
:)
Reply to: