Я тоже исповедовал такой подход. Потом появился проект с двумя десятками модулей в разработке половины из которых я не принимал участие.
Попытка посторить систему сборки на ant+ivy привела к xml на 2000 строк + 300-500 строк на каждый модуль + по 20 строк .properties + 100 строк .sh для деплоя и меток в CVS + необходимость доносить до людей нетривиальные соглашения по конфигурации проектов чтобы это работало + hand made репозитарий артефактов. Почти 2 месяца получал фан потерял. Слава богу административные задержки не позволили распространить эту конструкцию и дали время переехать на maven.
Альтернативой стал стэк maven + continuum + archiva. 150 строк общего pom + по 50-100 на модуль, .properties по 10 строк. Всё тэгирование и деплой на совести continnum. Структурированное хранилище с индексацией по именам артефактов и их содержимомму а также несколькими репозитариями для разных команд archiva. Всего около 3 недель.
И да, большинство модулей паковалось как RCP-плагины, часть зависело от импорта WSDL через утилиты JAX-WS. Это на тему невозможности решения нестандартных проблем.
То, что Вы предлагает — это конвеер по сборке машин доставлющий их прямо к гаражу. Реализуемо, вроде удобно, но количество получаемых проблем не имеющих отношения к процессу будет доминировать над основной задачей — сборкой машины. Посмотрите как например Continuum берёт на себя вопросы деплоя и тэгирования в scm избавляя сборку от заботы об этих вопросах.
В maven это выливается в 10 минут на сочинение правильного запроса к гуглу. Найденное решение не всегда блещет элегантностью, но оно есть.
В Gradle это выливается в 4-6 часов чтения его исходников и реверсинжиниринга DSL. Причина: документация далека от исчерпывающей, DSL не консистентен, а тул не настолько популярен, чтобы находились готовые рецепты. Рассылка завалена вопросами вроде «как сделать то?» и «я тут попробовал ваш рецепт и призвал сатану».
Может стоит для жалких смертных не знакомых с макросами Clojure добавить их перевод на русский? Сдаётся мне примерно 95% прочитавших так же как и я не поняли код собственно обработки кодов и исключений.
>… замедление работы приложения, так как теперь объекты надо будет сериализовать…
Позвольте, но для записи в off heap память ведь тоже нужно сериализовывать. Или я не верно понимаю?
Не вижу при таком подходе отличий от богомерзкой джавы. Что там что там надо думать о том, что и когда вычисляется. Тока в джаве когда хочется чёнить в лог сказать можно взять и сказать.
«Т.е. нам нужно как-то указать, что мы имеем в виду одни и те же выражения» — тут встаёт вопрос… А на кой чёрт в Хаскеле сделан весь этот геморрой с IO, если реально референциальная прозрачность не используется?
Блин увлёкся. Это я к чему начинал… В сообществе функциональщиков есть интересные наработки ([1], [2]) по обращению с ошибками, счетающие в себе явность потока управления и возможность не думать об ошибке пока не захочется. И кажется эти наработки потенциально портабельны в промышленные языки и применимы.
P.S. Я знаю ссылки ужасны. Поверьте, это всё можно изложить ещё в 10 раз менее понятно.
На мой взгляд с сиключениями две проблемы, из за которых их осознано или не очень избегают:
1. Они дают рваный поток выполнения. То есть по коду (даже в статически типизированных языках) нельзя сказать куда улетит брошенное нами исключение и что может вывалится из того, что мы вызвали. Код оказывается между молотом из исключений которые бросили в него и наковальней из интерфейса который он должен поддержать.
2. Даже в статически типизированных языках с поддержкой checked exceptions язык практически не помогает в какой-то спецификации обработки ошибок. Дело в том что реальный путь исключения по стэку (с.м. п. 1) определяется не статическим описанием программы (сигнатуры методов с исключениями) а её динамической структурой (кто какие реализации вызывает).
3. Предыдущие два пункта дают совсем прохой синергетический эффект — по коду трудно понять начальный замысел автора по обработке ошибок. А если чего-то не понимаешь, то это и легко разрушить.
В общем по-моему история распространения исключений по разным языкам — это ещё один пример того, как добро выдернутое из контекста обращается во зло.
Попытка посторить систему сборки на ant+ivy привела к xml на 2000 строк + 300-500 строк на каждый модуль + по 20 строк .properties + 100 строк .sh для деплоя и меток в CVS + необходимость доносить до людей нетривиальные соглашения по конфигурации проектов чтобы это работало + hand made репозитарий артефактов. Почти 2 месяца
получал фанпотерял. Слава богу административные задержки не позволили распространить эту конструкцию и дали время переехать на maven.Альтернативой стал стэк maven + continuum + archiva. 150 строк общего pom + по 50-100 на модуль, .properties по 10 строк. Всё тэгирование и деплой на совести continnum. Структурированное хранилище с индексацией по именам артефактов и их содержимомму а также несколькими репозитариями для разных команд archiva. Всего около 3 недель.
И да, большинство модулей паковалось как RCP-плагины, часть зависело от импорта WSDL через утилиты JAX-WS. Это на тему невозможности решения нестандартных проблем.
Шутка. Пролог лучше изгоняет императивность из сознания =)
То, что Вы предлагает — это конвеер по сборке машин доставлющий их прямо к гаражу. Реализуемо, вроде удобно, но количество получаемых проблем не имеющих отношения к процессу будет доминировать над основной задачей — сборкой машины. Посмотрите как например Continuum берёт на себя вопросы деплоя и тэгирования в scm избавляя сборку от заботы об этих вопросах.
В maven это выливается в 10 минут на сочинение правильного запроса к гуглу. Найденное решение не всегда блещет элегантностью, но оно есть.
В Gradle это выливается в 4-6 часов чтения его исходников и реверсинжиниринга DSL. Причина: документация далека от исчерпывающей, DSL не консистентен, а тул не настолько популярен, чтобы находились готовые рецепты. Рассылка завалена вопросами вроде «как сделать то?» и «я тут попробовал ваш рецепт и призвал сатану».
жалких смертныхне знакомых с макросами Clojure добавить их перевод на русский? Сдаётся мне примерно 95% прочитавших так же как и я не поняли код собственно обработки кодов и исключений.Позвольте, но для записи в off heap память ведь тоже нужно сериализовывать. Или я не верно понимаю?
P.S. Я знаю ссылки ужасны. Поверьте, это всё можно изложить ещё в 10 раз менее понятно.
1. Они дают рваный поток выполнения. То есть по коду (даже в статически типизированных языках) нельзя сказать куда улетит брошенное нами исключение и что может вывалится из того, что мы вызвали. Код оказывается между молотом из исключений которые бросили в него и наковальней из интерфейса который он должен поддержать.
2. Даже в статически типизированных языках с поддержкой checked exceptions язык практически не помогает в какой-то спецификации обработки ошибок. Дело в том что реальный путь исключения по стэку (с.м. п. 1) определяется не статическим описанием программы (сигнатуры методов с исключениями) а её динамической структурой (кто какие реализации вызывает).
3. Предыдущие два пункта дают совсем прохой синергетический эффект — по коду трудно понять начальный замысел автора по обработке ошибок. А если чего-то не понимаешь, то это и легко разрушить.
В общем по-моему история распространения исключений по разным языкам — это ещё один пример того, как добро выдернутое из контекста обращается во зло.