Для любой практики можно найти людей, которые ей не следуют. Означает ли это, что ничего не влияет на продуктивность? Но это так, если говорить о метауровне.
Я не говорил, что ничего. Я писал о том, что если бы роль системы типов была бы так велика, такие языки, как Python, Lua, PHP, JavaScript или не были бы столь популярны или быстро бы обзавелись системами типов.
Если говорить о прямом уровне рассуждений, то иногда важна не продуктивность, а время до первого запуска программы (потому что тогда можно закрыть тикет в джире, и пофиг, что там потом будет), например.
Странная логика. После закрытия тикета продукт разворачивается у клиента, который вообще-то платит за это деньги. Вы на эти деньги живете, помогаете родителям, оплачиваете «развивашки» детям. Это не пофиг.
Когда сначала говорите о субъективности опыта, а потом о том, что для сравнения продуктивности достаточно собственного опыта.
Мы не на научном симпозиуме. Я разговариваю с вами лично и мое предложение направлено на то, чтобы вы лично получили опыт, на который я ссылаюсь.
Я изначально написал, что с питоном менее продуктивен. Про психологические проблемы и что-то ещё говорить начали таки вы.
Возможно я ошибся. Судил по себе.
Я всего лишь делюсь собственным опытом, как вы и просили. А опыт — ну, какой есть, не понимаю, чем он вам не нравится.
Вы используете то что выдает вам тайпчекер как чеклист. В этом чеклисте нет ничего, кроме дефектов. Следовательно, выдача тайпчекера функционально эквивалентна реестру дефектов. Я тоже так делаю, можно считать эту практику условно хорошей.
Потому что система типов — это наиболее выраженный и прокачанный случай статического анализа.
Наоборот же, вырожденный случай. Например, статический анализ может сказать вам, что на ноль делить нельзя, а вот с точки зрения системы типов int / int → float. Также, система типов не поведет бровью, если вы попытаетесь удалить из БД уже отсутствующий в ней объект.
Про что и речь — я именно это и имел в виду, когда писал выше, что в дополнение к разработке системы типов придётся заниматься очень интересным трудом в виде аннотаций используемых библиотек (и не факт, что плодотворным — не все будут с радостью это мержить).
Если бы это реально влияло на продуктивность, все бы это делали с удовольствием.
Кажется, вы сами себе противоречите.
Возможно. В чем конкретно?
А это удобно — если результат эксперимента не такой, как вам нужно, можно просто объявить это психологическими проблемами!
Вы сами это написали.
PyCharm, полгода назад. На простейших случаях (которые я не воспроизведу, впрочем, ибо это было на работе, а личного кода на питоне у меня нет).
Мда. После ваших саркастичных комментариев о том что я сам себе противоречу и выдаю желаемое за действительное я ожидал что вы придерживаетесь столь же высоких стандартов дискуссии, каких требуете от меня. Разочарован.
Я хочу, чтобы компилятор с помощью системы типов сказал мне что будет ай-ай-ай.
Переписываю модуль, и после того, как я поборол все ошибки тайпчекера, все интеграционные тесты зелёные сразу.
Ну практически вы говорите что полезно иметь реестр дефектов. И хорошо бы чтобы дефекты выявлялись автоматически. Спорить с этим бессмысленно, я полностью согласен с этими утверждением, но почему вы приписываете достижения статического анализатора системе типов?
Во flow это делается не автоматически. Если библиотека экспортирует для себя декларации типов, flow ее подхватывает. Если нет то нет.
Так это же и будет означать субъективную продуктивность, разве нет?
До тех пор, пока у вас нет скрытой цели, ваша оценка будет достоверно отражать реальность.
А с питоном я на порядки менее продуктивен, чем с хаскелем
Не, ну понятно, что психологические проблемы разные бывают. Говорить о продуктивности имеет смысл только после того, как все психологические проблемы решены и вам ничего не мешает. Иначе разговор про систему типов превратится в перечисление тараканов.
Только интеллисенс, который пытается выводить типы, ломается даже на простейших примерах.
У меня не ломается. Про какой именно интеллисенс вы говорите? В какой среде? На каком языке?
Как? Допустим прочитали вы файл в строку. Что-то я не знаю такой системы типов, которая могла бы такие случаи анализировать.
Наверное, я занимаюсь чем-то не тем, но типизация очень помогает и тут. Особенно когда дизайн переделывается не с нуля, а с сохранением каких-то уже написанных кусков кода.
Как вы это поняли? Вы переписываете модуль и у вас нет ошибок компиляции? Ну так может вы просто хороший программист?
Что-то я не понял что конкретно он запрещает. Берем JavaScript. Добавляем в него flow на уровне V8, пишем пропозал, пропозал принимают. Что там Райс запрещает я не понимаю.
Боюсь, что я недостаточно хорошо знаю питон, чтобы сравнение было репрезентативным.
На уровне личных ощущений. Сами все поймете.
Не называете ли вы тут протезом условный бульдозер, утверждая, что есть люди, способные тайпчекать в голове делать то же, что делает бульдозер, и для которых он является протезом?
А с чего вы взяли, что на производительность программиста влияет именно типизация, а не Intellisense в IDE? Я думаю, что Intellisense влияет больше, чем типизация.
Что значит «не влияет»? То есть, если я возьму нетипизированный язык, то моя продуктивность не упадёт?
Думаю, да. Есть типизированный диалект Python-а — Boo. Попробуйте сравнить.
А тесты, кстати, влияют на продуктивность? А грамотная архитектура, солиды-киссы всякие, не знаю?
Я думаю, что это, опять-же индивидуально для каждого работает. То есть, глобально все эти вещи программистам не нужны. Но некоторые программисты испытывают сложности с тем или иным кодом и им требуются дополнительные условия. То есть, это как протез. Нет ничего плохого в том, чтобы им пользоваться, но нельзя утверждать, что «протез увеличивает производительность для всех и каждого».
Конечно. Если бы статическая типизация была такой полезной, как ее малюют, программисты быстро бы расширили эти языки системой типов.
Более того, у нас есть кейсы с TypeScript и flow, и есть доклад, где прямо говорится, что для них статическая типизация практически не играет роли. (Небольшой эффект наблюдается при рефакторинге, но мы все прекрасно знаем, что рефакторинг — развлекаловка разработчика, ценности он не несет).
1. В мире полно талантливых людей, которе будут рады решить любую нетривиальную задачу.
2. Вот именно. Статическая типизация — личное предпочтение конкретного программиста, и не влияет на продуктивность.
Вы можете сделать форк и если ваш форк с системой типов был бы кому-нибудь нужен он стал бы более популярен чем оригинал.
Вернемся к обсуждению по-существу?
Мой аргумент не в защиту динамической типизации, как единственной альтернативе статической. Мой аргумент про то, что типизация оказывает разве что психологический эффект.
Я вообще не считаю, что сама концепция тип объекта хоть сколько-то продуктивна. В реальной жизни объект проявляет себя только во взаимодействии с другими объектами, у него нет и не может быть универсальных черт, истинных с любой точки зрения. Концепт трейта мне видится более жизнеспособным.
А те задачи, которые сейчас выполняет типизация на уровне языка имеет больше смысла производить на уровне IDE: в реальном времени подсказывать программисту доступные возможности, ограничения, документацию, примеры использования, ограничения параметров и все остальное.
Ну так MR — это запрос на включение коммитов. Если бы это было реально нужно, то не отклонили бы и было бы очень много желающих расширить языки системами типов. Того что этого нет однозначно свидетельствует, что важность системы типов сильно преувеличена.
Ну так а зачем вам гарантии от самого себя? Когда вы из файла или из базы читаете бяку, типизация вам вообще никак не поможет.
Типизация сильно помогает обучению, это правда и чем она строже, тем лучше. Но после того как вы научились программировать, типизация уже практически не влияет. Расставлять типы и думать об отказоустойчивом дизайне в современной парадигме просто невозможно — в любой момент концепция может поменяться и весь ваш дизайн придется с нуля переделывать.
Если бы ваши слова были правдой, то программисты сделали бы динамические проверки типов в языках без статической типизации. Но практика показывает, что программисты вообще никак не защищаются и ничего не делают ради этого.
И в любой опенсорсный язык можно делать коммиты, почему-то никто не расширяет языки системой типов. Единственное исключение — JavaScript, но для него делать компиляторы вообще национальный спорт.
Вы путаете баги и дефекты. Да, время реализации фичи зависит от количества дефектов в программе, и язык может помогать или нет в их выявлении. Но количество багов, которые найдены на тестировании зависит только от программиста.
Я не говорил, что ничего. Я писал о том, что если бы роль системы типов была бы так велика, такие языки, как Python, Lua, PHP, JavaScript или не были бы столь популярны или быстро бы обзавелись системами типов.
Странная логика. После закрытия тикета продукт разворачивается у клиента, который вообще-то платит за это деньги. Вы на эти деньги живете, помогаете родителям, оплачиваете «развивашки» детям. Это не пофиг.
Мы не на научном симпозиуме. Я разговариваю с вами лично и мое предложение направлено на то, чтобы вы лично получили опыт, на который я ссылаюсь.
Возможно я ошибся. Судил по себе.
Все нравится.
Что в файле бяка написана.
Вы используете то что выдает вам тайпчекер как чеклист. В этом чеклисте нет ничего, кроме дефектов. Следовательно, выдача тайпчекера функционально эквивалентна реестру дефектов. Я тоже так делаю, можно считать эту практику условно хорошей.
Наоборот же, вырожденный случай. Например, статический анализ может сказать вам, что на ноль делить нельзя, а вот с точки зрения системы типов
int / int → float. Также, система типов не поведет бровью, если вы попытаетесь удалить из БД уже отсутствующий в ней объект.Если бы это реально влияло на продуктивность, все бы это делали с удовольствием.
Возможно. В чем конкретно?
Вы сами это написали.
Мда. После ваших саркастичных комментариев о том что я сам себе противоречу и выдаю желаемое за действительное я ожидал что вы придерживаетесь столь же высоких стандартов дискуссии, каких требуете от меня. Разочарован.
Я хочу, чтобы компилятор с помощью системы типов сказал мне что будет ай-ай-ай.
Ну практически вы говорите что полезно иметь реестр дефектов. И хорошо бы чтобы дефекты выявлялись автоматически. Спорить с этим бессмысленно, я полностью согласен с этими утверждением, но почему вы приписываете достижения статического анализатора системе типов?
До тех пор, пока у вас нет скрытой цели, ваша оценка будет достоверно отражать реальность.
Не, ну понятно, что психологические проблемы разные бывают. Говорить о продуктивности имеет смысл только после того, как все психологические проблемы решены и вам ничего не мешает. Иначе разговор про систему типов превратится в перечисление тараканов.
У меня не ломается. Про какой именно интеллисенс вы говорите? В какой среде? На каком языке?
Как вы это поняли? Вы переписываете модуль и у вас нет ошибок компиляции? Ну так может вы просто хороший программист?
На уровне личных ощущений. Сами все поймете.
А с чего вы взяли, что на производительность программиста влияет именно типизация, а не Intellisense в IDE? Я думаю, что Intellisense влияет больше, чем типизация.
Думаю, да. Есть типизированный диалект Python-а — Boo. Попробуйте сравнить.
Я думаю, что это, опять-же индивидуально для каждого работает. То есть, глобально все эти вещи программистам не нужны. Но некоторые программисты испытывают сложности с тем или иным кодом и им требуются дополнительные условия. То есть, это как протез. Нет ничего плохого в том, чтобы им пользоваться, но нельзя утверждать, что «протез увеличивает производительность для всех и каждого».
Более того, у нас есть кейсы с TypeScript и flow, и есть доклад, где прямо говорится, что для них статическая типизация практически не играет роли. (Небольшой эффект наблюдается при рефакторинге, но мы все прекрасно знаем, что рефакторинг — развлекаловка разработчика, ценности он не несет).
2. Вот именно. Статическая типизация — личное предпочтение конкретного программиста, и не влияет на продуктивность.
Вернемся к обсуждению по-существу?
Я вообще не считаю, что сама концепция тип объекта хоть сколько-то продуктивна. В реальной жизни объект проявляет себя только во взаимодействии с другими объектами, у него нет и не может быть универсальных черт, истинных с любой точки зрения. Концепт трейта мне видится более жизнеспособным.
А те задачи, которые сейчас выполняет типизация на уровне языка имеет больше смысла производить на уровне IDE: в реальном времени подсказывать программисту доступные возможности, ограничения, документацию, примеры использования, ограничения параметров и все остальное.
Типизация сильно помогает обучению, это правда и чем она строже, тем лучше. Но после того как вы научились программировать, типизация уже практически не влияет. Расставлять типы и думать об отказоустойчивом дизайне в современной парадигме просто невозможно — в любой момент концепция может поменяться и весь ваш дизайн придется с нуля переделывать.
И в любой опенсорсный язык можно делать коммиты, почему-то никто не расширяет языки системой типов. Единственное исключение — JavaScript, но для него делать компиляторы вообще национальный спорт.