Билл Гейтс о свободном ПО

> Дело в том что отрасль IT так на самом деле не оправдывает себя как это не странно. Одним словом внедряя везде кучи компьютеров якобы увеличивается в бесконечность производительность труда - это миф

только не надо судить всех по российским конторам, где главным IT'шником робит 25-летний сынок главного акционера. Курить яндекс на предмет ITSM

>то-есть имхо xml - как и рекурсию - надо избегать на больших задачах

рекурсию не надо избегать. В нормальных языковых средах. (например javascript)

> К сожалению, xml, как и java с linux сечас модно впихивать во все дырки - и куда нужно, и где это нафиг не надо. Для разминки советую покурить sf.net - куча проектов используют java,xml для простейших задач. Ну нахрена мне конфиг к программе в xml? coLinux его юзает, хотя .ini файлы на порядок удбнее читаются... Давайте вообще /etc оформим как один xml? Модно же бля! И либу на жабе накатаем.

> Все это от непрофессиональности, не иначе.

Это мне напомнило ситуацию, с внедрением в умы парадигм объектного подхода к разработке :) Тогда тоже, те, кто не понимал сути, кричали благим матом: "Зачем мне эти объекты? Я без всяких объектов все напишу намного быстрее...". Практика показывает, что написать может и быстрее, но развивать - нет. У нас сейчас идет очень крупный проект, так в ХМЛ не только описательная часть объектов вынесена, но и логика (грубо говоря, сделан свой язык). И сделано это именно на java+XML. Крутиться может быть (пока) не очень шустро, но для протитипирования ничего лучше не предумаешь - убрать кнопку, поменять акшэн по нажатию на кнопку, изменить свойства грида, поставить условие в зависимости от атрибута... Это все делается простым редактированием конфига без программинга и перекомпиляции.

>DOM вообще противопаказан так как строит аналог xml - но в виде структур в памяти - целиком. SAX парсеры не факт что поддерживают инкрементальный парсинг тоже.

гм. А зачем вообще парстить "гигантский XML"? XPATH?

>Почему бы в винде вместо реестра оракл не держать?

помтоу, что это "свято место" занято HP OpenView.

>> Дело в том что отрасль IT так на самом деле не оправдывает себя как это не странно. Одним словом внедряя везде кучи компьютеров якобы увеличивается в бесконечность производительность труда - это миф

> только не надо судить всех по российским конторам, где главным IT'шником робит 25-летний сынок главного акционера.

Ну в [censored] именно такая ситуация, но парнишка очень толковый. Может он в ИТ может не очень соображает, но на уровне стратегии очень даже. Начальники ИТфилиалов ему в рот смотрят (кстати, многие - сами бывшие программеры).

> Курить яндекс на предмет ITSM

Вопрос: Как расшифровывается ITSM?

Ответ: ITSM - IT Service Management - это Управление ИТ-услугами, то есть такой подход к управлению ИТ, при котором ИТ-организация рассматривается как поставщик ИТ-услуг. Соответственно на первое место выходит управление качеством их предоставления, а вопросы управления технологиями являются вспомогательными, хотя безусловно важными.

Ну и чем плохо, если паренек 25лет научился строить своих ИТшников, при этом сам ничего в их предмете не понимая? Все укладывается в определение. :->

> а делать из него недолисп - это уже изврат

почему? Это и есть Lisp.

>> Почему бы в винде вместо реестра оракл не держать?

> помтоу, что это "свято место" занято HP OpenView.

Нет не поэтому. :) Во-первых, потому, что это все равно как если бы ядерной ракетой по инфузории туфелке жахнеть, а во-вторых, потому что лицензии на оракл расчитываются по числу пользователей конечного приложения. Самый дешевый вариант поставки оракла - 149 на пользователя. Мягко говоря, это половина стоимости XP Pro... А если пользователей на тачке больше одного? А как насчет того, что сам оракл жрет ресурс?

Хотя, было бы крайне логично что-то вроде XML DB заместо реестра пихнуть, но это скорее в Линуксе произойдет :-> чем в Виндах.

>в ХМЛ не только описательная часть объектов вынесена, но и логика (грубо говоря, сделан свой язык)

Вот-вот. И не такая уж беда, что Lisp потерял своё имя - гораздо важнее, что хоть через тридцать лет, но идеи в нём заложенные всё таки проникают в массы. Хотя эти "массы" и невсегда это осознают.

> Ну и чем плохо, если паренек 25лет научился строить своих ИТшников, при этом сам ничего в их предмете не понимая?

Редкий "25-летний паренёк" в состоянии понять необходимость и возможность ITSM. ...впрочем и 40-летний пердун тоже. Ладно. Был неправ. Погорячился.

> Во-первых, потому, что это все равно как если бы ядерной ракетой по инфузории туфелке жахнет

зато какой нехилый откат можно получить на приобретнии ядерной ракеты.

> хм, спасибо за wbxml - много нового появляется последние годы

Да пожаллста, извини вчера я немного погорячился.... избыток кофе ;)

Просто тут как подойти к использованию XML. Если АБСОЛЮТНО ВСЕ будет идти в чистом текстовом XML - то это конечно же полный идиотизм, поскольку еще лет десять назад в институтах преподавали, что хранение числовых данных в в текстовом виде чрезвычайно сильно влияет на объем хранимых данных, а если все еще и с разметкой .... тут но комментс.

А если реальный обмен идет при помощи бинарного потока типа TLV (type/length/value), где идентификаторы type описаны XML-ной схемой на внешнем источнике - это ОЧЕНЬ красивое решение. Тут уже отпадают проблемы нестандартизированности. Кстати MMS WAP SyncML ну и тому подобное уже очень давно используют XML таким макаром.

Ведь в конечном итоге речь шла о межпрограммном взаимодействии, что в данном контексте, означает "сетевом", поскольку речь идет об абсолютно разных платформах.

>одно "но". "))" менее информативно, чем </define-form></ancestor-form>

Есть такой текстовый редактор (emacs), котрый умеет моргать на парные скобки. Так что "))" столь же информативно, но занимает меньше места.

>какой причине вы не любите XML я так же не понял

Хотя бы потому, что он малофункционален, неудобочитаем и монструозен. Кроме того он по всем параметрам проигрывает лиспу, созданному лет за 40 до него. Прогресс блин!

>Сразу как появляются массивы.

Ага. Очень удобно, вместо (1 2 (3 7) 4 5)

<massiv> <value>1</value> <value>2</value> <value><massiv> <value>3</value> <value>7</value> </massiv> </value> <value>4</value> <value>5</value> </massiv>

Да от этого вашего удобства глаза через 4кБ лопнут.

А для обработки списков есть такой специализированный язык LIst PRocessing называется

>не надо избегать. В нормальных языковых средах. (например javascript)

(вопрос (это ты серьёзно считаешь, что javascript является серьёзным яп))

> Да от этого вашего удобства глаза через 4кБ лопнут. > <massiv> <value>1</value> <value>2</value> <value><massiv> <value>3</value> <value>7</value

Не умеешь не берись...

<tr> <td></td><td></td><td></td><td></td ><td></td><td></td> </tr>

Наверно HTML тоже в топку ?

ООП это не панацея. Это очень нишевое решение. И как всякое нишевое решение вне своей ниши он теряет удобность.

dsa, не позорься.

Впрочем, если ты серьёзно считаешь <censored> xml заменителем lisp'а, то попробуй написать emacs на xml'е. А пока ты этого не сделаешь ....

> А если реальный обмен идет при помощи бинарного потока типа TLV (type/length/value), где идентификаторы type описаны XML-ной схемой на внешнем источнике - это ОЧЕНЬ красивое решение. Тут уже отпадают проблемы нестандартизированности. Кстати MMS WAP SyncML ну и тому подобное уже очень давно используют XML таким макаром.

А если передача идет между системами с разным представлением? Напимер на мэйнфремях ЕБЗДИК очень популярен... Кто будет делать перекодироку? А как принимающая сторона поймет, что ее делать надо? И вот мы так потихоньку до веб сервисов SOAP/UDDI и договоримся. :)

А что касаемо хранения данных в бинарном формате, то это 100% дань времени была (очень высокие цены на мегобайт были), сейчас неактуально, и даже более того - вредно и опасно!

>умеешь не берись...

А что тебе конкретно не нравится?

> А что тебе конкретно не нравится?

Твои попытки вытащить внутренности наружу, HEX батенька еще сложнее прочитать, тоже знаете-ли глаза сломать можно.

> Кто будет делать перекодироку? А как принимающая сторона поймет, что ее делать надо? И вот мы так потихоньку до веб сервисов SOAP/UDDI и договоримся. :)

А почему бы и нет. Никто не говорит, что XML плавно впишется во все уже имеющееся.

> А что касаемо хранения данных в бинарном формате, то это 100% дань времени была (очень высокие цены на мегобайт были), сейчас неактуально, и даже более того - вредно и опасно!

Возможно да, но еще все-таки критично, для embedded устройств. Да и с точки зрения разработчика, удобно оперировать данными с предопределенным размером.

феласофия и болтология. Ты конкретно скажи, что читаемее: многокилобайтное уёбище

<massiv> <value>1</value> <value>2</value> <value><massiv> <value>3</value> <value>7</value> </massiv> </value> <value>4</value> <value>5</value> </massiv>

или красивая, аккуратная, лаконичная запись (1 2 (3 7) 4 5)

С точки зрения софта - глубоко начхать. Мало того, форматирование подправь и все зачитается. А если голова - пухнет от massiv value - ну правь голову. Учитывая, что называть массивом структуру - малость того, некорректно.

>Пробовали xml - получили уход в thrashing (paging) и OutOfMemоry

на жабе небось парсер то? то-то! а память однако нынче задарма раздают - возьмите и добавьте, а чтобы пэйджинга небыло юзайте дос.

>Хотя, это может быть связано с ядром? 2.6.8 + 2 security path..

конечно! это проблемы в ядре! говорю же - ДОС юзать надо - там и ядра то нет! и жаба под досом памяти не жрет!

<massiv> <value>1</value> <value>2</value> <value><massiv> <value>3</value> <value>7</value> </massiv> </value> <value>4</value> <value>5</value> </massiv>


Форматирование никто не отменял.

<massiv>
<value>1</value>
<value>2</value>
<value>
<massiv>
<value>3</value>
<value>7</value>
</massiv>
</value>
<value>4</value>
<value>5</value>
</massiv>

Пробелы побились

> Пробелы побились

Ничего страшного, кстати тут еще маленькая приятная возможность в тэгах "value" типы этих самых переменных, а с фиксированными массивами допускается вообще <array rows="3" cols="3" separator="," value="1,2,3,4,5,6,7,8,9"/>

Кстати предлагаю тему сворачивать, а то глупо надеяться, что в пределах одного трэда будут рассмотрены все специфические моменты применения, и кто-то из участников дискуссии скажет "О! На меня снизошло просветление, отныне только (XML/LISP/CSV/ЁПРСТml)"

> Кстати предлагаю тему сворачивать, а то глупо надеяться, что в пределах одного трэда будут рассмотрены все специфические моменты применения, и кто-то из участников дискуссии скажет "О! На меня снизошло просветление, отныне только (XML/LISP/CSV/ЁПРСТml)"

Вот, и на Вас снизошло "просветление"...

P.S. IMHO, XML уместен там, где о факте его использования, я, как пользователь системы, не буду, даже, догадываться. Т.е. править руками XML -- не предлагать! Ни при настройке, ни при работе, ни при репликации и операциях backup|restore.

> P.S. IMHO, XML уместен там, где о факте его использования, я, как пользователь системы, не буду, даже, догадываться.

Абсолютно с Вами согласен.

>>одно "но". "))" менее информативно, чем </define-form></ancestor-form>

>Есть такой текстовый редактор (emacs), котрый умеет моргать на парные скобки. Так что "))" столь же информативно, но занимает меньше места.

Ну что ты, как маленький... господи... Вот в этой конструкции "))" допущена ошибка - не хватает ещё одной скобки - будь добр напиши валидатор, который _автоматически_ отдетектить эту ситуацию. Или никогда не приходилось искать эту пропцщенную скобку в лисповых исодниках, про которые известно только то, что "дерьмо случилось"... И фиг бы по ним не лазить не то, что с "морганием", но даже и подсветкой всей формы.

>>не надо избегать. В нормальных языковых средах. (например javascript)

>(вопрос (это ты серьёзно считаешь, что javascript является серьёзным яп))

да. В той же мере, в какой и Scheme. И в той же "экологической нише".

>Впрочем, если ты серьёзно считаешь <censored> xml заменителем lisp'а, то попробуй написать emacs на xml'е. А пока ты этого не сделаешь ....

Да я emacs'а и на Lisp'е не напишу. ..если только ты не оплатишь мне несколько десяков килобаксов. Только какое отношение это имеет к XML'ю, как языку позволяющему описывать другие предметно-ориентированные языки?

хм... JSP, jelly, webwork... Ей богу - наслаждаюсь - практически всё, что есть хорошего в Lisp, и при этом вполне себе "мейнстрим". Комплексами по поводу того, что вместо (xxx надо писать <xxx> ... </xxx> не страдаю.

>><massiv> <value>1</value> <value>2</value> <value><massiv> >><value>3</value> <value>7</value> </massiv> </value> <value>4</value> >><value>5</value> </massiv>

>или красивая, аккуратная, лаконичная запись (1 2 (3 7) 4 5)

Честно? Пофиг. ..только ты забыл про атрибуты, массивы, именованые параметры. И там уже всё становится совсем не однозаначно.

> <tr><td></td><td></td><td></td><td& gt;</td ><td></td><td></td> </tr>

> Наверно HTML тоже в топку ?

Да, разумеется. За вышеприведенный пример - как минимум.

И вообще, когда же наконец браузеры научатся на лету генерить dvi'шки из .tex и их показывать? =)

> А если передача идет между системами с разным представлением? Напимер на мэйнфремях ЕБЗДИК очень популярен... Кто будет делать перекодироку?

Обе стороны - в уникод. Который как раз для этого и создавался - чтоб не возникало проблем с несовместимыми кодироваками текста.

> А как принимающая сторона поймет, что ее делать надо?

А как принимающая сторона, если у нее это не зашито в коде, вообще поймет, что имеет XML-пакет, причем вполне особого формата? И если она даже это поймет, но не будет знать, что с ним делать, чем это ей поможет?

> А что касаемо хранения данных в бинарном формате, то это 100% дань времени была (очень высокие цены на мегобайт были), сейчас неактуально, и даже более того - вредно и опасно!

Я надеюсь, вы не предлагаете хранить изображения, видео и звук в текстовом виде и тем более в XML?

>Только какое отношение это имеет к XML'ю, как языку позволяющему описывать другие предметно-ориентированные языки?

А что, в LISP эту возможность уже кастрировали?

> Честно? Пофиг. ..только ты забыл про атрибуты, массивы, именованые параметры. И там уже всё становится совсем не однозаначно.

Пример с массивами (точнее, списками) он тебе как раз-таки привел. Атрибуты - см. keyword parameters в лиспе. А именованные параметры в XML - то что, если не атрибуты?

> Ну что ты, как маленький... господи... Вот в этой конструкции "))" допущена ошибка - не хватает ещё одной скобки - будь добр напиши валидатор, который _автоматически_ отдетектить эту ситуацию.

А чем это принципиально отличается от пропущенного XML-тега? который, строго говоря, тоже можно незадетектить, пока не пропарсишь файл до конца?

>Я надеюсь, вы не предлагаете хранить изображения, видео и звук в текстовом виде и тем более в XML?

И не надейся!

А int19h идет читать smil. :P

Адоб тоже обещал "похоронить" HTML PDFом - а не получилось ...

Новая тема для HOLY WARS

XML versus LISP

Все на баррикады!

> А int19h идет читать smil. :P

Вот когда там появится что-то вроде:

<bitmap width="32" height="32"> <pixel red="1.0" green="0.5" blue="0.7" /> <pixel red="1.0" green="0.5" blue="0.7" alpha="0.1" /> ... </bitmap>

тогда это будет именно то, что я имел в виду =)

>тогда это будет именно то, что я имел в виду =)

Тогда извини за резкость.

ЗЫ: Но все-мы знаем, что то, что ты имел ввиду мягко говоря брррррр... ни дай бог.

Ни дай бог! Ни на LISP ни на XML.

По поводу XML: А что мешает встроить в Мазилу или Эксплорер Perl или PHP. Оба занимаются синтаксическим анализом входного потока. Если что не так то на выход. Встройте любой интерпретатор в систему и можете парсить любые данные с заданым синтаксисом. (Java,SmallTalk и тд..) Если быть точным то XML без DTD применять не имеет смысла.

У меня вопрос к знатокам XML - 1. Могу я проверить в XML тип передаваемого параметра? 2. Как проверить допустимость значений двух параметров в разных ветвях дерева? К примеру если параметер А=1 то параметер Б должен быть равен 3.

> Но все-мы знаем, что то, что ты имел ввиду мягко говоря брррррр... ни дай бог.

А что? Зато его можно через XSLT перегнать и в BMP, и в TGA... =)

>SXML is an abstract syntax tree of an XML document. SXML is also a concrete representation of the XML Infoset in the form of S-expressions.

http://okmij.org/ftp/Scheme/SXML.html