В C# 7 — "Generalized async return types", в каком-нибудь C# 8 ещё с out-параметрами накостылят или ещё что-нибудь. В принципе, о том и речь, что асинхронный код, похожий на синхронный, будет всегда плохим решением, потому что по факту он несинхронный. И аргумент, что те, кто хорошо понимает что происходит за сценой, не испытывают проблем — не работает. Потому что вся эта декорация делается не для них, а для тех, кто ещё толком не понимает… типа "не задумывайся, что код больше не синхронный, просто добавь воды async/await".
Программисты C# уже давно пишут асинхронный код с использованием async/await и не испытывают никаких проблем с граблями.
С чего Вы так решили? Ещё как испытывают и часть из этих проблем даже официально признана и решается последующими релизами C# 6, C# 7, etc.
В принципе, тут невозможно сделать недырявую абстракцию, т.к. код по факту асинхронный и попытки это замаскировать, прикинувшись, что он как бы такой же как синхронный, ни к чему хорошему не ведут. Просто чем дальше, тем более изощрёнее будут грабли.
Мне кажется, имелось в виду, что явное в данном случае лучше неявного. И если писать асинхронный код, делая вид, что он синхронный, то рано или поздно начнётся танец по граблям.
что для кастомера бага, для разработчиков может быть фичей
Вот с этим я категорически не согласен. Когда у пользователя что-то не работает или работает не так, как ожидается, то это баг, реже enhancement или usability problem, но не фича.
Фича — это когда добавляется функциональная возможность, которой раньше вообще не было (с точки зрения пользователя), а не улучшение работы существующих возможностей.
Ну я вообще занимался в том числе и поддержкой трекера одного крупного OpenSource-проекта. Поверьте, первым делом изменяешь тип, отмечаешь дубликаты и убираешь вопросы, которые не соответствуют policy, иначе хаос и бардак будет.
Столько — это сколько? Я ж не говорю, что их все надо ежедневно перечитывать… а за день новых тикетов вряд ли появляется столько, что невозможно успеть пробежаться по ним и статусы расставить.
старые и неактуальные баги тоже закрываются, если заметят что он уже исправлен как-то
Такое бывает. Но это не относится к теме неверных типов у тикетов.
Вы намекаете, что эти тысячи тикетов никто из разработчиков даже не прочитал? Если хоть кто-то хоть раз прочитал, то тип тикета точно актуален, это меняется за секунду.
Саблайм и Атом для больших проектов — это немного не то как-бы) IDE не зря придумали всё-таки.
С одной стороны — да. А с другой — Rubymine, сколько не пробовал её в своих проектах, тупо виснет по несколько раз в час (причём может целую минуту висеть несмотря на 16 Gb оперативы) и получается, что она наоборот подходит только для относительно мелких проектов. В то время как Sublime справляется на ура с большими проектами.
Я бы проголосовал за то, чтобы в компании на какое-то время заморозили разработку новых фич и занялись исправлением ошибок и, самое главное, рефакторингом кода и/или производственного процесса
Этого, конечно, не будет, т.к. одни только багфиксы по платной подписке — это чересчур. Отдел маркетинга будет в шоке, да и пользователи, которых сейчас всё устраивает, тоже. Так что в лучшем случае больший процент времени на эти вещи смогут выделить.
Думаю, что проблема в том, что npm пытаются сравнивать с Maven, PyPI или RubyGems, в которых мусор не приветствуется. В npm же Эшли Уильямс (да и не только она) практически призывает постить всё подряд. По факту никому не интересно сколько пакетов в хранилище. Интересно сколько из них полезных… Это косвенно можно оценить по количеству скачиваний за месяц, допустим более 100 или более 1000 раз.
В принципе, даже если просто исходить из предпосылки, что полезный пакет решает какую-то обобщенную практическую задачу, то их количество ограниченно сверху тысячами, пусть будут представлены разные подходы к решению каждой задачи — всё равно остаётся ограничение в десятки тысяч. Всё что сверх этого, либо устаревшие пакеты, либо тот самый мусор, который всё же есть везде, просто в меньшем процентном соотношении. Чтобы показать крутость npm надо не циферками меряться, а составить список практических задач, для которых есть решения в npm, а в других хранилищах подобных пакетов нет.
Впрочем, тут есть ещё один феномен npm, который заключается в моде на пакеты с одной/двумя функциями. Это не укладывается в привычное понимание библиотеки, поэтому если сравнивать с другими хранилищами пакетов, то такие пакеты надо считать отдельно. Иначе какой смысл сравнивать тёплое с мягким на графиках?
Так это правда, доля программистов, которые всерьёз занимаются разработкой библиотек, довольно мала во всех языках. Но если в других языках остальные просто не публикуют никаких пакетов, то npm поставил своей целью, чтобы каждый, кто хоть неделю изучал JS, обязательно опубликовал какой-нибудь пакет. Они так прямо и говорят: хотим 15 миллионов авторов в npm и пофиг, что программистов в мире всего 18 миллионов. Можешь хотя бы пару строчек на JS написать — срочно делай пакет, мы ждём тебя!
Ну, Вы ворвались в ветку с заявлениями типа формальное описание — это бриф, а формальное доказательство — то же самое, что тестирование. Исходя из этого сложно сделать вывод, что тема Вам хоть капельку интересна, т.к. все заявления мимо кассы.
На самом деле тема очень обширная. Хоть пока и не мейнстримная. И то, что Eiffel, Coq и Prolog не используются широко в повседневной разработке вовсе не значит, что они умерли, идеи их живут и развиваются. Рано или поздно это всё придёт и в мейнстрим, т.к. цена ошибок в ПО с каждым годом только растёт.
Вам не кажется забавным, что эта "пустопорожняя беседа" по большей части состоит из Ваших собственных комментариев, на которые Вам изредка отвечают разные люди?
А по поводу ссылок, я Вам дал ссылки на Agda, на символьное выполнение программ и т.п. Уже успели ознакомиться?
В качестве практического применения символьное выполнение используется для автоматической генерации юнит-тестов.
Что касается Agda, то на основе его идей пилят язык общего назначения Idris, в феврале версию 1.0 собираются зарелизить.
А Вы ждали развития теории формального доказательства в комментариях на Хабре?.. смешной Вы однако.
Когда Вы уже ветку с начала перечитаете и осознаете, что тут никто и не собирался никаких задач ставить.
Сформулируйте лучше цель вашего активного оффтопика… Вы хотите привести доказательство, что формальная верификация невозможна никогда и ни при каких условиях или тупо покапитанить что это долго, дорого и не во всех случаях возможно?
Это сродни найти доказательство теоремы, что ничуть не проще нахождения конкретного решения, а даже — наоборот, сложнее.
Естественно написать корректную (с гарантированным отсутствием багов) программу сложнее, чем некорректную. И, разумеется, писать корректные программы экономически невыгодно, по крайней мере на текущем этапе развития индустрии. Какой смысл в ваших капитанских вопросах не по теме?
А практический смысл формальной верификации — то самое ПО без багов, пусть пока в теории. Но если не развивать теорию, то оно никогда в реальности и не появится.
В C# 7 — "Generalized async return types", в каком-нибудь C# 8 ещё с out-параметрами накостылят или ещё что-нибудь. В принципе, о том и речь, что асинхронный код, похожий на синхронный, будет всегда плохим решением, потому что по факту он несинхронный. И аргумент, что те, кто хорошо понимает что происходит за сценой, не испытывают проблем — не работает. Потому что вся эта декорация делается не для них, а для тех, кто ещё толком не понимает… типа "не задумывайся, что код больше не синхронный, просто добавь
водыasync/await".С чего Вы так решили? Ещё как испытывают и часть из этих проблем даже официально признана и решается последующими релизами C# 6, C# 7, etc.
В принципе, тут невозможно сделать недырявую абстракцию, т.к. код по факту асинхронный и попытки это замаскировать, прикинувшись, что он как бы такой же как синхронный, ни к чему хорошему не ведут. Просто чем дальше, тем более изощрёнее будут грабли.
Мне кажется, имелось в виду, что явное в данном случае лучше неявного. И если писать асинхронный код, делая вид, что он синхронный, то рано или поздно начнётся танец по граблям.
И он, в принципе, оказался прав :-)
Но хуже даже не забывчивость, а то, что бумага всё стерпит. Но это уже из Цицерона..
А его и не обязательно как-то специально учитывать… судя по примерам lany, у тех, кто сортирует баги в JetBrains, мнение просто совпадает с моим :-)
Вот с этим я категорически не согласен. Когда у пользователя что-то не работает или работает не так, как ожидается, то это баг, реже enhancement или usability problem, но не фича.
Фича — это когда добавляется функциональная возможность, которой раньше вообще не было (с точки зрения пользователя), а не улучшение работы существующих возможностей.
Не означает конечно, но если этого не делать пару месяцев, то трекер превратится в заброшенную помойку, если вашим продуктом реально пользуются люди.
Ну я вообще занимался в том числе и поддержкой трекера одного крупного OpenSource-проекта. Поверьте, первым делом изменяешь тип, отмечаешь дубликаты и убираешь вопросы, которые не соответствуют policy, иначе хаос и бардак будет.
Столько — это сколько? Я ж не говорю, что их все надо ежедневно перечитывать… а за день новых тикетов вряд ли появляется столько, что невозможно успеть пробежаться по ним и статусы расставить.
Такое бывает. Но это не относится к теме неверных типов у тикетов.
Вы намекаете, что эти тысячи тикетов никто из разработчиков даже не прочитал? Если хоть кто-то хоть раз прочитал, то тип тикета точно актуален, это меняется за секунду.
С одной стороны — да. А с другой — Rubymine, сколько не пробовал её в своих проектах, тупо виснет по несколько раз в час (причём может целую минуту висеть несмотря на 16 Gb оперативы) и получается, что она наоборот подходит только для относительно мелких проектов. В то время как Sublime справляется на ура с большими проектами.
Этого, конечно, не будет, т.к. одни только багфиксы по платной подписке — это чересчур. Отдел маркетинга будет в шоке, да и пользователи, которых сейчас всё устраивает, тоже. Так что в лучшем случае больший процент времени на эти вещи смогут выделить.
Думаю, что проблема в том, что npm пытаются сравнивать с Maven, PyPI или RubyGems, в которых мусор не приветствуется. В npm же Эшли Уильямс (да и не только она) практически призывает постить всё подряд. По факту никому не интересно сколько пакетов в хранилище. Интересно сколько из них полезных… Это косвенно можно оценить по количеству скачиваний за месяц, допустим более 100 или более 1000 раз.
В принципе, даже если просто исходить из предпосылки, что полезный пакет решает какую-то обобщенную практическую задачу, то их количество ограниченно сверху тысячами, пусть будут представлены разные подходы к решению каждой задачи — всё равно остаётся ограничение в десятки тысяч. Всё что сверх этого, либо устаревшие пакеты, либо тот самый мусор, который всё же есть везде, просто в меньшем процентном соотношении. Чтобы показать крутость npm надо не циферками меряться, а составить список практических задач, для которых есть решения в npm, а в других хранилищах подобных пакетов нет.
Впрочем, тут есть ещё один феномен npm, который заключается в моде на пакеты с одной/двумя функциями. Это не укладывается в привычное понимание библиотеки, поэтому если сравнивать с другими хранилищами пакетов, то такие пакеты надо считать отдельно. Иначе какой смысл сравнивать тёплое с мягким на графиках?
Так это правда, доля программистов, которые всерьёз занимаются разработкой библиотек, довольно мала во всех языках. Но если в других языках остальные просто не публикуют никаких пакетов, то npm поставил своей целью, чтобы каждый, кто хоть неделю изучал JS, обязательно опубликовал какой-нибудь пакет. Они так прямо и говорят: хотим 15 миллионов авторов в npm и пофиг, что программистов в мире всего 18 миллионов. Можешь хотя бы пару строчек на JS написать — срочно делай пакет, мы ждём тебя!
Ну, Вы ворвались в ветку с заявлениями типа формальное описание — это бриф, а формальное доказательство — то же самое, что тестирование. Исходя из этого сложно сделать вывод, что тема Вам хоть капельку интересна, т.к. все заявления мимо кассы.
На самом деле тема очень обширная. Хоть пока и не мейнстримная. И то, что Eiffel, Coq и Prolog не используются широко в повседневной разработке вовсе не значит, что они умерли, идеи их живут и развиваются. Рано или поздно это всё придёт и в мейнстрим, т.к. цена ошибок в ПО с каждым годом только растёт.
Вам не кажется забавным, что эта "пустопорожняя беседа" по большей части состоит из Ваших собственных комментариев, на которые Вам изредка отвечают разные люди?
А по поводу ссылок, я Вам дал ссылки на Agda, на символьное выполнение программ и т.п. Уже успели ознакомиться?
В качестве практического применения символьное выполнение используется для автоматической генерации юнит-тестов.
Что касается Agda, то на основе его идей пилят язык общего назначения Idris, в феврале версию 1.0 собираются зарелизить.
А Вы ждали развития теории формального доказательства в комментариях на Хабре?.. смешной Вы однако.
Когда Вы уже ветку с начала перечитаете и осознаете, что тут никто и не собирался никаких задач ставить.
Сформулируйте лучше цель вашего активного оффтопика… Вы хотите привести доказательство, что формальная верификация невозможна никогда и ни при каких условиях или тупо покапитанить что это долго, дорого и не во всех случаях возможно?
Естественно написать корректную (с гарантированным отсутствием багов) программу сложнее, чем некорректную. И, разумеется, писать корректные программы экономически невыгодно, по крайней мере на текущем этапе развития индустрии. Какой смысл в ваших капитанских вопросах не по теме?
А практический смысл формальной верификации — то самое ПО без багов, пусть пока в теории. Но если не развивать теорию, то оно никогда в реальности и не появится.
Пример выше легко решается символьным вычислением.
Что-то Вы опять какую-то несуразицу написали… Понятно что Вам лень изучать Agda, Prolog и т.д. Но какой смысл оффтопить, когда Вы совсем не в теме?