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

P>Реально смешно. Туева хуча с++ библиотек по логгированию + чуть ли не каждый пятый пишет свою, чтобы не тянуть стороннюю библиотеку. Это только на плюсах такое, когда проще написать свой велосипед, чем тянуть стороннюю библиотеку.

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

Потому что если бы со своим наивным подходом посмотрел, какой путь у нас совершают данные в нашем асинхронном логгере, у тебя бы сломался моск. )) Безблокировочность она такая, угу. Но это минимально затратно по тактам в целевом потоке обработки данных, а нам требуется именно такая минимальность.


P>И все они отличаются только синтаксисом и вкусовщиной (это ещё если отличаются) — в остальном братья-близнецы.

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


P>Или ты про тот 0.001% уникальных случаев?

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


V>>Просто на плюсах не заворачивают в дебильный XML то, что туда явно не лезет. Конечно, на плюсах используют XML аж бегом, но не так упорото, как в Джаве и дотнете. Потому что малость другие подходы. Можно и парсер конфига нарисовать или свой текстовый или бинарный протокол. Это в духе нейтива, бо в нём удобно парсить и генерить строки.
P>У тебя просто походу нет опыта работы с большими проектами (исходники больше 1 ГБ) и в больших компаниях (программеров больше 300).

С этой херней сразу в сад. Потому что и опыт есть и видел разного.
Де-факто, XML пихается повсеместно исключительно от нубства разработчиков-обезъянок.
Я ничуть не спорю с тем, что полно сценариев, когда XML вполне оправдан (декларативность/структурированность). Просто их раз в 10 меньше, чем фактических случаев использования. Потому что XML в Дотнете-Джаве часто используется вовсе дико — он используется ровно в тех сценариях, где надо описывать некие императивные действия. Т.е. в этом декларативном языке описывают AST неких императивных выражений. Во дичь-то! И это в 90% случаев использования XML. Даже если на первый взгляд система выглядит сугубо декларативной, типа как Ant/NAnt — нифига, 99% схемы этого документа описывает сугубо императивные действия, а на декларатив там оставлен жалкий 1% указания зависимостей.

Вот почему над вами ржут. Потому что вы не в состоянии ОБЪЕКТИВНО посмотреть как на свои инструменты, так и на собственные поделия. Вы живёте во лжи. Врёте себе и окружающим. Блин, ну если объективно нужна динамика — так бери динамику, какие проблемы, нахера брать XML? Существуют же кучи динамических языков. Абсолютно все из них идут в виде "движков", т.е. позволяют подключать эти движки в проект простым движением руки.


P>В таких случаях абсолютно все без исключений приходят к необходимости стандартизации и унификации.

Во-во. ))

XML не даёт стандартов на данные, он даёт стандарты для структурирования этих данных.
Поэтому, тебе всё-равно надо разрабатывать СХЕМУ документа.
Т.е. не брать некую стандартную/имеющуюся, а именно ВВОДИТЬ ее в проект, т.е. тебе в любом случае приходится СТАНДАРИЗИРОВАТЬ некий свой насос из пальца.

Ну и такой момент как читабельность. XML не читабелен от слова совсем. А ведь читабельность — это важная составляющая обслуживаемости, не?


P>Она ставится как цель номер один, иначе проект/компания утонет

Это всё нубские разговоры. По-факту в крупных компаниях процент проваленных проектов больше, чем в мелких. Посмотри сколько и каких мастабшных проектов ушло "в стол" в гугле или MS. Потому что мелкие компании не могут позволить себе нанимать толпы нубов (в том числе нубов-управленцев и архитекторов), а большие — могут. В больших компаниях большая текучка и низкий средний уровень программиста и управляющего персонала.

Поэтому, давай называть вещи своими именами — для трёхсот нубов требуются совсем другие внутренние стандарты на разработку, чем для пятидесяти профессионалов. И задача профессионалов в больших компаниях тоже отличается от задач профессионалов в небольших. Если во втором случае профессионалы непосредственно занимаются разработкой 100% времени, то в больших львиная доля профессионалов тратит своё рабочее время (и нервы!) на подтирание задниц нубам и уборкой за ними несметных туч г-на в архитектуре и непосредственно в коде.


P>Это номер раз почему "везде xml".

Да нет его "везде", уже отказываются, мода уже прошла.
Он есть только в вашем дотнете-джаве, но коробочные продукты на этих технологиях не покупаются.
Посмотри, например, на QML в QT.
Это даже не JSON, хотя близкая технология.
Какой-нить упоротый дотнечик или джавист непременнос лепил бы аналогичное на XML, а как же!


P>С xml легко работать, либы уже устоявшиеся, имеется куча утилит которые работают с xml. Не требуется иметь кучу парсеров/генераторов. Отсутствует головняк с разработкой и поддержкой кастомных парсеров/генераторов. Из-за наличия единообразия нет повышенной утомляемости, когда требуется всё время переключать контекст в мозгу.
P>Рисовать мульён своих конфигов и протоколов — это и есть тот самый инженерный идиотизм.

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

Просто ты живешь во лжи и не называешь вещи своими именами. А ни таковы, что из нейтива доступны произвольные либы парсинга и произвольные движки динамических языков с развитым АПИ, а у вас НИХРЕНА НЕТ. Поэтому, лишний раз подумаешь — то ли делать биндинг скриптового движка, то ли ну его нафик, давай опишем AST эквивалентных императивных выражений в виде XML!


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

Я прекрасно знаю как оно происходит в мире заказухи.
Слепил, втюхал, побежал дальше.
Сам активно фрилансил одно время или занимался заказной разработкой в рамках компаний.
Это свинское болото в большинстве случаев, потому что приоритеты другие — свинские.
Отсюда среднее качество решений в заказухе ниже плинтуса.


P>А xml позволяет достаточно просто и детально описать предметную область.

Нет не позволяет. Позволяет некая спека — схема документа.
И вот как посмотришь на некоторые спеки над XML, так начинаются вопросы из разряда — люди, вы чего творите-то? ))


P>Его очень легко использовать для кодогенерации.

Для кодогенерации легко использовать любое типизированное структурное представление, которое уже в памяти.
Представление в памяти XML в этом смысле — одно из самых неудобных.
Чтобы проводить по такому представлению кодогенерацию, это представление надо предварительно отобразить на некоторое типизированное и потом уже что-то такое пытаться делать.


P>С ним отсутствует большинство проблем, замечу ненужных проблем, которые решает парсеро/генераторо-писатель.

А кто мешает взять готовые решения?
А, ну да. Нет бинда под дотнет... Понимаю... ))


P>Это номер два почему "везде xml".

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


P>И пока познающие дзен размышляют как правильно спроектировать DSL или вообще сделать язык под предметную область — остальные уже запилили кодогенерацию на xml и продали.

Пипец...
За то время, которое тебе потребуется на дотнете только лишь для стадии кодогенерации, в нейтиве можно сделать проект целиком.


P>А ещё за счёт работы с БД

С БД в дотнете-джаве хуже.


P>и сетью

С сетью вообще хана.


P>и конфигами

Конфиги мы уже обсудили.


P>и плагинами

COM, WinRT — вполне компонентные технологии.
Нейтивные.

Собсно, чего-то аналогичному OLE/ActiveX ни дотнет ни джава так и не породил.
И оно востребовано в Офисных док-тах до сих пор и будет востребовано еще неизвестно сколько.
Лет 20 или больше аж бегом.


P>RPC

RPC отродясь возникло как нейтивное.
Учите матчасть.


P>асинхронность... wait, oh shit

Асинхронности в дотнете НЕТ. ))
Есть её муляж в таком зачаточном состоянии, что признать ЭТО за наличие асинхронности сложновато.

Если в нейтиве асинхронность ведёт к резкому увеличению пропускной способности, то в дотнете — к очень нерезкой.
Объект Task сам по себе настолько тяжеловесен вместе со всей инфраструктурой вокруг него, столько надо сделать процессору действий для банальной постановки задачи в очередь, что это получилась профанация асинхронности.

Ты хоть имеешь представление, почему в Task настолько тяжело приходится разбираться с SynchronizationContext?
Или никогда не интересовался?
Ну так поинтересуйся, потом приходи.

В итоге, максимум где полезна такая асинхронность а ля дотнет — сугубо в GUI, т.е. ы-ы-ы много раз.
Юзер тыкает по элементам управления максимум один раз в секунду, вот мы сейчас покажем тру асинхронность!!! )))
Тут следовало бы убиться апстену и не отсвечивать, как по мне.


P>Все проекты которые начинаются — заказывают на C#

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


P>как раз из-за скорости разработки и отсутствия рисков по сравнению с плюсами.

От предметной области зависит.
Если надо нарисовать неспешный магазинчик, то C#, Java, PHP, RoR — очень даже неплохие решения.
А если биржу — то увы.


P>Всё, что заказывают сейчас на плюсах — это мелкие утилиты (причём требуют обязательно сделать ещё и интерфейс на шарпе) и драйвера.

Всё, на чём ты работает, ну т.е. вообще всё — оно писано на нейтиве.
Даже твой дотнет.
Даже твои БД.
Даже твои веб-сервера.

Какую-бу программу ты не запустил, какой бы девайс не взял в руки — там нейтив и только нейтив.
Даже в Андроиде основные проги — нейтивные.
А всякими свистелками и перделками народ лишь недолго балуется, но каждый день пользуется сугубо нейтивными приложухами — модулем звонков, камерой и видео. На андроидной жабке там лишь 2-3 кнопки нарисованы, т.е. 0.0001% от всего кода, составляющего эти модули.


V>>Коробочные дотнетные проги в нашей реальности НЕ ПРОДАЮТСЯ, за очень малым исключением.
P>Во-первых покупаются,

Пример?


P>во-вторых — это ну очень маленький рынок по сравнению с частным бизнесом/корпорациями.

Бизнес ПО/Деловое ПО и заказное — это две большие разницы.
Например, Парус или 1С продают на 90% (грубо) коробочный продукт и на 10% конфигурируемый.
Так же есть нехилый рынок ПО, которое поставляет производитель оборудования в составе своих девайсов.
Простой пример — автомобильные системы, модули управления движком и т.д.
Там тоже почти всегда нейтив (на более чем 99% девайсов уж точно).

Так вот, если взять "чистую заказуху", т.е. которая не писана на какой-нить бизнес-платформе (которая сама по себе является коробочным продуктом/услугой), т.е. отбросить "мальчиков-1С-ников" и прочих т.н. value-added resellers, то в "чистой заказухе" останется денег и работы даже меньше, чем выделяется денег и работы на встраиваемое ПО производителями оборудования. Более того, 90% этих денег и работы сегодня сосредоточены исключительно в вебе, где эти деньги тебе, как программисту, надо делить с дизайнерами сайтов, администраторами или хостерами. Итого, собственно программистам остаётся с гулькин нос. Именно поэтому в разработке под веб хороших денег нет. Потому что есть деньги в разработке ферм, виртуализации и прочем. Но, блин, там тоже получают свои большие денюжки нифига не дотнетчики и не джависты. ))