Так я и говорю что наличие проверки в рантайме гарантируется на стадии компиляции, но если на стадии компиляции всё известно, то проверку в рантайм можно не добавлять.
Ну это уже в рантайме, тут типы разве что помогают оптимизировать — делать проверку в рантайме тогда и только тогда когда при компиляции ничего неизвестно.
Был пару дней в Хельсинки — да, видно что труд человека дорого — тротуары плиткой обычно не укладывают, в бане на пол и стены плитку тоже не потрудились уложить, хотя на стеклянную стену денег хватило.
Когда звали я не придумал как это красиво оформить, брал турвизу, а финскому пограничнику на его вопрос ответил как-то автоматом что meet friend, не скажу что мне нравится такой вариант, но не ожидал что будут вопросы.
К сожалению моё образование не позволяет ничего понять, но если я правильно понял дискуссии выше, то там идёт обсуждение о том как на стадии компиляции гарантировать, что индекс не выйдёт за пределы массива, при том что значение индекса будет известно только в рантайме — мне кажется это в принципе невозможно.
Или есть какая-то математическая магия которая хотя бы частично это покрывает?
Ээ, а что не так-то? Это просто коснтатация факта — значительная часть уязвимостей и багов связаны с такого типа ошибками. И если 40 лет назад ещё можно было думать что это просто плохие программисты, то сегодня понятно что даже самые лучшие ошибаются.
от хорошего программиста в продуктовой разработке часто ожидают эффективного решения всех вышеупомянутых задач.
ну наверное кто-то ожидает, но во-первых, это не значит что это так должно быть, а во-вторых, первые три требования они на самом деле про одно и то же — про читаемый и поддерживаемый код, который как раз и нужно увидеть на собесе (3-й пункт реализуем иммено в том случае когда код нормальный, иначе это лотерея), 4-й пункт это про адекватность, а не про код — нормальный человек понимает что такое разовая задача, хотя давать такие задачи стоит только джуниорам если не хотите терять спецов. 5-й — опять же разовая задача, но для опытного и толкового, который может также не помнить ничего про сложность конкретных алгоритмов, нагалит и решит.
Баги, связанные с алгоритмической сложностью, одни из самых неприятных для бизнеса.
но это не значит что человек должен поняить наизусть сложность всего и вся, он должен знать о самом понятии сложности.
Сюда же относятся и вопросы про ACID
точно также нет нужны помнить расшифровку, надо значить что уровня изорляции бывают разные (не нужно помнить наизусть) и что из этого следует.
Ваш опыт остаётся внутри вас, его не предъявишь другим, другим вы можете показать лишь свои аргументы.
Но конечно опыт формирует убуждения и может оказаться что убеждения разные и ни одна сторона не готова их менять, ибо строгих, объективных аргументов ни у кого нет, а у каждого есть лишь свой опыт.
Даже по этому комментарию понятно, что минусы вам ставили не за альтернативную точку зрения, а за слабую аргументацию. Что это за агумент «Я должен взять свой десятилетний опыт — выбросить в мусор?»? Вообще непонятно к чему эта фраза.
) хороший вопрос, я-то сам за чистофункциональный подход и строгие системы типов, но в реальности получается что древний хаскел остаёт от новорожденного раста, по популярности, да и по производительности, а по сложности мне их сравнивать трудно, разные они
UI это не картинка, UI это структура элементов управления. Положить под капот SVG вероятно хорошая идея, но это лишь часть вопроса, нужен адекватный UI Markup Language
Я же не говорил что он займёт нишу питона, я говорил что широта использования будет сравнима, если хотите можно сказать популярен раст будет когда C/C++ будут вытеснены хотя бы наполовину из новых проектов.
Всё-таки люди Rust хотят именно ради гарантий компилятора (так-то и на сях можно производительно написать), поэтому отмахиваться от замечаний на этот счёт не очень разумно.
похоже уже 6 мес
Или есть какая-то математическая магия которая хотя бы частично это покрывает?
ну наверное кто-то ожидает, но во-первых, это не значит что это так должно быть, а во-вторых, первые три требования они на самом деле про одно и то же — про читаемый и поддерживаемый код, который как раз и нужно увидеть на собесе (3-й пункт реализуем иммено в том случае когда код нормальный, иначе это лотерея), 4-й пункт это про адекватность, а не про код — нормальный человек понимает что такое разовая задача, хотя давать такие задачи стоит только джуниорам если не хотите терять спецов. 5-й — опять же разовая задача, но для опытного и толкового, который может также не помнить ничего про сложность конкретных алгоритмов, нагалит и решит.
но это не значит что человек должен поняить наизусть сложность всего и вся, он должен знать о самом понятии сложности.
точно также нет нужны помнить расшифровку, надо значить что уровня изорляции бывают разные (не нужно помнить наизусть) и что из этого следует.
Но конечно опыт формирует убуждения и может оказаться что убеждения разные и ни одна сторона не готова их менять, ибо строгих, объективных аргументов ни у кого нет, а у каждого есть лишь свой опыт.
) хороший вопрос, я-то сам за чистофункциональный подход и строгие системы типов, но в реальности получается что древний хаскел остаёт от новорожденного раста, по популярности, да и по производительности, а по сложности мне их сравнивать трудно, разные они
Дадите ссылки? Интересно