Да блин! Проблемы есть! И были и будут. С этим ничего не поделать. Архитектура и соглашения нарушаются, быдлокод в проектах есть, в проектах заводятся странные зависимости по прихоти вашей системы управления зависимостями.
Смиритесь с тем, что мир устроен хреново и ваши программы станут гораздо лучше ему соответствовать.
В своём опросе как и в статье Вы совершенно не учитываете (не понимаете?...) один важный момент: исключения и ошибки это разные вещи. Они служат разным целям, должны управляться разными механизмами и имеют совершенно разные требования к производительности.
Пункты «Коды ошибок — наше все» и «Мой код идеален, в нем не бывает ошибок» — не имеют смысла в опросе про исключения.
БОльшое спасибо за опдборку ссылок давно пытался найти источники по многопоточности в .NET. Но вот банальные запросы вроде ".net memory model" ничего дельного на на поверхность не выносили :(
Как человек два с половиной года использовавший самописный полу-REST полу-хрензнаетчто протокол с обоих сторон могу сказать, что тут нет ничего теоритического. Использование одной штуки для разных вещей верный путь к сотням просранных человекочасов. Просранных глупо и бессмысленно, без отдачи для проекта и с огромным минусом в мораль команды.
Альтернативы конечно есть: писать исчерпывающую документацию, которую потом читают. Вот только не похоже, что тут водятся ребята с фейсбука у которых есть ресурсы для первого и авторитет для второго.
Прочитал два раза и честно говоря не понял проблемы использовать POST. Его семантика: доставить сообщение ресурсу. Сообщение может быть «reboot». Как ресурс изменит своё (или не своё) состояние не оговаривается.
Цитируя RFC: «POST is designed to allow a uniform method to cover the following functions:
…
— Posting a message to a bulletin board, newsgroup, mailing list, or similar group of articles;
…
The actual function performed by the POST method is determined by the server and is usually dependent on the Request-URI.
…
The action performed by the POST method might not result in a resource that can be identified by a URI.
»
Таким образом планирование и исполнение задачи перезагрузки VM вполне укладывается в семантику POST. Мало того, если также рассматривать операции вроде создания образа или установки ОС как планирование задач (идентифицируемых и опрашиваемых на предмет состояния выполнения) они тоже прекрасно укладываются в REST.
> Каждый этап калькуляции — это объект, который будет участвовать во всем процессе.
Тут то есть проблема. Объекты и классы придуманы для удобной связи состояния и поведения с поддержкой сокрытия первого. Когда нет состояния (как в случае если объект представляет собой шаг вычислений) все ОО конструкции теряют смысл. Остаётся только ритуал создания объекта не имеющий ничего общего с задачей.
> Для общения между шагами, чтобы дать им возможность обмениваться данными, создадим еще один вспомогательный объект, который будет хранить в себе все промежуточные рассчеты.
На самом деле в подавляющем большинстве языков такой объект уже создан. Называется стэк :)
> все игровые объекты должны реализовывать интерфейс ManagedObject
> Ссылка на такой объект должна храниться не в явном виде, а внутри специального объекта – ManagedReference
Ааа!!! Sun прекрати разрабатывать прикладные фреймфорки. Больше не надо. Хватит. Просто остановись. Вы отлично делаете виртуальные машины, оси и процессоры, занимайтесь ими, пажалуйста!
Поинт в том, что без него обычно можно жить и часто гораздо приятнее. А не в том что надо всем бросить заниматься делом и строить бесполезные программы в лямбда-исчислении.
Ой да ладно. Твиттер со своим standard-project и в 0.7 страх наводил, которым тут и не пахнет. Научиться читать (и со скрипом писать) такие билды — это два вечера (сам вот только недавно осваивал).
По теме комента: а можно пример элемента _требующего_ знаний теории множеств.
Чем лучше имя на христианском набора символов? Если не понимаешь что оно делает — непонятно в любом случае. Если понимаешь — всё ок. Единственна реальная проблема — это именование таких операторов в устной речи. Но если не увлекаться и граничиваться операторами вроде << или ++ — проблем вообще не видно.
Вы — жалкий смертный. Или этого мало?
Смиритесь с тем, что мир устроен хреново и ваши программы станут гораздо лучше ему соответствовать.
Пункты «Коды ошибок — наше все» и «Мой код идеален, в нем не бывает ошибок» — не имеют смысла в опросе про исключения.
Альтернативы конечно есть: писать исчерпывающую документацию, которую потом читают. Вот только не похоже, что тут водятся ребята с фейсбука у которых есть ресурсы для первого и авторитет для второго.
Цитируя RFC: «POST is designed to allow a uniform method to cover the following functions:
…
— Posting a message to a bulletin board, newsgroup, mailing list, or similar group of articles;
…
The actual function performed by the POST method is determined by the server and is usually dependent on the Request-URI.
…
The action performed by the POST method might not result in a resource that can be identified by a URI.
»
Таким образом планирование и исполнение задачи перезагрузки VM вполне укладывается в семантику POST. Мало того, если также рассматривать операции вроде создания образа или установки ОС как планирование задач (идентифицируемых и опрашиваемых на предмет состояния выполнения) они тоже прекрасно укладываются в REST.
Тут то есть проблема. Объекты и классы придуманы для удобной связи состояния и поведения с поддержкой сокрытия первого. Когда нет состояния (как в случае если объект представляет собой шаг вычислений) все ОО конструкции теряют смысл. Остаётся только ритуал создания объекта не имеющий ничего общего с задачей.
> Для общения между шагами, чтобы дать им возможность обмениваться данными, создадим еще один вспомогательный объект, который будет хранить в себе все промежуточные рассчеты.
На самом деле в подавляющем большинстве языков такой объект уже создан. Называется стэк :)
> Ссылка на такой объект должна храниться не в явном виде, а внутри специального объекта – ManagedReference
Ааа!!! Sun прекрати разрабатывать прикладные фреймфорки. Больше не надо. Хватит. Просто остановись. Вы отлично делаете виртуальные машины, оси и процессоры, занимайтесь ими, пажалуйста!
Чем лучше имя на христианском набора символов? Если не понимаешь что оно делает — непонятно в любом случае. Если понимаешь — всё ок. Единственна реальная проблема — это именование таких операторов в устной речи. Но если не увлекаться и граничиваться операторами вроде << или ++ — проблем вообще не видно.