из примечательных ревизий эволюции механизма раскручивания стека ... В целом, мне кажется, и я и так потратил больше времени, чем хотел, на проверку вашей фантазии.
Вы потратили время на свои фантазии, которые совершенно не связаны с заданным мной вопросом. Выше я писал, что мне интересна реализация "контроля владения и заимствований во время компиляции при наличии исключений в языке"
Ключевым тут является во время компиляции. Ведь именно данная фича является главным аргументом апологетов за рекламирование Rust? Но согласитесь, что раскрутка стека, ссылки на реализацию которую вы несколько дней искали в коде, никак не связаны с контролем владения и заимствований во время компиляции?
Раз вы реально не понимаете, давайте я еще раз попробую расписать проблему на пальцах.
Чтобы во время компиляции анализатор языка мог контролировать жизненный цикл переменных, он должен быть детерминированным (строго определенным), тогда как исключения (или прерывания в общем случае), не позволяют это сделать во время анализа исходного текста программы.
Это можно попытаться исправить, например за счет введения в язык checked исключений, как в Java, но даже в этом случае остается класс unchecked исключений, которые компилятор никак не контролирует и которые можно обработать только в рантайме, т.е. при раскручивании стека, как в ваших примерах.
Но для этого, язык изначально должен поддерживать обработку исключений на уровне лексики, а не в виде отдельных элементов базовой библиотеки, которые можно использовать, а можно на них и забить, но этого в Rust не наблюдается.
Ну что же, раз исключение - "с точки контроля владения, возбуждение исключения - всего лишь ещё один способ вернуть значение из функции", то это конечно очень сильный аргумент.
А какие нибудь подробности или описание реализации, кроме "честное слово" у вас будет?
Не выявил никаких проблем с технической реализацией из-за противоречия каким-то киллер-фичам. Не вижу подтверждений Вашей гипотезы.
И каким же образом вы это выявили, только по названию ключевых слов?
Что же касается технической реализации, то будьте добры ссылку или напишите своими словами, как реализуется контроль владения и заимствований во время компиляции при наличии исключений в языке?
Так считаю не только я, но и Институт управления проектами ...
Да что вы все концентрируетесь на определениях? Я же вам написал, что их я вообще не касаюсь. Просто вы изначально использовали слово проект "разраб и продакт вместе пилят 10 проектов", но я пытаюсь обратить ваше внимание, что проект для разработчика и проект для продакта, это могут быть совершенно разные проекты (или подпроекты по классификации PMBOK).
Ведь посыл вашего поста в том, что "продакты становятся крутыми в 10 раз медленнее" на примере собеседований. Тогда как я вам предложил для продакта сценарий ответов на собеседовании точ-в-точ как и у разраба с упором на продуктовые фичи, которые будут полностью соответствовать запиленным фичам разработчика, а что соответствует их скорости развития 1 в 1, а не 10 раз медленнее.
Вы проектом называете сущность, которая во времени ограничена только коммерческой целесообразностью (пока целесообразно, ваш проект существует). Ваше право, определения — штука гибкая.
Нет, что вы, я вообще не трогаю определений.
Я говорю про то, что "завершенный проект" со стороны программиста (который их делает 10) и "завершенный проект" со стороны менеджера продукта (который делает только 1), это не только разные проекты, но и разные этапы жизненного цикла.
И если вы считаете, "Следите за руками: разраб и продакт вместе пилят 10 проектов" - что они начинают и заканчивают одновременно, то действительно "С такой аналитикой продакты и правда не нужны"
Согласен с комментарием насчет качества аналитики. Ведь что и как рассказывать на собеседовании в ответ на вопрос решает только кандидат. И оценивать "на выходе у разраба опыт реализации 10 (!) проектов, а у продакта 1 успешный проект", это верх примитивизма и отсутствие опыта (что как раз и говорит о низком качестве аналитики).
Если у продакта проект завершен, это скорее всего значит, что сам проект закрыли из-за его коммерческой неудачи, что может говорить о разных проблемах проекта, в том числе и с точки зрения управления продуктом. Ведь для программиста завершение проекта, это завершение активной стадии его разработки, тогда как для продукт-менеджера это НАЧАЛО его коммерческой эксплуатации.
Поэтому, как по мне, то для продакта вообще не желательно рассказывать про завершенные проекты. Рассказывайте про реализованные отдельные фичи, их аналитику, оценку их перспективности, планирование и согласование разработки, внедрение и полученный эффект, влияние на другие фичи и т.д. Ведь практически всегда приходится дорабатывать продукт в процессе его разработки и эксплуатации. И определение векторов развития продукта и есть основное назначение работы продакт-менеджера.
Вы вроде все правильно написали, и я даже апнул, но если честно, у вас слишком много воды. И про команду вроде бы все правильно, но архитектор, это не тимлид или ПМ (хотя и может совмещать).
Как по мне, то для архитектора самое важное, это разграничение зоны его ответственности. Если должность (или роль) архитектора формальная и итоговые архитектурные решения принимаются не им, то такую роль нужно вообще упразднять или передавать тому, кто подобные решения принимает (ПМ, продукт и т.д.).
Это всего лишь мое предположение, основанное на изучении особенностей реализации языка и некоторых оговорках разработчиков (или перевод на Хабре) о том, что изначально планировалось сделать и что в итоге из этого вышло.
Прострел ноги тут в том, что непроверяемое на этапе компиляции наличие catch блоков ведёт к созданию программ, которые иногда падают из-за непойманного исключения.
Тут проблема скорее в синтаксисе try/catch конструкций для типизированных исключений. Если попробовать придумать синтаксис, обеспечивающий декларацию перехвата исключений без дополнительных конструкций try/catch, тогда и исключения можно было бы использовать более безопасно.
вообще отказаться в языке от исключений.
Как оказалось, полностью отказаться от исключений все равно не получается
Гугл рекомендует не использовать исключения из-за нарушения совместимости с существующим легаси кодом, в котором исключений как правило нет, из-за чего подобное изменение архитектуры будет очень трудозатратно. Поэтому там и написано "Our advice against using exceptions is not predicated on philosophical or moral grounds, but practical ones. "
Что же касается реализация исключений в С++ и в Rust, то мне кажется, что они находятся как бы на двух противоположных крайностях. В С++ с исключениями можно делать все, что угодно, но там и без исключений можно серьезно накосячить, тогда как не использование исключений в Rust, это " идеологическое решение по уменьшению случайных выстрелов себе в ногу".
Хотя как я и писал в самом начале, изначально их не сделали, потому что при их наличии сложно реализовать основную киллер фичу языка, а потом поняли, что полностью без них обойтись нельзя, поэтому в версии 1.9 (или какой другой - не знаю), пришлось добавлять панику, и её обработку, но в виде исключительного решения :-).
Ок, жду вашего комментария на вопрос "что Вы имеете в виду?"
Хорошо, пусть будет по вашему. Я соглашусь с вами, что в Rust есть механизм похожий на исключения (которые называются паника), хотя их не очень удобно использовать для программирования логики работы приложения. Но это уже дело вкуса разработчиков на Rust, к которым я не отношусь.
Принципиальная разница между эти конструкциями в возможности вложения и возможности продолжения нормального выполнения приложения после возникновения исключения.
Я сам ничего не имею против Rust. Более того, часть его идей я взял и продолжил развитие в своем проекте. И мне больно смотреть, когда разработчики держатся за идеологию, но не хотят признавать некоторых шероховатостей при изначальном проектировании языка.
Но в настоящий момент идеология Rust уже сформирована и её нельзя переделать без коренных изменений в языке и сознании всего комьюнити, так как «бытие определяет сознание». Вот вы, вместо того, чтобы понять собеседника, ставите минус его мнению, потому что оно идет в разрез с вашими убеждениями.
будто бы из-за try/catch'а какие-то фичи Rust'а "превращались бы в тыкву", мне кажется несостоятельным.
Ну про тыкву писал я. И мое утверждение заключается в том, что создатели Rust просто не смогли реализовать проверки перехода владения и заимствования при наличии try/catch и в следствии этого объявили исключения идеологически неверными и якобы отсутствующими в языке. Но так как исключения (прерывания потока выполнения, в том числе и из-за ошибок) все равно никуда не деваются, то и возникает весь этот сыр бор с std::panic::set_hook и std::panic::catch_unwin для обработки того, чего в языке нет :-)
Это не взгляд с другой стороны, а подтасовка фактов, притянутая за уши. Обработка ошибок на коде возврата реализована как возврат целого числа, тогда как обработка ошибок на исключениях реализована как возврат текстовой строки. Еще бы ей не быть в 49540.11784 раз медленнее, если нужно каждый раз выделять память в куче :-)
Я вам привел пример кода, когда "предусмотренные в программе, но фактически не возбуждаемые исключения не ухудшают его эффективность", т.е. опровергают ваше голословное утверждение, что "автор пишет неправду", так как по факту неправы именно вы.
В вашем же примере я не понял, причем тут исключения, если два ваши фрагмента кода делают разные вещи.
Перелицензирование, это и означает убрать одну и поставить другу лицензию. Читайте по своей же ссылке пунктом ниже (где речь идет о лицензии CC BY)
BY and BY-NC material
When remixing BY or BY-NC material, it is generally recommended that your adapter’s license include at least the same license elements as the license applied to the original material. This eases reuse for downstream users because they are able to satisfy both licenses by complying with the adapter’s license. For example, if you adapt material licensed under BY-NC, your adapter’s license should also contain the NC restriction. See the chart below for more details.
Для этих лицензий (BY and BY-NC) рекомендуется сохранять исходную лицензию, но это не обязательное требование, как в случае остальных CC лицензий.
Я всего лишь обратил внимание, что когда автор статьи утверждает, что предусмотренные в программе, но фактически не возбуждаемые исключения не ухудшают эффективность кода, то это неправда.
А в чем не правда? Подобное предусмотренное исключение, но фактически не возбуждаемые, и в самом деле не ухудшают эффективность кода и оба примера ниже полностью идентичны, если не происходит ошибки.
Я же от вас прошу примера, в чем тут по вашему мнению состоит неправда.
Мне его обработчик деления на ноль нафиг не сдался, если он простым своим присутствием замедляет программу во много раз.
Что вы имеете тут ввиду? Неужто вы считаете, что проверка деления на ноль выполняется при обработке ошибок с помощью исключений, а когда этого нет, то на ноль можно делить и все будет хорошо?
Так ведь это вы про нее писали, осталось понять, при чем тут вообще раскрутка стека?
Вы потратили время на свои фантазии, которые совершенно не связаны с заданным мной вопросом. Выше я писал, что мне интересна реализация "контроля владения и заимствований во время компиляции при наличии исключений в языке"
Ключевым тут является во время компиляции. Ведь именно данная фича является главным аргументом апологетов за рекламирование Rust?
Но согласитесь, что раскрутка стека, ссылки на реализацию которую вы несколько дней искали в коде, никак не связаны с контролем владения и заимствований во время компиляции?
Раз вы реально не понимаете, давайте я еще раз попробую расписать проблему на пальцах.
Чтобы во время компиляции анализатор языка мог контролировать жизненный цикл переменных, он должен быть детерминированным (строго определенным), тогда как исключения (или прерывания в общем случае), не позволяют это сделать во время анализа исходного текста программы.
Это можно попытаться исправить, например за счет введения в язык checked исключений, как в Java, но даже в этом случае остается класс unchecked исключений, которые компилятор никак не контролирует и которые можно обработать только в рантайме, т.е. при раскручивании стека, как в ваших примерах.
Но для этого, язык изначально должен поддерживать обработку исключений на уровне лексики, а не в виде отдельных элементов базовой библиотеки, которые можно использовать, а можно на них и забить, но этого в Rust не наблюдается.
Ну что же, раз исключение - "с точки контроля владения, возбуждение исключения - всего лишь ещё один способ вернуть значение из функции", то это конечно очень сильный аргумент.
А какие нибудь подробности или описание реализации, кроме "честное слово" у вас будет?
И каким же образом вы это выявили, только по названию ключевых слов?
Что же касается технической реализации, то будьте добры ссылку или напишите своими словами, как реализуется контроль владения и заимствований во время компиляции при наличии исключений в языке?
Да что вы все концентрируетесь на определениях? Я же вам написал, что их я вообще не касаюсь. Просто вы изначально использовали слово проект "разраб и продакт вместе пилят 10 проектов", но я пытаюсь обратить ваше внимание, что проект для разработчика и проект для продакта, это могут быть совершенно разные проекты (или подпроекты по классификации PMBOK).
Ведь посыл вашего поста в том, что "продакты становятся крутыми в 10 раз медленнее" на примере собеседований. Тогда как я вам предложил для продакта сценарий ответов на собеседовании точ-в-точ как и у разраба с упором на продуктовые фичи, которые будут полностью соответствовать запиленным фичам разработчика, а что соответствует их скорости развития 1 в 1, а не 10 раз медленнее.
Нет, что вы, я вообще не трогаю определений.
Я говорю про то, что "завершенный проект" со стороны программиста (который их делает 10) и "завершенный проект" со стороны менеджера продукта (который делает только 1), это не только разные проекты, но и разные этапы жизненного цикла.
И если вы считаете, "Следите за руками: разраб и продакт вместе пилят 10 проектов" - что они начинают и заканчивают одновременно, то действительно "С такой аналитикой продакты и правда не нужны"
Согласен с комментарием насчет качества аналитики. Ведь что и как рассказывать на собеседовании в ответ на вопрос решает только кандидат. И оценивать "на выходе у разраба опыт реализации 10 (!) проектов, а у продакта 1 успешный проект", это верх примитивизма и отсутствие опыта (что как раз и говорит о низком качестве аналитики).
Если у продакта проект завершен, это скорее всего значит, что сам проект закрыли из-за его коммерческой неудачи, что может говорить о разных проблемах проекта, в том числе и с точки зрения управления продуктом. Ведь для программиста завершение проекта, это завершение активной стадии его разработки, тогда как для продукт-менеджера это НАЧАЛО его коммерческой эксплуатации.
Поэтому, как по мне, то для продакта вообще не желательно рассказывать про завершенные проекты. Рассказывайте про реализованные отдельные фичи, их аналитику, оценку их перспективности, планирование и согласование разработки, внедрение и полученный эффект, влияние на другие фичи и т.д. Ведь практически всегда приходится дорабатывать продукт в процессе его разработки и эксплуатации. И определение векторов развития продукта и есть основное назначение работы продакт-менеджера.
Вы вроде все правильно написали, и я даже апнул, но если честно, у вас слишком много воды. И про команду вроде бы все правильно, но архитектор, это не тимлид или ПМ (хотя и может совмещать).
Как по мне, то для архитектора самое важное, это разграничение зоны его ответственности. Если должность (или роль) архитектора формальная и итоговые архитектурные решения принимаются не им, то такую роль нужно вообще упразднять или передавать тому, кто подобные решения принимает (ПМ, продукт и т.д.).
Да.
Это всего лишь мое предположение, основанное на изучении особенностей реализации языка и некоторых оговорках разработчиков (или перевод на Хабре) о том, что изначально планировалось сделать и что в итоге из этого вышло.
Тут проблема скорее в синтаксисе try/catch конструкций для типизированных исключений. Если попробовать придумать синтаксис, обеспечивающий декларацию перехвата исключений без дополнительных конструкций try/catch, тогда и исключения можно было бы использовать более безопасно.
Как оказалось, полностью отказаться от исключений все равно не получается
Гугл рекомендует не использовать исключения из-за нарушения совместимости с существующим легаси кодом, в котором исключений как правило нет, из-за чего подобное изменение архитектуры будет очень трудозатратно. Поэтому там и написано "Our advice against using exceptions is not predicated on philosophical or moral grounds, but practical ones. "
Что же касается реализация исключений в С++ и в Rust, то мне кажется, что они находятся как бы на двух противоположных крайностях. В С++ с исключениями можно делать все, что угодно, но там и без исключений можно серьезно накосячить, тогда как не использование исключений в Rust, это " идеологическое решение по уменьшению случайных выстрелов себе в ногу".
Хотя как я и писал в самом начале, изначально их не сделали, потому что при их наличии сложно реализовать основную киллер фичу языка, а потом поняли, что полностью без них обойтись нельзя, поэтому в версии 1.9 (или какой другой - не знаю), пришлось добавлять панику, и её обработку, но в виде исключительного решения :-).
Хорошо, пусть будет по вашему. Я соглашусь с вами, что в Rust есть механизм похожий на исключения (которые называются паника), хотя их не очень удобно использовать для программирования логики работы приложения. Но это уже дело вкуса разработчиков на Rust, к которым я не отношусь.
Принципиальная разница между эти конструкциями в возможности вложения и возможности продолжения нормального выполнения приложения после возникновения исключения.
Я сам ничего не имею против Rust. Более того, часть его идей я взял и продолжил развитие в своем проекте. И мне больно смотреть, когда разработчики держатся за идеологию, но не хотят признавать некоторых шероховатостей при изначальном проектировании языка.
Но в настоящий момент идеология Rust уже сформирована и её нельзя переделать без коренных изменений в языке и сознании всего комьюнити, так как «бытие определяет сознание». Вот вы, вместо того, чтобы понять собеседника, ставите минус его мнению, потому что оно идет в разрез с вашими убеждениями.
Rust моей мечты — несостоявшийся язык / Хабр
Как легко перейти с Java на Rust: Особенности и советы / Комментарии / Хабр
Ну про тыкву писал я. И мое утверждение заключается в том, что создатели Rust просто не смогли реализовать проверки перехода владения и заимствования при наличии try/catch и в следствии этого объявили исключения идеологически неверными и якобы отсутствующими в языке.
Но так как исключения (прерывания потока выполнения, в том числе и из-за ошибок) все равно никуда не деваются, то и возникает весь этот сыр бор с std::panic::set_hook и std::panic::catch_unwin для обработки того, чего в языке нет :-)
:-(
Это не взгляд с другой стороны, а подтасовка фактов, притянутая за уши.
Обработка ошибок на коде возврата реализована как возврат целого числа, тогда как обработка ошибок на исключениях реализована как возврат текстовой строки. Еще бы ей не быть в 49540.11784 раз медленнее, если нужно каждый раз выделять память в куче :-)
Я вам привел пример кода, когда "предусмотренные в программе, но фактически не возбуждаемые исключения не ухудшают его эффективность", т.е. опровергают ваше голословное утверждение, что "автор пишет неправду", так как по факту неправы именно вы.
В вашем же примере я не понял, причем тут исключения, если два ваши фрагмента кода делают разные вещи.
Перелицензирование, это и означает убрать одну и поставить другу лицензию.
Читайте по своей же ссылке пунктом ниже (где речь идет о лицензии CC BY)
Для этих лицензий (BY and BY-NC) рекомендуется сохранять исходную лицензию, но это не обязательное требование, как в случае остальных CC лицензий.
А в чем не правда? Подобное предусмотренное исключение, но фактически не возбуждаемые, и в самом деле не ухудшают эффективность кода и оба примера ниже полностью идентичны, если не происходит ошибки.
Я же от вас прошу примера, в чем тут по вашему мнению состоит неправда.
Что вы имеете тут ввиду? Неужто вы считаете, что проверка деления на ноль выполняется при обработке ошибок с помощью исключений, а когда этого нет, то на ноль можно делить и все будет хорошо?