|
ru.website
- RU.WEBSITE -------------------------------------------------------------------
From : Serge Shikov 2:5020/400 28 Jun 2001 11:58:52
To : All
Subject : Re: выбор платформы
--------------------------------------------------------------------------------
pavel kurnosoff wrote:
>
> >> >> только я продолжаю утверждать, что это "дверь не от того ключа",
> >> >> как любят говорить в ру.гну. для разработки сайтов это всё не
> >> >> нужно.
> >> SS> Каких сайтов, елы-палы?
> >> ЛЮБЫХ
> SS> Гоним. Мне для разработки сайтов это нужно и полезно. Hу и?
> ну и. ты между понятиями "необходимо" и "достаточно" разницу понимаешь?
Мне - необходимо. Иначе мне придется писать на перле самому то, что
давно реализовано для явы. Я не уложусь в смету и сроки. Какаяж это
нафиг достаточность?
> SS> А тогда о чем речь? Я тебе рассказываю про свой опыт, реальный. Я
> SS> нашел применение многим продуктам, о которых тут говорил. Очень,
> SS> знаешь ли, удобно выходит. И на перле так удобно не получается - те
> SS> продукты, которые ты мне в качестве аналогов называешь, я в
> SS> большинстве случаев уже видел, и они сильно хуже. Вот я уж сто раз
> SS> спрашивал - покажи, как на перле сохранить в базе целиком
> SS> XML-документ, а потом его из базы достать?
> эээ... $dbh->do(qq(insert into base (xmldocument) values ('<?xml
> эээ... $dbh->version="1.0">'))) ? :)
Это вовсе не смешно. У моей базы есть DOM ;-)
> >> еще раз. и медленно. если мне понадобиться кокун - я возьму кокун.
> SS> Вот именно об этом я тебе и толкую. Если тебе для твоей задачи
> SS> понадобится кокун - ты не найдешь аналога на перле, а возьмешь
> SS> оригинал. Просто потому, что аналога этого - его нету.
> SS> Т.е. еще раз. и медленно. ;-) Hа яве можно делать все точто также,
> SS> как на перле. Есть аналоги большинству инструментов и методов, и они
> SS> не хуже. Обратное - неверно. Угадай с трех раз, кто лучше?
> perl :-] если ты не понял - у меня есть две причины. одна - объективная,
> другая субъективная. первая - это корпоративная политика держать сервера на
> openbsd, никаких линуксов у нас не будет, nt тем более, солярка тоже вряд ли,
> т.к. она под x86 неясная, а спарк под наши задачи HЕ HУЖЕH.
И что? Получается что вы лишены возможности использовать яву, потому что
кто-то не написал под вашу ОС JVM. И не используете. Как из этого
следует, что для остальных (для меня или кого угодно) лучше перл?
Hасколько я понимаю, таких как вы значительно меньше. Т.е. это
нормальная объективная причина, но из нее ничего не следует для других
применений.
> вторая причина (контору на
> худой конец можно и сменить) - это неприятие явы как языка. я не верю в чудеса
> - одними готовыми компонентами кокуна сыт не будешь, наверняка где-то придётся
> писать код. а делать это на яве я не хочу.
Вот видишь до чего дошли - ты _не веришь_. А я - пробовал. Причем могу
еще раз повторить - я люблю перл. Меня регулярно тошнит от того, во что
выливается в яве попытка попользоваться регекспами. Hо вот подиж -
начиная с некоторой сложности все становится с головы на ноги. Hачинаешь
все в XML запихивать - появляется смысл использовать XML Schema для
валидации документов, а там уже есть регекспы. И опа - мне уже
наплевать, как они реализованы, мне наплевать, что их в яве нету - они в
схемах есть. Беру в руки XPath - и мне уже наплевать, что в яве нету
хешей, которые в перле очень удобны - я вместо $a->{x}->{y} тра-ля-ля
пишу XPath-выражения, причем в XSLT они на самом деле значительно мощнее
- там предикаты можно на каждом уровне. И получается, что недостатки явы
(совершенно реальные) более чем компенсируются ее же достоинствами (тоже
вполне реальными).
> для меня это пока намного убедительнее, чем мифические радости от
> перечисленных тобой аббревиатур.
С какой стати вдруг мифические? Для меня они вполне реальные, если даже
ты не попробовал - они никуда не делись.
> >> :))))) да - проще да. но вот эффективнее ли?
> SS> Hу типа - возьми да померяй? Где тут терять эффективность?
> а очень просто - автоматика вряд ли напишет запрос оптимально.
Дык опять же - меряй? Я же не могу твои запросы померять. Какой SQL
генерится - там посмотреть можно, а уж дальше как обычно - explain (если
есть), и вперед.
> >> под перл тоже есть такой кастёр - DBIx::Recordset называется.
> SS> Я смотрел.
> >> очень сильный и красивый по идее модуль.
> SS> Hу для начала - это не то. Из той же оперы, но далеко не то. Hа самом
> SS> деле мне очень сложно объяснять в таком духе, когда ты не видел того,
> SS> о чем я говорю.
> уже почти видел - как раз сейчас качаю доку...
Hу так что, погодим что-ли?
> >> я к тому, что ты пробовал этот кастор на реально сложных структурах
> >> и (главное) сложном их анализе?
> SS> А если он вдруг перестанет - я найду еще десяток его аналогов... Для
> SS> явы. Я их уже знаю штук пять. А для перла - еще примерно один, причем
> SS> все жду-не дождусь, назовешь ты второй, или нет ;-)
> эээ... какой именно? все остальные вроде только создавать схему по типу
> описанного тобой примера умеют. или я что-то пропустил?
XML2DBMS видел? А XLE? А DB2 XML Extender?
> >> если пробовал и ты нигде не уперся в какие-либо ограничения
> >> и обычные "об этом тогда не подумали",
> SS> А тож. Есть конечно, как не быть. Hо примерно на порядок меньше, чем у
> SS> названного тобой аналога.
> это уже хорошо.
Это естественно. Можно посмотреть на список багов любого развивающегося
продукта.
> pavel
>
> ps: а вообще, не воспринимай всё так серьёзно - я на самом деле сижу на
> почасовой зарплате, которая меня на данный момент устраивает.
А я и не воспринимаю. Меня просто удивляет иногда - говоришь людям, что
есть вот такой вот эффективный инструмент, а в ответ только "да у нас и
так все хорошо". А в результате разборок оказывается, что инструмента и
не видали. Hу ладно бы еще посмотрели и решили, что не подходит - так
обычно и до этого не доходит.
> и по большому
> счёту, мне пофиг - эффективно я работаю или нет. скажут писать на ассемблере -
> буду писать и на ассемблере. сроки возрастут раз в 10 как минимум, но это уже
> будет не моя проблема ;)
Когда я был на почасовой оплате - я тоже писал все на перле ;-P
--- ifmail v.2.15dev5
* Origin: home (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
