в Go тоже можно нагородить спагетти вложенных замыканий
Такой код не пройдет, потому что начальник индус его не поймет. И потом, если кодер такой умный, сфигали он не пишет финансовые опердени на хаскеле? Это касается и растозадротов, которые в хеловордах усьраивают цирк с конями. Впрочем, на этих всем пофиг, их в индустрию не пустят все одно.
Да, мы попоболь лучше терпеть будем, сначала натягивая «обилие спецсимволов» на то, что хотим сделать, а потом, кряхтя, отлаживая всякие implicit behavior.
Слышать такое от любителей динамической типизации - бесценно %)
Динамическая типизация (в лиспе) и неявное поведение - это ортогональные вещи. Книжку с современным стандартом C++ даже колхозник побоится положить на технологические нужды в деревянное строение с дыркой в полу, не то, что читать.
А давайте проверим. Только что по диагонали пробежал глазами пример из «Senior Rust Programmer».
Похоже, что там программист пытается найти сумму целых чисел со знаком, общей величиной не более, чем 2^63, введённую единой строкой пользователем руками с клавиатуры, числа разделены пробельными символами. Пример содержит неочевидное для математика поведение, т.к. введённое '- 1' выдаст ошибку, в то время, как '-1' будет прочитано как отрицательное число.
tailgunner я прав? Код на Rust никогда не писал и более того, мои знания Rust на текущий момент абсолютно равны 0, т.к. доки по раст открывал пару, либо вообще 1 раз и довольно давно.
Следовательно, если я, хотя бы на 60% угадал, это будет показательным примером того, что вы неправы.
По-моему, особой проблемы в динамической типизации нет, если опустить вопрос производительности, а вот из-за слабой типизации я по ногам не раз стрелял.
Так он тоже не писал. Зачем у него спрашивать, это балаболка без единой подтвержденной строчки на чем бы то ни было. Воплощение лоровского специалиста по всему.
Больше никого не знаю на ЛОРе, кто знает раст. Не знаю, насколько хорошо, но во всяком случае, он хотя бы доки по нему читал. А я читал «настолько давно, что уже и неправда» (с).
С - это нежить. А в плюсах споткнуться можно, а можно и заделать себе полностью строгую типизацию. Если прям очень хочется, в плюсах можно полностью (на 99,99999%) отказаться от встроенных типов. А классы - сильно типизированы.
Ну, по-правде, я плюсы юзаю только когда на сях распердолисто получается, а всё нужное уже есть где-нибудь в бусте, например. Знаю очень поверхностно и не фанат. Но примерно то же самое можно сказать и про питон, например, прилаживаешь статический анализатор, а в коде просто никогда не меняешь типов переменных, плюс проверки переодически втыкаешь, и, считай, почти статика.
Но это не то. Возможность внезапно обделаться всё равно присутствует.
Похоже, что там программист пытается найти сумму целых чисел со знаком, общей величиной не более, чем 2^63, введённую единой строкой пользователем руками с клавиатуры, числа разделены пробельными символами. Пример содержит неочевидное для математика поведение, т.к. введённое ‘- 1’ выдаст ошибку, в то время, как ‘-1’ будет прочитано как отрицательное число.
Примерно так, да. Ошибок может быть больше, но вся их обработка отдана на откуп parse. Пойнт поста не в том, чтобы показать, как обрабатывать ошибки, а в том, чтобы продемонстрировать разные способы решения простой задачи - простые, сложные, и просто стебные.
«Нечитаемость» применительно к языку — это когда он выглядит как вуду-магия, а буквальной нечитаемости при большом желании можно на любом языке достичь.
Не помню откуда я это взял, но по-моему, было было какое-то исследование, которое показало, что большую часть времени разработчик не пишет код, а читает. Так что выразительностью следует жертвовать в пользу очевидности.
Не говоря уже о том, что чем сложнее язык, тем проще оверинженерить дичайшую срань, которую ты привёл в оп, сотней разных способов.
большую часть времени разработчик не пишет код, а читает.
Верно.
Так что выразительностью следует жертвовать в пользу очевидности.
Неверно. Как минимум, выразительность сокращает объем кода, который нужно писать (за счет этого может сократить количество ошибок) и читать (за счет этого может сократить затраты на понимание). Как пример из области, не относящейся к программированию - дорожные знаки. Никто не пишет «стоянка запрещена» - просто рисуют перечеркнутый круг.
Не говоря уже о том, что чем сложнее язык, тем проще оверинженерить дичайшую срань
А чем проще язык, тем сложнее, многословнее и разнообразнее может быть решение нетривиальной задачи.