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

V>>>>Т.е. ты сам себе ПМ, аналитик, архитектор и тот самый Вася, если тебе через 10 мин (!!!) потребовалось третье поле. ))
G>>>Как это связано? Чтобы добавить поле нужен аналитик, архитектор и еще кто-то?

V>>Ха-ха три раза.
V>>Сначала код, так?
V>>Например, для среднеразмерной складской программы?

G>Почему бы и нет? У тебя с этим проблемы?

А бизнес-процессы из головы? )))
Сколько складских программ написал уже? Сильно отличались? А вообще хоть что-то похожее было? )))


G>При чем тут внешние ностели? В большинстве NoSQL баз производительность падает до неприличных значений когда БД перестает влезать в ОП.
G>А SQL умудряется вполне достойно работать на базах объемами в сотни раз превышающими ОП на том же железе.

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


G>Но для большинства программистов разница SQL или NoSQL как раз в том как с базой работать. NoSQL предлагает самый прямолинейный подход — сериализация объектов целиком, даже думать не надо, просто вызвал Save и все. Проблемы начинаются когда данные оказываются сильно связанными, присутствуют циклы в связях. Тогда NoSQL предлагает такой же прямолинейный подход — тяни все объекты и делай join руками или делай индекс и напрямую к индексу обращайся. SQL все это делает внутри, далеко не очевидным образом, что и вызывает проблемы у программистов.

)))
Давно хотел спросить, сколько тебе лет... Можно не отвечать, это я так... )))

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

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

V>>>>>Т.е. ты сам себе ПМ, аналитик, архитектор и тот самый Вася, если тебе через 10 мин (!!!) потребовалось третье поле. ))
G>>>>Как это связано? Чтобы добавить поле нужен аналитик, архитектор и еще кто-то?

V>>>Ха-ха три раза.
V>>>Сначала код, так?
V>>>Например, для среднеразмерной складской программы?

G>>Почему бы и нет? У тебя с этим проблемы?

V>А бизнес-процессы из головы? )))
V>Сколько складских программ написал уже? Сильно отличались? А вообще хоть что-то похожее было? )))
Учетная часть везде одинаковая (двойная запись)+темпоральная часть, которая историю изменнеий хранит. Это как-бы и самая проблемная часть. А сверху уже операции относительно несложно делаются.
А в целом проще готовую платформу взять, типа 1с.



G>>Но для большинства программистов разница SQL или NoSQL как раз в том как с базой работать. NoSQL предлагает самый прямолинейный подход — сериализация объектов целиком, даже думать не надо, просто вызвал Save и все. Проблемы начинаются когда данные оказываются сильно связанными, присутствуют циклы в связях. Тогда NoSQL предлагает такой же прямолинейный подход — тяни все объекты и делай join руками или делай индекс и напрямую к индексу обращайся. SQL все это делает внутри, далеко не очевидным образом, что и вызывает проблемы у программистов.

V>)))
V>Давно хотел спросить, сколько тебе лет... Можно не отвечать, это я так... )))
Мне 29. Но я и без этого вижу, что ответить тебе нечего.

Здравствуйте, Ночной Смотрящий, Вы писали:

V>>Ну а этот сайт чего периодически выдаёт ошибку подключения к базе? Тоже Sybase?
НС>Не, MSSQL. Но тоже на С++ писано.

Но пока был на обычном ASP в прошлом, ни разу такой ошибки не было. Любопытно, у вас там было ADO, DAO или нейтивная либа доступа к MS SQL?

Я наблюдаю периодические вылеты ADO.Net не только здесь. И рядом указал одну из причин. Еще возможная причина — недетерминированное освобождение ресурсов. При хорошей нагрузке можно упереться в превышение максимального кол-ва открытых хендлов ОС. При детерминированном освобождении такое встречается всяко реже.

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

V>Здравствуйте, Ночной Смотрящий, Вы писали:

V>>>Ну а этот сайт чего периодически выдаёт ошибку подключения к базе? Тоже Sybase?
НС>>Не, MSSQL. Но тоже на С++ писано.

V>Но пока был на обычном ASP в прошлом, ни разу такой ошибки не было. Любопытно, у вас там было ADO, DAO или нейтивная либа доступа к MS SQL?

V>Я наблюдаю периодические вылеты ADO.Net не только здесь. И рядом указал одну из причин. Еще возможная причина — недетерминированное освобождение ресурсов. При хорошей нагрузке можно упереться в превышение максимального кол-ва открытых хендлов ОС. При детерминированном освобождении такое встречается всяко реже.

Снова твои фантазии. В .NET с весрии 2.0 используется пул соедиений. По умолчанию до 100 соединений в пуле. Учитывая 50 рабочих потоков в пуле asp.net, а более одного соединения на поток не нужно, то даже 100 это много.
При применении асинхронных обработчиков HTTP может быть понадобится увеличить до 1000. Лимит на количество дескрипторов — около 16 тысяч в очень древних версиях windows. В нынешних версиях упереться в лимит крайне сложно.

Будь добр укажи текст ошибки при "вылете ADO.NET", или приведи ссылку с описанием проблемы. А то ты сказки рассказываешь. Я 8 лет с .NET работаю (гораздо больше тебя судя по всему) и видел ошибок ADO.NET на порядок меньше, чем ты пишешь.

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

V>>Основной-то трафик — картинки и видео.
G>Это твои фантазии. Посмотри на Channel9, там с каждой олимпиады рассказывают что и как было сделано.

Пытаться оспорить процитированное — это жесть.
Ну и про предрендерённые странички ты тоже вежливо не откомментировал. Так же как и про наиболее вероятную скорость поступления событий.

V>>А чего же MS SQL на .NET не переписали, чтобы быстрее работал?
G>MS SQL и так с диском хорошо работает, переписывание вряд ли бы дало ченить.

Ты всерьёз в это веришь, что перепсывание MS SQL на дотнете ничего не изменит? )))))


G>Да при чем тут сервер, я про приложение. Оно же общается с кучей банкоматов, и фронтовых систем. В самой базе основная проблема — работа с диском, а не скорость исполнения кода.

Уже это не так для современных рейдов SSD. И скорость оч важна, ес-но.

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

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

V>>>Основной-то трафик — картинки и видео.
G>>Это твои фантазии. Посмотри на Channel9, там с каждой олимпиады рассказывают что и как было сделано.

V>Пытаться оспорить процитированное — это жесть.
V>Ну и про предрендерённые странички ты тоже вежливо не откомментировал. Так же как и про наиболее вероятную скорость поступления событий.
Зачем мне твои домыслы комментировать. Вот из первых уст что реально работало — http://channel9.msdn.com/Search?term=olympic%20games#ch9Search&type-session=true


V>>>А чего же MS SQL на .NET не переписали, чтобы быстрее работал?
G>>MS SQL и так с диском хорошо работает, переписывание вряд ли бы дало ченить.

V>Ты всерьёз в это веришь, что перепсывание MS SQL на дотнете ничего не изменит? )))))
Кроме того что MS угрохает на это 4-6 лет или больше, то практически ничего.



G>>Да при чем тут сервер, я про приложение. Оно же общается с кучей банкоматов, и фронтовых систем. В самой базе основная проблема — работа с диском, а не скорость исполнения кода.
V>Уже это не так для современных рейдов SSD. И скорость оч важна, ес-но.
И ты пропустил собственно вопрос. Если скорость важна, а надежность C++ кода выше, то почему процессинг на java?

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

V>Но пока был на обычном ASP в прошлом, ни разу такой ошибки не было.

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

V>Я наблюдаю периодические вылеты ADO.Net не только здесь.

Дедлок это никоим образом не вылет ADO.Net, дедлоки детектирует mssql.

V>Еще возможная причина — недетерминированное освобождение ресурсов.

Ресурсы mssql освобождаются детерминированно.

V> При хорошей нагрузке можно упереться в превышение максимального кол-ва открытых хендлов ОС.

Это не приведет к сообщению о дедлоке.

НС>Это инициатива SQL Server Team. И ломать там ничего не надо, надо просто красиво оформить доступ к телу минуя парсер SQL.
А кэш планов как будет работать? Сейчас же строка SQL является ключом для кэша.
Интересно как это будет, сейчас я могу посмотреть состояние кэша, посмотреть тексты запросов, которые находятся в кэше. А что я увижу для linq запросов, linq запросы будут показаны мне в виде как-то строки?

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

AP>Сейчас же строка SQL является ключом для кэша.

Значит не будет являться.

НС>Текста — может быть. А декомпозированный SQL запрос, на практике, в 99% случаев собирается склеиваиванием датасетов и дописыванием в предикаты по AND. Для всего этого возможностей выражений в C# за глаза.
НС>Ты же пытаешься вытащить какие то экзотические случаи, которые не в кажом проекте вообще бывают, и на основании этого заявить, что это все хуже чем фатальнейший прощелк с девэкспириенсом в твоей библиотечке, вылазящий строго на каждом запросе строго при каждой его модификации.
Видимо, твои и мои практики сильно отличаются, если для тебя склейка по AND это 99% динамического SQL-я. Вообще, мне неоднократно встречались люди, практика которых укладывалась в не динамический SQL. Не динамический SQL можно даже на хранимых процедурах оставить. Делаем кодогенерацию по хранимым процедурам и всё (это даже EF умеет). Люди разные, практики у них тоже разные, ты вот отошел от не динамического SQL, но не сильно далеко.
Но зачем себя ограничивать, если ранее известные для этого причины теперь устранены.

НС>А обоснование я увидел ровно одно — личне тебе некомфортно не видеть SQL. Браво, чо.
Не правильно делаешь акцент на мне и на SQL. Акцент надо делать вот на чем. При разработке приложения с использованием реляционной СУБД важно понимать, какой фрагмент кода является декларативным описанием запроса и обрабатывается СУБД, а какой фрагмент кода компилируется в IL и исполняется .NET рантаймом. Такое понимание необходимо, поскольку СУБД и .NET рантайм вещи совсем разные по своей природе. Абстрагирование от такого разделения ни к чему хорошему не приведет. Поэтому, да, я хочу видеть границы фрагментов кода, где декларативный запрос для СУБД, а где код, переходящий в IL. linq же всё смешивает, часть linq выражения преобразуется в SQL строку, а часть в IL.

Причем реляционные СУБД предлагают очень простой интерфейс в виде набора: колонка+значение примитивного типа. Проблема крайне прозрачна -- сделать этот набор типизированным. Зачем что-то еще делать? Это и отражено в примере интерфейсом IMessageInfo.

Практика, когда типы возникают из потребностей, является распространённой. Например, ASP.NET MVC, там model это View Model, т.е. типы, которые возникают из потребностей View.

НС>Значит не будет являться.
Получается задача сложнее, чем просто обойти парсер SQL, как ты писал выше.

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

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

Не сильно.

AP>>Получается задача сложнее, чем просто обойти парсер SQL, как ты писал выше.
НС>Не сильно.
Тем не менее, изменения в ядре СУБД потребуется сделать довольно глубоко. Для изменений глубоко в СУБД нужны веские причины. А тут мотивация совершенно непонятная, зачем вообще это делать? Зачем в ядре СУБД поддерживать ветвление LINQ/SQL?

А в SQL Management Studio можно будет писать LINQ запросы?

Если LINQ самодостаточная технология, то делайте полноценную СУБД с нуля. Если же LINQ не самодостаточен, тогда пусть не лезет куда не следует, а принимает правила базовой технологии. Правда, если честно принять правила базовой технологии, то от LINQ почти ничего не останется. Короче, как промежуточное звено LINQ неудобен, и поэтому не нужен, а полноценную СУБД никто разрабатывать не собирается, более того, там даже теория еще не до конца продумана, в отличии от того, что Кодд сделал еще в 1969 году.

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

AP>А тут мотивация совершенно непонятная, зачем вообще это делать?

1) Устранить лишний парсинг
2) Упростить создание ORM с собственными способами построения запросов.

AP> Зачем в ядре СУБД поддерживать ветвление LINQ/SQL?

Почему обязательно LINQ? Просто нетекстовый API для тех ситуаций, где сейчас SQL синтезируется. А что там на входе — LINQ, Query Builder или собственный язык запросов — неважно.

AP>А в SQL Management Studio можно будет писать LINQ запросы?

Зачем?

AP>Если LINQ самодостаточная технология, то делайте полноценную СУБД с нуля.

Зачем?

AP> Если же LINQ не самодостаточен, тогда пусть не лезет куда не следует

Детский сад.

НС>1) Устранить лишний парсинг
Какой видимый результат от этого будет? Генерация плана на порядки больше времени занимает, чем парсинг.

НС>2) Упростить создание ORM с собственными способами построения запросов.
Еще не известно что такое ORM, нужен ли он, а тут уже собираются для этого вносить изменения в ядро реляционной СУБД. Причина совсем не убедительная.

НС>Почему обязательно LINQ? Просто нетекстовый API для тех ситуаций, где сейчас SQL синтезируется. А что там на входе — LINQ, Query Builder или собственный язык запросов — неважно.
А чем текстовый запрос плох, только лишний парсинг? См. выше.

AP>>Если LINQ самодостаточная технология, то делайте полноценную СУБД с нуля.
НС>Зачем?
Затем, что для наборов кортежей (отношений) SQL хороший domain-specific language. LINQ для этого не лучше. Возможно, LINQ проявит себя лучше на специально разработанном domain-е, т.е. СУБД, написанной с нуля.

AP>>А в SQL Management Studio можно будет писать LINQ запросы?
НС>Зачем?
Хотя бы план посмотреть.

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

V>Нет. Это итог попыток использования дотнета за последние лет 10. Везде идёт отказ от него в чем-то более-менее требующем надежности и предсказуемости.

Дружище, ты меня в очередной раз поразил в самое не могу. Если ты под "везде" понимаешь те жалкие два процента задач, где вместо .net можно найти более достойную альтернативу, то таки да, там "везде идёт отказ от него в чем-то более-менее требующем надежности и предсказуемости". Я это сказал ещё в самом начале, и грамотные парни не стали терять 10 лет, чтобы это понять.

V>Серьезно. Вот огромная система, целый конгломерат приложений, всё вместе составляющих биржу, входящую в 5-ку крупнейших, уже 3 года как полностью отказалась от дотнета для чего-то более-менее серьезного, кроме неспешных задач или сайтостроения. Потратила на "игры" с этой технологией астрономические суммы. А ты с таким невинным толкаешь такие фразы. Не стыдно?

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

Разговоры про сырость технологии — это всё разговоры в пользу бедных. Проблемы были, как же без них, но за 12 лет их так или иначе порешали. Сегодня проблемы .net, если их можно назвать проблемами, давно перенесены в совершенно другую область — идёт процесс отбраковки и шлифовки архитектурных решений, парадигм, фреймворков и прочих инструментов. То, что EF7 будет переписан с нуля как раз часть такого процесса. И дело не в его внутренних багах и кривом коде, дело в неверно взятой за основу концепции.

Ты же здесь пытаешься нас убедить в том, что проблемы .net — это проблема парсинга блоба в драйвере sql провайдера. И хотя у меня в моей реальности пока никаких таких проблем не было, хотя с блобами работать приходится, ну допустим это так. Есть/была такая проблема. И что? Конец дотнету? Это же просто смешно, судить о всей технологии по одному глюку. Я ожидал всё-таки чего-то более серьёзного и привычного, вроде производительности, реалтаймности и т.п. Оказывается .net в целом проигрывает плюсам потому что в ADO.NET криво написан парсинг блобов. Вот оно оказывается в чём дело! Нужно скорее переписать этот код и всё сразу станет зашибцом и круче C++! Самому не смешно?

Что же касается плюсов, то тут вот какое дело. Я пишу на .net ещё с бета версий, т.е. довольно давно, тем не менее на C/C++ я писал всё же немного дольше и могу сказать, что более глюко-благоприятной технологии, чем C/C++ в сегодняшнем мейнстриме не существует.

Небольшое гипотетическое отставание .net в производительности легко нивелируется дешевым железом, но даже здесь не всё так просто и однозначно. Максимальная производительность сегодня в первую очередь достигается алгоритмами и архитектурными решениями. Буквально пару дней назад обсуждали требования к железу для нашей системы, и мы как разработчики затруднились ответить на вопрос каковы наши минимальные и максимальные требования к железу. Мы может спокойно израсходовать от 1 до 1000 ядер, при этом они не обязательно должны быть на одном компьютере. Соответственно, наш заказчик может получить производительность от X до X*1000, поэтому спрашивать сколько и за что он готов заплатить нужно у него. У нас только одно дополнительное требование — из-за объёма обрабатываемых данных для максимальной производительности каждое дополниетлное ядро требует дополнительно около гигабайта памяти. Остальное пусть решает заказчик.

Можно было бы сделать чуть более быструю систему на плюсах? Возможно. Только это либо вылилось бы в феерические затраты, либо в очередной феерический провал. Что в общем-то почти и произошло. Только не на плюсах, а на твоих любимых сохранённых процедурах.

Думаю, что с плюсами всё было бы гораздо хуже. Как я уже сказал, более глюко-благоприятной технологии не существует. Но сегодня к этому ещё добавляется и доминирование в этой технологии личностей с весьма негибким мышлением. У меня не так много знакомых плюсовиков, но за редчайшим исключением глядя на них, образ успешного C++ программиста — это лысеющий дядька, просидевший на жопе в одной конторе 15 лет, занимающийся парсингом какого-нибудь фида для того, чтобы платить по счетам и безумно увлечённый кто рыбалкой, кто охотой, кто оружием, машинами или музыкой. Про последнюю версию стандарта C++ не все из них знают, что она вообще есть и большинство затрудняются сказать в каком году она вышла.

V>Не боись. На многих обслуживающих нишах дотнет остался. Я бы даже сказал — его достаточно много.

Ну да. Продолжу про лысеющих дядек. В моей реальности мне дотнета бояться не надо. Как раз наоборот. Ко мне периодически обращается народ с вопросами о работе, в том числе иногда и лысеющие дядьки. При этом они понимают, что обращаются к дотнетчику и делают это исключительно от отчаяния. Их душераздирающие истории стоит послушать. Если сегодня в Нью-Йорке опытный программист несколько месяцев не может найти работу, то это можно объяснить только его специализацией — плюсами. Дотнетчики разлетаются как пирожки в базарный день. Кстати, речь идёт если что о финансовой столице мира, где в твоей реальности дотнетчикам отведена лишь участь подметать дворы банков и чистить мусорные ящики бирж.

V>Технология всё-равно сырая. В 2009-м я потратил более недели на поиски причин периодических глюков подключения к майкрософтному SQL-серваку и обнаружил рефлектором прикольный баг парсера потока от SQL-сервака, когда идёт нарезка блоб-полей... Ну что тут говорить??? В святая-святых, в драйвере общения с базой(!!!) кривой индусский код.

Это мы уже обсудили.

V>Причем, кривизна не только в том месте, где был баг. Сам код кривой до невероятности. В сравнении с нейтивными опенсорсными дровами под какую-нить БД для Линухов — это же просто детский лепет, а не драйвер клиента БД!!!

А ты уверен, что в Линухе вообще есть код, который парсит поток нарезки блоба SQL-сервера?

V>Смирись. Технология еще сырая. И я не говорю, что ты в этом виноват или любой другой программист на дотнете. Но таковы дела. Очень много функционала. Действительно много. Он бесплатен. Т.е. совершенно эта прорва функционала бесплатна. Качество не может быть хорошим в короткие сроки при таких раскладах. Просто руки не будут успевать делать всю эту прорву функционала качественно.

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

V>Морда на нете уже много лет где. А насчет "процессонговой" части любопытно. Бо самый рантайм-процессинг все-равно выполняется серверами БД, а не внешними приложениями. А внешняя аналитика или неспешный пересчет всего и вся по закрытию банковского дня может запросто быть написан на чем-то управляемом. Собсно, это уже десяток лет так и есть.

Ёлы-палы, так вы всё процесите серверами БД? А я тут C++ по ходу поласкаю. Как не хорошо получилось. Ну да ладно. Перейдём тогда к лысеющим датабазным админам, которые похоже понятия не имеют о том, что такое расширяемые системы. Или всё таки имеют? Или вы всё же умудрились запихнуть всю вашу биржу в одну единственную базу данных вместе с процессингом! Крутые всё-таки в твоей реальности сервера баз данных. У нас таких ещё не придумали.

V>Ты сидишь в крайне узкой нише разработок и считаешь, что на этом всё! ))
V>А что за пределами этой узенькой ниши — так сразу "альтернативная реальность".

Пять балов с жирным плюсом! Всё-таки я снимаю шляпу перед твоим умением выдавать желаемое за действительное. Молодец!

V>Не ты первый, кто развел крупные компании на серьезные инвестиции в никуда.



Как-то так получилось, что с моего первого проекта в штатах моя вторая профессиональная специализация — это вытаскивание провальных проектов из задницы (включая, кстати, в своё время этот сайт). На мой текущий проект меня пригласили как раз по этой причине. Кокое совпаданеи, что основная логика в этом проекте была реализована в виде сохранённых процедур. В новом проекте ни одной процедуры нет. Вместо них расширяемое на сотни ядер решение на .net. Уже сейчас видно, что по всем параметрам производительности мы впереди настолько, что этот вопрос снят с повестки дня. Но самое главное, текущая система уверенно деградирует по такому параметру как наращивание функциональности и простейшие фичи делаются неделями и с большой кровью. Мы эту проблему не то что сняли, а просто занулили.

Так ли у нас всё хорошо, потому что .net? Вовсе нет. Дурь в башке и кривые руки всё же большая причина неуспеха предыдущего проекта. Те, кто его начинал, кстати, рассматривали .net в качестве одной из альтернатив, но чего-то там у них не смоглось. .net — это в–ё же просто инструмент. Нормальный такой инструмент, который в нормальных руках позволяет делать нормальные проекты. А в тех двух процентах, где лучше использовать что-то другое, можно запросто использовать что-то другое.

Хотя в твоей реальности видимо всё по-другому.

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

V>Ну а этот сайт чего периодически выдаёт ошибку подключения к базе? Тоже Sybase?

Этот сайт месяцами работает не то что бы в отсутствии обслуживающего персонала, а вообще без присмотра. Ваша биржа так может? Хотя бы день продержаться без полчишь следящих за ней админов? Нет? А у нас легко!

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

V>Если ты называешь глюком вылет всего рантайма нафик, то у нас разные представления о глюках. Поэтому, твоё "итого" не считается.

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

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

V>А для чего в банках используется дотнет прямо на сейчас — все хорошо знают: клиентское ПО (рабочие места), отчетность, неспешная аналитика, пересчет итогов, бухгалтерия и т.д. Кароч, примерно так же, как в складских программах.

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

IT>Подавляющее большинство бизнес софта в мире пишется на технологиях вроде .net и java.
А как вот это понимать: Windows and Line of Business Applications: No Good Options?
На java ситуация точно такая же.
Получается что ни .net ни java не смогли предложить лучший UI, чем HTML/CSS/JS. А попытки были в течении нескольких лет. WPF, Silverlight в Maintenance Mode, WinRT что-то не особо взлетает. К слову, HTML/CSS/JS совсем не типизированный.