Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, gandjustas, Вы писали:
_>>>Ну и кстати для программиста csv тоже совсем не плохой формат для табличных данных — у него намного меньше накладных расходов в сравнение с остальными перечисленными. G>>Ты еще не понял, что мифические "накладные расходы" вообще никого не интересуют?
_>Даааааа? Хотя действительно, чему я удивляюсь, это же всё просто разные грани одного и того же взгляда на ПО... Ну давай посмотрим наш конкретный случай. Помнишь тот наш тестовый файлик? Расскажи, как бы ты представил эти же самые данные в формате xml? И оценим тогда размер результата в байтах...
Ты лучше скажи какой value от решения задачи, а потом поговрим.
В этом и проблема C++ — он него практической пользы (конвертируемой в деньги) очень мало.
G>>Более 95% времени программы находятся в ожидании завершения ввода-вывода. Грамотное использование асинхронности делает perceived performance достаточным для большинства приложений. _>Асинхронность вообще не имеет никакого отношения к производительности, пока у нас не ставится задача о тысячах параллельных операций.
Ты о какой производительности? Наблюдаемая пользователем производительность (http://en.wikipedia.org/wiki/Perceived_performance) от асинхронности растет ооочень сильно. Хотя при этом общее время выполнение операции может даже падать.
_>>>Кстати, уже и в самой MS сменился вектор с продавливания .net'a на другие технологии. G>>Ага, именно поэтому MS парнтерится с Xamarin, который позволяет именно на C# писать приложения для любых устройств. надеются что приложения написанные для iPhone и Android взлетят на WP. G>>А вот с Azure ситуация обратная. Чтобы продать как можно больше облаков надо сделать их пригодными для любых приложений. МС в этом преуспел.
_>Ты хочешь сказать, что совсем совсем не заметил как MS уже наверное второй год постепенно отворачиваются от .net? ))) Или всё же понимаешь о чём я? )))
Я понимаю о чем ты, и вижу что ты в этом нихрена не понимаешь, как обычно. Смотреть надо не со стороны технологий, а со стороны продаж. Тогда не будет идиотских идей про "поворачивается" и "отворачивается".
G>Ты о какой производительности? Наблюдаемая пользователем производительность (http://en.wikipedia.org/wiki/Perceived_performance) от асинхронности растет ооочень сильно. Хотя при этом общее время выполнение операции может даже падать.
Мне эта мантра про await/perceived performance напомнила:
Because it's got electrolytes perceived performance!
Здравствуйте, alex_public, Вы писали:
_>Это да, я утверждал такое... И собственно это очевидно так и есть. Т.к. все возможности C# можно повторить на C++, а вот часть возможностей C++ (в основном реализуемых через метапрограммирование или же наоборот на самом низком уровне) на C# повторить невозможно.
Ну повтори query comprehension и Expressions.
I>>А вот, скажем, новый компилер шарпа писаный на шарпе рвёт в хлам старый компилер шарпа писаный на плюсах. Странно, да ?
_>Это вообще ни о чём не говорит. Современные версии компиляторов C++ тоже делают старые.)))
Старый он условно старый — C# 5.0 все еще на с++, и рослин рвет его в хлам.
I>>Числодробилок раз два и обчелся. А всё остальное упирается в алгоритмы или ввод вывод.
_>Как бы это сказать попроще... ) Если бы это было правдой, то у меня на компьютере точно было бы установлено хотя бы несколько модных .net программ (уж за более чем десятилетие должны же были появиться такие).
Вероятно ты пользуешься одним и тем же набором программ
>Но из более чем 250 папок в Program Files насколько я помню ни одна не работает через .net. Раньше правда была одна такая мощная папка (Visual Studio), но уже несколько лет как ушёл и с неё. И то это не особо аргумент, т.к. для MS это был скорее их обычный пиар технологии. Так что похоже мифом у нас являются как раз перспективы .net. )))
Большие продукты в общем случае не переписываются. Так что это не аргумент.
_>Забавная история. ) Только вот она как раз в точности подтвердила именно мою мысль, что в руках профи и сомнительный инструмент будет эффективнее чем самый мощный в руках неумехи.
Стало быть у тебя есть хороший аналог паттерн-матчинга на с++. Самое главное — что бы алгоритм можно было менять на раз, а не тратить месяцы времени.
Здравствуйте, alex_public, Вы писали:
I>>1 вариант сама функция запускает кучу параллельных цепочек
_>И на C++ и на C# это не сделать без переписывания нашей библиотечной функции. Ну а с переписыванием понятно что проблем уже нет нигде... )))
Итого — 1й вариант надо переписывать.
I>>2 вариант — функция запускается в нескольких паралельных цепочках
_>На C# это опять же записывается только с переписыванием функции. На C++ это получается автоматически, без переписывания. Но и в том и в другом случае, такой код не является корректным, если в асинхронном хранилище данных не предусмотрена какая-то своя синхронизация.
В асинхронном хранилище такое как раз и не предусматривается. Там будут функции навроде read(value, callback)
Итого — 2 вариант требует переписывать. В сумме остаётся следующее — не важно, какой язык, для корректной асинхронщины код надо переписать. В C# это будет async/await, в с++ — приседания с каким нибудь фремворком.
То есть, в кратце, способ который вы с EP предлагаете, имеет смысл в частных случаях, когда во всех возможных цепочках нет разделяемых ресурсов. Как только они появляются, весь код надо переписывать.
В C# ты сразу видишь async/await и надо проанализировать только сам конкретный метод. Все остальное сделает компилер.
В С++ ты не можешь сказать ничего, глядя только в конкретный метод. А ну как хрен знает на какой глубине вызовов сработает короутина ?
то есть,
Begin();
Processing();
End();
Вот такой код потенциально некорректный, если хрен знает гду унутре Processing сработает короутина.
И для того, что бы не гадать над возможными путями выполнения программы придумали async/await.
То есть, асинхронщина это слишком большая деталь, что бы её игнорировать.
>Ну или же ещё будет нормальное если она вообще не требуется (например мы запускаем параллельное скачивание 10 файлов) по условию задачи.
Если только скачать, ничего с ними не делать и даже результат скачивания не важен, то да, всё сильно
Здравствуйте, Ikemefula, Вы писали:
I>Ну повтори query comprehension и Expressions.
Ты не решение из C# назови, а задачку. ))) Ведь никто же не будет повторять кривые реализации, если есть более удобные...
I>Вероятно ты пользуешься одним и тем же набором программ
Не, частенько новый софт ставлю. Вот недавно добавил Double Commander вместо сочетания Проводник/Far, а перед этим BitTorrent Sync, а ещё раньше Zim. А ещё самолётики (world of warplanes) весной ставил. Это то, что прямо с ходу вспомнилось. ))) Да и вообще цифра в 250 папок должна была навести на мысли... И нигде никаких намёков на .net.
Но ты лучше приведи свои примеры, какой .net софт стоит у тебя на компе. Ну кроме VisualStudio, которая особый случай...
I>Стало быть у тебя есть хороший аналог паттерн-матчинга на с++. Самое главное — что бы алгоритм можно было менять на раз, а не тратить месяцы времени.
Реально мощный паттерн-матчинг я знаю только в одном языке — в Прологе. Во всех остальных это обычно просто продвинутые версии switch'a... ))) В C++ такое чаще всего реализуется прямо в коде через перегрузку. Но можно и написать библиотечку на эту тему, например такую: https://parasol.tamu.edu/~yuriys/pm/.
Да, всё так. Кроме одного нюанса... Правда этот нюанс меняет всю картину. )))
Ты так пишешь, как будто бы сценарий запуска нескольких параллельных асинхронных операций на одних и тех же данных является основным. В то время как на мой взгляд основной сценарий как раз с последовательным запуском (с которым никаких проблем нет), а для твоего сценария я вот даже так с ходу и не могу подобрать задачку... Т.е. теоретически то я такое допускаю, но ни разу ничего подобного не припомню.
Вот приведи хоть один реальный практический пример такого...
Здравствуйте, alex_public, Вы писали:
I>>Ну повтори query comprehension и Expressions.
_>Ты не решение из C# назови, а задачку. ))) Ведь никто же не будет повторять кривые реализации, если есть более удобные...
Задачка простая — есть несколько вариантов хранилища, обеспечить единый интерфейс для них, что бы всё было типизировано и смена провайдера не требовала бы переписывание приложения.
_>Не, частенько новый софт ставлю. Вот недавно добавил Double Commander вместо сочетания Проводник/Far, а перед этим BitTorrent Sync, а ещё раньше Zim. А ещё самолётики (world of warplanes) весной ставил. Это то, что прямо с ходу вспомнилось. ))) Да и вообще цифра в 250 папок должна была навести на мысли... И нигде никаких намёков на .net.
wowp частично на питоне написан, кстати говоря, который еще более тормозной чем .net, странно да ?
_>Но ты лучше приведи свои примеры, какой .net софт стоит у тебя на компе. Ну кроме VisualStudio, которая особый случай...
У меня по большому счету только вижла, офис и фиддлер, они требуют .net не ниже 2.0
Проги которые приходится иногда ставить, требуют периодически .Net, но я как то уже не слежу, что на чем написано.
I>>Стало быть у тебя есть хороший аналог паттерн-матчинга на с++. Самое главное — что бы алгоритм можно было менять на раз, а не тратить месяцы времени.
_>Реально мощный паттерн-матчинг я знаю только в одном языке — в Прологе. Во всех остальных это обычно просто продвинутые версии switch'a... ))) В C++ такое чаще всего реализуется прямо в коде через перегрузку. Но можно и написать библиотечку на эту тему, например такую: https://parasol.tamu.edu/~yuriys/pm/.
Эта библиотечка ничем не лучше визитров — объем выхлопа почти такой же и проблемы ровно такие же — она расширяется как и визиторы, через одно место. У ПМ основное достоинство это компактный прозрачный код и тривиальная расширяемость.
Здравствуйте, alex_public, Вы писали:
_>Ты так пишешь, как будто бы сценарий запуска нескольких параллельных асинхронных операций на одних и тех же данных является основным.
Да, как правило всегда есть несколько паралельных цепочек. Например сихронизация локальной базы с сервером .
>В то время как на мой взгляд основной сценарий как раз с последовательным запуском (с которым никаких проблем нет), а для твоего сценария я вот даже так с ходу и не могу подобрать задачку... Т.е. теоретически то я такое допускаю, но ни разу ничего подобного не припомню.
Потому, что сложно использовать такие вещи как асинхронные притимивы синхронизации.
Сколько можно флеймить абсолютно посторонними технологиями? Что бы ни сделали в C# или примотали изолентой к Си++, это их сугубо личные дела. Главное — что Ди как-то продирается сквозь 30-летнюю скорлупу сознания и уже выходит в обсуждаемые языки. Если каждый уделит время для изучения хотя бы возможностей языка, сообщество профи перестанет быть таким плюсово-однобоким: Ди уже показал, что главный его курс — мэйнстрим, а количество исправленных С++-недоразумений зашкаливает, так что Ди — вполне осязаемая надежда писать нативные приложения и при этом не быть на крючке мелкософта.
Здравствуйте, Ikemefula, Вы писали:
I>Задачка простая — есть несколько вариантов хранилища, обеспечить единый интерфейс для них, что бы всё было типизировано и смена провайдера не требовала бы переписывание приложения.
Мммм, так это же простейшая вещь, если я правильно тебя понял. Например для доступа в многочисленные sql базы обычно делают единый интерфейс. И на C++ таких решений естественно тоже полно. В чём проблема то? Или ты про что-то другое?
I>wowp частично на питоне написан, кстати говоря, который еще более тормозной чем .net, странно да ?
Почему странно? ) Я сам его использую частенько, в том числе и в паре с C++.
I>У меня по большому счету только вижла, офис и фиддлер, они требуют .net не ниже 2.0
Офис написан на .net? ) Это с какой версии интересно? ))) Я конечно самые последние не ставил, но моя явно не на .net и что-то сомневаюсь, что они решили его переписать именно сейчас...
I>Проги которые приходится иногда ставить, требуют периодически .Net, но я как то уже не слежу, что на чем написано.
В общем, как я понимаю, ты тоже не можешь назвать у себя на компе ни одного продукта написанного на .net? ))) Да, а посмотреть то это довольно просто — изучаешь есть ли библиотека .net'a в списке зависимостей exe...
Кстати, обрати внимание, что часть поставленных мною продуктов в последнее время — это совсем молодые проекты. Так что отмазка типа "просто старый софт нет смысла переписывать" совсем не работает...
I>Эта библиотечка ничем не лучше визитров — объем выхлопа почти такой же и проблемы ровно такие же — она расширяется как и визиторы, через одно место. У ПМ основное достоинство это компактный прозрачный код и тривиальная расширяемость.
Ты не внимательно посмотрел. ) Кстати, я там заметил ещё один забавный момент связанный именно со сравнением языков не по скорости (чем в основном заняты авторы), а по коду... Если ты скачаешь архив с библиотекой, то увидишь там в корне 3 файла: cmp_cpp.cxx, cmp_haskell.hs, cmp_ocaml.ml. Они там естественно для сравнения производительности... Но меня повеселило другое. В варианте haskell и ocaml мы имеем здоровенные таблицы типов... А в C++ варианте нет ничего подобного — всё решено через циклы! ))) Это не плохой пример для тех, кто недооценивает возможности метапрограммирования... )
Это уже было в этой темке, чуть выше. И что-то никто так и не отреагировал...
E>Сколько можно флеймить абсолютно посторонними технологиями? Что бы ни сделали в C# или примотали изолентой к Си++, это их сугубо личные дела. Главное — что Ди как-то продирается сквозь 30-летнюю скорлупу сознания и уже выходит в обсуждаемые языки. Если каждый уделит время для изучения хотя бы возможностей языка, сообщество профи перестанет быть таким плюсово-однобоким: Ди уже показал, что главный его курс — мэйнстрим, а количество исправленных С++-недоразумений зашкаливает, так что Ди — вполне осязаемая надежда писать нативные приложения и при этом не быть на крючке мелкософта.
Согласен со всем, кроме последней фразы — она явно не про нашу реальность (в которой живут gcc, clang, или вообще Intel). )))
Здравствуйте, alex_public, Вы писали:
_>Мммм, так это же простейшая вещь, если я правильно тебя понял. Например для доступа в многочисленные sql базы обычно делают единый интерфейс. И на C++ таких решений естественно тоже полно. В чём проблема то? Или ты про что-то другое?
Давай проверим. Ты пишешь код для оракла, даёшь его мне. Я запускаю его против моей базы и все должно работать без перекомпиляции, меняем только строчку конфигурации.
I>>wowp частично на питоне написан, кстати говоря, который еще более тормозной чем .net, странно да ?
_>Почему странно? ) Я сам его использую частенько, в том числе и в паре с C++.
Тогда почему у тебя возникает удивление на счет дотнете ? Очевидно — куча задач не требует битовыжимания.
I>>У меня по большому счету только вижла, офис и фиддлер, они требуют .net не ниже 2.0
_>Офис написан на .net? ) Это с какой версии интересно? ))) Я конечно самые последние не ставил, но моя явно не на .net и что-то сомневаюсь, что они решили его переписать именно сейчас...
Процитируй, пожалуйста, где я написал что офис написан на дотнете.
_>В общем, как я понимаю, ты тоже не можешь назвать у себя на компе ни одного продукта написанного на .net? ))) Да, а посмотреть то это довольно просто — изучаешь есть ли библиотека .net'a в списке зависимостей exe...
Ты наверное хочешь сказать чтото вроде "раз никто не переписал офис на дотнете, значит дотнета в природе нет".
Я вот 10 лет проработал в конторе, которая новые продукты сделала на дотнете/Джаве. Эти продукты включают в себя сапр и вещи навроде того. Их можно считать или нет ? Старые версии были все плюсовые.
_>Кстати, обрати внимание, что часть поставленных мною продуктов в последнее время — это совсем молодые проекты. Так что отмазка типа "просто старый софт нет смысла переписывать" совсем не работает...
Здравствуйте, Ikemefula, Вы писали:
I>Давай проверим. Ты пишешь код для оракла, даёшь его мне. Я запускаю его против моей базы и все должно работать без перекомпиляции, меняем только строчку конфигурации.
Да без проблем. ) Только вот я думаю, что мы обойдёмся в данном случае без придумывания и тестирования своих примеров, а ты просто глянешь сюда http://soci.sourceforge.net.
I>Тогда почему у тебя возникает удивление на счет дотнете ? Очевидно — куча задач не требует битовыжимания.
Как бы Питон привносит минусы (ухудшение скорости, типобезопасности) относительно C++, но взамен даёт гору своих плюсов. Соответственно во многих ситуациях этот компромисс становится выгоден. А C#, при известных нам минусах, не привносит считай вообще никаких плюсов. Ну разве что только возможность использовать индусов в проекте, что для нас совсем не актуально.
I>Я вот 10 лет проработал в конторе, которая новые продукты сделала на дотнете/Джаве. Эти продукты включают в себя сапр и вещи навроде того. Их можно считать или нет ? Старые версии были все плюсовые.
Это продукты для открытой продажи или внутрикорпоративные/для заказчика?
_>>Кстати, обрати внимание, что часть поставленных мною продуктов в последнее время — это совсем молодые проекты. Так что отмазка типа "просто старый софт нет смысла переписывать" совсем не работает... I>Системнозависимый командер ?
Хы, вообще то он как раз работает под кучей разных ОС: http://doublecmd.sourceforge.net, но в данном случая я имел в виду не его, т.к. он всё же не совсем новый продукт. А вот если взять BitTorrent Sync например...
Здравствуйте, alex_public, Вы писали: _>Да без проблем. ) Только вот я думаю, что мы обойдёмся в данном случае без придумывания и тестирования своих примеров, а ты просто глянешь сюда http://soci.sourceforge.net.
А как там разруливать ситации, когда в случае MS SQL нужен TOP, а MySQL — LIMIT ?
Здравствуйте, alex_public, Вы писали:
I>>Давай проверим. Ты пишешь код для оракла, даёшь его мне. Я запускаю его против моей базы и все должно работать без перекомпиляции, меняем только строчку конфигурации.
_>Да без проблем. ) Только вот я думаю, что мы обойдёмся в данном случае без придумывания и тестирования своих примеров, а ты просто глянешь сюда http://soci.sourceforge.net.
Это каменный век. Нужна поддержка компилятором всех типов. Т.е. переименовал колонку и прога не скомпилилась.
I>>Тогда почему у тебя возникает удивление на счет дотнете ? Очевидно — куча задач не требует битовыжимания.
_>Как бы Питон привносит минусы (ухудшение скорости, типобезопасности) относительно C++, но взамен даёт гору своих плюсов. Соответственно во многих ситуациях этот компромисс становится выгоден. А C#, при известных нам минусах, не привносит считай вообще никаких плюсов. Ну разве что только возможность использовать индусов в проекте, что для нас совсем не актуально.
У дотнета для десктопа ровно два недостатка — долгое время запуска и отсутствие кроссплатформенности. Все питоновские, джавовские приложения кроссплатформенные, но имеют кучу своих проблем. По перформансу они все сливают дотнету.
I>>Я вот 10 лет проработал в конторе, которая новые продукты сделала на дотнете/Джаве. Эти продукты включают в себя сапр и вещи навроде того. Их можно считать или нет ? Старые версии были все плюсовые.
_>Это продукты для открытой продажи или внутрикорпоративные/для заказчика?
Продукты, но не для открытой продажи.
_>>>Кстати, обрати внимание, что часть поставленных мною продуктов в последнее время — это совсем молодые проекты. Так что отмазка типа "просто старый софт нет смысла переписывать" совсем не работает... I>>Системнозависимый командер ?
_>Хы, вообще то он как раз работает под кучей разных ОС: http://doublecmd.sourceforge.net, но в данном случая я имел в виду не его, т.к. он всё же не совсем новый продукт. А вот если взять BitTorrent Sync например...
Это не важно, под какими ОС он работает. Он юзает напрямую АПИ которое в менеджед большей частью напрямую недоступно. Кроме того, кроссплатформенностью дотнет не отличается.
Здравствуйте, Ikemefula, Вы писали:
I>Это каменный век. Нужна поддержка компилятором всех типов. Т.е. переименовал колонку и прога не скомпилилась.
Эээ что? ) Ты хочешь переименовать колонку в базе данных, ничего не трогать в программе и чтобы всё работало по прежнему? Или что?
I>У дотнета для десктопа ровно два недостатка — долгое время запуска и отсутствие кроссплатформенности. Все питоновские, джавовские приложения кроссплатформенные, но имеют кучу своих проблем. По перформансу они все сливают дотнету.
Ты что-то всё напутал. Сравнение вообще не такое.
1. У нас есть C++. Это максимальная производительность и нормальное удобство написание кода. Требует серьёзного умения.
2. У нас есть языки типа Питона. Это во много раз худшая производительность и проблематичное написание сложных проектов. Однако взамен намного более быстрое написание кода.
3. У нас есть Java/C#. Это несколько меньшая производительность чем пункт 1 и заметно большая чем 2. И такое же удобство написание кода как в пункте 1. Или даже местами хуже, если уместно метапрограммирование. Но порог вхождения заметно ниже пункта 1.
Из этой схемки очевидно следуют оптимальные ниши для данных технологий. Для варианта 2 явно оптимальны различные скрипты (как внешние, так и внутренние) и небольшие проекты не требующие серьёзной производительности. Вариант 3 подходит для случая потребности использовать в команде орду индусов. Ну и соответственно вариант 1 для всех остальных случаев. Что полностью подтверждается раскладом по софту на компе среднестатистического юзера.
I>Продукты, но не для открытой продажи.
Почему-то я так и думал... )))
I>Битторент написан на пейтоне
Вообще то нет. ) Но даже если бы и так, то всё равно же не .net. )))
Здравствуйте, alex_public, Вы писали:
_>Эээ что? ) Ты хочешь переименовать колонку в базе данных, ничего не трогать в программе и чтобы всё работало по прежнему? Или что?
Я хочу что бы компилятор подсказал _все_ ошибки.
_>Ты что-то всё напутал. Сравнение вообще не такое.
_>1. У нас есть C++. Это максимальная производительность и нормальное удобство написание кода. Требует серьёзного умения.
Я не сильно в курсе, как проверить "нормальное удобство". Предложишь хороший тест ?
_>3. У нас есть Java/C#. Это несколько меньшая производительность чем пункт 1 и заметно большая чем 2. И такое же удобство написание кода как в пункте 1. Или даже местами хуже, если уместно метапрограммирование. Но порог вхождения заметно ниже пункта 1.
И с удобством ровно тоже что и выше — не ясно как померить.
_>Из этой схемки очевидно следуют оптимальные ниши для данных технологий. Для варианта 2 явно оптимальны различные скрипты (как внешние, так и внутренние) и небольшие проекты не требующие серьёзной производительности. Вариант 3 подходит для случая потребности использовать в команде орду индусов. Ну и соответственно вариант 1 для всех остальных случаев. Что полностью подтверждается раскладом по софту на компе среднестатистического юзера.
Питон давно уже перерос стадию скриптов и небольших проектов. Для орды индусов дотнет и джава слишком сложные.
I>>Продукты, но не для открытой продажи.
_>Почему-то я так и думал... )))
У конкурентов ровно тоже вне зависимости от ЯП
I>>Битторент написан на пейтоне
_>Вообще то нет. ) Но даже если бы и так, то всё равно же не .net. )))
Вообще то на питоне. Причины я уже указал. Как видишь, эти самые причины кроются совсем не в производительности.
Здравствуйте, Ikemefula, Вы писали:
I>Я хочу что бы компилятор подсказал _все_ ошибки.
Это компилятор должен в процессе работы к базе обращаться? ) Иначе как ты отследишь все ошибки, если при работе с базой данных они возникают в основном в самой базе в динамике и зависят от структуры таблиц?
I>Я не сильно в курсе, как проверить "нормальное удобство". Предложишь хороший тест ?
Не нужен тест. Мы просто фиксируем какой-то определённый уровень, относительно которого и будем дальше рассуждать. Т.е. нет абсолютной шкалы, но сравнить два конкретных языка и сказать какой из них удобнее в какой-то области вполне можно.
I>И с удобством ровно тоже что и выше — не ясно как померить.
А что не ясного? Если не учитывать области, где полезно применение метапрограммирования или же каких-то совсем низкоуровневых возможностей, то в остальном решения ня C++, C# и Java будут иметь довольно похожую структуру (в отличие от скажем решений на динамических языках). И соответственно удобство разработки будет довольно близким.
I>Питон давно уже перерос стадию скриптов и небольших проектов. Для орды индусов дотнет и джава слишком сложные.
Сложный проект без статической типизации? Да ну нафиг такой мазохизм...
I>Вообще то на питоне. Причины я уже указал. Как видишь, эти самые причины кроются совсем не в производительности.
Хотя действительно, чему я удивляюсь, это же всё просто разные грани одного и того же взгляда на ПО... Ну давай посмотрим наш конкретный случай. Помнишь тот наш тестовый файлик? Расскажи, как бы ты представил эти же самые данные в формате xml? И оценим тогда размер результата в байтах...
