Комментарии 100

Думаю, что основная причина отсутствия популярности у F# это, как ни странно, .Net, ведь любая программа на F# будет обладать примерно схожими эксплуатационными свойствами, как и такая-же программа на C#: она будет работать (плюс/минус) с той же скоростью, потреблять приблизительно столько же памяти и количество платформ на которых эти программы можно запустить будет точно таким же. Как результат, при выборе языка будут использованы такие критерии как:


  • доступность разработчиков на рынке и их цена
  • количество справочных и обучающих материалов
  • количество и качество библиотек/фреймворков.
  • Меньшее количество кода на фичу: такой код быстрее пишется, изучается и поддерживается.
  • Меньшее количество багов на фичу. В частности, можно забыть про NullReferenceException.
Только эти два критерия относятся не к языку, а к программисту. Программист пишет больше или меньше кода, и баги допускает тоже программист.

Именно поэтому на программах на C++ и на Java одинаковое количество багов </sarcasm>

Вы путаете баги и дефекты. Да, время реализации фичи зависит от количества дефектов в программе, и язык может помогать или нет в их выявлении. Но количество багов, которые найдены на тестировании зависит только от программиста.
по этой же причине языки без строгой статической типизации — приводят к большему количеству трудноотлавлиемых багов (само собой речь не о двух обсуждаемых языках)
Если бы ваши слова были правдой, то программисты сделали бы динамические проверки типов в языках без статической типизации. Но практика показывает, что программисты вообще никак не защищаются и ничего не делают ради этого.
И в любой опенсорсный язык можно делать коммиты, почему-то никто не расширяет языки системой типов. Единственное исключение — JavaScript, но для него делать компиляторы вообще национальный спорт.
Коммиты вы сделать не сможете… А вот МР — можете… Которые отклонят в большинстве случаев… Есть опыт… Вы слишком идеализируете опенсурс…
Ну так MR — это запрос на включение коммитов. Если бы это было реально нужно, то не отклонили бы и было бы очень много желающих расширить языки системами типов. Того что этого нет однозначно свидетельствует, что важность системы типов сильно преувеличена.
я имею ввиду — в рабочую ветку вы ничего незакомитите. МР вы создать можете. Но судя по тому что я наблюдаю — КРАЙНЕ РЕДКО принимают МР не от «своих»…
Вы можете сделать форк и если ваш форк с системой типов был бы кому-нибудь нужен он стал бы более популярен чем оригинал.
Вернемся к обсуждению по-существу?
Того что этого нет однозначно свидетельствует, что важность системы типов сильно преувеличена.

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


Отсутствие MR'ов в условный питон всего лишь означает, что тем, кто пишет на питоне, по тем или иным причинам это не нужно (а когда становится нужно, например, они могут перестать писать на питоне и мигрировать на другой язык).

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

Потому что


  1. Накрутить систему типов сверху к уже имеющемуся языку очень нетривиально. А сохранение совместимости с нетипизированным кодом означает, что и весьма трудоёмко, так как придётся обновлять хотя бы распространённые библиотеки и заставлять их поддерживать аннотации типов.
  2. Если я ценитель статической типизации, то зачем мне это, если я могу сразу взять статически типизированный язык?
1. В мире полно талантливых людей, которе будут рады решить любую нетривиальную задачу.
2. Вот именно. Статическая типизация — личное предпочтение конкретного программиста, и не влияет на продуктивность.
В мире полно талантливых людей, которе будут рады решить любую нетривиальную задачу.

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


Вот именно.

Не понял связи, ну да ладно.


Статическая типизация — личное предпочтение конкретного программиста, и не влияет на продуктивность.

Что значит «не влияет»? То есть, если я возьму нетипизированный язык, то моя продуктивность не упадёт? Или существует человек, у которого на нетипизированном языке такая же производительность, как у меня на типизированном?


А тесты, кстати, влияют на продуктивность? А грамотная архитектура, солиды-киссы всякие, не знаю?

Что именно запрещает Тьюринг?

Что значит «не влияет»? То есть, если я возьму нетипизированный язык, то моя продуктивность не упадёт?

Думаю, да. Есть типизированный диалект Python-а — Boo. Попробуйте сравнить.

А тесты, кстати, влияют на продуктивность? А грамотная архитектура, солиды-киссы всякие, не знаю?

Я думаю, что это, опять-же индивидуально для каждого работает. То есть, глобально все эти вещи программистам не нужны. Но некоторые программисты испытывают сложности с тем или иным кодом и им требуются дополнительные условия. То есть, это как протез. Нет ничего плохого в том, чтобы им пользоваться, но нельзя утверждать, что «протез увеличивает производительность для всех и каждого».
Что именно запрещает Тьюринг?

Вывод типов для достаточно мощных систем типов, например. Или статический анализ нетривиальных свойств на непредназначенном для этого изначально языке без false positive'ов и false negative'ов.


Ну, строго говоря, запрещает Райс, но это одного поля ягоды.


Думаю, да. Есть типизированный диалект Python-а — Boo. Попробуйте сравнить.

Боюсь, что я недостаточно хорошо знаю питон, чтобы сравнение было репрезентативным.


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

Не называете ли вы тут протезом условный бульдозер, утверждая, что есть люди, способные тайпчекать в голове делать то же, что делает бульдозер, и для которых он является протезом?

Что-то я не понял что конкретно он запрещает. Берем JavaScript. Добавляем в него flow на уровне V8, пишем пропозал, пропозал принимают. Что там Райс запрещает я не понимаю.

Боюсь, что я недостаточно хорошо знаю питон, чтобы сравнение было репрезентативным.

На уровне личных ощущений. Сами все поймете.

Не называете ли вы тут протезом условный бульдозер, утверждая, что есть люди, способные тайпчекать в голове делать то же, что делает бульдозер, и для которых он является протезом?

А с чего вы взяли, что на производительность программиста влияет именно типизация, а не Intellisense в IDE? Я думаю, что Intellisense влияет больше, чем типизация.
А с чего вы взяли, что на производительность программиста влияет именно типизация, а не Intellisense в IDE? Я думаю, что Intellisense влияет больше, чем типизация.

С того, что внятный Intellisense куда проще прикрутить к статически типизированному языку.

Не поспоришь. Но тогда на производительность программиста влияет возможность статического анализа, а не типизация.

… Который можно сделать более простым и точным в статически типизированных языках, при прочих равных.

Вот это самое «при прочих равных» портит всю малину. Я не знаю кейсов, где эти самые «прочие равные» имели бы место.
Что-то я не понял что конкретно он запрещает. Берем JavaScript. Добавляем в него flow на уровне V8, пишем пропозал, пропозал принимают. Что там Райс запрещает я не понимаю.

Он запрещает автоматически вывести типы и аннотации для всех библиотек, например. Или иметь такую систему типов, в которой можно (разрешимо) типизировать любой семантически валидный сегодня JS-код.


На уровне личных ощущений. Сами все поймете.

Так это же и будет означать субъективную продуктивность, разве нет?


А с питоном я на порядки менее продуктивен, чем с хаскелем, например, если программа маленькая, и в бесконечное число раз менее продуктивен, если большая (потому что на питоне я её не способен закончить никогда).


А с чего вы взяли, что на производительность программиста влияет именно типизация, а не Intellisense в IDE? Я думаю, что Intellisense влияет больше, чем типизация.

Только интеллисенс, который пытается выводить типы, ломается даже на простейших примерах.

Во flow это делается не автоматически. Если библиотека экспортирует для себя декларации типов, flow ее подхватывает. Если нет то нет.

Так это же и будет означать субъективную продуктивность, разве нет?

До тех пор, пока у вас нет скрытой цели, ваша оценка будет достоверно отражать реальность.

А с питоном я на порядки менее продуктивен, чем с хаскелем

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

Только интеллисенс, который пытается выводить типы, ломается даже на простейших примерах.

У меня не ломается. Про какой именно интеллисенс вы говорите? В какой среде? На каком языке?
Во flow это делается не автоматически. Если библиотека экспортирует для себя декларации типов, flow ее подхватывает. Если нет то нет.

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


До тех пор, пока у вас нет скрытой цели, ваша оценка будет достоверно отражать реальность.

Кажется, вы сами себе противоречите.


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

А это удобно — если результат эксперимента не такой, как вам нужно, можно просто объявить это психологическими проблемами!


У меня не ломается. Про какой именно интеллисенс вы говорите? В какой среде? На каком языке?

PyCharm, полгода назад. На простейших случаях (которые я не воспроизведу, впрочем, ибо это было на работе, а личного кода на питоне у меня нет).

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

Если бы это реально влияло на продуктивность, все бы это делали с удовольствием.

Кажется, вы сами себе противоречите.

Возможно. В чем конкретно?

А это удобно — если результат эксперимента не такой, как вам нужно, можно просто объявить это психологическими проблемами!

Вы сами это написали.

PyCharm, полгода назад. На простейших случаях (которые я не воспроизведу, впрочем, ибо это было на работе, а личного кода на питоне у меня нет).

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

Для любой практики можно найти людей, которые ей не следуют. Означает ли это, что ничего не влияет на продуктивность? Но это так, если говорить о метауровне.


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


Возможно. В чем конкретно?

Когда сначала говорите о субъективности опыта, а потом о том, что для сравнения продуктивности достаточно собственного опыта.


Вы сами это написали.

Я изначально написал, что с питоном менее продуктивен. Про психологические проблемы и что-то ещё говорить начали таки вы.


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

Я всего лишь делюсь собственным опытом, как вы и просили. А опыт — ну, какой есть, не понимаю, чем он вам не нравится.

Для любой практики можно найти людей, которые ей не следуют. Означает ли это, что ничего не влияет на продуктивность? Но это так, если говорить о метауровне.

Я не говорил, что ничего. Я писал о том, что если бы роль системы типов была бы так велика, такие языки, как Python, Lua, PHP, JavaScript или не были бы столь популярны или быстро бы обзавелись системами типов.

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

Странная логика. После закрытия тикета продукт разворачивается у клиента, который вообще-то платит за это деньги. Вы на эти деньги живете, помогаете родителям, оплачиваете «развивашки» детям. Это не пофиг.

Когда сначала говорите о субъективности опыта, а потом о том, что для сравнения продуктивности достаточно собственного опыта.

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

Я изначально написал, что с питоном менее продуктивен. Про психологические проблемы и что-то ещё говорить начали таки вы.

Возможно я ошибся. Судил по себе.

Я всего лишь делюсь собственным опытом, как вы и просили. А опыт — ну, какой есть, не понимаю, чем он вам не нравится.

Все нравится.
Я писал о том, что если бы роль системы типов была бы так велика, такие языки, как Python, Lua, PHP, JavaScript или не были бы столь популярны или быстро бы обзавелись системами типов.

Ну у JS до поры до времени не было толком альтернатив, да и там сейчас есть всякие навёрнутые сверху системы типов. Python популярен как клей, да и там есть mypy. PHP популярен на серверах с начала нулевых, когда ничего другого на сервера толком не поставишь, и там тоже вроде что-то впиливают.


Писать на всём этом крупные системы — нуу, по факту, кажется, этого не происходит.


После закрытия тикета продукт разворачивается у клиента, который вообще-то платит за это деньги. Вы на эти деньги живете, помогаете родителям, оплачиваете «развивашки» детям. Это не пофиг.

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


Я вживую видел ровно два подхода:


  1. На качество всем плевать. Таски двигаются, KPI считается, дни проходят, зарплата капает. Там ни тесты, ни типы, ничего никому не нужно.
  2. Качество всем очень важно, потому что качество конвертируется в прямую прибыль вот прям сразу. И тогда там и типы, и обсуждение, как бы туда формальную верификацию прикрутить.

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

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

Ну у JS до поры до времени не было толком альтернатив, да и там сейчас есть всякие навёрнутые сверху системы типов. Python популярен как клей, да и там есть mypy. PHP популярен на серверах с начала нулевых, когда ничего другого на сервера толком не поставишь, и там тоже вроде что-то впиливают.

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

Писать на всём этом крупные системы — нуу, по факту, кажется, этого не происходит.

На всех этих языках написаны системы самой разной степени крупности. В гугле Python один из трех основных языков. На JavaScript-е и PHP практически весь веб написан. Включая хабр, вот. Хабр — достаточно крупная система?


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

Мда. Вы, видимо, в спор втянулись только ради спора.

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

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

То есть, факт наличия TS, mypy и тому подобного вы просто отрицаете, что ли?


В гугле Python один из трех основных языков.

На одной прошлой работе Python тоже был одним из основных языков. На нём всякие вспомогательные скрипты писали с околонулевой логикой.


Но, например, tensorflow написан на плюсах, chrome написан на плюсах, android тоже вроде как не на питоне. Вот это — большие проекты. Да и в соседнем треде к месту вспомнили про «Please don't use Python except for small scripts».


На всех этих языках написаны системы самой разной степени крупности.

LLVM написан на плюсах, ghc — хаскель, антиспам в фейсбуке — хаскель, сайт фейсбука — HHVM, который опционально типизированный пхп (и опциональность там исключительно из-за нужды поддержки легаси), один мой приятель по вузу делает типизированные руби для одной крупной фирмы.


Есть что-нибудь уровня LLVM или Chrome на питоне или JS?


Включая хабр, вот. Хабр — достаточно крупная система?

Известная, популярная, но не крупная. Что-то мне подсказывает, что по объёму кода какой-нибудь вордпресс или друпал будут крупнее, особенно если учесть всю экосистему с расширениями.


Мда. Вы, видимо, в спор втянулись только ради спора.

Не знаю, как это интерпретировать.


И в этом, конечно, питон виноват.

Нет, конечно. Это исключительно моя вина, что если в языке типы есть, то мне там проще, чем если в языке типов нет.

То есть, факт наличия TS, mypy и тому подобного вы просто отрицаете, что ли?

Не сами факты, а их значение для доказательства.
Нужно понимать, что TS — единорог, появился в недрах крупной компании и ему удалось проникнуть в один из крупнейших фреймворков. То есть, это успех для TS, безусловная инновация, однако это доказывает, что «мелкие игроки повторяют за крупными», а не того, что «система типов позитивно влияет на продуктивность».
А вот кейс mypy как раз показывает, что системы типов не так уж и нужны: несмотря на существование такой проверки, далеко не каждый программист им пользуется. И именно такой кейс показателен: нельзя просто так списать на то, что mypy просто недостаточно разрекламирован. Любой программист знает о существовании разных языков и систем типов. Ему просто не нужна система типов, его это не волнует.

На одной прошлой работе Python тоже был одним из основных языков. На нём всякие вспомогательные скрипты писали с околонулевой логикой.

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

Но, например, tensorflow написан на плюсах, chrome написан на плюсах, android тоже вроде как не на питоне. Вот это — большие проекты. Да и в соседнем треде к месту вспомнили про «Please don't use Python except for small scripts».

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

LLVM написан на плюсах, ghc — хаскель, антиспам в фейсбуке — хаскель, сайт фейсбука — HHVM, который опционально типизированный пхп (и опциональность там исключительно из-за нужды поддержки легаси), один мой приятель по вузу делает типизированные руби для одной крупной фирмы.

Нужно понимать, зачем типы в больших компаниях. Дело в том, что в них очень большая текучка между проектами. Поработать пару недель на одном, а потом на другом — обычное дело. Когда смотришь на компанию снаружи, эта текучка не видна, но внутри там все очень подвижно. И понятно зачем им система типов. Зачем она вам/нам — вот это вопрос на миллион.

Есть что-нибудь уровня LLVM или Chrome на питоне или JS?

JS интерпретируемый язык. В принципе, вы могли бы спросить почему все эти вещи не написаны на Java или на C#, и ответ был бы таким же.

Известная, популярная, но не крупная. Что-то мне подсказывает, что по объёму кода какой-нибудь вордпресс или друпал будут крупнее, особенно если учесть всю экосистему с расширениями.

Насколько мне известно, у Хабра свой движок, и раньше ТМ запускало на этом движке разные тематические проекты. Т.е. хабр = (друпал или вордпресс) + кастомный код.
Ну, не знаю тогда. Большинство веб-проектов меньше даже хабра, и если система типов работает только для очень крупных проектов, то нет смысла обсуждать ее влияние на продуктивность, потому у нее просто тогда слишком маленькая область применения.

Нет, конечно. Это исключительно моя вина, что если в языке типы есть, то мне там проще, чем если в языке типов нет.

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

А уж как удобно и продуктивно на баше писать…
Это какой-то психологический эффект, я не знаю. Например, я могу на баше просто вызвать внешнюю утилиту, чтобы прочитать из мегабайтного файла одно число, а на питоне уже как-то поперек горла такое решение.
Это довольно любопытно, потому что проявляет тот факт, что, видимо, многие языки написаны не в угоду одной лишь продуктивности.
И судя по тому, что очень много программистов вообще в ус не дуют по поводу систем типов, похоже, что они нужны также не ради продуктивности.
Скрипт в 3 строки для запуска пары готовых программ — да, удобно и быстро пишется на баше. Большой проект — лучше разрабатывать почти на чём угодно другом. Поэтому ваш довод
Тот факт, что для вспомогательных скриптов используется язык без типизации однозначно говорит, что типизация не увеличивает продуктивность.

далёк от реальности.
Вы так пишете, что не даете мне возможности как-то оспорить ваше утверждение. Возможно далек, возможно не далек. В той формулировке, что вы выбрали ваше утверждение невозможно осмыслить критически.
Я не утверждаю, что надо все бросить и пойти писать на баше. Я лишь утверждаю, что вопрос о том, что типизация увеличивает продуктивность — открыт.
Я лишь утверждаю, что вопрос о том, что типизация увеличивает продуктивность — открыт.

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

неактуален: из такой же логики следует, что баш удобен для разработки софта.
из такой же логики следует, что баш удобен для разработки софта

Я не понял, как из «типизация не увеличивает продуктивность» у вас получилось «баш удобен для разработки софта». Возможно, баш не удобен для разработки софта по тысяче разных причин, кроме отсутствия в нем системы типов.

Открыт или закрыт — не важно

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

На самом же деле из того, что «язык без типизации» (баш) «используется для вспомогательных скриптов», никак не следует, что «типизация не увеличивает продуктивность». А уж тем более «однозначно».
Ну так если бы типизация увеличивала продуктивность, никто бы не писал вспомогательные скрипты на баше. Все бы писали их на, не знаю, хаскелле, например.
И даже если вы скажете, что «хаскель нужно ставить, а баш доступен сразу», то почему тогда в баш за годы его развития не добавили систему типов?
И даже если ответ будет «потому что авторы баша в коматозе и не развивают его», почему тогда в дистрибутивы вставляют питон, но не вставляют хаскель?
Ровно по такой же логике структуры, объекты и многое другое не увеличивают продуктивность: их ведь в баше нет, а на баше пишут скрипты. С этим утверждением вы, получается, тоже согласны?
Противоречие, которое вы нашли — кажущееся, от того, что я позволил себе пренебречь церемониями, сократить время. Вы воспользовались этим сокращением, чтобы «загнать меня в ловушку». Это примерно то же самое, что говорить что А. С. Пушкин — не обязательно Александр, это может быть и Андрей.

То что вы вообще в принципе такие приемы применяете говорит о том, что вы лишь играете в логику.
Вы же этот аргумент не в пустоте привели, а утверждаете что из него что-то следует касательно продуктивности и типизации в языке. В итоге оказалось, что аргумент действительно совершенно некорректный.
Вы показали не некорректность аргумента, а что следует внимательно относиться к выбору собеседника )
Нужно понимать, что TS — единорог, появился в недрах крупной компании и ему удалось проникнуть в один из крупнейших фреймворков. То есть, это успех для TS, безусловная инновация однако это доказывает, что «мелкие игроки повторяют за крупными», а не того, что «система типов позитивно влияет на продуктивность».

А как вы разделяете одно доказательство от другого? Или у вас на любой аргумент есть контр-аргумент, утверждающий, что аргумент на самом деле не о преимуществах системы типов, а о чём-то другом?


А вот кейс mypy как раз показывает, что системы типов не так уж и нужны: несмотря на существование такой проверки, далеко не каждый программист им пользуется. И именно такой кейс показателен: нельзя просто так списать на то, что mypy просто недостаточно разрекламирован. Любой программист знает о существовании разных языков и систем типов. Ему просто не нужна система типов, его это не волнует.

Однако mypy при этом вполне пилится и развивается, его поддержка добавляется в питон, и так далее.


А что до программистов — ну, кто-то и на современные языки переходить не хочет, предпочитая писать на коболе каком-нибудь, или на C++03.


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

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


Но я очень часто видел, как система типов ломала чуть более сложные скрипты, и люди тратили значимое время на то, чтобы починить что-нибудь, сломанное после рефакторинга.


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

Однако даже он даёт больше статических гарантий, чем питон.


Тип в плюсах нужен только ради того, чтобы получить указатель на функцию-метод класса.

Разработчикам на плюсах только об этом не говорите. Не поймут-с.


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

Вы, кажется, перепутали большие компании с бодишопом. Как думаете, какая текучка на проектах типа LLVM или V8?


И понятно зачем им система типов. Зачем она вам/нам — вот это вопрос на миллион.

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


JS интерпретируемый язык. В принципе, вы могли бы спросить почему все эти вещи не написаны на Java или на C#, и ответ был бы таким же.

Каким?


Компилятор хаскеля вон на хаскеле написан, компилятор первого идриса — на хаскеле, компилятор агды — на хаскеле, компилятор всяких MLей — на MLях, хотя эти языки далеко не всегда топ в производительности.


Проще значит привычнее?

Нет. Опыт перехода на более строгие языки у меня есть, когда становилось как раз более непривычно, и я могу с этим опытом сравнить.

А как вы разделяете одно доказательство от другого?

Свидетельство. Я вообще не считаю, что в таком сложном вопросе можно найти строгое доказательство.

Или у вас на любой аргумент есть контр-аргумент, утверждающий, что аргумент на самом деле не о преимуществах системы типов, а о чём-то другом?

Да, я стараюсь рассматривать множество альтернативных вариантов.

А что до программистов — ну, кто-то и на современные языки переходить не хочет, предпочитая писать на коболе каком-нибудь, или на C++03.

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

Однако даже он даёт больше статических гарантий, чем питон.

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

Разработчикам на плюсах только об этом не говорите. Не поймут-с.

Вроде об этом Фаулер писал. Так что все в курсе.

Вы, кажется, перепутали большие компании с бодишопом. Как думаете, какая текучка на проектах типа LLVM или V8?

Это комьюнити проекты, там картина другая. Любой проект, когда выходит в паблик — это успешный проект. Мы вообще ничего не знаем о внутренних, а их там сотни.

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

Не каждую, разумеется. Сегодня спагетти-код считается моветом и программы структурируются довольно крупными блоками: функция, класс, модуль. Это вы и я вспомним и через 5 и через 10 лет.

Каким?

Медленно.

Компилятор хаскеля вон на хаскеле написан, компилятор первого идриса — на хаскеле, компилятор агды — на хаскеле, компилятор всяких MLей — на MLях, хотя эти языки далеко не всегда топ в производительности.

Это тут вообще роли не играет. Все перечисленные языки выполняются на виртуальной машине.

Нет. Опыт перехода на более строгие языки у меня есть, когда становилось как раз более непривычно, и я могу с этим опытом сравнить.

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

Вообще-то Haskell компилируется в нативный код.

AnthonyMikh Haskell не был перечислен.

Кроме того, я не знаю, как именно он компилируется. Может быть, он не использует все оптимальные процессорные инструкции.
Haskell не был перечислен.

Вообще-то был:


Компилятор хаскеля вон на хаскеле написан, компилятор первого идриса — на хаскеле, компилятор агды — на хаскеле, компилятор всяких MLей — на MLях, хотя эти языки далеко не всегда топ в производительности.

OCaml тоже компилируется в нативный код (насколько я знаю), первый идрис — тоже (да и второй). С агдой вот всё сложно.

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

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

Это понятно. Я про то и пишу, что вы связываете потребность в безопасности и статическую типизацию как будто бы это само собой разумеется.
Однако, почему программерская мысль остановилась на этом этапе? Что мешает пойти еще дальше?
Если бы ваши слова были правдой, то программисты сделали бы динамические проверки типов в языках без типизации. Но практика показывает, что программисты вообще никак не защищаются и ничего не делают ради этого.

Разве что не пишут на языках без типизации? =)
Пишут. Одни из самых популярных языков в мире — JavaScript, PHP и Python.
Конечно. Если бы статическая типизация была такой полезной, как ее малюют, программисты быстро бы расширили эти языки системой типов.
Более того, у нас есть кейсы с TypeScript и flow, и есть доклад, где прямо говорится, что для них статическая типизация практически не играет роли. (Небольшой эффект наблюдается при рефакторинге, но мы все прекрасно знаем, что рефакторинг — развлекаловка разработчика, ценности он не несет).
По тону понятно, что вы не согласны, но пока вы не сформулируете аргумент, я не могу ничего на это ответить.
Но количество багов, которые найдены на тестировании зависит только от программиста.

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

Назовите меня мракобесом — но я считаю что язык с хорошей и грамотной архитектурой отловит 99% процентов багов при компиляции или статическом анализе

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

Так ответ уже есть — «хорошая и грамотная архитектура языка», это та, которая обеспечивает нахождение багов во время компиляции или статического анализа с вероятностью 99% )))
Ну так а зачем вам гарантии от самого себя? Когда вы из файла или из базы читаете бяку, типизация вам вообще никак не поможет.
Типизация сильно помогает обучению, это правда и чем она строже, тем лучше. Но после того как вы научились программировать, типизация уже практически не влияет. Расставлять типы и думать об отказоустойчивом дизайне в современной парадигме просто невозможно — в любой момент концепция может поменяться и весь ваш дизайн придется с нуля переделывать.
Когда вы из файла или из базы читаете бяку, типизация вам вообще никак не поможет.

Типизация может помочь убедиться, что у меня есть рантайм-проверки, бяка пришла из БД (или из сокета) или нет.


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

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

Как? Допустим прочитали вы файл в строку. Что-то я не знаю такой системы типов, которая могла бы такие случаи анализировать.

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

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

Ну давайте поиграем в игру. Я прочитал файл в строку (ну или для простоты число, всё, что работает для чисел, сработает и для строк, просто писанины будет меньше). Что вы хотите провалидировать?


Как вы это поняли? Вы переписываете модуль и у вас нет ошибок компиляции? Ну так может вы просто хороший программист?

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

Что вы хотите провалидировать?

Я хочу, чтобы компилятор с помощью системы типов сказал мне что будет ай-ай-ай.

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

Ну практически вы говорите что полезно иметь реестр дефектов. И хорошо бы чтобы дефекты выявлялись автоматически. Спорить с этим бессмысленно, я полностью согласен с этими утверждением, но почему вы приписываете достижения статического анализатора системе типов?
Я хочу, чтобы компилятор с помощью системы типов сказал мне что будет ай-ай-ай.

Ай-ай-ай какого рода-то?


Ну практически вы говорите что полезно иметь реестр дефектов. И хорошо бы чтобы дефекты выявлялись автоматически.

Какой реестр дефектов? Причём тут он?


Спорить с этим бессмысленно, я полностью согласен с этими утверждением, но почему вы приписываете достижения статического анализатора системе типов?

Потому что система типов — это наиболее выраженный и прокачанный случай статического анализа.

Ай-ай-ай какого рода-то?

Что в файле бяка написана.

Какой реестр дефектов? Причём тут он?

Вы используете то что выдает вам тайпчекер как чеклист. В этом чеклисте нет ничего, кроме дефектов. Следовательно, выдача тайпчекера функционально эквивалентна реестру дефектов. Я тоже так делаю, можно считать эту практику условно хорошей.

Потому что система типов — это наиболее выраженный и прокачанный случай статического анализа.

Наоборот же, вырожденный случай. Например, статический анализ может сказать вам, что на ноль делить нельзя, а вот с точки зрения системы типов int / int → float. Также, система типов не поведет бровью, если вы попытаетесь удалить из БД уже отсутствующий в ней объект.
Что в файле бяка написана.

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


Например, статический анализ может сказать вам, что на ноль делить нельзя, а вот с точки зрения системы типов int / int → float.

А система типов не может, что ли?


safeDiv : (a, b : Int) -> { prf : Not (b = 0) } -> Rational

Всё, эту функцию нельзя вызывать, если нет свидетельства того, что делитель ненулевой.


Также, система типов не поведет бровью, если вы попытаетесь удалить из БД уже отсутствующий в ней объект.

А как тут статический анализ поможет? Это внешний ресурс с не пойми как специфицируемым поведением (что тоже можно типизировать, но смысла в этом мало ввиду того, что БД — разделяемый ресурс, и туда между делом может написать кто-нибудь ещё).

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

Как он это проверит? Откуда он что-то знает про формат файла?

Всё, эту функцию нельзя вызывать, если нет свидетельства того, что делитель ненулевой.

То есть, ваше решение — делать двойную работу: вначале расставлять типы так, чтобы компилятор вам надавал по рукам, а потом все равно делать рантайм-проверки. Вам не кажется это слегка шизофреничным? То что вы знаете что такой тип нужно поставить однозначно говорит о том, что вы не забудете вставить и рантайм-проверку. Но если у вас и так есть рантайм-проверка, нет необходимости дополнительно выражать это в типе.

А как тут статический анализ поможет? Это внешний ресурс с не пойми как специфицируемым поведением (что тоже можно типизировать, но смысла в этом мало ввиду того, что БД — разделяемый ресурс, и туда между делом может написать кто-нибудь ещё).

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

При этом я не говорю и о том, что система типов не нужна. Лишь о том, что ее влияние на продуктивность под большиииим вопросом.
Как он это проверит? Откуда он что-то знает про формат файла?

Он потребует у меня это проверить. Ну, потому что в типе функции написано, что ей надо передать аргумент-доказательство того, что в файле не бяка. А бяка там или нет — определяете вы.


То есть, ваше решение — делать двойную работу: вначале расставлять типы так, чтобы компилятор вам надавал по рукам, а потом все равно делать рантайм-проверки.

Рантайм-проверки, кстати, не обязательны (если вы статически можете доказать, что всё будет хорошо), либо их можно делать ровно один раз, и потом таскать свидетельство проверки с собой.


Вам не кажется это слегка шизофреничным? То что вы знаете что такой тип нужно поставить однозначно говорит о том, что вы не забудете вставить и рантайм-проверку. Но если у вас и так есть рантайм-проверка, нет необходимости дополнительно выражать это в типе.

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


Конечно, если вы бесконечно внимательны 100% времени и никогда не делаете ошибок, то вам это всё не нужно. Но я не такой.


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

Система типов по определению статическая штука. Так что не очень понимаю, о чём мы тут спорим. А если система типов достаточно выразительная, то она и есть то, что вы называете статическим анализом. Только без false negative'ов.


В этом мой поинт: система типов создает лишь иллюзию безопасности, оставляя реальные проблемы актуальными.

Зависит от её силы.


Так и всё же, причём тут БД и как статический анализ решает эту проблему?


А, ну и да, я сегодня не выспался и забыл в предыдущем комментарии написать:


Вы используете то что выдает вам тайпчекер как чеклист. В этом чеклисте нет ничего, кроме дефектов. Следовательно, выдача тайпчекера функционально эквивалентна реестру дефектов.

Только она эквивалентна реестру дефектов, в котором счётно бесконечное число дефектов. У вас где-нибудь такие реестры были?

Он потребует у меня это проверить.

А откуда он это узнает? Ну, допустим, я пишу парсер JSON-а. Как система типов заставит меня проверить баланс скобочек?

Конечно, если вы бесконечно внимательны 100% времени и никогда не делаете ошибок, то вам это всё не нужно. Но я не такой.

Ясно. Рад, что система типов вам помогает. Но, простите, это разговор уже не о продуктивности.
А откуда он это узнает?

Потому что в сигнатуре функции это написано, например?


Ну, допустим, я пишу парсер JSON-а. Как система типов заставит меня проверить баланс скобочек?

Парсер жсона — вообще нетривиальная задача, потому что JSON — нетривиальный формат, ну да ладно. Только зачем там проверять баланс скобочек?


Ясно. Рад, что система типов вам помогает. Но, простите, это разговор уже не о продуктивности.

А к чему относится помощь инструментов при разработке, если не к продуктивности?

Потому что в сигнатуре функции это написано, например?

Ну, я так понял, что я должен сделать иерархию наследования FileJSONFileSyntacticallyCorrectJSONFile, а потом использовать в своем коде только указатели на SyntacticallyCorrectJSONFile. Но это же смешно. Если я допустил ошибку в определении корректности синтаксиса, система типов мне радостно отрапортует что все безопасно, хотя по факту безопасностью там и не пахло.

Парсер жсона — вообще нетривиальная задача, потому что JSON — нетривиальный формат, ну да ладно. Только зачем там проверять баланс скобочек?

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

А к чему относится помощь инструментов при разработке, если не к продуктивности?

Ну, смотрите. Есть два человека. Предположим, что один пишет код со скоростью 10 поинтов в итерацию, а другой со скоростью 5 поинтов в итерацию. Мы можем дать второму систему типов и он начнет писать код со скоростью 7 поинтов за итерацию.
Это неплохо, но, может ему стоит посоветовать для начала подкачать свои навыки до тех пор, пока он не достигнет производительности в 10 поинтов, прежде, чем искать внешние инструменты? Может быть, с точки зрения 10 поинтов актуальные проблемы будут уже другими?
Ну, я так понял, что я должен сделать иерархию наследования File → JSONFile → SyntacticallyCorrectJSONFile, а потом использовать в своем коде только указатели на SyntacticallyCorrectJSONFile. Но это же смешно. Если я допустил ошибку в определении корректности синтаксиса, система типов мне радостно отрапортует что все безопасно, хотя по факту безопасностью там и не пахло.

Нет, зачем? Никакой иерархии наследования (в таких языках нет наследования), просто foo : JSONFile -> ... или что-то подобное. Или foo : (f : JSONFile) -> HasKey "meh" f, если вам нужно доказательство наличия ключа. И так далее.


Если я допустил ошибку в определении корректности синтаксиса, система типов мне радостно отрапортует что все безопасно, хотя по факту безопасностью там и не пахло.

Для этого вам её надо допустить везде, во всей программе, если упрощать. Практика показывает, что это сделать сложно.


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

Можно начать с «прочитать из сокета данные, где в первых четырёх байтах длина, а в следующих — содержимое, со статическими гарантиями невыхода за границы массива и обработки плохих случаев». Продолжить можно с «подключиться к БД, достать схему и проверить, что все запросы соответствуют этой схеме».


Предположим, что один пишет код со скоростью 10 поинтов в итерацию, а другой со скоростью 5 поинтов в итерацию. Мы можем дать второму систему типов и он начнет писать код со скоростью 7 поинтов за итерацию.
Это неплохо, но, может ему стоит посоветовать для начала подкачать свои навыки до тех пор, пока он не достигнет производительности в 10 поинтов, прежде, чем искать внешние инструменты? Может быть, с точки зрения 10 поинтов актуальные проблемы будут уже другими?

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

если вам нужно доказательство наличия ключа. И так далее.

Мне нужно чтобы система типов мне гарантировала, что в файле не будет бяки.

Для этого вам её надо допустить везде, во всей программе, если упрощать. Практика показывает, что это сделать сложно.

Поясните.

Можно начать с «прочитать из сокета данные, где в первых четырёх байтах длина, а в следующих — содержимое, со статическими гарантиями невыхода за границы массива и обработки плохих случаев». Продолжить можно с «подключиться к БД, достать схему и проверить, что все запросы соответствуют этой схеме».

Хорошие примеры. Теперь покажите, как это решается с помощью системы типов.

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

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

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

Расставлять типы и думать об отказоустойчивом дизайне в современной парадигме просто невозможно

Не затруднит ли вас привести конкретный пример с динамический типизацией, которая позволит вам менять дизайн быстрее, чем со статической?
Мой аргумент не в защиту динамической типизации, как единственной альтернативе статической. Мой аргумент про то, что типизация оказывает разве что психологический эффект.
Я вообще не считаю, что сама концепция тип объекта хоть сколько-то продуктивна. В реальной жизни объект проявляет себя только во взаимодействии с другими объектами, у него нет и не может быть универсальных черт, истинных с любой точки зрения. Концепт трейта мне видится более жизнеспособным.
А те задачи, которые сейчас выполняет типизация на уровне языка имеет больше смысла производить на уровне IDE: в реальном времени подсказывать программисту доступные возможности, ограничения, документацию, примеры использования, ограничения параметров и все остальное.
Я вообще не считаю, что сама концепция тип объекта хоть сколько-то продуктивна. [...] Концепт трейта мне видится более жизнеспособным.

Вы так пишете, как будто трейты — не статическая типизация.


А те задачи, которые сейчас выполняет типизация на уровне языка имеет больше смысла производить на уровне IDE

Чтобы IDE могла чего-то там подсказывать, надо чтобы кто-то описал статические типы, пусть даже в документации.

Программист пишет больше или меньше кода, и баги допускает тоже программист.

С одной стороны соглашусь, но в целом логика опасная. Если язык позволяет мне на этапе компиляции увидеть, что я забыл обработать null ref — при прочих равных этот язык лучше. Можно заставить программиста по несколько раз пересматривать свой код, городить стены тестов, но зачем?
Напомнило, как у нас были проблемы с внесением изменений в один конкретный сервис, в котором архитектура отличалась от остальных. Авторы сервиса в ответ предложили «просто писать без багов». Спасибо, но лучше я буду считать себя глупым и невнимательным разработчиком и напишу так, чтобы потом поддерживать было легче.
Это справедливое рассуждение, юзабилити языка действительно имеет значение. Но если влияет именно юзабилити, почему бы тогда не перестать говорить про системы типов и не начать говорить про статический анализ в целом?

Подобными качествами обладают и другие функциональные языки, и выбор в пользу F# тут совсем не очевиден. Начиная с того, что он тащит с собой рантайм со сборщиком мусора и проверкой типов, который в функциональном языке особо-то и не нужен, заканчивая тем, что все библиотеки/фреймворки в .Net пишутся в первую очередь под C#.

Начиная с того, что он тащит с собой рантайм со сборщиком мусора и проверкой типов, который в функциональном языке особо-то и не нужен,


Можете раскрыть мысль?
По моим ощущениям необходимость типизации зависит скорее от объема проекта, а сборщик мусора вообще ортоганален понятиям ООП vs функциональщина, зависит от задач.

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

Основная причина отстутсвтия популярности F# — это отсутствие решарпера и медленный компилятор.

По крайней мере это то, почему я вернулся на C# после нескольких лет, когда понадобилось написать крупный проект.

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


Так что можно обратно на F#!

Этот райдер в F# хотябы умеет методы между модулями/классами носить? Сдаётся мне он также ограничен, как F# IntelliSense в студии.
НЛО прилетело и опубликовало эту надпись здесь
А я всегда говорил, что программистский жаргон — это искажённый тюремный. Вышел пацан из маргинализированной зоны, нигде не получалось находить работу.
Я понимаю, что все это спорная вещь, и люди будут говорить — да ну нахер ваш F#. Можно по разному относиться, но один хороший F# разработчик реально может заменить двух средних сишарперов.

Большую роль для бизнеса играет заменяемость программистов — т.е. возможность в удовлетворительные сроки найти нового программиста.

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

Если у тебя есть поле для экспериментов, например совсем свежий стартап, то можно взять неплохих сишарперов, научить их F#.

Не все согласятся.

Впрочем, это не отменяет того, что новые, более лучшие языки нужно пытаться создавать (как говорится — если не пробовать, то и не получится), и пропагандировать.
один хороший F# разработчик реально может заменить двух средних сишарперов

более того, любой хороший X разработчик реально может заменить двух средних Х кодеров :)
Более того, обычно проблема как раз найти одного хорошего разработчика, и если его можно заменить двумя средними, то это большой плюс, а если его можно заменить 4-мя джунами то вообще замечательно! К сожалению обычно нельзя(
в F# по умолчанию не может быть null рефов

Ну это развод лохов. F# может оперировать любыми объектами .Net, которые вполне могут быть null. Обычные строки, например, или массивы. Но по на самом то деле проблемы null dereference нет в том виде, как её преподносят адепты фп — первый же прогон интеграционных тестов даёт эксепшон, и null dereference мгновенно фиксится по стектрейсу

А вот тайп-суммы — полезная штука. Но конечно не настолько полезная, чтобы переходить из-за неё с топового языка на язык с хреновым IntelliSense и отсутствием фреймворков.

С другой стороны, есть задачи для которых ни фреймворки, ни зависимость от внешних C# либ не нужны. Парсинг например — вот тут F# на высоте, есть весьма удобная либа для парсер-комбинаторов. Или например сложные билинговые расчёты. В общем F# годен там, где чистая математика — вот там пригодится улучшенный вывод типов и тайп-суммы
Но по на самом то деле проблемы null dereference нет в том виде, как её преподносят адепты фп — первый же прогон интеграционных тестов даёт эксепшон, и null dereference мгновенно фиксится по стектрейсу

У вас настолько хорошие тесты, что они покрывают все пути исполнения?

Интеграционные и функциональные — да, они пишутся согласно спецификации на апи и покрывают всё возможные сценарии. Иначе грош им цена

Той же жертвой, например, пал Rust — все говорят, это язык для системой разработки, хотя на нем очень хорошо писать веб-приложения и бэкенды.

Сейчас все-таки ситуация меняется.

Есть еще F*, но я никогда е слышал что бы его кто-то использовал.
fstar-lang.org
Есть ли у вас комментарии по поводу этого языка?
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Минуточку внимания

Разместить