Комментарии 107
Думаю, что основная причина отсутствия популярности у F# это, как ни странно, .Net, ведь любая программа на F# будет обладать примерно схожими эксплуатационными свойствами, как и такая-же программа на C#: она будет работать (плюс/минус) с той же скоростью, потреблять приблизительно столько же памяти и количество платформ на которых эти программы можно запустить будет точно таким же. Как результат, при выборе языка будут использованы такие критерии как:
- доступность разработчиков на рынке и их цена
- количество справочных и обучающих материалов
- количество и качество библиотек/фреймворков.
- Меньшее количество кода на фичу: такой код быстрее пишется, изучается и поддерживается.
- Меньшее количество багов на фичу. В частности, можно забыть про NullReferenceException.
Только эти два критерия относятся не к языку, а к программисту. Программист пишет больше или меньше кода, и баги допускает тоже программист.
Именно поэтому на программах на C++ и на Java одинаковое количество багов </sarcasm>
Вы путаете баги и дефекты. Да, время реализации фичи зависит от количества дефектов в программе, и язык может помогать или нет в их выявлении. Но количество багов, которые найдены на тестировании зависит только от программиста.
НЛО прилетело и опубликовало эту надпись здесь
Если бы ваши слова были правдой, то программисты сделали бы динамические проверки типов в языках без статической типизации. Но практика показывает, что программисты вообще никак не защищаются и ничего не делают ради этого.
И в любой опенсорсный язык можно делать коммиты, почему-то никто не расширяет языки системой типов. Единственное исключение — JavaScript, но для него делать компиляторы вообще национальный спорт.
И в любой опенсорсный язык можно делать коммиты, почему-то никто не расширяет языки системой типов. Единственное исключение — JavaScript, но для него делать компиляторы вообще национальный спорт.
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
1. В мире полно талантливых людей, которе будут рады решить любую нетривиальную задачу.
2. Вот именно. Статическая типизация — личное предпочтение конкретного программиста, и не влияет на продуктивность.
2. Вот именно. Статическая типизация — личное предпочтение конкретного программиста, и не влияет на продуктивность.
НЛО прилетело и опубликовало эту надпись здесь
Что именно запрещает Тьюринг?
Думаю, да. Есть типизированный диалект Python-а — Boo. Попробуйте сравнить.
Я думаю, что это, опять-же индивидуально для каждого работает. То есть, глобально все эти вещи программистам не нужны. Но некоторые программисты испытывают сложности с тем или иным кодом и им требуются дополнительные условия. То есть, это как протез. Нет ничего плохого в том, чтобы им пользоваться, но нельзя утверждать, что «протез увеличивает производительность для всех и каждого».
Что значит «не влияет»? То есть, если я возьму нетипизированный язык, то моя продуктивность не упадёт?
Думаю, да. Есть типизированный диалект Python-а — Boo. Попробуйте сравнить.
А тесты, кстати, влияют на продуктивность? А грамотная архитектура, солиды-киссы всякие, не знаю?
Я думаю, что это, опять-же индивидуально для каждого работает. То есть, глобально все эти вещи программистам не нужны. Но некоторые программисты испытывают сложности с тем или иным кодом и им требуются дополнительные условия. То есть, это как протез. Нет ничего плохого в том, чтобы им пользоваться, но нельзя утверждать, что «протез увеличивает производительность для всех и каждого».
НЛО прилетело и опубликовало эту надпись здесь
Что-то я не понял что конкретно он запрещает. Берем JavaScript. Добавляем в него flow на уровне V8, пишем пропозал, пропозал принимают. Что там Райс запрещает я не понимаю.
На уровне личных ощущений. Сами все поймете.
А с чего вы взяли, что на производительность программиста влияет именно типизация, а не Intellisense в IDE? Я думаю, что Intellisense влияет больше, чем типизация.
Боюсь, что я недостаточно хорошо знаю питон, чтобы сравнение было репрезентативным.
На уровне личных ощущений. Сами все поймете.
Не называете ли вы тут протезом условный бульдозер, утверждая, что есть люди, способные тайпчекать в голове делать то же, что делает бульдозер, и для которых он является протезом?
А с чего вы взяли, что на производительность программиста влияет именно типизация, а не Intellisense в IDE? Я думаю, что Intellisense влияет больше, чем типизация.
А с чего вы взяли, что на производительность программиста влияет именно типизация, а не Intellisense в IDE? Я думаю, что Intellisense влияет больше, чем типизация.
С того, что внятный Intellisense куда проще прикрутить к статически типизированному языку.
НЛО прилетело и опубликовало эту надпись здесь
Во flow это делается не автоматически. Если библиотека экспортирует для себя декларации типов, flow ее подхватывает. Если нет то нет.
До тех пор, пока у вас нет скрытой цели, ваша оценка будет достоверно отражать реальность.
Не, ну понятно, что психологические проблемы разные бывают. Говорить о продуктивности имеет смысл только после того, как все психологические проблемы решены и вам ничего не мешает. Иначе разговор про систему типов превратится в перечисление тараканов.
У меня не ломается. Про какой именно интеллисенс вы говорите? В какой среде? На каком языке?
Так это же и будет означать субъективную продуктивность, разве нет?
До тех пор, пока у вас нет скрытой цели, ваша оценка будет достоверно отражать реальность.
А с питоном я на порядки менее продуктивен, чем с хаскелем
Не, ну понятно, что психологические проблемы разные бывают. Говорить о продуктивности имеет смысл только после того, как все психологические проблемы решены и вам ничего не мешает. Иначе разговор про систему типов превратится в перечисление тараканов.
Только интеллисенс, который пытается выводить типы, ломается даже на простейших примерах.
У меня не ломается. Про какой именно интеллисенс вы говорите? В какой среде? На каком языке?
НЛО прилетело и опубликовало эту надпись здесь
Про что и речь — я именно это и имел в виду, когда писал выше, что в дополнение к разработке системы типов придётся заниматься очень интересным трудом в виде аннотаций используемых библиотек (и не факт, что плодотворным — не все будут с радостью это мержить).
Если бы это реально влияло на продуктивность, все бы это делали с удовольствием.
Кажется, вы сами себе противоречите.
Возможно. В чем конкретно?
А это удобно — если результат эксперимента не такой, как вам нужно, можно просто объявить это психологическими проблемами!
Вы сами это написали.
PyCharm, полгода назад. На простейших случаях (которые я не воспроизведу, впрочем, ибо это было на работе, а личного кода на питоне у меня нет).
Мда. После ваших саркастичных комментариев о том что я сам себе противоречу и выдаю желаемое за действительное я ожидал что вы придерживаетесь столь же высоких стандартов дискуссии, каких требуете от меня. Разочарован.
НЛО прилетело и опубликовало эту надпись здесь
Для любой практики можно найти людей, которые ей не следуют. Означает ли это, что ничего не влияет на продуктивность? Но это так, если говорить о метауровне.
Я не говорил, что ничего. Я писал о том, что если бы роль системы типов была бы так велика, такие языки, как Python, Lua, PHP, JavaScript или не были бы столь популярны или быстро бы обзавелись системами типов.
Если говорить о прямом уровне рассуждений, то иногда важна не продуктивность, а время до первого запуска программы (потому что тогда можно закрыть тикет в джире, и пофиг, что там потом будет), например.
Странная логика. После закрытия тикета продукт разворачивается у клиента, который вообще-то платит за это деньги. Вы на эти деньги живете, помогаете родителям, оплачиваете «развивашки» детям. Это не пофиг.
Когда сначала говорите о субъективности опыта, а потом о том, что для сравнения продуктивности достаточно собственного опыта.
Мы не на научном симпозиуме. Я разговариваю с вами лично и мое предложение направлено на то, чтобы вы лично получили опыт, на который я ссылаюсь.
Я изначально написал, что с питоном менее продуктивен. Про психологические проблемы и что-то ещё говорить начали таки вы.
Возможно я ошибся. Судил по себе.
Я всего лишь делюсь собственным опытом, как вы и просили. А опыт — ну, какой есть, не понимаю, чем он вам не нравится.
Все нравится.
НЛО прилетело и опубликовало эту надпись здесь
Ну у JS до поры до времени не было толком альтернатив, да и там сейчас есть всякие навёрнутые сверху системы типов. Python популярен как клей, да и там есть mypy. PHP популярен на серверах с начала нулевых, когда ничего другого на сервера толком не поставишь, и там тоже вроде что-то впиливают.
То что не было альтернатив роли не играет. Программисты решили бы проблему имеющимися средствами. Тот факт, что все эти языки до сих пор счастливо живут без систем типов говорит о том, что не так уж система типов и нужна.
Писать на всём этом крупные системы — нуу, по факту, кажется, этого не происходит.
На всех этих языках написаны системы самой разной степени крупности. В гугле Python один из трех основных языков. На JavaScript-е и PHP практически весь веб написан. Включая хабр, вот. Хабр — достаточно крупная система?
Или выкидывается, если это полуресёрч. Или не доходит до продакшена, если это крупная компания, которая может позволить себе быть неэффективной. Или клиент мирится с багами и доработками, если продукт на рынке такой один.
Мда. Вы, видимо, в спор втянулись только ради спора.
Ну вот и получается такой опыт, что под вещами больше чем на сотню строк на питоне я как-то тону.
И в этом, конечно, питон виноват.
НЛО прилетело и опубликовало эту надпись здесь
То есть, факт наличия 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 строки для запуска пары готовых программ — да, удобно и быстро пишется на баше. Большой проект — лучше разрабатывать почти на чём угодно другом. Поэтому ваш довод
далёк от реальности.
Тот факт, что для вспомогательных скриптов используется язык без типизации однозначно говорит, что типизация не увеличивает продуктивность.
далёк от реальности.
Вы так пишете, что не даете мне возможности как-то оспорить ваше утверждение. Возможно далек, возможно не далек. В той формулировке, что вы выбрали ваше утверждение невозможно осмыслить критически.
Я не утверждаю, что надо все бросить и пойти писать на баше. Я лишь утверждаю, что вопрос о том, что типизация увеличивает продуктивность — открыт.
Я не утверждаю, что надо все бросить и пойти писать на баше. Я лишь утверждаю, что вопрос о том, что типизация увеличивает продуктивность — открыт.
Я лишь утверждаю, что вопрос о том, что типизация увеличивает продуктивность — открыт.
Открыт или закрыт — не важно. Я указал, что ваш довод
Тот факт, что для вспомогательных скриптов используется язык без типизации однозначно говорит, что типизация не увеличивает продуктивность.
неактуален: из такой же логики следует, что баш удобен для разработки софта.
из такой же логики следует, что баш удобен для разработки софта
Я не понял, как из «типизация не увеличивает продуктивность» у вас получилось «баш удобен для разработки софта». Возможно, баш не удобен для разработки софта по тысяче разных причин, кроме отсутствия в нем системы типов.
Открыт или закрыт — не важно
На мой взгляд, есть причины полагать, что многие программисты используют типизацию по причинам, не имеющим ничего общего с продуктивностью.
Вы пишете:
На самом же деле из того, что «язык без типизации» (баш) «используется для вспомогательных скриптов», никак не следует, что «типизация не увеличивает продуктивность». А уж тем более «однозначно».
Тот факт, что для вспомогательных скриптов используется язык без типизации однозначно говорит, что типизация не увеличивает продуктивность.
На самом же деле из того, что «язык без типизации» (баш) «используется для вспомогательных скриптов», никак не следует, что «типизация не увеличивает продуктивность». А уж тем более «однозначно».
Ну так если бы типизация увеличивала продуктивность, никто бы не писал вспомогательные скрипты на баше. Все бы писали их на, не знаю, хаскелле, например.
И даже если вы скажете, что «хаскель нужно ставить, а баш доступен сразу», то почему тогда в баш за годы его развития не добавили систему типов?
И даже если ответ будет «потому что авторы баша в коматозе и не развивают его», почему тогда в дистрибутивы вставляют питон, но не вставляют хаскель?
И даже если вы скажете, что «хаскель нужно ставить, а баш доступен сразу», то почему тогда в баш за годы его развития не добавили систему типов?
И даже если ответ будет «потому что авторы баша в коматозе и не развивают его», почему тогда в дистрибутивы вставляют питон, но не вставляют хаскель?
Ровно по такой же логике структуры, объекты и многое другое не увеличивают продуктивность: их ведь в баше нет, а на баше пишут скрипты. С этим утверждением вы, получается, тоже согласны?
Противоречие, которое вы нашли — кажущееся, от того, что я позволил себе пренебречь церемониями, сократить время. Вы воспользовались этим сокращением, чтобы «загнать меня в ловушку». Это примерно то же самое, что говорить что А. С. Пушкин — не обязательно Александр, это может быть и Андрей.
То что вы вообще в принципе такие приемы применяете говорит о том, что вы лишь играете в логику.
То что вы вообще в принципе такие приемы применяете говорит о том, что вы лишь играете в логику.
НЛО прилетело и опубликовало эту надпись здесь
А как вы разделяете одно доказательство от другого?
Свидетельство. Я вообще не считаю, что в таком сложном вопросе можно найти строгое доказательство.
Или у вас на любой аргумент есть контр-аргумент, утверждающий, что аргумент на самом деле не о преимуществах системы типов, а о чём-то другом?
Да, я стараюсь рассматривать множество альтернативных вариантов.
А что до программистов — ну, кто-то и на современные языки переходить не хочет, предпочитая писать на коболе каком-нибудь, или на C++03.
В том-то и дело, что речь идет не о ком-то, а о массах программистов. Сотнях и, возможно, тысячах. Вы не можете их просто так сбросить со счетов.
Однако даже он даёт больше статических гарантий, чем питон.
Ну, я бы не сказал что это прям плюс. Кому-то уже писал, что я действительно считаю систему типов неоценимой подмогой во время обучения программированию. Но зачем она зрелому программисту — вопрос открыт.
Разработчикам на плюсах только об этом не говорите. Не поймут-с.
Вроде об этом Фаулер писал. Так что все в курсе.
Вы, кажется, перепутали большие компании с бодишопом. Как думаете, какая текучка на проектах типа LLVM или V8?
Это комьюнити проекты, там картина другая. Любой проект, когда выходит в паблик — это успешный проект. Мы вообще ничего не знаем о внутренних, а их там сотни.
А, ну если у меня текучки нет, то я-то бесконечно внимательный и помню каждую строку кода, которую писал 5 лет назад.
Не каждую, разумеется. Сегодня спагетти-код считается моветом и программы структурируются довольно крупными блоками: функция, класс, модуль. Это вы и я вспомним и через 5 и через 10 лет.
Каким?
Медленно.
Компилятор хаскеля вон на хаскеле написан, компилятор первого идриса — на хаскеле, компилятор агды — на хаскеле, компилятор всяких MLей — на MLях, хотя эти языки далеко не всегда топ в производительности.
Это тут вообще роли не играет. Все перечисленные языки выполняются на виртуальной машине.
Нет. Опыт перехода на более строгие языки у меня есть, когда становилось как раз более непривычно, и я могу с этим опытом сравнить.
Ну, понятно. У меня тоже был период, когда я боялся к крупным проектам подходить. Ничего, период прошел, теперь все норм.
Это тут вообще роли не играет. Все перечисленные языки выполняются на виртуальной машине.
Вообще-то Haskell компилируется в нативный код.
AnthonyMikh Haskell не был перечислен.
Кроме того, я не знаю, как именно он компилируется. Может быть, он не использует все оптимальные процессорные инструкции.
Кроме того, я не знаю, как именно он компилируется. Может быть, он не использует все оптимальные процессорные инструкции.
НЛО прилетело и опубликовало эту надпись здесь
Что-то я не понял что конкретно он запрещает. Берем JavaScript. Добавляем в него flow на уровне V8, пишем пропозал, пропозал принимают. Что там Райс запрещает я не понимаю.
Вот блин для динамического языка зачем-то написали аж две популярные системы типов flow и typescript. Действительно, типизация не нужна
Если бы ваши слова были правдой, то программисты сделали бы динамические проверки типов в языках без типизации. Но практика показывает, что программисты вообще никак не защищаются и ничего не делают ради этого.
Разве что не пишут на языках без типизации? =)
Пишут. Одни из самых популярных языков в мире — JavaScript, PHP и Python.
НЛО прилетело и опубликовало эту надпись здесь
Конечно. Если бы статическая типизация была такой полезной, как ее малюют, программисты быстро бы расширили эти языки системой типов.
Более того, у нас есть кейсы с TypeScript и flow, и есть доклад, где прямо говорится, что для них статическая типизация практически не играет роли. (Небольшой эффект наблюдается при рефакторинге, но мы все прекрасно знаем, что рефакторинг — развлекаловка разработчика, ценности он не несет).
Более того, у нас есть кейсы с TypeScript и flow, и есть доклад, где прямо говорится, что для них статическая типизация практически не играет роли. (Небольшой эффект наблюдается при рефакторинге, но мы все прекрасно знаем, что рефакторинг — развлекаловка разработчика, ценности он не несет).
Но количество багов, которые найдены на тестировании зависит только от программиста.
Не согласен. В достаточно выразительных языках можно получить гарантии, которые попросту невыразимы на более простых языках: раз, два. Да, язык не даёт автоматически ошибкоустойчивый дизайн, но если язык не позволяет сделать подобный дизайн, то он вам в этом смысле не поможет, какой бы крутой разработчик у вас бы не был.
НЛО прилетело и опубликовало эту надпись здесь
Ну так а зачем вам гарантии от самого себя? Когда вы из файла или из базы читаете бяку, типизация вам вообще никак не поможет.
Типизация сильно помогает обучению, это правда и чем она строже, тем лучше. Но после того как вы научились программировать, типизация уже практически не влияет. Расставлять типы и думать об отказоустойчивом дизайне в современной парадигме просто невозможно — в любой момент концепция может поменяться и весь ваш дизайн придется с нуля переделывать.
Типизация сильно помогает обучению, это правда и чем она строже, тем лучше. Но после того как вы научились программировать, типизация уже практически не влияет. Расставлять типы и думать об отказоустойчивом дизайне в современной парадигме просто невозможно — в любой момент концепция может поменяться и весь ваш дизайн придется с нуля переделывать.
НЛО прилетело и опубликовало эту надпись здесь
Как? Допустим прочитали вы файл в строку. Что-то я не знаю такой системы типов, которая могла бы такие случаи анализировать.
Как вы это поняли? Вы переписываете модуль и у вас нет ошибок компиляции? Ну так может вы просто хороший программист?
Наверное, я занимаюсь чем-то не тем, но типизация очень помогает и тут. Особенно когда дизайн переделывается не с нуля, а с сохранением каких-то уже написанных кусков кода.
Как вы это поняли? Вы переписываете модуль и у вас нет ошибок компиляции? Ну так может вы просто хороший программист?
НЛО прилетело и опубликовало эту надпись здесь
Что вы хотите провалидировать?
Я хочу, чтобы компилятор с помощью системы типов сказал мне что будет ай-ай-ай.
Переписываю модуль, и после того, как я поборол все ошибки тайпчекера, все интеграционные тесты зелёные сразу.
Ну практически вы говорите что полезно иметь реестр дефектов. И хорошо бы чтобы дефекты выявлялись автоматически. Спорить с этим бессмысленно, я полностью согласен с этими утверждением, но почему вы приписываете достижения статического анализатора системе типов?
НЛО прилетело и опубликовало эту надпись здесь
Ай-ай-ай какого рода-то?
Что в файле бяка написана.
Какой реестр дефектов? Причём тут он?
Вы используете то что выдает вам тайпчекер как чеклист. В этом чеклисте нет ничего, кроме дефектов. Следовательно, выдача тайпчекера функционально эквивалентна реестру дефектов. Я тоже так делаю, можно считать эту практику условно хорошей.
Потому что система типов — это наиболее выраженный и прокачанный случай статического анализа.
Наоборот же, вырожденный случай. Например, статический анализ может сказать вам, что на ноль делить нельзя, а вот с точки зрения системы типов
int / int → float. Также, система типов не поведет бровью, если вы попытаетесь удалить из БД уже отсутствующий в ней объект.НЛО прилетело и опубликовало эту надпись здесь
Если у вас все функции требуют доказательство того, что им пришла не бяка, то компилятор проверит, что вы это доказательство производите (то есть, что вы делаете все нужные проверки).
Как он это проверит? Откуда он что-то знает про формат файла?
Всё, эту функцию нельзя вызывать, если нет свидетельства того, что делитель ненулевой.
То есть, ваше решение — делать двойную работу: вначале расставлять типы так, чтобы компилятор вам надавал по рукам, а потом все равно делать рантайм-проверки. Вам не кажется это слегка шизофреничным? То что вы знаете что такой тип нужно поставить однозначно говорит о том, что вы не забудете вставить и рантайм-проверку. Но если у вас и так есть рантайм-проверка, нет необходимости дополнительно выражать это в типе.
А как тут статический анализ поможет? Это внешний ресурс с не пойми как специфицируемым поведением (что тоже можно типизировать, но смысла в этом мало ввиду того, что БД — разделяемый ресурс, и туда между делом может написать кто-нибудь ещё).
Про статический анализ было в контексте того, что преимущества, которые вы приписываете системе типов на самом деле относятся к статическому анализу. И, да, система типов, анализ которой возможен статически — хорошее дело.
Но система типов не решает проблем, которые реально возникают при разработке. В этом мой поинт: система типов создает лишь иллюзию безопасности, оставляя реальные проблемы актуальными.
При этом я не говорю и о том, что система типов не нужна. Лишь о том, что ее влияние на продуктивность под большиииим вопросом.
НЛО прилетело и опубликовало эту надпись здесь
Он потребует у меня это проверить.
А откуда он это узнает? Ну, допустим, я пишу парсер JSON-а. Как система типов заставит меня проверить баланс скобочек?
Конечно, если вы бесконечно внимательны 100% времени и никогда не делаете ошибок, то вам это всё не нужно. Но я не такой.
Ясно. Рад, что система типов вам помогает. Но, простите, это разговор уже не о продуктивности.
НЛО прилетело и опубликовало эту надпись здесь
Потому что в сигнатуре функции это написано, например?
Ну, я так понял, что я должен сделать иерархию наследования File → JSONFile → SyntacticallyCorrectJSONFile, а потом использовать в своем коде только указатели на SyntacticallyCorrectJSONFile. Но это же смешно. Если я допустил ошибку в определении корректности синтаксиса, система типов мне радостно отрапортует что все безопасно, хотя по факту безопасностью там и не пахло.
Парсер жсона — вообще нетривиальная задача, потому что JSON — нетривиальный формат, ну да ладно. Только зачем там проверять баланс скобочек?
Да не принципиально какой формат, что в голову пришло. Придумайте сами пример, который можно решить именно с помощью системы типов в контексте получения внешних данных.
Мой прогноз, что у вас это не получится и это докажет мое утверждение, что система типов не работает на действительно актуальных проблемах.
А к чему относится помощь инструментов при разработке, если не к продуктивности?
Ну, смотрите. Есть два человека. Предположим, что один пишет код со скоростью 10 поинтов в итерацию, а другой со скоростью 5 поинтов в итерацию. Мы можем дать второму систему типов и он начнет писать код со скоростью 7 поинтов за итерацию.
Это неплохо, но, может ему стоит посоветовать для начала подкачать свои навыки до тех пор, пока он не достигнет производительности в 10 поинтов, прежде, чем искать внешние инструменты? Может быть, с точки зрения 10 поинтов актуальные проблемы будут уже другими?
НЛО прилетело и опубликовало эту надпись здесь
если вам нужно доказательство наличия ключа. И так далее.
Мне нужно чтобы система типов мне гарантировала, что в файле не будет бяки.
Для этого вам её надо допустить везде, во всей программе, если упрощать. Практика показывает, что это сделать сложно.
Поясните.
Можно начать с «прочитать из сокета данные, где в первых четырёх байтах длина, а в следующих — содержимое, со статическими гарантиями невыхода за границы массива и обработки плохих случаев». Продолжить можно с «подключиться к БД, достать схему и проверить, что все запросы соответствуют этой схеме».
Хорошие примеры. Теперь покажите, как это решается с помощью системы типов.
Ну вот вы уже измеряете производительность в терминах каких-то абстрактных поинтов за итерацию. А потом удивляетесь, когда я рассказываю вам про погоню за поинтами вместо пользовательского счастья в командах разработки.
Понятно, что пока вы не можете удовлетворить пользователя, нет смысла говорить о производительности.
Ну так я к ровно тому и подвожу, что пока у вас пользователь несчастлив, пока вы его удовлетворяете не достаточно быстро, нет смысла и говорить о корректности программы с точки зрения типов. Тем более, что система типов вообще никак не решает те проблемы, которые реально доставляют пользователю боль.
Расставлять типы и думать об отказоустойчивом дизайне в современной парадигме просто невозможно — в любой момент концепция может поменяться и весь ваш дизайн придется с нуля переделывать.
В динамически типизированном языке точно также придётся переделывать, только при это у вас не будет компилятора, который подскажет, где изменения забыли внести.
Расставлять типы и думать об отказоустойчивом дизайне в современной парадигме просто невозможно
Не затруднит ли вас привести конкретный пример с динамический типизацией, которая позволит вам менять дизайн быстрее, чем со статической?
Мой аргумент не в защиту динамической типизации, как единственной альтернативе статической. Мой аргумент про то, что типизация оказывает разве что психологический эффект.
Я вообще не считаю, что сама концепция тип объекта хоть сколько-то продуктивна. В реальной жизни объект проявляет себя только во взаимодействии с другими объектами, у него нет и не может быть универсальных черт, истинных с любой точки зрения. Концепт трейта мне видится более жизнеспособным.
А те задачи, которые сейчас выполняет типизация на уровне языка имеет больше смысла производить на уровне IDE: в реальном времени подсказывать программисту доступные возможности, ограничения, документацию, примеры использования, ограничения параметров и все остальное.
Я вообще не считаю, что сама концепция тип объекта хоть сколько-то продуктивна. В реальной жизни объект проявляет себя только во взаимодействии с другими объектами, у него нет и не может быть универсальных черт, истинных с любой точки зрения. Концепт трейта мне видится более жизнеспособным.
А те задачи, которые сейчас выполняет типизация на уровне языка имеет больше смысла производить на уровне IDE: в реальном времени подсказывать программисту доступные возможности, ограничения, документацию, примеры использования, ограничения параметров и все остальное.
Я вообще не считаю, что сама концепция тип объекта хоть сколько-то продуктивна. [...] Концепт трейта мне видится более жизнеспособным.
Вы так пишете, как будто трейты — не статическая типизация.
А те задачи, которые сейчас выполняет типизация на уровне языка имеет больше смысла производить на уровне IDE
Чтобы IDE могла чего-то там подсказывать, надо чтобы кто-то описал статические типы, пусть даже в документации.
Программист пишет больше или меньше кода, и баги допускает тоже программист.
С одной стороны соглашусь, но в целом логика опасная. Если язык позволяет мне на этапе компиляции увидеть, что я забыл обработать null ref — при прочих равных этот язык лучше. Можно заставить программиста по несколько раз пересматривать свой код, городить стены тестов, но зачем?
Напомнило, как у нас были проблемы с внесением изменений в один конкретный сервис, в котором архитектура отличалась от остальных. Авторы сервиса в ответ предложили «просто писать без багов». Спасибо, но лучше я буду считать себя глупым и невнимательным разработчиком и напишу так, чтобы потом поддерживать было легче.
Подобными качествами обладают и другие функциональные языки, и выбор в пользу F# тут совсем не очевиден. Начиная с того, что он тащит с собой рантайм со сборщиком мусора и проверкой типов, который в функциональном языке особо-то и не нужен, заканчивая тем, что все библиотеки/фреймворки в .Net пишутся в первую очередь под C#.
Начиная с того, что он тащит с собой рантайм со сборщиком мусора и проверкой типов, который в функциональном языке особо-то и не нужен,
Можете раскрыть мысль?
По моим ощущениям необходимость типизации зависит скорее от объема проекта, а сборщик мусора вообще ортоганален понятиям ООП vs функциональщина, зависит от задач.
Я говорил не про типизацию как таковую, а про то, что все проверки типов можно было бы полностью выполнить на этапе компиляции.
С ограничением мутабельности становится возможным отследить моменты, когда выделенная память может быть освобождена и освобождать ее сразу же, делая выполнение программы более предсказуемым (без внезапных остановок на сбор мусора).
НЛО прилетело и опубликовало эту надпись здесь
Можно писать на F# и для js, фронт и бэк.
Ключевые слова Fable + F#
НЛО прилетело и опубликовало эту надпись здесь
А я всегда говорил, что программистский жаргон — это искажённый тюремный. Вышел пацан из маргинализированной зоны, нигде не получалось находить работу.
Я понимаю, что все это спорная вещь, и люди будут говорить — да ну нахер ваш F#. Можно по разному относиться, но один хороший F# разработчик реально может заменить двух средних сишарперов.
Большую роль для бизнеса играет заменяемость программистов — т.е. возможность в удовлетворительные сроки найти нового программиста.
С редкими же языками, работодатель становится заложником программиста — замену найти ему он не сможет (в адекватные сроки). В такой ситуации хорошо только программисту.
Если у тебя есть поле для экспериментов, например совсем свежий стартап, то можно взять неплохих сишарперов, научить их F#.
Не все согласятся.
Впрочем, это не отменяет того, что новые, более лучшие языки нужно пытаться создавать (как говорится — если не пробовать, то и не получится), и пропагандировать.
В сообществе более тысячи программистов сидят, заменяемость есть.
Не все согласятся.
Не все согласятся писать и на С#, тут дело больше в инерционности мышления. + Пару лет назад F# был most loved по опросам Stackoverflow.
Кроме этого в сообществе сплошь и рядом примеры того как сишарперов берут на проект и они через две недели пишут в прод на F#, синтаксис не так важен, если вы не меняете платформу, а она остаётся .net.
один хороший F# разработчик реально может заменить двух средних сишарперов
более того, любой хороший X разработчик реально может заменить двух средних Х кодеров :)
в F# по умолчанию не может быть null рефов
Ну это развод лохов. F# может оперировать любыми объектами .Net, которые вполне могут быть null. Обычные строки, например, или массивы. Но по на самом то деле проблемы null dereference нет в том виде, как её преподносят адепты фп — первый же прогон интеграционных тестов даёт эксепшон, и null dereference мгновенно фиксится по стектрейсу
А вот тайп-суммы — полезная штука. Но конечно не настолько полезная, чтобы переходить из-за неё с топового языка на язык с хреновым IntelliSense и отсутствием фреймворков.
С другой стороны, есть задачи для которых ни фреймворки, ни зависимость от внешних C# либ не нужны. Парсинг например — вот тут F# на высоте, есть весьма удобная либа для парсер-комбинаторов. Или например сложные билинговые расчёты. В общем F# годен там, где чистая математика — вот там пригодится улучшенный вывод типов и тайп-суммы
Той же жертвой, например, пал Rust — все говорят, это язык для системой разработки, хотя на нем очень хорошо писать веб-приложения и бэкенды.
Сейчас все-таки ситуация меняется.
Есть еще F*, но я никогда е слышал что бы его кто-то использовал.
fstar-lang.org
Есть ли у вас комментарии по поводу этого языка?
fstar-lang.org
Есть ли у вас комментарии по поводу этого языка?
F# или scala? Или они не сравнимы?
По некоторым параметрам можно сравнить.
F# — .net, Scala — Java
Оба имеют поддержку ООП и ФП.
F# — ML-подобный синтаксис, Scala — с-подобный, хотя в третьей скале он стал ближе к ml-подобному.
Сообщество — скалисты часто угорают по тайпастронавтике(не все, но мода, математическом смысле, такая), F# сообщество топит за прагматичность, включая создателя языка, например у него есть чудесная статья "why OO matters" где описывается плюс подхода смешения двух парадигм. Как и ООП так и ФП головного мозга выливаются в неудобства использования, поэтому и наблюдаем смешение парадигм в мейнстримовых языках
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Основатель F# сообщества: «ООП и ФП головного мозга должны умереть»// Мы обречены #7