Vladimir Zhbanov -> [email protected] @ 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++ слишком низкоуровневый, чтобы сравнивать его с лиспом. То есть в смысле статической проверки типов он да, лучше, но его оверхед на выражение мысли возвращает его обратно к ассемблерам :)
