Re: контейнеры
В сообщении от 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. Имхо, для открытого софта ява не пригодна, для проприетарного годится
только тогда, когда надо закрыть исходники (любой ценой, даже много теряя в
качестве софта и делая разработку намного дороже), но нет желания/возможности
писать на С.
Reply to: