В сообщении от Friday 11 January 2008 13:32:03 Kirill A. Korinskiy написал(а): > Alexey Pechnikov -> debian-russian@lists.debian.org @ Thu, 10 Jan 2008 > 22:45:53 +0300: > > AP> Прикручивание томкатов с апачами и нужными библиотеками и классами > доступа к AP> БД (и указание их параметров) иначе назвать не могу. > > Ужас. Надругательство. Конечно. > > Для разработки и отладки я использую intellij idea и оттуда стартую tomcat.
Я использую nano или редактор в mc. Как-то оттуда не очень удобно томкат запускать. Использование всяческих сред разработки и т.п. дело сугубо личное, но они далеко не всем нужны и совсем никуда не годится, если без них нельзя обойтись. > Для установки приложения я делаю deb'ы. Ужас, правда? Да, ужас. Ставим опенофис и открытую яву. Открываем xml-документ m$ office и все висит. Оказывается, надо ставить сановскую яву. С ней xslt-процессинг на яве чуть лучше, но большой документ тоже не открыть. И что в этом хорошего? > Вот тут появляется действительно минус явы. Можно распространять софт без > исходника. > > Хотя есть jad… Беда в том, что открытые компоненты зачастую используют закрытые. И если из многообразия софта на яве выкинуть весь тот, что пользуется закрытыми компонентами, картина становится печальной. Притом разработчики зачастую и выбирают яву в целях спрятать исходные коды, так что ситуация меняться не будет. > 1) Иногда OO парадигма удобна. Иногда. В тикле есть ресколько ОО-реализаций, выбирайте. > 2) Список генерировать намного, намного проще. Вы просто не работали с > lisp. Тикль работает со списками, взяв эту идею из лиспа. Попробуйте. Методологии "все есть список" и "все есть строка" отнюдь не противоречивы. > AP> А вы себе представляете стоимость модернизации и поддержки такого > решения? При AP> достаточно длительном жизненном цикле продукта затраты на > создание становятся AP> много меньше затрат на адаптацию и разработку > модулей. > > С такой логикой можно отказаться и от db, а перейти на написание своей. > Правда? > > AP> Умея писать серверный код на ява, вы не напишите на той же яве > программу AP> для КПК. > > Почему? Потому что нет разработки, а есть использование компонентов. На сервере вы работаете с совершенно другими компонентами. Это как вижуал бейсик - сам язык настолько слаб, что без сторонних расширений (com-объекты, activex) ничего не умеет. Ява в этом отношении получше, но тоже требует множества чужого кода. Я не против повторного использования кода, но _модульного_ кода, где нет зависимости от десятков различных классов (а то и еще хуже - конкретной их реализации). В принципе, это все следствие закрытости многих компонентов, когда приходится писать тучи оберток, но зачем такие проблемы себе создавать, выбирая яву. > Хм. А слабо на tcl да с web camera подключаемая по usb на macosx? В винде пробовал три способа, сейчас работаю через directx, поскольку самый переносимый способ (directx какой-нибудь версии есть во всех виндах). Так что при наличии драйвера для мака сделать можно, вопрос лишь в том, как добиться совместимости со всеми версиями ОС. Но не имея машины с MacOS не возьмусь. > > AP> К примеру, набор тиклевских функций для создания файлов в формате ms > AP> excel 2003 xml имеет размер в несколько килобайт и не имеет никаких > AP> зависимостей, что позволяет его использовать с любым интерпретатором > AP> тикля (в том числе, с написанным на ява интерпретатором). > > А в java есть native код для создания xsl файлов… Тоже без зависимостей. > Весит jar не много. jar это архив, еще бы он весил много. Это открытый компонент? > А в xml от офиса есть огранечение на обьем. Т.е. не огранечение а > достаточно большой xml он просто не откроет. Или съест столько памяти, что > лучше вешаться. Файлы в десятки тысяч записей клиенты свободно открывают в m$ office и виндовом openoffice. Линуксовый опенофис вешается (на мощном компе) при попытке открыть файл с сотней записей. Я просто восхищен переносимостью решений на ява. P.S. Опенофис на платформе arm есть, но... где бы взять сановскую яву для arm, а с другой явой нормально не работает? Интерпретатор tcl для arm есть, и не один. java-шелл можете назвать? В tclsh работать удобно, очень удобно. Если попробуете софтину на яве запустить на linksys nslu2 узнаете, насколько ява тормозная и сколько ресурсов жрет (тикль, перл, питон там нормально работают). Попробуйте воспользоваться явой, удалив все библиотеки. Годится на что-нибудь? Думаю, нет. Вот и приходится таскать огромные наборы библиотек, и то с ними "каши не сваришь" - приходится искать дополнительные компоненты. В итоге установленный в системе объем кода ява становится все больше, поддержка этого безобразия заморочной, а быстродействие... лучше и не вспоминать. Посмотрите программы для ГИС, сделанные на ява (в том числе обертки для mapserver) - размером в десятки мегов! А если возьмете исходники mapserver, там есть несколько тиклевских утилит (не помню, занимают килобайты или десятки килобайт), работающих с тем же движком на С. P.P.S. Имхо, для открытого софта ява не пригодна, для проприетарного годится только тогда, когда надо закрыть исходники (любой ценой, даже много теряя в качестве софта и делая разработку намного дороже), но нет желания/возможности писать на С.
