>С какой частотой у вас «релизы»?
Зависит от проекта и продукта, как правило от 4 месяцев до года, иногда больше.
>А как определить, кроссплатформенно ли вы пишете?
Есть некоторые стандарты и правила. Если коротко, суть их в том, что на С++ вы должны использовать только библиотеки включенные в стандарт С++ и кросплатформенные библиотеки, а всякие API операционной системы не использовать.
Тестировать приложение надо перед релизом.
И да — конечно надо, на каждой платформе, если релиз на несколько платформ.
Однако это не значит что во время разработки вы должны каждое изменение проверять на всех платформах. Если писать более менее кросплатформенно, то этапа тестирования перед релизом должно бы хватить.
>как раз не в UI .net ведет себя лучше (а теперь — еще лучше) на других платформах.
Как же без UI на десктопе?
>Вы не понимаете. Я не выбрал IOCP, я выбрал асинхронный I/O.
То есть вы в целом были готовы к тому что работа асинхронного I/O может отличаться на разных платформах.
В конкретно вашем случае это отличие скорее всего вполне приемлемо, но врядли так будет во всех платформо-зависимых решениях…
>То-то MS официально объявила о выходе .net для других платформ, разбиении фреймворка и так далее.
Прошло 15 лет с появления .net и первого обещания MS о том что кросплатформенность будет и вот уже «MS официально объявила».
Объявление конечно это не может не радовать, но когда же уже он выйдет и какие библиотеки в нем будут? Почему именно сейчас?
> Вопрос в том, что считать платформой MS.
Думаю это в первую очередь то что приносит продажи MS
> Что вы понимаете под «workstation»?
> Для всего энтерпрайза, если быть точным.
Согласен — термин не очень конкретный.
Я имел ввиду рабочие места дизайнеров, конструкторов, разработчиков ПО, и думаю не только их. А чьи рабочие места в вашем понимании входят в энтерпрайз, почему конструктора например не входят?
>Да ладно вам. Я перестал дома (и на ноутбуке) пользоваться десктопным клиентом для почты.
А как насчет Word, Excel, Visio? Кстати наверняка на смартфоне вы используете приложение клиента, а не веб интефейс. А если так, — не задумывались, — почему?
>Но, еще раз повторюсь: это все старые отрасли применения, по сравнению с ситуацией, скажем, десять лет назад — ничего нового не появилось. Или я пропустил что-то?
Да, это старые области применения, они развились и сейчас в них происходят не революционные, а эволюционные изменения. Но так ли много новых именно областей появилось для энтерпрайз?
>В общем, все это возвращает нас к началу дискуссии: при правильных архитектурных решениях C# сейчас является не более «опасным» с точки зрения будущего языком, чем C++.
Язык сам по себе не причем, но выбор С# часто тянет за собой выбор инфраструктуры и библиотек, которые «внезапно» оказываются существуют только под Windows. И это уже ведет к рискам.
Например: я собираюсь писать на С#, но не хочу завазываться на Windows. На чем мне писать UI? Если я из-за красивостей и биндинга (выгодных моей разработке) выберу WPF, то путь на другие платформы у меня будет отрезан, с Winforms ситуация не на много лучше, только без красивостей и биндинга и с некой реализацией winapi на mono, в 100% идентичность оригиналу которой я не верю.
Gtk#? Как-то страшновато, да и функционал до WPF не додягивает, хорошо если покроет Winforms.
И кроме UI можно найти еще направления, где для С# есть инфраструктура под Windows, для которой нет аналогов на других платформах.
Но парадокс в том, что именно ради нее часто и выбирают C#, отрубая путь на другие платформы.
Например вы выбрали IOCP. Замечательная штука, но на других платформах ее нет в таком виде, и она будет реализована через другие механизмы(по сути будет эмулироваться) поэтому будет по-другому работать.
Для вашей задачи это «по-другому» возможно будет приемлемо, но когда таких «по-другому» накапливается критическая масса, то это может вызвать критические проблемы.
Вы можете сказать, что на С++ тоже можно завязаться на платформо-зависимую и все проблемы будут теже самые.
Да, это правда, но разница в том, что для С++ есть практики и рекомендации как писать «кросплатформенно», а для C# такие практики не пропагандируются (разве что не тянуть импорты из dll) потому что такого рода пропаганда не выгодна Microsoft. Выгода Microsoft в максимально глубоком и сильно связанном подсаживании на свою платформу.
>А-га. Вот возьмем, например, Apple — эти долго и упорно работали с Objective-C, а недавно выкатили — и всем пропагандируют Swift.
>Или Adobe. Внезапно, от 40 до 60 (по разным источникам) процентов Lightroom (это такое весьма графически интенсивное приложение) написано на Lua.
Можно еще добавить что часть офиса написана на VBA, и некоторые части кадов написаны на их встроены языках для приложений. Но тут важно понимать как это делается: сначала пишется быстрое API на C++, и потом оно проводится на верхний уровень, где уже с ним работают на «прикладных» языках. Но эта «управленческая» работа т.е. если хотят работать быстро, на верху оперируют очень крупными сущностными. Это конечно решает ряд задач, но далеко не все и поэтому не может стать единственным направлением развития. Тяжелые функции ведь тоже надо писать, если их писать наверху то приложение может деградировать по производительности (если говорить о кадах например, да похоже что и о офисе)
>А по поводу WPF у многих есть такие сомнения (просто не надо путать WPF и .net), у него действительно был продолжительный период упадка.
Да… Но на чем еще писать UI под .net? Winforms хоть и быстрее, но откровенный и не очень хороший враппер WinAPI. А других вариантов особо и нет вроде?
>Основной пойнт в том, что чистые десктопные приложения понемногу вымирают, их область применения не растет (в отличие от отрасли в целом).
Декстопные приложение уходят на Workstation, где им и место ну и плюс игры.
Пока Workstation на вебе есть в лучшем случае для бухгалтеров и документооборота. Даже офис приложения на вебе не смог занять нишу офиса в виде приложения для десктопов и мобильных устройств.
Мобильные же устройства пока у них не будет нормального ввода нишу Workstation тоже занять не смогут. Тач он хорош, но до производительности ввода клавиатуры и точности ввода мышкой ему пока далеко (да и цели у него такой нет), а без этого сейчас сложно представить Workstation.
>Утечка памяти в языке с GC может быть по двум причинам:
>В обоих случаях запуск профайлера памяти сразу покажет кто виноват и как поправить.
То простые случаи. Более неприятные случаи когда:
— Утечки возникают из-за не освобожденных ресурсов системы, особенно взятых импортами из dll системы.
— В неправильной последовательности освобождаются COM объекты ( GC не знает в какой последовательности их освобождать, а типичный дотнет девелопер не приучен чего-либо освобождать, если у него нет метода Dispose)
— Кривой маршалинг при вызове импортов из dll. Тут скорее не утечка памяти, а просто ее порча со всеми вытекающими последствиями не менее страшными, чем на С++, но более неожиданными.
— С WPF ом тоже помню были утечки, которые трудоемко было отловить
>Что ты имеешь ввиду? Что в C++ не надо пользоваться профайлером, чтобы найти узкое место? Это откровенно глупое заявление.
Надо. Но при ревью С++ кода проще найти более тяжелые для выполнения вещи из-за меньшего количества синтетики.
Это скорее к языку. Например код: «instance.Name» на С++ однозначно обратиться к филду, а на С# легко может обратиться к проперти внутри которой может быть засунуты тяжелые вычисления. Были еще какие-то подобные примеры.
Это вроде и мелочи, но несколько увеличивают вероятность пропустить потенциальную трату ресурсов.
>гугл с го, твиттер со скалой, мозилла с растом
Но это только «большие игроки» веба. Есть еще немало «больших игроков» десктоп-приложений. Они по большей части сидят на С++ и исправно переходят на более свежие компиляторы, поддерживают новые платформы.
Даже Микрософт пока не спешит переводить свои десктопные продукты на .net…
(конечно кое-что из дотнета в них есть, но вот например не-WPF рибоны в офисе у меня зародили сомнения в том, что микрософт уверен в перспективности технологии)
Да и хром от гугла, равно как и firefox от мозилы врядли будет переписан на что-то отличное от С++ (это если говорить о десктопных приложениях)
>Они все идут в сторону повышения абстракции и упрощения тех или иных аспектов современного программирования.
Безусловно, все развивающиеся средства разработки к этому так или иначе идут…
>Чтобы получить такое веб-приложение, которое нельзя легко адаптировать под другой браузер, нужно долго и последовательно совершать ошибки.
Да. Либо выбрать стратегию, которая из «кривой архитектуры» извлекает экономию в краткосрочном периоде.
>Очередной велосипед? Чем вам существующих протоколов мало, вот уж нужды типовых приложений они покрывают с головой.
Если подходящий протокол с его реализацией найдется — конечно стоит взять его.
> То, что вы описываете — не технологическая проблема.
И да и нет. Это проблема затачивания приложения под фичи, которые существуют только на одной платформе. Она может возникнуть конечно не только с ASP.NET, это проблема подхода. Просто ASP.NET тогда оказался самым дешевым способом
> И опять-таки, мобильное приложение к существующему сайту написать несложно, WebAPI из asp.net выставляется легко, все мобильные клиенты умеют есть REST API.
Вероятно когда спохватились, было уже недостаточно ресурсов для адаптации. Да и приложение похоже было слишком ориентировано на работу в локалке с большим трафиком и хорошим пингом к серверу, что не хорошо для мобильной версии.
>c++ предлагает только debug билды и это всё?
Не, ну почему, можно добавить логгинг в свое приложение и логить происходяшее там, дабы получать информацию о исключениях и местах где они произошли
Про gflags я говорил уже
Практика code review в принципе тоже позволяет избежать большой части ошибок, которые могут совершить программисты.
Регрессионные «юнит»-тесты тоже вполне могут помочь.
Конечно все это не панацея, но справедливости ради и в managed средах бывают сложно вылавливыемае ошибки. Например утечки памяти в managed средах ловить не так и просто.
А некторые проблемы с избыточным потреблением ресурсов процессора, без профайлера, могут быть заметно менее очевыдны чем в случае С++.
Хотя согласен что в managed ловить ошибки проще (но ровно до тех пор пока среда не стала mixed)
>Типичная ошибка архитектуры, не имеющая отношения к выбранной технологии.
Скорее ошибка оценки перспектив рынка. Если бы мобильные платформы не развились, проекты вероятно жили бы и по сей день.
>А чем, по-вашему, серверная часть на C++ отличается от веб-бекэнда на C++, что первое на нем писать можно, а второе — нет?
Серверная часть С++ может быть написана со своим протоколом, это может сильно снизить трафик и упростить «парсинг» пакетов.
>В общем и целом этот ваш пример вот никак не показывает ущербность C# с точки зрения перспектив
Да, но пример и не был призван иллюстрировать ущербность C#. Пример показывает риски связанные с завязкой приложения на одну платформу.
Во втором из тех двух проектов, завязки на IE были не очень сильные и там даже успели адаптироваться под другние браузеры, но получилась ситуация в которой мобильные приложения стали удобнее, чем их веб решение поэтому рынок стал теряться и проект сворачиваться.
Razaz, я выложил тестовый проект с тормозным гридом (на чистом WPF), и скриншот профайлера во время скрола. Можете посмотреть и вынести свое суждение относительно причин тормозни, былобы очень интересно узнать.
Воспроизводить так:
1. Запустить
2. Развернуть на полный экран (хотя должна развернуться итак на старте)
3. Подергать вертикальный скроллер ввер и вниз.
4. Наблюдать лаги отзывчивости UI на скроллер.
>А это одного порядка вещи. Вы настолько же не знаете, что внутри себя делает ReadFile, насколько я — как именно ReadAsync делает свое волшебство.
C одной лишь разницей,- я знаю что ReadAsync(и любое другое дотнетовское чтение файла) в конечном счете вызовет ReadFile
>Нет, ну правда, сколько процентов от времени чтения мегабайтного чанка будет занимать оверхед? А десятимегабайтного?
При больших чанках процент очень малый. И если в работе с памятью оверхеда не будет, то смысла в переходе на С++ конкретно для этой задачи мало.
Да и еще проект тестовый, очень быстро набросан, кода почти нет
s000.tinyupload.com/?file_id=09607171972593390390
Воспроизводить так:
1. Запустить
2. Развернуть на полный экран (хотя должна развернуться итак на старте)
3. Подергать вертикальный скроллер ввер и вниз.
4. Наблюдать лаги отзывчивости UI на скроллер.
Зависит от проекта и продукта, как правило от 4 месяцев до года, иногда больше.
>А как определить, кроссплатформенно ли вы пишете?
Есть некоторые стандарты и правила. Если коротко, суть их в том, что на С++ вы должны использовать только библиотеки включенные в стандарт С++ и кросплатформенные библиотеки, а всякие API операционной системы не использовать.
И да — конечно надо, на каждой платформе, если релиз на несколько платформ.
Однако это не значит что во время разработки вы должны каждое изменение проверять на всех платформах. Если писать более менее кросплатформенно, то этапа тестирования перед релизом должно бы хватить.
Как же без UI на десктопе?
>Вы не понимаете. Я не выбрал IOCP, я выбрал асинхронный I/O.
То есть вы в целом были готовы к тому что работа асинхронного I/O может отличаться на разных платформах.
В конкретно вашем случае это отличие скорее всего вполне приемлемо, но врядли так будет во всех платформо-зависимых решениях…
>То-то MS официально объявила о выходе .net для других платформ, разбиении фреймворка и так далее.
Прошло 15 лет с появления .net и первого обещания MS о том что кросплатформенность будет и вот уже «MS официально объявила».
Объявление конечно это не может не радовать, но когда же уже он выйдет и какие библиотеки в нем будут? Почему именно сейчас?
> Вопрос в том, что считать платформой MS.
Думаю это в первую очередь то что приносит продажи MS
> Для всего энтерпрайза, если быть точным.
Согласен — термин не очень конкретный.
Я имел ввиду рабочие места дизайнеров, конструкторов, разработчиков ПО, и думаю не только их. А чьи рабочие места в вашем понимании входят в энтерпрайз, почему конструктора например не входят?
>Да ладно вам. Я перестал дома (и на ноутбуке) пользоваться десктопным клиентом для почты.
А как насчет Word, Excel, Visio? Кстати наверняка на смартфоне вы используете приложение клиента, а не веб интефейс. А если так, — не задумывались, — почему?
>Но, еще раз повторюсь: это все старые отрасли применения, по сравнению с ситуацией, скажем, десять лет назад — ничего нового не появилось. Или я пропустил что-то?
Да, это старые области применения, они развились и сейчас в них происходят не революционные, а эволюционные изменения. Но так ли много новых именно областей появилось для энтерпрайз?
Язык сам по себе не причем, но выбор С# часто тянет за собой выбор инфраструктуры и библиотек, которые «внезапно» оказываются существуют только под Windows. И это уже ведет к рискам.
Например: я собираюсь писать на С#, но не хочу завазываться на Windows. На чем мне писать UI? Если я из-за красивостей и биндинга (выгодных моей разработке) выберу WPF, то путь на другие платформы у меня будет отрезан, с Winforms ситуация не на много лучше, только без красивостей и биндинга и с некой реализацией winapi на mono, в 100% идентичность оригиналу которой я не верю.
Gtk#? Как-то страшновато, да и функционал до WPF не додягивает, хорошо если покроет Winforms.
И кроме UI можно найти еще направления, где для С# есть инфраструктура под Windows, для которой нет аналогов на других платформах.
Но парадокс в том, что именно ради нее часто и выбирают C#, отрубая путь на другие платформы.
Например вы выбрали IOCP. Замечательная штука, но на других платформах ее нет в таком виде, и она будет реализована через другие механизмы(по сути будет эмулироваться) поэтому будет по-другому работать.
Для вашей задачи это «по-другому» возможно будет приемлемо, но когда таких «по-другому» накапливается критическая масса, то это может вызвать критические проблемы.
Вы можете сказать, что на С++ тоже можно завязаться на платформо-зависимую и все проблемы будут теже самые.
Да, это правда, но разница в том, что для С++ есть практики и рекомендации как писать «кросплатформенно», а для C# такие практики не пропагандируются (разве что не тянуть импорты из dll) потому что такого рода пропаганда не выгодна Microsoft. Выгода Microsoft в максимально глубоком и сильно связанном подсаживании на свою платформу.
>Или Adobe. Внезапно, от 40 до 60 (по разным источникам) процентов Lightroom (это такое весьма графически интенсивное приложение) написано на Lua.
Можно еще добавить что часть офиса написана на VBA, и некоторые части кадов написаны на их встроены языках для приложений. Но тут важно понимать как это делается: сначала пишется быстрое API на C++, и потом оно проводится на верхний уровень, где уже с ним работают на «прикладных» языках. Но эта «управленческая» работа т.е. если хотят работать быстро, на верху оперируют очень крупными сущностными. Это конечно решает ряд задач, но далеко не все и поэтому не может стать единственным направлением развития. Тяжелые функции ведь тоже надо писать, если их писать наверху то приложение может деградировать по производительности (если говорить о кадах например, да похоже что и о офисе)
>А по поводу WPF у многих есть такие сомнения (просто не надо путать WPF и .net), у него действительно был продолжительный период упадка.
Да… Но на чем еще писать UI под .net? Winforms хоть и быстрее, но откровенный и не очень хороший враппер WinAPI. А других вариантов особо и нет вроде?
>Основной пойнт в том, что чистые десктопные приложения понемногу вымирают, их область применения не растет (в отличие от отрасли в целом).
Декстопные приложение уходят на Workstation, где им и место ну и плюс игры.
Пока Workstation на вебе есть в лучшем случае для бухгалтеров и документооборота. Даже офис приложения на вебе не смог занять нишу офиса в виде приложения для десктопов и мобильных устройств.
Мобильные же устройства пока у них не будет нормального ввода нишу Workstation тоже занять не смогут. Тач он хорош, но до производительности ввода клавиатуры и точности ввода мышкой ему пока далеко (да и цели у него такой нет), а без этого сейчас сложно представить Workstation.
>В обоих случаях запуск профайлера памяти сразу покажет кто виноват и как поправить.
То простые случаи. Более неприятные случаи когда:
— Утечки возникают из-за не освобожденных ресурсов системы, особенно взятых импортами из dll системы.
— В неправильной последовательности освобождаются COM объекты ( GC не знает в какой последовательности их освобождать, а типичный дотнет девелопер не приучен чего-либо освобождать, если у него нет метода Dispose)
— Кривой маршалинг при вызове импортов из dll. Тут скорее не утечка памяти, а просто ее порча со всеми вытекающими последствиями не менее страшными, чем на С++, но более неожиданными.
— С WPF ом тоже помню были утечки, которые трудоемко было отловить
>Что ты имеешь ввиду? Что в C++ не надо пользоваться профайлером, чтобы найти узкое место? Это откровенно глупое заявление.
Надо. Но при ревью С++ кода проще найти более тяжелые для выполнения вещи из-за меньшего количества синтетики.
Это скорее к языку. Например код: «instance.Name» на С++ однозначно обратиться к филду, а на С# легко может обратиться к проперти внутри которой может быть засунуты тяжелые вычисления. Были еще какие-то подобные примеры.
Это вроде и мелочи, но несколько увеличивают вероятность пропустить потенциальную трату ресурсов.
Но это только «большие игроки» веба. Есть еще немало «больших игроков» десктоп-приложений. Они по большей части сидят на С++ и исправно переходят на более свежие компиляторы, поддерживают новые платформы.
Даже Микрософт пока не спешит переводить свои десктопные продукты на .net…
(конечно кое-что из дотнета в них есть, но вот например не-WPF рибоны в офисе у меня зародили сомнения в том, что микрософт уверен в перспективности технологии)
Да и хром от гугла, равно как и firefox от мозилы врядли будет переписан на что-то отличное от С++ (это если говорить о десктопных приложениях)
>Они все идут в сторону повышения абстракции и упрощения тех или иных аспектов современного программирования.
Безусловно, все развивающиеся средства разработки к этому так или иначе идут…
Да. Либо выбрать стратегию, которая из «кривой архитектуры» извлекает экономию в краткосрочном периоде.
>Очередной велосипед? Чем вам существующих протоколов мало, вот уж нужды типовых приложений они покрывают с головой.
Если подходящий протокол с его реализацией найдется — конечно стоит взять его.
> То, что вы описываете — не технологическая проблема.
И да и нет. Это проблема затачивания приложения под фичи, которые существуют только на одной платформе. Она может возникнуть конечно не только с ASP.NET, это проблема подхода. Просто ASP.NET тогда оказался самым дешевым способом
> И опять-таки, мобильное приложение к существующему сайту написать несложно, WebAPI из asp.net выставляется легко, все мобильные клиенты умеют есть REST API.
Вероятно когда спохватились, было уже недостаточно ресурсов для адаптации. Да и приложение похоже было слишком ориентировано на работу в локалке с большим трафиком и хорошим пингом к серверу, что не хорошо для мобильной версии.
Не, ну почему, можно добавить логгинг в свое приложение и логить происходяшее там, дабы получать информацию о исключениях и местах где они произошли
Про gflags я говорил уже
Практика code review в принципе тоже позволяет избежать большой части ошибок, которые могут совершить программисты.
Регрессионные «юнит»-тесты тоже вполне могут помочь.
Конечно все это не панацея, но справедливости ради и в managed средах бывают сложно вылавливыемае ошибки. Например утечки памяти в managed средах ловить не так и просто.
А некторые проблемы с избыточным потреблением ресурсов процессора, без профайлера, могут быть заметно менее очевыдны чем в случае С++.
Хотя согласен что в managed ловить ошибки проще (но ровно до тех пор пока среда не стала mixed)
Каких именно «игроков» вы имеете ввиду, и куда они идут, по вашему мнению?
Скорее ошибка оценки перспектив рынка. Если бы мобильные платформы не развились, проекты вероятно жили бы и по сей день.
>А чем, по-вашему, серверная часть на C++ отличается от веб-бекэнда на C++, что первое на нем писать можно, а второе — нет?
Серверная часть С++ может быть написана со своим протоколом, это может сильно снизить трафик и упростить «парсинг» пакетов.
>В общем и целом этот ваш пример вот никак не показывает ущербность C# с точки зрения перспектив
Да, но пример и не был призван иллюстрировать ущербность C#. Пример показывает риски связанные с завязкой приложения на одну платформу.
Во втором из тех двух проектов, завязки на IE были не очень сильные и там даже успели адаптироваться под другние браузеры, но получилась ситуация в которой мобильные приложения стали удобнее, чем их веб решение поэтому рынок стал теряться и проект сворачиваться.
Если поставить заведомо дурные приоритеты разработки, то испортить можно любой продукт на любом языке.
>Кстати именно отзывчивость обещают в первую очередь починить в 2016.
Хорошо-бы.
s000.tinyupload.com/?file_id=09607171972593390390
Воспроизводить так:
1. Запустить
2. Развернуть на полный экран (хотя должна развернуться итак на старте)
3. Подергать вертикальный скроллер ввер и вниз.
4. Наблюдать лаги отзывчивости UI на скроллер.
А ниже можно еще найти скриншот профайлера.
www.codesynthesis.com/products/odb
Тут вообще ничего нет, только сгенеренные данные, и достаточно много колонок (автогенеренные колонки я не выключал)
Виртуализация — включена.
C одной лишь разницей,- я знаю что ReadAsync(и любое другое дотнетовское чтение файла) в конечном счете вызовет ReadFile
>Нет, ну правда, сколько процентов от времени чтения мегабайтного чанка будет занимать оверхед? А десятимегабайтного?
При больших чанках процент очень малый. И если в работе с памятью оверхеда не будет, то смысла в переходе на С++ конкретно для этой задачи мало.
s30.postimg.org/4lvgfhrnl/Measure.png
s000.tinyupload.com/?file_id=09607171972593390390
Воспроизводить так:
1. Запустить
2. Развернуть на полный экран (хотя должна развернуться итак на старте)
3. Подергать вертикальный скроллер ввер и вниз.
4. Наблюдать лаги отзывчивости UI на скроллер.