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 <catap@catap.ru>
: :' : proud (maniac)? (developer|hacker)
`. `'` http://catap.ru/ - +7 (916) 3-604-704 - xmpp:catap@catap.ru
`- Debian - when you have better things to do than fixing systems
-- madduck
Attachment:
pgpeMZLSpL22M.pgp
Description: PGP signature