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

W>using System;
W>using System.Linq;
W>using System.IO;
W>using System.Collections.Generic;

Using'и не нужно цитировать. Их вообще редко читают. На них обращают внимание только при добавлении/удалении, чтоб не тащить ненужного.

W>class A {
W> static void Main() {

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

W>При прочих равных я предпочту недоязык. По причине более краткости и батарейности.

Не знаю, что такое батарейность, но "краткость" я в приведенном вами примере не вижу. Код на перле по объему примерно такой же.

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

M>Да, компилятор часть проблем отловить на стадии компиляции. Зависит, конечно, от проекта и компилятора, но сколько времени может занять перекомпиляция проекта чтобы все проверить?
Куда меньше чем гоняются тесты.
Даже если пересобирается вся ОС.

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

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

M>>Да, компилятор часть проблем отловить на стадии компиляции. Зависит, конечно, от проекта и компилятора, но сколько времени может занять перекомпиляция проекта чтобы все проверить?
CC>Куда меньше чем гоняются тесты.
CC>Даже если пересобирается вся ОС.

Ну допустим. А тесты для статически типизуеромого языка запускать не надо совсем? И перекомпилировать тоже?

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

_>>Есть вполне однозначное определение строгой (она же сильная) типизации.
AK>Можете привести это определение? А то википедия говорит "термины не являются однозначно трактуемыми".

Это ты где смотрел? Я вот вижу здесь https://en.wikipedia.org/wiki/Strong_and_weak_typing вполне однозначное утверждение про Питон: "Smalltalk, Perl, Ruby, Python, and Self are all "strongly typed" in the sense that typing errors are prevented at runtime and they do little implicit type conversion".

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

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

Львиная часть тестового кода обычно идет в виде библиотек, чтоб не переизобретать велосипед по пять раз в году. Вот те общие библиотеки и пересекаются. Сам-то тест у нас вообще идет не в виде кода на Питоне, а в виде небольших файлов сценариев в формате Yaml, где перечисляются действия и выполняемые проверки. Наверное, тестерам так удобнее. Те Yaml-файлы парсятся Питоном, создается указанная в конфигурации топология сети, настраивается требуемое для теста окружение и дальше уже, одна за другой, выполняются инструкции тестового сценария.

У нас типичный тест в вольном пересказе на русский звучал бы примерно так — "Две виртуальные сети объединить в одну логическую сеть, проверить, что нода VM1.1 из сети VNet1 может соединиться с REST-сервисом на ноде VM2.1 в сети VNet2. После этого заблокировать соединение ноды VM2.1 с гейтвеем, убедиться, что нода отправлена в карантин и недоступна для других нод".

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

M>Мне кажется описаны общие проблемы разработки больших проектов большой командой.

Не, вот те ошибки типов и сигнатур вызова методов характерны только для скриптовых языков. Я не претендую на роль знатока Питона, я смотрю, как с ним работают другие и пока что-то я не видел сценариев работы, защищающих или хотя бы сводящих к минимуму вот эти косяки. Но я, повторюсь, пока наблюдал использование Питона только на вспомогательных задачах вроде интеграционных тестов. Я пока не работал над проектами, где продакшн-код был бы на Питоне. Хотя я давно наблюдаю JS в продакшне и вижу там все те же проблемы.

Для сравнения могу припомнить свою работу в General Electric Healthcare, где тестовый фреймворк был построен на базе SpecFlow, с кодом на C#. Там таких проблем с кодом самих тестовых компонент не было.

M>Неужто при статической типизации не ломают билды, не портят друг друг pull request-ы и NullPointerException потом не появляется в рантайме?

Все это есть. NullPointerException в рантайме вылетает, но это уже проблемы следующей ступени, проблемы корректности алгоритма. Они и в Питоне есть. А вот проблем с неправильным количеством или типом аргументов нет — их ловит компилятор.
Билды ломаются, но происходит это на порядок реже, чем поломки тестового кода на Питоне. Как бы даже не на два порядка реже.

Пулл-реквесты не портятся, но частенько приходится делать ручной мерж, если кто-то уже поменял тот же файл.

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

Я не строю из себя знатока динамических языков. Я смотрю, как другие работают с Питоном и JS и вижу, что и профессиональные программеры на этих языках то и дело наступают на эти грабли. Интеграционные тесты у нас ломаются по два раза на дню, а эксепшны в web-интерфейсе мы наблюдаем в течении всего времени разработки веб-морды. При том, что там у нас Angular2, т.е. TypeScript, а не голый JavaScript.

M>Да, компилятор часть проблем отловить на стадии компиляции. Зависит, конечно, от проекта и компилятора, но сколько времени может занять перекомпиляция проекта чтобы все проверить? Насколько это сравнимо с запусками тестов?

В случае с нашими интеграционными тестами — совершенно несопоставимо. Я не могу сказать, сколько времени заняла бы компиляция нашего тестового фреймворка, будь он написан на компилируемом языке. Но сборка двух основных сервисов, над которыми я работаю, занимает 1 минуту и 3 минуты. Юнит-тесты требуют еще 2 минуты для первого сервиса и 7 минут для второго.

Подготовка к запуску наших интеграционных тестов (т.е. еще не сам тестовый код, а развертывание Docker-контейнеров, настройка окружения, регистрация компонентов) занимает минут 30. Это отдельная песня — я с осени бодаю наших тестеров, прошу переделать все это чтоб разделить на два действия — отдельно деплоймент, отдельно запуск тестов. Они сейчас понемногу работают над этим, но пока что есть, то есть — просто запустить один тест на Питоне займет 30 минут на деплоймент, плюс 2..5 минут на сам тест. Полный набор тестов для нашей подсистемы выполняется часов за 5 — один раз 30 минут деплоится окружение, потом уже запускается весь набор тестов. Как и следует из законов подлости, ломается обычно где-нибудь в конце.

M>Хотя да, в динамическом языке смены интерфейса — это веселая штука, нужно уметь готовить

Ну вот да. По моим наблюдениям, это основной источник проблем. По крайней мере, там, где я видел.

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

AK>Сам-то тест у нас вообще идет не в виде кода на Питоне, а в виде небольших файлов сценариев в формате Yaml, где перечисляются действия и выполняемые проверки. Наверное, тестерам так удобнее. Те Yaml-файлы парсятся Питоном, создается указанная в конфигурации топология сети, настраивается требуемое для теста окружение и дальше уже, одна за другой, выполняются инструкции тестового сценария.
AK>У нас типичный тест в вольном пересказе на русский звучал бы примерно так — "Две виртуальные сети объединить в одну логическую сеть, проверить, что нода VM1.1 из сети VNet1 может соединиться с REST-сервисом на ноде VM2.1 в сети VNet2. После этого заблокировать соединение ноды VM2.1 с гейтвеем, убедиться, что нода отправлена в карантин и недоступна для других нод".

а, понятно. это можно обложить тестами

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

AK>> ждем 5 часов
M>Это в один процесс или с распараллеливанием тестов?

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

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

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

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

В последние время иногда стал себя ловить на мыслях, что вот статическая типизация помогла бы. Потому что приходится писать иногда лишние проверки и покрывать тестами места, где бы с типами все было попроще.
Еще хочется макросов

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

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

Вон некоторые даже всякую дичь придумывают
https://medium.com/byteconf/stripe-is-building-a-ruby-typechecker-d6cd7cee6abf

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

_>Потому как они способны неприятно удивлять:

С++ может удивить не меньше .

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

S>Как известно, на плохих языках писать намного сложнее. Но почему то именно плохие языки завоевывают любовь публики.

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

Думаю, преимущества php, python & js для новичков — низкий порог вхождения. А для опытных кодеров что перечисленные, что другие — примерно одно и то же, когда шишки уже набиты, кода насмотрелся, подход наработан и т.д.

Я когда после Си сел за js, матерился только первые несколько дней, пока не понял, что и на этом говне кодить можно. Наблюдал обратный переход js — С++ у одного парня, там все было намного хуже. Для него С++ был ужасен. Короче, стереотипы мешают. Предположу, что у большинства людей, знающих несколько языков, проблем не возникает, оценку "плохой язык" могут они дать только в конкретном контексте.

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

W>>При прочих равных я предпочту недоязык. По причине более краткости и батарейности.
С>Одно радует, что перл помирает вместе с его седыми адептами.

В примере PowerShell, а не Perl. Ну, а Perl помирает уже больше, чем годков многим ожидающим с нетерпением его смерти.