Re: контейнеры
В сообщении от Thursday 10 January 2008 18:38:18 Kirill A. Korinskiy
написал(а):
> Alexey Pechnikov -> debian-russian@lists.debian.org @ Thu, 10 Jan 2008
> 14:25:56 +0300:
>
> Позволите кусками, да?
>
> AP> Ява требует надругательства над системой, куда ставится, не сравнить с
> AP> установкой интерпретатора tcl, perl, python и т.п.
>
> Что-то я не заметил особых надругательств над системой при установки deb
> пакета из репозитория. Честно.
Прикручивание томкатов с апачами и нужными библиотеками и классами доступа к
БД (и указание их параметров) иначе назвать не могу.
>
> AP> Огромное преимущество явы - наличие "продвинутых" серверов приложений
> AP> сегодня уже не актуально - для всех языков они есть.
>
> Гм. А есть application server уровня jboss для tcl? А что-то подобное gwt
> для python? Мне вот не известно.
AOL Web server. Я про него уже упоминал. Смотрите платформу OpenACS (мне и
она показалась монстром, но кое-какие идеи оттуда чрезвычайно полезны).
> AP> Высокие требования к ресурсам,
>
> Хм. Спорное утверждение, честно.
>
> То что программисты на яве, в большинстве своем не умеют писать, так это не
> проблема. Сейчас программисты вообще не особо умеют писать. Просто других
> слов уже нет.
Интерпретатор тикль на КПК (etcl) вместе с огромным набором библиотек "весит"
несколько мегабайт и представляет собой один бинарь (так же, как под линукс
или виндоус или макос). После запуска библиотеки доступны в виртуальной ФС,
что позволяет с ними комфортно работать (упаковка классов ява малость
отличается... не в лучшую сторону). В результате закрытости базовых библиотек
и для быстроты разработки при открытости этих библиотек над ними громоздятся
наслоения очередных классов, что вовсе не идет на пользу. Ну и то, что
разработчики используемых вами классов не умеют писать код мне тоже не
кажется достоинством технологии.
> AP> множество малосовместимых реализаций (тикль один и тот же хоть на
> AP> сервере, хоть на виндовом КПК, а ява - разная).
>
> Угу, много. j2me, j2se, j2ee. Причем первая уже умерла т.к. на
> телефонах/кпк можно запускать se.
На первой, которую вы назвали умершей, написана туча приложений, для которых
нет исходников. Как следствие, теперь активно пишут эмуляторы. Да и на многих
сотовых это единственно доступная реализация.
>
> AP> В яве не используется концепция динамической генерации кода, без чего
> я AP> не представляю себе разработку (классы, виртуальные классы,
> родительские AP> и производные классы - все это безобразие пытается
> заменить собой простую AP> идею создания кода для нужной ситуации и
> выполнения его; зачем заранее AP> писать вручную тучу кода, когда "по
> месту" можно создавать небольшие AP> блоки кода и тут же их выполнять).
>
> Хм. Да. В прямом смысле этого слова в java нет генерации кода. Но после
> lisp'а генерации кода нет нигде ;)
В тикле есть. Тот же самый принцип - все есть строка, со всеми вытекающими.
Скорость работы? Полно вам - написать нужную функцию на С и оформить в
модуль, обращаясь потом к этой функции напрямую, много эффективнее, чем
делать иерархию классов с конструкторами/деструкторами в каждом. Сменив
фабрики классов на динамическую генерацию кода, обратно уже не вернусь.
>
> На самом деле во время работы можно создавать свои классы и их динамически
> загружать. Просто делается это не совсем очевидно. Но делается.
>
> AP> А что много написано - это не показатель.
>
> Зато это показатель популярности технологии. И чем больше написано, тем
> больше вероятность что то что тебе будет нужно уже написано.
Ну тогда странно, что j2me вы мертвой назвали. По вашему критерию me живее
многих живых.
>
> AP> На пхп написано еще больше, и с худшим качеством.
>
> Нет, на php написано меньше чем на java. Больше чем на(о) java написано
> только на(о) cobol.
В мегабайтах кода точно больше написано. Потому и хуже :-) И серверных
приложений больше, а для других пхп не годится.
>
> AP> Имхо, чем меньше кода решает поставленную задачу, тем качественнее он
> AP> написан, а проекты на яве монстрообразны
>
> Не все. Далеко не все. Есть изящные проекты. Но они теряются в стае
> уродливых. А уродливый код я вам могу написать на любом языке
> программирования. Честно‑честно.
Изящные есть, однако и в них видна явная избыточность кода. Скажем, функции
для доступа к закрытым переменным класса... в противовес общему запрету на
изменение переменных в "более интересных" языках.
> AP> (да, системные библиотеки тоже считаю - их тоже периодически
> приходится AP> проверять и править - скажем, выйдет постгрес 8.3, нужно
> будет AP> оптимизировать под него функции доступа к базе данных; быстрее и
> надежнее AP> сделать это самому, чем месяцами ждать появления нужной
> библиотеки в AP> инете и тестировать появляющиеся их разновидности).
>
> http://jdbc.postgresql.org/
Это низкоуровневый интерфейс. Посмотрите, к примеру, функции работы с БД из
OpenACS.
>
> AP> Так я и общаюсь с _коммерческими_ заказчиками. Тут своя специфика - их
> AP> интересует не модульность и проч. технические характеристики, а
> готовое AP> решение для определенных задач. Что может заинтересовать
> _разработчиков_, я AP> пока не в курсе..
>
> Угу. И готовое решение появляется тем быстрее, чем больше кусков уже
> написано.
А вы себе представляете стоимость модернизации и поддержки такого решения? При
достаточно длительном жизненном цикле продукта затраты на создание становятся
много меньше затрат на адаптацию и разработку модулей. Умея писать серверный
код на ява, вы не напишите на той же яве программу для КПК. На тикле я могу
легко переключиться с создания веб-портала на разработку программы
анкетирования на смартфонах или работу с веб-камерой под оффтопик. К примеру,
набор тиклевских функций для создания файлов в формате ms excel 2003 xml
имеет размер в несколько килобайт и не имеет никаких зависимостей, что
позволяет его использовать с любым интерпретатором тикля (в том числе, с
написанным на ява интерпретатором). Я на его создание потратил пару дней,
зато при необходимости могу очень быстро модифицировать (прочитать код нужной
функции и ее поправить), в отличии от иерархии классов на ява (классы ячейка,
строка, лист, рабочая книга), где нужно еще тратить время на понимание
структуры (нужно в том числе изучить _все_ конструкторы или деструкторы,
чтобы понять порядок инициализации нужных переменных).
Reply to: