Re: Стабильная система?
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 'все
остальные'?
Reply to: