>> А вот это уже пробовалось и не пошло.
> никем это не пробовалось. Общего интерфейса для той же метаинформации не задефейнено,

Пробовалось. Микрософтом. И активно внедрялось. Как будешь в виндовых краях, попробуй на .doc-файле свойства посмотреть.

> скриптового языка которым можно модули всех программ скриптовать без биндингов - нету. У большинства форматов либ вообще нету, а если и есть то все они в сложно-программируемом, не единообразном относительно остальных, не модульном стиле, на каких-нибудь сях, без дслей вроде xpath.

А его и не будет. Так что головотяпство с универсальными форматами оставь головотяпам.

> И текстовое представление удобно для разработчиков парсера/валидатора. Вот и всё. Авк тебе не очень поможет для таких сложных форматов.

Bingo! Теперь осталось сделать очевидный вывод, что если ты на открытой системе желаешь привлечь к своему продукту разработчиков, то тебе полезно делать формат текстовым.

> xmlpath + dom куда как более полезны для работы с тем же оdt. А они не юникс-вей ибо procedure call.

xmlstarlet вполне себе юниксвейная тула даже в упрощённом определении.

> Писать микропарсер для каждой работы с pdf'ой это предел глупости.

Потому что формат говнистый, т.к. view-only. Но pdftext тем не менее существует.

>Открыл вимом sqlite базу. Смог прочитать часть из её содержимого.

Того же можно достичь ecли для каждого формата есть свой просмотрщик-дампер-формата (Вроде того что у Firebug'а в разделе DOM) И без лишнего оверхеда на программистов, если всех поставщиков обязать всех имплементить определённый набор интерфейсов. Причём с повышенным уровнем осмысленности увиденного.

Разве sqlite сейчас юзает текстовое предствление ? Вроде в фирефоксе бинарное...

>то тебе полезно делать формат текстовым.

не нужно его делать текстовым. Достаточно иметь опциональное текстовое предствление.

>привлечь к своему продукту разработчиков

ИДИОТИЗМ ДЕБИЛИЗМ УБИВАТЬ ! Разработчики не должны тратить время на формат. Открытая система. Парсер пишется один раз, и потом не переписывается каждый раз по чуть-чуть в скриптах. Дальше манипуляции ТОЛЬКО с помощью api/dsl'елей. Не хватает функционала - улучшается парсер, отчего всем сразу лучше. Разработчиков нудно привлекать к api.

>Пробовалось. Микрософтом.

Не пробовалось. Ни обязательных модульности, своппинга компонентов, не скриптования приложений там нету.

>попробуй на .doc-файле свойства посмотреть.

Это типа доступный программисту парсер ? Все провайдеры форматов на винде обязаны предоставить доступный программисту парсер ? Нет ? Ну так что ты тут утверждаешь обратное ?

>универсальными форматами

какие нафиг универсальные форматы ?

>pdftext

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

>xmlstarlet

Это юниксовый костыль.

>> то тебе полезно делать формат текстовым.
> не нужно его делать текстовым. Достаточно иметь опциональное текстовое предствление.

Никому не интересно ковыряться в твоих сраных бинарниках. Особенно когда оригинальный парсер обрастёт мхом и перестанет компилироваться.

>> привлечь к своему продукту разработчиков
> ИДИОТИЗМ ДЕБИЛИЗМ УБИВАТЬ ! Разработчики не должны тратить время на формат. Открытая система. Парсер пишется один раз, и потом не переписывается каждый раз по чуть-чуть в скриптах.

Да-да, и ошибки у всех будут одинаковыми. А уж как сладостно будет сделать vendor lock-in с помощью неимоверно сложного парсера, в котором никто разобраться не сможет. Ммммм... Что-то саном и опенофисом запахло, откройте форточку!

> Дальше манипуляции ТОЛЬКО с помощью api/dsl'елей. Не хватает функционала - улучшается парсер, отчего всем сразу лучше. Разработчиков нудно привлекать к api.

Это никому не интересно. Потому что между "грепнуть быстренько в консоли" и "прочитать доки по api, запустить IDE, написать проект, протестировать его" огромная пропасть. Которую из-за лени не преодолеет большинство.

>> Пробовалось. Микрософтом.
> Не пробовалось.

Я тебе про Фосу --- ту мне про Ерёму. Открой под своей виндой окно свойств вордовского документа и ты увидишь, что метаинформация там показывается.

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

com, activex, ole automation. Всё есть и всё через жопу.

>> попробуй на .doc-файле свойства посмотреть.
> Это типа доступный программисту парсер ?

Да. Описание его API есть в MSDN.

> Все провайдеры форматов на винде обязаны предоставить доступный программисту парсер ? Нет ? Ну так что ты тут утверждаешь обратное ?

А вот я и показываю, что не срослось с этим. И не будет, потому что никому из независимых разработчиков это не интересно.

>> универсальными форматами
> какие нафиг универсальные форматы ?

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

>> xmlstarlet
> Это юниксовый костыль.

Ну конечно, если что-то не подходит под твою теорию, то это костыль!

> если всех поставщиков обязать всех имплементить определённый набор интерфейсов. Причём с повышенным уровнем осмысленности увиденного.

Мечтай дальше. А у нас, в реальности, все эти потуги никому не интересны. Потому что реализация каждой дополнительной обязаловки стоит времени и денег.

> Парсер пишется один раз, и потом не переписывается каждый раз по чуть-чуть в скриптах. Дальше манипуляции ТОЛЬКО с помощью api/dsl'елей.

ИДИОТИЗМ ДЕБИЛИЗМ УБИВАТЬ

Открытыми должны быть именно форматы данных. Чтобы можно было обрабатывать чистые данные, без всякого привязанного к ним левого кода.

>>> попробуй на .doc-файле свойства посмотреть. >> Это типа доступный программисту парсер ? >Да. Описание его API есть в MSDN.

я люблю ЛОР. Год назад искал в инете простой способ считывания этих метаданных (не с .doc, а с других файлов, но это неважно). Нашел только с использованием доп. библиотеки от MS. Сейчас почитал тред, спьяну снова поискал и нашел нечто совсем элементарное. Чем тогдашние ключевые слова при поиске отличались от сегодняшних - сам не знаю.

>Открытыми должны быть именно форматы данных.

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

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

Какие чистые данные ? Что такое чистые данные ? Ты c xml'ом с помощью регекспов работаешь, чтоб не запачкаться в "левом коде" парсера ? Если определён и стандартизован интерфейс, то это уже не левый код, а заменяемый компонент.

> Открытость формата как раз только поможет появлению альтернативных версий "левого кода", имплементящего дополнительные интерфейсы.

И это важно. Потому как любую задачу можно решить кучей способов и есть возможность выбрать из них наиболее оптимальный.

>> Чтобы можно было обрабатывать чистые данные, без всякого привязанного к ним левого кода.
> Какие чистые данные ? Что такое чистые данные ? Ты c xml'ом с помощью регекспов работаешь, чтоб не запачкаться в "левом коде" парсера ?

xml --- это прозрачный стандартизированный _формат_. И различных парсеров к нему десятки. Причём различие между sax и dom настолько сильно, что не заметить его можно только если ни разу к ним не прикасаться.

> Если определён и стандартизован интерфейс, то это уже не левый код, а заменяемый компонент.

Это называется отпиской. Формально парсер формата того же опенофиса открыт, но много ли ты видел альтернативных реализаций?

>Никому не интересно ковыряться в твоих сраных бинарниках. Особенно когда оригинальный парсер обрастёт мхом и перестанет компилироваться.

Никому не интересен твой сраный текст. Парсер с открытым кодом мхом не обрастёт никогда, пока он нужен.

>А уж как сладостно будет сделать vendor lock-in с помощью неимоверно сложного парсера, в котором никто разобраться не сможет.

С какой стати то ? ты своими юниксовыми убогими шаред либами мыслишь чтоли ? Мои воображаемые парсеры с открытым кодом, c api на языке высокого уровня.

>Да-да, и ошибки у всех будут одинаковыми.

Вот именно. И ошибки будет дешевле исправлять. Ибо они в одном месте, а не в тысячах мест.

>Всё есть и всё через жопу.

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

>"прочитать доки по api, запустить IDE, написать проект, протестировать его" огромная пропасть.

Ложь и провокация. API может быть консоле-угодным. Слово API в данном контексте можно заменить на CSI (Сonslole Scripting Interface)

>что метаинформация там показывается.

То что ты делаешь называется http://en.wikipedia.org/wiki/Straw-man . Я говорю про модульность, заменяемость, и скриптованность, хотя бы в том же масштабе что и текст в юниксах, но с консолеугодным интерфейсами, ты мне про то что метаинформация в винде делалась, а значит ни у чего модульного-объектного в этом плане будущего нет. Ну не идиотизм? Опыт майкрософта ни о чём не говорит на самом деле. ибо появляется второй straw-man - приложения там это совсем "не связанные скриптами компоненты которые пользователь может rewire'ить".

>Да. Описание его API есть в MSDN.

Давай ссылку. Я подозреваю что он высокоуровневый, и не даёт low-level представления.

>что никому из независимых разработчиков это не интересно.

А вот не надо телепатией заниматься пожалуйста. Тут может быть десяток других причин. Они могут про это не знать. (Я к примеру в первые слушу). Их начальники могут это считать неоправданными лишними расходами. и.т.п.

>так что между универсальным форматом и универсальным парсером разницы я не вижу.

Бред какой... Если я правильно понимаю русский, то "универсальный формат" это формат для всех задач. Как утверждение "Один парсер для одного формата" делает этот формат подходящим для всех задач я плохо понимаю.

>что не заметить его можно только если ни разу к ним не прикасаться.

Это разные модели API. Я это как раз и называл "дополнительным интерфейсом парсера". Они кстати могут разделять low-level код. Парсер здесь понимается как модуль, а не как обьект.

>но много ли ты видел альтернативных реализаций?

А зачем кому то делать альтернативную реализацию, если им понятно что вся сложность в рендеринге, а не в парсинге ? Их сложность реализации полной поддержки формата останавливает, а не сложность парсера.

>И различных парсеров к нему десятки

Да, и через стандартизованные интерфейсы. DOM SAX STAX итп. Отчего всем хорошо и удобно.

>И различных парсеров к нему десятки

Это особый случай на самом деле. Там все скоростью мерялись. Для обычного формата этого не нужно. А опенсорсу поддерживать десятки примерно одинаковых парсеров (потому что через стандартизованный интерфейс) совсем не с руки. Поэтому я и говорю про один.(с разными интерфейсами/моделями api).

>Никому не интересен твой сраный текст. Парсер с открытым кодом мхом не обрастёт никогда, пока он нужен.

plain text это между прочим unix-way. Так что пошли вы в ... виндузятники!

> Это особый случай на самом деле. Там все скоростью мерялись.

Ыыыы, чушь какая. Си и Ява мерялись скоростью? Вроде на Питоне еще есть парсер - там тоже скоростью мерялись? :D

> Для обычного формата этого не нужно.

Что такое "обычный формат"? ELF подойдет? Ты "парсер" ELF из ld прямо в ядро засунешь? Любому формату нужно несколько "парсеров", хотя бы для работы на нескольких платформах (в том числе тех, которые не существовали на момент разработки формата).

И кстати... как насчет "генератора" данных этого "обычного формата" - он тоже должен быть один? :D

>Си и Ява мерялись скоростью? Вроде на Питоне еще есть парсер - там тоже скоростью мерялись? :D

О каких сях питонах вообще может идти речь ? Я говорил про полностью интегрированную среду. Такм модуля мля. Никаких си питонов и жаб быть не может. Поэтому множество парстеров я понял как множество парсеров для одного языка. Имплементаций дома и сакса для жабы действительно выше крыши. И много их именно потому что каждый пытался изобрести мега-быстрый пасрер.

>Что такое "обычный формат"?

Тот формат который выполняет только свою задачу. А не метаформат, которым является xml.

>хотя бы для работы на нескольких платформах

***анись. Ты вообще не в теме о чём речь идёт.

>plain text это между прочим unix-way.

Перечитай тред пожалуйста. Именно я и доказывал тейлганнеру, что текст это unix-way, и не бывает unix-way без текста. Отсюда следует что unix-way это неадекватная херня из семидесятых.

> О каких сях питонах вообще может идти речь ? Я говорил про полностью интегрированную среду. Такм модуля мля. Никаких си питонов и жаб быть не может.

Собственно, я с диагнозом "головотяпство" не прогадал. Ты идёшь по порочному пути COM, дотнета и glib.
Опровергать таких верующих эффективно не получается, поэтому остаётся только ждать, пока самому тебе надоест ходить по граблям, вызываемым таким подходом.

> Я говорил про полностью интегрированную среду.

Сферическую. В вакууме. Окончательный венец развития всех технологий.

> Такм модуля мля. Никаких си питонов и жаб быть не может.

Ты бредишь, мля. Никому никогда не удавалось построить одноязыковую среду.

>>Что такое "обычный формат"?

> Тот формат который выполняет только свою задачу.

Так как насчет ELF?

>> хотя бы для работы на нескольких платформах

> ***анись. Ты вообще не в теме о чём речь идёт.

Утипути, какие суровые смолтокеры пошли. На вопрос про генераторы ответь, умник.

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

Ага, на основе одной цитаты из Википедии :D

Почитай дайджест, что ли: http://catb.org/~esr/writings/taoup/html/ch01s06.html

И обрати внимание на Rule 16

<Ъ>More of the Unix philosophy was implied not by what these elders said but by what they did and the example Unix itself set. Looking at the whole, we can abstract the following ideas:

1. Rule of Modularity: Write simple parts connected by clean interfaces.

2. Rule of Clarity: Clarity is better than cleverness.

3.Rule of Composition: Design programs to be connected to other programs.

4. Rule of Separation: Separate policy from mechanism; separate interfaces from engines.

5. Rule of Simplicity: Design for simplicity; add complexity only where you must.

6. Rule of Parsimony: Write a big program only when it is clear by demonstration that nothing else will do.

7. Rule of Transparency: Design for visibility to make inspection and debugging�easier.

8. Rule of Robustness: Robustness is the child of transparency and simplicity. 9. Rule of Representation: Fold knowledge into data so program logic can be stupid and robust.

10. Rule of Least Surprise: In interface design, always do the least surprising thing.

11. Rule of Silence: When a program has nothing surprising to say, it should say nothing.

12. Rule of Repair: When you must fail, fail noisily and as soon as possible.

13. Rule of Economy: Programmer time is expensive; conserve it in preference to machine time.

14. Rule of Generation: Avoid hand-hacking; write programs to write programs when you can.

15. Rule of Optimization: Prototype before polishing. Get it working before you optimize it.

16. Rule of Diversity: Distrust all claims for “one true way”.

17. Rule of Extensibility: Design for the future, because it will be here sooner than you think.

</Ъ>

>Сферическую. В вакууме. Окончательный венец развития всех технологий.

Именно так. Тот кто хочет жить в говне, вечно писать биндинги, и преодолевать барьеры несовместимости - не достоин жить вообще. И это тогда, когда уже понятно что ничего лучше параметризированных модулей с состоянием или без, отделённых от своего интерфейса. Так или иначе все языки/фреймворки вобщем повторяют одно и тоже. Тот же Zope на питоне. И Trac тоже.

>Никому никогда не удавалось построить одноязыковую среду.

Да даже если много-языковуй. Если интерфейсинг происходит через понятный всем языкам интефейс, то без разницы. Пишешь один раз парсер на одном языке, потом все остальные используют. Биндинг таким образом один. ALSO языки содланные в эру C-api, а не в эру этого стандартного интерфейса, помрут всё равно, ибо будут требовать boilerpaita. Одна из причин провала COM СORBA пододного между прочим - отсутствие языковой поддержки, и использование boilerlate'а вместо неё.

>Так как насчет ELF?

Я вообще не понял прчём здесь ELF и засовывание его в ядро. Я вроде в этом треде был за модульность.

содланные/cозданные

>> Сферическую. В вакууме. Окончательный венец развития всех технологий.

> Именно так.

Ты не доживешь. Я - тем более.

>>Никому никогда не удавалось построить одноязыковую среду.

>Да даже если много-языковуй. Если интерфейсинг происходит через понятный всем языкам интефейс, то без разницы.

Этого даже на виртуальных машинах пока не добились.

>> Так как насчет ELF?

> Я вообще не понял прчём здесь ELF

Это пример формата. Объясни, как твои идеи об универсальном парсере приложимы к ELF. И ответь уже на вопрос о генераторе.

> и засовывание его в ядро.

А это пример того, что требования к парсерам бывают разные.

>these elders said

Но тем неменее unix-way это то что они said. А приведённый пример это поздняя попытка (в 1999 unixway уже сформировался) отмыться от текста.

Юникс вей это вот:

Write programs to handle text streams, because that is a universal interface.

>> these elders said

> Но тем неменее unix-way это то что они said.

"Talk is cheap" (c) И говорили Отцы не только то, что ты процитировал.

> А приведённый пример это поздняя попытка (в 1999 unixway уже сформировался) отмыться от текста.

Приведенный пример - это анализ Unix V7, готовой в 1978 году :D

>Я - тем более.

Ололо. Тейлганнер, у моего прошлого акка дата регистрации пораньше будет.

>Ты не доживешь. Я - тем более.

Стремиться к этому нужно. Текст интерфейс был попыткой этого. Сейчас ясно что не всеобъемлющей. Значит нужно двигаться дальше.

>Этого даже на виртуальных машинах пока не добились.

А там ещё и не пытались. Там нету строгого разделения интерфейс воплощение. Классы экспортятся напрямую создавая хардлинк. С точки зрения многоязыковости - на дотнете вполне. Хотя там проприетарщина и разумеется никакой свободы быть не может.

>универсальном парсере

xerces считай универсальный парсер/набор парсеров для жабы. Использование других имплементаций интерфейса ничего не даст. Если не заметил выше речь шла скорее об одном опенсорс проекте, чем об одном именно парсере. Этот опенсорс проект может быть модульным и содержать несколько моделей api, соответственно несколько парсеров шарящих общий код.

>"генератора" данных этого "обычного формата" - он тоже должен быть один?

Низкоуровневый вполне может быть один, с несколькими высокоуровевыми. Единичность парсера/генератора не принципиальна пусть их будет 5, это гораздо лучше чем 1000 недоделанных написанных в скриптах заново каждый раз.

>это анализ

Отанализирвать можно всё что угодно. В том числе и идеи которые появились только недавно, потому что анализатор с ними занаком. Юниквей это то что создатели думали(а соотвтественно и говорили) когда делали юникс.

>"Talk is cheap" (c) И говорили Отцы не только то, что ты
процитировал.

Тем не менее судя по gaa и остальным носителям - это основной постулат.

>> Я - тем более.

> Ололо. Тейлганнер, у моего прошлого акка дата регистрации пораньше будет.

Раньше чего? :D Хотя да, есть в тебе что-то знакомое.

>> Этого даже на виртуальных машинах пока не добились.

> А там ещё и не пытались

Пытались, но не клеится.

> Единичность парсера/генератора не принципиальна пусть их будет 5

Вот из этого и следует, что определять надо _формат данных_, а не API доступа к нему. Как уже стопицот лет делается в сетевых протоколах.

>Собственно, я с диагнозом "головотяпство"

О да ладно... Пользователь тикля и сторонник "текст это универсальный интерфейс" звучит гораздо более тяжлый диагноз, в 2009ом то...

>COM, дотнета

Они как раз поддерживают много языков.

Я не против многоязыковости в прицепи.. Я против переписывания кода только ради того чтобы предоставить неинородный интерфейс для каждого языка.

> судя по gaa и остальным носителям

А, ну если ты предпочитаешь судить по gaa, а не по ESR, тогда ой.

>Пытались, но не клеится.

Не пытались они ничего. Скриптованность, модульность и взаимозаменяемость - это против проприетарщины в принципе. Потому что к примеру необходимость покупать весь фотошоп сразу из-за одной нужной фичи, а не только нужный модуль через стандартизированный инерфейс, от которого ещё можно и конкурентов огрести - это разновидность lock-in.

>а не API доступа к нему. Как уже стопицот лет делается в сетевых протоколах.

Для скриптинга нужны именно стандартизованные api, а стандартизованный формат данных поможет в создании дополнительных парсеров/генераторов.

>ну если ты предпочитаешь судить по gaa,

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

>>Пытались, но не клеится.

>Не пытались они ничего. Скриптованность, модульность и взаимозаменяемость - это против проприетарщины в принципе.

Пытались. На VM работает куча открытого софта - Python и Ruby, к примеру.

>>а не API доступа к нему. Как уже стопицот лет делается в сетевых протоколах.

>Для скриптинга нужны именно стандартизованные api

Стандартизированный? Не особо. Это плюс, но не более.

> а стандартизованный формат данных поможет в создании дополнительных парсеров/генераторов.

Если есть возможность получить и API, и формат, это хорошо. Но если есть только формат, то тоже жить можно. Если только API - тогда нафиг.

>>ну если ты предпочитаешь судить по gaa,

>Конечно судят по носителям, и по тем кто что-то делает, а не по тем кто давно на пенсию вышел.

ESR тоже всё еще действующий прогер, по крайней мере пару лет назад был. На момент написания AOUP - точно.

>Если только API - тогда нафиг.

А я и не поднимал на флаг "только API". Я поднимал на флаг "API как основной интерфейс для скрпитописателя, а не текст как основной интерфейс для скриптописателя".

>ESR тоже всё еще действующий

С ESR мы покончили когда выяснилось что он не основатель, а анализатор.

>Пытались. На VM работает куча открытого софта - Python и Ruby, к примеру.

с чего ты взял что засовывание руби с питоном в VM это не попытка доставить скриптовые языки на платформу,в том числе для скриптования уже написанных приложений, а попытка достичь "Скриптованность, модульность и взаимозаменяемость" ?

Re^2: [убиться тапком] в файловый диалог gtk наконец-то добавили просмотр размера файлов

>>Собственно, я с диагнозом "головотяпство"
> О да ладно... Пользователь тикля и сторонник "текст это универсальный интерфейс" звучит гораздо более тяжлый диагноз, в 2009ом то...

Не надо приписывать мне некорректных обобщений.

>>COM, дотнета
> Они как раз поддерживают много языков.

Так тебе ещё и одноязыковую среду подавай? Маразм крепчал, деревья гнулись...

> Я не против многоязыковости в прицепи.. Я против переписывания кода только ради того чтобы предоставить неинородный интерфейс для каждого языка.

Ну так не переписывай.

Короче устал я от вас ребята - жрите текст и живите хорошо. :)

/me пошёл дизайнить модульное интегрированное DE...

Re^2: [убиться тапком] в файловый диалог gtk наконец-то добавили просмотр размера файлов

> /me пошёл дизайнить модульное интегрированное DE...

Гном переизобрести решил? Ну-ну...

Кроме шуток, если задизайнишь модульное интегрированное ДЕ, способное развиваться в рамках opensource, то я тебе собственноручно памятник поставлю.

> С ESR мы покончили когда выяснилось что он не основатель

Керниган - вполне основатель (я бы даже сказал - идеолог). Он же автор Software Tools.

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

Они сказали. Но дело не в этом, а в том, что взаимодействия Питона и Руби не получилось. Только через Ява-объекты.

> Остался вопрос: зачем?

При сдаче в издательство размер имеет значение.

> Вот именно, потому что юникс умер. То что ты пытаешься назвать юниквеем - это общепринятые нормы софтваре инжениринга.

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