Здравствуйте, gandjustas, Вы писали:
G>Бери ef и не парься.
Это несовместимые условия ))
Опять же, стартовать новый проект на заведомо устаревших технологиях — довольно странный совет, если только задача не "сделать и забыть".
Здравствуйте, IB, Вы писали:
IB>Здравствуйте, gandjustas, Вы писали:
G>>Бери ef и не парься. IB>Это несовместимые условия )) IB>Опять же, стартовать новый проект на заведомо устаревших технологиях — довольно странный совет, если только задача не "сделать и забыть".
Апгрейд сделать не проблема вообще. Я переводил с 4.0 database first на 5.0 codefirst, заняло от силы пару часов. Переезд ef6 -> ef7 гораздо проще будет.
Здравствуйте, gandjustas, Вы писали:
G>Апгрейд сделать не проблема вообще. Я переводил с 4.0 database first на 5.0 codefirst, заняло от силы пару часов. Переезд ef6 -> ef7 гораздо проще будет.
We’ll be keeping the same concepts and patterns wherever it makes sense. The upgrade to EF7 will require some changes to your code. Our aim is that code that uses the core functionality of the DbContext API will upgrade easily, code that makes use of the lower level APIs in EF may require more complicated changes.
То есть переводя в практическую плоскоть — они даже API не собираются сохранять.
Переезд с 4.0 на 5.0 и должен был пройти гладко так как старый функционал не выкидывали. Здесь же в корне меняется концепция — из Havy ORM будут делать lightweight ORM, переписав продукт заново и сохранив API лишь там где концепции пересекаются.
В свете этого, я не понимаю откуда надежда, что переезд на 7-ю версию пройдет безболезненно.
Здравствуйте, IB, Вы писали:
IB>Здравствуйте, gandjustas, Вы писали:
G>>Апгрейд сделать не проблема вообще. Я переводил с 4.0 database first на 5.0 codefirst, заняло от силы пару часов. Переезд ef6 -> ef7 гораздо проще будет.
IB>We’ll be keeping the same concepts and patterns wherever it makes sense. The upgrade to EF7 will require some changes to your code. Our aim is that code that uses the core functionality of the DbContext API will upgrade easily, code that makes use of the lower level APIs in EF may require more complicated changes. IB>То есть переводя в практическую плоскоть — они даже API не собираются сохранять.
IB>Переезд с 4.0 на 5.0 и должен был пройти гладко так как старый функционал не выкидывали. Здесь же в корне меняется концепция — из Havy ORM будут делать lightweight ORM, переписав продукт заново и сохранив API лишь там где концепции пересекаются. IB>В свете этого, я не понимаю откуда надежда, что переезд на 7-ю версию пройдет безболезненно.
еще раз: я переводил с 4.0 database-first (с использованием генератора POCO) на 5.0 code first. Там поменялось все — меппинг, апи, дефолтное поведение. Это заняло пару часов.
Переезд ef6 -> ef7, которые оба codefirst, выльется в правку пары вызовов API.
Здравствуйте, gandjustas, Вы писали:
G>еще раз: я переводил с 4.0 database-first (с использованием генератора POCO) на 5.0 code first.
Странно, что приходится объяснять... code-first или last — значения не имеет. Это вообще фича с боку.
Между 4 и 5 — была обратная совместимость. Между 6 и 7 ее не будет.
G>Переезд ef6 -> ef7, которые оба codefirst, выльется в правку пары вызовов API.
Они оба ORM, на этом сходство заканчивается.
Здравствуйте, IB, Вы писали:
IB>Здравствуйте, gandjustas, Вы писали:
G>>еще раз: я переводил с 4.0 database-first (с использованием генератора POCO) на 5.0 code first. IB>Странно, что приходится объяснять... code-first или last — значения не имеет. Это вообще фича с боку. IB>Между 4 и 5 — была обратная совместимость. Между 6 и 7 ее не будет.
Между database-frist и code first не было и нет.
G>>Переезд ef6 -> ef7, которые оба codefirst, выльется в правку пары вызовов API. IB>Они оба ORM, на этом сходство заканчивается. https://github.com/aspnet/EntityFramework посмотри примеры, тот же DbContext и DbSet, те же мапинги и миграции.
Ты тоже ведешься на сказки о "полном переписывании" ? Посмотри историю, там видно что в начале тупо скопировали из существующей кодовой базы.
Здравствуйте, gandjustas, Вы писали:
G>Между database-frist и code first не было и нет.
и еще раз: что именно там first — фича с боку, и на переход межу версиями не влияет.
G>https://github.com/aspnet/EntityFramework посмотри примеры, тот же DbContext и DbSet, те же мапинги и миграции.
Какая разница, DbContext или DataContext? Важно как оно работает. Если ты заложишься на LazyLoading или ChangeTracking какой-нибудь, а тебе его открутят в новой версии, то это будет уже совсем другой масштаб проблемы.
G>Ты тоже ведешься на сказки о "полном переписывании" ? Посмотри историю, там видно что в начале тупо скопировали из существующей кодовой базы.
У меня все просто — я смотрю не на сказки, а на готовый результат. Если результат мне нравится, я его использую, если же я вижу, что уродец получился (как в случае EF) — то не использую и другим не рекомендую.
IT>Чем HTML лучше того же WPF и что вообще подразумевается под "лучший UI"? IT>Ну не знаю. По мне так вроде нормально работает. Есть, конечно, косяки, в том числе касающиеся не только производительности. Например, сама по себе вполне качественная идея обезображена местами кривой имплементацией. Что касается производительности, то с ней всё впорядке, если не увлекаться кривыми левыми контролами и самому не злоупотреблять вложенностью контролов. IT>XAML — это по сути один большой костыль. Парни из MS вроде как сообразили, что для разметки UI пора делать свой собственный DSL, но не решились его сделать по человечески как тот же Razor, например. Вот и получился редкосный уродец на XML, который у нас в таких случаях выступает как универсальный всемогутор-языкозаменитель. IT>Всё это по сути лишь подтверждение моих слов о том, что идёт отбраковка и шлифовка.
В WPF (даже по сравнению с html/css/js) плохо всё: XAML, Dependency Properties, Data Binding, Control Templates, Data Templating, Triggers, Resource dictionaries, Commands, Logical and Visual Trees, Animation.
Всё перечисленное это безумие архитекторов астронавтов, которые малом писали приложений для конечных пользователей.
WPF не шлифовать надо, а просто выкинуть. Собственно, так и происходит, никто его не шлифует. Инсайдер из компании, которая занимается разработкой визуальных компонент, говорил, что продажи WPF компонент крайне малы (не окупаются даже). У Silverlight с продажами контролов было получше. Из-за того, что разработчики жаждут C# на клиенте и через web (но отнюдь не благодаря архитектуре). Но теперь это уже прошлое, не о чем говорить.
html/css/js далеко не идеален. Но это нормальный проверенный временем набор элементарных UI кирпичиков, из которых можно строить сложный UI. Никому не пришло в голову в UI ядро встраивать Data Binding, Data Templating, Control Templates. UI должен отвечать за UI.
Из концептуальных серьезных недостатков html/css/js отсутствие статической типизации, но для js это худо бедно решили с помощью TypeScript. А в css можно и отсутствие статической типизации потерпеть.
Т.е. у .NET огромный потенциал сделать лучший UI движок на базе статической типизации, но архитекторы астронавты умудрились слить даже html/css/js.
Здравствуйте, gandjustas, Вы писали:
V>>А я говорил, что ты не понимаешь нифига. Visual Studio вышла до выхода WinRT. Более того, она должна работать даже на тех версиях виндов, где WinRT не поддерживается. Более того, запуск студии в 5-15 секунд никого не волнует. Это же утилитное приложение. Вот если бы виндовый калькулятор запускался 5-15 секунд, то никто бы его не использовал. Вот почему в коробочных продуктах фактически нет WPF.
G>Действительно не понимаю как это связано. Похоже что связь у тебя в голове только существует.
Я же сразу сказал — не понимаешь нифига. Не понимаешь, почему студия написана на WPF, а не на WinRT. Не понимаешь, почему виндовый калькулятор на WPF не написан, хотя (я уверен) будет переписан на winRT (или уже полно аналогов с аналогичным временем запуска, как у старого).
G>>>А если учесть что из WPF родился UI для Windows 8 и Windows Phone, то не понимаю вдвойне. V>>А я говорил, что ты не понимаешь нифига. Этим UI должен был стать дотнетный "Авалон". Поищи по "Avalon Longhorn". G>Кому должен?
Согласно планам MS, где дидлайн был на конец 2006-го.
G>Может быть и стал бы, не будь у Синофски зуб на .NET.
Чего же до него не стал? Лет 6 было в запасе даже после дидлайна.
G>На WP таки сделали на .NET UI, только через несколько лет таки переписали на COM, чтобы единая платформа была.
Нет. Не сделали. Должна была быть не просто очередная ГУИ-либа для дотнета, а фундаментальная ГУИ среда для виндов, типа как было Win32+GDI. Так вот, WPF так и не стал тем, чем должен был стать. Собсно, наличие сервелатов уже говорило само за себя.
V>>Так вот. Эпик фейл WPF в том, что он так и не стал Авалоном. Заодно ЗАДЕРЖАЛ выход новых виндов более чем на 5 лет. Windows Vista должна была быть последним фейс-лифтом старых виндов, типа как Windows 98 перед Windows XP. А по-факту Windows Vista задержалась на 8 лет как основная операционка в виде "ребрендинга" Windows 7. И эта задержка могла бы продолжаться вечно, если бы не волевое решение переписать нафик Авалон на нейтиве. G>Ты веришь в маркетинговый буллшит? Слишком много слов "должен\должна", тебе никто ничего не должен, успокойся.
Ты утомил своей непроходимостью, реально. Официальный объявленный MS дидлайн операционки на Авалон был конец 2006-го года. Что здесь сложного для понимания?
V>>6 лет задержки из-за того, что дотнет так и не стал обладать необходимыми потребительскими характеристиками. G>При чем тут .NET? Почему это не помешало сделать UI для WP7 на .NET?
Потому что WP7 в ж-пе, по факту. WP8 — цаца. Некоторые аппараты можно обновить до 8-й.
V>>Масштаб этого эпик фейла не поддаётся осмыслению. Собсно, именно с конца 2006-го года начался обратный отсчет уровню доверия дотнету, как универсальной платформе. Прямо на сегодня этот уровень нулевой. Дотнет нифига не универсален, а занял лишь те ниши, в которых неплоха была и Джава. На этом всё. G>Сильную роль сыграло развитие JS, которое по сути похоронило идею Rich Desktop UI, очень популярную в начале 20 века
Не вижу никаких похорон. ГУИ внутри браузера как было унылым г-ном, так и осталось. А так-то десктопный ГУИ на скриптах отродясь писался что в Линухах, что под виндой на VBS, твоя JS — просто одна из популярных технологий. Ты не туда смотришь, кароч. Автоматизация на скриптах делается над каким-то низлежащим движком. Так вот, дотнетный движок им не стал, winRT — полностью нейтивная платформа.
V>>В 2005-2006 годах я занимался этим вопросом много и видел много таких проектов. На сегодня они не актуальны, ес-но, т.к. вопрос можно считать закрытым. Можешь поискать еще кодеки, например по speex dotnet. Я сходу нашел NAudio, например. Но более детальное знакомство показало, что для того же speex используется нейтивный кодек, хотя в проекте NSpeex были планы по релизу "родного" дотнетного кодека. Собсно, перевести открытый исходник на дотнет — это 2-3 дня работы разработчику средней руки. Я видел в те времена несколько "родных" дотнетных реализаций кодеков. Один из кодеков на дотнете как-то публиковал здесь я, для G.711. Портирование его из нейтива заняло меньше часа. Пользовали это в своих проектах. Характеристики производительности ни к черту. Поэтому, дотнет остался только для макетирования всех этих вещей, для боевого применения более половины движка переписали на нейтив, оставив дотнету только сигналинг. G>Я понял, про астериск были фантазии.
Нифиг ты не понял опять. Все эти эпик-фейлы ушли с горизонта уже к 2008-му окончательно. Но я тебе дал вполне конкретные имена проектов. Но эти проекты можно использовать лишь для макетирования, а не для боевого применения.
G>Про кодеки — не ясно зачем их на .NET писать вообще, там же числомолотилка, .NET ничего не даст.
1. Почему числомолотилка на дотнете хуже нейтивной? А как же JIT?
2. А где вообще дотнет что-то даст, окромя неспешного разбора ответа базы или формирования неспешного WEB-ответа?
V>>Если сможешь заставить работать быстрее — велкам. )) При том, что этот кодек до невозможности примитивен, в сравнении с тем же speex. G>Пот посмотрел на код, его чуть ли не 1-в-1 можно на C заменить (даже не C++), только массивы надо извне передавать. А для .NET можно написать обертку, которая зовет эту либу.
Еще раз повторю вопрос №1.
Вычисления по ссылке целочисленные, заметь. То бишь, даже пресловутое неумение дотнета пользовать SSEx оставим за кадром. Там банальные табличные вычисления. Дотнет сливает раза в 3 нейтиву даже на этом примитиве.
V>>Paint.Net не требует быстродействия. Вообще. Я разработал графический редактор для конференций на дотнете в 2006-м, где участники конференций могут рисовать на одной доске совместно. Никакой скорости не требуется. Вообще. Потому что основные тормоза от самой сетки. Потому что события даже от самых крутых мышек поступали не чаще 100 раз в секунду. Более того, мой редактор векторный, участники конференций могут изменять объекты, нарисованные другими участниками. Это намного сложнее растровой графики. G>Большинство десктопных приложений не требует быстродействия, вообще.
Фотошоп или CorelDraw требует еще как. Про AutoCAD я вообще молчу. Не говори таких глупостей никогда — засмеют.
G>Ни мессенджеры, ни заметки, ни какая-либо еще фигня.
Мессенджер должен запускаться мгновенно, так же как заметки и прочая фигня. Яховский мессенджер сдох именно по причине долгого (до 20 сек) запуска. OneNote тоже нейтивный и тоже быстро запускается. Кароч, я не понимаю, как ты не понимаешь очевидных аргументов.
G>Быстродействия на десктопе требуют игры
ВСЁ требует быстродействия. Браузер, калькулятор, мессенджер, фото-редактор.
G>в которых кстати игровая логика пишется на скриптовых языках
ы-ы-ы
G>которые по твоему гораздо менее надежны и быстры
А где надежность сидит, по-твоему?
В типичной современной навороченной игре используется нейтивный движок на порядка 3-5 млн строк исходников, порядка 30-50 тыщ строк исходников тех самых "скриптов для логики" и гигабайты медиа.
V>>В плане требований к производительности сравни с теми же нейтивными фильтрами для фотошлёпа, где даже на современных рабочих станциях хочется добавить мощщи. На дотнете это просто не влетит. От слова вообще. Се ля ви. G>Хм... почему фотошопу требуется быстродействие, а paint.nt — нет?
Хороший вопрос. Предлагаю освоить оба продукта самостоятельно. "Ты же программист!" ))
G>Разница только в тормозных фильтрах? Которые кстати тоже числомолотилки.
Даже без фильтров, при десятке слоёв с наложением для современной 16мбпкс фоты с камеры твой дотнетный паинт сразу мертв. А фотошлёп живее всех живых.
G>>>EverNote написали на .NET, получили инвестиции, пошли переписывать на C++. С таким баблом можно было и на ассемблере написать. А бекенд то на .NET и остался. Если бы начали на C++, то не то что инвестиций, даже релиза не было бы.
V>>Не юли. ЗАЧЕМ они переписали клиента под нейтив? Причем, он переписан под нейтив на кучи мобильных платформ в т.ч. V>>Вот нафига было переписывать со сверхудобного дотнета на страшный и ужасный нейтив? Твои варианты?
G>Потому что они могли это сделать и у них была на это куча бабла.
Детсад.
G>А альтернативы какие?
Добавить потребительских фич. Вложиться в сам сервис.
G>Разогнать команду и положить бабло в карман? Увы на инвестиционные деньги так поступать нельзя.
Детсад.
G>Дали бы мне столько бабла, я бы тоже все переписал на C++, даже за 1% прироста быстродействия.
Не так уж там много бабла было дано. Перепись на С++ была на грани бизнес-рисков. За ради 1% никто бы не возился.
G>Но мне не дают столько, поэтому пишу на .NET и проблем из-за этого не испытываю.
От твоих прог не требуется мгновенно появиться, проглотить заметку и так же мгновенно испариться.
V>>А я видел кучу влетевших нейтивных продуктов в то же самое время, хотя, нейтивные, как ты понимаешь, требуют больше человеко-лет, так? G>Ну приведи хотябы маленький список из этой кучи. Особенно, которые стартанули за последние 5-10 лет.
Скайп, Евернот, Вибер, ОпенОфис (и его клоны), переписанный на фик Гимп, переписанный с 0-ля на новом С++ и бусте КДЕ, переписанный нафик QT, сразу несколько физических и геометрических движков для игр, nosql-базы, самый популярный веб-сервак ngix. Список можно продолжать бесконечно.
V>>Так вот, по опыту серьезной разработки на дотнете и нейтиве одновременно я уже делился с тобой своими собственными наблюдениями еще пару лет назад (или даже больше). На дотнете можно оч быстро накидать "макет". Можно даже заставить его работать при полной функциональности. Затем, при попытке выжать эффективность с этого "макета" мы обнаруживаем, что вложения трудоёмкости оч быстро переплёвывают вложения трудоёмкости в сравнении с нейтивным вариантом. Ну т.е., когда такое же кол-во усилий по вылизыванию тратишь на нейтив, то результат просто несравнимый не в пользу дотнета. Поэтому, дотнет хорош там, где никакую эффективность ни от куда выжимать не надо, а надо чтобы написал — и оно работает и этого было уже достаточно. G>Ты опять про свой мир говоришь. Я никогда проблем с оптимизацией .NET коа до приемлемого уровня быстродействия не испытывал. Я конечно верю, что у тебя с этим проблемы, но .NET в этом не виноват.
Во-во, у тебя исключительно вопрос веры, бо опыта ноль. Дотнет виноват в том, что на нём очень трудоёмко добиться приемлимой производительности. Например, в одном из проектов мы полностью переписали основные коллекции таким образом, что сами объекты-коллекции стали value-type. Сразу всплыла куча ограничений на то, как этими коллекциями пользоваться... Зато быстродействие на ровном месте подскочило почти вдвое.
Да кароч, я пару лет назад приводил простой пример очереди задержки на аналогичной технике, где разница с вариантом на встроенных либах была 2.7 раз не в пользу последней. По моей статистике, простое уменьшение косвенности в 4 раза способно дать общее увеличение производительности в 2 раза. Прикол нейтивной программы в том, что в ней нет такого развесистого графа объектов, как в дотнете, бо 99% объектов размещаются в памяти других объектов как value-type в дотнете. И ты этот феномен не переплюнешь, как не прыгай.
G>>>Очень даже представляю, если понабрать таких грамотных посонов как ты и отправить писать .NET приложение, то его ждет эпик фейл. Постоянные баги и борьба с ветрянными мельницами. А еще потом полученное убожество надо продать.
V>>Ну так в дотнет "планка вхождения" ниже или как? Или дотнет требует сверх-мега спецов, чтобы написать продаваемый коробочный продукт? G>Одно другому не мешает. Ты же сам писал что не везде требуется супер-быстродействие.
Тебе мешает ограниченность. У тебя есть свой мир, своя вера. А если кто даёт тебе "неудобную" информацию, то ты, первым делом, пытаешься подвергнуть сомнению его профессиональный уровень. Это при том, что из обсуждений пары лет назад мне стало видно, что любую работу, которую ты вообще в состоянии выполнить, я сделаю быстрее и качественнее. Как бы ты ни старался, я всё-равно напишу эффективнее и быстрее на твоей же вотчине — дотнете. )) Потому что я хорошо понимаю, как работает низлежащая платформа, а ты — нет. Поэтому, такие как ты могут оптимизировать только оценку сложности сверху, но не снизу и не реальную сложность. Это уже не ваш удел.
V>>Зря ты перешел на личности, кста. По опыту разбора с тобой технических моментов за последние года 4 я бы оценил твоё владение платформой .Net как очень посредственное и очень поверхностное. Ничего более-менее серьезного, чем то, что можно сделать, пользуя лишь готовые библиотеки и инструменты, тебе поручать нельзя. Т.е. ты типичный пользователь технологий, а не их разработчик. G>Ну верь в это, может легче станет.
Ну я как бы могу поискать твои эпичные фейлы. Эпичные в том плане, что нельзя же столько постов подряд подставляться. ))
V>>>>Даже SQL-сервак и IIS. ))) G>>>SQL Server в таком виде как мы его знаем был создан в 2000 году, дальше были только доработки. Но вот что странно, новые фичи SQL часто реализуются через .NETтипы.
V>>Новые фичи самого сервака там реализуются в нейтиве, ес-но. Ты, наверно, хотел сказать, про поддержку хранимок на дотнете? Дык, Оракл это давно делает. Еще один дык от тебя и таких как ты говорит, что хранимки — это зло. Я уже запутался. Не поможешь распутать? G>hierarchyid как ни странно — .NET тип, Geometry и Geography тоже реализованы через .NET обертки. Но это все фигня, ибо главное в быстродействии SQL Server — чтение с диска.
Потрясающее невежество.
Ну и как твои Net-типы устроены, хранятся и обрабатываются, не в курсе? ))
И да... Если бы для SQL-сервака было важно только быстрое чтение с диска, то его бы давно и насовсем вытеснил бы какой-нить MySQL.
G>>>Ибо быстродействие зависит от скорости работы с диском, а не от того нативный там код или нет. V>>Та нифига. В "разогретой" базе индексы и статистика в основном сидят в ОП, а значит, скорость обработки их влияет существенно. Разница в скорости работы разогретой базы и не разогретой на порядки. G>Ты же понимаешь что в любой серьезной задаче с БД рассчитывать на то, что все данные будут в памяти невозможно. Поэтому и пилят запросы, чтобы количество чтений страниц уменьшить.
Поэтому индексы — это лишь проекции данных, а не все данные. Поэтому статистика — это диапазоны данных, а не сами данные. Поэтому, разогретая база работает почти на порядок быстрее холодной, что частоиспользуемые индексы и статистика оседают в ОП. У MS SQL свой механизм маппинга оперативки на файлы, вот этот шедуллер, который решает — какие страницы ОП освобождать, а какие еще оставить — это и есть один из важных моментов итогового быстродействия, эдакое важнейшее ноу-хау. А ты пытаешься выхолащивать всё до "быстрого чтения с диска".
V>>Думаю, что с момента выхода дотнета прошло дохрена времени. Думаю, что существует просто море альтернативных HTML-движков, в т.ч. есть пара и на дотнете. Не взлетели на дотнете, увы. А на нейтиве — взлетели. Даже на этом сайте есть форум, посвящённый одному из них. G>Опять твои фантазии, какие движки на .NET? Ссылок хоть пару приведешь? Не исследовательские проекты, а реальные попытки сделать браузер на .NET?
С чего ты взял, что это исследовательские проекты, а не реальные попытки, которые были заброшены из-за неперспективности.
Ты теперь понял, в чем твои сложности понимания реальности? Читать предыдущий вопрос до просветления.
G>Какой смысл в этом когда есть WebKit?
Ты о других движках не слышал, что ле?
И этот вебкит уже не разрабатывается, что ле? Он пилится быстро и много в данный момент.
К тому же, браузер — это же не числобробилка. Почему бы его не сделать на дотнете, ы? )))
Ведь это было бы так круто и модно, проще развивать и поддерживать новые стандарты HTML, не? Ты же сам утверждаешь, что на сравнимую задачу на дотнете надо в 10 раз меньше человекоресурсов. Прикинь, что если переписать вебкит на дотнете (а это работы на меньше месяца паре опытных разрабов, которые владеют и нейтивом и дотнетом), так вот, если прямо сейчас начать переписывать вебкит на дотнете при сравнимых человекоресурсах, то уже через 3-4 месяца он обгонит по надежности, кол-ву фич и стандартизации исходный вебкит. Но, почему-то, так никто не делает. Твои версии происходящего?
V>>Более того, движок IE был фактически полностью переписан с выходом 8-го IE. Расскажи нам, когда же вышел IE 8. )) G>"Полностью переписан" это маркетинговый буллшит. От силы 30% перписали, остальное скопипастили.
Увы, нет. Бока с CSS потребовали переделать внутренности. И после этого IE резво стал "правильным" и "совместимым". На предыдущей кодовой базе они бодались с этим бесполезно хрен знает сколько лет.
G>Как можно на несколько лет полностью переписать продукт, в который вложено несколько сотен человеко-лет труда и суммарно сотни лет тестирования, в том числе на реальных пользователях.
Потому что на современных либах и соврееменных ср-вах разработки и контроля кода это намного проще. Засада в либах, амиго. На нынешних либах буста и внутренних либах нашей конторы я могу переписать свои старые проекты 10-тилетней давности, ужав исходник в 3-10 раз и повысив надежность в бесконечное кол-во раз.
Я ж тебе грю — фишка дотнета в ОГРОМНОМ кол-ве отлаженного функционала.
G>IE 10 кстати тоже "полностью переписали" судя по маркетинговым заявлениями.
Ты плохо читаешь. Ему изменили только технологию вывода на экран и внешний ГУЙ. О внутренней переработке никто не заикался. Говорили еще что-то о JS-движке, но он общий на винду и браузер.
G>Откуда у МС ресурсы раз в 3 года полностью переписывать браузер?
По-твоему, код пишется со скоростью набора с клавиатуры?
Тогда бы средний программист писал 10-30 тыщ строк кода в день, а не 100-300.
Код пишется со скоростью принятия проектных (и других) решений. Со скоростью набивки тестовой регрессионной базы, со скоростью обрастания артефактами проектирования и сопровождения.
G>Это опять кратина в твоей голове. Самый популярный софт на мобилках — клиенты соцсетей. Все, как ни странно, не на C++ написаны.
Самый популярный из них — официальный клиент ВКонтакте. На 90% нейтивный на андроиде и полностью нейтивный на Симбиан, ИОС, Бада.
G>Яндекс карты, которыми постоянно пользуюсь, тоже не нативные.
О.М.Г.
У меня в браузере они какие, по твоему?
Жжешь не по детски.
G>Мобильный банк — тоже не нативный.
У меня он вообще в браузере, и?
G>Многие игры на Unity, который на .NET.
Это в твоих влажных мечтах он на .Net. Для дотнета там только бинд его библиотек. Утилиты и редактор на дотнете.
Основная фишка — это сервер ресурсов. Нейтивный, ес-но. Сам движок полностью нейтивный. И т.д.
V>>Не отожмут. Философия Аксапты примерно такая же, как у Паруса. Поэтому — не отожмут никогда. Парусы/Аксапты хороши в крупном секторе с большими инвестициями. А для средних и мелких предприятий они пролетают из-за своей бизнес-модели. А эта модель, в свою очередь, целиком и полностью зависит от технологии платформы. Кароч, для программирования под Парус и Аксапту нужны спецы в программировании, в отличие от спецов сугубо в прикладной области, которые могут "настраивать" 1С. Не зря же огромное программистов 1С — девушки. Но их почти нет в разработке под Парус и Аксапту. Поэтому рынок 1С и не отожмут — это другой совсем рынок. G>А ты думаешь МС интересуют внедрения в конторах на 10 человек с одним бухгалтеорм?
Это отмазка.
Дело в том, что в самой Америке бухгалтерия проста как дважды два. Можно прямо в Экселе её вести. А у нас сложна. Поэтому у нас появилась платформа 1C (были и конкурирующие похожие, типа Акцента и т.д.), а в Штатах такой платформы нет и не предвидится. А теперь гоу на оставленное цитирование, где речь была таки о технологических ограничениях, а не об офисах в 10 человек... MS им продаёт же серверную ОСь и офис, не гнушается, так? ))
G>>>Смотрю самсунг — http://hh.ru/search/vacancy?no_magic=true&text=Samsung&clusters=true&search_field=company_name&area=1&specialization=1.221&from=cluster_specialization G>>>Java\Android через одну. Много разработок драйверов, там по понятным причинам managed платформ нету. Да и чето не сильно похоже на "коробочные продукты" сервисы всякие в основном.
V>>hh.ru??? V>>Ты издеваешься? А на сам Самсунг зайти не судьба? G>Кинь ссылку, мне искать лень.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, gandjustas, Вы писали:
V>>>А я говорил, что ты не понимаешь нифига. Visual Studio вышла до выхода WinRT. Более того, она должна работать даже на тех версиях виндов, где WinRT не поддерживается. Более того, запуск студии в 5-15 секунд никого не волнует. Это же утилитное приложение. Вот если бы виндовый калькулятор запускался 5-15 секунд, то никто бы его не использовал. Вот почему в коробочных продуктах фактически нет WPF.
G>>Действительно не понимаю как это связано. Похоже что связь у тебя в голове только существует.
V>Я же сразу сказал — не понимаешь нифига. Не понимаешь, почему студия написана на WPF, а не на WinRT. Не понимаешь, почему виндовый калькулятор на WPF не написан, хотя (я уверен) будет переписан на winRT (или уже полно аналогов с аналогичным временем запуска, как у старого).
Я не понимаю к чему ты это пишешь. Калькулятор в W8 кстати есть в виде app на JS.
G>>>>А если учесть что из WPF родился UI для Windows 8 и Windows Phone, то не понимаю вдвойне. V>>>А я говорил, что ты не понимаешь нифига. Этим UI должен был стать дотнетный "Авалон". Поищи по "Avalon Longhorn". G>>Кому должен? V>Согласно планам MS, где дидлайн был на конец 2006-го.
И че?
G>>Может быть и стал бы, не будь у Синофски зуб на .NET. V>Чего же до него не стал? Лет 6 было в запасе даже после дидлайна.
Синофски, если что, ушел только в 2012, а фарш назад не провернешь.
G>>На WP таки сделали на .NET UI, только через несколько лет таки переписали на COM, чтобы единая платформа была.
V>Нет. Не сделали.
Опять фантазии? Я вот видел WPF\Silverlight UI на WP7-8, а ты куда смотрел в это время?
V>Должна была быть не просто очередная ГУИ-либа для дотнета, а фундаментальная ГУИ среда для виндов, типа как было Win32+GDI. Так вот, WPF так и не стал тем, чем должен был стать. Собсно, наличие сервелатов уже говорило само за себя.
Кому должна? Успокойся, тебе никто ничего не должен.
Отсутствие .NET на клиенте — заслуга синофски. На сервере дофига .NET, как минимум треть серверных фич использует .NET. А уж то, что все серверные продукты на .NET я вообще молчу.
V>>>Так вот. Эпик фейл WPF в том, что он так и не стал Авалоном. Заодно ЗАДЕРЖАЛ выход новых виндов более чем на 5 лет. Windows Vista должна была быть последним фейс-лифтом старых виндов, типа как Windows 98 перед Windows XP. А по-факту Windows Vista задержалась на 8 лет как основная операционка в виде "ребрендинга" Windows 7. И эта задержка могла бы продолжаться вечно, если бы не волевое решение переписать нафик Авалон на нейтиве. G>>Ты веришь в маркетинговый буллшит? Слишком много слов "должен\должна", тебе никто ничего не должен, успокойся. V>Ты утомил своей непроходимостью, реально. Официальный объявленный MS дидлайн операционки на Авалон был конец 2006-го года. Что здесь сложного для понимания?
Еще раз — никто тебе ничего не должен. То что ты поверил в маркетинговый буллшит — твоя проблема на 100%. МС стабильно меняет планы каждые 3 года, так что вполне ожидаемо, что avalon не родился. Так десятки продуктов и технологий не родились. И вовсе не по техническим причинам, а по политическим.
V>>>6 лет задержки из-за того, что дотнет так и не стал обладать необходимыми потребительскими характеристиками. G>>При чем тут .NET? Почему это не помешало сделать UI для WP7 на .NET? V>Потому что WP7 в ж-пе, по факту. WP8 — цаца. Некоторые аппараты можно обновить до 8-й.
Ситуация после появления WP8 не изменилась. Посмотри графики долей рыка и продаж устройств.
V>>>Масштаб этого эпик фейла не поддаётся осмыслению. Собсно, именно с конца 2006-го года начался обратный отсчет уровню доверия дотнету, как универсальной платформе. Прямо на сегодня этот уровень нулевой. Дотнет нифига не универсален, а занял лишь те ниши, в которых неплоха была и Джава. На этом всё. G>>Сильную роль сыграло развитие JS, которое по сути похоронило идею Rich Desktop UI, очень популярную в начале 20 века V>Не вижу никаких похорон.
Потому что ты видишь только фантазии в твоей голове.
МС пытался Rich Desktop UI вытянуть очень долго, только после релиза W7 сдался. Думаешь почему на IE забивали столько времени, а сейчас в попыхах догоняют? Какая стратегия привела к такой ситуации? Догадаешься?
V>ГУИ внутри браузера как было унылым г-ном, так и осталось.
Тем не менее сейчас это самый популярный вариант.
V>А так-то десктопный ГУИ на скриптах отродясь писался что в Линухах, что под виндой на VBS, твоя JS — просто одна из популярных технологий. Ты не туда смотришь, кароч. Автоматизация на скриптах делается над каким-то низлежащим движком. Так вот, дотнетный движок им не стал, winRT — полностью нейтивная платформа.
Это разговор ни о чем. В любом случае где-то выполняется нативный код. Но это абсолютно нерелевантно тому, на чем люди пишут. Ты наверное удивишься, но большинство WinRT приложений это JS и .NET.
V>>>В 2005-2006 годах я занимался этим вопросом много и видел много таких проектов. На сегодня они не актуальны, ес-но, т.к. вопрос можно считать закрытым. Можешь поискать еще кодеки, например по speex dotnet. Я сходу нашел NAudio, например. Но более детальное знакомство показало, что для того же speex используется нейтивный кодек, хотя в проекте NSpeex были планы по релизу "родного" дотнетного кодека. Собсно, перевести открытый исходник на дотнет — это 2-3 дня работы разработчику средней руки. Я видел в те времена несколько "родных" дотнетных реализаций кодеков. Один из кодеков на дотнете как-то публиковал здесь я, для G.711. Портирование его из нейтива заняло меньше часа. Пользовали это в своих проектах. Характеристики производительности ни к черту. Поэтому, дотнет остался только для макетирования всех этих вещей, для боевого применения более половины движка переписали на нейтив, оставив дотнету только сигналинг. G>>Я понял, про астериск были фантазии. V>Нифиг ты не понял опять. Все эти эпик-фейлы ушли с горизонта уже к 2008-му окончательно. Но я тебе дал вполне конкретные имена проектов. Но эти проекты можно использовать лишь для макетирования, а не для боевого применения.
Ну так приведи ссылки. На слово тебе верить что ли?
G>>Про кодеки — не ясно зачем их на .NET писать вообще, там же числомолотилка, .NET ничего не даст. V>1. Почему числомолотилка на дотнете хуже нейтивной? А как же JIT?
Тут есть проблема: у JIT довольно мало времени заниматься оптимизацией, а сделать оптимизацию на уровне IL сложно, ибо IL должен быть верифицируемым.
Чтобы добиться максимального быстродействия нужен умный AOT-компилятор, который работает с учетом профилирования. МС сейчас делает такой, .NET Native называется. Вангую что через 3-5 лет он заменит\дополнит стандартный ngen.
V>2. А где вообще дотнет что-то даст, окромя неспешного разбора ответа базы или формирования неспешного WEB-ответа?
Фактически везде. Потому что писать быстрее, готовых либ больше и средства разработки удобнее.
А на сервере так вообще .NET рвет C++, потому что:
1) Есть эффективная и удобная асинхронность.
2) Есть Linq. который позволяет генерировать хорошие запросы к базе.
3) Готовые библиотеки с реализацией кеширования, которое необходимо для разработки приложения.
4) Склейка строк для генерации HTML делается на .NET быстрее, чем на C++.
V>>>Если сможешь заставить работать быстрее — велкам. )) При том, что этот кодек до невозможности примитивен, в сравнении с тем же speex. G>>Пот посмотрел на код, его чуть ли не 1-в-1 можно на C заменить (даже не C++), только массивы надо извне передавать. А для .NET можно написать обертку, которая зовет эту либу.
V>Еще раз повторю вопрос №1. V>Вычисления по ссылке целочисленные, заметь. То бишь, даже пресловутое неумение дотнета пользовать SSEx оставим за кадром. Там банальные табличные вычисления. Дотнет сливает раза в 3 нейтиву даже на этом примитиве.
И что? Никто не спорит, что чилополотилка на C будет быстрее, чем на .NET. Но числомолотилки в реальных приложениях встречаются крайне редко.
V>>>Paint.Net не требует быстродействия. Вообще. Я разработал графический редактор для конференций на дотнете в 2006-м, где участники конференций могут рисовать на одной доске совместно. Никакой скорости не требуется. Вообще. Потому что основные тормоза от самой сетки. Потому что события даже от самых крутых мышек поступали не чаще 100 раз в секунду. Более того, мой редактор векторный, участники конференций могут изменять объекты, нарисованные другими участниками. Это намного сложнее растровой графики. G>>Большинство десктопных приложений не требует быстродействия, вообще.
V>Фотошоп или CorelDraw требует еще как. Про AutoCAD я вообще молчу. Не говори таких глупостей никогда — засмеют.
Для автокада успешно пишут плагины на .NET, да и сам он WPF использует (по крайней мере в 2009).
В фотошопе скорость нужна только в фильтрах (числомолотилках). Во всем остальном — нет. Paint.NET нормально работает, для большинства пользователей отлично заменяет фотошоп.
Кстати никто не мешает сделать на C либу фильтра, завернуть в .NET и использовать с тем же успехом в Paint.net.
G>>Ни мессенджеры, ни заметки, ни какая-либо еще фигня.
V>Мессенджер должен запускаться мгновенно, так же как заметки и прочая фигня. Яховский мессенджер сдох именно по причине долгого (до 20 сек) запуска. OneNote тоже нейтивный и тоже быстро запускается. Кароч, я не понимаю, как ты не понимаешь очевидных аргументов.
У меня почему-то Paint.NET запускается быстрее OneNote. Да и вообще приложения как-то не торопясь стуртуют, пара секунд — вполне.
Кстати скорость запуска != скорость работы. Сделай NGen сборкам и приложение начнет также "мгновенно" запускаться.
G>>Быстродействия на десктопе требуют игры V>ВСЁ требует быстродействия. Браузер, калькулятор, мессенджер, фото-редактор.
Успокойся, у тебя снова фантазия воспаляется. Были исследования по скорости запуска, человек спокойно ждет пару секунд.
G>>в которых кстати игровая логика пишется на скриптовых языках V>ы-ы-ы
Совсем заклинило? Lua, Python и даже C# (Unity) не слышал?
G>>которые по твоему гораздо менее надежны и быстры V>А где надежность сидит, по-твоему?
Уж точно не в C++
V>В типичной современной навороченной игре используется нейтивный движок на порядка 3-5 млн строк исходников, порядка 30-50 тыщ строк исходников тех самых "скриптов для логики" и гигабайты медиа.
Только движок не пишется на каждую игру, а логика пишется. У меня есть подозрение что для игр на сегодня пишется гораздо больше кода на скриптовых языках, чем на C++.
А если учеть Unity, то на C++ пишется очень маленькая часть.
И, кстати, по твоей логике нет смылса вообще использовать скриптовые движки, ибо C++ надежнее, а по факту оказывается наоборот.
V>>>В плане требований к производительности сравни с теми же нейтивными фильтрами для фотошлёпа, где даже на современных рабочих станциях хочется добавить мощщи. На дотнете это просто не влетит. От слова вообще. Се ля ви. G>>Хм... почему фотошопу требуется быстродействие, а paint.nt — нет?
V>Хороший вопрос. Предлагаю освоить оба продукта самостоятельно. "Ты же программист!" ))
Кроме фильтров не вижу где вообще может потребоваться быстродейстие. Отзывчивость интерфейса гораздо важнее. А это для C++ гораздо большая проблема, чем для .NET.
G>>Разница только в тормозных фильтрах? Которые кстати тоже числомолотилки.
V>Даже без фильтров, при десятке слоёв с наложением для современной 16мбпкс фоты с камеры твой дотнетный паинт сразу мертв. А фотошлёп живее всех живых.
Открыл Paint.NET, сделал 12 слоев с прозрачностью с 10мп фотками, полет нормальный. Не тормозит.
И как-бы логично, рисуется только один раз, разницы нет будет это 10мс или 100мс.
Так что снова твои воспаленные фантазии, крайне далекие от реальной жизни.
G>>>>EverNote написали на .NET, получили инвестиции, пошли переписывать на C++. С таким баблом можно было и на ассемблере написать. А бекенд то на .NET и остался. Если бы начали на C++, то не то что инвестиций, даже релиза не было бы.
V>>>Не юли. ЗАЧЕМ они переписали клиента под нейтив? Причем, он переписан под нейтив на кучи мобильных платформ в т.ч. V>>>Вот нафига было переписывать со сверхудобного дотнета на страшный и ужасный нейтив? Твои варианты?
Еще раз — надо было куда-то потратить бабло. Переписать на C++ — хороший способ. Будь у меня избыток бабла я тоже буду все на C++ переписывать.
G>>Потому что они могли это сделать и у них была на это куча бабла. V>Детсад.
Правда жизни. Ты слишком далек от бизнеса чтобы понимать это.
G>>А альтернативы какие? V>Добавить потребительских фич. Вложиться в сам сервис.
Каких фич? Думаешь это так просто, взять и добавить фичу?
Это вообще хороший способ убить продукт — вкладываться в тонну новых фич, когда получил инвестиции.
G>>Разогнать команду и положить бабло в карман? Увы на инвестиционные деньги так поступать нельзя. V>Детсад.
Правда жизни. Ты слишком далек от бизнеса чтобы понимать это.
G>>Дали бы мне столько бабла, я бы тоже все переписал на C++, даже за 1% прироста быстродействия. V>Не так уж там много бабла было дано. Перепись на С++ была на грани бизнес-рисков. За ради 1% никто бы не возился.
Бабло куда-то пустить надо. Новые фичи это сложно, ибо надо не перегрузить продукт. А переписать — прекрасная идея чтобы бабло потратить и выйграть время подумать над продуктом. На самом деле можно удачно релизить пару мажорных версий, изменяя шрифты и добавляя 1% быстродействия. Еще и бабла за апгрейд брать.
G>>Но мне не дают столько, поэтому пишу на .NET и проблем из-за этого не испытываю. V>От твоих прог не требуется мгновенно появиться, проглотить заметку и так же мгновенно испариться.
Угу, от моих прог требуется обрабатывать терабайты данных и выдавать ответ менее чем за секунду.
Это конечно крайне далеко от того, чтобы "мгновенно испариться".
А кто мешает приложение в фоне держать и показывать окно по нажатию кнопки? При чем тут скорость запуска и скорость работы вообще? Разве реально требуется запускать и останавливать приложение?
V>>>А я видел кучу влетевших нейтивных продуктов в то же самое время, хотя, нейтивные, как ты понимаешь, требуют больше человеко-лет, так? G>>Ну приведи хотябы маленький список из этой кучи. Особенно, которые стартанули за последние 5-10 лет.
V>Скайп, Евернот, Вибер, ОпенОфис (и его клоны), переписанный на фик Гимп, переписанный с 0-ля на новом С++ и бусте КДЕ, переписанный нафик QT, сразу несколько физических и геометрических движков для игр, nosql-базы, самый популярный веб-сервак ngix. Список можно продолжать бесконечно.
Скайп старше 10 лет, а текущая версия вообще на JS.
Эвернот был написан на .NET
опенофис — говно, лучше бы его не упоминал
гимп рядом не валялся с Paint.NET
Самая крутая NoSQL база написана на .NET
V>>>Так вот, по опыту серьезной разработки на дотнете и нейтиве одновременно я уже делился с тобой своими собственными наблюдениями еще пару лет назад (или даже больше). На дотнете можно оч быстро накидать "макет". Можно даже заставить его работать при полной функциональности. Затем, при попытке выжать эффективность с этого "макета" мы обнаруживаем, что вложения трудоёмкости оч быстро переплёвывают вложения трудоёмкости в сравнении с нейтивным вариантом. Ну т.е., когда такое же кол-во усилий по вылизыванию тратишь на нейтив, то результат просто несравнимый не в пользу дотнета. Поэтому, дотнет хорош там, где никакую эффективность ни от куда выжимать не надо, а надо чтобы написал — и оно работает и этого было уже достаточно. G>>Ты опять про свой мир говоришь. Я никогда проблем с оптимизацией .NET коа до приемлемого уровня быстродействия не испытывал. Я конечно верю, что у тебя с этим проблемы, но .NET в этом не виноват.
V>Во-во, у тебя исключительно вопрос веры, бо опыта ноль. Дотнет виноват в том, что на нём очень трудоёмко добиться приемлимой производительности.
Это тебе трудно, я всегда добивался, при чем довольно быстро. Конечно у меня и в мыслях не было кодеки писать на .NET.
Так что это у тебя опыта написания и оптимизации на .NET нету. Но не переживай, готов тебя научить за небольшое вознаграждение.
V>Например, в одном из проектов мы полностью переписали основные коллекции таким образом, что сами объекты-коллекции стали value-type. Сразу всплыла куча ограничений на то, как этими коллекциями пользоваться... Зато быстродействие на ровном месте подскочило почти вдвое.
Пример кода и тестов в студию. На слово тебе чтоли верить?
V>Да кароч, я пару лет назад приводил простой пример очереди задержки на аналогичной технике, где разница с вариантом на встроенных либах была 2.7 раз не в пользу последней. По моей статистике, простое уменьшение косвенности в 4 раза способно дать общее увеличение производительности в 2 раза. Прикол нейтивной программы в том, что в ней нет такого развесистого графа объектов, как в дотнете, бо 99% объектов размещаются в памяти других объектов как value-type в дотнете. И ты этот феномен не переплюнешь, как не прыгай.
Давай код, я тебе не верю. У меня слишком много оснований для этого.
G>>>>Очень даже представляю, если понабрать таких грамотных посонов как ты и отправить писать .NET приложение, то его ждет эпик фейл. Постоянные баги и борьба с ветрянными мельницами. А еще потом полученное убожество надо продать. V>>>Ну так в дотнет "планка вхождения" ниже или как? Или дотнет требует сверх-мега спецов, чтобы написать продаваемый коробочный продукт? G>>Одно другому не мешает. Ты же сам писал что не везде требуется супер-быстродействие.
V>Тебе мешает ограниченность. У тебя есть свой мир, своя вера. А если кто даёт тебе "неудобную" информацию, то ты, первым делом, пытаешься подвергнуть сомнению его профессиональный уровень.
Ты от зеркала отойди
V>Это при том, что из обсуждений пары лет назад мне стало видно, что любую работу, которую ты вообще в состоянии выполнить, я сделаю быстрее и качественнее. Как бы ты ни старался, я всё-равно напишу эффективнее и быстрее на твоей же вотчине — дотнете. )) Потому что я хорошо понимаю, как работает низлежащая платформа, а ты — нет. Поэтому, такие как ты могут оптимизировать только оценку сложности сверху, но не снизу и не реальную сложность. Это уже не ваш удел.
Успокой уже свою воспаленную фантазию. Ты уже столько раз откровенно врал, что вообе нет никаких оснований верить, что ты хоть что-либо писал.
Более того я помню эпик фейл, когда ты рассказывал как WPF работает и почему он тормозит, а профайлер показал что тормозит тупо загрузка стандартных ресурсов.
Да и про SqlClient ты уже показал свои "знания", про APС, хотя ни одного APC вызова в .NET и не существет.
Но ты продолжай, к успеху идешь.
V>>>Зря ты перешел на личности, кста. По опыту разбора с тобой технических моментов за последние года 4 я бы оценил твоё владение платформой .Net как очень посредственное и очень поверхностное. Ничего более-менее серьезного, чем то, что можно сделать, пользуя лишь готовые библиотеки и инструменты, тебе поручать нельзя. Т.е. ты типичный пользователь технологий, а не их разработчик. G>>Ну верь в это, может легче станет. V>Ну я как бы могу поискать твои эпичные фейлы. Эпичные в том плане, что нельзя же столько постов подряд подставляться. ))
Ты о чем? Помоему ты уже не первый пост просто врешь. Ты еще ни одного доказательства своим словам не привел. Зато насвистел уже столько, что уровень доверия к твоим словам не просто нулевой, а отрицательный.
V>>>>>Даже SQL-сервак и IIS. ))) G>>>>SQL Server в таком виде как мы его знаем был создан в 2000 году, дальше были только доработки. Но вот что странно, новые фичи SQL часто реализуются через .NETтипы.
V>>>Новые фичи самого сервака там реализуются в нейтиве, ес-но. Ты, наверно, хотел сказать, про поддержку хранимок на дотнете? Дык, Оракл это давно делает. Еще один дык от тебя и таких как ты говорит, что хранимки — это зло. Я уже запутался. Не поможешь распутать? G>>hierarchyid как ни странно — .NET тип, Geometry и Geography тоже реализованы через .NET обертки. Но это все фигня, ибо главное в быстродействии SQL Server — чтение с диска. V>Потрясающее невежество.
Да, чувак, ты прав, ты настолько не понимаешь как делается разработка, что даже не знаю что тебе еще сказать.
V>Ну и как твои Net-типы устроены, хранятся и обрабатываются, не в курсе? ))
В курсе. Хранятся на диске в виде массива байт, для обработки десериализуется в .NET объект и с ним выполняется обычный .NET код.
V>И да... Если бы для SQL-сервака было важно только быстрое чтение с диска, то его бы давно и насовсем вытеснил бы какой-нить MySQL.
Шутка дня, спасибо, записал.
обогнать SQL Serer по прямому чтению с диска не может ни один движок. Потому что в SQL Server вложено столько знаний об особенностях Windows, что ни одному MySQL не под силу.
Кроме этого SQL еще очень хорошо умеет оптимизировать чтение, за счет индексов, статистики итп. При чем для этой оптимизации тратится доифга ресурсов на стадии записи.
G>>>>Ибо быстродействие зависит от скорости работы с диском, а не от того нативный там код или нет. V>>>Та нифига. В "разогретой" базе индексы и статистика в основном сидят в ОП, а значит, скорость обработки их влияет существенно. Разница в скорости работы разогретой базы и не разогретой на порядки. G>>Ты же понимаешь что в любой серьезной задаче с БД рассчитывать на то, что все данные будут в памяти невозможно. Поэтому и пилят запросы, чтобы количество чтений страниц уменьшить.
V>Поэтому индексы — это лишь проекции данных, а не все данные.
Что означает эта фраза? Чем проекции отличаются от "самих данных" ? Проекция колонки типа int это что?
V>Поэтому статистика — это диапазоны данных, а не сами данные.
А эта фраза что означает?
V>Поэтому, разогретая база работает почти на порядок быстрее холодной, что частоиспользуемые индексы и статистика оседают в ОП.
Статистика используется только при построении планов. Никакого "оседания" в оп нет. Там нечто вроде LRU для buffer pool используется.
V>У MS SQL свой механизм маппинга оперативки на файлы, вот этот шедуллер, который решает — какие страницы ОП освобождать, а какие еще оставить — это и есть один из важных моментов итогового быстродействия, эдакое важнейшее ноу-хау. А ты пытаешься выхолащивать всё до "быстрого чтения с диска".
Это "ноу-хау" это LRU кеш, а "свой механизм маппинга оперативки на файлы" — обычное небуфиризированное чтение. Магии никакой нет, но есть куча тонкостей, что без ковыряния довольно сложно сходу такое повторить.
Но это далеко не самое главное. Самое главное в находится в оптимизаторе запросов, который определяет какие страницы читать, а какие нет. Вот там действительно дофига науки.
Короче как обычно ты не там ишещь потенциал оптимизации. На низком уровне довольно простые вещи используются причем их и на .NET можно написать с тем же успехом (см RavenDB).
V>>>Думаю, что с момента выхода дотнета прошло дохрена времени. Думаю, что существует просто море альтернативных HTML-движков, в т.ч. есть пара и на дотнете. Не взлетели на дотнете, увы. А на нейтиве — взлетели. Даже на этом сайте есть форум, посвящённый одному из них. G>>Опять твои фантазии, какие движки на .NET? Ссылок хоть пару приведешь? Не исследовательские проекты, а реальные попытки сделать браузер на .NET?
V>С чего ты взял, что это исследовательские проекты, а не реальные попытки, которые были заброшены из-за неперспективности.
Как минимум с того что про это говоришь ты Поводов верить тебе никаких, а не верть — хоть отбавляй.
V>Ты теперь понял, в чем твои сложности понимания реальности? Читать предыдущий вопрос до просветления.
Да, в том что моя реальность билже к объективной, чем твоя. Но это я давно понял.
G>>Какой смысл в этом когда есть WebKit? V>Ты о других движках не слышал, что ле? V>И этот вебкит уже не разрабатывается, что ле? Он пилится быстро и много в данный момент.
И какой смысл пилить другой? Если бы был хоть один экономический фактор, из-за которого имеет смысл свой движок делать, то уже бы кто-нибудь это делал. А без такого стимула будут только исследовательские проекты.
V>К тому же, браузер — это же не числобробилка. Почему бы его не сделать на дотнете, ы? )))
Потому что браузеры не пишутся с нуля.
V>Ведь это было бы так круто и модно, проще развивать и поддерживать новые стандарты HTML, не? Ты же сам утверждаешь, что на сравнимую задачу на дотнете надо в 10 раз меньше человекоресурсов. Прикинь, что если переписать вебкит на дотнете (а это работы на меньше месяца паре опытных разрабов, которые владеют и нейтивом и дотнетом), так вот, если прямо сейчас начать переписывать вебкит на дотнете при сравнимых человекоресурсах, то уже через 3-4 месяца он обгонит по надежности, кол-ву фич и стандартизации исходный вебкит. Но, почему-то, так никто не делает. Твои версии происходящего?
Давай посчитаем.
Вебкит начали разрабатывать в 2000 году. Не знаю сколько человек его пилило, но по статистике таких проектов это около 50 человек должно быть. То есть в него вложено порядка 700 человеко-лет. Предположим, что .NET реально увеличит скорость разработки в 10 раз. То есть 70 человеко-лет. И это только движок. Если его на .NET переписать, то надо будет и всю обвязку вокруг него сделать на .NET. Это еще примерно столько же. Грубо говоря полноценный браузер на .NET это в лучшем случае 150 человеко-лет. Стоимость программиста такого уровня будет порядка $100,000 год. Итого $15 лямов баксов. Это только программисты. А еще тестеры, манагеры итп. Короче суммарно выйдет не мене $50М и пара-тройка лет. А какой выхлоп будет? В деньгах. Чето мне кажется никакого.
Если ты думаешь что в таких проектах есть хоть какие-то технические причины не писать на .NET, то ты сльно заблуждаешься. Достаточно посчитать бабло и понять что причины чисто экономические.
V>>>Более того, движок IE был фактически полностью переписан с выходом 8-го IE. Расскажи нам, когда же вышел IE 8. )) G>>"Полностью переписан" это маркетинговый буллшит. От силы 30% перписали, остальное скопипастили.
V>Увы, нет. Бока с CSS потребовали переделать внутренности. И после этого IE резво стал "правильным" и "совместимым". На предыдущей кодовой базе они бодались с этим бесполезно хрен знает сколько лет.
Походу ты реально поверил. А в реальности "полное переписывание" — от силы 30% кодовой базы затрагивает. Во времена офиса 2007 говорил о "полном переписывании", а выяснилось что переписали совсем не много, увы ссылку не найду.
G>>Как можно на несколько лет полностью переписать продукт, в который вложено несколько сотен человеко-лет труда и суммарно сотни лет тестирования, в том числе на реальных пользователях. V>Потому что на современных либах и соврееменных ср-вах разработки и контроля кода это намного проще. Засада в либах, амиго. На нынешних либах буста и внутренних либах нашей конторы я могу переписать свои старые проекты 10-тилетней давности, ужав исходник в 3-10 раз и повысив надежность в бесконечное кол-во раз.
Да-да, видел я таких бравых парней. А после переписывания появляется 100500 новых багов и правка их приводит к тому, что от сил в 2 раза меньше трудозатрат уходит на переписываение, и то потому что уже знаешь как оно должно работать. Вообще ни один крупный продукт никогда 100% не переписывался. Один раз попытались это сделать в Netscape и это убило и браузер, и компанию. И любой руководитель большой разработки прекрасно это знает и никогда не допустит такого развития событий.
V>Я ж тебе грю — фишка дотнета в ОГРОМНОМ кол-ве отлаженного функционала.
А почему нет этого огромного количества в C++? Чем он хуже?
G>>IE 10 кстати тоже "полностью переписали" судя по маркетинговым заявлениями. V>Ты плохо читаешь. Ему изменили только технологию вывода на экран и внешний ГУЙ. О внутренней переработке никто не заикался. Говорили еще что-то о JS-движке, но он общий на винду и браузер.
Я как раз хорошо читаю и не верю в буллшит о "переписывании". JS движок тоже неслабая часть браузера в современных браузерах.
G>>Откуда у МС ресурсы раз в 3 года полностью переписывать браузер? V>По-твоему, код пишется со скоростью набора с клавиатуры? V>Тогда бы средний программист писал 10-30 тыщ строк кода в день, а не 100-300.
Это ты о чем?
V>Код пишется со скоростью принятия проектных (и других) решений. Со скоростью набивки тестовой регрессионной базы, со скоростью обрастания артефактами проектирования и сопровождения.
Если надо переписать готовое приложение, то к чему это ты написал?
G>>Это опять кратина в твоей голове. Самый популярный софт на мобилках — клиенты соцсетей. Все, как ни странно, не на C++ написаны. V>Самый популярный из них — официальный клиент ВКонтакте. На 90% нейтивный на андроиде и полностью нейтивный на Симбиан, ИОС, Бада.
Доказательства? На слово тебе верить чтоли?
G>>Яндекс карты, которыми постоянно пользуюсь, тоже не нативные.
V>О.М.Г. V>У меня в браузере они какие, по твоему?
У тебя в браузере они на JS.
А у меня на планшете и на телефоне на .NET.
А на iOS они на ObjC написаны.
G>>Мобильный банк — тоже не нативный. V>У меня он вообще в браузере, и?
И он не нативный
G>>Многие игры на Unity, который на .NET.
V>Это в твоих влажных мечтах он на .Net. Для дотнета там только бинд его библиотек. Утилиты и редактор на дотнете. V>Основная фишка — это сервер ресурсов. Нейтивный, ес-но. Сам движок полностью нейтивный. И т.д.
Да какая разница, не важно на начем движок, важно на чем пишет программист.
Почему не существует такого Unity для C++?
V>>>Не отожмут. Философия Аксапты примерно такая же, как у Паруса. Поэтому — не отожмут никогда. Парусы/Аксапты хороши в крупном секторе с большими инвестициями. А для средних и мелких предприятий они пролетают из-за своей бизнес-модели. А эта модель, в свою очередь, целиком и полностью зависит от технологии платформы. Кароч, для программирования под Парус и Аксапту нужны спецы в программировании, в отличие от спецов сугубо в прикладной области, которые могут "настраивать" 1С. Не зря же огромное программистов 1С — девушки. Но их почти нет в разработке под Парус и Аксапту. Поэтому рынок 1С и не отожмут — это другой совсем рынок. G>>А ты думаешь МС интересуют внедрения в конторах на 10 человек с одним бухгалтеорм?
V>Это отмазка.
Это правда жизни.
V>Дело в том, что в самой Америке бухгалтерия проста как дважды два. Можно прямо в Экселе её вести. А у нас сложна. Поэтому у нас появилась платформа 1C (были и конкурирующие похожие, типа Акцента и т.д.), а в Штатах такой платформы нет и не предвидится. А теперь гоу на оставленное цитирование, где речь была таки о технологических ограничениях, а не об офисах в 10 человек... MS им продаёт же серверную ОСь и офис, не гнушается, так? ))
Ты не в курсе что банки должны отчитываться по МСФО, что успешно умеет AX. Но есть свои особенности налогооблажения, для которых собственно и пилят.
G>>>>Смотрю самсунг — http://hh.ru/search/vacancy?no_magic=true&text=Samsung&clusters=true&search_field=company_name&area=1&specialization=1.221&from=cluster_specialization G>>>>Java\Android через одну. Много разработок драйверов, там по понятным причинам managed платформ нету. Да и чето не сильно похоже на "коробочные продукты" сервисы всякие в основном.
V>>>hh.ru??? V>>>Ты издеваешься? А на сам Самсунг зайти не судьба? G>>Кинь ссылку, мне искать лень.
V>Просто потрать квант своей внимательности на эти ссылки. Не по диагонали. Не отмахиваясь, как от назойливой мухи.
И? Где реальные вакансии? Чтобы можно было откликнуться.
V>Ты еще относительно молод. У тебя всё еще может сложится по-другому.
За меня не переживай. Я за работу беру по $100\час, при этом работаю когда мне захочется.
Здравствуйте, QrystaL, Вы писали:
QL>Здравствуйте, Dair, Вы писали: D>>в Django/RoR накладываются довольно жёсткие ограничения даже на именование таблиц в БД
QL>Ну это проблемы реализации Django/RoR В .NET с этим всё порядке.
Ну, хорошо. Как написать вот такой запрос на ОРМ.NET?
Это реальный запрос и, наверно, самый сложный, который я реально применяю.
select count(e.id), l.id, l.name from location l left outer join event e on (e.cr_date >= now() - '#{sanitize(period)}h'::interval and e.location_id = l.id) group by l.id order by l.id asc
Фрагмент "e.cr_date >= now() — '#{sanitize(period)}h'::interval" означает "за последние period часов".
Здравствуйте, Dair, Вы писали:
D>Здравствуйте, QrystaL, Вы писали: D>Ну, хорошо. Как написать вот такой запрос на ОРМ.NET?
Что такое ОРМ.NET? Любой ORM под дотнет?
D>Это реальный запрос и, наверно, самый сложный, который я реально применяю.
D>
select count(e.id), l.id, l.name from location l left outer join event e on (e.cr_date >= now() - '#{sanitize(period)}h'::interval and e.location_id = l.id) group by l.id order by l.id asc
D>Фрагмент "e.cr_date >= now() — '#{sanitize(period)}h'::interval" означает "за последние period часов".
Оно точно рабочее? Потому что известные мне сервера скажут, что l.name отсутствует в group by.
D>>Ну, хорошо. Как написать вот такой запрос на ОРМ.NET? НС>Что такое ОРМ.NET? Любой ORM под дотнет?
Я ни одним не владею, поэтому да, любой. Мне для примера понять, как оно будет выглядеть.
D>>Это реальный запрос и, наверно, самый сложный, который я реально применяю. D>>
select count(e.id), l.id, l.name from location l left outer join event e on (e.cr_date >= now() - '#{sanitize(period)}h'::interval and e.location_id = l.id) group by l.id order by l.id asc
D>>Фрагмент "e.cr_date >= now() — '#{sanitize(period)}h'::interval" означает "за последние period часов".
НС>Оно точно рабочее? Потому что известные мне сервера скажут, что l.name отсутствует в group by.
у меня на PostgreSQL 9.1 вполне работает, это copy&paste из рабочего проекта.
Таблица event содержит события, таблица location — места этих событий, связка event->location "много к одному". Запрос возвращает кол-во событий по локациям за указанное кол-во часов он настоящего времени. Для тех локаций, в которых событий не было — 0, для этого, собсно, outer join.
Здравствуйте, Dair, Вы писали:
D>Я ни одним не владею, поэтому да, любой. Мне для примера понять, как оно будет выглядеть.
Да примерно так же и будет:
from loc in db.Locations
from evt in loc.Events
where evt.CrDate > DateTime.Now - TimeSpan.FromHours(period)
order by loc.Id
group loc by new {loc.Id, loc.Name} into g
select new {g.Key.Id, g.Key.Name, g.Count()};
НС>>Оно точно рабочее? Потому что известные мне сервера скажут, что l.name отсутствует в group by.
D> у меня на PostgreSQL 9.1 вполне работает, это copy&paste из рабочего проекта.
И что в name попадает? Первое попавшееся значение из группы?
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>>>Оно точно рабочее? Потому что известные мне сервера скажут, что l.name отсутствует в group by.
D>> у меня на PostgreSQL 9.1 вполне работает, это copy&paste из рабочего проекта.
НС>И что в name попадает? Первое попавшееся значение из группы?
Так как задана группировка по первичному ключу location, то группировка i.id даст тот же результат, что и (l.id, l.name).
Здравствуйте, A-Myth, Вы писали:
AM>К чему этот вопрос: мне сейчас надо накидать прототип, который возможно перерастёт в большой проект (а возможно и нет). Нужен ORM. Хотелось бы, конечно, плюшек в виде lazy loading и change tracking (т.к. неизвестно куда потом требования угуляют), но и без них можно обойтись. AM>Так же важен момент быстрого вхождения средних (не совсем бестолковых, но и не "10x") разработчиков. AM>Хотелось бы надёжную штуковину, которая бы 3-4 года ещё была актуальна и "в струе" дотнета. AM>База планируется средней нагруженности — будут блобы, файлы-документы, сотни пользователей, планировщики и т.д. AM>Что бы мне такое выбрать, чтобы не очень промахнуться?
Не очень понимаю где будет проблема. Если код ORM полностью скрыт от остальной программы за слоем репозиториев (тут важное уточнение: многие под репозиториями понимают почему-то шлюзы к таблицам), то сменить его будет просто или вообще использовать SQL и ADO.NET.
На практике, увы, люди таскают классы-маппинги ORM (хоть POCO, хоть нет) по всей системе, пытаются вывернуть ORM наизнанку, заставляя внешний код вникать в детали того, как эта конкретная ORM работает. Сам так делал пока не вырос. В результате, их код очень цепко связан с конкретной ORM.
Здравствуйте, Vladek, Вы писали:
V>Сам так делал пока не вырос. В результате, их код очень цепко связан с конкретной ORM.
Сейчас, в принципе, ни одна ORM не доросла до уровня, который позволит абстрагироваться от ее специфики. Так что попытка такую абстракцию ввести — классический случай leaky abstraction со всеми вытекающими.
Здравствуйте, Vladek, Вы писали:
V>Здравствуйте, A-Myth, Вы писали:
AM>>К чему этот вопрос: мне сейчас надо накидать прототип, который возможно перерастёт в большой проект (а возможно и нет). Нужен ORM. Хотелось бы, конечно, плюшек в виде lazy loading и change tracking (т.к. неизвестно куда потом требования угуляют), но и без них можно обойтись. AM>>Так же важен момент быстрого вхождения средних (не совсем бестолковых, но и не "10x") разработчиков. AM>>Хотелось бы надёжную штуковину, которая бы 3-4 года ещё была актуальна и "в струе" дотнета. AM>>База планируется средней нагруженности — будут блобы, файлы-документы, сотни пользователей, планировщики и т.д. AM>>Что бы мне такое выбрать, чтобы не очень промахнуться?
V>Не очень понимаю где будет проблема. Если код ORM полностью скрыт от остальной программы за слоем репозиториев (тут важное уточнение: многие под репозиториями понимают почему-то шлюзы к таблицам), то сменить его будет просто или вообще использовать SQL и ADO.NET.
V>На практике, увы, люди таскают классы-маппинги ORM (хоть POCO, хоть нет) по всей системе, пытаются вывернуть ORM наизнанку, заставляя внешний код вникать в детали того, как эта конкретная ORM работает. Сам так делал пока не вырос. В результате, их код очень цепко связан с конкретной ORM.
Приведи пример такого кода.
Для начала простой кейс как в StackOverflow:
1) Показывать посты по дате добавления
2) Показывать посты по количеству оценок за день (самые популярные)
3) Показывать посты по комментов за день (самые обсуждаемые)
Еще обязательно пейджинг.
Я предполагаю что получится такой набор методов в репозитариях:
IEnumerable<PostData> GetPostsByDate(int start, int pageSize);
IEnumerable<PostData> GetPostsByComments(int start, int pageSize);
IEnumerable<PostData> GetPostsByScore(int start, int pageSize);
Потом внезапно требуется сделать фильтр по тегам, придется править все три метода. В итоге у нас "нижние" слои приложения страдают от изменений деталей представления. Значит расслоение сделано неверно.
В сценарии интернет-магазина или CRM может быть куча фильтров и сортировок и таких методов в репозитарии будет очень много. Поэтому цена изменения станет огромной.
Мы уже победили, просто это еще не так заметно...
у меня на PostgreSQL 9.1 вполне работает, это copy&paste из рабочего проекта.
