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