Тема ушла в полнейший аут. Так что лазить по ней нет никакого желания. Если у кого есть желание, то можете выскаться здесь.

Защитники статической типизации не то что бы верят, во что-то. Они пользуются доказанными фактами. А вот их оппоненты именно что верят. Причем, почему-то споря с защитниками статической типизации, они спорят не с их утверждениями, а с некими вымышленными.

Так, похоже, что в этой дискуссии ни один защитник статической типизации не говорит, что тесты это плохо. Они говорят другое. Они говорят, что тесты — это не всегда возможно. Что тесты не гарантируют отсутствия ошибок. И говоря, что с точки зрения надежности и простоты модификации кода лучше иметь статически типизированную программу с тестами, чем динамически типизированную с ними же.

Если подумать, то спорить с подобными утверждениями может только полоумный. Но как не странно находится на удивление не малое количество спорщиков.

Мне кажется, что очевидно, что при прочих равных статическая типизация лучше. Так что выбор динамики — это однозначный компромисс. Раз так, то этот выбор может быть оправдан, только при условии, что динамика дает какие-то существенные преимущества по сравнению со статикой.

И разумно было бы повернуть обсуждение именно в эту сторону. Потому как если таких преимуществ или они не значительны, то мы наблюдаем форменное проявление фанатизма и не желания видеть факты.

Пока что из преимуществ динамики я слышал:
1. Отсутствие аннотаций типов замусоривающих код. Мало того, что это утверждение спорно (многие считают аннотацию типов средством документирования и дополнительной информацией), так оно еще и ложно, так как есть очень нехилые СТЯП (статически типизированные языки программирования) занимающиеся выводом типов и не требующие наличия аннотаций или сокращающие их применение до мизерных величин.
2. Программу можно сделать гибче принимая решение в runtime-е. Да, само по себе это так. Но современные СТЯП без проблем позволяют делать это. А во многих случаях помогает метапрограммирование. Оно к тому же дает более надежный и более производительный код.
3. Более интерактивный режим разработки. Да, это, пожалуй, единственно верный пункт. Но и но скорее является обманом. Ведь современные СТЯП тоже предоставляют весьма интерактивный режим разработки. Фактически сегодня они не умеют править структуру типов на ходу. Но так ли это важно если на правку приложения и его перезапуск уходят считанные секунды? На мой взгляд совершенно не важно. По крайней мере остальные преимущества СТ (статической типизации) явно перевешивают этот недостаток.
4. Код на ДТЯП (динамически типизированные языки программирования) меньше и его легче держать в голове. Это откровенная лож. Но эта лож пожалуй чаще всего повторяется поклонниками ДТЯП. А чтобы эта лож не выглядила очень уж явно она всегда преподносится на фоне ЯП вроде С и С++ чья выразительность уже давно оставляет желать лучшего. Правда же заключается в том, что выразительность языка (а именно она определяет сколько кода нужно для выражения одной мысли) определяется не типом типизации, а количеством и качеством реализованных в них языковых конструкций (и/или средств расширения языка). Так ДТЯП чаще всего пиаримые на этом форуме — Питон и Руби существенно проигрывают как ДТ Эрлэнгу, так и СТ Nemerle-у просто потому, что в их арсенале нет таких мощных средств как алгебраические типы и сопоставление с образцом.

Если список не полон, то дополните его. Конкретно этот список на мой взгляд явно показывает надуманность гипотезы о преимуществе ДТЯП перед СТЯП.

Здравствуйте, VladD2, Вы писали:

VD>3. Более интерактивный режим разработки. Да, это, пожалуй, единственно верный пункт. Но и но скорее является обманом. Ведь современные СТЯП тоже предоставляют весьма интерактивный режим разработки. Фактически сегодня они не умеют править структуру типов на ходу. Но так ли это важно если на правку приложения и его перезапуск уходят считанные секунды? На мой взгляд совершенно не важно. По крайней мере остальные преимущества СТ (статической типизации) явно перевешивают этот недостаток.
Это очень субъективный на мой взгляд фактор и зависит от привычек, вон Вольфхаунд неделями пишет код до компиляции вроде как
А некоторые очень любят REPL, а его на статике врядли получишь
Так что, имхо, каждому своё, и, наверное, каждой задаче своё, т.к. нужная интерактивность может ею определяться.

Здравствуйте, Курилка, Вы писали:

К>Это очень субъективный на мой взгляд фактор и зависит от привычек, вон Вольфхаунд неделями пишет код до компиляции вроде как

Мне кажется, что твой смайлик сам по себе отвечает на твое же замечание. Плюс, уверен, что если мы спросим Вольфхаунда о том является ли положительным моментом вомможность быстро компилироваться и запускаться или вообще править код на ходу, то он скрее всего ответит — да.

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, Курилка, Вы писали:

К>>Это очень субъективный на мой взгляд фактор и зависит от привычек, вон Вольфхаунд неделями пишет код до компиляции вроде как

VD>Мне кажется, что твой смайлик сам по себе отвечает на твое же замечание. Плюс, уверен, что если мы спросим Вольфхаунда о том является ли положительным моментом вомможность быстро компилироваться и запускаться или вообще править код на ходу, то он скрее всего ответит — да.

Ну подождём лично его, но там он говорил вроде как, что как раз эта возможность там не была важна (хотя такая ситуация лично мне кажется странной).
А про REPL и задачи, больше заточенные на прототипирование, ты воздержишься от комментария?

Здравствуйте, Курилка, Вы писали:

К>А про REPL и задачи, больше заточенные на прототипирование, ты воздержишься от комментария?

Конкретно про REPL — воздержусь, так как незнаком с ним.

Про прототипирование могу сказат. Это одна из мантр потвотяемая динамщиками. Вот только современные статически типизированные языки без проблем позволяют быстро и качественно делать прототипы (если я правильно понимаю этот термин). Так что приемуществ тут особых нет.

Здравствуйте, VladD2, Вы писали:

VD>Конкретно про REPL — воздержусь, так как незнаком с ним.

VD>Про прототипирование могу сказат. Это одна из мантр потвотяемая динамщиками. Вот только современные статически типизированные языки без проблем позволяют быстро и качественно делать прототипы (если я правильно понимаю этот термин). Так что приемуществ тут особых нет.

Не знаю, я тоже вроде не сильный адепт REPL, но вот думаю, что как раз эти 2 вещи получаются очень связанные: из коммандной строки ты можешь менять собственно всё поведение системы: определения классов (если таковые есть в языке ), функции и т.п., создавать объекты, менять по ходу "пьесы" их сущность, причём всё это происходит "на лету", т.е. допустим изменение метода класса может превратиться в одну операцию, вызов его во вторую, тогда как в статике тебе надо:
1. изменить метод.
2. сохранить файл.
3. скомпилить сборку.
4. запустить тест.
Причём интересный пункт 4 — а что будет если у нас не такой примитивный класс? Для приведения его (а возможно ещё и целого дерева связанных объектов) в нужное состояние может потребоваться ещё n-ное число строчек в коде теста, тогда как в динамике у нас есть "старый" экземпляр, и надо только запустить изменённый метод.
Хотя, конечно, это довольно упрощённая картина, но всё-таки есть, на мой взгляд бенефиты у динамики, но эти они:
1. могут быть не сильно нужны для конкретной задачи (хотя тут тоже не всё понятно, и это может определяться предпочтениями/предрассудками программиста/проектировщика)
2. пребуют несколько иного подхода к разработке от программиста (не такая это общеупотребительная практика, насколько я понимаю)

Здравствуйте, Курилка, Вы писали:

К> допустим изменение метода класса может превратиться в одну операцию, вызов его во вторую, тогда как в статике тебе надо:
К>1. изменить метод.
К>2. сохранить файл.
К>3. скомпилить сборку.
К>4. запустить тест.

Ну, да, ну, да. Придумывай сказки. Волшебная командная строка и ужасный набор страшных действий.

Вот только по жизни все с точностью на оборот. Изменить строку в проекте и нажать F5 или долго возиться вспоминая что нужно набить в командной строке чтобы что-то получить.

Здравствуйте, VladD2, Вы писали:

VD>Вот только по жизни все с точностью на оборот. Изменить строку в проекте и нажать F5 или долго возиться вспоминая что нужно набить в командной строке чтобы что-то получить.

Есть подозрение, что вспоминать ничего не придется, после некоторого опыта работы... Скорее всего это будет делаться на автомате, по крайней мере в 90% основных случаях.
А что до ф5, я долго и мучитлеьно вспоминаю, где же все-таки прописать параметр который будет передаваться экзешнику при запуске.

Но все равно пользуюсь студией

Здравствуйте, VladD2, Вы писали:

VD>Ну, да, ну, да. Придумывай сказки. Волшебная командная строка и ужасный набор страшных действий.

VD>Вот только по жизни все с точностью на оборот. Изменить строку в проекте и нажать F5 или долго возиться вспоминая что нужно набить в командной строке чтобы что-то получить.

Я специально же написал, что подход к разработке меняется, если ты его не пробовал и пробовать не хочешь — это не значит, что другим людям он не может быть очень удобен и привычен
Лично про себя на данный момент такое сказать не могу (с REPL больше "баловался", чем целенаправленно работал), но в принципе подход мне очень нравится.
Плюс есть отзывы других, более известных людей (скажем, на LISP этот подход используется изначально).
Если для тебя мнения других людей, сильно отличающиеся от твоего — сказки, то чтож, остаётся пожать плечами.

Здравствуйте, Курилка, Вы писали:

К>Я специально же написал, что подход к разработке меняется

Подход к разработке чего? Он бывает очень разный в разных областях работы.
В области бизнес-программ для предприятий такой подход, наверно, очень удобен. В других областях он может быть вообще неприменим.

Здравствуйте, AndreiF, Вы писали:

AF>Здравствуйте, Курилка, Вы писали:

К>>Я специально же написал, что подход к разработке меняется

AF>Подход к разработке чего? Он бывает очень разный в разных областях работы.
AF>В области бизнес-программ для предприятий такой подход, наверно, очень удобен. В других областях он может быть вообще неприменим.

Блин, ты ветку читал?
Цитирую сам себя:

Так что, имхо, каждому своё, и, наверное, каждой задаче своё, т.к. нужная интерактивность может ею определяться.

и

1. могут быть не сильно нужны для конкретной задачи (хотя тут тоже не всё понятно, и это может определяться предпочтениями/предрассудками программиста/проектировщика)

ты с этим споришь?
И расскажи про "другие области" — я не спорю, что их нет, мне просто интересно, где интерактивность при разработке может мешать...

Здравствуйте, Курилка, Вы писали:

К>И расскажи про "другие области" — я не спорю, что их нет, мне просто интересно, где интерактивность при разработке может мешать...

Я так думаю — чем сложнее внутреннее устройство софта, тем больше вероятность того, что излишняя интерактивность будет только мешать. ИМХО

Здравствуйте, AndreiF, Вы писали:

AF>Здравствуйте, Курилка, Вы писали:

К>>И расскажи про "другие области" — я не спорю, что их нет, мне просто интересно, где интерактивность при разработке может мешать...

AF>Я так думаю — чем сложнее внутреннее устройство софта, тем больше вероятность того, что излишняя интерактивность будет только мешать. ИМХО

Не знаю, не вижу особой связи между этими вещами.
Просто при интерактивности ты "по живому" сможешь попробовать сценарии, а при статике — тесты гонять.
И что такое "сложнее"? Большое число слабосвязных компонент? Тогда их можно отдельно тестить и "играться" с ними.
Если же монолитное приложение — то, думаю, возможно это проблемы дизайна.

Здравствуйте, Курилка, Вы писали:

К>Не знаю, не вижу особой связи между этими вещами.
К>Просто при интерактивности ты "по живому" сможешь попробовать сценарии, а при статике — тесты гонять.

Для более менее сложного сценария, необходимо, чтобы система находилась в определенном состоянии. Т.е. были созданы все пред-условия для начала выполнения юз кейса какого-нибудь. А выполнение какого-то сценария переводит систему в другое состояние. И для запуска того же сценария, но с измененным методом допустим каким-нибудь необходимо будет сначала привести систему в исходное состояние. А здесь уже возможны варианты
1) останавливать систему, и переинициализировать все.
(в статике это допустим можно сделать допустим в NUnit. Перед выполнением юнит теста приведем систему к необходимому состоянию, а после выполнения, допустим откатим все до исходного состояния. При этом не обязательно загружать всю систему, можно использовать реально только ту часть с которой хочется играться. Уверен, что точно то же можно сделать и в динамике.)

2) не останавливая систему попытаться перевести ее в нужное состояние.
Для достаточно сложной системы я не думаю что это будет проще\быстрее перезапуска.
Тут вопрос больше не в монолитности, а именно в наличии состояния системы или подсистемы ИМХО.

Что будет проще в каждой из систем — хз.
К>И что такое "сложнее"? Большое число слабосвязных компонент? Тогда их можно отдельно тестить и "играться" с ними.
+1 Но тестить и играться можно и в юнит тестах. конечно цикл Red green refactor из TDD в статике будет скорее всего медленнее, чем REPL в динамике, но я не думаю, что это будет НАМНОГО медленнее. А если нужно определенное состояние для начала игры, то и для динамики придется делать перезапуск.

Здравствуйте, Mirrorer, Вы писали:

M>Для более менее сложного сценария, необходимо, чтобы система находилась в определенном состоянии. Т.е. были созданы все пред-условия для начала выполнения юз кейса какого-нибудь. А выполнение какого-то сценария переводит систему в другое состояние. И для запуска того же сценария, но с измененным методом допустим каким-нибудь необходимо будет сначала привести систему в исходное состояние. А здесь уже возможны варианты

Ну REPL тестов не заменит, только вот тесты тоже могу быть вещью, для которой он может применяться. Т.е. возможны комбинации, надо же использовать лучшее.

К>>И что такое "сложнее"? Большое число слабосвязных компонент? Тогда их можно отдельно тестить и "играться" с ними.
M>+1 Но тестить и играться можно и в юнит тестах. конечно цикл Red green refactor из TDD в статике будет скорее всего медленнее, чем REPL в динамике, но я не думаю, что это будет НАМНОГО медленнее. А если нужно определенное состояние для начала игры, то и для динамики придется делать перезапуск.

Вопрос в том, что тесты могут готовиться целенаправленно и заранее (и возможно другими людьми), тогда как в целях разработки сценарии могут придумываться на лету и видоизменяться. Я не говорю, что REPL полностью заменяет тесты, они вполне хорошо могут жить вместе

Здравствуйте, Курилка, Вы писали:

К>Вопрос в том, что тесты могут готовиться целенаправленно и заранее (и возможно другими людьми), тогда как в целях разработки сценарии могут придумываться на лету и видоизменяться.
В таком случае, REPL будет конечно удобнее.

К>Я не говорю, что REPL полностью заменяет тесты, они вполне хорошо могут жить вместе
А там, где нету REPL его можно эмулировать юнит-тестами

Здравствуйте, Mirrorer, Вы писали:

M>А там, где нету REPL его можно эмулировать юнит-тестами

Ну да, вопрос только насколько это будет равноценная замена, а тут, как говорится, it depends.
Но лично мне уже как-то надоело слишком абстрактно это обсуждать, а конкретных примеров сам придумать не могу — нужна практика, поэтому разойдёмся полюбовно

Здравствуйте, Mirrorer, Вы писали:

M>Есть подозрение, что вспоминать ничего не придется, после некоторого опыта работы...

Есть четкая уверенность, что как только звучит апелляция к опыту работы, то можно с уверенностью говорить о кривизне обсуждаемой вещи.

M> Скорее всего это будет делаться на автомате, по крайней мере в 90% основных случаях.

Вот, вот, вот. И совершенно не ясно чем выработка каких-то там рефлексов будет лучше чем просто нажатие на F5.

M>А что до ф5, я долго и мучитлеьно вспоминаю, где же все-таки прописать параметр который будет передаваться экзешнику при запуске.

Ничего, это не вседа надо, и уж точно проще чем выработка рефлексов.

M>Но все равно пользуюсь студией

И я о том же.

Здравствуйте, Курилка, Вы писали:

К>Здравствуйте, VladD2, Вы писали:

VD>>Ну, да, ну, да. Придумывай сказки. Волшебная командная строка и ужасный набор страшных действий.

VD>>Вот только по жизни все с точностью на оборот. Изменить строку в проекте и нажать F5 или долго возиться вспоминая что нужно набить в командной строке чтобы что-то получить.

К>Я специально же написал, что подход к разработке меняется, если ты его не пробовал и пробовать не хочешь

Я его пробовал. И больше пробовать не хочу.

К>Если для тебя мнения других людей, сильно отличающиеся от твоего — сказки, то чтож, остаётся пожать плечами.

Мнения "других" людей — это мнение долей процента супротив мения большинства.

Здравствуйте, Курилка, Вы писали:

К>Это очень субъективный на мой взгляд фактор и зависит от привычек, вон Вольфхаунд неделями пишет код до компиляции вроде как
Вулфхаунд может работать в любом режиме. И не страдает догматизмом в отличии от...
Там где удобно не компилироватся неделями я могу не компилировать неделями. Там где удобно запускать компиляцию в место сохранения там я запускаю компиляцию вместо сохранения.
К>А некоторые очень любят REPL, а его на статике врядли получишь
Дает преймущества только если нужно разобратся с совершенно не знакомой средой. Если среда знакома то можно и без этого работать не потеряв в производительности, а если это какойнибудь C# с ReSharper'ом то еще и быстрее.