Alexey Pechnikov -> debian-russian@lists.debian.org @ Thu, 10 Jan 2008 22:45:53 +0300:
AP> Прикручивание томкатов с апачами и нужными библиотеками и классами доступа к AP> БД (и указание их параметров) иначе назвать не могу. Ужас. Надругательство. Конечно. Для разработки и отладки я использую intellij idea и оттуда стартую tomcat. Для установки приложения я делаю deb'ы. Ужас, правда? >> Угу, много. j2me, j2se, j2ee. Причем первая уже умерла т.к. на >> телефонах/кпк можно запускать se. AP> На первой, которую вы назвали умершей, написана туча приложений, для которых AP> нет исходников. Как следствие, теперь активно пишут эмуляторы. Да и на многих AP> сотовых это единственно доступная реализация. Вот тут появляется действительно минус явы. Можно распространять софт без исходника. Хотя есть jad… >> Хм. Да. В прямом смысле этого слова в java нет генерации кода. Но после >> lisp'а генерации кода нет нигде ;) AP> В тикле есть. Тот же самый принцип - все есть строка, со всеми вытекающими. AP> Скорость работы? Полно вам - написать нужную функцию на С и оформить в AP> модуль, обращаясь потом к этой функции напрямую, много эффективнее, чем AP> делать иерархию классов с конструкторами/деструкторами в каждом. Сменив AP> фабрики классов на динамическую генерацию кода, обратно уже не вернусь.. 1) Иногда OO парадигма удобна. 2) Список генерировать намного, намного проще. Вы просто не работали с lisp. >> Зато это показатель популярности технологии. И чем больше написано, тем >> больше вероятность что то что тебе будет нужно уже написано. AP> Ну тогда странно, что j2me вы мертвой назвали. По вашему критерию me живее AP> многих живых. Я ее назвал мертвой т.к. sun сказала что развивать ее дальше не имеет смысла. Т.к. на pda можно пускать уже se. AP> Это низкоуровневый интерфейс. Посмотрите, к примеру, функции работы с БД из AP> OpenACS. Смотрите, например, hibernate AP> А вы себе представляете стоимость модернизации и поддержки такого решения? При AP> достаточно длительном жизненном цикле продукта затраты на создание становятся AP> много меньше затрат на адаптацию и разработку модулей. С такой логикой можно отказаться и от db, а перейти на написание своей. Правда? AP> Умея писать серверный код на ява, вы не напишите на той же яве программу AP> для КПК. Почему? AP> На тикле я могу легко переключиться с создания веб-портала на разработку AP> программы анкетирования на смартфонах или работу с веб-камерой под AP> оффтопик. Хм. А слабо на tcl да с web camera подключаемая по usb на macosx? AP> К примеру, набор тиклевских функций для создания файлов в формате ms AP> excel 2003 xml имеет размер в несколько килобайт и не имеет никаких AP> зависимостей, что позволяет его использовать с любым интерпретатором AP> тикля (в том числе, с написанным на ява интерпретатором). А в java есть native код для создания xsl файлов… Тоже без зависимостей. Весит jar не много. А в xml от офиса есть огранечение на обьем. Т.е. не огранечение а достаточно большой xml он просто не откроет. Или съест столько памяти, что лучше вешаться. AP> Я на его создание потратил пару дней, зато при необходимости могу очень AP> быстро модифицировать (прочитать код нужной функции и ее поправить), в AP> отличии от иерархии классов на ява (классы ячейка, строка, лист, рабочая AP> книга), где нужно еще тратить время на понимание структуры (нужно в том AP> числе изучить _все_ конструкторы или деструкторы, чтобы понять порядок AP> инициализации нужных переменных). Хм. Спорно. Очень спорно. -- .''`. Kirill A. Korinskiy <[EMAIL PROTECTED]> : :' : proud (maniac)? (developer|hacker) `. `'` http://catap.ru/ - +7 (916) 3-604-704 - xmpp:[EMAIL PROTECTED] `- Debian - when you have better things to do than fixing systems -- madduck
pgpxMllPVRHQM.pgp
Description: PGP signature
