Это можно понимать как частное мнение какого-то чувака.
AP>Получается что ни .net ни java не смогли предложить лучший UI, чем HTML/CSS/JS. А попытки были в течении нескольких лет.
Чем HTML лучше того же WPF и что вообще подразумевается под "лучший UI"?
AP>WPF,
Ну не знаю. По мне так вроде нормально работает. Есть, конечно, косяки, в том числе касающиеся не только производительности. Например, сама по себе вполне качественная идея обезображена местами кривой имплементацией. Что касается производительности, то с ней всё впорядке, если не увлекаться кривыми левыми контролами и самому не злоупотреблять вложенностью контролов.
XAML — это по сути один большой костыль. Парни из MS вроде как сообразили, что для разметки UI пора делать свой собственный DSL, но не решились его сделать по человечески как тот же Razor, например. Вот и получился редкосный уродец на XML, который у нас в таких случаях выступает как универсальный всемогутор-языкозаменитель.
Всё это по сути лишь подтверждение моих слов о том, что идёт отбраковка и шлифовка.
AP>Silverlight в Maintenance Mode,
MS убила Silverlight по причине того, что оно как бы не пошло в вебе. При этом они совершенно не разглядели бизнес применения Silverlight. Идиоты, что тут можно сказать. В моей предыдущей конторе в MorganStanley Silverlight приложения начали расти как грибы. Очень удобно. C одной стороны C# и все прелести полноценного UI, с другой веб и zero deployment. И тут вдруг нате вам, технология перестаёт развиваться. Козлы, блин.
AP>WinRT что-то не особо взлетает.
Если ты про бизнес задачи, то он никогда и не взлетит. Для бизнес задач, функциональность которых сводится к размазыванию грязи пальцем по экрану вполне приспособлен и веб интерфейс. А что-то более серьёзное в концепцию тачскрина не вписывается.
AP>К слову, HTML/CSS/JS совсем не типизированный.
И в этом его главная проблема.
ЗЫ. А какие у нас имеются альтернативы UI на C++?
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, SleepyDrago, Вы писали:
SD>я скажу за игропром — все инструменты по созданию/редактированию внутриигрового контента на дотнете (те самые гуи). https://github.com/SonyWWS/ATF как паблик линк. Про контору где я, ничего писать не могу. Могу только молчать как рыба и глазами сигналить что ты в альтернативно-реальном бреду. Так что в рантайм игры ничего дотнетного не попадает, но кода на дотнете не меньше чем.
Ты невнимательно меня читал, похоже. У нас тоже 99% утилит на дотнете.
Раньше GUI вообще на VB или Delphi писали. А в AutoCAD даже на своём диалекте Лиспа. Что как бы заранее показывает вычислительные требования к GUI продуктов-утилит.
Физический/графический игровой движок у вас на дотнете или как?
А если не на дотнете, то можно узнать — почему?
Здравствуйте, gandjustas, Вы писали:
G>Я вот смотрю на Visual Studio, которая на WPF, и не понимаю о чем ты говоришь.
А я говорил, что ты не понимаешь нифига. Visual Studio вышла до выхода WinRT. Более того, она должна работать даже на тех версиях виндов, где WinRT не поддерживается. Более того, запуск студии в 5-15 секунд никого не волнует. Это же утилитное приложение. Вот если бы виндовый калькулятор запускался 5-15 секунд, то никто бы его не использовал. Вот почему в коробочных продуктах фактически нет WPF.
G>А если учесть что из WPF родился UI для Windows 8 и Windows Phone, то не понимаю вдвойне.
А я говорил, что ты не понимаешь нифига. Этим UI должен был стать дотнетный "Авалон". Поищи по "Avalon Longhorn".
Avalon offers a fundamental change in how you interact with your computer, and is probably the most significant UI change since Windows 1.0. It promises fundamental changes in technology, such as the way graphics are buffered internally. These features will include more efficient integration with sound and video, complex graphics displays, and sophisticated use of transparency. Microsoft believes the real advances here will come when experts in human computer interactions are free from the limitations of Win32 and can develop new controls and techniques that offer more of an immersive experience.
Так вот. Эпик фейл WPF в том, что он так и не стал Авалоном. Заодно ЗАДЕРЖАЛ выход новых виндов более чем на 5 лет. Windows Vista должна была быть последним фейс-лифтом старых виндов, типа как Windows 98 перед Windows XP. А по-факту Windows Vista задержалась на 8 лет как основная операционка в виде "ребрендинга" Windows 7. И эта задержка могла бы продолжаться вечно, если бы не волевое решение переписать нафик Авалон на нейтиве.
Microsoft officials earlier this month announced the company is cutting some key features, such as the WinFS file system, from Longhorn, the next major version of Windows, to meet its late-2006 deadline.
Из Вики:
Windows 8 — операционная система, принадлежащая к семейству ОС Microsoft Windows, в линейке следующая за Windows 7 и разработанная транснациональной корпорацией Microsoft. Номер версии в линейке NT — 6.2. Поступила в продажу 26 октября 2012 года.
6 лет задержки из-за того, что дотнет так и не стал обладать необходимыми потребительскими характеристиками.
Масштаб этого эпик фейла не поддаётся осмыслению. Собсно, именно с конца 2006-го года начался обратный отсчет уровню доверия дотнету, как универсальной платформе. Прямо на сегодня этот уровень нулевой. Дотнет нифига не универсален, а занял лишь те ниши, в которых неплоха была и Джава. На этом всё.
V>>Тебя в гугле видимо забанили. ))) G>Видимо да, ибо гугл не находит IP телефонию на .NET, которая должна была переплюнуть Asterisk, никаких свидетельств что такие проекты вообще были.
G>Хоть пару ссылок приведи для подтверждения своих слов.
В 2005-2006 годах я занимался этим вопросом много и видел много таких проектов. На сегодня они не актуальны, ес-но, т.к. вопрос можно считать закрытым. Можешь поискать еще кодеки, например по speex dotnet. Я сходу нашел NAudio, например. Но более детальное знакомство показало, что для того же speex используется нейтивный кодек, хотя в проекте NSpeex были планы по релизу "родного" дотнетного кодека. Собсно, перевести открытый исходник на дотнет — это 2-3 дня работы разработчику средней руки. Я видел в те времена несколько "родных" дотнетных реализаций кодеков. Один из кодеков на дотнете как-то публиковал здесь я, для G.711. Портирование его из нейтива заняло меньше часа. Пользовали это в своих проектах. Характеристики производительности ни к черту. Поэтому, дотнет остался только для макетирования всех этих вещей, для боевого применения более половины движка переписали на нейтив, оставив дотнету только сигналинг.
Если сможешь заставить работать быстрее — велкам. )) При том, что этот кодек до невозможности примитивен, в сравнении с тем же speex.
V>>Существовала одно время потребность в полностью байткодных приложениях. Тогда еще по наивности носились с "бинарной" переносимостью. Оч многие проекты были сделаны на дотнете. Сосредоточься. Не обязательно переписаны существующие, как бедняга EverNote или яховский мессенджер. G>Какие например? Paint.NET до сих пор живет и развивается.
Paint.Net не требует быстродействия. Вообще. Я разработал графический редактор для конференций на дотнете в 2006-м, где участники конференций могут рисовать на одной доске совместно. Никакой скорости не требуется. Вообще. Потому что основные тормоза от самой сетки. Потому что события даже от самых крутых мышек поступали не чаще 100 раз в секунду. Более того, мой редактор векторный, участники конференций могут изменять объекты, нарисованные другими участниками. Это намного сложнее растровой графики.
В плане требований к производительности сравни с теми же нейтивными фильтрами для фотошлёпа, где даже на современных рабочих станциях хочется добавить мощщи. На дотнете это просто не влетит. От слова вообще. Се ля ви.
G>EverNote написали на .NET, получили инвестиции, пошли переписывать на C++. С таким баблом можно было и на ассемблере написать. А бекенд то на .NET и остался. Если бы начали на C++, то не то что инвестиций, даже релиза не было бы.
Не юли. ЗАЧЕМ они переписали клиента под нейтив? Причем, он переписан под нейтив на кучи мобильных платформ в т.ч.
Вот нафига было переписывать со сверхудобного дотнета на страшный и ужасный нейтив? Твои варианты?
G>Я видел пару таких проектов. Пролетели чисто по экономическим причинам. Для вытеснения конкурентов надо было 50+ человеко-лет работы вложить, а никто столько кормить не будет. Это сейчас, с развитием персональных устройств, можно создавать нишевые продукты и продавать их достаточно массово чтобы окупить затраты, а 10 лет назад такой возможности не было. Рынок уже был насыщен приложениями, а ниши были слишком узкими, чтобы на них реально зарабатывать.
А я видел кучу влетевших нейтивных продуктов в то же самое время, хотя, нейтивные, как ты понимаешь, требуют больше человеко-лет, так?
Так вот, по опыту серьезной разработки на дотнете и нейтиве одновременно я уже делился с тобой своими собственными наблюдениями еще пару лет назад (или даже больше). На дотнете можно оч быстро накидать "макет". Можно даже заставить его работать при полной функциональности. Затем, при попытке выжать эффективность с этого "макета" мы обнаруживаем, что вложения трудоёмкости оч быстро переплёвывают вложения трудоёмкости в сравнении с нейтивным вариантом. Ну т.е., когда такое же кол-во усилий по вылизыванию тратишь на нейтив, то результат просто несравнимый не в пользу дотнета. Поэтому, дотнет хорош там, где никакую эффективность ни от куда выжимать не надо, а надо чтобы написал — и оно работает и этого было уже достаточно.
G>Очень даже представляю, если понабрать таких грамотных посонов как ты и отправить писать .NET приложение, то его ждет эпик фейл. Постоянные баги и борьба с ветрянными мельницами. А еще потом полученное убожество надо продать.
Ну так в дотнет "планка вхождения" ниже или как? Или дотнет требует сверх-мега спецов, чтобы написать продаваемый коробочный продукт? Зря ты перешел на личности, кста. По опыту разбора с тобой технических моментов за последние года 4 я бы оценил твоё владение платформой .Net как очень посредственное и очень поверхностное. Ничего более-менее серьезного, чем то, что можно сделать, пользуя лишь готовые библиотеки и инструменты, тебе поручать нельзя. Т.е. ты типичный пользователь технологий, а не их разработчик.
V>>Даже SQL-сервак и IIS. ))) G>SQL Server в таком виде как мы его знаем был создан в 2000 году, дальше были только доработки. Но вот что странно, новые фичи SQL часто реализуются через .NETтипы.
Новые фичи самого сервака там реализуются в нейтиве, ес-но. Ты, наверно, хотел сказать, про поддержку хранимок на дотнете? Дык, Оракл это давно делает. Еще один дык от тебя и таких как ты говорит, что хранимки — это зло. Я уже запутался. Не поможешь распутать?
G>Ибо быстродействие зависит от скорости работы с диском, а не от того нативный там код или нет.
Та нифига. В "разогретой" базе индексы и статистика в основном сидят в ОП, а значит, скорость обработки их влияет существенно. Разница в скорости работы разогретой базы и не разогретой на порядки.
G>IIS более чем наполовину на .NET написан, но основная часть IIS — драйвер ядра HTTP.SYS, он ессесно нативный.
IIS нетивный полностью. Это тулзины для него на дотнете написаны и то, далеко не все. MMX-консоль нейтивная. А дотнетный ASPX — это обычный плагин, не хуже и не лучше остальных плагинов, таких как Jetty для хостинга джавовских сервлетов.
G>Так что оба примера мимо кассы
Возвращая тебе твои же собственные манеры: у вас дотнет головного мозга, коллега.
V>>Даже браузер, в котором отображается твоя веб-морда. G>Рассказать когда появился IE? Думаешь его кто-то будет переписывать?
Думаю, что с момента выхода дотнета прошло дохрена времени. Думаю, что существует просто море альтернативных HTML-движков, в т.ч. есть пара и на дотнете. Не взлетели на дотнете, увы. А на нейтиве — взлетели. Даже на этом сайте есть форум, посвящённый одному из них.
Более того, движок IE был фактически полностью переписан с выходом 8-го IE. Расскажи нам, когда же вышел IE 8. ))
V>>Ну так сайты и прочая заказуха как у тебя, фиг ли. А ты бы считал не вакансии, а реальные кол-ва инсталляций продуктов. G>"Реальное количество продуктов" ни о чем, ибо старые всегда будут иметь больше.
Дотнету уже 12 лет. А продуктов, моложе 12 лет — полно.
G>Кроме того сейчас эпоха сервисов, а не продуктов. Сегодня никто не хочет ставить себе лишний софт, если тоже самое есть в браузере.
На планшетах и мобилках полно софта. Но тот софт, который не свистелка и перделка — всегда нейтивный. Даже под Андроид. Виберы и его многочисленные клоны, например. Не хочу повторяться, я уже перечислял тебе много всего. Все эти продукты намного моложе дотнета.
V>>Для объективности зайди на вакансии той же MS/Intel/Samsung и вообще любых серьезных контор, делающих коробочные продукты и увидишь реальное положение дел в промышленной разработке, а не в заказухе под конкретного клиента некоего единичного экземпляра системы.
G>Смотрю вакансии MS в России и вижу что ищут девелоперов в свой центр разработки пилить расширения для Axapta, на .NET ессесно.
Во-во. Вот для чего дотнет в нише самой MS. Примерно та же ниша, что и у тебя. ))
А те программисты, которые не на Аксапте, там на что требуется, ы?
G>Хотя все таки рынок у 1С отжать.
Не отожмут. Философия Аксапты примерно такая же, как у Паруса. Поэтому — не отожмут никогда. Парусы/Аксапты хороши в крупном секторе с большими инвестициями. А для средних и мелких предприятий они пролетают из-за своей бизнес-модели. А эта модель, в свою очередь, целиком и полностью зависит от технологии платформы. Кароч, для программирования под Парус и Аксапту нужны спецы в программировании, в отличие от спецов сугубо в прикладной области, которые могут "настраивать" 1С. Не зря же огромное программистов 1С — девушки. Но их почти нет в разработке под Парус и Аксапту. Поэтому рынок 1С и не отожмут — это другой совсем рынок.
Здравствуйте, IT, Вы писали:
IT>Что же касается плюсов, то тут вот какое дело. Я пишу на .net ещё с бета версий, т.е. довольно давно, тем не менее на C/C++ я писал всё же немного дольше и могу сказать, что более глюко-благоприятной технологии, чем C/C++ в сегодняшнем мейнстриме не существует.
Твои данные устарели на 12 лет. Качество компиляторов, а так же тулзов поддержки разработки совсем не то. Про кач-во библиотек я вообще молчу. Их покрытие задач и их кач-во не сравнимо выросли за те же 12 лет.
Странный ты в своих аргументах, кароч. Дотнет, знач, равивался все эти годы, а нейтив стоял на месте. ))
IT>Небольшое гипотетическое отставание .net в производительности легко нивелируется дешевым железом, но даже здесь не всё так просто и однозначно.
К сожалению, всё просто и однозначно. Дотнет, действительно, пробовали на все подряд ниши. Вообще на все мыслимые ниши. Но в промышленном масштабе остался он только как клиент к БД или для написания утилит.
IT>Максимальная производительность сегодня в первую очередь достигается алгоритмами и архитектурными решениями.
Эта мантру я знаю наизусть. Предел сложности сверху О и прочее бла-бла-бла. Это всё оценочные пределы. Есть еще предел сложности снизу. Есть еще коэф К при переходе от оценочной стоимости алгоритма к реальной. Так вот, для дотнета этот К равен примерно 3-м. Т.е. для реальных задач, где требуется производительность, при прочих равных на нейтиве можно добиться в 3 раза быстрее. Но частенько бывает и в 10 раз.
IT>Буквально пару дней назад обсуждали требования к железу для нашей системы, и мы как разработчики затруднились ответить на вопрос каковы наши минимальные и максимальные требования к железу. Мы может спокойно израсходовать от 1 до 1000 ядер, при этом они не обязательно должны быть на одном компьютере. Соответственно, наш заказчик может получить производительность от X до X*1000, поэтому спрашивать сколько и за что он готов заплатить нужно у него. У нас только одно дополнительное требование — из-за объёма обрабатываемых данных для максимальной производительности каждое дополниетлное ядро требует дополнительно около гигабайта памяти. Остальное пусть решает заказчик.
Я же говорю — я не против посмотреть на первый успешный проект некоей реалтайм-системы на дотнете. Но ты же понимаешь, что прямо на сегодня этих прецендентов нет ВООБЩЕ. И если ты его создашь — то этим исключением лишь подтвердишь правило.
IT>Можно было бы сделать чуть более быструю систему на плюсах? Возможно. Только это либо вылилось бы в феерические затраты, либо в очередной феерический провал. Что в общем-то почти и произошло. Только не на плюсах, а на твоих любимых сохранённых процедурах.
Сравнил, блин, теплое с мягким.
Оставлю на твоей совести выделенную демагогию. Ты и сам знал, что демагогия, пока писал, но, видать, самоконтроль не справился. ))
Возьми ЛЮБОЕ приложение на плюсах возрастом 15+ лет, перепиши его, используя современный С++ и современные же библиотеки. Объем кода уменьшится раз в 10. Надежность увеличиться раз в бесконечно.
Все-таки вы не понимаете, что основной профит от дотнета вовсе не в ГЦ, а огромном кол-ве отлаженных библиотек. Но это было актуально на момент выхода первых джавы и немного актуально на момент выхода первых версий дотнета. Сейчас сложно не найти готовую и надежную нейтивную либу под какую-либо задачу.
А вот библиотек для хранимок я не видел. Там каждый велосипедик с 0-ля, ручками.
Понимаешь... Меня уже начинают раздражать ваши подобные спекуляции. Оставь тебе сейчас только базовые типы дотнета, компилятор, ГЦ, джит, кароч, только базовую платформу + интероп. И ты окажешься в положении разработчика хранимок и не факт, что на хранимках не выйдет получше.
IT>Думаю, что с плюсами всё было бы гораздо хуже.
Думаю, что на первом дотнете всё было бы еще хуже. А твой плюсовый опыт как раз тех времён.
IT>Как я уже сказал, более глюко-благоприятной технологии не существует. Но сегодня к этому ещё добавляется и доминирование в этой технологии личностей с весьма негибким мышлением. У меня не так много знакомых плюсовиков, но за редчайшим исключением глядя на них, образ успешного C++ программиста — это лысеющий дядька, просидевший на жопе в одной конторе 15 лет, занимающийся парсингом какого-нибудь фида для того, чтобы платить по счетам и безумно увлечённый кто рыбалкой, кто охотой, кто оружием, машинами или музыкой. Про последнюю версию стандарта C++ не все из них знают, что она вообще есть и большинство затрудняются сказать в каком году она вышла.
А у меня все знакомые плюсовики в курсе всех новых библиотек, всех изменений стандарта и всех новых парадигм.
Странный у тебя круг общения, кароч. То ДБА без профильного образования, то плюсовики, которые вовсе не плюсовики, а сишники, судя по описанию.
V>>Не боись. На многих обслуживающих нишах дотнет остался. Я бы даже сказал — его достаточно много.
IT>Ну да. Продолжу про лысеющих дядек. В моей реальности мне дотнета бояться не надо. Как раз наоборот. Ко мне периодически обращается народ с вопросами о работе, в том числе иногда и лысеющие дядьки. При этом они понимают, что обращаются к дотнетчику и делают это исключительно от отчаяния. Их душераздирающие истории стоит послушать. Если сегодня в Нью-Йорке опытный программист несколько месяцев не может найти работу, то это можно объяснить только его специализацией — плюсами. Дотнетчики разлетаются как пирожки в базарный день. Кстати, речь идёт если что о финансовой столице мира, где в твоей реальности дотнетчикам отведена лишь участь подметать дворы банков и чистить мусорные ящики бирж.
Странно. Это при том, что более-менее опытных плюсовиков вообще раздирают сегодня на части. В свободном рынке их просто нет — обычно их ПЕРЕМАНИВАЮТ с работы на работу, в отличие от сомна дотнетчиков. Я думаю, что те дядьки просто не могут пройти интервью. Ты поговори с ними по душам.
Я вот вижу на jobs.monster.com
C++ Software Developer for Ultra low-latency data delivery (NYC 150-250k+)
Прошелся по предложениям C#, для сеньоров в среднем 70-120К. Для сеньоров плюсовиков — 120-200к. Профит! ))
Более высокие ЗП для дотнетчиков — это уже не просто девелоперы, а еще много чего. Для плюсовика для той же ЗП достаточно быть просто девелопером. Вот тебе реальные расклады. А с твоими дядьками что-то не то. С тем же успехом они могли быть фортранщиками.
V>>Технология всё-равно сырая. В 2009-м я потратил более недели на поиски причин периодических глюков подключения к майкрософтному SQL-серваку и обнаружил рефлектором прикольный баг парсера потока от SQL-сервака, когда идёт нарезка блоб-полей... Ну что тут говорить??? В святая-святых, в драйвере общения с базой(!!!) кривой индусский код.
IT>Это мы уже обсудили.
Комментов про кривой код не было. Ты же должен был все эти 12 лет многократно лазить декомпиляторами в платформу (там же без рефлектора или аналога вообще было невозможно работать!!!). Качество кода ниже плинтуса. Весь мир это видит. А ты просто хвалишь своё болото, хотя прекрасно в курсе, что технологически это пока просто болото. И так будет еще долго, бо технология еще вовсю развивается и до устаканивания далеко.
V>>Причем, кривизна не только в том месте, где был баг. Сам код кривой до невероятности. В сравнении с нейтивными опенсорсными дровами под какую-нить БД для Линухов — это же просто детский лепет, а не драйвер клиента БД!!!
IT>А ты уверен, что в Линухе вообще есть код, который парсит поток нарезки блоба SQL-сервера?
Конечно. Дать ссылку?
Но можно посмотреть код других драйверов, зачем же именно под MS SQL? Мы же обсуждали сравнительное качество кода клиентских драйверов в опенсорсе и в дотнете. При том, что кач-во опенсорса обычно не на высоте.
V>>Смирись. Технология еще сырая. И я не говорю, что ты в этом виноват или любой другой программист на дотнете. Но таковы дела. Очень много функционала. Действительно много. Он бесплатен. Т.е. совершенно эта прорва функционала бесплатна. Качество не может быть хорошим в короткие сроки при таких раскладах. Просто руки не будут успевать делать всю эту прорву функционала качественно.
IT>Хорошо, что ты об этом сам заговорил. Про глюко-благоприятность я уже говорил? Кажется, говорил. Так вот, там, где дотнетчик сделает один баг, плюсовик того же уровня сделает на порядок больше.
А я 12 лет наблюдаю ровно обратное. Дотнет отучает думать. В нем баги делаются чаще. Просто их легче было ловить одно время, угу. Но уже лет 8 на нейтиве баги ловятся так же легко и непринужденно.
IT>Это не я придумал, это медицинский факт, обоснованный природой самих технологий.
Я хорошо знаю природу этих технологий. И ты хорошо знаешь, что я хорошо знаю. Нейтивная "ловушка" после дотнетного джита для отладки ничем не отличается от точно такой же ловушки в debug-версии бинарного образа. И да, сейчас не принято пользовать встроенные в С массивы, в С++ принято использовать контейнеры стандартных библиотек или буста. Так вот, там точно такие же все защиты в дебажном образе. И я не верю, что ты этого не знал. А нулевые указатели ловились отродясь. Просто еще дело в культуре разработки. В дотнете принято в начале методов проверять аргументы. Если этого не делать, то ошибку найти становилось сложновато, т.к. она может проявить себя не там, где возникла. Стоило в нейтиве укрепиться такой же точно культуре и оп-па!!! Такой же точно эффект в плане надежности и легкости отыскания багов.
IT>Соответственно качество кода на .net и производительность программистов растёт примерно в той же прогрессии.
Производительность программиста зависит от наличия готового библиотечного функционала. Я видел ситуации, когда этого готового функционала не было. И я бы не сказал, что разработка чего-нить с 0-ля на дотнете сильно дешевле. Дудки. Свои ограничения, свои причины увеличения трудоёмкости. Из-за особенностей шаблонов С++ полно задач, где именно библиотечный функционал на плюсах писать быстрее и приятнее.
IT>Кажущиеся проблемы .net вызваны тем, что таки да, уровень девелоперов в целом ниже, чем у лысеющих дядек, пилящих один и тот же фид 15 лет, а также тем, что пока они всё ещё пилят свой фид, дотнетчики успевают наклепать на два порядка больше всяких полезных приложений.
Это тоже устаревшая инфа. Посмотри, с какой скоростью сейчас разрабатываются всякие десктопы, свистелки и перделки под линуксоподобные оси. Когда ты заканчивал свою С++ карьеру, это было немыслимо. А сейчас эти приложухи клепаются быстрее дотнетных. Потому что уже ВСЁ ЕСТЬ.
Скажу так. Я все реже в последние годы пользую дотнет даже для макетирования или утилит. Чем больше доступного готового библиотечного функционала в нейтиве, тем меньше мне интересен дотнет для утилит и макетов. Смысла уже нет. Уже нет той потрясающей разницы в скорости разработки макета в дотнете vs нейтив, какая была еще буквально в 2005-м.
Вот только еще для ГУИ-утилит пользую исключительно дотнет, грешен. )) Если бы эти наглецы-подлецы из MS предоставили бы WinRT-слой и под предыдущие оси, хотя бы под Win7 (а технологически это ЭЛЕМЕНТАРНО), то писал бы уже ГУИ на XAML — WinRT — С++/CX.
Далее. Если пройтись по JIRA нашей конторы, то большинство багов — это "функциональные", то бишь касаются исключительно логики, а не "технологические", типа выхода за пределы массивов или нулевых указателей. Не пользуемся мы массивами. ))
V>>Морда на нете уже много лет где. А насчет "процессонговой" части любопытно. Бо самый рантайм-процессинг все-равно выполняется серверами БД, а не внешними приложениями. А внешняя аналитика или неспешный пересчет всего и вся по закрытию банковского дня может запросто быть написан на чем-то управляемом. Собсно, это уже десяток лет так и есть.
IT>Ёлы-палы, так вы всё процесите серверами БД? А я тут C++ по ходу поласкаю. Как не хорошо получилось. Ну да ладно. Перейдём тогда к лысеющим датабазным админам, которые похоже понятия не имеют о том, что такое расширяемые системы. Или всё таки имеют? Или вы всё же умудрились запихнуть всю вашу биржу в одну единственную базу данных вместе с процессингом! Крутые всё-таки в твоей реальности сервера баз данных. У нас таких ещё не придумали.
Ну так биржа не на MS SQL, господя. )))
Движок для транзакций бирж должен позволять работать в том же процессе. Опять же — биржа легко масштабируема из-за того, кто почти каждый продукт независим от других. Ну и запоминаемые транзакции в бирже тривиальны, таки, в отличие от транзакций распределённой складской системы, например. Для учета всех транзакций биржи достаточно всего одной изменяемой таблицы. И не всегда имеет смысл эту главную таблицу обслуживать именно через СУБД и тем более реляционную. Современные транзакционные/журналируемые файловые системы в мире unix заруливают любые мыслимые СУБД. В СУБД обычно хранят "развесистую" информацию справочного характера, которая подготавливается ДО открытия торгов.
V>>Ты сидишь в крайне узкой нише разработок и считаешь, что на этом всё! )) V>>А что за пределами этой узенькой ниши — так сразу "альтернативная реальность".
IT> Пять балов с жирным плюсом! Всё-таки я снимаю шляпу перед твоим умением выдавать желаемое за действительное. Молодец!
Парадокс блабла, однако. Я в твоей нише проработал с 96-го по 2002-й и потом регулярно приходилось по базам, сайтам, учёту и прочему. В курсе всего и вся. Вот там дотнет помог в полный рост. Но было много других ниш, где этот дотнет показал себя попросту вредителем, а не технологией.
Выпускаем и дотнетный движок для бирж в т.ч. Все сравнимые характеристики на уровне ведущих игроков (а мы и есть одни из ведущих). И у всех игроков решения под дотнет и джаву отстают по характеристикам примерно на порядок. Это нормально.
IT>На мой текущий проект меня пригласили как раз по этой причине. Кокое совпаданеи, что основная логика в этом проекте была реализована в виде сохранённых процедур. В новом проекте ни одной процедуры нет. Вместо них расширяемое на сотни ядер решение на .net. Уже сейчас видно, что по всем параметрам производительности мы впереди настолько, что этот вопрос снят с повестки дня. Но самое главное, текущая система уверенно деградирует по такому параметру как наращивание функциональности и простейшие фичи делаются неделями и с большой кровью. Мы эту проблему не то что сняли, а просто занулили.
Так я ж не против, чтобы клиентов к БД писали на дотнете. Не в дотнете тормоза для этого сценария, потому что. Но зато "бесплатный" маппинг затем в объекты — это прелэсть! Дуй да нижамай посильней! )) В нейтиве для подобного надо писать мапперы отдельно. Обычно, пишутся каким-нить кодогенератором, угу. Головняк, согласен. ))
IT>Так ли у нас всё хорошо, потому что .net? Вовсе нет. Дурь в башке и кривые руки всё же большая причина неуспеха предыдущего проекта.
Ага, проснулась совесть. Молодец! ))
IT>Те, кто его начинал, кстати, рассматривали .net в качестве одной из альтернатив, но чего-то там у них не смоглось. .net — это в–ё же просто инструмент. Нормальный такой инструмент, который в нормальных руках позволяет делать нормальные проекты. А в тех двух процентах, где лучше использовать что-то другое, можно запросто использовать что-то другое.
Если бы еще не спекуляция на процентах, вообще чудесная концовка вышла бы.
IT>Хотя в твоей реальности видимо всё по-другому.
Смешно в этой концовке лишь то, что именно это дословно я говорил аналогичное еще в 2005-м, когда всё для дотнета стало ясно. В моей реальности лишь другие проценты. Просто вы, дотнетчики, воспринимаете многое, с чем вы работаете, как "данное свыше", хотя это "данное" тоже было кем-то разработано, причем, на нейтиве. Ты пишешь на дотнете, пользуя нейтивную ОСь, под нейтивный сервак, с нейтивными фильтрами TCP, нейтивными дровами и сервисами, слушаешь музычку в найшниках, пользуя нейтивные кодеки, смотришь стримы через нейтивный AdobeFlash или нейивный же сервелат, пишешь под платформу, где основные её элементы — нейтивные, ес-но (ГЦ, джит, многие системные классы) и т.д. до бесконечности.
Твой дотнет — это ма-а-а-аленький такой островок под конкретно решаемую тобой задачу в океане нейтива вокруг этой задачи.
Здравствуйте, gandjustas, Вы писали:
V>>Пока не увижу в новостях, что где-то вышел движок биржи на Linq или банковский оп-день — это всё сказки про белого бычка. G>А ты видишь в новостях про биржи на ODBC или опердни на ADO?
Твой вопрос лишен смысла.
Биржи написаны на С/С++. ВСЕ единицы попыток переписать биржи на дотнет закончились отказом от этих попыток.
Наиболее часто вызываемые рантайм-транзакции в оперднях банков сделаны на хранимках.
G>Работа с данными не самая важная часть приложения, хотя зачастую и самая ресурсоемкая. А Linq вообще не более чем генератор запросов, от которого можно в будущем отказаться, если активная разработка уже не ведется (как сделали в StackOverflow).
Я ж говорю, что ты нифига не понимаешь. )))
Linq — это не просто генератор запросов, это еще мега-удобный маппер их результатов. В нейтиве такое на сегодня, увы, никак в подобном виде. В нейтиве код маппинга обычно генерируют отдельной тулзиной, типа http://www.qxorm.com/qxorm_en/home.html или http://www.codesynthesis.com/products/odb/, а то и просто ручками, см. boost::serialization. Только в следующем стандарте С++ ожидается, наконец, стандарт на ABI и на метаинформацию... только тогда можно будет делать сравнимые в плане удобства для разработчика мапперы на плюсах, без необходимости подключать и настраивать внешние утилиты для процесса разработки.
G>Но именно этот генератор запросов позволяет разрабатывать приложения с огромной скоростью, не нагружая DBA написанием селектов.
Ну вот AVK утверждает, что он не пользуется специфическим Linq-синтаксисом. А используемый им синтаксис был доступен мне еще хрен его знает когда через самописный генератор запросов + маппинг через BLT. Более того, в нейтивных генераторах запросов тоже примерно такой же синтаксис, как показывает AVK.
Вот ты используешь синтаксис запросов Linq или пишешь в "классическом" стиле?
Я ж чего с вами спорю. Мне же есть с чем сравнить. Я на дотнете периодически оч плотно, вижу что происходит и там и там.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, gandjustas, Вы писали:
G>>Я вот смотрю на Visual Studio, которая на WPF, и не понимаю о чем ты говоришь.
V>А я говорил, что ты не понимаешь нифига. Visual Studio вышла до выхода WinRT. Более того, она должна работать даже на тех версиях виндов, где WinRT не поддерживается. Более того, запуск студии в 5-15 секунд никого не волнует. Это же утилитное приложение. Вот если бы виндовый калькулятор запускался 5-15 секунд, то никто бы его не использовал. Вот почему в коробочных продуктах фактически нет WPF.
Действительно не понимаю как это связано. Похоже что связь у тебя в голове только существует.
G>>А если учесть что из WPF родился UI для Windows 8 и Windows Phone, то не понимаю вдвойне. V>А я говорил, что ты не понимаешь нифига. Этим UI должен был стать дотнетный "Авалон". Поищи по "Avalon Longhorn".
Кому должен? Может быть и стал бы, не будь у Синофски зуб на .NET. На WP таки сделали на .NET UI, только через несколько лет таки переписали на COM, чтобы единая платформа была.
V>
V>Avalon offers a fundamental change in how you interact with your computer, and is probably the most significant UI change since Windows 1.0. It promises fundamental changes in technology, such as the way graphics are buffered internally. These features will include more efficient integration with sound and video, complex graphics displays, and sophisticated use of transparency. Microsoft believes the real advances here will come when experts in human computer interactions are free from the limitations of Win32 and can develop new controls and techniques that offer more of an immersive experience.
V>Так вот. Эпик фейл WPF в том, что он так и не стал Авалоном. Заодно ЗАДЕРЖАЛ выход новых виндов более чем на 5 лет. Windows Vista должна была быть последним фейс-лифтом старых виндов, типа как Windows 98 перед Windows XP. А по-факту Windows Vista задержалась на 8 лет как основная операционка в виде "ребрендинга" Windows 7. И эта задержка могла бы продолжаться вечно, если бы не волевое решение переписать нафик Авалон на нейтиве.
Ты веришь в маркетинговый буллшит? Слишком много слов "должен\должна", тебе никто ничего не должен, успокойся.
V>6 лет задержки из-за того, что дотнет так и не стал обладать необходимыми потребительскими характеристиками.
При чем тут .NET? Почему это не помешало сделать UI для WP7 на .NET?
V>Масштаб этого эпик фейла не поддаётся осмыслению. Собсно, именно с конца 2006-го года начался обратный отсчет уровню доверия дотнету, как универсальной платформе. Прямо на сегодня этот уровень нулевой. Дотнет нифига не универсален, а занял лишь те ниши, в которых неплоха была и Джава. На этом всё.
Сильную роль сыграло развитие JS, которое по сути похоронило идею Rich Desktop UI, очень популярную в начале 20 века
V>>>Тебя в гугле видимо забанили. ))) G>>Видимо да, ибо гугл не находит IP телефонию на .NET, которая должна была переплюнуть Asterisk, никаких свидетельств что такие проекты вообще были.
G>>Хоть пару ссылок приведи для подтверждения своих слов.
V>В 2005-2006 годах я занимался этим вопросом много и видел много таких проектов. На сегодня они не актуальны, ес-но, т.к. вопрос можно считать закрытым. Можешь поискать еще кодеки, например по speex dotnet. Я сходу нашел NAudio, например. Но более детальное знакомство показало, что для того же speex используется нейтивный кодек, хотя в проекте NSpeex были планы по релизу "родного" дотнетного кодека. Собсно, перевести открытый исходник на дотнет — это 2-3 дня работы разработчику средней руки. Я видел в те времена несколько "родных" дотнетных реализаций кодеков. Один из кодеков на дотнете как-то публиковал здесь я, для G.711. Портирование его из нейтива заняло меньше часа. Пользовали это в своих проектах. Характеристики производительности ни к черту. Поэтому, дотнет остался только для макетирования всех этих вещей, для боевого применения более половины движка переписали на нейтив, оставив дотнету только сигналинг.
Я понял, про астериск были фантазии. Про кодеки — не ясно зачем их на .NET писать вообще, там же числомолотилка, .NET ничего не даст.
V>Специально нашел тот пост: http://www.rsdn.ru/forum/media/2926468
V>Если сможешь заставить работать быстрее — велкам. )) При том, что этот кодек до невозможности примитивен, в сравнении с тем же speex.
Пот посмотрел на код, его чуть ли не 1-в-1 можно на C заменить (даже не C++), только массивы надо извне передавать. А для .NET можно написать обертку, которая зовет эту либу.
V>>>Существовала одно время потребность в полностью байткодных приложениях. Тогда еще по наивности носились с "бинарной" переносимостью. Оч многие проекты были сделаны на дотнете. Сосредоточься. Не обязательно переписаны существующие, как бедняга EverNote или яховский мессенджер. G>>Какие например? Paint.NET до сих пор живет и развивается.
V>Paint.Net не требует быстродействия. Вообще. Я разработал графический редактор для конференций на дотнете в 2006-м, где участники конференций могут рисовать на одной доске совместно. Никакой скорости не требуется. Вообще. Потому что основные тормоза от самой сетки. Потому что события даже от самых крутых мышек поступали не чаще 100 раз в секунду. Более того, мой редактор векторный, участники конференций могут изменять объекты, нарисованные другими участниками. Это намного сложнее растровой графики.
Большинство десктопных приложений не требует быстродействия, вообще. Ни мессенджеры, ни заметки, ни какая-либо еще фигня. Быстродействия на десктопе требуют игры, в которых кстати игровая логика пишется на скриптовых языках, которые по твоему гораздо менее надежны и быстры А также кодеки, которые работают с непрерывными потоками информации.
V>В плане требований к производительности сравни с теми же нейтивными фильтрами для фотошлёпа, где даже на современных рабочих станциях хочется добавить мощщи. На дотнете это просто не влетит. От слова вообще. Се ля ви.
Хм... почему фотошопу требуется быстродействие, а paint.nt — нет? Разница только в тормозных фильтрах? Которые кстати тоже числомолотилки.
G>>EverNote написали на .NET, получили инвестиции, пошли переписывать на C++. С таким баблом можно было и на ассемблере написать. А бекенд то на .NET и остался. Если бы начали на C++, то не то что инвестиций, даже релиза не было бы.
V>Не юли. ЗАЧЕМ они переписали клиента под нейтив? Причем, он переписан под нейтив на кучи мобильных платформ в т.ч. V>Вот нафига было переписывать со сверхудобного дотнета на страшный и ужасный нейтив? Твои варианты?
Потому что они могли это сделать и у них была на это куча бабла. А альтернативы какие? Разогнать команду и положить бабло в карман? Увы на инвестиционные деньги так поступать нельзя.
Дали бы мне столько бабла, я бы тоже все переписал на C++, даже за 1% прироста быстродействия.
Но мне не дают столько, поэтому пишу на .NET и проблем из-за этого не испытываю.
G>>Я видел пару таких проектов. Пролетели чисто по экономическим причинам. Для вытеснения конкурентов надо было 50+ человеко-лет работы вложить, а никто столько кормить не будет. Это сейчас, с развитием персональных устройств, можно создавать нишевые продукты и продавать их достаточно массово чтобы окупить затраты, а 10 лет назад такой возможности не было. Рынок уже был насыщен приложениями, а ниши были слишком узкими, чтобы на них реально зарабатывать.
V>А я видел кучу влетевших нейтивных продуктов в то же самое время, хотя, нейтивные, как ты понимаешь, требуют больше человеко-лет, так?
Ну приведи хотябы маленький список из этой кучи. Особенно, которые стартанули за последние 5-10 лет.
V>Так вот, по опыту серьезной разработки на дотнете и нейтиве одновременно я уже делился с тобой своими собственными наблюдениями еще пару лет назад (или даже больше). На дотнете можно оч быстро накидать "макет". Можно даже заставить его работать при полной функциональности. Затем, при попытке выжать эффективность с этого "макета" мы обнаруживаем, что вложения трудоёмкости оч быстро переплёвывают вложения трудоёмкости в сравнении с нейтивным вариантом. Ну т.е., когда такое же кол-во усилий по вылизыванию тратишь на нейтив, то результат просто несравнимый не в пользу дотнета. Поэтому, дотнет хорош там, где никакую эффективность ни от куда выжимать не надо, а надо чтобы написал — и оно работает и этого было уже достаточно.
Ты опять про свой мир говоришь. Я никогда проблем с оптимизацией .NET коа до приемлемого уровня быстродействия не испытывал. Я конечно верю, что у тебя с этим проблемы, но .NET в этом не виноват.
G>>Очень даже представляю, если понабрать таких грамотных посонов как ты и отправить писать .NET приложение, то его ждет эпик фейл. Постоянные баги и борьба с ветрянными мельницами. А еще потом полученное убожество надо продать.
V>Ну так в дотнет "планка вхождения" ниже или как? Или дотнет требует сверх-мега спецов, чтобы написать продаваемый коробочный продукт?
Одно другому не мешает. Ты же сам писал что не везде требуется супер-быстродействие.
V>Зря ты перешел на личности, кста. По опыту разбора с тобой технических моментов за последние года 4 я бы оценил твоё владение платформой .Net как очень посредственное и очень поверхностное. Ничего более-менее серьезного, чем то, что можно сделать, пользуя лишь готовые библиотеки и инструменты, тебе поручать нельзя. Т.е. ты типичный пользователь технологий, а не их разработчик.
Ну верь в это, может легче станет.
V>>>Даже SQL-сервак и IIS. ))) G>>SQL Server в таком виде как мы его знаем был создан в 2000 году, дальше были только доработки. Но вот что странно, новые фичи SQL часто реализуются через .NETтипы.
V>Новые фичи самого сервака там реализуются в нейтиве, ес-но. Ты, наверно, хотел сказать, про поддержку хранимок на дотнете? Дык, Оракл это давно делает. Еще один дык от тебя и таких как ты говорит, что хранимки — это зло. Я уже запутался. Не поможешь распутать?
hierarchyid как ни странно — .NET тип, Geometry и Geography тоже реализованы через .NET обертки. Но это все фигня, ибо главное в быстродействии SQL Server — чтение с диска.
G>>Ибо быстродействие зависит от скорости работы с диском, а не от того нативный там код или нет. V>Та нифига. В "разогретой" базе индексы и статистика в основном сидят в ОП, а значит, скорость обработки их влияет существенно. Разница в скорости работы разогретой базы и не разогретой на порядки.
Ты же понимаешь что в любой серьезной задаче с БД рассчитывать на то, что все данные будут в памяти невозможно. Поэтому и пилят запросы, чтобы количество чтений страниц уменьшить.
V>>>Даже браузер, в котором отображается твоя веб-морда. G>>Рассказать когда появился IE? Думаешь его кто-то будет переписывать?
V>Думаю, что с момента выхода дотнета прошло дохрена времени. Думаю, что существует просто море альтернативных HTML-движков, в т.ч. есть пара и на дотнете. Не взлетели на дотнете, увы. А на нейтиве — взлетели. Даже на этом сайте есть форум, посвящённый одному из них.
Опять твои фантазии, какие движки на .NET? Ссылок хоть пару приведешь? Не исследовательские проекты, а реальные попытки сделать браузер на .NET? Какой смысл в этом когда есть WebKit?
V>Более того, движок IE был фактически полностью переписан с выходом 8-го IE. Расскажи нам, когда же вышел IE 8. ))
"Полностью переписан" это маркетинговый буллшит. От силы 30% перписали, остальное скопипастили. Как можно на несколько лет полностью переписать продукт, в который вложено несколько сотен человеко-лет труда и суммарно сотни лет тестирования, в том числе на реальных пользователях. IE 10 кстати тоже "полностью переписали" судя по маркетинговым заявлениями. Откуда у МС ресурсы раз в 3 года полностью переписывать браузер?
V>>>Ну так сайты и прочая заказуха как у тебя, фиг ли. А ты бы считал не вакансии, а реальные кол-ва инсталляций продуктов. G>>"Реальное количество продуктов" ни о чем, ибо старые всегда будут иметь больше. V>Дотнету уже 12 лет. А продуктов, моложе 12 лет — полно.
Приведи список.
G>>Кроме того сейчас эпоха сервисов, а не продуктов. Сегодня никто не хочет ставить себе лишний софт, если тоже самое есть в браузере.
V>На планшетах и мобилках полно софта. Но тот софт, который не свистелка и перделка — всегда нейтивный. Даже под Андроид. Виберы и его многочисленные клоны, например. Не хочу повторяться, я уже перечислял тебе много всего. Все эти продукты намного моложе дотнета.
Это опять кратина в твоей голове. Самый популярный софт на мобилках — клиенты соцсетей. Все, как ни странно, не на C++ написаны.
Яндекс карты, которыми постоянно пользуюсь, тоже не нативные. Мобильный банк — тоже не нативный.
Многие игры на Unity, который на .NET.
V>>>Для объективности зайди на вакансии той же MS/Intel/Samsung и вообще любых серьезных контор, делающих коробочные продукты и увидишь реальное положение дел в промышленной разработке, а не в заказухе под конкретного клиента некоего единичного экземпляра системы.
G>>Смотрю вакансии MS в России и вижу что ищут девелоперов в свой центр разработки пилить расширения для Axapta, на .NET ессесно.
V>Во-во. Вот для чего дотнет в нише самой MS. Примерно та же ниша, что и у тебя. )) V>А те программисты, которые не на Аксапте, там на что требуется, ы?
SharePoint, CRM, разработка под Windows Azure, все как-то на .NET и JS.
Что там в редмонде — я не в курсе. Но кто-то ведь должен писать драйверы ядра и поддерживать виндовый калькулятор
G>>Хотя все таки рынок у 1С отжать.
V>Не отожмут. Философия Аксапты примерно такая же, как у Паруса. Поэтому — не отожмут никогда. Парусы/Аксапты хороши в крупном секторе с большими инвестициями. А для средних и мелких предприятий они пролетают из-за своей бизнес-модели. А эта модель, в свою очередь, целиком и полностью зависит от технологии платформы. Кароч, для программирования под Парус и Аксапту нужны спецы в программировании, в отличие от спецов сугубо в прикладной области, которые могут "настраивать" 1С. Не зря же огромное программистов 1С — девушки. Но их почти нет в разработке под Парус и Аксапту. Поэтому рынок 1С и не отожмут — это другой совсем рынок.
А ты думаешь МС интересуют внедрения в конторах на 10 человек с одним бухгалтеорм?
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, gandjustas, Вы писали:
V>>>Пока не увижу в новостях, что где-то вышел движок биржи на Linq или банковский оп-день — это всё сказки про белого бычка. G>>А ты видишь в новостях про биржи на ODBC или опердни на ADO?
V>Твой вопрос лишен смысла.
Также как и твой.ODBC и ADO такие же технологии работы с данными, как и EF.
V>Биржи написаны на С/С++. ВСЕ единицы попыток переписать биржи на дотнет закончились отказом от этих попыток.
Я знаю только одну историю про LSE, у тебя еще есть?
V>Наиболее часто вызываемые рантайм-транзакции в оперднях банков сделаны на хранимках.
Не факт что это хорошо.
G>>Работа с данными не самая важная часть приложения, хотя зачастую и самая ресурсоемкая. А Linq вообще не более чем генератор запросов, от которого можно в будущем отказаться, если активная разработка уже не ведется (как сделали в StackOverflow). V>Я ж говорю, что ты нифига не понимаешь. )))
Уровень аргументации на высоте
V>Linq — это не просто генератор запросов, это еще мега-удобный маппер их результатов. В нейтиве такое на сегодня, увы, никак в подобном виде. В нейтиве код маппинга обычно генерируют отдельной тулзиной, типа http://www.qxorm.com/qxorm_en/home.html или http://www.codesynthesis.com/products/odb/, а то и просто ручками, см. boost::serialization. Только в следующем стандарте С++ ожидается, наконец, стандарт на ABI и на метаинформацию... только тогда можно будет делать сравнимые в плане удобства для разработчика мапперы на плюсах, без необходимости подключать и настраивать внешние утилиты для процесса разработки.
При чем тут маппер? Код на C++ уже научился запросы генерить из лямбд? Маппер это малекькая часть, которая при наличии прямых рук пишется за неделю.
G>>Но именно этот генератор запросов позволяет разрабатывать приложения с огромной скоростью, не нагружая DBA написанием селектов. V>Ну вот AVK утверждает, что он не пользуется специфическим Linq-синтаксисом. А используемый им синтаксис был доступен мне еще хрен его знает когда через самописный генератор запросов + маппинг через BLT. Более того, в нейтивных генераторах запросов тоже примерно такой же синтаксис, как показывает AVK.
Ну и пусть утверждает. Но AVK один, а Linq используют десятки или сотни тысяч.
V>Вот ты используешь синтаксис запросов Linq или пишешь в "классическом" стиле?
Конечно пишу Linq когда возможно. Более того, даже оптимизировал некоторые приложения переписывая с хранимок на Linq.
Здравствуйте, gandjustas, Вы писали:
G>С .NET 2.0 SqlConnection поддерживает аснхронное чтение. Ты с 2005 года .NET то видел вообще?
Вот, опять ты подставился. Это "асинхронное" чтение в дотнете сделано по технологии Completion Routines. Это предъявляет определённые требования к потоку, в котором это происходит. В результате, твоя асинхронщина подключается только тогда, когда ты вызываешь асинхронное же АПИ, иначе событие Completion Routines никогда не получит шанса на обработку. Более того, для тех же злополучных блобов, когда ты открывал к нему Stream и читал из него асинхронно, то там асинхронность эмулировалась на стороне дотнета, реально её не было. И именно там я обнаружил ошибку.
И да. Упомянутый мною баг я обнаружил на 2-м дотнете, ес-но. И мне пришлось изучить код дотнетного клиентского драйвера под MS SQL фактически наизусть. А твоя распальцовка попросту смешна, бо ты в глаза не его видел и понятие не имеешь, как он работает.
Далее. В Windows есть минимум 4 способа организации асинхронщины. Так вот, OLEDB давал "правильную" работу с TCP-соединением, даже при обычном, т.е. блокирующем чтении из него. Потому что overlapped API позволяет не только ожидать готовности данных, но может "само" заливать данные в заранее подготовленные буфера.
Ты ведь совсем не в курсе, что в дотнете до сих пор НЕТ нормального асинхронного ввода-вывода, в т.ч. у дров БД. (Вернее — в первую очередь у дров БД, бо самые большие бока с асинхронщиной в дотнете — это сетка). Ты ведь не в курсе, что типичная дотнетная асинхронщина сидит на простом сигналинге готовности, но не использует ср-ва ОС по фоновому заливу или чтению данных, которое происходит прямо по прерываниям устройств прямо из ядра, не заходя в юзверское кольцо?
Это реализация асинхронщины через Completion Ports. Ох мы и погоняли эту реализацию. Потом сравнили со своей, нейтивной. Скажем так, более неэффективной и тормозной реализации, чем по ссылке, свет еще не видел. Я тебе ОЧЕНЬ рекомендую изучить все то, что связано с SocketAsyncEventArgs, пройдись декомпилятором и посмотри, что и как там происходит... потому что на прямо сейчас ты настолько не в теме, насколько может быть не в теме человек, который вообще никогда не видел дотнета. Ужаснись тому коду, который составляет "самый эффективный способ асинхронных сокетов для дотнет". Это ужас и бред одновременно. Начиная с того, что SocketAsyncEventArgs используется вовсе не как привычный EventArgs, а как обычный объект, который надо создавать на стороне клиента библиотеки, а не получать его в событиях готовым, как это принято в XxxEventArgs. Кароч, криво всё, что можно. Всё тормозит, производительность никакая. Хотя, намного лучше, чем обычные дотнетные BeginRead/EndRead и прочий мусор, который чаще всего используется в расширениях async/await дотнета, хотя является самым неэффективным вариантом асинхронщины как таковой.
Кароч, я подробно знаю, в отличие от вас всех, внутренние механизмы библиотек ввода/вывода дотнета. Прекрасно, в отличие от вас, понимаю их ограничения. Прекрасно понимаю, почему ты, как клиент библиотеки, не имеешь возможности настраивать способ использования IO/CP или параметров overlapped в АПИ виндов. Прекрасно понимаю, почему самый эффективный сценарий асинхронности на дотнете (чтение/запись, не выходя из ядра) из дотнета недоступны. Вернее, доступны, через пины буферов, но когда кол-во пинов ужасащее (а для сервака это ВСЕГДА так, бо есть куча буферов на одно соединение, помноженное на кучу соединений), то сам дотнет начинает безбожно тормозить.
G>>>Но даже если база не падает, то твой запрос, даже самый безобидный, может отвалиться по куче причин. Начиная от банального дедлока, заканчивая происками resource governor. V>>Дедлок в базе? ))) G>Да легко
Как? "Длинные транзакции"? )))
V>>Тут кто-то пишет на курсорах пошагово? Не распланировав уровни блокировки данных? А, не! Тут же все крутые Linq-программисты, всё делается одним запросом, откуда дедлок-то? G>Дедлок можно схватить с обычным select в одной сессии и insert в другой, даже на read commited. .NET не при чем.
Это ПРИНЦИПИАЛЬНО НЕВОЗМОЖНО при одном и том же уровне блокирования. Вот просто математически не существует такого способа, хоть ты убейся. А если у тебя разные уровни блокирования к одним и тем же таблицам... гы-гы-гы... я тут даже не знаю, что сказать. Это похлеще выхода за пределы массива в С++.
G>Но я понимаю что ты не в курсе.
Я тоже кое-чего уже понимаю. Хотя, относительно конкретно тебя мне всё понятно уже слишком давно. Ты подставляешься примерно каждый второй свой пост. Ты о гранулярности блокировок слышал хоть что-нить хоть когда-нить? Я уже не о СУБД спрашиваю, а об обычной разработке. Опиши, плиз, простейший алгоритм избегать дедлока при обычной твоей разработке? Вот у тебя пара ресурсов. Процесс 1 лочит ресурс 1 и лезет в ресурс 2, в то же самое время процесс 2 уже залочил ресурс 2 и лезет в ресурс 1. Какой алгоритм недопущений дедлока в этой ситуации?
G>Судя по сообщениям только у тебя и глючило. Учитывая твой уровень знаний СУБД, мне кажется что проблема вовсе не в .NET.
Судя по экранам с ошибкой на этом сайте и не только на этом — на дотнете глючит постоянно.
V>>Ну конечно же! Предикаты и проекции — самые изменяемый части!!! Методом несложной дедукции выводим, что джоины — это самые устойчивые конструкции в разных запросах. А что я предлагал запихивать во вьюхи? Ах, блин! Неужели их же? G>И что ты собираешься выйграть от этого? Сокращение запросов на 3 строки? В чем смысл? Все равно придется генерить предикаты и проекции
Для 5 таблиц, связанных не только суррогатными атомарными ключами, а иногда и составными, это порядка 200-400 символов исходника сэкономленной копипасты. Причем, именно той копипасты, в которой чаще всего ошибаются.
V>>Если для полной инфы по товару надо сделать джоин по примерно 5-ти таблицам (и это еще скромно), то я обязательно сделаю такую вьюху, где будет описан этот джоин. И буду пользовать её в сотнях разных запросов. Примаешь, вьюха для сервака "прозрачна". Т.е. это как текстовый макрос. Не бойся, что вьюха "выбирает" все поля, а тебе нужно в проекции всего пяток, нифига лишнего на самом деле не выбирается. Это просто уже предкомпиллированный приличный кусок SQL-конструкции. G>Я тоже вьюху сделаю, но как она поможет уменьшить количество работы по генерации кучи запросов?
Избежишь копипасты.
V>>В том-то и дело, что не существует в природе "запросов с параметрами". Есть просто запросы и есть хранимки с параметрами. )) G> G>Существуют, эдак с 2000 года. Просто ты о них не знаешь. Более того в .NET используются с самой первой версии.
Нет. Это заморочки драйвера. Просто ты об этом не знаешь.
V>>Существует драйвер базы и временная хранимка уровня соединения на той стороне. Просто драйвер базы даёт такой синтаксис, что как бы просто запрос с как бы параметрами. Поэтому всё, что верно для хранимок, верно и для т.н. "запросов с параметрами". G>Опять бессвязный набор слов... Временная хранимка, драйвер базы, как-бы запрос... чушь полнейшая, уж прости.
Просто ты об этом не знаешь.
V>>Потому что параметры в запросы могут подставляться разным способом. В случае твоего Linq на каждое новое значение ID может генериться тупо другой итоговый текст с другим числовым ID, а не параметром. G>Может, но не генерируется. Провайдеры не идиоты пишут к счастью.
По-факту, кста, идиоты. Потому что зачастую новое числовое значение прямо в тексте эффективнее подставляемого параметра. И ты сам же верно говорил — почему.
V>>И как ты предлагаешь держать это всё под контролем сквозь всё приложение, где у нас будет запрос с параметром, а где тупо другой текст с другим числовым ID? G>Ты никогда не сможешь все держать под контролем.
Вообще-то смогу. Я тебя проверял.
G>Ты всегда отдаешь часть контроля в обен на скорость разработки. В языке C отдали контроль над регистрами и над стеком. В C++ отдали контроль над способом передачи структур и генерацией кода, итд. Linq отдает контроль над гененрацией запроса, а авторы провайдеров берут на себя обязательства генерировать хорошие запросы. И как обычно у автоматического генератора получается лучше, чем у среднего программиста.
Еще раз. КАК мне отделить места в выражении Linq, использующем переменные и генерящем для них параметры от мест, где вместо параметров непосредственно подставляются значения переменных? Это тебе домашнее задание, разработчик ты наш.
Здравствуйте, Ночной Смотрящий, Вы писали:
V>> При хорошей нагрузке можно упереться в превышение максимального кол-ва открытых хендлов ОС. НС>Это не приведет к сообщению о дедлоке.
С чего ты решил, что ошибка была именно из-за дедлока?
И почему, если ошибка в дедлоке, то просто-напросто не переспросить запрос заново?
Здравствуйте, gandjustas, Вы писали:
V>>Я наблюдаю периодические вылеты ADO.Net не только здесь. И рядом указал одну из причин. Еще возможная причина — недетерминированное освобождение ресурсов. При хорошей нагрузке можно упереться в превышение максимального кол-ва открытых хендлов ОС. При детерминированном освобождении такое встречается всяко реже.
G>Снова твои фантазии. В .NET с весрии 2.0 используется пул соедиений. По умолчанию до 100 соединений в пуле. Учитывая 50 рабочих потоков в пуле asp.net, а более одного соединения на поток не нужно, то даже 100 это много.
Как же ты забодал уже своей... назовём это "неосведомлённостью". И ведь спешишь отвечать первый!
Кол-во одновременно открытых соединений/сессий может на порядки превышать кол-во потоков. Потоки обрабатывают запросы, а не соединения.
Я выделил место, в котором ты подставился (опять) так, что мне хочется с тобой не общаться еще несколько лет. Нарисуй себе, что ле, на листике, как соотносятся сетевые TCP-сессии с потоками из пула. ))) А теперь, если асинхронно? ))
G>При применении асинхронных обработчиков HTTP может быть понадобится увеличить до 1000. Лимит на количество дескрипторов — около 16 тысяч в очень древних версиях windows. В нынешних версиях упереться в лимит крайне сложно.
Упереться очень просто. Без специальных настроек виндов под системную память будет выделено ограниченное пространство верхних адресов. Адресов, а не памяти, соображаешь? Т.е. даже при наличии дохрена свободной обычной памяти — ничего уже не поделать.
G>Будь добр укажи текст ошибки при "вылете ADO.NET", или приведи ссылку с описанием проблемы. А то ты сказки рассказываешь. Я 8 лет с .NET работаю (гораздо больше тебя судя по всему) и видел ошибок ADO.NET на порядок меньше, чем ты пишешь.
Считаю года я плохо, поэтому соглашусь, что ты длиннее. )))
Я работаю на дотнет с конца 2000-го года. С тех самых его бет. Особенно плотно я работал до выхода версии 3.5... От неё ожидал кое-какие обещанные ранее вещи, так и не дождался, разозлился и фактически свалил с него. Разозлился, потому что в своём хобби накатал оч большой фрйемворк в расчете на те будущие улучшения, которые нам обещали. Так же по работе нам надо было решить, спасет ли нас 3.5 или мы уходим на нейтив. Не спас. На нейтив перешли относительно безболезненно, кста. Т.е. пропали даром те самые "инвестиции трудозатрат" в дотнет, к которым нас призывали. Без ожидаемых улучшений мой фреймворк не имел смысла. Еще раз я внимательно посмотрел уже на дотнет 4.5 и разачаровался уже окончательно. В нужной мне области никаких подвижек. Это был пипец, товарищи. Это 10 лет выкинутых нафик. Юбилей, однако.
Ну тут плюсы за эти годы подтянулись до адекватного уровня... библиотеки разные, в т.ч. свои собственные... в общем, по мере развития инструментария и библиотек в нейтиве, для меня значимость дотнета с годами всё более падает.
Как только опять увижу сию ошибку этого сайта, то обязательно отпишусь. Правда, я уже сообщил о ней лично IT на форуме, а так же предложил простейший workaround как её избежать. Так что, если он внес предложенное исправление, то вряд ли дождусь именно экрана с ошибкой. Думаю, тебе лучше обратиться лично к IT и спросить, что там показывают логи (и логируются ли такие ситуации?)
Здравствуйте, IT, Вы писали:
IT>Испорченная память в нативном приложении — это проблема того же порядка.
По моему опыту, испорченная память в нейтиве на сегодня возникает только при гонках. Вот можешь себе представить вероятность такого события в нейтиве? ))
Но в дотнете по причине гонок наблюдал багов всяко больше, от дотнетных же разработчиков. У них же порог вхождения как бэ другой, что способствует. По кол-ву виденных приложений на дотнете я бы никогда не сказал, что в дотнетных программах меньше багов. Наоборот! Дотнет даёт преимущество только ОЧЕНЬ хорошему разработчику. ))) Но повальный уход в дотнет самой неграмотной части разработчиков (се ля ви!) нивелирует любые преимущества дотнета в плане статистики багов.
Я понимаю, что в своём лице ты пытаешься представлять весь дотнет. Но это не так. Ты достаточно опытен, у тебя был нейтивный опыт, ты прекрасно понимаешь ПОЧЕМУ местами именно так, а не иначе. ТЫ понимаешь мотивы, поэтому понимаешь решения и представляешь как всё работает. В реальной же дотнетной реальности всё оч печально. Половину дотнетчиков к многопоточности даже не подпускают. Лок-фри — ругательство. Чтобы хоть как-то привлечь эти массы к прекрасному, им дают async/await. Но и там, судя по местным форумам, кто не понимал многопоточность, тот продолжает пороть бока.
Здравствуйте, IT, Вы писали:
V>>А для чего в банках используется дотнет прямо на сейчас — все хорошо знают: клиентское ПО (рабочие места), отчетность, неспешная аналитика, пересчет итогов, бухгалтерия и т.д. Кароч, примерно так же, как в складских программах.
IT>Чья бы корова мукала. Запихнуть процессинг целой биржы в сохранённые процедуры базы данных — это офигительно спешное и главное супер расширяемое решение.
С чего ты решил, что биржа на хранимках? Что она вообще на БД? Я говорил о банковских наиболее популярных транзакциях в опердне, что они повсеместно на хранимках на сегодня.
Для бирж есть С/С++. Есть еще внутренние DSL, которые порождают код на С, но это ноу-хау каждой биржи.
Здравствуйте, gandjustas, Вы писали:
V>>Сколько складских программ написал уже? Сильно отличались? А вообще хоть что-то похожее было? ))) G>Учетная часть везде одинаковая (двойная запись)
Вот и нет. Это только для финансовых проводок так. А для складского учета существует несколько независимых подходов: карточный, партионный, регистровый, усреднённый, с учётом разносортицы и без этого учёта. Иногда по разным группам товаров бывает удобнее вести разный по принципу складской учёт. Т.е. в одной и той же складской программе может быть реализовано несколько алгоритмов.
G>+темпоральная часть, которая историю изменнеий хранит. Это как-бы и самая проблемная часть.
Это самая проблемная часть, когда создание исторических данных хочется автоматизировать, как в 1С — нажатием на чек-бокс. )))
А так-то какие проблемы? Карточный и партионный учёт — это разновидность "исторического" учета.
G>А сверху уже операции относительно несложно делаются. G>А в целом проще готовую платформу взять, типа 1с.
А вот и нет. Это только если встроенные ср-ва и уже имеющиеся "конфигурации" покрывают приличную часть функционала. А если нет, то с 0-ля писать на 1С — легче застрелиться.
G>>>Но для большинства программистов разница SQL или NoSQL как раз в том как с базой работать. NoSQL предлагает самый прямолинейный подход — сериализация объектов целиком, даже думать не надо, просто вызвал Save и все. Проблемы начинаются когда данные оказываются сильно связанными, присутствуют циклы в связях. Тогда NoSQL предлагает такой же прямолинейный подход — тяни все объекты и делай join руками или делай индекс и напрямую к индексу обращайся. SQL все это делает внутри, далеко не очевидным образом, что и вызывает проблемы у программистов.
V>>))) V>>Давно хотел спросить, сколько тебе лет... Можно не отвечать, это я так... ))) G>Мне 29. Но я и без этого вижу, что ответить тебе нечего.
Я думал меньше, если честно.
Мне есть что ответить. Ты часто не понимаешь МОТИВЫ тех или иных технических решений. Не понимаешь, почему именно так, а не иначе. При общении с более старшими разработчиками из местного дотнетного лагеря я таких боков не вижу — они обычно прекрасно понимают, что именно я спрашиваю или за какое место пытаюсь их поймать, когда опускаюсь до провокаций. )))
Тут когда-то был задан не очень хороший тон для общения. Это было из-за великой "битвы технологий" в те далёкие года, когда тебе было всего 17. Зря ты подхватил этот тон сейчас, объективных причин для этого на сегодня просто нет. Всё и так всем понятно. Практически всё, что мы пишем сегодня друг другу, IT, AVK, VlaD2 — мы это всё уже писали друг другу не один десяток раз еще до 2007-го, когда тебе исполнился годик на дотнете. ))) Сейчас так... фигней маемся... как бывшие спортсмены выходим иногда размяться. ))) С некоторой ленцой и заведомым пониманием, что именно ответит оппонент. ))) А ты слишком серьезно относишься к процессу, но несерьезно к фактическому материалу. AVK после залётов (у кого не бывает) хотя бы делал паузу. Ты — нет. )) Я тоже после "залётов" предпочитаю освежить/подкрепиться, кста. Что и тебе советую. Помнишь обсуждение байткода дотнетной VM, верификации, косвенности и признака управляемого и неуправляемого кода на дотнете? Тебе тогда стоило сделать паузу и подкрепиться, а не вырабатывать привычку переть на пролом даже после серии жесточайших залётов. А теперь мне трудно что-либо обсуждать с тобой всерьез. А смысл? ))
Здравствуйте, vdimas, Вы писали:
V>Упереться очень просто. Без специальных настроек виндов под системную память будет выделено ограниченное пространство верхних адресов. Адресов, а не памяти, соображаешь? Т.е. даже при наличии дохрена свободной обычной памяти — ничего уже не поделать.
Только ты забыл одну интересную вещь — это все критично для 32 бит, а 32битные серверные винды уже много лет не выпускаются. Ах да, я забыл, чуть менее чем все С++ приложения портировать на 64 бита — изрядный геморой.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, gandjustas, Вы писали:
G>>С .NET 2.0 SqlConnection поддерживает аснхронное чтение. Ты с 2005 года .NET то видел вообще?
V>Вот, опять ты подставился. Это "асинхронное" чтение в дотнете сделано по технологии Completion Routines.
Это асинхронное чтение сделано на базе нативного SNI. Так что все баги и сложность парсера — его следствие. Веб-стек, например, не опирается на сложные и старые API, поэтому там прекрасно работает асинхронность.
V>Это предъявляет определённые требования к потоку, в котором это происходит. В результате, твоя асинхронщина подключается только тогда, когда ты вызываешь асинхронное же АПИ, иначе событие Completion Routines никогда не получит шанса на обработку.
Логично, а ты что хотел? Если ты используегшь синхронное API, то ты и так занимаешь поток, зачем нужно занимать еще один поток на Completion или любые другие пляски исполнять, если в итоге получатель данных работает синхронно?
V>Более того, для тех же злополучных блобов, когда ты открывал к нему Stream и читал из него асинхронно, то там асинхронность эмулировалась на стороне дотнета, реально её не было.
Если у тебя не установлен CommandBehavior.SequentialAccess, то парсер TDS читает строку, а тебе отдает тупо MemoryStream.
Если у тебя установлен CommandBehavior.SequentialAccess, то тебе отдается SqlSequentialStream, который таки асинхронно читает поток. Глянь в ILSpy — он ожидает сигнала получения пакета и копирует байты в выходной буфер.
V>И именно там я обнаружил ошибку.
Какую ошибку? В каком методе? Ничего что GetStream появился в .NET 4.5, а ты рассказываешь про какие-то дремучие времена?
По моему эти ошибки только в твоем воображении существуют.
V>И да. Упомянутый мною баг я обнаружил на 2-м дотнете, ес-но. И мне пришлось изучить код дотнетного клиентского драйвера под MS SQL фактически наизусть. А твоя распальцовка попросту смешна, бо ты в глаза не его видел и понятие не имеешь, как он работает.
Ну ты окончательно заврался, GetStream появился только в .NET 4.5.
До .NET 4.5 не было API для асинхронного чтения ридера.
V>Далее. В Windows есть минимум 4 способа организации асинхронщины. Так вот, OLEDB давал "правильную" работу с TCP-соединением, даже при обычном, т.е. блокирующем чтении из него. Потому что overlapped API позволяет не только ожидать готовности данных, но может "само" заливать данные в заранее подготовленные буфера.
Ага, верю, чувак, верю. Жги дальше.
V>Ты ведь совсем не в курсе, что в дотнете до сих пор НЕТ нормального асинхронного ввода-вывода, в т.ч. у дров БД. (Вернее — в первую очередь у дров БД, бо самые большие бока с асинхронщиной в дотнете — это сетка). Ты ведь не в курсе, что типичная дотнетная асинхронщина сидит на простом сигналинге готовности, но не использует ср-ва ОС по фоновому заливу или чтению данных, которое происходит прямо по прерываниям устройств прямо из ядра, не заходя в юзверское кольцо?
Глянул в ILSpy говорит что в .NET используется WSASend\WSARecv функции с Overlapped.
Ты знаешь более православный способ, который "использует ср-ва ОС по фоновому заливу или чтению данных, которое происходит прямо по прерываниям устройств прямо из ядра, не заходя в юзверское кольцо"?
V>Только в дотнете 3.5 появился первый более-менее настоящий асинхронный сокет, а не та порнография, что была до этого. V>Курить тут: V>http://msdn.microsoft.com/en-us/library/system.net.sockets.socketasynceventargs(v=vs.90).aspx
V>Это реализация асинхронщины через Completion Ports. Ох мы и погоняли эту реализацию. Потом сравнили со своей, нейтивной. Скажем так, более неэффективной и тормозной реализации, чем по ссылке, свет еще не видел.
Хватит писать слова, просто покажи пример как надо. И замеры покажи.
Я вообще не верю что ты чтототам смотрел, не верю абсолютно ни одному твоему слову.
V>Кароч, я подробно знаю, в отличие от вас всех, внутренние механизмы библиотек ввода/вывода дотнета. Прекрасно, в отличие от вас, понимаю их ограничения. Прекрасно понимаю, почему ты, как клиент библиотеки, не имеешь возможности настраивать способ использования IO/CP или параметров overlapped в АПИ виндов. Прекрасно понимаю, почему самый эффективный сценарий асинхронности на дотнете (чтение/запись, не выходя из ядра) из дотнета недоступны. Вернее, доступны, через пины буферов, но когда кол-во пинов ужасащее (а для сервака это ВСЕГДА так, бо есть куча буферов на одно соединение, помноженное на кучу соединений), то сам дотнет начинает безбожно тормозить.
Ну приведи замеры, примеры кода итп, на слово тебе верить чтоли?
G>>>>Но даже если база не падает, то твой запрос, даже самый безобидный, может отвалиться по куче причин. Начиная от банального дедлока, заканчивая происками resource governor. V>>>Дедлок в базе? ))) G>>Да легко
V>Как? "Длинные транзакции"? )))
Нет. В одной сессии один селект, а в другой один update. Уровень изоляции read commited (без snapshot).
V>>>Тут кто-то пишет на курсорах пошагово? Не распланировав уровни блокировки данных? А, не! Тут же все крутые Linq-программисты, всё делается одним запросом, откуда дедлок-то? G>>Дедлок можно схватить с обычным select в одной сессии и insert в другой, даже на read commited. .NET не при чем.
V>Это ПРИНЦИПИАЛЬНО НЕВОЗМОЖНО при одном и том же уровне блокирования. Вот просто математически не существует такого способа, хоть ты убейся. А если у тебя разные уровни блокирования к одним и тем же таблицам... гы-гы-гы... я тут даже не знаю, что сказать. Это похлеще выхода за пределы массива в С++.
Действительно не знаешь, а на практике кейс очень частый.
Селект использует индекс по полю, и индекс оказывается не покрывающий.
Поэтому select делает сначала index seek, вешая S блокировку на ключ в индексе, а потом Key Lookup, блокируя ключ в странице данных.
А insert сначала пишет в кластерный индекс, вешая X блокировку на страницу, а потом пишет индекс, также пытаясь навесить X блокировку.
Порядок блокировок оказывается разный, возникает deadlock. В нагруженных системах, где нет возможости создать покрывающие индексы на все случаи, такое может случаться довольно часто.
Но я так понимаю ты к таким нагруженным даже близко не подходил, как и не делал большинство из того, что ты тут пишешь. У тебя это все теория, у тебя все "математически"
G>>Но я понимаю что ты не в курсе. V>Я тоже кое-чего уже понимаю. Хотя, относительно конкретно тебя мне всё понятно уже слишком давно. Ты подставляешься примерно каждый второй свой пост.
Кто бы говорил
V>Ты о гранулярности блокировок слышал хоть что-нить хоть когда-нить?
А-то сылшал, а ты, похоже, нет.
V>Я уже не о СУБД спрашиваю, а об обычной разработке. Опиши, плиз, простейший алгоритм избегать дедлока при обычной твоей разработке? Вот у тебя пара ресурсов. Процесс 1 лочит ресурс 1 и лезет в ресурс 2, в то же самое время процесс 2 уже залочил ресурс 2 и лезет в ресурс 1. Какой алгоритм недопущений дедлока в этой ситуации?
В отличие от тебя я не пишу такой код, который лочит ресурсы в случайном порядке. Бросил это дело еще на первой работе, открыл для себя lock-free алгоритмы. Они, конечно, медленнее в отдельности, но в совокупности в разы лучше локов работают.
G>>Судя по сообщениям только у тебя и глючило. Учитывая твой уровень знаний СУБД, мне кажется что проблема вовсе не в .NET. V>Судя по экранам с ошибкой на этом сайте и не только на этом — на дотнете глючит постоянно.
Ну покажи хоть один экран с ошибкой .NET. Почему эта ошибка только у тебя, а у тысяч других пользователей RSDN её нет?
V>>>Ну конечно же! Предикаты и проекции — самые изменяемый части!!! Методом несложной дедукции выводим, что джоины — это самые устойчивые конструкции в разных запросах. А что я предлагал запихивать во вьюхи? Ах, блин! Неужели их же? G>>И что ты собираешься выйграть от этого? Сокращение запросов на 3 строки? В чем смысл? Все равно придется генерить предикаты и проекции
V>Для 5 таблиц, связанных не только суррогатными атомарными ключами, а иногда и составными, это порядка 200-400 символов исходника сэкономленной копипасты. Причем, именно той копипасты, в которой чаще всего ошибаются.
Разговор начался с того, что у нас Linq позволяет не делать копипасту и позволяет делать много чего еще. Но даже эти 200 символов это менее 20% от среднего объема запроса будут, который все равно никак функциям или вьюхами не разрулишь.
V>>>Если для полной инфы по товару надо сделать джоин по примерно 5-ти таблицам (и это еще скромно), то я обязательно сделаю такую вьюху, где будет описан этот джоин. И буду пользовать её в сотнях разных запросов. Примаешь, вьюха для сервака "прозрачна". Т.е. это как текстовый макрос. Не бойся, что вьюха "выбирает" все поля, а тебе нужно в проекции всего пяток, нифига лишнего на самом деле не выбирается. Это просто уже предкомпиллированный приличный кусок SQL-конструкции. G>>Я тоже вьюху сделаю, но как она поможет уменьшить количество работы по генерации кучи запросов? V>Избежишь копипасты.
И? как это поможет около 15 различных запросов сгенерировать? С Linq таких проблем вообще не будет, а вьюха позволяет избавится от 200 символов копипасты, которые вообще не станут проблемой, пока схема не поменяется.
V>>>В том-то и дело, что не существует в природе "запросов с параметрами". Есть просто запросы и есть хранимки с параметрами. )) G>> G>>Существуют, эдак с 2000 года. Просто ты о них не знаешь. Более того в .NET используются с самой первой версии. V>Нет. Это заморочки драйвера. Просто ты об этом не знаешь.
Про sp_executesql слышал? А про автопараметризацию?
Но я уже понял что у тебя все только "математически"
V>>>Существует драйвер базы и временная хранимка уровня соединения на той стороне. Просто драйвер базы даёт такой синтаксис, что как бы просто запрос с как бы параметрами. Поэтому всё, что верно для хранимок, верно и для т.н. "запросов с параметрами". G>>Опять бессвязный набор слов... Временная хранимка, драйвер базы, как-бы запрос... чушь полнейшая, уж прости. V>Просто ты об этом не знаешь.
Ну да, об этом знаешь только ты. Даже создатели SQL Server не знают об этом.
V>>>Потому что параметры в запросы могут подставляться разным способом. В случае твоего Linq на каждое новое значение ID может генериться тупо другой итоговый текст с другим числовым ID, а не параметром. G>>Может, но не генерируется. Провайдеры не идиоты пишут к счастью. V>По-факту, кста, идиоты. Потому что зачастую новое числовое значение прямо в тексте эффективнее подставляемого параметра. И ты сам же верно говорил — почему.
Прости, но если сравнить тебя и среднего писателя Linq-провайдера, то звание идиота он не получит.
Под каждый новый параметр SQL начнет компилировать запрос, что будет долго. Запрос с параметром может быть хуже только в случае нестабильного плана, но это проблема плана, а не параметра.
V>>>И как ты предлагаешь держать это всё под контролем сквозь всё приложение, где у нас будет запрос с параметром, а где тупо другой текст с другим числовым ID? G>>Ты никогда не сможешь все держать под контролем. V>Вообще-то смогу. Я тебя проверял.
Да у тебя парсер TDS падает, что ты держать под контролем можешь вообще?
Сказки какие-то рассказываешь только.
G>>Ты всегда отдаешь часть контроля в обен на скорость разработки. В языке C отдали контроль над регистрами и над стеком. В C++ отдали контроль над способом передачи структур и генерацией кода, итд. Linq отдает контроль над гененрацией запроса, а авторы провайдеров берут на себя обязательства генерировать хорошие запросы. И как обычно у автоматического генератора получается лучше, чем у среднего программиста.
V>Еще раз. КАК мне отделить места в выражении Linq, использующем переменные и генерящем для них параметры от мест, где вместо параметров непосредственно подставляются значения переменных? Это тебе домашнее задание, разработчик ты наш.
В большинстве случаев константа подставляется в текст запроса, а переменная — нет. Но детали могут от провайдера зависеть. Например хорошим тоном считается подстановка NULL в запрос, ибо без этого можно получить хреновый план. Короче проще проверить, а не гадать или "математически доказывать".
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, gandjustas, Вы писали:
V>>>Я наблюдаю периодические вылеты ADO.Net не только здесь. И рядом указал одну из причин. Еще возможная причина — недетерминированное освобождение ресурсов. При хорошей нагрузке можно упереться в превышение максимального кол-ва открытых хендлов ОС. При детерминированном освобождении такое встречается всяко реже.
G>>Снова твои фантазии. В .NET с весрии 2.0 используется пул соедиений. По умолчанию до 100 соединений в пуле. Учитывая 50 рабочих потоков в пуле asp.net, а более одного соединения на поток не нужно, то даже 100 это много.
V>Как же ты забодал уже своей... назовём это "неосведомлённостью". И ведь спешишь отвечать первый! V>Кол-во одновременно открытых соединений/сессий может на порядки превышать кол-во потоков. Потоки обрабатывают запросы, а не соединения.
Ты похоже вообще не понимаешь...
Один рабочий поток в один момент времени обрабатывает один запрос, для одного запроса достаточно одного соединения. Зачем иметь более одного соединения на поток?
100 выбрано как раз из-за сценария asp.net, с учетом того что хреново написанный код может несколько соединений на один запрос использовать.
V>Я выделил место, в котором ты подставился (опять) так, что мне хочется с тобой не общаться еще несколько лет. Нарисуй себе, что ле, на листике, как соотносятся сетевые TCP-сессии с потоками из пула. ))) А теперь, если асинхронно? ))
Как раз об асинхронном я написал ниже, ты читаешь перед тем, как отвечать?
G>>При применении асинхронных обработчиков HTTP может быть понадобится увеличить до 1000. Лимит на количество дескрипторов — около 16 тысяч в очень древних версиях windows. В нынешних версиях упереться в лимит крайне сложно.
V>Упереться очень просто. Без специальных настроек виндов под системную память будет выделено ограниченное пространство верхних адресов. Адресов, а не памяти, соображаешь? Т.е. даже при наличии дохрена свободной обычной памяти — ничего уже не поделать.
А при чем тут адреса, если речь про дескрипторы? Для них не обязаны никакие адреса выделяться.
Ну даже если предположить что чтототам выделяется, то все равно в пуле соединений по умолчанию не более 100 соединений, я видел единицы проектов где этого не хватало. Упереться в максимальное количество хендлов при этом нельзя.
До этого момента ты и не знал, что есть пул соединений, то есть в живую ты не мог этой картины наблюдать. Получается что это снова твои фантазии и не более того, все вылеты ado.net просто плод твоего воображения.
G>>Будь добр укажи текст ошибки при "вылете ADO.NET", или приведи ссылку с описанием проблемы. А то ты сказки рассказываешь. Я 8 лет с .NET работаю (гораздо больше тебя судя по всему) и видел ошибок ADO.NET на порядок меньше, чем ты пишешь. V>Считаю года я плохо, поэтому соглашусь, что ты длиннее. )))
Все таки укажи текст ошибки.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, gandjustas, Вы писали:
V>>>Сколько складских программ написал уже? Сильно отличались? А вообще хоть что-то похожее было? ))) G>>Учетная часть везде одинаковая (двойная запись)
V>Вот и нет. Это только для финансовых проводок так. А для складского учета существует несколько независимых подходов: карточный, партионный, регистровый, усреднённый, с учётом разносортицы и без этого учёта. Иногда по разным группам товаров бывает удобнее вести разный по принципу складской учёт. Т.е. в одной и той же складской программе может быть реализовано несколько алгоритмов.
Да-да, я всю эту херню слышал от "эксперта", а потом запилил проводки с дополнительными аналитическими признаками. А сверху на них уже нужный учет накрутил. Основные проблема были — узнать сколько на складе товара определенного вида, а также узнать оборот за период (сколько пришло, сколько ушло). Эти операции делались медленно, как раз потому что "эксперт" в базе понарожал лишних сущностей.
G>>+темпоральная часть, которая историю изменнеий хранит. Это как-бы и самая проблемная часть. V>Это самая проблемная часть, когда создание исторических данных хочется автоматизировать, как в 1С — нажатием на чек-бокс. ))) V>А так-то какие проблемы? Карточный и партионный учёт — это разновидность "исторического" учета.
Конкретно в этой части у меня проблем не было.
G>>А сверху уже операции относительно несложно делаются. G>>А в целом проще готовую платформу взять, типа 1с.
V>А вот и нет. Это только если встроенные ср-ва и уже имеющиеся "конфигурации" покрывают приличную часть функционала. А если нет, то с 0-ля писать на 1С — легче застрелиться.
Честно не в курсе насколько сложно писать конфигурацию с нуля, но конфигурации для склада в 1С есть, дальше можно под себя пилить.
G>>>>Но для большинства программистов разница SQL или NoSQL как раз в том как с базой работать. NoSQL предлагает самый прямолинейный подход — сериализация объектов целиком, даже думать не надо, просто вызвал Save и все. Проблемы начинаются когда данные оказываются сильно связанными, присутствуют циклы в связях. Тогда NoSQL предлагает такой же прямолинейный подход — тяни все объекты и делай join руками или делай индекс и напрямую к индексу обращайся. SQL все это делает внутри, далеко не очевидным образом, что и вызывает проблемы у программистов.
V>>>))) V>>>Давно хотел спросить, сколько тебе лет... Можно не отвечать, это я так... ))) G>>Мне 29. Но я и без этого вижу, что ответить тебе нечего.
V>Я думал меньше, если честно.
А я думал, что ты умнее, если честно. А ты все доказываешь что у тебя больная фантазия и много слов нахватался. Реальных знаний и опыта у тебя очень мало.
V>Мне есть что ответить. Ты часто не понимаешь МОТИВЫ тех или иных технических решений. Не понимаешь, почему именно так, а не иначе. При общении с более старшими разработчиками из местного дотнетного лагеря я таких боков не вижу — они обычно прекрасно понимают, что именно я спрашиваю или за какое место пытаюсь их поймать, когда опускаюсь до провокаций. )))
Твои провокации смешны, ты выпячиваешь свое незнание и сыпишь кучей терминов, не имеющих отношения к делу. Доказательств твоих слов я пока не видел. Ни разу вообще.
Мотивы я понимаю получше тебя, потому что понимаю ЭКОНОМИЧЕСКИЕ мотивы ТЕХНИЧЕСКИХ решений. В отличие от тебя у меня экономических мотивов гораздо больше и я гораздо лучше знаю как они влияют.
Здравствуйте, gandjustas, Вы писали:
V>>>>Пока не увижу в новостях, что где-то вышел движок биржи на Linq или банковский оп-день — это всё сказки про белого бычка. G>>>А ты видишь в новостях про биржи на ODBC или опердни на ADO?
V>>Твой вопрос лишен смысла. G>Также как и твой.ODBC и ADO такие же технологии работы с данными, как и EF.
V>>Биржи написаны на С/С++. ВСЕ единицы попыток переписать биржи на дотнет закончились отказом от этих попыток. G>Я знаю только одну историю про LSE, у тебя еще есть?
Э, нет. В случае LSE биржа реально перешла на дотнет, а потом вернулась. А так-то многие ведущие биржи активно внедряли дотнет. Просто, в случае именно "движка" биржи, до релиза дело не дошло.
V>>Наиболее часто вызываемые рантайм-транзакции в оперднях банков сделаны на хранимках. G>Не факт что это хорошо.
Зато безопасно. Потому что, если процессить внешним серваком — то это можно быстро, конечно, но встаёт вопрос об журналинге транзакций в БД — в случае непредвиденности можно потерять транзакции за последние миллисекунды. А это ну ваще никак нельзя. А если делать на внешнем серваке приложений т.н. "длинные транзакции", то резко падает производительность. Поэтому, самые частовызываемые вещи делают в БД. В принципе, возможность писать хранимки на дотнете может помочь.
V>>Linq — это не просто генератор запросов, это еще мега-удобный маппер их результатов. В нейтиве такое на сегодня, увы, никак в подобном виде. В нейтиве код маппинга обычно генерируют отдельной тулзиной, типа http://www.qxorm.com/qxorm_en/home.html или http://www.codesynthesis.com/products/odb/, а то и просто ручками, см. boost::serialization. Только в следующем стандарте С++ ожидается, наконец, стандарт на ABI и на метаинформацию... только тогда можно будет делать сравнимые в плане удобства для разработчика мапперы на плюсах, без необходимости подключать и настраивать внешние утилиты для процесса разработки.
G>При чем тут маппер?
Потому что для нейтива это самая болезненная часть.
G>Код на C++ уже научился запросы генерить из лямбд?
Да. В С++, в отличие от, можно переопределить вообще все операторы языка, даже операторы присваивания. Это позволяет в том же синтаксисе организовать некий query builder.
G>Маппер это малекькая часть, которая при наличии прямых рук пишется за неделю.
Я напишу тебе маппер на десяток объектов с помощью boost::serialization за единицы минут. Дальше что? По мере разработки этих объектов, добавления/удаления — ничего автоматом не происходит. Нужно ручками синхронизировать. Кароч, геммор не приведи господь, если этих объектов сотни. Поэтому с внешними тулзами удобнее, они дают хоть какую-то автоматизацию. Тебе не с чем сравнить, ты не понимаешь, насколько это круто — интегрированный маппер. )))
G>>>Но именно этот генератор запросов позволяет разрабатывать приложения с огромной скоростью, не нагружая DBA написанием селектов. V>>Ну вот AVK утверждает, что он не пользуется специфическим Linq-синтаксисом. А используемый им синтаксис был доступен мне еще хрен его знает когда через самописный генератор запросов + маппинг через BLT. Более того, в нейтивных генераторах запросов тоже примерно такой же синтаксис, как показывает AVK. G>Ну и пусть утверждает. Но AVK один, а Linq используют десятки или сотни тысяч.
V>>Вот ты используешь синтаксис запросов Linq или пишешь в "классическом" стиле? G>Конечно пишу Linq когда возможно. Более того, даже оптимизировал некоторые приложения переписывая с хранимок на Linq.
Ты не понял вопроса, походу. Библиотеку Linq можно использовать как обычную библиотеку, без использования в коде "синтаксиса запросов". Я спрашиваю — ты используешь этот новый синтаксис запросов или используешь Linq в виде вызовов обычных методов (методов-расширений в т.ч.)?
Если нам не помогут, то мы тоже никого не пощадим.
