И как я для float-ов это докажу за приемлемое время? Тут вон ребята из Gaulois для градиентного спуска в самой примитивной его форме доказательство писали 2 года вдесятером. Да и то, все реальные вычисления у них были на C++ и просто покрыты аксиомами (при чём, для Real, а не для Float), а не доказательствами корректности. И на плохих данных, там легко возникнут бесконечности.
Потом вопрос: кто мне будет платить эти 2 года? Даже если и будут платить, конкуренты получат результаты гораздо быстрее, доказывая корректность на бумажке и отлаживаясь на реальных данных.
Это неприемлемые издержки, по крайней мере, в моей области деятельности. Проще и продуктивнее работать в языке с нормальной поддержкой аппаратных исключений.
Про TypeScript - это частный случай. Сам JS задизайнен странным образом, не самым удачным. Но даже в таком случае TS помогает выловить лишь 15% ошибок - это не сокращение времени отладки прямо в разы. А процесс разработки затягивается далеко не на 15%. Я сравнивал для себя время решения одинаковых задач на Scheme и Haskell.
К слову, о последнем: а что, сейчас у нас много Haskell-программистов, которые быстрее решают задачи за меньшую зарплату? Я вот, например, зная, насколько процесс программирования на Haskell выматывающий, тоже бы брал за это +50% к своим обычным запросам.
Да бросьте. Медийное давление, создаваемое Rust-сообществом просто беспрецедентно. С Go даже близко такого нет. Даже с Haskell в своё время такого не было. Куда ни глянь - везде только Rust и обсуждают. Ну, или другие языки в контексте того, насколько они хуже Rust. В каналах языковых телеграмма тоже сплошной Rust. Фанаты крайне активны.
Мне, конечно, до авторов Go далеко, но, вот, всё же, зря они пошли на поводу у сообщества. Добавили бы лучше generic functions. И синтаксис такой бы вписался бы лучше в язык, и по выразительности они достаточны, и по производительности хуже не были бы, учитывая текущую реализацию generic-ов.
Зачем гоферу сутки изобретать велосипед? Чай не во времена телетайпов живём. Взял готовую реализацию, подправил в ней что-то под себя, и вперёд. Ну, не 5 минут займёт, а 15. Зато потом можно будет алгоритм под свои задачи подстраивать, параметризовать каким хитрым образом. У generic-библиотек существенный недостаток: железобетонный интерфейс, который не так часто достаточен, как хотелось бы. Приходится изловчаться разными методами. Просто сложность в другое место переезжает, вот и всё.
На C++ и на Haskell я пописал достаточно долго, чтобы испытать облегчение от перехода на Go, а потом и вообще на Lisp, именно по той причине, что выражать свои задумки на них гораздо проще.
Странный критерий, на Python продуктивность явно выше, но удобнее его в долгосрочной перспективе это не делает. Тут скорее речь о том насколько удобно код будет поддерживать и если мы говорим о Go, то это просто ассемблер от мира современной разработки.
Продуктивность подразумевает сохранение удобства и скорости разработки в долгосрочной перспективе. И этот критерий первостепенный в условиях свободного рынка. Пока один пишет "правильный" код на сложном языке, забивая, кстати, себе голову ещё и сложностями этого языка, меньше оставляя нейронов для работы с самой решаемой задачей, другой возьмёт язык попроще, напишет "неправильный", более функциональный код быстрее, и раньше запустит свою экосистему, эффективнее сможет её модифицировать. Selectel недавно рассказывал, почему они с Haskell перешли на Go.
Необоснованная критика. Зачем тогда в Go используются фигурные скобки? Это же все от лукавого. Мой тейк в том, что системы типов и удобный синтаксис упрощают, ускоряют и делают разработку более надежной, что неоднократно подтверждается с выходом новых языков. Например Kotlin, который как Java, только лучше.
В чём отличие Вашего заявления от следующего? "Земля плоская, потому что регулярно выпускаются книги и проводятся конференции, утверждающие, что она плоская."
Единственное мне известное действительно научное исследование влияние ЯП на качество кода не выявило никакого существенного влияния ни типов, ни синтаксиса, ни наличия nil на качество. Единственное, что, возможно, слегка влияет положительно - это иммутабельность и поддержка замыканий.
Программисты вынуждены работать с тем, что есть, а не с тем, что объективно повышает их продуктивность. Разработчики же языков вынуждены следовать модным трендам в языкостроении, чтобы не выглядеть отщепенцами. Но эти тренды - прикладная теология, в основном. За ними нет ничего экспериментально проверяемого, за ними только рассуждения, авторитеты и личные переживания да убеждения.
В программировании такие ситуации сводятся к "забыл что-то проверить и обратился к нулю" (потому что в противном случае проблемы можно предсказать и сообщить о них - как в ошибке деления на ноль).
Не сводятся, у вас легко может окружение поменяться (сдох диск, например), и до проверки дело может просто не дойти. Кроме того, даже с проверкой на ноль не всё так просто. Проверки могут потребовать львиной доли производительности, в зависимости от алгоритма. И выбрасывание исключения может быть гораздо, гораздо более эффективной реализацией алгоритма. А ещё есть всякие переполнения, бесконечности, потеря точности и т.д. и т.п., что тривиально реализуется в железе (если процессор поддерживает прерывания), но весьма неэффективно при ручных проверках.
Если это однократное вложение затягивается на годы, как с Haskell, например, в силу особенностей экосистемы, то стоит ли оно того? Rust или C++ тоже простыми языками не назовёшь. Кроме того, важна метрика: время до запуска бажного MVP. Потому что баги бывают не только в коде, типах и указателях, но и в самой идее, в организации интерфейса, etc.
А дальше берём одну и ту же задачу, и смотрим, как она на разных языках решается, и с какой скоростью.
Вот так всё просто, на самом деле. Только почему-то народ предпочитает витать в абстрактных рассуждениях о тех или иных схоластических тонкостях.
Ну в самом деле, если знаете, как сделать правильный язык, - делайте, да пишите на нём. Критерием того, что язык правильный, является его высокая продуктивность. Если вы сделаете правильный язык, то с небольшой компанией единомышленников сможете на нём написать что-нибудь интересное, и народ потянется. Керниган и Ричи смогли даже на отстойном по мнению многих Си, и вы сможете. Экосистема языка запустится и начнёт жить. Вот и всё. Остальное - религиозные войны. Что теория типов, что особенности синтаксиса, что пресловутый nil и т.д. Пока религия не подтверждена практикой - это пустая болтовня, какой бы красивой и логичной она ни была бы.
О nil. Как разница, от чего программа ведёт себя некорректно: от того, что по nil к памяти обратились, или от того, что не те два числа сложили, или от того, что в select забыли сокет передать? Это просто ошибки, которые бывают. Почему особое вниманием именно nil? Программы по другим причинам не вываливаются с исключениями? Взять тот же Rust, в котором нет проблем с nil. В программах на Rust повсеместно понатыканы unwrap: что-то пошло по непредусмотренному пути, программа вылетает. И? Давайте теперь изобретать язык, в котором unwrap невозможен? А что делать тогда с ситуациями, когда у программы нет информации для обработки возникшей ситуации? Просто выход с exit(code != 0)? Ну, ok, но чем это будет отличаться по сути от вываливания с исключением, если просто логика программы неверная?
Просто по опыту, при программировании на Си ошибки в типах - не самые часто встречающиеся ошибки. Как и при программировании на языке с более сложной системой тимпов, основные ошибки алгоритмические. А от этого никакая система типов не спасёт.
Там не классы эмулируют, а интерфейсы. А для этого C++ - overkill. C++ сложный язык, создающий зависимость от разработчиков компиляторов для C++, от комитета стандартизации C++ и от многолетней учёбы, необходимой для освоения C++ и от прочих слциальных институтов. Linux, он, как бы, не про это, а про индивидуальную свободу и независимость. Сносный компилятор C можно написать с нуля в одиночку за приемлемое время и раскрутить на этом компиляторе GNU/Linux. Написание компилятора C++ современного стандарта - это отдельное приключение длинною в десятилетие.
Вообще-то, есть метод верификации: пишется несколько разных кодов с разными методами рассчёта, или хотя бы рассчётов на разных сетках (можно даже рандомизировать немного), а потом результаты сравниваются.
Тут, видимо, просто поменяли метод вычислений, но "кросс-валидацию" не провели. Это, всё же, серьёзный недочёт в работае.
Ну, а про турбулентные потоки - это уже, конечно, только "сын ошибок трудных" мог показать.
Это вполне HF. Во-первых, есть специальные сборщики с низкими задержками. Во-вторых, в HFT работа ведётся с несколькими постоянно живыми массивами историй. Работа, в основном, арифметическая, объектов в куче почти нет, нагрузка на GC низкая. Поэтому даже Clojure достаточно быстр для торговли с частотой 1ms при обработке нескольких сотен тысяч записей в истории. Был доклад на Clojure Conj несколько лет назад об этом.
И как я для float-ов это докажу за приемлемое время? Тут вон ребята из Gaulois для градиентного спуска в самой примитивной его форме доказательство писали 2 года вдесятером. Да и то, все реальные вычисления у них были на C++ и просто покрыты аксиомами (при чём, для Real, а не для Float), а не доказательствами корректности. И на плохих данных, там легко возникнут бесконечности.
Потом вопрос: кто мне будет платить эти 2 года? Даже если и будут платить, конкуренты получат результаты гораздо быстрее, доказывая корректность на бумажке и отлаживаясь на реальных данных.
Это неприемлемые издержки, по крайней мере, в моей области деятельности. Проще и продуктивнее работать в языке с нормальной поддержкой аппаратных исключений.
Про TypeScript - это частный случай. Сам JS задизайнен странным образом, не самым удачным. Но даже в таком случае TS помогает выловить лишь 15% ошибок - это не сокращение времени отладки прямо в разы. А процесс разработки затягивается далеко не на 15%. Я сравнивал для себя время решения одинаковых задач на Scheme и Haskell.
К слову, о последнем: а что, сейчас у нас много Haskell-программистов, которые быстрее решают задачи за меньшую зарплату? Я вот, например, зная, насколько процесс программирования на Haskell выматывающий, тоже бы брал за это +50% к своим обычным запросам.
Я не шибко великий специалист по Go, но мне кажется, реализация там чрезмерно усложнённая. Я бы проще написал.
Да бросьте. Медийное давление, создаваемое Rust-сообществом просто беспрецедентно. С Go даже близко такого нет. Даже с Haskell в своё время такого не было. Куда ни глянь - везде только Rust и обсуждают. Ну, или другие языки в контексте того, насколько они хуже Rust. В каналах языковых телеграмма тоже сплошной Rust. Фанаты крайне активны.
Мне, конечно, до авторов Go далеко, но, вот, всё же, зря они пошли на поводу у сообщества. Добавили бы лучше generic functions. И синтаксис такой бы вписался бы лучше в язык, и по выразительности они достаточны, и по производительности хуже не были бы, учитывая текущую реализацию generic-ов.
Есть uTCP. Туда вообще умельцы много чего помещают. Например, виртуальную lisp-машину с реализацией http-сервера поверх неё.
Зачем гоферу сутки изобретать велосипед? Чай не во времена телетайпов живём. Взял готовую реализацию, подправил в ней что-то под себя, и вперёд. Ну, не 5 минут займёт, а 15. Зато потом можно будет алгоритм под свои задачи подстраивать, параметризовать каким хитрым образом. У generic-библиотек существенный недостаток: железобетонный интерфейс, который не так часто достаточен, как хотелось бы. Приходится изловчаться разными методами. Просто сложность в другое место переезжает, вот и всё.
На C++ и на Haskell я пописал достаточно долго, чтобы испытать облегчение от перехода на Go, а потом и вообще на Lisp, именно по той причине, что выражать свои задумки на них гораздо проще.
А в чём проблема? Пишете return, join, и вперёд. Руководств по монадам на Go предостаточно.
Продуктивность подразумевает сохранение удобства и скорости разработки в долгосрочной перспективе. И этот критерий первостепенный в условиях свободного рынка. Пока один пишет "правильный" код на сложном языке, забивая, кстати, себе голову ещё и сложностями этого языка, меньше оставляя нейронов для работы с самой решаемой задачей, другой возьмёт язык попроще, напишет "неправильный", более функциональный код быстрее, и раньше запустит свою экосистему, эффективнее сможет её модифицировать. Selectel недавно рассказывал, почему они с Haskell перешли на Go.
В чём отличие Вашего заявления от следующего? "Земля плоская, потому что регулярно выпускаются книги и проводятся конференции, утверждающие, что она плоская."
Единственное мне известное действительно научное исследование влияние ЯП на качество кода не выявило никакого существенного влияния ни типов, ни синтаксиса, ни наличия nil на качество. Единственное, что, возможно, слегка влияет положительно - это иммутабельность и поддержка замыканий.
https://arxiv.org/abs/1901.10220
Программисты вынуждены работать с тем, что есть, а не с тем, что объективно повышает их продуктивность. Разработчики же языков вынуждены следовать модным трендам в языкостроении, чтобы не выглядеть отщепенцами. Но эти тренды - прикладная теология, в основном. За ними нет ничего экспериментально проверяемого, за ними только рассуждения, авторитеты и личные переживания да убеждения.
Не сводятся, у вас легко может окружение поменяться (сдох диск, например), и до проверки дело может просто не дойти. Кроме того, даже с проверкой на ноль не всё так просто. Проверки могут потребовать львиной доли производительности, в зависимости от алгоритма. И выбрасывание исключения может быть гораздо, гораздо более эффективной реализацией алгоритма. А ещё есть всякие переполнения, бесконечности, потеря точности и т.д. и т.п., что тривиально реализуется в железе (если процессор поддерживает прерывания), но весьма неэффективно при ручных проверках.
Да, хотелось бы понять, откуда такой вывод. Группировка языков очеь странная. Можете указать критерий, по которому группировались они?
Если это однократное вложение затягивается на годы, как с Haskell, например, в силу особенностей экосистемы, то стоит ли оно того? Rust или C++ тоже простыми языками не назовёшь. Кроме того, важна метрика: время до запуска бажного MVP. Потому что баги бывают не только в коде, типах и указателях, но и в самой идее, в организации интерфейса, etc.
А дальше берём одну и ту же задачу, и смотрим, как она на разных языках решается, и с какой скоростью.
Вот так всё просто, на самом деле. Только почему-то народ предпочитает витать в абстрактных рассуждениях о тех или иных схоластических тонкостях.
Вот Вы говорите "наиболее популярный и эффективный". А на какой статистике Вы основываете это утверждение?
Для языковых холивоинов должен быть отдельный ад.
Ну в самом деле, если знаете, как сделать правильный язык, - делайте, да пишите на нём. Критерием того, что язык правильный, является его высокая продуктивность. Если вы сделаете правильный язык, то с небольшой компанией единомышленников сможете на нём написать что-нибудь интересное, и народ потянется. Керниган и Ричи смогли даже на отстойном по мнению многих Си, и вы сможете. Экосистема языка запустится и начнёт жить. Вот и всё. Остальное - религиозные войны. Что теория типов, что особенности синтаксиса, что пресловутый nil и т.д. Пока религия не подтверждена практикой - это пустая болтовня, какой бы красивой и логичной она ни была бы.
О nil. Как разница, от чего программа ведёт себя некорректно: от того, что по nil к памяти обратились, или от того, что не те два числа сложили, или от того, что в select забыли сокет передать? Это просто ошибки, которые бывают. Почему особое вниманием именно nil? Программы по другим причинам не вываливаются с исключениями? Взять тот же Rust, в котором нет проблем с nil. В программах на Rust повсеместно понатыканы unwrap: что-то пошло по непредусмотренному пути, программа вылетает. И? Давайте теперь изобретать язык, в котором unwrap невозможен? А что делать тогда с ситуациями, когда у программы нет информации для обработки возникшей ситуации? Просто выход с exit(code != 0)? Ну, ok, но чем это будет отличаться по сути от вываливания с исключением, если просто логика программы неверная?
p.s. прошу прощения за грамматические ошибки
https://en.m.wikipedia.org/wiki/C2x - даже так. Но не факт, что это всё на пользу языку. Всё же, хотелось бы, чтобы KISS.
Я тут недавно специально сравнивал -- не компилируется. На Си, конечно, тоже надо уметь писать.
Просто по опыту, при программировании на Си ошибки в типах - не самые часто встречающиеся ошибки. Как и при программировании на языке с более сложной системой тимпов, основные ошибки алгоритмические. А от этого никакая система типов не спасёт.
Там не классы эмулируют, а интерфейсы. А для этого C++ - overkill. C++ сложный язык, создающий зависимость от разработчиков компиляторов для C++, от комитета стандартизации C++ и от многолетней учёбы, необходимой для освоения C++ и от прочих слциальных институтов. Linux, он, как бы, не про это, а про индивидуальную свободу и независимость. Сносный компилятор C можно написать с нуля в одиночку за приемлемое время и раскрутить на этом компиляторе GNU/Linux. Написание компилятора C++ современного стандарта - это отдельное приключение длинною в десятилетие.
Вообще-то, есть метод верификации: пишется несколько разных кодов с разными методами рассчёта, или хотя бы рассчётов на разных сетках (можно даже рандомизировать немного), а потом результаты сравниваются.
Тут, видимо, просто поменяли метод вычислений, но "кросс-валидацию" не провели. Это, всё же, серьёзный недочёт в работае.
Ну, а про турбулентные потоки - это уже, конечно, только "сын ошибок трудных" мог показать.
Это вполне HF. Во-первых, есть специальные сборщики с низкими задержками. Во-вторых, в HFT работа ведётся с несколькими постоянно живыми массивами историй. Работа, в основном, арифметическая, объектов в куче почти нет, нагрузка на GC низкая. Поэтому даже Clojure достаточно быстр для торговли с частотой 1ms при обработке нескольких сотен тысяч записей в истории. Был доклад на Clojure Conj несколько лет назад об этом.
Наслаждайтесь:
https://github.com/sharkdp/bat/blob/f93d650708a90bc593ad09ad7090e512f6043f02/tests/integration_tests.rs#L307