Почему новые программы на Яве пишутся "с нуля", именно как standalone-приложения, а не оформляются в виде плагинов к какой-ниудб системе, тому же Eclipse? Вот написали JEdit. А зачем? Ведь есть тот же Eclipse, где уже есть готовый тектовый редактор. Если есть какие-то суперпрогрессивные идеи по организации текстового редактора, почему бы не написать его именно как плагин к Eclipse? Почему бы не написать браузер или офисный пакет как набор плагинов к Eclipse? Что этому мешает.
Я не фанат Eclipse и Java. Просто интересно, почему если есть возможность сэкономить время, люди её не пользуются? Может, есть что-то что Eclipse сделать не в состоянии. Или он слишком тормозной? А если бы был аналог Eclipse для .NET, писали бы дотнетчики для него плагины? Скажем, был бы RSDN@Home плагином к некому "Eclipse.NET", или всё-таки отдельным приложением?
Какие существуют подобные платформы? Почему они не так широко используются разработчиками?
Прошу не бросаться во флейм и не ставить смайликов и минусов, а просто ответить на "почему". Заметьте, что я говорю об Eclipse не как об IDE, а как о некотором каркасе, на базе которого можно строить свои приложения.
Здравствуйте, konsoletyper, Вы писали:
K>Почему новые программы на Яве пишутся "с нуля", именно как standalone-приложения, а не оформляются в виде плагинов к какой-ниудб системе, тому же Eclipse? Вот написали JEdit. А зачем? Ведь есть тот же Eclipse, где уже есть готовый тектовый редактор. Если есть какие-то суперпрогрессивные идеи по организации текстового редактора, почему бы не написать его именно как плагин к Eclipse? Почему бы не написать браузер или офисный пакет как набор плагинов к Eclipse? Что этому мешает.
Независимое приложение проще написать. С эклипсом надо предварительно разобраться, а документации не особо много. Плюс к тому же, он немного тормознутый, а для некоторых это критерий.
K>Я не фанат Eclipse и Java. Просто интересно, почему если есть возможность сэкономить время, люди её не пользуются? Может, есть что-то что Eclipse сделать не в состоянии. Или он слишком тормозной? А если бы был аналог Eclipse для .NET, писали бы дотнетчики для него плагины? Скажем, был бы RSDN@Home плагином к некому "Eclipse.NET", или всё-таки отдельным приложением?
Янус к плагинам ни коим боком не относится. Эклипс — среда для разработки, и он заточен на это, и архитектура его больше подходит для редактирования и организации текстовых документов, а не форумов.
K>Какие существуют подобные платформы? Почему они не так широко используются разработчиками?
Платформа — широкое понятие. На самом деле можно выделить несколько уровней платформ, приведу на примере эклипса:
1. Железячная платформа (проц + память + остальные приблуды).
2. Операционная система (платформа над железом, облегчающая программировать за счет того, что не надо думать про машинные коды, прерывания и т.п.)
3. Ява (высокоуровневая платформа, позволяющая программировать не думаю о ресурсах и низкоуровневой реализации API).
4. Эклипс (платформа еще более высокого уровня, позволяющая пользовать его супер-высокоуровневым АПИ для конкретных задач )
Каждый выбирает сам тот уровень, на котором ему проще и удобней писать.
[skip]
N>Каждый выбирает сам тот уровень, на котором ему проще и удобней писать.
С данным тезисом согласен. Однако глядя на засилие текстовых редакторов, файл-менеджеров, браузеров и т.д, которые написаны с нуля (многие поддерживают плагины, причём плагины для них так и не пишутся), я удивляюсь: каким же образом люди выбирают платформу?
Давайте рассмотрим конкретный пример. Есть три программиста: A, B, C. A пишет новый навороченный xml-редактор. B пишет тектовый процессор, который сохраняет документы в новом открытом формате. Наконец, С пишет редактор uml-диаграмм с поддержкой печати.
Теперь некто (D) использовал текстовый процессор, написанный B и заметил, что новый открытый формат документов, если документ написан по определённому шаблону, неплохо конвертируется в XHTML, и наоборот. Соотвественно, D решил написать браузер + редактор XHTML.
Пусть все они работают по стандартной схеме: каждый пишет приложение с нуля. Появляется три незваисимых программных продукта. Вероятно, каждый из них предоставит dll-ку со своими контролами и документацию к ним. Тогда D останется взять компоненты (XmlEditor, DocumentEditor, PrintController; UmlEditor ему не понадобится), прочитать документацию, заставить их работать вместе. Причём, ему придётся правильно реагировать на нажатие кнопки "Вырезать" — перенаправлять обращение к открытому в данный момента окну с одним из двух компонентов. Или, скажем, A предусмотрел навигацию в виде докающегося окна (view) с изображением DOM-дерева и D оценил идею. Т.е. D должен явно создать view, прилепить на него нужный контрол, к нему в свою очередь контекстное меню и заставить всё это нормально работать.
Пусть теперь кадлый решил делать всё это как плагин к некоторой платформе наподобие Eclipse, не обязательно заточенной под написание программ. Тогда A, B и C пишут плагины. Причём, они могут написать по несколько плагинов, например C пишет плагины: для поддержки редакторов диаграмм вообще, редактор UML, менеджер печати, плагин для печати на принтер, плагин для печати в PrintPreview. Каждый делает пакет из плагионов, приложение. Тогда D остаётся отобрать нужные плагины из приложений A, B, C, правильно их связать, может быть, написать свой плагин (для поддержки загрузки документов по HTTP) и выложить всё это как приложение "Браузер + XHTML редактор". Все нужные фичи из приложений A, B и C получаются автоматом. В результате D просто сэкономил своё время, причём исключил написание весьма однообразного кода.
Так вот меня интересует вопрос: почему первый подход сейчас распространён гораздо меньше второго? Почему не понаписано платформ, заточенных под решение целых классов крупных задач, или хотя бы того класса, который я описал?
K>Так вот меня интересует вопрос: почему первый подход сейчас распространён гораздо меньше второго? Почему не понаписано платформ, заточенных под решение целых классов крупных задач, или хотя бы того класса, который я описал?
А ответ тривиален
1. Если A и B распространяют свои продукты под знаком GPL и D работает над коммерческим продуктом, и при этом A и B ни в какую не хотят менять условия лицензирования, то D, воспользовавшись их кодом просто не может позиционировать свой проект как коммереческий.
В то же время C написал коммереческий продукт, а у D просто нет желания/времени/финансовых возможностей для согласования условий лицензирования использования частей проекта C в своём проекте.
На самом деле, зачастую легче написать с нуля, чем решить проблемы именно такого уровня, котороы у непосредственно написанию кода никакого отношения не имеют.
Здравствуйте, supersceev, Вы писали:
K>>Так вот меня интересует вопрос: почему первый подход сейчас распространён гораздо меньше второго? Почему не понаписано платформ, заточенных под решение целых классов крупных задач, или хотя бы того класса, который я описал?
S>А ответ тривиален S>1. Если A и B распространяют свои продукты под знаком GPL и D работает над коммерческим продуктом, и при этом A и B ни в какую не хотят менять условия лицензирования, то D, воспользовавшись их кодом просто не может позиционировать свой проект как коммереческий. S>В то же время C написал коммереческий продукт, а у D просто нет желания/времени/финансовых возможностей для согласования условий лицензирования использования частей проекта C в своём проекте. S>На самом деле, зачастую легче написать с нуля, чем решить проблемы именно такого уровня, котороы у непосредственно написанию кода никакого отношения не имеют.
Это понятно. Но и чтобы использовать первый подход, D всё равно должен согласовывать условия соглашения.
Допустим, D нашёл деньги, чтобы купить продукцию A, B и C (либо все четверо работают по GPL). Тогда D будет невыгоден первый путь. Особенно странно это выглядит в мире OpenSource, где проблем с лицензированием быть не должно.
Кроме того, D — некоторая абстракция (в отличие от A, B и C) . Я говорил лишь о том, что найдётся такой D. Т.е. если у D1 есть идея, но нет возможностей, то всегда найдётся Dk, у которого есть и то и другое. Но подход No.1 не способствует появлению таких D.
Ещё при подходе No.2 можно творить чудеса с редакциями. Например, не выгодно продавать штампованный продукт на все случаи жизни. И потому менеджмент решает выпустить кучу Edition'ов для разных целевых групп. Естественно сделать "плагинистую" архитектуру, и в каждую редакцию включать только необходимый набор плагинов (как с VS). Только зачем для каждого продукта делать собственную модульную архитектуру? Не проще взять готовое решение? Если бы MS это было нужно и они чуть-чуть напряглись, то был бы "лысый" VS, совершенно бесплатный (т.к. непонятно, за что же там платить). Но есть по крайней мере две причины, по которым этого не будет: нежелаение MS и кривоватость архитектуры VS. Но у тех же IBM есть Eclipse. И у них нет причин тормозить написание плагинов мастерами-умельцами. Так что-же их тормозит, этих мастеров-умельцев?
Здравствуйте, konsoletyper, Вы писали:
K>Так вот меня интересует вопрос: почему первый подход сейчас распространён гораздо меньше второго? Почему не понаписано платформ, заточенных под решение целых классов крупных задач, или хотя бы того класса, который я описал?
Ну почему же? Ява и дотнет и являются такими платформами общеуниверсального назначения. Более того, во многих областях есть свои крупные платформы. Единственное, они малоизвестны, т.к. стоят обычно немало денег.
Вот, например, тот же продукт IBM — Lotus Notes. Мощнейшая платформа с возможностью расширения. Она заточена под документооборот, но при этом настолько наворачивается, что на ней можно решать большой круг задач. Однако вход в программирование на этой платформе довольно-таки высокий, а чтобы разобраться в ней досконально, понадобится несколько месяцев.
Во многих других областях есть свои платформы, как например, та же Галактика или Парус для бухгалтерии. Про 1С я лучше промолчу, тут просто сделал свое дело пиар и поддержка государства.
Здравствуйте, konsoletyper, Вы писали:
K>Ещё при подходе No.2 можно творить чудеса с редакциями. Например, не выгодно продавать штампованный продукт на все случаи жизни. И потому менеджмент решает выпустить кучу Edition'ов для разных целевых групп. Естественно сделать "плагинистую" архитектуру, и в каждую редакцию включать только необходимый набор плагинов (как с VS). Только зачем для каждого продукта делать собственную модульную архитектуру? Не проще взять готовое решение? Если бы MS это было нужно и они чуть-чуть напряглись, то был бы "лысый" VS, совершенно бесплатный (т.к. непонятно, за что же там платить). Но есть по крайней мере две причины, по которым этого не будет: нежелаение MS и кривоватость архитектуры VS. Но у тех же IBM есть Eclipse. И у них нет причин тормозить написание плагинов мастерами-умельцами. Так что-же их тормозит, этих мастеров-умельцев?
Я в свое время не захотел связываться с Эклипсом из-за его громоздкой архитектуры и кривоватости — он частенько спотыкался на обычных вещах. Не говорю уж про Яву, которая только к версии 1.5 стала более или менее удобоварима. Не спорю, сейчас возможно Эклипс несложно расширять и проще писать, но поезд ушел.
Здравствуйте, Nuald, Вы писали:
N>Независимое приложение проще написать. С эклипсом надо предварительно разобраться, а документации не особо много. Плюс к тому же, он немного тормознутый, а для некоторых это критерий.
Во-первых, для написания модуля расширения к Eclipse документации вполне достаточно на http://eclipse.org. Во-вторых, медленный в сравнении с чем? У меня Eclipse 3.2 примерно раз в 5 быстрее загружается (выгружается), чем MS Visual Studio 2005.
N>Янус к плагинам ни коим боком не относится. Эклипс — среда для разработки, и он заточен на это, и архитектура его больше подходит для редактирования и организации текстовых документов, а не форумов.
И опять неправда.
Eclipse начинался с Eclipse SDK (Java IDE), но теперь это группа проектов с общей модульной архитектурой. Это Eclipse Platform, Eclipse RCP, Eclipse RIA и т.п. — взгляните http://www.eclipse.org/downloads/index_topic.php
Янус вполне мог быть Eclipse RCP.
DAS> Reuse-in-the-small (libraries of subroutines) began nearly 50 years ago and is a well-solved problem.
DAS> Fact 16
DAS> Reuse-in-the-large (components) remains a mostly unsolved problem, even though everyone agrees it is important and desirable.
DAS> (Facts and Fallacies of Software Engineering By Robert L. Glass)
Ну, надо за решение этой проблемы бороться. Есть Эклипс, но на нём белый свет клином не сошёлся. Можно и лучше. Что-то я не вижу, чтобы кто-то в этом деле волонтёрствовал или пионерствовал. А надо бы! По крайней мере, стоило бы активно пользоваться существующими фреймворками, чтобы был мотив совершенствовать их.
Здравствуйте, konsoletyper, Вы писали:
K>Ну, надо за решение этой проблемы бороться.
Тогда, вот примерное направление:
Fact 17
Reuse-in-the-large works best in families of related systems and thus is domain-dependent. This narrows the potential applicability of reuse-in-the-large.
Здравствуйте, rsn81, Вы писали:
R>Во-первых, для написания модуля расширения к Eclipse документации вполне достаточно на http://eclipse.org. Во-вторых, медленный в сравнении с чем? У меня Eclipse 3.2 примерно раз в 5 быстрее загружается (выгружается), чем MS Visual Studio 2005.
Хм, кому-то и явадоки нравятся, но по мне MSDN лучше. Может, конечно, это сила привычки, но тут уж ничего не поделаешь. Эклипс может и загружается/выгружается быстрее чем VS, однако с большими проектами с сотней файлов и больше работает медленно. Но 3.2 не видел, возможно, сейчас все поменялось, спорить не буду.
R>Eclipse начинался с Eclipse SDK (Java IDE), но теперь это группа проектов с общей модульной архитектурой. Это Eclipse Platform, Eclipse RCP, Eclipse RIA и т.п. — взгляните http://www.eclipse.org/downloads/index_topic.php R>Янус вполне мог быть Eclipse RCP.
Мог, но вопрос к его создателям. Эклипс не идеал, и студия не идеал, однако поработав с некоторым количеством такого рода платформ, пришел к мнению, что лучше что-то более низкоуровневое, как тот же дотнет и ява, т.к. они дают большую гибкость. Но это мое личное ИМХО, и я бы уже никогда в жизни не выбрал бы какого-рода Эклипс за базовую платформу, т.к. знаю цену поддержки такого — когда приходится отвечать за глюки не только твоего софта, но и платформы.
Здравствуйте, rsn81, Вы писали:
R>Во-первых, для написания модуля расширения к Eclipse документации вполне достаточно на http://eclipse.org. Во-вторых, медленный в сравнении с чем? У меня Eclipse 3.2 примерно раз в 5 быстрее загружается (выгружается), чем MS Visual Studio 2005.
Если работа заключается в загрузке (выгрузке) IDE, то Eclipse явно проигрывает...
Здравствуйте, Nuald, Вы писали:
N>С эклипсом надо предварительно разобраться, а документации не особо много.
... N>Хм, кому-то и явадоки нравятся, но по мне MSDN лучше.
Вот вы с самого начала так и пишите: "в MSDN документации по эклипс не особо сного".
Здравствуйте, boluba, Вы писали:
B>Вот вы с самого начала так и пишите: "в MSDN документации по эклипс не особо сного".
Хм, ничего не понял. Это была какая-то тонкая шутка? MSDN и Eclipse никак не связаны, я говорил, что так как он на яве, то его документация — это в основном явадоки, которые мне не очень нравятся.
Здравствуйте, Nuald, Вы писали:
N>Хм, кому-то и явадоки нравятся, но по мне MSDN лучше. Может, конечно, это сила привычки, но тут уж ничего не поделаешь.
По-крайней мере Sun не поленился сделать генератор докуменации по javadoc исходного кода. Недоумение вызвало XML-комментирование исходного кода .NET. Вроде как, вам надо, вы пишите генератор программной документации; есть конечно сторонние разработки по генерации документации...
N> Эклипс может и загружается/выгружается быстрее чем VS, однако с большими проектами с сотней файлов и больше работает медленно.
Это не так.
N> Но 3.2 не видел, возможно, сейчас все поменялось, спорить не буду.
Поверьте, я бы не стал утверждать сказанное выше, если бы не занимался одновременной разработкой в обоих упомянутых программных платформах — обоих последней версии.
N>Мог, но вопрос к его создателям. Эклипс не идеал, и студия не идеал, однако поработав с некоторым количеством такого рода платформ, пришел к мнению, что лучше что-то более низкоуровневое, как тот же дотнет и ява, т.к. они дают большую гибкость.
Речь идет ведь только про упрощение процесса программирования графики и наиболее часто встречающихся примитивов. В случае Eclipse RCP разработчик избавляется от целого класса оформительских проблем, что позволяет больше времени уделить написанию именно бизнес-логики приложения. Последнее пишется на, так названном вами — низкоуровневом программировании.
N> Но это мое личное ИМХО, и я бы уже никогда в жизни не выбрал бы какого-рода Эклипс за базовую платформу, т.к. знаю цену поддержки такого — когда приходится отвечать за глюки не только твоего софта, но и платформы.
И зря, зачем писать то, что уже написано, притом по умолчанию лучше, нежели сделаешь сам? Успешно внедрил три проекта на Ecpise RCP (первый с полтора года назад, последний в начале года), особенных проблем не встретил.
Здравствуйте, rsn81, Вы писали:
R>И зря, зачем писать то, что уже написано, притом по умолчанию лучше, нежели сделаешь сам? Успешно внедрил три проекта на Ecpise RCP (первый с полтора года назад, последний в начале года), особенных проблем не встретил.
Почему по умолчанию лучше? Неужели команда высоквалифицированных разработчиков не сможет в приемлимые сроки написать аналог Эклипса? Что-то верится с трудом. Взять хотя бы тот же JetBrains.
Полтора года — это не срок. Я говорю про системы, которым больше пяти лет, которые необходимо постоянно сопровождать и наращивать, и когда начинаешь упираться в ограничения платформы или ее глюки, это не особо радует. Впрочем, не буду говорить конкретно про Эклипс — у него может все хорошо.
)
