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

eao197 wrote:

>> > В общем, нет в ХМЛ ничего такого, что делало бы его панацеей... для чего
>> > бы то ни было. Просто еще один формат данных, да еще не совсем удачный
> kan>А он и не панацея. Есть места где он неприменим, но те наезды что
> звучат здесь — мимо тазика.

> Изначально речь шла о том, что XML плох в качестве языка
> программирования. По этому поводу вы что можете сказать?
Насчёт языков программирования ещё могу согласится, но "описания тестов", "описания объектно-реляционного отображения",
"описания потоков управления" уже со скрипом, особенно, если в качестве альтернанивы предлагается написать свой
собственный компилятор, да ещё и сетует "ремесла построения компиляторов не так уж и много".

Posted via RSDN NNTP Server 2.0

>> kan>Понятно, что в данном конкретном случае ничего этого, наверное, не
>> надо. Но не надо простые случаи обобщать.
>> Так бОльшая часть случаев как раз укладывается в простые
kan>И чем такая штука была бы хуже? Чем сложнее?
kan>

kan><payment>
kan>  <key1>Value</key1>
kan>  <key2>По-русски</key2>
kan>  <key3>Ё!"№;%:?*()_+Ё!"№;%:?*()~!@#$%^&*()_+{}|<>?[\];',./</key3>
kan></payment>
kan>

kan>Зато ни у кого никаких бы вопросов не возникло бы.

Так как это payment gateway, то им критичны объемы передаваемой информации.
Что-то в стиле:

payment:1;2;34.5;;

всяко меньше, чем в ХМЛ.

>> kan>В общем уроды, могли бы заюзать url-form-encoded формат или даже
>> csv, нет, придумали свой велосипед.
>> Ну, так там примерно CSV и получился
kan>И какого хера тогда? Вместо того, чтобы взять готовый кусок кода для работы с CSV, программист вынужден писать очередной
kan>велосипед.

CSV им не особо подходит, потому что на одних значениях не уедешь, а там довольно разнообразная информация передается (аутентикация, типы карточек, суммы, типы оплат, информация о пользователе...). Жаль, я сейчас просто не вспомню, что это за gateway был

Но формат у них был легчайший. А ответы могли разбираться даже простейшим split() по какому-то символу.

... << RSDN@Home 1.2.0 alpha rev. 655>>

>>> >> > Вот вопрос. Чем их ASN.1 не устроил?
>>> > C>Ответ: назови мне 10 полностью свободных и бесплатных решений для ASN
>>> > C>для С++, Java, Perl, PHP, C, C#.
>>> > Ну вот в том-то и дело
>> kan>Кто виноват? Что делать?
>> Маркетинг виноват Подняли бы вокруг него столько же шумихи, сколько
>> вокруг ХМЛ, то же самое было бы
kan>Как ни прискорбно знать, но маркетинг обычно отражает реальные требования (тем более если учесть некоммерческое
kan>происхождение XML с w3c.org), а не "единственно верные" решения.

Тот же ASN.1 — вполне себе открытый стандарт, уже включающий в себя многое из того, чтов ХМЛ нет и не предвидится, и для чего приходится выдумывать новые стандарты. См. Re[4]: Снова XML: Just Say No to XML в самом начале, где сравнивается ASN.1 и XML.

w3c достаточно было оставить ASN.1 как есть, в текстовом формате, без компиляции, и был бы готовый новый ХМЛ. А там бы и тулзы подтянулись бы. Благо парсить его будет полегче, чем ХМЛ, да и на больших файлах он выгоднее.

Вот интересно, почему все же был выбран SGML за основу

... << RSDN@Home 1.2.0 alpha rev. 655>>

Andrei N.Sobchuck wrote:

> M>ASN.1 *XER*
> С таким названием, не удивительно, что они в массы не пошли
Есть такая штука XEP (вторая ссылка в русском гугле, не первая

Posted via RSDN NNTP Server 2.0

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

Весь смысл статьи — "Печально я гляжу на не наше поколенье" и "да молодежь нонче не та, вот в наше время.."

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

ZS>Весь смысл статьи — "Печально я гляжу на не наше поколенье" и "да молодежь нонче не та, вот в наше время.."

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

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

E>Представляю себе цепочку причинно-следственных связей:
E>

E>Используем XML чтобы не писать транслятор.
E>`-> Получили нечитабельные скрипты, используем XSTL (XML опять же)
E>    чтобы получить читабельность.
E>    `-> Невозможно преобразовать модифицированные читабельные скрипты
E>        обратно в XML.
E>        `-> Пишем транслятор читабельных скриптов чтобы преобразовать
E>            их в XML. Который нечитабельный.
E>            `-> Вспоминаем, что XML использовалься для того, чтобы не
E>                писать транслятор.
E>

Ну кто так оформляет данные?!! Вот как надо:

<?xml version="1.0" encoding="windows-1251"?>

<ns1:problem subject="не хотим писать транслятор">
    <ns1:solution rule="Используем XML">
    <ns1:problem subject="Получили нечитабельные скрипты">
        <ns1:solution rule="Используем XSLT" why="чтобы получить читабельность">
        <ns1:whatIs what="XSLT">
            <ns1:is-a-kind-of child="XSLT" parent="XML"/>
        </ns1:whatIs>
        <ns1:problem subject="Невозможно преобразовать модифицированные читабельные скрипты обратно в XML">
            <ns1:solution rule="Пишем транслятор читабельных скриптов" why="чтобы преобразовать их в XML"> <!-- XML нечитаемый -->
            <ns1:remember what="XML использовался для того, чтобы не писать транслятор">
            </ns1:solution>
        </ns1:problem>
        </ns1:solution>
    </ns1:problem>
    </ns1:solution>
</ns1:problem>

Видишь, насколько удобнее стало? А понятнее? А проще? Вот! А ты говоришь!

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

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

ZS>>Весь смысл статьи — "Печально я гляжу на не наше поколенье" и "да молодежь нонче не та, вот в наше время.."

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

Это вопрос квалификации, а не XML. Настораживает формулировка "если для задачи будет удобно сделать свой транслятор". Что заначит удобнее? Кому удобнее? Программисту Пете — фанату трансляторов и "красивых решений", а дальше хоть трава не расти?

Рассуждая в сторону, любую программу можно рассматривать как транслятор/интерпритатор/компилятор. Так что же теперь, для всех задачь придумывать свой язык? Кроме того, давно известно: больше кода — больше ошибок. Так что даже не знаю... Очень спорная статья, я бы даже сказл — провокационная.

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

ZS>Это вопрос квалификации, а не XML. Настораживает формулировка "если для задачи будет удобно сделать свой транслятор". Что заначит удобнее? Кому удобнее? Программисту Пете — фанату трансляторов и "красивых решений", а дальше хоть трава не расти?

Ну всегда удобно кому-то. Ты предлагаешь заменить Петю на Ваню, фаната xml?

ZS>Рассуждая в сторону, любую программу можно рассматривать как транслятор/интерпритатор/компилятор. Так что же теперь, для всех задачь придумывать свой язык? Кроме того, давно известно: больше кода — больше ошибок. Так что даже не знаю... Очень спорная статья, я бы даже сказл — провокационная.

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

Здравствуйте, c-smile

Заранее прошу прощения за длинное сообщение

CS>... Ну дык json то рулез я всегда говорил...

Ну не всегда. Сейчас попробовал один из своих средних размеров конфигов в JSON представить. Дошел только до половины, затем устал -- слишком много синтаксических заморочек (необходимость использования массивов, числа не имеют шестнадцатиричного представления и пр.). Вот что получилось (извиняюсь за объем, но это всего лишь половина того, что нужно):

{ "smpp_smsc" :
  [
      { "mbox" : "aag_3::smpp_smsc::<censored>" },
      { "smsc_map_mbox" : "aag_3::smsc_map::default" },

      { "ip" : "<censored>" },

      { "reconnect_timeout" : 91 },
      { "restore_timeout" : 91 },

      { "mode" : "transceiver" },

      { "db" :
        [ { "name" : "smpp_smsc/<censored>" },
          { "template_cfg" : "aag_3/smpp_smsc/oess.db_template.cfg" }
        ]
      },

      { "authentification" :
        [ { "system_id" : "<censored>" },
          { "system_type" : "<censored>" },
          { "password" : "<censored>" },

          { "interface_version" : "0x34" },

          { "addr_ton" : 0 },
          { "addr_npi" : 0 },

          { "bind_resp_timeout" : 20 },
          { "unbind_resp_timeout" : 20 }
        ]
      },

      { "channel" :
        [ { "enquire_link_timeout" : 60 },
          { "sms_data_type::smpp2smsg" :
            [ { "import_defaults" : "aag_3/sms_data_type/smpp2smsg.cfg"} ]
          },
          { "sms_data_type::smsg2smpp" :
            [ { "import_defaults" : "aag_3/sms_data_type/smsg2smpp.cfg"},
              { "type" :
                [ { "name" : "e_custom_03" },
                  { "esm_class" : "0x00" },
                  { "protocol_id" : "0x00" },
                  { "data_coding" : "0x19" }
                ]
              },
              { "type" :
                [ { "name" : "e_8bit_with_udh" },
                  { "esm_class" : "0b01000000" },
                  { "protocol_id" : "0b01111111" },
                  { "data_coding" : "0b11110110" }
                ]
              }
            ]
          },
// ...bla-bla-bla...
  ]
}

В исходном варианте было так:

{smpp_smsc
    {mbox    "aag_3::smpp_smsc::<censored>" }
    {smsc_map_mbox    "aag_3::smsc_map::default" }

    {ip "<censored>" }

    {reconnect_timeout    91 }
    {restore_timeout    91 }

    {mode "transceiver" }

    {db    "smpp_smsc/<censored>"
        {template_cfg "aag_3/smpp_smsc/oess.db_template.cfg" } }

    {authentification

        {system_id    "<censored>" }
        {system_type    "<censored>" }
        {password    "<censored>" }

        {interface_version 0x34 }

        {addr_ton    0x00 }
        {addr_npi    0x00 }

        {bind_resp_timeout    20 }
        {unbind_resp_timeout 20 }
    }

    {channel
        {enquire_link_timeout 60 }

        {sms_data_type::smpp2smsg
            {import_defaults "aag_3/sms_data_type/smpp2smsg.cfg"}
        }

        {sms_data_type::smsg2smpp
            {import_defaults "aag_3/sms_data_type/smsg2smpp.cfg"}

            {type    "e_custom_03"
                {esm_class    0x00 }
                {protocol_id    0x00}
                {data_coding    0x19} }

            {type    "e_8bit_with_udh"
                {esm_class   0b01000000 }
                {protocol_id 0b01111111 }
                {data_coding 0b11110110 } }
        }
|| ...bla-bla-bla...
}

Читабельность, имхо, чуть повыше. И писабельность

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

А вот то же самое, но в YAML. Очень компактно, но, имхо, эта же компактность и вредит читабельности:

smpp_smsc:
  mbox: aag_3::smpp_smsc::<censored>
  smsc_map_mbox: aag_3::smsc_map::default
  ip: <censored>
  reconnect_timeout: 91
  restore_timeout: 91
  mode: transceiver
  db:
    name: smpp_smsc/<censored>
    template_cfg: aag_3/smpp_smsc/oess.db_template.cfg
  authentification:
    system_id: <censored>
    system_type: <censored>
    password: <censored>
    interface_version: 0x34
    addr_ton: 0x00
    addr_npi: 0x00
    bind_resp_timeout: 20
    unbind_resp_timeout: 20
  channel:
    enquire_link_timeout: 60
    sms_data_type--smpp2smsg:
      -
        import_defaults: aag_3/sms_data_type/smpp2smsg.cfg
    sms_data_type--smsg2smpp:
      -
        import_defaults: aag_3/sms_data_type/smsg2smpp.cfg
      -
        type: e_custom_03
        esm_class: 0x00
        protocol_id: 0x00
        data_coding: 0x19
      -
        type: e_8bit_with_udh
        esm_class: 0b01000000
        protocol_id: 0b01111111
        data_coding: 0b11110110

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

ZS>>Это вопрос квалификации, а не XML. Настораживает формулировка "если для задачи будет удобно сделать свой транслятор". Что заначит удобнее? Кому удобнее? Программисту Пете — фанату трансляторов и "красивых решений", а дальше хоть трава не расти?
SH>Ну всегда удобно кому-то. Ты предлагаешь заменить Петю на Ваню, фаната xml?

Нет, даже не так, это еще бы было полбеды. На самом деле предлагается заменить программиста и разработчика системы Петю на множество Вась — пользователей этой системы. И еще не факт, что они будут фанатеть от навязанного им XML, особенно если внедряется он не ради их удобства, а просто потому что "зачем ломать голову, если есть SAX/DOM" и "не хватало нам еще тратить ресурсы на собственный парсер".

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

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

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

... << RSDN@Home 1.2.0 alpha rev. 654>>

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

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

Вы оба правы и не правы. Синтаксис одинаков если за него принимать сам ХМЛ. И разный если оговориваться, что ХМЛ уточняется специаьными конструкциями и ключевыми словами.

Что до чтения, то с одной стороны базирующиеся на ХМЛ языки проще изучать так как часть синтаксиса уже ясна, но конечно их все равно нужно изучать для понимания формата. Потому и говорят "формат основанный на ХМЛ".

Что касается применений, то ХМЛ конечно никуда не годен как основа для ЯП. Но как формат хранения данных он очень неплох. Формат на то и нужен чтобы него не читать в таком виде постянно, а чтобы хранить в нем что-то с возможностью если нужно открыть файл в текстовом редакторе и подправить что нужно. Так что для разного роде конфигов, форматов файлов (например, Word/Excel/MSBuild), форматов передачи данных по сети и т.п. он отлично подходит. А делать из чего-то панаценю и не надо.

ЗЫ

Не надо бравировать словами панацея и серебрянная пуля. Что за манера наклеивать ярлыки?

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

kan>Это семантика, не путаем, плз. Редактор обученный xsd-шкой поможет в данном случае.

Это ты путашь. Это как раз синтаксис. Семантика это интерпретация данных.

Ты же говоришь о базовм синтаксисе. Только языки базирующиеся на ХМЛ добавляют к ХМЛ свои ограничения и синтаксические правила.

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

M>В нем есть XER, кодирующий его в ХМЛ (веяние времени, однако

)

А я всегда думал, что наличие XER-а — это признак, а не моде.

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

E>

E>{ "smpp_smsc" :
E>  [
E>      { "mbox" : "aag_3::smpp_smsc::<censored>" },
E>      { "smsc_map_mbox" : "aag_3::smsc_map::default" },

E>      { "ip" : "<censored>" },

E>      { "reconnect_timeout" : 91 },
E>      { "restore_timeout" : 91 },

E>      { "mode" : "transceiver" },

E>      { "db" :
E>        [ { "name" : "smpp_smsc/<censored>" },
E>          { "template_cfg" : "aag_3/smpp_smsc/oess.db_template.cfg" }
E>        ]
E>      },
...
E>

Как-то у тебя там все неправильно (имхо) закручено — явно лишние массивы например.

Надо примерно так:

{ 
  smpp_smsc: 
  {
      mbox              :"aag_3::smpp_smsc::<censored>",
      smsc_map_mbox     :"aag_3::smsc_map::default",

      ip                :"<censored>",

      reconnect_timeout :91,
      restore_timeout   :91,

      mode              :"transceiver",
      ...
   }
}

(я использую т.н. JSON+ формат)

Заметьте, кто поставил минус на основной пост... А я что? Так, просто...

[EOF]

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

T>Заметьте, кто поставил минус на основной пост... А я что? Так, просто...

Видимо, я перевод некачественный сделал

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

VD>ЗЫ

VD>Не надо бравировать словами панацея и серебрянная пуля. Что за манера наклеивать ярлыки?

Ну, XML явно не серебрянная пуля. Это, как минимум золотая гиря.

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

..

SH>Ну всегда удобно кому-то. Ты предлагаешь заменить Петю на Ваню, фаната xml?

Я как раз про то, что удобно должно быть конечному пользователю продукта. Кроме того надеюсь ни кто не будет спорить что XML имеет множество приемуществ.

ZS>>Рассуждая в сторону, любую программу можно рассматривать как транслятор/интерпритатор/компилятор. Так что же теперь, для всех задачь придумывать свой язык? Кроме того, давно известно: больше кода — больше ошибок. Так что даже не знаю... Очень спорная статья, я бы даже сказл — провокационная.

SH>Может оказаться, что кода получится меньше. Использование скриптов — возможность вынести логику из основного кода. В результате сам "основной код" может стать проще и короче. И гибкость повысится — скрипты проще модифицировать. Я думаю, это и значит "удобнее для задачи".

Вынести логику из основного кода невозможно. Конечно если это — основная логика.

Даже если логику забить в таблицу базы данных — основной код будет уже в таблице базы данных.

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

	От:	kan
	Дата:	28.09.06 11:51
	Оценка:

От:	Mamut	http://dmitriid.com
Дата:	28.09.06 11:53
Оценка:

От:	Mamut	http://dmitriid.com
Дата:	28.09.06 12:09
Оценка:

	От:	kan
	Дата:	28.09.06 12:16
	Оценка:

	От:	ZevS
	Дата:	28.09.06 14:11
	Оценка:

От:	eao197	http://eao197.blogspot.com
Дата:	28.09.06 14:14
Оценка:

	От:	Пацак
	Дата:	28.09.06 14:43
	Оценка:	58 (3)

От:	Odi$$ey	http://malgarr.blogspot.com/
Дата:	28.09.06 15:38
Оценка:

От:	VladD2	www.nemerle.org
Дата:	28.09.06 16:57
Оценка:	+1

От:	c-smile	http://terrainformatica.com
Дата:	28.09.06 20:09
Оценка:	1 (1)

	От:	Трурль
	Дата:	29.09.06 05:02
	Оценка: