On Fri, Oct 16, 2015 at 09:43:25PM +0300, Artem Chuprina wrote: > Vladimir Zhbanov -> debian-russian@lists.debian.org @ Fri, 16 Oct 2015 > 18:51:37 +0300: > > >> Я иногда тоже хочу параметров по умолчанию, но сильно подозреваю, что > >> это пережиток языков с duck typing. На практике, учитывая, что язык > >> компилируемый, всегда можно либо добавить пару параметров и поменять все > >> (найденные компилятором) вхождения вызовов, добавив туда дефолтные > >> значения, либо, что чаще, одновременно со вводом дополнительных > >> параметров переименовать функцию, а старое имя определить как > >> каррирование нового. > VZ> А что если параметров десяток-два? > > Тогда кто-то что-то делает не так. Ожидаемый общий ответ. Типичный пример про кучу параметров, например, в документации guile, он про графическое иксовое окошко, написанное хз на чём, ну, скажем, на gtk, которое имеет кучу параметров только иксовых. Или, например, взять тот же xrandr. Что если кто-то захочет сделать его функцией для использования в модуле для какой-то графической хрени. Я не буду приводить свои более спицфицкие примеры, но вот это -- такое использование -- неправильно? Ты считаешь, правильно делать кучу функций для каждой отдельной ерунды? Или таки вызвать 'такое окошко шириной столько-то и высотой столько-то, со всеми остальными параметрами по умолчанию' допустимо на твой взгляд? (Не, сразу оговорюсь, я здесь ни разу не хочу спорить о том, кто должен решать размер окна, юзер или wm, это о другом, есличо.)
> > VZ> И, прошу прощения за невежество, что в языках с duck typing хуже по > VZ> сравнению с языками со статической типизацией, если не считать размер > VZ> объектного кода из-за проверок типа? Не знаю за другие языки (и даже за > VZ> другие лиспы), дюже не пробовал, но в guile scheme (который я пытаюсь > VZ> начать осваивать в последние пару лет) вопрос размера объектного кода > VZ> сейчас во многом решается на этапе прекомпиляции (если я правильно понял > VZ> одного из авторов), причём работа в этом направлении идёт масштабная. > > Основная проблема заключается в том, что почти любая проблема выявляется > только в рантайме. Как раз размер объектного кода чем дальше, тем > меньше важен. А вот время на разработку... Ага, понял, спасибо. Таки ты считаешь си++ лучше лиспов в отношении времени на разработку (из-за статической типизации; не говорю про обычный си, искал, но не нашёл его в списках языков ни с динамической, ни со статической типизацией; каюсь, ленивый, смотрел только в "авторитетной" википедии)? Или сие касается только Haskel vs 'все остальные'?
