Re[10]: Снова XML: Just Say No to XML - Философия программирования

Здравствуйте, Odi$$ey, Вы писали:

ZS>>Так что же теперь, для всех задачь придумывать свой язык?

OE>Языково-ориентированное программирование: следующая парадигма

Один из основных пунктов парадигмы: узкоспециализированный редактор. Притом DSL может вообще не быть plain-text (посмотри хотя-бы microsoft реализацию), главное чтобы его редактировать можно было удобно при помощи редактора.
Пользователю (прикладному программисту) глубоко наплевать в каком формате сохраняется его работа. Главное что бы было удобно и легко без редактора:
1) Хранить
2) Проводить тесты на валидность
3) Проводить batch-компиляцию
4) Была модульность системы
5) Смотреть историю модуля
6+) и в таком духе
Как видно все эти пункты просто решаются с использованием текстовых форматов. А какой формат выберет системный программист — дело вкуса и возможности "системного" языка хранить в нем объекты.
Т.ч. в данном случае XML не упускает своего шанса (C#, Java итд).

E>А это лучше заменить на:
E>

E>html {
E>  head {
E>    title 'Hi'
E>  }
E>  body {
E>    p {
E>      'Hello, world!'
E>    }
E>  }
E>}
E>

Выкиньте этот велик, всё придумано ещё в 60-х годах.

(html
  (head
    (title "Hi")
    (body
      (p "Hello, World"))))

Алану Голубу бы стоило помолчать

именно его поколение программистов не оставило после себя удобоваримого набора инструментов для написания компиляторов!

xml по сравнению с каким нибудь yacc — это как манна небесная по сравнению с кактусом!

переводить код в "удобочитаемый" и "краткий" язык стоит только тогда когда устоялась структура..

для примера, когда начали программировать и когда придумали "краткий C"?

в общем нынешнее засилье XML ИМХО это то что прогресс движется гораздо быстрее чем могут позволить
обычные "компиляторы компиляторов"..

Здравствуйте, vvaizh, Вы писали:

V>Алану Голубу бы стоило помолчать

+1

V> переводить код в "удобочитаемый" и "краткий" язык стоит только
V> тогда когда устоялась структура..

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

Здравствуйте, eao197, Вы писали:

E>Вот вам бы, например, было бы удобно писать Wiki-странички в формате XML? И как вы думаете, получили бы Wiki-системы такое распространение, если бы в качестве языка разметки они предлагали пользователю XML?

Мне лично удобнее был бы XML. Просто по той причине, что разметочные маркеры предлагаемые многими wiki конфликтуют с тем, как мне нужно что-то записать, причём регулярно.
Например, где-то для подчёркивания пишется __x__. А если мне нужно описать например питоновый __init__? Или в MediaWiki пробел в начале строки создаёт (грубо говоря) таблицу. А если мне надо сделать отступ?
У XML регулярный конфликт только по трём символам "<>&" (ну, может ещё " — но это уже в полях, которые тут не интересуют). Элементарно сделать автоматическую подстановку при импорте текста. А с wiki — у каждой свои правила, все заточены на "интуитивные" подходы типа "вот тут оберните звёздочками" как будто никакой информации кроме плоского английского текста нет. И если делать импорт текста то приходится его чуть ли не целиком заворачивать, например, в две двойные кавычки (для WackoWiki). А если в тексте будут две двойные кавычки (а они будут, например, в сишной константе "строка длины 0")? Разворачивать перед ними, как-то их эскейпить, заворачивать обратно? Последний раз я такие извраты видел, когда передавались строки в команду для /bin/sh...

Видеть вместо всего этого бардака простые и понятные <u>...</u> в разы понятнее и проще. Подход один, единообразен, достаточно удобен как человеку, так и машине. И что важно — общие правила просты и немногочисленны. Думаю, это и есть те причины, по которым вообще продвигается XML: вместо туевой хучи локальных язычков, сляпанных обычно кое-как на коленке и постоянно страдающих от недоработки, он дал один общий метод и инфраструктуру (те же валидаторы и преобразователи). Фактически я видел до того (если не считать SGML) только один более-менее нормальный язык разметки — roff. Но у того всё-таки ориентация на форматирование для печати, а не на представление "вообще".

Вот уже на языки программирования я бы такой подход не распространял — там обычно немного другая... мнэээ... мотивация принятых решений.

Здравствуйте, vvaizh, Вы писали:

V>Алану Голубу бы стоило помолчать
V>именно его поколение программистов не оставило после себя удобоваримого набора инструментов для написания компиляторов!
V>xml по сравнению с каким нибудь yacc — это как манна небесная по сравнению с кактусом!

Особенно интересно смотреть на такие "сравнения" понимая что сравниваются совершенно разнородные сущности.

А какой инструмент для написания _компиляторов_ Вы хотели видеть вместо... мнэээ... yacc? И как он заменит, например, кодогенерацию?:)))

Здравствуйте, netch80, Вы писали:

V>>Алану Голубу бы стоило помолчать
V>>именно его поколение программистов не оставило после себя удобоваримого набора инструментов для написания компиляторов!
V>>xml по сравнению с каким нибудь yacc — это как манна небесная по сравнению с кактусом!

N>Особенно интересно смотреть на такие "сравнения" понимая что сравниваются совершенно разнородные сущности.

N>А какой инструмент для написания _компиляторов_ Вы хотели видеть вместо... мнэээ... yacc?

например pccts (http://www.cs.rhul.ac.uk/research/languages/links.html)
избавлен от многих детских болезней yacc-а

N>И как он заменит, например, кодогенерацию?

ну вообще то пользователи XML как то обходят это место..
большинство используют DOM-модель..
так и тут могли бы использовать доведённые до ума AST (abstract syntax tree)

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

Здравствуйте, vvaizh, Вы писали:

V>Здравствуйте, netch80, Вы писали:

V>>>Алану Голубу бы стоило помолчать
V>>>именно его поколение программистов не оставило после себя удобоваримого набора инструментов для написания компиляторов!
V>>>xml по сравнению с каким нибудь yacc — это как манна небесная по сравнению с кактусом!
N>>Особенно интересно смотреть на такие "сравнения" понимая что сравниваются совершенно разнородные сущности.
N>>А какой инструмент для написания _компиляторов_ Вы хотели видеть вместо... мнэээ... yacc?
V>например pccts (http://www.cs.rhul.ac.uk/research/languages/links.html)
V>избавлен от многих детских болезней yacc-а

И каким образом это объясняет Ваши тезисы? Да, pccts появился позднее. Но:
— не так страшен yacc, как его малюют:) GCC, например, сидит на yacc (в виде bison). Perl — на yacc. Видимо, он их удовлетворяет?
— чтобы понять, как делать лучше, надо было наработать опыт использования. Как этот опыт можно было получить без такого средства как yacc?
— и снова: при чём тут XML? Его средства заменят полноценный синтаксический разбор? Причём уровня как минимум pccts (иначе бы не нужно было это писать)? Просто потребовать баланса тегов разных уровней и соответствия заранее заданной иерархии — это даже не уровень yacc, это ниже. yacc хоть даёт возможность иногда пробиваться через нарушенный синтаксис.

N>>И как он заменит, например, кодогенерацию?:)))
V>ну вообще то пользователи XML как то обходят это место..
V>большинство используют DOM-модель..
V>так и тут могли бы использовать доведённые до ума AST (abstract syntax tree)
V>речь ведь не об оптимальности кода.. а о краткости и наглядности синтаксиса..

Я не думаю, что <expr><sum><item>1</item><item>2</item></sum></expr> нагляднее, чем 1+2. Попробуйте переубедить:)

Здравствуйте, netch80, Вы писали:

N>Здравствуйте, vvaizh, Вы писали:

V>>>>Алану Голубу бы стоило помолчать
V>>>>именно его поколение программистов не оставило после себя удобоваримого набора инструментов для написания компиляторов!
V>>>>xml по сравнению с каким нибудь yacc — это как манна небесная по сравнению с кактусом!
N>>>Особенно интересно смотреть на такие "сравнения" понимая что сравниваются совершенно разнородные сущности.
N>>>А какой инструмент для написания _компиляторов_ Вы хотели видеть вместо... мнэээ... yacc?
V>>например pccts (http://www.cs.rhul.ac.uk/research/languages/links.html)
V>>избавлен от многих детских болезней yacc-а

N>И каким образом это объясняет Ваши тезисы? Да, pccts появился позднее. Но:
N>- не так страшен yacc, как его малюют

GCC, например, сидит на yacc (в виде bison). Perl — на yacc. Видимо, он их удовлетворяет?

не удовлетворяет
я говорю то что знаю
работал в разработке продукта, также на yacc..
знаю этот гемор изнутри и то что о нём думают разработчики

N>- чтобы понять, как делать лучше, надо было наработать опыт использования. Как этот опыт можно было получить без такого средства как yacc?

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

N>- и снова: при чём тут XML? Его средства заменят полноценный синтаксический разбор? Причём уровня как минимум pccts (иначе бы не нужно было это писать)? Просто потребовать баланса тегов разных уровней и соответствия заранее заданной иерархии — это даже не уровень yacc, это ниже. yacc хоть даёт возможность иногда пробиваться через нарушенный синтаксис.

средства XML позволяют гибко, просто и без геморроя менять язык
этого оказалось достаточно

N>>>И как он заменит, например, кодогенерацию?

V>>ну вообще то пользователи XML как то обходят это место..
V>>большинство используют DOM-модель..
V>>так и тут могли бы использовать доведённые до ума AST (abstract syntax tree)
V>>речь ведь не об оптимальности кода.. а о краткости и наглядности синтаксиса..

N>Я не думаю, что <expr><sum><item>1</item><item>2</item></sum></expr> нагляднее, чем 1+2. Попробуйте переубедить

видите ли, в большинстве критикуемых применений XML (nant, wix и т.п.)
такие выражения практически не используются, а там где используются используется обычный синтаксис, не XML

так что мимо кассы

с вашим примером вам нужно критиковать какой нибудь MathML да и то попробуйте в ваш синтаксис (1+2) ввести интегралы кванторы и прочую мат-обыденность и вам сразу поплохеет и захочется полноценного XML-я

Здравствуйте, vvaizh, Вы писали:

N>>И каким образом это объясняет Ваши тезисы? Да, pccts появился позднее. Но:
N>>- не так страшен yacc, как его малюют:) GCC, например, сидит на yacc (в виде bison). Perl — на yacc. Видимо, он их удовлетворяет?
V>не удовлетворяет
V>я говорю то что знаю

Ага — значит, Вы знаете что думает народ пишущий GCC и Perl? Тогда почему они используют yacc?

V>работал в разработке продукта, также на yacc..
V>знаю этот гемор изнутри и то что о нём думают разработчики

Разработчики бывают разные. Думать они могут о разном. Например, о бабах:) Вы хотите сказать, что yacc прост и прямолинеен настолько, что примитивен? Я согласен. Что он "гемор"? Не вижу оснований. У него есть своя ниша — разбор конфигов и простых языков — и он её отлично закрывает. Причём в отличие от многих XML'евых парсеров (контекст не потеряли?) у него валидатор синтаксиса встроенный, а не стоящий где-то сбоку припёка отдельным средством.

Или в чём ещё проблема yacc?

N>>- чтобы понять, как делать лучше, надо было наработать опыт использования. Как этот опыт можно было получить без такого средства как yacc?
V>мне не интересно как этот опыт можно было получить
V>мне более интересно что ко времени массовой потребности хорошего механизма не появилось.

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

N>>- и снова: при чём тут XML? Его средства заменят полноценный синтаксический разбор? Причём уровня как минимум pccts (иначе бы не нужно было это писать)? Просто потребовать баланса тегов разных уровней и соответствия заранее заданной иерархии — это даже не уровень yacc, это ниже. yacc хоть даёт возможность иногда пробиваться через нарушенный синтаксис.
V>средства XML позволяют гибко, просто и без геморроя менять язык
V>этого оказалось достаточно

Средство "последовательность байт" позволяют гибко, просто и без геморроя менять язык. При этом их возможности значительно шире чем у XML — можно применять и бинарные форматы, и другие варианты форматов с самотерминацией лексем (что резко упрощает парсеры), и при этом оно в разы экономнее XML. Давайте его использовать, зачем нам эти костыли?

N>>Я не думаю, что <expr><sum><item>1</item><item>2</item></sum></expr> нагляднее, чем 1+2. Попробуйте переубедить:)
V>видите ли, в большинстве критикуемых применений XML (nant, wix и т.п.)
V>такие выражения практически не используются, а там где используются используется обычный синтаксис, не XML
V>так что мимо кассы

Не "мимо кассы", а Вы хотите и крестик оставить, и трусы снять:) Вы ж наехали на "поколение Голуба" за недостаток средств, а взамен в качестве альтернативы предложили XML. Их (того поколения) средства справляются с синтаксисом вида 1+2 беспроблемно и не требуется XML'ное обрамление. А у Вас будет двуслойность — и одни средства, и другие? И что это даст тем применениям, где обычно используется тот же yacc?

V>с вашим примером вам нужно критиковать какой нибудь MathML да и то попробуйте в ваш синтаксис (1+2) ввести интегралы кванторы и прочую мат-обыденность и вам сразу поплохеет и захочется полноценного XML-я

Я там лучше TeX'овский стиль синтаксиса применю.

Здравствуйте, netch80, Вы писали:

N>Здравствуйте, vvaizh, Вы писали:

N>>>И каким образом это объясняет Ваши тезисы? Да, pccts появился позднее. Но:
N>>>- не так страшен yacc, как его малюют

GCC, например, сидит на yacc (в виде bison). Perl — на yacc. Видимо, он их удовлетворяет?
V>>не удовлетворяет
V>>я говорю то что знаю

N>Ага — значит, Вы знаете что думает народ пишущий GCC и Perl? Тогда почему они используют yacc?

они думают "ну и угрёбище", но переписывать кучу существующего кода тяжело.. хотя и пытаются
тот же pccts — я не зря упомянул, именно он рассматривался как замена

V>>работал в разработке продукта, также на yacc..
V>>знаю этот гемор изнутри и то что о нём думают разработчики

N>Разработчики бывают разные.

это была мысль CTO и более того на работу по переходу на pccts было затрачено при мне не менее человеко/месяца

N>Думать они могут о разном. Например, о бабах

Вы хотите сказать, что yacc прост и прямолинеен настолько, что примитивен? Я согласен. Что он "гемор"? Не вижу оснований. У него есть своя ниша — разбор конфигов и простых языков — и он её отлично закрывает. Причём в отличие от многих XML'евых парсеров (контекст не потеряли?) у него валидатор синтаксиса встроенный, а не стоящий где-то сбоку припёка отдельным средством.

в отличие от того же XML, ошибку в синтаксисе которого показывает банально любой броузер а новые языковые конструкции не вводят предыдущие версии в ступор (не нужен никакой препроцессор чтобы пропускать новые конструкции)

yacc не позволяет выдавать нормальные сообщения об ошибках
и на больших грамматиках добавлять чего то и отслеживать
непротиворечивость (а там постоянон растёт количество варнингов)
очень тяжело

N>Или в чём ещё проблема yacc?

отсутствие модульности, объектности, нормальных сообщений об ошибках, да куча всего, почитайте про pccts, там многое перечислено

N>>>- чтобы понять, как делать лучше, надо было наработать опыт использования. Как этот опыт можно было получить без такого средства как yacc?
V>>мне не интересно как этот опыт можно было получить
V>>мне более интересно что ко времени массовой потребности хорошего механизма не появилось.

N>Ну так сформулируйте конкретно и детально (а то я тут из Вас каждое слово клещами тяну) что именно Вы вкладываете в понятие "хорошего" механизма, тогда можно будет рассмотреть, почему такого не было (уточняя: в публичном доступе).

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

N>>>- и снова: при чём тут XML? Его средства заменят полноценный синтаксический разбор? Причём уровня как минимум pccts (иначе бы не нужно было это писать)? Просто потребовать баланса тегов разных уровней и соответствия заранее заданной иерархии — это даже не уровень yacc, это ниже. yacc хоть даёт возможность иногда пробиваться через нарушенный синтаксис.
V>>средства XML позволяют гибко, просто и без геморроя менять язык
V>>этого оказалось достаточно

N>Средство "последовательность байт" позволяют гибко, просто и без геморроя менять язык. При этом их возможности значительно шире чем у XML — можно применять и бинарные форматы, и другие варианты форматов с самотерминацией лексем (что резко упрощает парсеры), и при этом оно в разы экономнее XML. Давайте его использовать, зачем нам эти костыли?

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

N>>>Я не думаю, что <expr><sum><item>1</item><item>2</item></sum></expr> нагляднее, чем 1+2. Попробуйте переубедить

V>>видите ли, в большинстве критикуемых применений XML (nant, wix и т.п.)
V>>такие выражения практически не используются, а там где используются используется обычный синтаксис, не XML
V>>так что мимо кассы

N>Не "мимо кассы", а Вы хотите и крестик оставить, и трусы снять

Вы ж наехали на "поколение Голуба" за недостаток средств, а взамен в качестве альтернативы предложили XML. Их (того поколения) средства справляются с синтаксисом вида 1+2 беспроблемно и не требуется XML'ное обрамление. А у Вас будет двуслойность — и одни средства, и другие? И что это даст тем применениям, где обычно используется тот же yacc?

простите, но выражения 1+2 легко парсятся первокурсником в качестве лабораторной работы без всякого yacc
если вы ссчитаете результатом поколения голуба то что первокурсник делает за один-два дня, то мне не чего вам возразить

V>>с вашим примером вам нужно критиковать какой нибудь MathML да и то попробуйте в ваш синтаксис (1+2) ввести интегралы кванторы и прочую мат-обыденность и вам сразу поплохеет и захочется полноценного XML-я

N>Я там лучше TeX'овский стиль синтаксиса применю.

который никто кроме теха не поймёт
так что даже чтобы примитивный конвертор написать придётся попотеть

Здравствуйте, vvaizh, Вы писали:

N>>Ага — значит, Вы знаете что думает народ пишущий GCC и Perl? Тогда почему они используют yacc?
V>они думают "ну и угрёбище", но переписывать кучу существующего кода тяжело.. хотя и пытаются
Интересный вывод:)

V>в отличие от того же XML, ошибку в синтаксисе которого показывает банально любой броузер а новые языковые конструкции не вводят предыдущие версии в ступор (не нужен никакой препроцессор чтобы пропускать новые конструкции)

Так называемый "синтаксис" XML, который способен показывать браузер, для других средств (не-XML'ных) аналогичен уровню деления битового потока на байты. И даже баланс тегов — это не синтаксис. Синтаксис — это то, что не может быть например быть while внутри выражения (expression). Это Вам покажет "любой браузер"? Это уже весьма высокий уровень полёта, и далеко не любой браузер способен на такое.

V>yacc не позволяет выдавать нормальные сообщения об ошибках

Нормальные чему?

V>и на больших грамматиках добавлять чего то и отслеживать
V>непротиворечивость (а там постоянон растёт количество варнингов)

shift/reduce? Несерьёзно, они по жизни конфликтуют:)

V>очень тяжело

Очень конкретно:))

N>>Ну так сформулируйте конкретно и детально (а то я тут из Вас каждое слово клещами тяну) что именно Вы вкладываете в понятие "хорошего" механизма, тогда можно будет рассмотреть, почему такого не было (уточняя: в публичном доступе).
V>а зачем?
V>разработчики уже сделали свой выбор
V>обосновывать его не вижу смысла
V>таково сложившееся положение вещей

Другим объясните, чтобы по тем же граблям не ходить.

N>>Средство "последовательность байт" позволяют гибко, просто и без геморроя менять язык. При этом их возможности значительно шире чем у XML — можно применять и бинарные форматы, и другие варианты форматов с самотерминацией лексем (что резко упрощает парсеры), и при этом оно в разы экономнее XML. Давайте его использовать, зачем нам эти костыли?
V>угу..
V>вот только при этом изменении языка старые данные читаться не будут

Ойвэй, так таки и не будут. Годами программисты нарабатывали методы, как читать не только "старые данные" но и старые форматы, как их различать и по явным указаниям, и эмпирически (если где-то не получилось пометить явно). А тут вдруг раз — и не будут.

А в случае XML Вы готовы принимать данные во всех старых форматах, какие были при развитии некоторой большой и сложной программы например до 20-й версии? Или только два последних формата, а проблемы остальных оставили индейцам?

N>>Не "мимо кассы", а Вы хотите и крестик оставить, и трусы снять:) Вы ж наехали на "поколение Голуба" за недостаток средств, а взамен в качестве альтернативы предложили XML. Их (того поколения) средства справляются с синтаксисом вида 1+2 беспроблемно и не требуется XML'ное обрамление. А у Вас будет двуслойность — и одни средства, и другие? И что это даст тем применениям, где обычно используется тот же yacc?
V>простите, но выражения 1+2 легко парсятся первокурсником в качестве лабораторной работы без всякого yacc
V>если вы ссчитаете результатом поколения голуба то что первокурсник делает за один-два дня, то мне не чего вам возразить

Это Ваши домыслы. Я бы на Вас посмотрел что бы Вы сделали на машине слабее PC XT и стоимостью как "Мерседес" и отдали бы при этом в open source (которое тогда только-только начиналось).

N>>Я там лучше TeX'овский стиль синтаксиса применю.
V>который никто кроме теха не поймёт
V>так что даже чтобы примитивный конвертор написать придётся попотеть

да ну.

Здравствуйте, netch80, Вы писали:

N>Здравствуйте, vvaizh, Вы писали:

N>>>Ага — значит, Вы знаете что думает народ пишущий GCC и Perl? Тогда почему они используют yacc?
V>>они думают "ну и угрёбище", но переписывать кучу существующего кода тяжело.. хотя и пытаются
N>Интересный вывод

какой есть
и главное из жизни очень успешной и известной компании

V>>в отличие от того же XML, ошибку в синтаксисе которого показывает банально любой броузер а новые языковые конструкции не вводят предыдущие версии в ступор (не нужен никакой препроцессор чтобы пропускать новые конструкции)

N>Так называемый "синтаксис" XML, который способен показывать браузер, для других средств (не-XML'ных) аналогичен уровню деления битового потока на байты. И даже баланс тегов — это не синтаксис. Синтаксис — это то, что не может быть например быть while внутри выражения (expression). Это Вам покажет "любой браузер"? Это уже весьма высокий уровень полёта, и далеко не любой браузер способен на такое.

да главное что парсеры не сломаются об такие ошибки

V>>yacc не позволяет выдавать нормальные сообщения об ошибках
N>Нормальные чему?

нормальные не чему а что ошибки нормальные
которые указывали бы не только место где произошла ошибка но и конкретно что это за ошибка
большинство программ использующих yacc выдают сообщения типа
"нарушение синтаксиса в строке такой то, позиции такой то"

V>>и на больших грамматиках добавлять чего то и отслеживать
V>>непротиворечивость (а там постоянон растёт количество варнингов)
N>shift/reduce? Несерьёзно, они по жизни конфликтуют

серъёзно, нет нормальных средств борьбы с ними

V>>очень тяжело
N>Очень конкретно

а я конкретники и не обещал, я обещал практический опыт

N>>>Ну так сформулируйте конкретно и детально (а то я тут из Вас каждое слово клещами тяну) что именно Вы вкладываете в понятие "хорошего" механизма, тогда можно будет рассмотреть, почему такого не было (уточняя: в публичном доступе).
V>>а зачем?
V>>разработчики уже сделали свой выбор
V>>обосновывать его не вижу смысла
V>>таково сложившееся положение вещей
N>Другим объясните, чтобы по тем же граблям не ходить.

дык уже и не ходят, юзают XML где только можно

N>>>Средство "последовательность байт" позволяют гибко, просто и без геморроя менять язык. При этом их возможности значительно шире чем у XML — можно применять и бинарные форматы, и другие варианты форматов с самотерминацией лексем (что резко упрощает парсеры), и при этом оно в разы экономнее XML. Давайте его использовать, зачем нам эти костыли?
V>>угу..
V>>вот только при этом изменении языка старые данные читаться не будут
N>Ойвэй, так таки и не будут. Годами программисты нарабатывали методы, как читать не только "старые данные" но и старые форматы, как их различать и по явным указаниям, и эмпирически (если где-то не получилось пометить явно). А тут вдруг раз — и не будут.

угу.. годами.. и лучшее средство которое придемули — XML
где раскрученное средство весовой категории yacc/XML которое бы для yacc-а обеспечивало это?

N>А в случае XML Вы готовы принимать данные во всех старых форматах, какие были при развитии некоторой большой и сложной программы например до 20-й версии? Или только два последних формата, а проблемы остальных оставили индейцам?

в случае XML у меня есть путь который обеспечивает способ работы со старыми форматами без переписывания или усложнения парсера

N>>>Не "мимо кассы", а Вы хотите и крестик оставить, и трусы снять

Вы ж наехали на "поколение Голуба" за недостаток средств, а взамен в качестве альтернативы предложили XML. Их (того поколения) средства справляются с синтаксисом вида 1+2 беспроблемно и не требуется XML'ное обрамление. А у Вас будет двуслойность — и одни средства, и другие? И что это даст тем применениям, где обычно используется тот же yacc?
V>>простите, но выражения 1+2 легко парсятся первокурсником в качестве лабораторной работы без всякого yacc
V>>если вы ссчитаете результатом поколения голуба то что первокурсник делает за один-два дня, то мне не чего вам возразить
N>Это Ваши домыслы. Я бы на Вас посмотрел что бы Вы сделали на машине слабее PC XT и стоимостью как "Мерседес" и отдали бы при этом в open source (которое тогда только-только начиналось).

простите, но XML/HTML/SGML именно тогда и зародился
так что это не домыслы. это — жизнь

кстати эту лабораторную (парсер арифметических выражений со скобками и функциями)
я именно па XT-шках и писал..

Здравствуйте, vvaizh, Вы писали:

N>>Интересный вывод:)
V>какой есть
V>и главное из жизни очень успешной и известной компании

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

N>>Так называемый "синтаксис" XML, который способен показывать браузер, для других средств (не-XML'ных) аналогичен уровню деления битового потока на байты. И даже баланс тегов — это не синтаксис. Синтаксис — это то, что не может быть например быть while внутри выражения (expression). Это Вам покажет "любой браузер"? Это уже весьма высокий уровень полёта, и далеко не любой браузер способен на такое.
V>да главное что парсеры не сломаются об такие ошибки

А лучше бы сломались, раз это ошибки.

V>>>yacc не позволяет выдавать нормальные сообщения об ошибках
N>>Нормальные чему?
V>нормальные не чему а что ошибки нормальные
:)
V>>>очень тяжело
N>>Очень конкретно:))
V>а я конкретники и не обещал, я обещал практический опыт

Это не объяснение опыта разработки. Это объяснение уровня "мы тут вкурили и меня плющило". Опыт разработки должен быть выражен детально, иначе это не опыт.

N>>Другим объясните, чтобы по тем же граблям не ходить.
V>дык уже и не ходят, юзают XML где только можно

Что-то я не вижу переписки синтаксиса Си на XML.:)))

N>>Ойвэй, так таки и не будут. Годами программисты нарабатывали методы, как читать не только "старые данные" но и старые форматы, как их различать и по явным указаниям, и эмпирически (если где-то не получилось пометить явно). А тут вдруг раз — и не будут.
V>угу.. годами.. и лучшее средство которое придемули — XML
V>где раскрученное средство весовой категории yacc/XML которое бы для yacc-а обеспечивало это?

Что именно обеспечивало бы? Определить в начале потока какой-то признак формата и дальше выполнить "условный switch"? ЛЮБОЕ средство такое может. Тот же yacc, только надо в грамматику это вставить.

N>>А в случае XML Вы готовы принимать данные во всех старых форматах, какие были при развитии некоторой большой и сложной программы например до 20-й версии? Или только два последних формата, а проблемы остальных оставили индейцам?
V>в случае XML у меня есть путь который обеспечивает способ работы со старыми форматами без переписывания или усложнения парсера

А его нету без XML? М-да... Ваши заявления всё интереснее и интереснее.

V>>>простите, но выражения 1+2 легко парсятся первокурсником в качестве лабораторной работы без всякого yacc
V>>>если вы ссчитаете результатом поколения голуба то что первокурсник делает за один-два дня, то мне не чего вам возразить
N>>Это Ваши домыслы. Я бы на Вас посмотрел что бы Вы сделали на машине слабее PC XT и стоимостью как "Мерседес" и отдали бы при этом в open source (которое тогда только-только начиналось).
V>простите, но XML/HTML/SGML именно тогда и зародился
V>так что это не домыслы. это — жизнь

Когда это они зародились? В конце 70-х? М-да... смените траву:) В конце 70-х был roff. Кстати — отличный язык разметки, не хуже SGML. И не такой многословный.

Здравствуйте, netch80, Вы писали:

N>>>Интересный вывод

V>>какой есть
V>>и главное из жизни очень успешной и известной компании
N>При этом сказано 0 целых фиг десятых про то, что этой компании было нужно и что она требовала.

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

N>>>Так называемый "синтаксис" XML, который способен показывать браузер, для других средств (не-XML'ных) аналогичен уровню деления битового потока на байты. И даже баланс тегов — это не синтаксис. Синтаксис — это то, что не может быть например быть while внутри выражения (expression). Это Вам покажет "любой браузер"? Это уже весьма высокий уровень полёта, и далеко не любой браузер способен на такое.
V>>да главное что парсеры не сломаются об такие ошибки
N>А лучше бы сломались, раз это ошибки.

это не просто ошибки, это "такие" ошибки..
о которых ломаться не должно

V>>>>очень тяжело
N>>>Очень конкретно

V>>а я конкретники и не обещал, я обещал практический опыт
N>Это не объяснение опыта разработки. Это объяснение уровня "мы тут вкурили и меня плющило". Опыт разработки должен быть выражен детально, иначе это не опыт.

опыт вообще не обязан выражаться или объясняться, он либо есть либо нет, как данность!
его можно либо игнорировать и учиться на своих ошибках либо САМОМУ слушателю пытаться вкурить для себя

N>>>Другим объясните, чтобы по тем же граблям не ходить.
V>>дык уже и не ходят, юзают XML где только можно
N>Что-то я не вижу переписки синтаксиса Си на XML.

что то я не вижу там больших изменений в синтаксисе за последние кавырнадцать лет для того чтобы его переводить на XML
кроме того C-подобные языки которые в качестве синтаксиса используют XML я уже видел

N>>>Ойвэй, так таки и не будут. Годами программисты нарабатывали методы, как читать не только "старые данные" но и старые форматы, как их различать и по явным указаниям, и эмпирически (если где-то не получилось пометить явно). А тут вдруг раз — и не будут.
V>>угу.. годами.. и лучшее средство которое придемули — XML
V>>где раскрученное средство весовой категории yacc/XML которое бы для yacc-а обеспечивало это?
N>Что именно обеспечивало бы? Определить в начале потока какой-то признак формата и дальше выполнить "условный switch"? ЛЮБОЕ средство такое может. Тот же yacc, только надо в грамматику это вставить.

а зачем я должен поддерживать несколько веток для switch-а?
это bad smell вообще то!
а зачем я должен заставлять пользователя прописывать версию и следить за её актуальностью?

N>>>А в случае XML Вы готовы принимать данные во всех старых форматах, какие были при развитии некоторой большой и сложной программы например до 20-й версии? Или только два последних формата, а проблемы остальных оставили индейцам?
V>>в случае XML у меня есть путь который обеспечивает способ работы со старыми форматами без переписывания или усложнения парсера
N>А его нету без XML? М-да... Ваши заявления всё интереснее и интереснее.

его нету в виде промышленного решения и парадигмы
это не мои заявления повторяю, это опыт всей отрасли

а автор статьи (Голуб) вместе с вами маргинально пытается отрасли умозрительно чего то объяснить
даже не собираюсь вступать в дебаты

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

не только что "вся отрасль — дураки"
но и "наверно классические средства для создания парсеров имеют какие то изъяны"

V>>>>простите, но выражения 1+2 легко парсятся первокурсником в качестве лабораторной работы без всякого yacc
V>>>>если вы ссчитаете результатом поколения голуба то что первокурсник делает за один-два дня, то мне не чего вам возразить
N>>>Это Ваши домыслы. Я бы на Вас посмотрел что бы Вы сделали на машине слабее PC XT и стоимостью как "Мерседес" и отдали бы при этом в open source (которое тогда только-только начиналось).
V>>простите, но XML/HTML/SGML именно тогда и зародился
V>>так что это не домыслы. это — жизнь

N>Когда это они зародились? В конце 70-х? М-да... смените траву

В конце 70-х был roff. Кстати — отличный язык разметки, не хуже SGML. И не такой многословный.

я не знаю кто тут курит траву, но википедия показывает (http://ru.wikipedia.org/wiki/SGML):

Standard Generalized Markup Language (SGML) это некий метаязык, на котором можно определять язык разметки для документов. SGML — наследник разработанного в 1960 году в IBM языка GML (Generalized Markup Language)

и далее:

SGML это стандарт ISO «ISO 8879:1986 Information processing—Text and office systems—Standard Generalized Markup Language (SGML)»

итого зарождение — между 60м и 86м, как раз ваши 70-е

Здравствуйте, vvaizh, Вы писали:

N>>>>Интересный вывод:)
V>>>какой есть
V>>>и главное из жизни очень успешной и известной компании
N>>При этом сказано 0 целых фиг десятых про то, что этой компании было нужно и что она требовала.
V>сказано было больше другое дело что ничего из сказанного не было услышано, а вернее было прослушано, высокомерно заявлено что это не проблемы и стёрто из слуховой памяти

А, так это и было то что "успешная и известная компания" накопала? OK, принято.

V>>>да главное что парсеры не сломаются об такие ошибки
N>>А лучше бы сломались, раз это ошибки.
V>это не просто ошибки, это "такие" ошибки..
V>о которых ломаться не должно

Так это ошибки или нет?

V>>>а я конкретники и не обещал, я обещал практический опыт
N>>Это не объяснение опыта разработки. Это объяснение уровня "мы тут вкурили и меня плющило". Опыт разработки должен быть выражен детально, иначе это не опыт.
V>:)
V>опыт вообще не обязан выражаться или объясняться, он либо есть либо нет, как данность!
V>его можно либо игнорировать и учиться на своих ошибках либо САМОМУ слушателю пытаться вкурить для себя

Вот именно что "вкурить". Это уже дзэн какой-то получается, а не опыт.

N>>>>Другим объясните, чтобы по тем же граблям не ходить.
V>>>дык уже и не ходят, юзают XML где только можно
N>>Что-то я не вижу переписки синтаксиса Си на XML.:)))
V>что то я не вижу там больших изменений в синтаксисе за последние кавырнадцать лет для того чтобы его переводить на XML

О.

N>>>>Ойвэй, так таки и не будут. Годами программисты нарабатывали методы, как читать не только "старые данные" но и старые форматы, как их различать и по явным указаниям, и эмпирически (если где-то не получилось пометить явно). А тут вдруг раз — и не будут.
V>>>угу.. годами.. и лучшее средство которое придемули — XML
V>>>где раскрученное средство весовой категории yacc/XML которое бы для yacc-а обеспечивало это?
N>>Что именно обеспечивало бы? Определить в начале потока какой-то признак формата и дальше выполнить "условный switch"? ЛЮБОЕ средство такое может. Тот же yacc, только надо в грамматику это вставить.
V>а зачем я должен поддерживать несколько веток для switch-а?
V>это bad smell вообще то!
V>а зачем я должен заставлять пользователя прописывать версию и следить за её актуальностью?

Пользователь как раз ничего не прописывает. Вы о чём?

N>>>>А в случае XML Вы готовы принимать данные во всех старых форматах, какие были при развитии некоторой большой и сложной программы например до 20-й версии? Или только два последних формата, а проблемы остальных оставили индейцам?
V>>>в случае XML у меня есть путь который обеспечивает способ работы со старыми форматами без переписывания или усложнения парсера
N>>А его нету без XML? М-да... Ваши заявления всё интереснее и интереснее.
V>его нету в виде промышленного решения и парадигмы
V>это не мои заявления повторяю, это опыт всей отрасли
V>а автор статьи (Голуб) вместе с вами маргинально пытается отрасли умозрительно чего то объяснить
V>даже не собираюсь вступать в дебаты
V>просто подумайте о том, что раз отрасль отказывается от классических синтаксисов на средствах типа yacc
V>то этому могут быть разные объяснения

Опять — я про то, зачем XML, а Вы — про yacc. Это и есть передовой опыт отрасли — перевод разговора на иное?
(Это я уж не вспоминаю в каких случаях вводился XML. А вводился он, как правило, вместо того, что в разы кривее,
и для описания данных, а не для программирования)

V>не только что "вся отрасль — дураки"

Этот вывод откуда? Это не мой вывод.

V>>>простите, но XML/HTML/SGML именно тогда и зародился
V>>>так что это не домыслы. это — жизнь
N>>Когда это они зародились? В конце 70-х? М-да... смените траву:) В конце 70-х был roff. Кстати — отличный язык разметки, не хуже SGML. И не такой многословный.
V>я не знаю кто тут курит траву, но википедия показывает (http://ru.wikipedia.org/wiki/SGML):
V>

V>Standard Generalized Markup Language (SGML) это некий метаязык, на котором можно определять язык разметки для документов. SGML — наследник разработанного в 1960 году в IBM языка GML (Generalized Markup Language)

V>и далее:
V>

V>SGML это стандарт ISO «ISO 8879:1986 Information processing—Text and office systems—Standard Generalized Markup Language (SGML)»

V>итого зарождение — между 60м и 86м, как раз ваши 70-е

Думаете, он 13 лет зарождался?

От:	Andir	http://twitter.com/AndirNotes
Дата:	01.10.06 03:58
Оценка:

	От:	GlebZ
	Дата:	01.10.06 12:21
	Оценка:

	От:	Turtle.BAZON.Group
	Дата:	02.10.06 04:45
	Оценка:

	От:	Turtle.BAZON.Group
	Дата:	02.10.06 04:45
	Оценка:

	От:	ArhAngelVezel
	Дата:	02.10.06 12:38
	Оценка:

	От:	rasmus_aagensson
	Дата:	19.11.06 15:07
	Оценка:

От:	vvaizh	http://izh-test.sourceforge.net/
Дата:	20.11.06 04:52
Оценка:	+1

От:	netch80	http://netch80.dreamwidth.org/
Дата:	23.11.06 21:58
Оценка:	+2

	От:	МихаилС
	Дата:	21.11.06 07:42
	Оценка: