Здравствуйте, Erop, Вы писали:

E>Прикольно, как это взаимосоотносится с тезисом Цайберакса о том, что Ява для людей пишуших мегастройный код, а C# для кодеров начального уровня...
E>Хотя мне вот тоже кажется, что вся методология работы с Мавином построена на том, что библиотеки намного лучше реализованы, чем прикладной код...

Да, ключевой момент успеха Maven2 в Java среде (на мой взгляд) — наличие большого числа качественных и средне-качественных OS библиотек практически на все случаи жизни.

Здравствуйте, IB, Вы писали:

WF>> При этом эти OS библиотеки и фреймворки, как правило, по качеству гораздо лучше того, что делаем мы сами.

IB>Меня терзают смутные сомненья. Сколько OS фреймворков не видел, в большинстве случаев качество ниже плинтуса и никто ни за что не отвечает.

В .NET-среде или в Java? Я только за Java ручаться могу. И то за небольшую часть, ту, с которой я работал. С .NET фактически не работал, потому и сравнить не могу.

WF>>Либо они написаны грамотными разработчиками (тот же GWT).

IB>А вы не грамотные что ли? =)

Не особо.

Здравствуйте, IB, Вы писали:

WF>> При этом эти OS библиотеки и фреймворки, как правило, по качеству гораздо лучше того, что делаем мы сами.
IB>Меня терзают смутные сомненья. Сколько OS фреймворков не видел, в большинстве случаев качество ниже плинтуса и никто ни за что не отвечает.

я так понимаю смотрели нетовские ос фреймворки? это ли не еше одно подтверждение словам Cyberax-а, что "в Java предпочитают более красивые и стройные решения, а в .NET — по большей части то, что легко использовать 90% новичков"?

Здравствуйте, goorov, Вы писали:

G>я так понимаю смотрели нетовские ос фреймворки?
Не правильно понимаешь, именно явовские и их тупые порты на .Net =)

G>это ли не еше одно подтверждение словам Cyberax-а,
Это еще одно подверждение того, что вся явовская "красивость" на поверку оказывается редкостной кривизны конструкцией..

Здравствуйте, IB, Вы писали:

G>>я так понимаю смотрели нетовские ос фреймворки?
IB>Не правильно понимаешь, именно явовские и их тупые порты на .Net =)

G>>это ли не еше одно подтверждение словам Cyberax-а,
IB>Это еще одно подверждение того, что вся явовская "красивость" на поверку оказывается редкостной кривизны конструкцией..

короче, имена в студию — какие конкретно библиотеки и фреймворки, что не устраивает и т.д., а то все твои посты до текущего момента мягко говоря выглядят неадекватно

Здравствуйте, goorov, Вы писали:

G> а то все твои посты до текущего момента мягко говоря выглядят неадекватно
Вот именно, начиная с поста про красивость архитектуры явовских компонент и некрасивость .net-овских.

Здравствуйте, Cyberax, Вы писали:

C>А case-типы так вполне нормально использоваться могут, просто как обычные типы. Посмотри во что они компилируются.

C>1) Имеем:
C>

C>abstract class Node
C>case class Leaf(name: String) extends Node
C>case class Middle(name: String, left: Node, right: Node) extends Node
C>

C>2) В скомпилированом виде (часть кода вырезана):
C>

<Skipped>
C>

C>То есть, вполне обычные классы, которые можно вполне нормально использовать из Java. Где тут непеодолимые преграды?

Это понятно, в АТД Немерле кажется тоже примерно в такое компилируется. Но дело то вот в чем, АТД без паттерн-матчинга по сути бесполезны. Мне например в голову use cases АТД приходят только в сочетании с паттерн-матчингом, а без оного, я себе плохо представляю, какие можно получить выигрышы от использования АТД.

Здравствуйте, yumi, Вы писали:

Y>Это понятно, в АТД Немерле кажется тоже примерно в такое компилируется. Но дело то вот в чем, АТД без паттерн-матчинга по сути бесполезны. Мне например в голову use cases АТД приходят только в сочетании с паттерн-матчингом, а без оного, я себе плохо представляю, какие можно получить выигрышы от использования АТД.
Оно нужно для ситуации, когда надо создать параметры и вызвать какую-то Скалистую функцию с ними. Или что-то сделать из Java-кода с возвращённым результатом.

А больше ничего особого от них и не нужно. Разве что, ещё бы пригодилась возможность создавать свои case-классы на Java...

Здравствуйте, Erop, Вы писали:

C>>Фиксим зависимость и делаем для неё override. Примерно так:
E>А если всё-таки вернуться к ситуации, когда библиотеки проприетарные и код их не доступен, а редестрибуция своих версий невозможна?
Надо добавить: сидим в танке, Инета нет, компьютеров тоже.

E>Ты же в этих условиях все эти фичи заюзать советуешь, или ты всё только о мире OS говоришь?
А почему нет? Тут Maven, правда, поможет только тем, что структурирует свалку зависимостей.

Ну и опять же — в мире Java большая часть нормальных вещей как раз открытая.

E>Правда править чужую непростую либу я и сам не хотел бы, безотносительно к лицензиям. Вот, скажем, есть такая распознавалка "клинопись", у неё есть тулкит. Работает нестабильно. Отлаживать я бы не взялся, даже при доступных исходниках...
Это уже другой вопрос.

C>>На практике, багов с зависимостями в рантайме у меня пока (к счастью) не было.
E>Ну и хорошо. Хотя это для меня странно. А у тебя какой цикл разработки (сколько времени между версиями проходит). У наукоёмкого софта это годы...
У меня это дни. У нас сервис, в который мы непрерывно добавляем улучшения по просьбам клиентов. С наукоёмким софтом тоже разницы особой нет.

Здравствуйте, Erop, Вы писали:

C>>Ну так а что делать, если эти зависимости реально нужны? Основной другой вариант — свалить всё в кучу и молиться, чтоб работало.
E>Что значит "реально нужны"? Обычно смежники дороже разработчиков обходятся...
Вот мне нужен движок правил. Я взял и подключил DRools (JBoss Rules) — и оно всё работает. Руками писать аналог — месяцы труда.

Или, к примеру, Hibernate — это ORM. Там тоже руками писать месяцы работы.

C>>У нас пока ещё не очень. В приватном репозитории лежат, в основном, только несколько чисто утиллитных проектов. Но к этому движется, да.
E>Ну когда стаент всё так "хорошо" поделишься опытом управления этим зоопарком и механизмами разрешения конфликтов интересов...
"Чукча не дурак, чукча умный" (c) анекдот. Я сначала посмотрел как там проект JBoss с Maven'ом живёт — у них что-то около 30 подпроектов. Ничего, вполне так нормально всё.

Erop wrote:

> Хотя мне вот тоже кажется, что вся методология работы с Мавином
> построена на том, что библиотеки намного лучше реализованы, чем
> прикладной код...
В .net-мире обычно если что-то вдруг потребовалось относительно распространённое, то либо пишется велосипед (возможно копипастом опубликованных исходников), либо ждется благодать от майкрософт, чтобы в фраймворк включили, либо покупается сторонняя либа и добавляется в зависимости.

В maven — добавляется пару xml-тегов в списках зависимостей.

Это, конечно, не ново, самое старое что я могу припомнить это перл с его "ppm install SuperLib", но это было не столь удобно...

Здравствуйте, IB, Вы писали:

WF>> При этом эти OS библиотеки и фреймворки, как правило, по качеству гораздо лучше того, что делаем мы сами.
IB>Меня терзают смутные сомненья. Сколько OS фреймворков не видел, в большинстве случаев качество ниже плинтуса и никто ни за что не отвечает.
Где ты такие находишь?

Посмотри на Eclipse RCP, GWT, например, на досуге.

WF>> Просто потому что их использует масса народу, включая монстров типа IBM.
IB>Обожемой, это первый признак того, что ни в коем случае использовать это нельзя..
То-то Eclipse сейчас постепенно превращается в основную IDE для кучи языков.

WF>>Либо они написаны грамотными разработчиками (тот же GWT).
IB>А вы не грамотные что ли? =)
С чего ты делаешь такой вывод?

Здравствуйте, ., Вы писали:

.>В .net-мире обычно если что-то вдруг потребовалось относительно распространённое, то либо пишется велосипед (возможно копипастом опубликованных исходников), либо ждется благодать от майкрософт, чтобы в фраймворк включили, либо покупается сторонняя либа и добавляется в зависимости.

.>В maven — добавляется пару xml-тегов в списках зависимостей.

А при чём тут стройность архитектур? Это всего лишь разный подход к лицензиям на софт. Инструмент типа Мавена в мире пончиков не особо востребован, только и всего

Здравствуйте, Cyberax, Вы писали:

E>>А если всё-таки вернуться к ситуации, когда библиотеки проприетарные и код их не доступен, а редестрибуция своих версий невозможна?
C>Надо добавить: сидим в танке, Инета нет, компьютеров тоже.
При чём тут танк? Ты не встречал проприетарные продукты вообще не содержащиен ни строчки GPL кода?

E>>Ты же в этих условиях все эти фичи заюзать советуешь, или ты всё только о мире OS говоришь?
C>А почему нет? Тут Maven, правда, поможет только тем, что структурирует свалку зависимостей.
Потому, что свалка такая дорого очень обойдётся...

C>Ну и опять же — в мире Java большая часть нормальных вещей как раз открытая.
Ну открытый и проприетарный софт -- это две схемы финансирования разработок. Обе, IMHO, имеют право на существование. При этом для каждой схемы органичны разные стратегии использования библиотек и вообще кода смежников...

C>Это уже другой вопрос.
Почему другой? Очень даже не другой. Сложную юиюлиотеку ты всё равно поддержать хорошо не смоежшь, а простую не так уж сложно заменить и своим кодом...

C>>>На практике, багов с зависимостями в рантайме у меня пока (к счастью) не было.
E>>Ну и хорошо. Хотя это для меня странно. А у тебя какой цикл разработки (сколько времени между версиями проходит). У наукоёмкого софта это годы...
C>У меня это дни. У нас сервис, в который мы непрерывно добавляем улучшения по просьбам клиентов. С наукоёмким софтом тоже разницы особой нет.

У наукоёмкого софта цикл разработки от года обычно (раньше просто не сойдётся программы эксперементов), соответсвенно каждая версия независимо поддерживается несколько лет...
Когда цикл -- пара недель, то конечно расклады совсем другие...

Здравствуйте, Erop, Вы писали:

C>>Надо добавить: сидим в танке, Инета нет, компьютеров тоже.
E>При чём тут танк? Ты не встречал проприетарные продукты вообще не содержащиен ни строчки GPL кода?
Запросто, в моём проекте на GPL ни одной строчки нет (но есть другие лицензии).

C>>А почему нет? Тут Maven, правда, поможет только тем, что структурирует свалку зависимостей.
E>Потому, что свалка такая дорого очень обойдётся...
Что именно "дорого"?

C>>Это уже другой вопрос.
E>Почему другой? Очень даже не другой. Сложную юиюлиотеку ты всё равно поддержать хорошо не смоежшь, а простую не так уж сложно заменить и своим кодом...
Запросто смогу. Мои патчи в нескольких достаточно сложных проектах. Опять же, никто не мешает купить саппорт, если очень уж так хочется.

C>>У меня это дни. У нас сервис, в который мы непрерывно добавляем улучшения по просьбам клиентов. С наукоёмким софтом тоже разницы особой нет.
E>У наукоёмкого софта цикл разработки от года обычно (раньше просто не сойдётся программы эксперементов), соответсвенно каждая версия независимо поддерживается несколько лет...
И что это меняет?

Erop wrote:

> .>В maven — добавляется пару xml-тегов в списках зависимостей.
> А при чём тут стройность архитектур? Это всего лишь разный подход к
> лицензиям на софт. Инструмент типа Мавена в мире пончиков не особо
> востребован, только и всего
Кибер сказал

Автор: Cyberax
Дата: 05.06.08

, что лицензии поддерживаются мавеном.

Здравствуйте, Cyberax, Вы писали:

C>Запросто, в моём проекте на GPL ни одной строчки нет (но есть другие лицензии).
Ну и зачем ты прикалываешься? Я говорю о проектах, в которых используются проприетарные библиотеки, а не открытый код.

E>>Потому, что свалка такая дорого очень обойдётся...
C>Что именно "дорого"?
Дорого обойдётся управление всеми этими бизнес-связями.

C>Запросто смогу. Мои патчи в нескольких достаточно сложных проектах. Опять же, никто не мешает купить саппорт, если очень уж так хочется.
Ну вот представь себе библиотеку, которая делает китайскую сегментацию, или распознавание речи или ещё что-то такое, что ты сделать не сможешь. И надо тебе, например, добавить сунскоий даилект. И что ты будешт делать?

E>>У наукоёмкого софта цикл разработки от года обычно (раньше просто не сойдётся программы эксперементов), соответсвенно каждая версия независимо поддерживается несколько лет...
C>И что это меняет?
Бизнеспроцессы меняет очень. В частности саппорт меняет.

Здравствуйте, ., Вы писали:

.>Кибер сказал

Автор: Cyberax
Дата: 05.06.08

, что лицензии поддерживаются мавеном.
А толку-то? Договор о лицензировании тоже мавен заключит? И о редистрибуции? И запросы на поддержку нужному провайдеру перенаправит, ну и деньги конечно, тоже мавен заплатит за это всё смежникам?

Здравствуйте, Erop, Вы писали:

.>>Кибер сказал

Автор: Cyberax
Дата: 05.06.08

, что лицензии поддерживаются мавеном.
E>А толку-то? Договор о лицензировании тоже мавен заключит? И о редистрибуции? И запросы на поддержку нужному провайдеру перенаправит, ну и деньги конечно, тоже мавен заплатит за это всё смежникам?
Понятно, что так просто Maven ничего не сделает. Однако, когда договор заключен, NDA подписаны, девелоперские места проплачены — он как раз может помочь в учёте всего этого. Так как явно выделяет зависимости, и ты случайно не воткнёшь её в проект, на который лицензия не распространяется.

Здравствуйте, Erop, Вы писали:

C>>Запросто, в моём проекте на GPL ни одной строчки нет (но есть другие лицензии).
E>Ну и зачем ты прикалываешься? Я говорю о проектах, в которых используются проприетарные библиотеки, а не открытый код.
Проприетарные библиотеки ничем особым от всех других технически не отличаются.

C>>Что именно "дорого"?
E>Дорого обойдётся управление всеми этими бизнес-связями.
А собственное написание всего — ещё дороже.

C>>Запросто смогу. Мои патчи в нескольких достаточно сложных проектах. Опять же, никто не мешает купить саппорт, если очень уж так хочется.
E>Ну вот представь себе библиотеку, которая делает китайскую сегментацию, или распознавание речи или ещё что-то такое, что ты сделать не сможешь. И надо тебе, например, добавить сунскоий даилект. И что ты будешт делать?
Найму китайца, чтоб поддерживал. Или куплю официальный саппорт. Тут, собственно, тоже к открытости/закрытости/Maven'у ничего не относится.

C>>И что это меняет?
E>Бизнеспроцессы меняет очень. В частности саппорт меняет.
С точки зрения системы сборки?