Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Не было никакой спирали. Синовский с самого начала похоронил .NET как средство разработки в Windows division.
Мне там цитатка понравилась:
We are not Windows developers because we love Windows. We put up with Windows so we can use C#, F# and VS2010. I've considered changing the platform many times. What stops me each time is the goodness that keeps coming from devdiv. LINQ, Rx, TPL, async — these are the reasons I'm still on Windows.
Она отражает и мое отношение к Винде. Берясь за очередную главу по программированию в Mac OS, всегда ловил себя на том, как же много сладких фенечек в программировании под Винду на .Net-е. И что же теперь? Крайне неприятное событие для MS, да еще и в день WWDC, что как-бэ намекает...
Re: No mention of either Silverlight or .NET on Windows 8
The fear of .NET developers is that Microsoft's Windows team now regards not only Silverlight but also .NET as a legacy technology
А откуда взят сей вывод? В прессрелизе сплошная маркетологическая вода и никакой конкретики: всё старое будет работать, но добавится еще и яваскрипт с блекджеком. Или я не туда смотрю?
Re: No mention of either Silverlight or .NET on Windows 8
Здравствуйте, c-smile, Вы писали:
CS>Завершился очередной виток спирали.
Перестаньте создавать панику без причины. Никуда .NET не денется. В Майкрософте не настолько глупые люди работают, чтобы такое сделать. Они прекрасно знают, что одна лишь попытка забросить .NET в пользу чего-то еще будет стоить им всех девелоперов, включая самых лояльных, которые после такой шутки сбегут куда угодно, хоть на PHP. А такая массовая миграция будет концом Майкрософта. На сегодняшний день они свой лимит экспериментов над программистами уже исчерпали. Следующий эксперимент сработает тригером.
Re[2]: No mention of either Silverlight or .NET on Windows 8
Здравствуйте, DorfDepp, Вы писали:
DD>Здравствуйте, c-smile, Вы писали: CS>>Завершился очередной виток спирали.
DD>Перестаньте создавать панику без причины.
Панику по определению "создать" нельзя. Её можно "вызвать".
Мопед — не мой, я просто о нем написал. Но если найдется критическая масса людей не уверенных в данной технологии то возникнет паника, да.
Я к образованию этой массы людей не имею никакого отношения.
DD>Никуда .NET не денется. В Майкрософте не настолько глупые люди работают, чтобы такое сделать. Они прекрасно знают, что одна лишь попытка забросить .NET в пользу чего-то еще будет стоить им всех девелоперов, включая самых лояльных, которые после такой шутки сбегут куда угодно, хоть на PHP. А такая массовая миграция будет концом Майкрософта. На сегодняшний день они свой лимит экспериментов над программистами уже исчерпали. Следующий эксперимент сработает тригером.
Ну как тебе сказать. Я был на двух конференциях Microsoft. На обоих вещал Don Box: на первой COM это наше всё, на второй он же и теми же словами — NET наше всё теперь. Смотрю на последние W7 API, скажем Direct2D/Write, это COM alike интерфейсы — т.е. на круги своя возвращаемся переосмыслив (в последнее хочется верить). Если тебе так не кажется то я не настаиваю на том. Но мнение свё имею право высказать, да?
Re: No mention of either Silverlight or .NET on Windows 8
DD>В Майкрософте не настолько глупые люди работают, чтобы такое сделать. Они прекрасно знают, что одна лишь попытка забросить .NET в пользу чего-то еще будет стоить им всех девелоперов, включая самых лояльных, которые после такой шутки сбегут куда угодно, хоть на PHP. А такая массовая миграция будет концом Майкрософта. На сегодняшний день они свой лимит экспериментов над программистами уже исчерпали. Следующий эксперимент сработает тригером.
Хотелось бы верить конечно. Но вот в Борланде наверно тоже не глупые люди работали. Если рассуждать более глобально, то и в Римской империи люди были неглупые, только сильно увлеклись разборками между собой
CS>Ну как тебе сказать. Я был на двух конференциях Microsoft. На обоих вещал Don Box: на первой COM это наше всё, на второй он же и теми же словами — NET наше всё теперь. Смотрю на последние W7 API, скажем Direct2D/Write, это COM alike интерфейсы — т.е. на круги своя возвращаемся переосмыслив (в последнее хочется верить). Если тебе так не кажется то я не настаиваю на том. Но мнение свё имею право высказать, да?
ну так COM вроде некуда не делся. И микрософт сделали все для совместимости COM и .Net
Здравствуйте, c-smile, Вы писали:
CS>Ну как тебе сказать. Я был на двух конференциях Microsoft. На обоих вещал Don Box: на первой COM это наше всё, на второй он же и теми же словами — NET наше всё теперь.
Всё для кого?
Больше всего в этой статье поражает непонимание автором одной простой вещи — для решения каждой конкретной задачи нужно выбирать наиболее подходящий инструмент. OS нужно писать на C++, а ещё лучше на C. У Windows цикл релизов в несколько лет и одна из важнейших решаемых задач — это потребление ресурсов. Если следующая операционная система вдруг потребует от меня покупки втрое более мощного компьютера, чем у меня сейчас, то я либо никуда не перейду, либо перейду к конкурентам.
Совсем другое дело бизнес приложения. Если я предложу своему босу на выбор — пол года разработки и продакшин сервер втрое мощнее или полтора года, но возможность использования существующего железа, то выбор, думаю, очевиден. У бизнес приложений цикл разработки месяцы в лучшем случае. Потом поток доработок под адаптирующийся бизнес, которые нужно сделать вчера. Какой тут C/C++? Вы что, ребята? .NET — наше всё! И никуда он не денется.
Если нам не помогут, то мы тоже никого не пощадим.
Re[4]: No mention of either Silverlight or .NET on Windows 8
Здравствуйте, IT, Вы писали:
IT>.NET — наше всё! И никуда он не денется.
С серверов — да, никуда не денется. Там ему хорошо и там он хорош.
Но вопрос то про клиентскую ось. HTML/CSS/Script/Ajax по многим причинам более приемлем для UI
business систем.
Re[5]: No mention of either Silverlight or .NET on Windows 8
Здравствуйте, c-smile, Вы писали:
CS>Здравствуйте, IT, Вы писали:
IT>>.NET — наше всё! И никуда он не денется.
CS>С серверов — да, никуда не денется. Там ему хорошо и там он хорош. CS>Но вопрос то про клиентскую ось. HTML/CSS/Script/Ajax по многим причинам более приемлем для UI CS>business систем.
по каким, кроме того что браузеры везде есть?
— это дублирование кода для клиента и сервера на разных языках
— проблемы с совместимостью браузеров
— либо примитивный фреймворк для гуя — никаких тебе биндингов, объектной модели, шаблонов итд., либо использование сторонних jscript библиотек — тормозных и без поддержки тулов для дизайна
Здравствуйте, Евгений Акиньшин, Вы писали:
IT>>>.NET — наше всё! И никуда он не денется.
CS>>С серверов — да, никуда не денется. Там ему хорошо и там он хорош. CS>>Но вопрос то про клиентскую ось. HTML/CSS/Script/Ajax по многим причинам более приемлем для UI CS>>business систем.
ЕА>по каким, кроме того что браузеры везде есть?
Этого мало? Кроме того есть еще не только броузеры умеющие HTML/CSS/Script/Ajax
ЕА>- это дублирование кода для клиента и сервера на разных языках
Дублирование кода в клиент-сервер модели? Это про что вообще?
Ну и потом... UI и сервер исповедуют настолько разные парадигмы что объять их одним языком нереально. Что-то пострадает.
Скажем jQuery как DSL для UI как-то более симпатичнее выглядит чем километровые конструкции на C#.
html более высокоуровневый язык чем XAML. CSS как язык описания стилей ... короче стилям XAMLа до него как до луны.
ЕА>- проблемы с совместимостью браузеров
Были когда-то, да. На сегодняшний момент не так уж и актульно.
Ну и если вопрос стоит про бизнесс системы то вполне себе можно ориентироваться на webkit only.
ЕА>- либо примитивный фреймворк для гуя — никаких тебе биндингов, объектной модели, шаблонов итд., либо использование сторонних jscript библиотек — тормозных и без поддержки тулов для дизайна
Тем не менее количество приложений и бизнесс систем с GUI в browser на порядки превышает все что было создано на Winforms, WPF, etc.
Re[4]: No mention of either Silverlight or .NET on Windows 8
Здравствуйте, Евгений Акиньшин, Вы писали:
ЕА>ну так COM вроде некуда не делся. И микрософт сделали все для совместимости COM и .Net
Я вообще не ацкий спец по .NET, но судя по data.oledb они сделали ровно столько, чтобы сказать "ну мы типа что-то сделали". Хочешь поддержку получше — перепиши это все с нуля.
-- Пользователи не приняли программу. Всех пришлось уничтожить. --
Re[7]: No mention of either Silverlight or .NET on Windows 8
ЕА>>по каким, кроме того что браузеры везде есть?
CS>Этого мало? Кроме того есть еще не только броузеры умеющие HTML/CSS/Script/Ajax
этого не мало, но это не отменяет того факта что html кривой и по разному отображается во всех браузерах, соотвественно усилий на создание и поддержание такого приложения в разы больше
ЕА>>- это дублирование кода для клиента и сервера на разных языках CS>Дублирование кода в клиент-сервер модели? Это про что вообще?
ну вообще классический пример для бизнес-приложений это валидация данных. Вообще странный вопрос — у меня вот есть например встраиваемый в бизнес-приложения редактор диаграмм и нужна единая объектная модель этих диаграмм для клиента и сервера, чтобы все манипуляции, отрисовка, экспорт в картинку работали и на стороне клиент (даже если у него коннекшиона к интернету нету) и на стороне сервера.
CS>Ну и потом... UI и сервер исповедуют настолько разные парадигмы что объять их одним языком нереально. Что-то пострадает. CS>Скажем jQuery как DSL для UI как-то более симпатичнее выглядит чем километровые конструкции на C#. CS>html более высокоуровневый язык чем XAML. CSS как язык описания стилей ... короче стилям XAMLа до него как до луны.
ну да, конечно, отсутствие возможности создавать свои визуальные элементы, биндингов, отсутсвии lookless контролов, графических трансформаций, универсального механизма раскладки элементов с возможностью создания своих контейнеров, единого механизма для отображения векторной графики, движка для декларативной анимации, MarkUp Extensitions, DataTemplates итд. автоматически делает Html более высокуровневым языком — даже не смешно
ЕА>>- проблемы с совместимостью браузеров
CS>Были когда-то, да. На сегодняшний момент не так уж и актульно. CS>Ну и если вопрос стоит про бизнесс системы то вполне себе можно ориентироваться на webkit only.
угу, плавали — знаем как это не актуально. пока у большинства таки IE, и совсем даже не 9-й
ЕА>>- либо примитивный фреймворк для гуя — никаких тебе биндингов, объектной модели, шаблонов итд., либо использование сторонних jscript библиотек — тормозных и без поддержки тулов для дизайна
CS>Тем не менее количество приложений и бизнесс систем с GUI в browser на порядки превышает все что было создано на Winforms, WPF, etc.
не спорю, ну так это не аргумент о совершенстве системы. У нас в городе жигулей на порядок больше чем БМВ, отнюдь не из-за технического превосходства первых
Здравствуйте, Евгений Акиньшин, Вы писали:
ЕА>ну да, конечно, отсутствие возможности создавать свои визуальные элементы, биндингов, отсутсвии lookless контролов, графических трансформаций, универсального механизма раскладки элементов с возможностью создания своих контейнеров, единого механизма для отображения векторной графики, движка для декларативной анимации, MarkUp Extensitions, DataTemplates итд. автоматически делает Html более высокуровневым языком — даже не смешно
Может он и фичастый, только никому не нужный. Три с половиной прожки на WPF и десятки миллионов сайтов с jQuery нам как-бэ намекаются.
Re[3]: No mention of either Silverlight or .NET on Windows 8
Здравствуйте, Евгений Акиньшин, Вы писали:
ЕА> Хотелось бы верить конечно. Но вот в Борланде наверно тоже не глупые люди работали.
Да что ты снова про Борланд... Борланд сгубил дебильный менеджмент с его бесконечными мотыляниями из стороны в сторону (переименуемся в Inprise. Нет, переименуемся обратно в Борланд. Не будем развивать Interbase, отдадим исходники. Нет, будем развивать Interbase. Выпустим линукс-версию дельфей. Нет, не будем поддерживать линукс. О-о-о, теперь только дотнет! Напишем свой C# билдер, круче МС-студии. Нет, не будем писать C# билдер. Так-так, средства разработки это не профильный актив, нужно избавиться. Займемся продуктами жизненного цикла приложений. RIP.). Но только пользователи Борланда его кончины на себе не ощутили, т.к. продукты были выкуплены новой компанией и получили нехилый импульс в развитие. И эта компания постепенно делает то, чего от Борланда все ждали очень давно, но так и не дождались.
Здравствуйте, Евгений Акиньшин, Вы писали:
CS>>Ну и потом... UI и сервер исповедуют настолько разные парадигмы что объять их одним языком нереально. Что-то пострадает. CS>>Скажем jQuery как DSL для UI как-то более симпатичнее выглядит чем километровые конструкции на C#. CS>>html более высокоуровневый язык чем XAML. CSS как язык описания стилей ... короче стилям XAMLа до него как до луны.
ЕА>ну да, конечно, отсутствие возможности создавать свои визуальные элементы, биндингов, отсутсвии lookless контролов, графических трансформаций, универсального механизма раскладки элементов с возможностью создания своих контейнеров, единого механизма для отображения векторной графики, движка для декларативной анимации, MarkUp Extensitions, DataTemplates итд. автоматически делает Html более высокуровневым языком — даже не смешно
Про MarkUp Extensitions ничего не знаю но подозреваю что вот это:
<object property="{StaticResource key}" .../>
валидно как в XAML так и в HTML. Куча всяко разных тулкитов используют свои атрибуты вплоть до DSL в своих
<script type="text/x-my-dsl">...</script> секциях.
ЕА>>>- проблемы с совместимостью браузеров
CS>>Были когда-то, да. На сегодняшний момент не так уж и актульно. CS>>Ну и если вопрос стоит про бизнесс системы то вполне себе можно ориентироваться на webkit only.
ЕА>угу, плавали — знаем как это не актуально. пока у большинства таки IE, и совсем даже не 9-й
Еще раз, если ты строишь корпоративную бизнесс систему то ты можешь делать её скажем под Google Chrome / WebKit только.
Работает везде: от Win до iOS c андроидами.
ЕА>>>- либо примитивный фреймворк для гуя — никаких тебе биндингов, объектной модели, шаблонов итд., либо использование сторонних jscript библиотек — тормозных и без поддержки тулов для дизайна
CS>>Тем не менее количество приложений и бизнесс систем с GUI в browser на порядки превышает все что было создано на Winforms, WPF, etc.
ЕА>не спорю, ну так это не аргумент о совершенстве системы. У нас в городе жигулей на порядок больше чем БМВ, отнюдь не из-за технического превосходства первых
Ну как тебе сказать. У нас в городе количество BMW и Mercedes наверное превышает количество любых других марок взятых отдельно.
Но тем не менее единственный способ сделать систему которой смогут пользоваться все жители это WebUI. Ибо соотношение MacPC и WinPC примерно 50/50.
Короче: ты можешь "об-дата-биндиться" весь но если твоя система не работает на iPhone то в городе Richmond у тебя шансов нет.
Re[4]: No mention of either Silverlight or .NET on Windows 8
H>Да что ты снова про Борланд... Борланд сгубил дебильный менеджмент с его бесконечными мотыляниями из стороны в сторону (переименуемся в Inprise. Нет, переименуемся обратно в Борланд. Не будем развивать Interbase, отдадим исходники. Нет, будем развивать Interbase. Выпустим линукс-версию дельфей. Нет, не будем поддерживать линукс. О-о-о, теперь только дотнет! Напишем свой C# билдер, круче МС-студии. Нет, не будем писать C# билдер.
Именно так, мотыляния и сгубили. Так о том-то и речь, что микрософт в ту же игру играет:
— все делаем на ВинФормз
— нет винформз устарел не будем его развивать, все делаем на WPF
— нет ну нафиг WPF, сильверлайт рулит
— нет сильверлайт забрасываем, "HTML5 is the way to go"
задолбали, и ладно если раньше избавлялись от того что реально устарело, типа VB6, то теперь технологии не только устареть, но даже заматереть не успевают
H> Но только пользователи Борланда его кончины на себе не ощутили, т.к. продукты были выкуплены новой компанией и получили нехилый импульс в развитие. И эта компания постепенно делает то, чего от Борланда все ждали очень давно, но так и не дождались.
знаю таких не ощутивших, ждавших по несколько лет 64-битный компилятор (выход которого откладывали не знаю сколько раз на моей памяти), а потом переписавших свои приложения на Си++, а также других не ощутивших, которые до сих пор ждут
Здравствуйте, iHateLogins, Вы писали: HL>Может он и фичастый, только никому не нужный. Три с половиной прожки на WPF и десятки миллионов сайтов с jQuery нам как-бэ намекаются.
Угу, только при этом типовой веб vs десктоп выглядит как-то так:
Silverlight
Grapholite. 3 человека, работа в свободное время, менее года работы (информация отсюда).
Здравствуйте, Sinix, Вы писали:
HL>>Может он и фичастый, только никому не нужный. Три с половиной прожки на WPF и десятки миллионов сайтов с jQuery нам как-бэ намекаются.
S>Угу, только при этом типовой веб vs десктоп выглядит как-то так:
Из принципиалных отличий — "замыленные" шрифты на десктопе. Всего остального в вебе — вагон и маленькая тележка.
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Re[5]: No mention of either Silverlight or .NET on Windows 8
Здравствуйте, Евгений Акиньшин, Вы писали:
ЕА> Именно так, мотыляния и сгубили. Так о том-то и речь, что микрософт в ту же игру играет:
ЕА> — все делаем на ВинФормз ЕА> — нет винформз устарел не будем его развивать, все делаем на WPF ЕА> — нет ну нафиг WPF, сильверлайт рулит ЕА> — нет сильверлайт забрасываем, "HTML5 is the way to go"
ЕА> задолбали, и ладно если раньше избавлялись от того что реально устарело, типа VB6, то теперь технологии не только устареть, но даже заматереть не успевают
Ну так ведь от дотнета никто не отказывается, вроде Ну не напишут следующую винду на нем, но прикладникам-то не пофигу ли?
ЕА> H> Но только пользователи Борланда его кончины на себе не ощутили, т.к. продукты были выкуплены новой компанией и получили нехилый импульс в развитие. И эта компания постепенно делает то, чего от Борланда все ждали очень давно, но так и не дождались.
ЕА> знаю таких не ощутивших, ждавших по несколько лет 64-битный компилятор (выход которого откладывали не знаю сколько раз на моей памяти), а потом переписавших свои приложения на Си++, а также других не ощутивших, которые до сих пор ждут
64 бита очень мало кому нужны, особенно в том секторе куда направлены основные усилия разработчиков дельфей. Любой софт не требующий интеграции с 64битной ОС выгоднее делать 32-битным, это же очевидно Впрочем, тем кто ждет, ждать осталось не долго. В сентябре будет 64-битный компилятор и компилятор под МакОС.
Здравствуйте, Sinix, Вы писали: S> HL>Может он и фичастый, только никому не нужный. Три с половиной прожки на WPF и десятки миллионов сайтов с jQuery нам как-бэ намекаются. S> Угу, только при этом типовой веб vs десктоп выглядит как-то так: S>
Здравствуйте, c-smile, Вы писали:
CS>С серверов — да, никуда не денется. Там ему хорошо и там он хорош. CS>Но вопрос то про клиентскую ось. HTML/CSS/Script/Ajax по многим причинам более приемлем для UI business систем.
Причин то не множество, а одна — кроссплатформенность. Но я не об этом хочу поговорить. Можешь ли привести примеры нескольких серьезных клиентских приложений, написанных только с использованием HTML/CSS/Script/Ajax? Не фигню с тремя четырьмя пёстрыми формочками, а серьезное решение, с большим числом окон на клиенте, с графиками, выполняющее много серьезных расчетов на клиентской стороне?
Re[6]: No mention of either Silverlight or .NET on Windows 8
Здравствуйте, hattab, Вы писали:
H>Здравствуйте, Евгений Акиньшин, Вы писали:
ЕА>> Именно так, мотыляния и сгубили. Так о том-то и речь, что микрософт в ту же игру играет:
ЕА>> — все делаем на ВинФормз ЕА>> — нет винформз устарел не будем его развивать, все делаем на WPF ЕА>> — нет ну нафиг WPF, сильверлайт рулит ЕА>> — нет сильверлайт забрасываем, "HTML5 is the way to go"
ЕА>> задолбали, и ладно если раньше избавлялись от того что реально устарело, типа VB6, то теперь технологии не только устареть, но даже заматереть не успевают
H>Ну так ведь от дотнета никто не отказывается, вроде Ну не напишут следующую винду на нем, но прикладникам-то не пофигу ли?
не пофигу, платформа должна развиваться и поддерживаться — иначе твое приложение в будущем не сможет использовать какие-нидь плюшки типа тач-скрина или 64бит, а это может быть критично, и заранее этого не предусмотришь, а все переписывать — это очень дорого, а иногда не реально дорого
оно конечно понятно, что любая платформа рано или поздно перестает развиваться, но писать новое приложения на уже закапываемой платформе это, с точки зрения менеджмента, безумие
ЕА>> H> Но только пользователи Борланда его кончины на себе не ощутили, т.к. продукты были выкуплены новой компанией и получили нехилый импульс в развитие. И эта компания постепенно делает то, чего от Борланда все ждали очень давно, но так и не дождались.
ЕА>> знаю таких не ощутивших, ждавших по несколько лет 64-битный компилятор (выход которого откладывали не знаю сколько раз на моей памяти), а потом переписавших свои приложения на Си++, а также других не ощутивших, которые до сих пор ждут
H>64 бита очень мало кому нужны, особенно в том секторе куда направлены основные усилия разработчиков дельфей. Любой софт не требующий интеграции с 64битной ОС выгоднее делать 32-битным, это же очевидно Впрочем, тем кто ждет, ждать осталось не долго. В сентябре будет 64-битный компилятор и компилятор под МакОС.
ага, не прошло и 10 лет. или прошло
некоторым по-зарез были нужны — я особо не вникал, но насколько я помню, речь шла о интеграции в експлорер в 64-битной винде и подобных вещах
Здравствуйте, c-smile, Вы писали:
CS>Здравствуйте, Евгений Акиньшин, Вы писали:
CS>>>Ну и потом... UI и сервер исповедуют настолько разные парадигмы что объять их одним языком нереально. Что-то пострадает. CS>>>Скажем jQuery как DSL для UI как-то более симпатичнее выглядит чем километровые конструкции на C#. CS>>>html более высокоуровневый язык чем XAML. CSS как язык описания стилей ... короче стилям XAMLа до него как до луны.
ЕА>>ну да, конечно, отсутствие возможности создавать свои визуальные элементы, биндингов, отсутсвии lookless контролов, графических трансформаций, универсального механизма раскладки элементов с возможностью создания своих контейнеров, единого механизма для отображения векторной графики, движка для декларативной анимации, MarkUp Extensitions, DataTemplates итд. автоматически делает Html более высокуровневым языком — даже не смешно
CS>Ты немного отстал от технлогий как я понимаю.
CS>Это вот тебе декларативные transition и animation: http://www.w3.org/TR/css3-transitions/http://www.w3.org/TR/css3-animations/ CS>Это вот декларативные transformations: http://www.w3.org/TR/css3-2d-transforms/ CS>"механизм для отображения векторной графики" есть <canvas>, простой аки двери. CS>Про DataTemplates ... вот тебе https://developer.mozilla.org/en/JavaScript_templates на любой вкус. И это далеко не все. CS>Про биндинг и templates вот например: http://knockoutjs.com/documentation/template-binding.html
видел я все это, я как раз этот вопрос изучаю, но как-то с моей точки зрения это редкий зоопарк (ключевое слово "на любой вкус"), без какой-то единой идеологии, все с разным синтаксисом, без поддержки тулзами — для разработки в команде это пипец, я могу в вакансии разраба написать "Silverlight", а "на любой вкус" не могу
опять же где это применяется все? На сайте того же нокаута я ни одной ссылки на реальные приложения не нашел, только примеры в стиле Hello World
CS>Ну как тебе сказать. У нас в городе количество BMW и Mercedes наверное превышает количество любых других марок взятых отдельно.
хорошо живете
CS>Но тем не менее единственный способ сделать систему которой смогут пользоваться все жители это WebUI. Ибо соотношение MacPC и WinPC примерно 50/50.
но это ты загнул, по всем пузомеркам у виндовса пока процентов 90, хотя доля падает, это да
CS>Короче: ты можешь "об-дата-биндиться" весь но если твоя система не работает на iPhone то в городе Richmond у тебя шансов нет.
Здравствуйте, Евгений Акиньшин, Вы писали:
ЕА> H>Ну так ведь от дотнета никто не отказывается, вроде Ну не напишут следующую винду на нем, но прикладникам-то не пофигу ли?
ЕА> не пофигу, платформа должна развиваться и поддерживаться — иначе твое приложение в будущем не сможет использовать какие-нидь плюшки типа тач-скрина или 64бит, а это может быть критично, и заранее этого не предусмотришь, а все переписывать — это очень дорого, а иногда не реально дорого
Ну так ведь дотнет не хоронят Сильверлайт обретает крышу WP7, насколько я понимаю, то есть развивать его, вроде как, должны
ЕА> оно конечно понятно, что любая платформа рано или поздно перестает развиваться, но писать новое приложения на уже закапываемой платформе это, с точки зрения менеджмента, безумие
А, что, не безумие подсаживаться на технологию выступающую в роли догоняющей на сформированном рынке и имеющей нехилого конкурента в виде Flash/Flex/AIR? Или это слепая вера в могучего и ужасного? ЕА> H>64 бита очень мало кому нужны, особенно в том секторе куда направлены основные усилия разработчиков дельфей. Любой софт не требующий интеграции с 64битной ОС выгоднее делать 32-битным, это же очевидно Впрочем, тем кто ждет, ждать осталось не долго. В сентябре будет 64-битный компилятор и компилятор под МакОС.
ЕА> ага, не прошло и 10 лет. или прошло
Windows XP 64bit вышла в 2003 году. 2011 — 2003 = 8 лет
ЕА> некоторым по-зарез были нужны — я особо не вникал, но насколько я помню, речь шла о интеграции в експлорер в 64-битной винде и подобных вещах
Здравствуйте, TK, Вы писали: TK>Из принципиалных отличий — "замыленные" шрифты на десктопе.
Мой косяк — опера перехватывает ctrl+колёсико и сама масштабирует контент.
Скрытый текст
так немного лучше, но всё равно далеко от идеала. WPF в том плане поприятней будет. TK>Всего остального в вебе — вагон и маленькая тележка.
Ок, покажете хоть одно юзабельное приложение на чистом html/js?
Re[11]: No mention of either Silverlight or .NET on Windows
Здравствуйте, hattab, Вы писали:
H>А тормозящий курсор мыши в сильверлайт версии надо?
Не надо. Подозреваю, они мухлюют с курсором для того, чтобы выводить красивые картинки при наведении на блоки — остальной сервелат-софт таких глюков не имеет. ССЗБ, короче.
Re[12]: No mention of either Silverlight or .NET on Windows
Здравствуйте, Sinix, Вы писали:
S>Здравствуйте, hattab, Вы писали:
H>>А тормозящий курсор мыши в сильверлайт версии надо? S>Не надо. Подозреваю, они мухлюют с курсором для того, чтобы выводить красивые картинки при наведении на блоки — остальной сервелат-софт таких глюков не имеет. ССЗБ, короче.
так в сильверлайте сцуко нету кастомных курсоров — вот и пришлось мне так сделать
Здравствуйте, c-smile, Вы писали:
CS>HTML/CSS/JS наше всё теперь опять.
все-таки надо быть очень нездоровым на голову человеком, чтобы предлагать променять тот же WPF/SilverLight на уродство JS... но с микрософта станется..
я всегда был виндовым человеком, но вот сейчас (если это окажется правдой), однозначно перейду, не знаю на что, но перейду.
маскарад технологий реально уже затрахал. Метания — признак отсутствия стратегии и/или воли и начало конца.
In P=NP we trust.
Re[13]: No mention of either Silverlight or .NET on Windows
Здравствуйте, Евгений Акиньшин, Вы писали:
ЕА>так в сильверлайте сцуко нету кастомных курсоров — вот и пришлось мне так сделать
grapholite — ваш софт? Решпект!
ЕА>а в html можно курсор подменить?
Гугль уверяет что можно. Сам не баловался.
Re[14]: No mention of either Silverlight or .NET on Windows
Здравствуйте, Sinix, Вы писали:
S>Здравствуйте, Евгений Акиньшин, Вы писали:
ЕА>>так в сильверлайте сцуко нету кастомных курсоров — вот и пришлось мне так сделать S>grapholite — ваш софт? Решпект!
ЕА>>а в html можно курсор подменить? S>Гугль уверяет что можно. Сам не баловался.
Надо же, и правда работает
Все таки, как не грустно это признавать, в сильверлайте много таких недоделок, особенно форматированный текст расстраивает — редкое убожество, если его развивать не будут, то и правда смысла писать на нем приложения не будет
Здравствуйте, Sinix, Вы писали:
S>так немного лучше, но всё равно далеко от идеала. WPF в том плане поприятней будет.
WPF в вебе?
TK>>Всего остального в вебе — вагон и маленькая тележка. S>Ок, покажете хоть одно юзабельное приложение на чистом html/js?
Не нравится вам google docs — посмотрите на Microsoft office online. В остальном, градиентные картинки, риббон и пару скроллеров для этого, что теперь нужен SL?
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Re[13]: No mention of either Silverlight or .NET on Windows
Здравствуйте, TK, Вы писали:
TK>Не нравится вам google docs — посмотрите на Microsoft office online. В остальном, градиентные картинки, риббон и пару скроллеров для этого, что теперь нужен SL?
Клиент — это не только UI. Офис Онлайн полностью на JavaScript?
Re[14]: No mention of either Silverlight or .NET on Windows
Здравствуйте, MxMsk, Вы писали:
TK>>Не нравится вам google docs — посмотрите на Microsoft office online. В остальном, градиентные картинки, риббон и пару скроллеров для этого, что теперь нужен SL? MM>Клиент — это не только UI. Офис Онлайн полностью на JavaScript?
HTML5 и JS это в первую очередь именно UI. Или вы собрались на SL бизнес-логику и научные расчеты писать?
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Re[15]: No mention of either Silverlight or .NET on Windows
Здравствуйте, Евгений Акиньшин, Вы писали:
ЕА>>>а в html можно курсор подменить? S>>Гугль уверяет что можно. Сам не баловался.
ЕА>Надо же, и правда работает
Но, как обычно, не везде. В IE 9 нормально, в FF 4.0 не пашет hand, сustom mouse pointers и сustom сursor to table Cells. Chrome 11 не пашет "target" cursor. Ручаюсь, что у других версий и Оперы свой неповторимый набор глюков.
А так — да, всё отлично работает, полная кроссплатформеность и удобство разарботки.
Re[15]: No mention of either Silverlight or .NET on Windows
Здравствуйте, TK, Вы писали:
MM>>Клиент — это не только UI. Офис Онлайн полностью на JavaScript? TK>HTML5 и JS это в первую очередь именно UI. Или вы собрались на SL бизнес-логику и научные расчеты писать?
Я имел ввиду толстый клиент. И в UI приходится делать расчеты. Например, для графиков железнодорожной работы — там много всякой специфики — что, где и как рисовать. Это только UI, но он далеко не тривиальный. И зная, сколько нам сейчас приходится делать в коде на C#, мне страшно представить, какой это будет гемороище на JS.
Re[2]: No mention of either Silverlight or .NET on Windows 8
Здравствуйте, Deprivator, Вы писали:
D>маскарад технологий реально уже затрахал. Метания — признак отсутствия стратегии и/или воли и начало конца.
а ишак всё не дохет...
Re[15]: No mention of either Silverlight or .NET on Windows
Здравствуйте, TK, Вы писали:
TK>Здравствуйте, MxMsk, Вы писали:
TK>>>Не нравится вам google docs — посмотрите на Microsoft office online. В остальном, градиентные картинки, риббон и пару скроллеров для этого, что теперь нужен SL? MM>>Клиент — это не только UI. Офис Онлайн полностью на JavaScript?
TK>HTML5 и JS это в первую очередь именно UI. Или вы собрались на SL бизнес-логику и научные расчеты писать?
ну как бы с HTML5 продвигается идея оффлайновых HTML приложений.
и да, SL хорош именно тем, что можно очень многое в случае необходимости с сервера на клиент перебросить — зачем делать задержку и нагружать сервак, если все необходимые данные на клиенте уже есть
ну вот например отображение сводных таблиц — вполне типичная задача для UI бизнес приложений, какой смысл делать round trip на сервер, если хочется отфильтровать уже загруженные данные? Но чтобы это сделать надо иметь упрощенный Олап движок на клиенте. На сильверлайте я просто серверный код скопирую, если он нормально написан — а что делать в вебе? переписать весь движок заново да еще на ява-скрипте? увольте-с
Здравствуйте, LGB, Вы писали:
CS>>HTML/CSS/JS наше всё теперь опять. LGB>Шо, опять?! (с) LGB>А хранимые процедуры в SQL Server будут тоже теперь на HTML/JS? %-)
Мелко берете. С таким подходом скоро сам MS SQL Server будет на JS написан, а данные хранить станет исключительно в XML. Это ведь модно, а железо и так слишком быстрое.
а кстати, раз уж зашла речь, кто подскажет отставшему от технологий, каким редактором можно "мультик" нарисовать c использованием svg,html и этих самых стилей. И вообще оно с svg совместимо, т.е. если мне надо одновременно и html и svg анимировать я могу это как-то единнообразно делать?
Здравствуйте, Евгений Акиньшин, Вы писали:
ЕА>ну как бы с HTML5 продвигается идея оффлайновых HTML приложений.
И это правильная идея. Возьмите любой планшет — у кого из них "батарейка не ресурс"? Браузер и JS это практически основной use-case использоватния планшета — HTML/JS движки скорее всего уже загружены в память и отображение еще одной HTML страницы достаточно дешево. А вот от SL/WPF/.NET Runtime вполне можно и отказаться — не всем и не всегда оно надо.
ЕА>ну вот например отображение сводных таблиц — вполне типичная задача для UI бизнес приложений, какой смысл делать round trip на сервер, если хочется отфильтровать уже загруженные данные? Но чтобы это сделать надо иметь упрощенный Олап движок на клиенте. На сильверлайте я просто серверный код скопирую, если он нормально написан — а что делать в вебе? переписать весь движок заново да еще на ява-скрипте? увольте-с
Если приложение на десктопе то, HTML занимается рендерингом (для рендеренга хитрых элементов он легко расширяется на любом доступном языке) JS — манипуляция DOM, простой интерфейс к UI модели, а бизнес логика реализуется хоть C++ хоть на .NET. В итоге, каждый занимается тем, для чего предназначен.
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Re[16]: No mention of either Silverlight or .NET on Windows
Здравствуйте, MxMsk, Вы писали:
MM>Я имел ввиду толстый клиент. И в UI приходится делать расчеты. Например, для графиков железнодорожной работы — там много всякой специфики — что, где и как рисовать. Это только UI, но он далеко не тривиальный. И зная, сколько нам сейчас приходится делать в коде на C#, мне страшно представить, какой это будет гемороище на JS.
Толстый клиент замечательно пишется на толстом .net зачем там обязательно SL? только ради его ограничений?
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Re[7]: No mention of either Silverlight or .NET on Windows 8
Здравствуйте, TK, Вы писали:
MM>>Я имел ввиду толстый клиент. И в UI приходится делать расчеты. Например, для графиков железнодорожной работы — там много всякой специфики — что, где и как рисовать. Это только UI, но он далеко не тривиальный. И зная, сколько нам сейчас приходится делать в коде на C#, мне страшно представить, какой это будет гемороище на JS. TK>Толстый клиент замечательно пишется на толстом .net зачем там обязательно SL? только ради его ограничений?
Затем, что одно и то же приложение могло бы идти на разных устройствах. И все слои этого приложения могли бы быть написаны на одном языке с полным доступом к фичам .Net.
Re[18]: No mention of either Silverlight or .NET on Windows
Здравствуйте, MxMsk, Вы писали:
TK>>Толстый клиент замечательно пишется на толстом .net зачем там обязательно SL? только ради его ограничений? MM>Затем, что одно и то же приложение могло бы идти на разных устройствах. И все слои этого приложения могли бы быть написаны на одном языке с полным доступом к фичам .Net.
Судя потому, что тут moonlight остановился на версии 2... Какие у вас есть устройства кроме windows и возможно mac'а? И непонятно, какой у вас полный доступ к фичам .net из SL?
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Re[17]: No mention of either Silverlight or .NET on Windows
Здравствуйте, TK, Вы писали:
TK>Здравствуйте, MxMsk, Вы писали:
MM>>Я имел ввиду толстый клиент. И в UI приходится делать расчеты. Например, для графиков железнодорожной работы — там много всякой специфики — что, где и как рисовать. Это только UI, но он далеко не тривиальный. И зная, сколько нам сейчас приходится делать в коде на C#, мне страшно представить, какой это будет гемороище на JS.
TK>Толстый клиент замечательно пишется на толстом .net зачем там обязательно SL? только ради его ограничений?
— простой деплоймент, прилога гарантированно в sandbox и не оставит следов на компьютере. в ссылку я без проблем в любую ткну. а инсталлировать\деинсталлировать ну нафиг, три раза подумаю почистит инсталляшка за собой все корректно или нет
— кросс-платформенность на десктопе, не забываем что Mac это теперь солидная доля рынка
— реализация сценариев типа — кинул клиенту ссылку на отчет в скайпе или по мылу, он по ней ткнул и все что надо увидел. Особенно если для конкретный человек не собирается постоянно этим пользоваться, но показать ему надо
Здравствуйте, Евгений Акиньшин, Вы писали:
ЕА>- простой деплоймент, прилога гарантированно в sandbox и не оставит следов на компьютере. в ссылку я без проблем в любую ткну. а инсталлировать\деинсталлировать ну нафиг, три раза подумаю почистит инсталляшка за собой все корректно или нет ЕА>- кросс-платформенность на десктопе, не забываем что Mac это теперь солидная доля рынка ЕА>- реализация сценариев типа — кинул клиенту ссылку на отчет в скайпе или по мылу, он по ней ткнул и все что надо увидел. Особенно если для конкретный человек не собирается постоянно этим пользоваться, но показать ему надо
1. Браузер оно тоже как бы гарантированно sandbox И если SL нет то, кто его будет ставить/потом чистить?
2. Планшеты/телефоны это больше не доля рынка?
3. А потом еще рассказал как ему до этого отчета добраться... Ссылок с отчетами PDF рулит
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Re[19]: No mention of either Silverlight or .NET on Windows
Здравствуйте, TK, Вы писали:
TK>Судя потому, что тут moonlight остановился на версии 2... Какие у вас есть устройства кроме windows и возможно mac'а? И непонятно, какой у вас полный доступ к фичам .net из SL?
Да не, на устройства других производителей я не смотрю. Та же Винда разделится на три вида: десктоп, ВинФон, планшет. И у каждой своя технология UI: WPF/WinForms, SL, JS соответственно. Мне это не нравится. А ведь .Net в свое время позиционировался в том числе, как средство, которое сможет работать везде с "правильным" JIT-ом.
Re[19]: No mention of either Silverlight or .NET on Windows
Здравствуйте, TK, Вы писали:
TK>Здравствуйте, Евгений Акиньшин, Вы писали:
ЕА>>- простой деплоймент, прилога гарантированно в sandbox и не оставит следов на компьютере. в ссылку я без проблем в любую ткну. а инсталлировать\деинсталлировать ну нафиг, три раза подумаю почистит инсталляшка за собой все корректно или нет ЕА>>- кросс-платформенность на десктопе, не забываем что Mac это теперь солидная доля рынка ЕА>>- реализация сценариев типа — кинул клиенту ссылку на отчет в скайпе или по мылу, он по ней ткнул и все что надо увидел. Особенно если для конкретный человек не собирается постоянно этим пользоваться, но показать ему надо
TK>1. Браузер оно тоже как бы гарантированно sandbox И если SL нет то, кто его будет ставить/потом чистить?
все это имеет смысл если плагин почти у всех стоит — в этом-то главная проблема и есть
TK>2. Планшеты/телефоны это больше не доля рынка?
не всегда это актуально, есть вещи которые почти невозможно на них делать из-за размеров экрана и отсутсвия средств ввода
TK>3. А потом еще рассказал как ему до этого отчета добраться... Ссылок с отчетами PDF рулит
интерактивный отчет, который покрутить можно
ну вот например, Expression SketchFlow — делаешь черновик приложения, причем там все элементы могут быть живыми и посылаешь клиенту линк. Клиент по линку заходит и прямо поверх приложения пишет и рисует свои комментарии, чего куда передвинуть итд.
Здравствуйте, Евгений Акиньшин, Вы писали:
TK>>2. Планшеты/телефоны это больше не доля рынка?
ЕА>не всегда это актуально, есть вещи которые почти невозможно на них делать из-за размеров экрана и отсутсвия средств ввода
А каких там средств ввода не хватает? Клавиатура есть, мышка условно есть, камера/микрофон есть.
TK>>3. А потом еще рассказал как ему до этого отчета добраться... Ссылок с отчетами PDF рулит ЕА>интерактивный отчет, который покрутить можно
Возможно. с другой стороны, если отчет такой интерактивный то, почему он себе его сам не сделает... Если же времени нет, то и крутить его скорее всего никто не будет.
ЕА>ну вот например, Expression SketchFlow — делаешь черновик приложения, причем там все элементы могут быть живыми и посылаешь клиенту линк. Клиент по линку заходит и прямо поверх приложения пишет и рисует свои комментарии, чего куда передвинуть итд.
для "толстого" приложения можно просто конференцию устроить и лично обсудить — подобная коммуникация бывает более эффективной чем вопрос/ответ.
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Re[20]: No mention of either Silverlight or .NET on Windows
Здравствуйте, MxMsk, Вы писали:
MM>Да не, на устройства других производителей я не смотрю. Та же Винда разделится на три вида: десктоп, ВинФон, планшет. И у каждой своя технология UI: WPF/WinForms, SL, JS соответственно. Мне это не нравится. А ведь .Net в свое время позиционировался в том числе, как средство, которое сможет работать везде с "правильным" JIT-ом.
А будет доступна единая технология: HTML5 + JS
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
After a first tip this week on Microsoft’s Jupiter — a new “application model” for Windows 8 — I started nosing around to learn more about this mysterious new Microsoft codename.
Jupiter is going to be a new user interface (UI) library for Windows, built alongside Windows 8. It will be a thin XAML/UI layer on top of Windows application programming interfaces and frameworks for subsystems like graphics, text and input. The idea is Jupiter will bring support for smoother and more fluid animation, rich typography, and new media capabilities to Windows 8 devices. (Not surprisingly, the more fluid UI capabilities also are on the feature set list for Silverlight 5.)
Re[21]: No mention of either Silverlight or .NET on Windows
ЕА>>не всегда это актуально, есть вещи которые почти невозможно на них делать из-за размеров экрана и отсутсвия средств ввода
TK>А каких там средств ввода не хватает? Клавиатура есть, мышка условно есть, камера/микрофон есть.
ну как нидь на досуге попробуй попрограмировать на телефоне или дизайном позаниматься, можно на jscript и html
TK>>>3. А потом еще рассказал как ему до этого отчета добраться... Ссылок с отчетами PDF рулит ЕА>>интерактивный отчет, который покрутить можно
TK>Возможно. с другой стороны, если отчет такой интерактивный то, почему он себе его сам не сделает... Если же времени нет, то и крутить его скорее всего никто не будет.
ЕА>>ну вот например, Expression SketchFlow — делаешь черновик приложения, причем там все элементы могут быть живыми и посылаешь клиенту линк. Клиент по линку заходит и прямо поверх приложения пишет и рисует свои комментарии, чего куда передвинуть итд.
TK>для "толстого" приложения можно просто конференцию устроить и лично обсудить — подобная коммуникация бывает более эффективной чем вопрос/ответ.
угу, именно поэтому средства для черновиков интерфейсов так популярны, тут человек может с реальным интерфесом в живую поиграть и стрелочками нарисовать что изменить и ему для этого у себя ничего ставить не надо
Здравствуйте, Евгений Акиньшин, Вы писали:
TK>>А каких там средств ввода не хватает? Клавиатура есть, мышка условно есть, камера/микрофон есть.
ЕА>ну как нидь на досуге попробуй попрограмировать на телефоне или дизайном позаниматься, можно на jscript и html
Уж написать письмо/прочитать документ/сделать заметок — какие проблемы? На десктопах-то программируют и занимаются дизайном считаные единицы
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Re[3]: No mention of either Silverlight or .NET on Windows 8
Здравствуйте, blackhearted, Вы писали:
D>>маскарад технологий реально уже затрахал. Метания — признак отсутствия стратегии и/или воли и начало конца. B>а ишак всё не дохет...
серьезные метания у MS начались относительно недавно.. так что вполне может сдохнуть.. просто ишак больно жирный, инерция большая.
In P=NP we trust.
Re[5]: No mention of either Silverlight or .NET on Windows 8
Здравствуйте, c-smile, Вы писали:
IT>>.NET — наше всё! И никуда он не денется.
CS>С серверов — да, никуда не денется. Там ему хорошо и там он хорош. CS>Но вопрос то про клиентскую ось. HTML/CSS/Script/Ajax по многим причинам более приемлем для UI business систем.
Причина по сути одна — лёгкий деплоймент. Зато и недостатков выше крыши. На скриптах получаются дешёвые быстрые одноразовые решения, но часто меняющиеся задачи требующие постоянной адаптации под бизнес получаются довольно дорогими.
Если нам не помогут, то мы тоже никого не пощадим.
Re[6]: No mention of either Silverlight or .NET on Windows 8
Здравствуйте, IT, Вы писали:
CS>>С серверов — да, никуда не денется. Там ему хорошо и там он хорош. CS>>Но вопрос то про клиентскую ось. HTML/CSS/Script/Ajax по многим причинам более приемлем для UI business систем.
IT>Причина по сути одна — лёгкий деплоймент. Зато и недостатков выше крыши. На скриптах получаются дешёвые быстрые одноразовые решения, но часто меняющиеся задачи требующие постоянной адаптации под бизнес получаются довольно дорогими.
С моей — кроссплатформенность — уже две набралось
Re[6]: No mention of either Silverlight or .NET on Windows 8
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, c-smile, Вы писали:
IT>>>.NET — наше всё! И никуда он не денется.
CS>>С серверов — да, никуда не денется. Там ему хорошо и там он хорош. CS>>Но вопрос то про клиентскую ось. HTML/CSS/Script/Ajax по многим причинам более приемлем для UI business систем.
IT>Причина по сути одна — лёгкий деплоймент. Зато и недостатков выше крыши. На скриптах получаются дешёвые быстрые одноразовые решения, но часто меняющиеся задачи требующие постоянной адаптации под бизнес получаются довольно дорогими.
а кстати как уважаемые участники обсуждения относятся к средствам автоматической генерации jscript на основе типизированного кода? Типа GWT для Java или Script# для Нета?
Или вот например ссылка проскакивала
на первый взгляд вполне рабочий подход, вроде гугл активно этим пользуется? Собираемся использовать Script# для одного проекта — у него конечно ограничений много, но это все же лучше чем поддерживать jscript. Есть у кого опыт в этом направлении?
Здравствуйте, Евгений Акиньшин, Вы писали:
ЕА>а кстати как уважаемые участники обсуждения относятся к средствам автоматической генерации jscript на основе типизированного кода? Типа GWT для Java или Script# для Нета?
С интересом. В конце концов HTML тоже в основном рендерится, а не руками пишется.
Если нам не помогут, то мы тоже никого не пощадим.
Re: No mention of either Silverlight or .NET on Windows 8
Здравствуйте, IT, Вы писали:
ЕА>>а кстати как уважаемые участники обсуждения относятся к средствам автоматической генерации jscript на основе типизированного кода? Типа GWT для Java или Script# для Нета? IT>С интересом. В конце концов HTML тоже в основном рендерится, а не руками пишется.
Гмм... Код, который компилируется в il, который транслируется в машинный код, который дёргает вспомогательные библиотеки, которые создают html/js что парсится в dom/интерпретируется движком браузера, который вызывает системные библиотеки, которые вызывают kernel-mode код, который дёргает драйвера чтобы наконец вывести "Hello, world!"?
I like it!
Re[9]: No mention of either Silverlight or .NET on Windows 8
Здравствуйте, Sinix, Вы писали:
S>Здравствуйте, IT, Вы писали:
ЕА>>>а кстати как уважаемые участники обсуждения относятся к средствам автоматической генерации jscript на основе типизированного кода? Типа GWT для Java или Script# для Нета? IT>>С интересом. В конце концов HTML тоже в основном рендерится, а не руками пишется.
S>Гмм... Код, который компилируется в il, который транслируется в машинный код, который дёргает вспомогательные библиотеки, которые создают html/js что парсится в dom/интерпретируется движком браузера, который вызывает системные библиотеки, которые вызывают kernel-mode код, который дёргает драйвера чтобы наконец вывести "Hello, world!"?
S>I like it!
изврат конечно, но все лучше чем мантаинить большой проект на скрипте
Здравствуйте, Sharowarsheg, Вы писали:
S>Здравствуйте, c-smile, Вы писали:
CS>>Завершился очередной виток спирали. CS>>http://www.theregister.co.uk/2011/06/06/windows_tablets_without_silverlight_dot_net/ CS>>Вот такие вот дела. Sic transit gloria mundi... CS>>HTML/CSS/JS наше всё теперь опять.
S>Про CreateFileA/W там тоже не говорили. Что ж теперь, и файлов нельзя будет создавать?
Можно. Но только из яваскрипта.
Re[7]: No mention of either Silverlight or .NET on Windows 8
Здравствуйте, c-smile, Вы писали:
CS>Ну и потом... UI и сервер исповедуют настолько разные парадигмы что объять их одним языком нереально. Что-то пострадает. CS>Скажем jQuery как DSL для UI как-то более симпатичнее выглядит чем километровые конструкции на C#.
Я вот тут имел удовольствие попилить проект с гуем полностью на jQuery, включая гриды , такое ощущение, что вернулся лет на 15 назад во времена Borland C++ 3. Так что все хорошо в меру.
... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>
Re[2]: No mention of either Silverlight or .NET on Windows 8
Здравствуйте, yoriсk.kiev.ua, Вы писали:
YKU>А откуда взят сей вывод?
Тем не менее это близко к действительности. Только термин legacy неверный — дотнета там никогда и не было. Точнее был в Лонгхорне, который PDCшный, а не из которого сделали Висту, но все наработки коцнули в полном объеме.
Re[4]: No mention of either Silverlight or .NET on Windows 8
Здравствуйте, Deprivator, Вы писали:
D>серьезные метания у MS начались относительно недавно.
Ровно как Гейтс свалил. Баллмер явно не тянет. Шоу устраивать он умеет, не отнять, а со стратегией у него тухляк. Маленький пример — это кем надо быть, чтобы сделать ланч WP7 без international фич? Причем это не техническое решение, технически WP7 более менее готов уже сейчас, а чисто маркетологическое. Сравните с яблофоном, где русский в iOS был задолго до официальных продаж в России.
nme>Jupiter is going to be a new user interface (UI) library for Windows, built alongside Windows 8. It will be a thin XAML/UI layer on top of Windows application programming interfaces and frameworks for subsystems like graphics, text and input. The idea is Jupiter will bring support for smoother and more fluid animation, rich typography, and new media capabilities to Windows 8 devices. (Not surprisingly, the more fluid UI capabilities also are on the feature set list for Silverlight 5.)
Есть только одно но — Юпитер это не SL, а полностью unmanaged технология (концы скорее всего из MCE растут).
Re[6]: No mention of either Silverlight or .NET on Windows 8
Здравствуйте, hattab, Вы писали:
H>64 бита очень мало кому нужны
Статистика есть? Или мало кому означает лично тебе? Потому как у меня и на прошлой работе и на текущей приложения конкретно упирались в нехватку address space и с этим приходилось много и упорно бороться.
Re[8]: No mention of either Silverlight or .NET on Windows 8
Здравствуйте, c-smile, Вы писали:
CS>Ну и потом... UI и сервер исповедуют настолько разные парадигмы что объять их одним языком нереально. Что-то пострадает. CS>Скажем jQuery как DSL для UI как-то более симпатичнее выглядит чем километровые конструкции на C#.
Можно пример таких километровых конструкций?
CS>Тем не менее количество приложений и бизнесс систем с GUI в browser на порядки превышает все что было создано на Winforms, WPF, etc.
Пруфлинк?
Re[9]: No mention of either Silverlight or .NET on Windows 8
Здравствуйте, Ночной Смотрящий, Вы писали:
НС> H>Ну так ведь дотнет не хоронят Сильверлайт обретает крышу WP7, насколько я понимаю
НС> Сервелат в WP7 не совсем обычный.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС> H>64 бита очень мало кому нужны
НС> Статистика есть? Или мало кому означает лично тебе? Потому как у меня и на прошлой работе и на текущей приложения конкретно упирались в нехватку address space и с этим приходилось много и упорно бороться.
Статистики нет, есть реальность. За все время существования 64-битных ОС, количество 64-битного софта не позволяет говорить о какой либо значимости этих самых 64 бит То есть, есть конечно софт, но реально нуждающегося в 64-битах очень и очень мало. А уж нуждающегося настолько, что люди с дельфей перешли на C++ вместо использования FPC, поддерживающего 64-бита, и вовсе кажется мне фантастикой.
Здравствуйте, Sinix, Вы писали:
S>Гмм... Код, который компилируется в il, который транслируется в машинный код, который дёргает вспомогательные библиотеки, которые создают html/js что парсится в dom/интерпретируется движком браузера, который вызывает системные библиотеки, которые вызывают kernel-mode код, который дёргает драйвера чтобы наконец вывести "Hello, world!"?
Хех. Тут ещё пару слоёв можно добавить
Здравствуйте, Евгений Акиньшин, Вы писали:
ЕА>Здравствуйте, Ночной Смотрящий, Вы писали:
НС>>Есть только одно но — Юпитер это не SL, а полностью unmanaged технология (концы скорее всего из MCE растут).
ЕА>а в сильверлайте можно подумать много managed кода тоже если разобраться практически нативный продукт
Точно так же как и браузер — "практически нативный продукт".
Re[3]: No mention of either Silverlight or .NET on Windows 8
Здравствуйте, c-smile, Вы писали:
DD>>Перестаньте создавать панику без причины. CS>Панику по определению "создать" нельзя. Её можно "вызвать". CS>Мопед — не мой, я просто о нем написал. Но если найдется критическая масса людей не уверенных в данной технологии то возникнет паника, да. CS>Я к образованию этой массы людей не имею никакого отношения.
.NET в первую очередь рулит в корпоративной среде. Он там поселился довольно прочно и никуда не собирается. Проблем там никаких с использованием .NET нет. Сейчас можно лишь говорить о том, что надежды "большевиков" на то, что некая новая Windows будет написана на .NET пока не оправдались. Ну, честно говоря, мне в это в любом случае верилось слабо.
А то, что в желтой прессе из этого делают какие-то далеко идущие выводы... Ну оставим это на их совести.
CS>Ну как тебе сказать. Я был на двух конференциях Microsoft. На обоих вещал Don Box: на первой COM это наше всё, на второй он же и теми же словами — NET наше всё теперь. Смотрю на последние W7 API, скажем Direct2D/Write, это COM alike интерфейсы — т.е. на круги своя возвращаемся переосмыслив (в последнее хочется верить). Если тебе так не кажется то я не настаиваю на том. Но мнение свё имею право высказать, да?
Мнение высказать всегда полезно, вот только ты его, к сожалению, не высказал.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Есть только одно но — Юпитер это не SL, а полностью unmanaged технология (концы скорее всего из MCE растут).
Есть ссылка?
Re[5]: No mention of either Silverlight or .NET on Windows 8
Здравствуйте, c-smile, Вы писали:
CS>HTML/CSS/Script/Ajax по многим причинам более приемлем для UI business систем.
Ну во-первых эти умные слова и так в бизнес-системах, скажем так, примелькаются. Во-вторых, не более приемлем на самом деле. Хотя бы потому что тот же Сильверлайт предоставляет более rapid средства для разработки, он проще для дотнетчиков, позволяет пользоваться львиной долей фреймворка, имеет множество готовых ГУИ-решений в рамках своих тулкитов и пр.
nme>Jupiter is going to be a new user interface (UI) library for Windows, built alongside Windows 8. It will be a thin XAML/UI layer on top of Windows application programming interfaces and frameworks for subsystems like graphics, text and input. The idea is Jupiter will bring support for smoother and more fluid animation, rich typography, and new media capabilities to Windows 8 devices. (Not surprisingly, the more fluid UI capabilities also are on the feature set list for Silverlight 5.)
Заяц — это не только ценный мех managed на xaml-е не заканчивается. И что-то меня ни разу не вдохновляют костыли взамен new Application.Run(new AppWindow());
Здравствуйте, nme, Вы писали:
FR>>XAML уже сейчас MS активно внедряет в WinAPI и соответственно в нативные приложения, например http://msdn.microsoft.com/en-us/library/dd316924(v=VS.85).aspx
nme>Я думаю, это хорошие новости для тех, кто занимается SL и WPF.
Здравствуйте, Sinix, Вы писали:
FR>>XAML уже сейчас MS активно внедряет в WinAPI и соответственно в нативные приложения, например http://msdn.microsoft.com/en-us/library/dd316924(v=VS.85).aspx
S>Заяц — это не только ценный мех managed на xaml-е не заканчивается. И что-то меня ни разу не вдохновляют костыли взамен new Application.Run(new AppWindow());
Да ладно в C++ нормальных фреймфорках (например QT) оно примерно так же и выглядит.
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, Sinix, Вы писали:
FR>>>XAML уже сейчас MS активно внедряет в WinAPI и соответственно в нативные приложения, например http://msdn.microsoft.com/en-us/library/dd316924(v=VS.85).aspx
S>>Заяц — это не только ценный мех managed на xaml-е не заканчивается. И что-то меня ни разу не вдохновляют костыли взамен new Application.Run(new AppWindow());
FR>Да ладно в C++ нормальных фреймфорках (например QT) оно примерно так же и выглядит.
там есть GC?? Или на подсчете ссылок?? если второе — то не катит. Совсем.
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, nme, Вы писали:
FR>>>XAML уже сейчас MS активно внедряет в WinAPI и соответственно в нативные приложения, например http://msdn.microsoft.com/en-us/library/dd316924(v=VS.85).aspx
nme>>Я думаю, это хорошие новости для тех, кто занимается SL и WPF.
FR>Там же C++.
Здравствуйте, Jack128, Вы писали:
FR>>Да ладно в C++ нормальных фреймфорках (например QT) оно примерно так же и выглядит.
J>там есть GC?? Или на подсчете ссылок??
Там нет GC и не обязательно подсчет ссылок, но все вменяемые C++ GUI библиотеки полностью
автоматически управляют памятью.
J>если второе — то не катит. Совсем.
Почему?
Re[8]: No mention of either Silverlight or .NET on Windows 8
Здравствуйте, hattab, Вы писали:
H>Статистики нет, есть реальность. За все время существования 64-битных ОС, количество 64-битного софта не позволяет говорить о какой либо значимости этих самых 64 бит
Вынужден был при недавнем апгрейде поставить х64. И, что характерно, абсолютно весь софт, который мне нужен есть в х64 версии. Кроме студии, увы.
H> То есть, есть конечно софт, но реально нуждающегося в 64-битах очень и очень мало.
Реально, нереально, а доля установленных х64 ОС постоянно растет. Особенно на серверах, там 32 бита уже редкость.
Здравствуйте, Евгений Акиньшин, Вы писали:
НС>>Есть только одно но — Юпитер это не SL, а полностью unmanaged технология (концы скорее всего из MCE растут).
ЕА>а в сильверлайте можно подумать много managed кода тоже если разобраться практически нативный продукт
Почти все библиотеки и весь прикладной код — managed.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Здравствуйте, nme, Вы писали:
nme>>>>Изучение SL/WPF это в первую очередь XAML.
НС>>>Это кому как.
nme>>А что там ещё нового если уже WinForms знаешь?
НС>А при чем тут новое?
Люди обычно изучают, то чего ещё не знают..
Re[4]: No mention of either Silverlight or .NET on Windows 8
Здравствуйте, IT, Вы писали:
IT>Больше всего в этой статье поражает непонимание автором одной простой вещи — для решения каждой конкретной задачи нужно выбирать наиболее подходящий инструмент. OS нужно писать на C++, а ещё лучше на C.
Зачем на С? При грамотном знании С++ можно писать не менее производительный код, чем на С с меньшими трудозатратами.
Здравствуйте, nme, Вы писали:
nme>А что там ещё нового если уже WinForms знаешь?
Не столько новое, сколько другой подход, начиная от свойств и лэйаута и заканчивая композицией контролов.
Re[9]: No mention of either Silverlight or .NET on Windows 8
Здравствуйте, Ночной Смотрящий, Вы писали:
НС> H>Статистики нет, есть реальность. За все время существования 64-битных ОС, количество 64-битного софта не позволяет говорить о какой либо значимости этих самых 64 бит
НС> Вынужден был при недавнем апгрейде поставить х64. И, что характерно, абсолютно весь софт, который мне нужен есть в х64 версии. Кроме студии, увы.
У меня апгрейд на 64-битную ОС случился летом 2009 года. До сих пор практически весь софт, что у меня установлен, 32-битный. То есть обычно есть выбор какой инсталлятор качать, но некоторое время повозившись и с 32 и с 64 битными версиями одного и то же софта можно легко прийти к выводу, что никаких бенефитов от 64 бит эндюзер не получает. Ну а если разработчик дает возможность использовать 32-битные версии при наличии 64-битных, значит не так уж и важны для него эти 64 бита, раз не дали отказаться от 32-битных версий. А вот чего мне не встречалось, так это 64-бит-only софта. То есть, сегодня, 64 бита ближе к маркетингу, чем к реальным потребностям
НС> H> То есть, есть конечно софт, но реально нуждающегося в 64-битах очень и очень мало.
НС> Реально, нереально, а доля установленных х64 ОС постоянно растет. Особенно на серверах, там 32 бита уже редкость.
Рост доли 64-битных ОС объясним, при нынешних то объемах памяти. Но это совсем не означает, что софту, в массе своей, нужны 64 бита. Наверняка и среди 32-битного софта, лишь малая часть собирается с указанием на использование 4Gb адресного пространства под 64-битными ОС.
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, Jack128, Вы писали:
FR>>>Да ладно в C++ нормальных фреймфорках (например QT) оно примерно так же и выглядит.
J>>там есть GC?? Или на подсчете ссылок??
FR>Там нет GC и не обязательно подсчет ссылок, но все вменяемые C++ GUI библиотеки полностью FR>автоматически управляют памятью.
J>>если второе — то не катит. Совсем.
FR>Почему?
потому что циклические ссылки придется руками разруливать.
Re[10]: No mention of either Silverlight or .NET on Windows
Здравствуйте, nme, Вы писали:
nme>Тут вопрос в том какая часть WPF будет использована в Jupiter. Я думаю общий подход, лэйауты и возможно основные контролы останутся теми же.
Не останется. В unmanaged очень тяжело реализовать большую часть концепций wpf. Как минимум с ресурсами и биндингами будет очень много интересных вопросов.
Здравствуйте, FR, Вы писали:
FR>>>Почему? J>>потому что циклические ссылки придется руками разруливать. FR>Не обязательно, например в питоне GC основано на подсчете ссылок + модуль автоматически разруливающий FR>циклические ссылки.
Так мы про GC или про подсчет ссылок? Про Python или про C++?
Здравствуйте, nme, Вы писали:
nme>Есть конкретные примеры когда возникают проблемы?
Для начала — как мы будем их освобождать? Особенно если ресурс помечен x:Shared="false", или на source биндинга никто больше не ссылается, или у нас несколько биндингов по сложному пути (object[0].SomeProp/Prop2).
Здравствуйте, MxMsk, Вы писали:
FR>>Не обязательно, например в питоне GC основано на подсчете ссылок + модуль автоматически разруливающий FR>>циклические ссылки. MM>Так мы про GC или про подсчет ссылок? Про Python или про C++?
Эта техника не явлется питон специфичной и вполне реализуема и на C++.
Мы же про возможность автоматического управления ресурсами и памятью для GUI библиотек на C++.
Здравствуйте, FR, Вы писали:
FR>Эта техника не явлется питон специфичной и вполне реализуема и на C++. FR>Мы же про возможность автоматического управления ресурсами и памятью для GUI библиотек на C++.
Ну, вот когда реализуешь, тогда и поговорим
Здравствуйте, MxMsk, Вы писали:
FR>>Мы же про возможность автоматического управления ресурсами и памятью для GUI библиотек на C++. MM>Ну, вот когда реализуешь, тогда и поговорим
Все очень давно украдено до нас, практически все живые сейчас C++ GUI библиотеки автоматически управляют ресурсами.
Здравствуйте, FR, Вы писали:
FR>Все очень давно украдено до нас, практически все живые сейчас C++ GUI библиотеки автоматически управляют ресурсами.
Они это могут делать только в рамках себя самих. Допустим, я беру ссылку на какой-нить контрол, а потому выкидываю этот контрол из родительского. Кто им управит?
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, MxMsk, Вы писали:
FR>>>Мы же про возможность автоматического управления ресурсами и памятью для GUI библиотек на C++. MM>>Ну, вот когда реализуешь, тогда и поговорим
FR>Все очень давно украдено до нас, практически все живые сейчас C++ GUI библиотеки автоматически управляют ресурсами.
Здравствуйте, MxMsk, Вы писали:
FR>>Все очень давно украдено до нас, практически все живые сейчас C++ GUI библиотеки автоматически управляют ресурсами. MM>Они это могут делать только в рамках себя самих. Допустим, я беру ссылку на какой-нить контрол, а потому выкидываю этот контрол из родительского. Кто им управит?
Новый родитель.
Re[11]: No mention of either Silverlight or .NET on Windows
Здравствуйте, FR, Вы писали:
FR>>>Все очень давно украдено до нас, практически все живые сейчас C++ GUI библиотеки автоматически управляют ресурсами. MM>>Они это могут делать только в рамках себя самих. Допустим, я беру ссылку на какой-нить контрол, а потому выкидываю этот контрол из родительского. Кто им управит? FR>Новый родитель.
Его нет. Я выдернул контрол из дерева, а потом передал его еще в кучу разных лямбд, которые вызовутся через определенное время, и возможно вернут его в дерево, а возможно нет. Как здесь автоматически что-то соберется? Или упомянутый уже Data Binding. Допустим у меня есть объект, который я задал как источник данных в неизвестном числе контролов. Теперь все эти контролы удаляются из дерева. Должен ли их источник данных быть уничтожен? А если на него сослался какой-то другой объект вне дерева? Как GUI об этом узнает?
Re[12]: No mention of either Silverlight or .NET on Windows
Здравствуйте, Константин Б., Вы писали:
КБ> FR>Все очень давно украдено до нас, практически все живые сейчас C++ GUI библиотеки автоматически управляют ресурсами.
КБ> Например в Qt да?
Здравствуйте, MxMsk, Вы писали:
MM> Они это могут делать только в рамках себя самих. Допустим, я беру ссылку на какой-нить контрол, а потому выкидываю этот контрол из родительского. Кто им управит?
В VCL понятия владения и принадлежности разделены. Смена парента не изменяет владельца.
Здравствуйте, hattab, Вы писали:
MM>> Они это могут делать только в рамках себя самих. Допустим, я беру ссылку на какой-нить контрол, а потому выкидываю этот контрол из родительского. Кто им управит? H>В VCL понятия владения и принадлежности разделены. Смена парента не изменяет владельца.
Не означает ли это, что мудрая VCL возьмет да грохнет мой контрол, когда я того не хочу?
Re[13]: No mention of either Silverlight or .NET on Windows
Здравствуйте, MxMsk, Вы писали:
MM> L>> Последний SQL Server и SharePoint
MM> H>А что нибудь из недевелоперского?
MM> SharePoint и есть "недевелоперское".
Он более девелоперский, чем эндюзерский Хотя со стороны МС это вообще чистая политика, в свете перевода своих ОС на 64-бита и отказа от 32 бит. То есть, тут, как раз, все очень даже ожидаемо
Здравствуйте, MxMsk, Вы писали:
FR>>Новый родитель. MM>Его нет. Я выдернул контрол из дерева, а потом передал его еще в кучу разных лямбд, которые вызовутся через определенное время, и возможно вернут его в дерево, а возможно нет. Как здесь автоматически что-то соберется?
Держать список сирот и прибивать на выходе из цикла обработки сообщений.
MM>Или упомянутый уже Data Binding. Допустим у меня есть объект, который я задал как источник данных в неизвестном числе контролов. Теперь все эти контролы удаляются из дерева. Должен ли их источник данных быть уничтожен? А если на него сослался какой-то другой объект вне дерева? Как GUI об этом узнает?
Тут не спорю GC рулит, особенно если нужно управлять объектами вне конкретной библиотеки.
Но те же библиотеки обычно представляют механизмы (тот же подсчет ссылок например) позволяющие взять под свое управление
внешние объекты.
Здравствуйте, MxMsk, Вы писали:
MM> MM>> Они это могут делать только в рамках себя самих. Допустим, я беру ссылку на какой-нить контрол, а потому выкидываю этот контрол из родительского. Кто им управит?
MM> H>В VCL понятия владения и принадлежности разделены. Смена парента не изменяет владельца.
MM> Не означает ли это, что мудрая VCL возьмет да грохнет мой контрол, когда я того не хочу?
Здравствуйте, hattab, Вы писали:
MM>> H>В VCL понятия владения и принадлежности разделены. Смена парента не изменяет владельца. MM>> Не означает ли это, что мудрая VCL возьмет да грохнет мой контрол, когда я того не хочу? H>Не означает. Она позволяет управлять владением.
Вернее, там, где она не может справиться с владением, она возлагает эту рутину на разработчика.
Здравствуйте, MxMsk, Вы писали:
MM>Его нет. Я выдернул контрол из дерева, а потом передал его еще в кучу разных лямбд, которые вызовутся через определенное время, и возможно вернут его в дерево, а возможно нет. Как здесь автоматически что-то соберется?
На С++ все очень даже соберется — достаточно сказать объекту delete и он сам отпишется от всех событий и удалит себя из всех лямбд. Тем более, что для UI контролов обычно всегда понятно что "тут он нужен", а "тут уже больше не нужен". А вот с managed кодом — солнце придется закатывать "вручную"
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Здравствуйте, TK, Вы писали:
MM>>Его нет. Я выдернул контрол из дерева, а потом передал его еще в кучу разных лямбд, которые вызовутся через определенное время, и возможно вернут его в дерево, а возможно нет. Как здесь автоматически что-то соберется? TK>На С++ все очень даже соберется — достаточно сказать объекту delete и он сам отпишется от всех событий и удалит себя из всех лямбд. Тем более, что для UI контролов обычно всегда понятно что "тут он нужен", а "тут уже больше не нужен". А вот с managed кодом — солнце придется закатывать "вручную"
Далеко не всегда. В WPF, например, время жизни контрола вообще трудоуловимое в силу таких фичей, как шаблоны данных. Что касается "удаления из лямбд", то как же он сам это сделает?
Здравствуйте, MxMsk, Вы писали:
MM>Далеко не всегда. В WPF, например, время жизни контрола вообще трудоуловимое в силу таких фичей, как шаблоны данных. Что касается "удаления из лямбд", то как же он сам это сделает?
В WPF никак. А в С++ есть готовые решения.
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Здравствуйте, TK, Вы писали:
MM>>Далеко не всегда. В WPF, например, время жизни контрола вообще трудоуловимое в силу таких фичей, как шаблоны данных. Что касается "удаления из лямбд", то как же он сам это сделает? TK>В WPF никак. А в С++ есть готовые решения.
Я про эти решения и спрашиваю.
Здравствуйте, MxMsk, Вы писали:
MM> H>Не означает. Она позволяет управлять владением.
MM> Вернее, там, где она не может справиться с владением, она возлагает эту рутину на разработчика.
Что за бред? Тебе хоть раз приходилось вручную управлять владением в VCL? Компонентная модель дельфей позволяет писать такой код:
THook.Create(OkButton);
и не беспокоиться о том кто, как и когда убъет хук поставленный на кнопку. Но хук будет прибит, как только кнопка решит отдать концы.
Здравствуйте, hattab, Вы писали:
MM>> H>Не означает. Она позволяет управлять владением. MM>> Вернее, там, где она не может справиться с владением, она возлагает эту рутину на разработчика. H>Что за бред? Тебе хоть раз приходилось вручную управлять владением в VCL? Компонентная модель дельфей позволяет писать такой код: H> THook.Create(OkButton); H>и не беспокоиться о том кто, как и когда убъет хук поставленный на кнопку. Но хук будет прибит, как только кнопка решит отдать концы.
А если хук понадобиться мне после того, как "кнопка решит отдать концы"? Давай повторю, что мне хочется. Мне хочется, чтобы объекты могли собираться тогда, когда GUI фреймворк о них не имеет понятия. Когда они "в пределах видимости" GUI, т.е. находятся в визуальном дереве, ну или там в списке Components — то всё легко. А если я их временно оттуда выкидываю, что тогда? А если не выкину, но контрол понадобиться мне после удаления его родителя? Тут и начинаются танцы с бубнами и ручное управление.
Здравствуйте, MxMsk, Вы писали:
MM> H>Что за бред? Тебе хоть раз приходилось вручную управлять владением в VCL? Компонентная модель дельфей позволяет писать такой код: MM> H> THook.Create(OkButton); MM> H>и не беспокоиться о том кто, как и когда убъет хук поставленный на кнопку. Но хук будет прибит, как только кнопка решит отдать концы.
MM> А если хук понадобиться мне после того, как "кнопка решит отдать концы"? Давай повторю, что мне хочется. Мне хочется, чтобы объекты могли собираться тогда, когда GUI фреймворк о них не имеет понятия. Когда они "в пределах видимости" GUI, т.е. находятся в визуальном дереве, ну или там в списке Components — то всё легко. А если я их временно оттуда выкидываю, что тогда? А если не выкину, но контрол понадобиться мне после удаления его родителя? Тут и начинаются танцы с бубнами и ручное управление.
Ты путаешь владение и принадлежность. Визуальное дерево это не владение, это принадлежность.
Здравствуйте, hattab, Вы писали:
MM>> А если хук понадобиться мне после того, как "кнопка решит отдать концы"? Давай повторю, что мне хочется. Мне хочется, чтобы объекты могли собираться тогда, когда GUI фреймворк о них не имеет понятия. Когда они "в пределах видимости" GUI, т.е. находятся в визуальном дереве, ну или там в списке Components — то всё легко. А если я их временно оттуда выкидываю, что тогда? А если не выкину, но контрол понадобиться мне после удаления его родителя? Тут и начинаются танцы с бубнами и ручное управление. H>Ты путаешь владение и принадлежность. Визуальное дерево это не владение, это принадлежность.
Хорошо. С бубнами я так понимаю, ты не споришь.
Здравствуйте, MxMsk, Вы писали:
MM> MM>> А если хук понадобиться мне после того, как "кнопка решит отдать концы"? Давай повторю, что мне хочется. Мне хочется, чтобы объекты могли собираться тогда, когда GUI фреймворк о них не имеет понятия. Когда они "в пределах видимости" GUI, т.е. находятся в визуальном дереве, ну или там в списке Components — то всё легко. А если я их временно оттуда выкидываю, что тогда? А если не выкину, но контрол понадобиться мне после удаления его родителя? Тут и начинаются танцы с бубнами и ручное управление.
MM> H>Ты путаешь владение и принадлежность. Визуальное дерево это не владение, это принадлежность.
MM> Хорошо. С бубнами я так понимаю, ты не споришь.
Ты не правильно понимаешь. Нет никаких бубнов Достаточно владение контролом передать компоненту в том scope, из которого он тебе потребуется
Здравствуйте, hattab, Вы писали:
MM>> Хорошо. С бубнами я так понимаю, ты не споришь. H>Ты не правильно понимаешь. Нет никаких бубнов Достаточно владение контролом передать компоненту в том scope, из которого он тебе потребуется
Не пытайся вылезти на этом "непонимании". Что такое Owner в VCL, я пока что помню. Только проблему это не фига не решает. Что ты будешь делать, если у тебя не будет скопа, которому передавать владение, м? Впрочем, уже как-то стремно становится. Мы опускаемся до обсуждения очевиднейших траблов языков без GC. Для чего нужно объяснять убогость этих решений, мне не очень ясно
P.S. Забавно. На всякий случай я поискал в Гугле, и первая же ссылка вывела меня на трэд, в котором я же и отвечал когда-то про Parent/Owner.
Здравствуйте, MxMsk, Вы писали:
H>>Ты не правильно понимаешь. Нет никаких бубнов Достаточно владение контролом передать компоненту в том scope, из которого он тебе потребуется MM>Не пытайся вылезти на этом "непонимании". Что такое Owner в VCL, я пока что помню. Только проблему это не фига не решает. Что ты будешь делать, если у тебя не будет скопа, которому передавать владение, м? Впрочем, уже как-то стремно становится. Мы опускаемся до обсуждения очевиднейших траблов языков без GC. Для чего нужно объяснять убогость этих решений, мне не очень ясно
GC это очень хорошо спору нет.
Но практика показывает что не всякий и не везде.
GUI на управляемых языках все-таки гораздо тормознее на практике чем даже когда-то считавшиеся не шустрым нативный VCL.
Re[12]: No mention of either Silverlight or .NET on Windows
Здравствуйте, MxMsk, Вы писали:
MM> H>Ты не правильно понимаешь. Нет никаких бубнов Достаточно владение контролом передать компоненту в том scope, из которого он тебе потребуется
MM> Не пытайся вылезти на этом "непонимании". Что такое Owner в VCL, я пока что помню. Только проблему это не фига не решает.
Да нет же, решает Я тебе код с хуком показал. Там о существовании хука не знает вообще никто. Ни кнопка, ни какие либо глобальные компоненты. Более того, хук не является компонентом и у него нет owner'а, но он тем не менее помрет, когда помрет кнопка. Угадай, как решается
MM> Что ты будешь делать, если у тебя не будет скопа, которому передавать владение, м?
Что значит не будет scope? Как может не быть области видимости? Как бы там ни было, у тебя всегда есть глобальный Application, отдай ему, если сам запутался А воообще, мне как-то странно обсуждать сферовакуумные выдумки без конкретных примеров
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, MxMsk, Вы писали:
H>>>Ты не правильно понимаешь. Нет никаких бубнов Достаточно владение контролом передать компоненту в том scope, из которого он тебе потребуется MM>>Не пытайся вылезти на этом "непонимании". Что такое Owner в VCL, я пока что помню. Только проблему это не фига не решает. Что ты будешь делать, если у тебя не будет скопа, которому передавать владение, м? Впрочем, уже как-то стремно становится. Мы опускаемся до обсуждения очевиднейших траблов языков без GC. Для чего нужно объяснять убогость этих решений, мне не очень ясно
FR>GC это очень хорошо спору нет. FR>Но практика показывает что не всякий и не везде. FR>GUI на управляемых языках все-таки гораздо тормознее на практике чем даже когда-то считавшиеся не шустрым нативный VCL.
"Гораздо" — это насколько? Цифрами и методикой измерений не поделитесь?
FR>>GC это очень хорошо спору нет. FR>>Но практика показывает что не всякий и не везде. FR>>GUI на управляемых языках все-таки гораздо тормознее на практике чем даже когда-то считавшиеся не шустрым нативный VCL.
КБ>"Гораздо" — это насколько? Цифрами и методикой измерений не поделитесь?
Чисто субъективно.
Цифры возможно найдутся у разработчиков Evernote.
Re[12]: No mention of either Silverlight or .NET on Windows
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, Константин Б., Вы писали:
FR>>>GC это очень хорошо спору нет. FR>>>Но практика показывает что не всякий и не везде. FR>>>GUI на управляемых языках все-таки гораздо тормознее на практике чем даже когда-то считавшиеся не шустрым нативный VCL.
КБ>>"Гораздо" — это насколько? Цифрами и методикой измерений не поделитесь?
FR>Чисто субъективно.
А зачем вы писали "практика показывает", "на практике", когда вам всего лишь кажется?
FR>Цифры возможно найдутся у разработчиков Evernote.
Ну вот пусть они вместо вас в дискуссии и участвуют.
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, Константин Б., Вы писали: FR>>>Чисто субъективно. КБ>>А зачем вы писали "практика показывает", "на практике", когда вам всего лишь кажется?
FR>Моя практика это показывает. Она конечно субъективна, но совпадает с практиками большого количества FR>людей.
Ну так расскажите о своей практике поподробнее. Что, с чем и как сравнивали?
Методику подсчета "большинства людей" оставим за кадром. Художественное преувеличение и все такое.
FR>>>Цифры возможно найдутся у разработчиков Evernote. КБ>>Ну вот пусть они вместо вас в дискуссии и участвуют. FR>Не вижу ваших цифр, думаю вам стоит применить ваши только что установленные правила в первую очередь FR>к себе.
Правило тут простое: Кто сомнительные тезисы приводит — тот пусть их цифрами и подкрепляет.
Здравствуйте, Константин Б., Вы писали:
КБ>Ну так расскажите о своей практике поподробнее. Что, с чем и как сравнивали?
Нет не расскажу, я выразил свое мнение, не нравится опровергайте с цифрами, не хотите
опровергать высказываете свое.
Жаль только VS версией 2010 испортили
КБ>Методику подсчета "большинства людей" оставим за кадром. Художественное преувеличение и все такое.
Не надо передергивать, про большинство людей я не говорил.
FR>>Не вижу ваших цифр, думаю вам стоит применить ваши только что установленные правила в первую очередь FR>>к себе.
КБ>Правило тут простое: Кто сомнительные тезисы приводит — тот пусть их цифрами и подкрепляет.
Здравствуйте, hattab, Вы писали:
MM>> Что ты будешь делать, если у тебя не будет скопа, которому передавать владение, м? H>Что значит не будет scope? Как может не быть области видимости? Как бы там ни было, у тебя всегда есть глобальный Application, отдай ему, если сам запутался А воообще, мне как-то странно обсуждать сферовакуумные выдумки без конкретных примеров
Ты понимаешь, что означает слово "автоматически"? Именно об автоматическом слежении за ресурсами изначально шла речь. И именно с возможностью полноценного автоматического управления в нативных языках я и спорю. То, что ты предлагаешь — это не автоматически. Твой вариант с Application только демонстрирует проблему. Либо контролы, либо Application — среднего не дано — в этом проблема.
Почему-то TK не торопится с примером "отсоединения от ламбд"
Re[11]: No mention of either Silverlight or .NET on Windows
Здравствуйте, hattab, Вы писали:
H>Ну а если разработчик дает возможность использовать 32-битные версии при наличии 64-битных
Ну вот на текущей работе софт вообще managed, и запускается и на 32-х и на 64-х битах. На 32-х оно в принципе работает, но на некоторых приложениях под большой нагрузкой может вылететь OutOfMemoryException. На 64 битах этой проблемы нет.
Здравствуйте, MxMsk, Вы писали:
MM>>>Далеко не всегда. В WPF, например, время жизни контрола вообще трудоуловимое в силу таких фичей, как шаблоны данных. Что касается "удаления из лямбд", то как же он сам это сделает? TK>>В WPF никак. А в С++ есть готовые решения. MM>Я про эти решения и спрашиваю.
Для С++ есть "слабые" указатели которые уходят в 0 при явном удалении объекта (а не тогда, когда GC в голову придет). Есть сигналы которые могут автоматически разрывать связь с объектом при его удалении (не надо думать кто и куда подписал удаляемый объект и как его потом отписывать). Для всего этого написаны нормальные библиотеки которые позволяют выразит намерения разработчика без лишнего шума.
В итоге, проблема циклических ссылок стоит не так явно как то может казаться. Проблема циклических ссылок есть скорее в .net — каждая подписка на событие это фактически разделение владения объекта с источником событий. А учитывая, что детерминированного освобождения объектов нет (а в GUI как раз обычно все детерминировано) — это лишняя головная боль.
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Здравствуйте, MxMsk, Вы писали:
MM>А если хук понадобиться мне после того, как "кнопка решит отдать концы"? Давай повторю, что мне хочется. Мне хочется, чтобы объекты могли собираться тогда, когда GUI фреймворк о них не имеет понятия. Когда они "в пределах видимости" GUI, т.е. находятся в визуальном дереве, ну или там в списке Components — то всё легко. А если я их временно оттуда выкидываю, что тогда? А если не выкину, но контрол понадобиться мне после удаления его родителя? Тут и начинаются танцы с бубнами и ручное управление.
Не надо путать враппер для кнопки (OkButton) и ресурс связанный с данной кнопкой (окно).
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Здравствуйте, MxMsk, Вы писали:
MM> MM>> Что ты будешь делать, если у тебя не будет скопа, которому передавать владение, м?
MM> H>Что значит не будет scope? Как может не быть области видимости? Как бы там ни было, у тебя всегда есть глобальный Application, отдай ему, если сам запутался А воообще, мне как-то странно обсуждать сферовакуумные выдумки без конкретных примеров
MM> Ты понимаешь, что означает слово "автоматически"?
Я понимаю, а ты похоже нет Если я не прикладываю усилий для слежением за жизнью контролов, значит VCL делает это за меня т.е. автоматически. На уровне библиотеки. Все просто
MM> Именно об автоматическом слежении за ресурсами изначально шла речь.
...применительно к гуевым библиотекам. Тебе цитату привести?
MM> И именно с возможностью полноценного автоматического управления в нативных языках я и спорю.
А мы не о языках, мы о гуевых библиотеках Ладно, цитирую:
Мы же про возможность автоматического управления ресурсами и памятью для GUI библиотек на C++
MM> То, что ты предлагаешь — это не автоматически. Твой вариант с Application только демонстрирует проблему. Либо контролы, либо Application — среднего не дано — в этом проблема.
Да нет же, это автоматически Просто эта автоматизация осуществлена на уровне библиотеки, а не языка. А пример с Application был призван продемонстрировать тебе, что если ты заблудился в scope — есть универсальное решение . И вообще странная претензия: либо контролы, либо Application... Вообще-то любому компоненту можно передать права владения.
MM> Почему-то TK не торопится с примером "отсоединения от ламбд"
Так и ты что-то не торопишься с примерами хитрых манипуляций с контролами, где тебе требуется передача прав владения. Лишь одно пожелание: будешь медитировать, старайся ближе к реальности
Здравствуйте, Ночной Смотрящий, Вы писали:
НС> H>Ну а если разработчик дает возможность использовать 32-битные версии при наличии 64-битных
НС> Ну вот на текущей работе софт вообще managed, и запускается и на 32-х и на 64-х битах. На 32-х оно в принципе работает, но на некоторых приложениях под большой нагрузкой может вылететь OutOfMemoryException. На 64 битах этой проблемы нет.
Менеджед такой менеджед? Недетерминированность высвобождения ресурсов во всей красе, я правильно понимаю? Ок. Для избавления от подобного рода проблем использование 64 бит является оправданным. Остается лишь порадоваться, что явление это не массовое
Здравствуйте, hattab, Вы писали:
H>Менеджед такой менеджед? Недетерминированность высвобождения ресурсов во всей красе, я правильно понимаю?
Нет, не правильно. Просто интенсивная работа с большими объемами памяти и, как следствие, фрагментация. Я ведь не зря писал про нехватку address space, а не памяти.
H>Ок. Для избавления от подобного рода проблем использование 64 бит является оправданным. Остается лишь порадоваться, что явление это не массовое
Смотря где. На рынке серверных приложений вполне массовое. Да и решарперы всякие огребают по полной программе.
Re[13]: No mention of either Silverlight or .NET on Windows
Здравствуйте, Ночной Смотрящий, Вы писали:
НС> H>Менеджед такой менеджед? Недетерминированность высвобождения ресурсов во всей красе, я правильно понимаю?
НС> Нет, не правильно. Просто интенсивная работа с большими объемами памяти и, как следствие, фрагментация. Я ведь не зря писал про нехватку address space, а не памяти.
Пардон, а как же дефрагментация хипа? Или куски такие большие что для них дефрагментация не выполняется? А пулы проблему не решают?
НС> H>Ок. Для избавления от подобного рода проблем использование 64 бит является оправданным. Остается лишь порадоваться, что явление это не массовое
НС> Смотря где. На рынке серверных приложений вполне массовое. Да и решарперы всякие огребают по полной программе.
Натив позволяет этого избежать выбрав политику управления памятью под задачу
Здравствуйте, hattab, Вы писали:
H>А что нибудь из недевелоперского?
Топовые игры. ИМХО 32 поддерживаются для того, чтоб оно хоть как-то запустилось и там, но во всяких Фаркраях2 и прочих последних Сталкерах 64 — хардли рекоммендед и всё такое. Как только манагеры дадут отмашку, что рынок на 32 можно забить, так сразу будет 64 only. Хотя может я и ошибаюсь, хотелось-бы коментариев кого-нибуть из гейм-дева.
Re[13]: No mention of either Silverlight or .NET on Windows
Здравствуйте, yoriсk.kiev.ua, Вы писали:
YKU>Топовые игры. ИМХО 32 поддерживаются для того, чтоб оно хоть как-то запустилось и там, но во всяких Фаркраях2 и прочих последних Сталкерах 64 — хардли рекоммендед и всё такое.
По поводу игр как-то сомнительно. Большинство игр на ПС приходят с консолей, где вообще памяти не густо (256+256 или 512 общей). И тут внезапно на ПС им начинает не хватать памяти?
YKU>Как только манагеры дадут отмашку, что рынок на 32 можно забить, так сразу будет 64 only. Хотя может я и ошибаюсь, хотелось-бы коментариев кого-нибуть из гейм-дева.
В смысле забить на все консоли и делать только для 64-бит ПС?
Здравствуйте, TK, Вы писали:
TK>Здравствуйте, MxMsk, Вы писали:
MM>>>>Далеко не всегда. В WPF, например, время жизни контрола вообще трудоуловимое в силу таких фичей, как шаблоны данных. Что касается "удаления из лямбд", то как же он сам это сделает? TK>>>В WPF никак. А в С++ есть готовые решения. MM>>Я про эти решения и спрашиваю.
TK>Для С++ есть "слабые" указатели которые уходят в 0 при явном удалении объекта (а не тогда, когда GC в голову придет). Есть сигналы которые могут автоматически разрывать связь с объектом при его удалении (не надо думать кто и куда подписал удаляемый объект и как его потом отписывать). Для всего этого написаны нормальные библиотеки которые позволяют выразит намерения разработчика без лишнего шума.
Почему вы ручное удаление продолжаете называть "автоматическим управлением ресурсами"? Разницу между "удалить объект когда не останется ссылок" и "удалить все ссылки когда не останется объекта" не видим?
TK>В итоге, проблема циклических ссылок стоит не так явно как то может казаться. Проблема циклических ссылок есть скорее в .net — каждая подписка на событие это фактически разделение владения объекта с источником событий. А учитывая, что детерминированного освобождения объектов нет (а в GUI как раз обычно все детерминировано) — это лишняя головная боль.
Здравствуйте, Константин Б., Вы писали:
КБ>Почему вы ручное удаление продолжаете называть "автоматическим управлением ресурсами"? Разницу между "удалить объект когда не останется ссылок" и "удалить все ссылки когда не останется объекта" не видим?
Надо понимать, что подлинной автоматики нет нигде. Добиться ситуации "когда не останется ссылок" это такое-же ручное управление — любая отписка от "глобальных" событий это и есть ручное управление памятью.
КБ>В .Net проблема циклических ссылок не стоит
Любая ссылка "из вне" на объект и проблема встанет в полный рост.
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Re[13]: No mention of either Silverlight or .NET on Windows
Здравствуйте, yoriсk.kiev.ua, Вы писали:
y> H>А что нибудь из недевелоперского?
y> Топовые игры. ИМХО 32 поддерживаются для того, чтоб оно хоть как-то запустилось и там, но во всяких Фаркраях2 и прочих последних Сталкерах 64 — хардли рекоммендед и всё такое. Как только манагеры дадут отмашку, что рынок на 32 можно забить, так сразу будет 64 only. Хотя может я и ошибаюсь, хотелось-бы коментариев кого-нибуть из гейм-дева.
Недавно, не то здесь, не то на хабре, видел статистику пользовательских конфигураций (выборка вроде приличная, жаль ссылку не могу найти). Там большинство пользовательских систем имеют менее 4 Gb Но даже если игруха будет хотеть 4Gb, ей для этого не обязательно быть 64-битной. А иметь две версии всегда более геморойно чем одну.
Здравствуйте, TK, Вы писали:
MM>>>>Далеко не всегда. В WPF, например, время жизни контрола вообще трудоуловимое в силу таких фичей, как шаблоны данных. Что касается "удаления из лямбд", то как же он сам это сделает? TK>>>В WPF никак. А в С++ есть готовые решения. MM>>Я про эти решения и спрашиваю. TK>Для С++ есть "слабые" указатели которые уходят в 0 при явном удалении объекта (а не тогда, когда GC в голову придет). Есть сигналы которые могут автоматически разрывать связь с объектом при его удалении (не надо думать кто и куда подписал удаляемый объект и как его потом отписывать). Для всего этого написаны нормальные библиотеки которые позволяют выразит намерения разработчика без лишнего шума.
Погоди погоди. Я же просил нормальный, реальный пример. Понятно, что можно напридумывать кучу костылей. Я привел пример, когда отдаю контрол в несколько лямбд. На что был получен ответ, типа это не проблема для C++. Однако, внятного решения — автоматической заботы об объекте, вырванном из дерева, мне никто не приводит. Вон, как что не скажешь про C++, у FR на всё ответ "при желании можно", но что-то пример продакшн уровня реализации этих желаний никто не приводит, только самопальные костыли... или Python!
TK>В итоге, проблема циклических ссылок стоит не так явно как то может казаться. Проблема циклических ссылок есть скорее в .net — каждая подписка на событие это фактически разделение владения объекта с источником событий. А учитывая, что детерминированного освобождения объектов нет (а в GUI как раз обычно все детерминировано) — это лишняя головная боль.
Проблемы циклических ссылок в .Net нет. И потом, я не уверен, что разрыв связи — это правильный путь. Если кто-то подписался на event, значит это ему нужно. Да и weak event при желании реализовать можно. А лучше научится реализовывать GUI без этих заморочек.
Здравствуйте, TK, Вы писали:
MM>>А если хук понадобиться мне после того, как "кнопка решит отдать концы"? Давай повторю, что мне хочется. Мне хочется, чтобы объекты могли собираться тогда, когда GUI фреймворк о них не имеет понятия. Когда они "в пределах видимости" GUI, т.е. находятся в визуальном дереве, ну или там в списке Components — то всё легко. А если я их временно оттуда выкидываю, что тогда? А если не выкину, но контрол понадобиться мне после удаления его родителя? Тут и начинаются танцы с бубнами и ручное управление. TK>Не надо путать враппер для кнопки (OkButton) и ресурс связанный с данной кнопкой (окно).
Да я видел полно кнопок, в которых еще таймер задействуется или какой-нибудь битмап грузится. Чем не ресурс? В конце концов, мы в нативной среде — там и сам враппер тоже ресурс.
Здравствуйте, MxMsk, Вы писали:
MM>Погоди погоди. Я же просил нормальный, реальный пример. Понятно, что можно напридумывать кучу костылей. Я привел пример, когда отдаю контрол в несколько лямбд. На что был получен ответ, типа это не проблема для C++. Однако, внятного решения — автоматической заботы об объекте, вырванном из дерева, мне никто не приводит. Вон, как что не скажешь про C++, у FR на всё ответ "при желании можно", но что-то пример продакшн уровня реализации этих желаний никто не приводит, только самопальные костыли... или Python!
Я уже писал выше GUI библиотеки предлагают решение, автоматическое управление с помощью подсчета ссылок:
Да это хуже GC из-за циклов, но никак ни ничего как пытаешься доказать тут ты.
Ну и потом проблемы с отвязкой — привязкой событий из NET вызванные особенностью реализации делегатов и событий
не нужно проецировать на другие среды в которых таких проблем нет.
Здравствуйте, FR, Вы писали:
MM>>Погоди погоди. Я же просил нормальный, реальный пример. Понятно, что можно напридумывать кучу костылей. Я привел пример, когда отдаю контрол в несколько лямбд. На что был получен ответ, типа это не проблема для C++. Однако, внятного решения — автоматической заботы об объекте, вырванном из дерева, мне никто не приводит. Вон, как что не скажешь про C++, у FR на всё ответ "при желании можно", но что-то пример продакшн уровня реализации этих желаний никто не приводит, только самопальные костыли... или Python!
FR>Я уже писал выше GUI библиотеки предлагают решение, автоматическое управление с помощью подсчета ссылок: FR>http://docs.wxwidgets.org/trunk/overview_refcount.html FR>http://www.gtk.org/api/2.6/gtk/GtkObject.html#id3557216 FR>Да это хуже GC из-за циклов, но никак ни ничего как пытаешься доказать тут ты.
Я что, где-либо отрицал наличие либ с reference counting? Речь идет о решении проблемы циклов через какой-то сторонний модуль, который типа их разруливает. Вот такое я и жду.
FR>Ну и потом проблемы с отвязкой — привязкой событий из NET вызванные особенностью реализации делегатов и событий FR>не нужно проецировать на другие среды в которых таких проблем нет.
Да не проецировал я делегаты, не я про них начал. Давайте уже последовательно!
Здравствуйте, MxMsk, Вы писали:
MM>Я что, где-либо отрицал наличие либ с reference counting? Речь идет о решении проблемы циклов через какой-то сторонний модуль, который типа их разруливает. Вот такое я и жду.
Я показал что это принципиально возможно, в питоне реализовано, в C++ я реализаций не видел.
В контексте темы GUI такой механизм не является необходимостью и каким-либо существенным стоп фактором,
так как циклы очень редки при типичном сценарии использования, и вполне нормально при необходимости разруливаются
вручную.
FR>>Ну и потом проблемы с отвязкой — привязкой событий из NET вызванные особенностью реализации делегатов и событий FR>>не нужно проецировать на другие среды в которых таких проблем нет. MM>Да не проецировал я делегаты, не я про них начал. Давайте уже последовательно!
Ну эта тема сразу вспоминается так как явный косяк и GC ничем ни помогает.
Re[14]: No mention of either Silverlight or .NET on Windows
Здравствуйте, Воронков Василий, Вы писали:
YKU>>Топовые игры. ИМХО 32 поддерживаются для того, чтоб оно хоть как-то запустилось и там, но во всяких Фаркраях2 и прочих последних Сталкерах 64 — хардли рекоммендед и всё такое.
ВВ>По поводу игр как-то сомнительно. Большинство игр на ПС приходят с консолей
Угу. Идут-идут и приходят.
ВВ>где вообще памяти не густо (256+256 или 512 общей). И тут внезапно на ПС им начинает не хватать памяти?
А вы требования к PC играм давно читали? А то я и не припомню уже, что-бы в recommended ниже 2G было. А так, всё больше 4G+ хотят, даже всякие Цивилизации, которым, по идее, оно вообще не сильно надо.
Re[15]: No mention of either Silverlight or .NET on Windows
Здравствуйте, yoriсk.kiev.ua, Вы писали:
ВВ>>где вообще памяти не густо (256+256 или 512 общей). И тут внезапно на ПС им начинает не хватать памяти? YKU>А вы требования к PC играм давно читали? А то я и не припомню уже, что-бы в recommended ниже 2G было. А так, всё больше 4G+ хотят, даже всякие Цивилизации, которым, по идее, оно вообще не сильно надо.
Мало ли что они пишут в требованиях. 32-битной игре *минимум* 4ГБ? Это сложно назвать технически обоснованным. Скорее всего просто подстраховываются на случай, если большая часть этих 4ГБ уже занята.
Re[14]: No mention of either Silverlight or .NET on Windows
Здравствуйте, Воронков Василий, Вы писали:
ВВ>По поводу игр как-то сомнительно. Большинство игр на ПС приходят с консолей, где вообще памяти не густо (256+256 или 512 общей). И тут внезапно на ПС им начинает не хватать памяти?
В играх легко забить почти любую доступную память увеличив детализацию, ну и получить ~квадратичный рост потребления памяти при этом.
Re[15]: No mention of either Silverlight or .NET on Windows
Здравствуйте, FR, Вы писали:
FR>В играх легко забить почти любую доступную память увеличив детализацию, ну и получить ~квадратичный рост потребления памяти при этом.
Ну вот, в ПС3 оперативной памяти — 256 ГБ. Увеличиваем детализацию вдвое (чего я вообще обычно не наблюдаю) — получаем увеличение памяти в четыре раза. А ведь текстурками потребление памяти не ограничивается. И откуда дефицит памяти на 32-битах?
Re[14]: No mention of either Silverlight or .NET on Windows
Здравствуйте, hattab, Вы писали:
H>Пардон, а как же дефрагментация хипа?
Для LOH компактификация не делается, там классический алгоритм с поиском свободных блоков.
H> Или куски такие большие что для них дефрагментация не выполняется?
Именно. Такие большие = 80 Кб.
H> А пулы проблему не решают?
Не всегда возможно пулы использовать. Отчасти проблему решают IO потоки, но и с ними проблем предостаточно.
НС>> Смотря где. На рынке серверных приложений вполне массовое. Да и решарперы всякие огребают по полной программе.
H>Натив позволяет этого избежать выбрав политику управления памятью под задачу
Нет тут никакой разницы с нативом. И там и там, чтобы ужаться до 2 Гб, нужно использовать целый комплекс мер, усложняющих решение и снижающих производительность даже при небольшой нагрузке. Намного проще просто перейти на 64 бита.
Здравствуйте, Ночной Смотрящий, Вы писали:
FR>>Ну эта тема сразу вспоминается так как явный косяк и GC ничем ни помогает.
НС>Что это за загадочный косяк такой?
Возможно Microsoft ожидает заметных перемен в компьютерных железках. Если нововведения будут достаточно привлекательными ( А тот же Apple постарается, чтобы так оно и было ) то потребуется обновлять весь софт.
При таком раскладе надо успевать выдать свежую версию и ОС и средств разработки и это надо делать паралелльно. Нет времени ждать, пока .Net устаканится под новые реалии, она слишком мнолитна и громоздка для резких поворотов.
Вот на правах свободного полета фантазии:
Представьте, если у кого-то уже дозревает до рыночной кондиции технология хранения данных со скоростью процессорного кэша и емкостью + себестоимость + энегронезависимость HDD. Как это повлияет на поведение крупных производителей софта ?!
Re[15]: No mention of either Silverlight or .NET on Windows
Здравствуйте, Ночной Смотрящий, Вы писали:
НС> НС>> Смотря где. На рынке серверных приложений вполне массовое. Да и решарперы всякие огребают по полной программе.
НС> H>Натив позволяет этого избежать выбрав политику управления памятью под задачу
НС> Нет тут никакой разницы с нативом.
При использование специализированных менеджеров памяти можно вообще избежать фрагментирования кучи
НС> И там и там, чтобы ужаться до 2 Гб, нужно использовать целый комплекс мер, усложняющих решение и снижающих производительность даже при небольшой нагрузке. Намного проще просто перейти на 64 бита.
Зачем ужиматься до 2Gb, когда позволяется 3Gb на 32-битных системах и 4Gb на 64? Разумеется, я не отрицаю явного преимущества 64-битного адресного пространства, но нужно это далеко не всем.
Здравствуйте, Sinix, Вы писали:
S>Здравствуйте, FR, Вы писали:
НС>>>Что это за загадочный косяк такой? FR>>Тут http://habrahabr.ru/blogs/net/89529/ S>Ткните пальцем — в чём косяк?
В утечке памяти на платформе с GC и переходе на практически ручное управление чтобы ее избежать.
Здравствуйте, MxMsk, Вы писали:
MM>Погоди погоди. Я же просил нормальный, реальный пример. Понятно, что можно напридумывать кучу костылей. Я привел пример, когда отдаю контрол в несколько лямбд. На что был получен ответ, типа это не проблема для C++. Однако, внятного решения — автоматической заботы об объекте, вырванном из дерева, мне никто не приводит. Вон, как что не скажешь про C++, у FR на всё ответ "при желании можно", но что-то пример продакшн уровня реализации этих желаний никто не приводит, только самопальные костыли... или Python!
Реализации ссылок на любой вкус есть в TR1/boost, сигналы есть в boost/QT. Например, в QT есть QPointer<T> — надо "вырвать" объект из дерева — сказали ему delete obj и он автоматически будет из него "вырван" (все указатели на объект станут равны 0) А вот в .net удаление любого объекта из дерева, это хождение по граблям — все ссылки владеющие, а WeakReference без "внешней поддержки" использовать практически нельзя.
MM>Проблемы циклических ссылок в .Net нет. И потом, я не уверен, что разрыв связи — это правильный путь. Если кто-то подписался на event, значит это ему нужно. Да и weak event при желании реализовать можно. А лучше научится реализовывать GUI без этих заморочек.
"Если кто-то подписался на event, значит это ему нужно." — получается паттерн "буратино вырос". после этого, истинный владелец "буратин" будет ломать голову над тем, как их всех родить обратно. Weak Event в том-же WPF это как раз и следствие того, что "проблемы циклических ссылок в .Net нет".
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Re[16]: No mention of either Silverlight or .NET on Windows
Здравствуйте, hattab, Вы писали:
H>При использование специализированных менеджеров памяти можно вообще избежать фрагментирования кучи
Не бесплатно.
H>Зачем ужиматься до 2Gb, когда позволяется 3Gb на 32-битных системах и 4Gb на 64?
Я в курсе. Принципиально проблему это не решает.
H> Разумеется, я не отрицаю явного преимущества 64-битного адресного пространства, но нужно это далеко не всем.
Но это не означает, что не нужно почти никому, как ты утверждаешь.
И где там проблемы GC? Фиксация на глобальных событиях/сигналах без отписки при любой технологии управления памятью приведет к утечке. Потому что проблема логическая, а не технологическая.
Здравствуйте, TK, Вы писали:
TK>А вот в .net удаление любого объекта из дерева, это хождение по граблям — все ссылки владеющие, а WeakReference без "внешней поддержки" использовать практически нельзя.
А зачем убивать объект, когда на него остались ссылки? Чтобы потом воевать с помершими ссылками?
TK>"Если кто-то подписался на event, значит это ему нужно." — получается паттерн "буратино вырос". после этого, истинный владелец "буратин" будет ломать голову над тем, как их всех родить обратно. Weak Event в том-же WPF это как раз и следствие того, что "проблемы циклических ссылок в .Net нет".
Какая связь между циклическими ссылками и weak подпиской?
Re[2]: No mention of either Silverlight or .NET on Windows 8
Здравствуйте, Sclis, Вы писали:
S>Возможно Microsoft ожидает заметных перемен в компьютерных железках.
Нет.
S>При таком раскладе надо успевать выдать свежую версию и ОС и средств разработки и это надо делать паралелльно. Нет времени ждать, пока .Net устаканится под новые реалии
Нет никакой необходимости чего то устаканивать с дотнетом — рантайм обновляется очень редко и понемногу.
S>, она слишком мнолитна и громоздка для резких поворотов.
Аргументируй. Потому что, по факту, как раз нативные решения проигрывают по скорости адаптации к изменениям.
S>Представьте, если у кого-то уже дозревает до рыночной кондиции технология хранения данных со скоростью процессорного кэша и емкостью + себестоимость + энегронезависимость HDD. Как это повлияет на поведение крупных производителей софта ?!
Сперва ты расскажи, что такого придется кардинально менять при этом в рантайме дотнета.
S>>При таком раскладе надо успевать выдать свежую версию и ОС и средств разработки и это надо делать паралелльно. Нет времени ждать, пока .Net устаканится под новые реалии
НС>Нет никакой необходимости чего то устаканивать с дотнетом — рантайм обновляется очень редко и понемногу.
а почему тогда в текущей версии windows phone используется урезанный Compact Framework, а не нормальный .net? я так понял они не успели его полноценно на АРм портировать
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Аргументируй. Потому что, по факту, как раз нативные решения проигрывают по скорости адаптации к изменениям.
По факту не проигрывают, так как не припомню таких событий чтобы сравнить для менеджед, а натив
вполне неплохо адаптируем, например тот же apple уже несколько раз менял аппаратуру.
Re[4]: No mention of either Silverlight or .NET on Windows 8
Здравствуйте, Евгений Акиньшин, Вы писали:
ЕА>а почему тогда в текущей версии windows phone используется урезанный Compact Framework, а не нормальный .net? я так понял они не успели его полноценно на АРм портировать
FR>В утечке памяти на платформе с GC и переходе на практически ручное управление чтобы ее избежать.
Это не утечка памяти. Проблема ничем не отличается от
class A { }
class B { public A A { get; set; } }
// ...
A a = new A();
B b = new B() { A = a };
и сохранения ссылки на b, поэтому какой-нибудь "альтернативный" GC тут ничем не поможет. Костыли по ссылки — защита от отдельных одарённых личностей, что не могут усвоить правило "подписался — отпишись".
Re[16]: No mention of either Silverlight or .NET on Windows
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Скорее всего просто подстраховываются на случай, если большая часть этих 4ГБ уже занята.
А когда хотят 8, то подстраховываются на случай, если пользователь забил большую часть этих восьми? Когда пишут "рекомендуем исспользовать 64-х битную версию" от чего подстраховываются?
ВВ>И откуда дефицит памяти на 32-битах?
А вы с чем спорите-то? С надписями на дисках от производителей?
Кстати, Крайтек уже пишет в Спортлото, что на приставки надо 8G ставить. Это минимум, говорят.
Здравствуйте, Sinix, Вы писали:
FR>>В утечке памяти на платформе с GC и переходе на практически ручное управление чтобы ее избежать. S>Это не утечка памяти. Проблема ничем не отличается от
Да это понятно конечно.
Но память все равно бестолково зависает.
S>и сохранения ссылки на b, поэтому какой-нибудь "альтернативный" GC тут ничем не поможет. Костыли по ссылки — защита от отдельных одарённых личностей, что не могут усвоить правило "подписался — отпишись".
Это и есть ручное управление.
Утрированно и RAII в C++ и GC это только защита от отдельных одаренных личностей не способных на каждый malloc вызвать free
Re[17]: No mention of either Silverlight or .NET on Windows
Здравствуйте, Ночной Смотрящий, Вы писали:
НС> H> Разумеется, я не отрицаю явного преимущества 64-битного адресного пространства, но нужно это далеко не всем.
НС> Но это не означает, что не нужно почти никому, как ты утверждаешь.
Здравствуйте, FR, Вы писали:
FR>Да это понятно конечно. FR>Но память все равно бестолково зависает.
+1
S>>и сохранения ссылки на b, поэтому какой-нибудь "альтернативный" GC тут ничем не поможет. Костыли по ссылки — защита от отдельных одарённых личностей, что не могут усвоить правило "подписался — отпишись". FR>Это и есть ручное управление.
Неа, тут скорее явное освобождение ресурсов
На самом деле по ссылке городят тонну лишнего кода, для ленивого события более чем достаточно WeakList<T> (пишется самостоятельно за 5 минут).
Ну, а если делать всерьёз, то надо целиком имитировать реализацию multicast delegate — сделать immutable-тип, внутри которого — WeakReference<TDelegate>[] + (опционально) хелпер, что будет обновлять поле, используя Modify-CompareExchange loop (см пример). Поскольку снаружи всё выглядит как обычный event EventHandler MyEvent, для клиентского кода разницы никакой.
Делается 1 раз... и нигде не используется за практической ненадобностью. У меня где-то валяется набросок трёхлетней давности, не пригодился пока.
FR>Утрированно и RAII в C++ и GC это только защита от отдельных одаренных личностей не способных на каждый malloc вызвать free
Угу
Здравствуйте, FR, Вы писали:
НС>>Слабые ссылки это у тебя ручное управление? Вобщем, все как и предполагалось, слышал звон ...
FR>Так полного автомата нет
Что значит нет? Слабые ссылки работают полностью автоматически.
FR>, а полуавтоматы и без GC доступны, те же shared_ptr/weak_ptr
Ага, с проблемами на циклах и перформансе.
Re[4]: No mention of either Silverlight or .NET on Windows 8
Здравствуйте, Евгений Акиньшин, Вы писали:
ЕА>а почему тогда в текущей версии windows phone используется урезанный Compact Framework, а не нормальный .net?
Потому же, почему вообще CF существует — куцые ресурсы и необходимость беречь батарейку.
Re[4]: No mention of either Silverlight or .NET on Windows 8
Здравствуйте, Ночной Смотрящий, Вы писали:
FR>>Так полного автомата нет
НС>Что значит нет? Слабые ссылки работают полностью автоматически.
Так и shared_ptr/weak_ptr тоже полностью автоматически работают, после того как их расставил.
FR>>, а полуавтоматы и без GC доступны, те же shared_ptr/weak_ptr
НС>Ага, с проблемами на циклах и перформансе.
Тут вопрос сложный в контексте GUI который обычно однопоточный и не требует особого быстродействия
(кроме самого нижнего уровня) но зато очень любит чтобы не было внезапных остановок даже на короткое
время. С этим как раз у ref count все гораздо лучше чем у GC.
Re[5]: No mention of either Silverlight or .NET on Windows 8
Здравствуйте, yoriсk.kiev.ua, Вы писали:
YKU>А когда хотят 8, то подстраховываются на случай, если пользователь забил большую часть этих восьми? Когда пишут "рекомендуем исспользовать 64-х битную версию" от чего подстраховываются? YKU>
А кто пишет-то? Крайтеки? Много таких прецендентов?
ВВ>>И откуда дефицит памяти на 32-битах?
YKU>А вы с чем спорите-то? С надписями на дисках от производителей?
Да ни с чем я не спорю. Понятно, что при желании в игрушке практически любой размер оперативы забить не сложно. Но вот в массовое пришествие 64 бит в играх мне верится слабо. Хотя бы потому что основные по рыночной массе игровые платформы сейчас 32-битные, и не факт, что это изменится в будущем поколении. И подавляющее большинство игр таки портированы — нравятся вам это или нет. Причем при портировании качество графики улучшается незначительно, в чем я не раз убеждался (это если вообще улучшается). При этом на одной платформе нам хватает 236 мег, а на другой — 32 бит мало?
YKU>Кстати, Крайтек уже пишет в Спортлото, что на приставки надо 8G ставить. Это минимум, говорят.
Ага, не получилась у них убер-графика на консолях, теперь память виновата. Остальные вот как-то справляются.
В 8ГБ я лично не верю. У PS3, к примеру, 256МБ оперативы сейчас. Мне слабо верятся, что в следующем поколении память увеличат в 32 раза. Таких прецендентов не было вообще. К тому же консоли на старте всегда продают в убыток, а лишние деньги терять никто не хочет. Если же памяти будет в пределах 4ГБ (а скорее — в пределах 2ГБ), то смысла в 64 битах нет вообще.
Re[18]: No mention of either Silverlight or .NET on Windows
Здравствуйте, Воронков Василий, Вы писали:
ВВ>А кто пишет-то? Крайтеки? Много таких прецендентов?
5 минут в Гугле спасут отца.
ВВ>И подавляющее большинство игр таки портированы — нравятся вам это или нет.
Да портируют конечно. И порт под PC всегда хочет памяти побольше, чем порт под приставки, причём в разы. Я всегда думал, что это не от хорошей жизни на консолях.
ВВ>Таких прецендентов не было вообще.
Xbox увеличивал в 8 раз. Ну тут увеличат в 16. Ничего принципиально невозможного я вообще не вижу. Когда-то usb и wifi на консолях казались фантастикой. Да и кому это вообще могло бы понадобиться?
YKU>>А вы с чем спорите-то? С надписями на дисках от производителей? ВВ>Да ни с чем я не спорю.
Значит мне показалось. Так или иначе — вот вам еще одна ниша, где есть потребность в 64: РС игры, кушающие 4G+ и собраные под 64 есть, и разработчики хотят всё это щастье на консолях тоже.
Re[19]: No mention of either Silverlight or .NET on Windows
Здравствуйте, yoriсk.kiev.ua, Вы писали:
YKU>Да портируют конечно. И порт под PC всегда хочет памяти побольше, чем порт под приставки, причём в разы. Я всегда думал, что это не от хорошей жизни на консолях.
Тут скорее "кривые" руки портировщиков/изначальная "неоптимальность" платформы. Что еще может заставить резко поднимать требования?
YKU>Xbox увеличивал в 8 раз. Ну тут увеличат в 16. Ничего принципиально невозможного я вообще не вижу. Когда-то usb и wifi на консолях казались фантастикой. Да и кому это вообще могло бы понадобиться?
Wifi в Xbox появился только в прошлом году, а встроенного жесткого диска нет до сих пор. А вы про 64 бита и 4G+
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Re[19]: No mention of either Silverlight or .NET on Windows
Здравствуйте, yoriсk.kiev.ua, Вы писали:
ВВ>>А кто пишет-то? Крайтеки? Много таких прецендентов? YKU>5 минут в Гугле спасут отца.
Вы делаете какие-то утверждения, а им должен в Гугле подтверждение искать? Не уж, извините, уступаю это право вам.
ВВ>>И подавляющее большинство игр таки портированы — нравятся вам это или нет. YKU>Да портируют конечно. И порт под PC всегда хочет памяти побольше, чем порт под приставки, причём в разы. Я всегда думал, что это не от хорошей жизни на консолях.
Ну вот меня несколько удивляет, что порт, скажем, с ПС3 требует памяти в 8 раз больше. 8 раз — это много, епт. И думаю, это не от хорошего качества этих портов.
ВВ>>Таких прецендентов не было вообще. YKU>Xbox увеличивал в 8 раз. Ну тут увеличат в 16. Ничего принципиально невозможного я вообще не вижу. Когда-то usb и wifi на консолях казались фантастикой. Да и кому это вообще могло бы понадобиться?
Давайте не забывать, что в случае XBox (оба поколения) речь идет а шаред мемори, т.е. это видео и оперативная память вместе. Мы здесь обсуждаем увеличение только оперативной памяти до 8 Гиг. Для ПС3 это увеличение памяти ровно в 32 раза, чему прецендентов таки не было.
YKU>>>А вы с чем спорите-то? С надписями на дисках от производителей? ВВ>>Да ни с чем я не спорю. YKU>Значит мне показалось. Так или иначе — вот вам еще одна ниша, где есть потребность в 64: РС игры, кушающие 4G+ и собраные под 64 есть, и разработчики хотят всё это щастье на консолях тоже.
Да пусть хотят.
Добавьте веточку в фавориты, кстати. Я более чем уверен, что 64 бит на консолях следующего поколения не будет. Wii U даже не считаем. Только PS3/X360.
Re[3]: No mention of either Silverlight or .NET on Windows 8
Здравствуйте, blackhearted, Вы писали:
D>>маскарад технологий реально уже затрахал. Метания — признак отсутствия стратегии и/или воли и начало конца. B>а ишак всё не дохет...
Дохнет, дохнет. Просто ишак большой попался.
WBR, Igor Evgrafov
Re[4]: No mention of either Silverlight or .NET on Windows 8
Здравствуйте, GarryIV, Вы писали:
GIV>Здравствуйте, blackhearted, Вы писали:
D>>>маскарад технологий реально уже затрахал. Метания — признак отсутствия стратегии и/или воли и начало конца. B>>а ишак всё не дохет...
GIV>Дохнет, дохнет. Просто ишак большой попался.
Здравствуйте, FR, Вы писали:
FR>Да это понятно конечно. FR>Но память все равно бестолково зависает.
S>>и сохранения ссылки на b, поэтому какой-нибудь "альтернативный" GC тут ничем не поможет. Костыли по ссылки — защита от отдельных одарённых личностей, что не могут усвоить правило "подписался — отпишись".
FR>Это и есть ручное управление. FR>Утрированно и RAII в C++ и GC это только защита от отдельных одаренных личностей не способных на каждый malloc вызвать free
Масштаб проблемы мягко говоря разный.
Во-первых, события используются гораздо реже, чем просто выделение нового куска памяти.
Во-вторых, ситуаций, когда потребитель событий живет меньше источника событий еще меньше.
В-третьих, самое главное, для поиска таких утечек в управляемом коде даже на продакшене на рабочей системе требуется примерно минута-полторы (столько обычно уходит на запуск windbg и ввод пары-тройки тривиальных команд). То есть в реальной жизни это вообще не проблема.
То есть проблема утечек в .NET на событиях — это примерно как проблема медведей в городах России. Для иностранцев выглядит серьезно
лэт ми спик фром май харт
Re: No mention of either Silverlight or .NET on Windows 8
SL тормозной как Flash, оба они жрут батарейку и их нет на iPhone. Если поддержать HTML5- можно "бесплатно" получить рабочие приложения с яблофона (кроме нативных), и попытаться уравнять счет по их количеству. C# и Java на клиенте imho останутся в enterprise в силу инерции еще очень долго- типа оно уже написано и работает. На компах обычных людей оно не прижилось.
Re[5]: No mention of either Silverlight or .NET on Windows 8
Здравствуйте, blackhearted, Вы писали:
D>>>>маскарад технологий реально уже затрахал. Метания — признак отсутствия стратегии и/или воли и начало конца. B>>>а ишак всё не дохет...
GIV>>Дохнет, дохнет. Просто ишак большой попался.
B>Ждём-ждём... когда прогнозируются похороны?
Они уже идут. Этого ишака по частям хоронят, мобильное подразделения похоронили, браузер в реанимации, интернет проекты мертвые от рождения.
WBR, Igor Evgrafov
Re[20]: No mention of either Silverlight or .NET on Windows
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Да пусть хотят. ВВ>Добавьте веточку в фавориты, кстати. Я более чем уверен, что 64 бит на консолях следующего поколения не будет. Wii U даже не считаем. Только PS3/X360.
А об чем спор?
Вроде как и PS3 и Xbox360 и без того с самого начала 64-битные. Там система команд, если без ускорителя, от PowerPC, которые всегда 64-битные были.
Re[21]: No mention of either Silverlight or .NET on Windows
Здравствуйте, Michael7, Вы писали:
M>А об чем спор? M>Вроде как и PS3 и Xbox360 и без того с самого начала 64-битные. Там система команд, если без ускорителя, от PowerPC, которые всегда 64-битные были.
Речь о софтовой части. А какой там набор команд поддерживают PowerPC я даже без понятия — да это и неважно.
Re[8]: No mention of either Silverlight or .NET on Windows 8
Здравствуйте, Ночной Смотрящий, Вы писали:
CS>>Тем не менее количество приложений и бизнесс систем с GUI в browser на порядки превышает все что было создано на Winforms, WPF, etc.
НС>Пруфлинк?
JQuery это как минимум некий GUI programming — т.е. сайт есть приложение.
Оптимистическая оценка: было и есть 50,000 .NET приложений с .NET UI в любой форме.
Т.е. по самой оптимистичной оценке (для .NET) имеем разницу на два порядка.
Re[9]: No mention of either Silverlight or .NET on Windows 8
То, что находится по ссылке не имеет к XAML никакого отношения, по ссылке просто DSL выполненный в виде XML и предназначенный для использования в рамках одной конкретной либы
Здравствуйте, Visor2004, Вы писали:
FR>>XAML уже сейчас MS активно внедряет в WinAPI и соответственно в нативные приложения, например http://msdn.microsoft.com/en-us/library/dd316924(v=VS.85).aspx
V>То, что находится по ссылке не имеет к XAML никакого отношения, по ссылке просто DSL выполненный в виде XML и предназначенный для использования в рамках одной конкретной либы
В первом же абзаце там написано:
The Windows Ribbon framework is composed of two distinct, yet dependent, development platforms: a markup language based on Extensible Application Markup Language (XAML) to declare controls and their visual layout, and a C++ Component Object Model (COM)-based set of interfaces to define command functionality and application hooks.
Здравствуйте, FR, Вы писали:
FR>>>XAML уже сейчас MS активно внедряет в WinAPI и соответственно в нативные приложения, например http://msdn.microsoft.com/en-us/library/dd316924(v=VS.85).aspx V>>То, что находится по ссылке не имеет к XAML никакого отношения, по ссылке просто DSL выполненный в виде XML и предназначенный для использования в рамках одной конкретной либы FR>В первом же абзаце там написано:
Написано, что "based on", но фичи то несравнимы.
О нет, в новом мерседесе появятся подушки безопасности! О ремнях ни слова!! Они считают ремни устаревшими!!! Я лучше куплю жигули, там 30 лет ничего не меняется!
Re[9]: No mention of either Silverlight or .NET on Windows 8
CS>валидно как в XAML так и в HTML. Куча всяко разных тулкитов используют свои атрибуты вплоть до DSL в своих CS><script type="text/x-my-dsl">...</script> секциях.
Все это здорово и очень круто... Но, как бишь мне банальный рефакторинг переименованя выполнить в JS чтобы потом два часа не сидеть в файрбаге?
Здравствуйте, mrTwister, Вы писали:
S>>>и сохранения ссылки на b, поэтому какой-нибудь "альтернативный" GC тут ничем не поможет. Костыли по ссылки — защита от отдельных одарённых личностей, что не могут усвоить правило "подписался — отпишись".
FR>>Это и есть ручное управление. FR>>Утрированно и RAII в C++ и GC это только защита от отдельных одаренных личностей не способных на каждый malloc вызвать free
T>Масштаб проблемы мягко говоря разный. T>Во-первых, события используются гораздо реже, чем просто выделение нового куска памяти. T>Во-вторых, ситуаций, когда потребитель событий живет меньше источника событий еще меньше. T>В-третьих, самое главное, для поиска таких утечек в управляемом коде даже на продакшене на рабочей системе требуется примерно минута-полторы (столько обычно уходит на запуск windbg и ввод пары-тройки тривиальных команд). То есть в реальной жизни это вообще не проблема.
T>То есть проблема утечек в .NET на событиях — это примерно как проблема медведей в городах России. Для иностранцев выглядит серьезно
Как похоже на аргументацию про утечки памяти в плюсах.
Во-первых, память на вручную выделяется редко — чаще либо на стэке, либо в контейнере через аллокатор, либо как поле в классе.
Во-вторых, ситуаций, когда объект живёт дольше чем его создатель ещё меньше. (как правило отношения владения между объектами очевидны и память управляется умными указателями).
В-третьих, утечки ищутся на раз тем же Valgrind'ом. Или, если среда не настроена, тупым логированием в конструкторах/деструкторах.
Здравствуйте, Mazay, Вы писали:
M>Во-первых, память на вручную выделяется редко — чаще либо на стэке, либо в контейнере через аллокатор, либо как поле в классе.
Тем не менее это на порядки чаще, чем подписка на события
M>Во-вторых, ситуаций, когда объект живёт дольше чем его создатель ещё меньше. (как правило отношения владения между объектами очевидны и память управляется умными указателями). M>В-третьих, утечки ищутся на раз тем же Valgrind'ом. Или, если среда не настроена, тупым логированием в конструкторах/деструкторах.
И что, у кастомеров или на продакшене стоит Valgrind?
Здравствуйте, Mazay, Вы писали:
M>Аналогия про медведей в самый раз.
Ага, в самый раз. Не поверишь, но я вот прямо сейчас сижу в windbg и ковыряюсь в дампе, пришедшего от одного кастомера, у которого наш продукт внезапно начал падать по OutOfMemory. К несчастью, течет одна из неуправляемых куч, при этом я не могу даже разобрать чья эта куча (какому компоненту принадлежит). И ты мне будешь рассказывать про медведей?
Здравствуйте, Mazay, Вы писали:
M>Во-первых, память на вручную выделяется редко — чаще либо на стэке, либо в контейнере через аллокатор, либо как поле в классе. M>Во-вторых, ситуаций, когда объект живёт дольше чем его создатель ещё меньше. (как правило отношения владения между объектами очевидны и память управляется умными указателями).
Вот только такой образцово-показательный код на С++ при работе с памятью сосет как дешевая проститутка, по сравнению с .NET
И чтобы вытянуть производительность приходится прибегать к совсем небезопасным методам работы с памятью, что увеличивает число проблем с утечками, расстрелами памяти итп.
Re[2]: No mention of either Silverlight or .NET on Windows 8
Здравствуйте, Deprivator, Вы писали:
D>Здравствуйте, c-smile, Вы писали:
CS>>HTML/CSS/JS наше всё теперь опять.
D>все-таки надо быть очень нездоровым на голову человеком, чтобы предлагать променять тот же WPF/SilverLight на уродство JS... но с микрософта станется.. D>я всегда был виндовым человеком, но вот сейчас (если это окажется правдой), однозначно перейду, не знаю на что, но перейду. D>маскарад технологий реально уже затрахал. Метания — признак отсутствия стратегии и/или воли и начало конца.
Здравствуйте, Sinix, Вы писали:
nme>>Есть конкретные примеры когда возникают проблемы? S>Для начала — как мы будем их освобождать? Особенно если ресурс помечен x:Shared="false", или на source биндинга никто больше не ссылается, или у нас несколько биндингов по сложному пути (object[0].SomeProp/Prop2).
Подсчет ссылок никто не отменял.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Sinix, Вы писали:
S>Не останется. В unmanaged очень тяжело реализовать большую часть концепций wpf. Как минимум с ресурсами и биндингами будет очень много интересных вопросов.
В unmanaged, а точнее в С++ есть только две проблемы низкий уровень кода и возможность получить AV при любом неосторожном движении. Но за-то можно добиться меньшего потребления памяти, и как следствие, немного более отзывчивый интерфейс. Когда бабла немерено и есть много опытных С++-ников, это оказывается вполне себе решением.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re: No mention of either Silverlight or .NET on Windows 8
Спокойствие, только спокойствие. Почти уверен, что как и всегда это бывает с МС — это все домысли.
Ты очень точно предсказал слив IE, в свое время, но это не тот случай. Винда — это море кода. Переписать его в одночасье не под силу даже МС.
Думаю, что правду нужно читать не в Советских газетах блогах и желтой прессе, а в делах.
На мой взгляд в МС как всегда происходит одно и то же. С одной стороны клановая борьба разных групп разработки, хорошо описанная Роном Барком (бывшим редактором WDJ 10 лет назад):
Скрытый текст
История программных революций от Microsoft, вкратце: Сначала были Windows API и DLL Hell. Революцией №1 было DDE – помните, как ссылки позволили нам создавать статусные строки, отражающие текущую цену акций Microsoft? Примерно тогда же Microsoft создала ресурс VERSION INFO, исключающий DLL Hell. Но другая группа в Microsoft нашла в DDE фатальный недостаток – его писали не они!
Для решения этой проблемы они создали OLE (похожее на DDE, но другое), и я наивно вспоминаю докладчика на Microsoft-овской конференции, говорящего, что скоро Windows API перепишут как OLE API, и каждый элемент на экране будет ОСХ-ом. В OLE появились интерфейсы, исключающие DLL Hell. Помните болезнь с названием «по месту», при которой мы мечтали встроить все свои приложения в один (возможно, очень большой) документ Word? Где-то в то же время Microsoft уверовала в религию С++, возникла MFC решившая все наши проблемы еще раз.
Но OLE не собиралась, сложа руки смотреть на это, поэтому оно заново родилось под именем COM, и мы внезапно поняли, что OLE (или это было DDE?) будет всегда – и даже включает тщательно разработанную систему версий компонентов, исключающую DLL Hell. В это время группа отступников внутри Microsoft обнаружила в MFC фатальный недостаток – его писали не они! Они немедленно исправили этот недочет, создав ATL, который как MFC, но другой, и попытались спрятать все замечательные вещи, которым так упорно старалась обучить нас группа COM. Это заставило группу COM (или это было OLE?) переименоваться в ActiveX и выпустить около тонны новых интерфейсов (включая интерфейсы контроля версий, исключающие DLL Hell), а заодно возможность сделать весь код загружаемым через браузеры, прямо вместе с определяемыми пользователем вирусами (назло этим гадам из ATL!).
Группа операционных систем громким криком, как забытый средний ребенок, потребовала внимания, сказав, что нам следует готовиться к Cairo, некой таинственной хреновине, которую никогда не могли даже толком описать, не то, что выпустить. К их чести, следует сказать, что они не представляли концепции «System File Protection», исключающей DLL Hell. Но тут некая группа в Microsoft нашла фатальный недостаток в Java — её писали не они! Это было исправлено созданием то ли J, то ли Jole, а может, и ActiveJ (если честно, я просто не помню), точно такого же как Java, но другого. Это было круто, но Sun засудило Microsoft по какому-то дряхлому закону. Это была явная попытка задушить право Microsoft выпускать такие же продукты, как у других, но другие.
Помните менеджера по J/Jole/ActiveJ, стучащего по столу туфлей и говорящего, что Microsoft никогда не бросит этот продукт? Глупец! Все это означало только одно – недостаток внимания к группе ActiveX (или это был COM?). Эта невероятно жизнерадостная толпа вернулась с COM+ и MTS наперевес (может, это стоило назвать ActiveX+?). Непонятно почему к MTS не приставили «COM» или «Active» или «X» или «+» – они меня просто потрясли этим! Они также грозились добавить + ко всем модным тогда выражениям. Примерно тогда же кое-кто начал вопить про «Windows DNA» (почему не DINA) и «Windows Washboard», и вопил некоторое время, но все это почило раньше, чем все поняли, что это было.
К этому моменту Microsoft уже несколько лет с нарастающей тревогой наблюдала за интернет. Недавно они пришли к пониманию, что у Интернет есть фатальный недостаток: ну, вы поняли. И это приводит нас к текущему моменту и технологии .NET (произносится как «doughnut (пончик по-нашему)», но по-другому), похожей на Интернет, но с большим количеством пресс- релизов. Главное, что нужно очень четко понимать — .NET исключает DLL Hell.
В .NET входит новый язык, C#, (выясняется, что в Active++ Jspresso был фатальный недостаток, от которого он и помер). .NET включает виртуальную машину, которую будут использовать все языки (видимо, из-за фатальных недостатков в процессорах Интел). .NET включает единую систему защиты (есть все-таки фатальный недостаток в хранении паролей не на серверах Microsoft). Реально проще перечислить вещи, которых .NET не включает. .NET наверняка революционно изменит Windows-программирование... примерно на год.
С другой же стороны давит реальность и обратная совместимость.
С первым фактором все ясно, а вот второй стоит пояснить.
Даже в относительно отдельном продукте вроде Visual Studio много кода и много тех кто использует старые версии продукта. Переписать его в одночасье сложно и это может очень негативно повлиять на тех кто использовал продукт ранее. По сему процесс этот растягивается на долгие годы (а то и десятилетия).
Но процесс таки потихонечку идет. Студия с каждой версией избавляется от С++ заменяя его управляемым кодом. Думаю версии через 2-3 от С++ избавятся во все и после этого порвут со его наследием (совместимостью). COM поможет сгладить этот процесс (сделать обратную совместимость хоть в каком-то виде).
В случае успеха со студией дальше пойдут и другие продукты. К тому времени старая гвардия уйдет на пенсию и все расклады изменятся. Но будет это не скоро.
Теперь что касается Вынь АПИ. Ему вообще ничего не грозит. Винда останется анменеджед и с этим ужасным АПИ еще долгие десятилетия. Возможно будут появляться разные новые АПИ. Возможно что они будут предоставлять более приличный доступ к возможностям винды, но старый добрый CreateWindowEx умрет только с виндовс.
Так что все эти страхи — это всего лишь пурга поднятая разными пиарящимися товарищами.
Ну, будет какой-то новый АПИ на базе HTML 5 и жабастипте. Что это значит? А только то, что группа индусов, разработчиков IE нашла фатальный недостаток в других АПИ. Ну, вы знаете какой! (с)
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[10]: No mention of either Silverlight or .NET on Windows
Здравствуйте, hardcase, Вы писали:
H>Все это здорово и очень круто... Но, как бишь мне банальный рефакторинг переименованя выполнить в JS чтобы потом два часа не сидеть в файрбаге?
Ну, это — покрываешь тестами всю фигню со 100% coverage
Re[2]: No mention of either Silverlight or .NET on Windows 8
... VD>Ну, будет какой-то новый АПИ на базе HTML 5 и жабастипте. Что это значит? А только то, что группа индусов, разработчиков IE нашла фатальный недостаток в других АПИ. Ну, вы знаете какой! (с)
В деталях много чего не так, но принципы описаны правильно.
Re: No mention of either Silverlight or .NET on Windows 8
Silverlight — жив и поддерживает новые фичи Windows 8,
С# и VB — живы,
среды разработки — те же,
Expression Blend научился плюсом к XAML редактировать HTML5.
Re[5]: No mention of either Silverlight or .NET on Windows 8
Здравствуйте, Евгений Акиньшин, Вы писали:
ЕА>Именно так, мотыляния и сгубили. Так о том-то и речь, что микрософт в ту же игру играет:
ЕА>- все делаем на ВинФормз ЕА>- нет винформз устарел не будем его развивать, все делаем на WPF ЕА>- нет ну нафиг WPF, сильверлайт рулит ЕА>- нет сильверлайт забрасываем, "HTML5 is the way to go"
Ну так старые технологии-то остаются. Если они тебе подходят -- юзай. Другое дело, что на рынке востребованы уже другие. Ну так в этом жизнь. В переменах. И если теюе не нравятся перемены, то тебе надо просто немного другую отрасль IT выбрать. Ну, скажем в вычматы уйти и сидеть себе спокойно на фортране...
ЕА>знаю таких не ощутивших, ждавших по несколько лет 64-битный компилятор (выход которого откладывали не знаю сколько раз на моей памяти), а потом переписавших свои приложения на Си++, а также других не ощутивших, которые до сих пор ждут
Дык, это, одна из главных черт программиста -- адекватность в восприятии кода и его авторов. Может мне тоже, хочется, что бы Луна красного цвета была. Сижу вот, жду...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[7]: No mention of either Silverlight or .NET on Windows 8
Здравствуйте, Евгений Акиньшин, Вы писали:
ЕА>не пофигу, платформа должна развиваться и поддерживаться — иначе твое приложение в будущем не сможет использовать какие-нидь плюшки типа тач-скрина или 64бит, а это может быть критично, и заранее этого не предусмотришь, а все переписывать — это очень дорого, а иногда не реально дорого
Вроде как у дотнета нет проблем с интеромпом с нативом и с ОС...
Даже если в MS сойдут с ума и не станут поддерживать тачскрин из дотнета, то тут же кто-то третий напишет библу...
ЕА>ага, не прошло и 10 лет. или прошло
Дык зачем они ждали-то?
ЕА>некоторым по-зарез были нужны — я особо не вникал, но насколько я помню, речь шла о интеграции в експлорер в 64-битной винде и подобных вещах
Ну сделали бы переходник на более рассово-чистом компиляторе...
А разве 64-битный экспорер не умеет вызывать 32-е плагины?..
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[6]: No mention of either Silverlight or .NET on Windows 8
Здравствуйте, Erop, Вы писали:
E>Здравствуйте, Евгений Акиньшин, Вы писали:
ЕА>>Именно так, мотыляния и сгубили. Так о том-то и речь, что микрософт в ту же игру играет:
ЕА>>- все делаем на ВинФормз ЕА>>- нет винформз устарел не будем его развивать, все делаем на WPF ЕА>>- нет ну нафиг WPF, сильверлайт рулит ЕА>>- нет сильверлайт забрасываем, "HTML5 is the way to go"
E>Ну так старые технологии-то остаются. Если они тебе подходят -- юзай. Другое дело, что на рынке востребованы уже другие. Ну так в этом жизнь. В переменах. И если теюе не нравятся перемены, то тебе надо просто немного другую отрасль IT выбрать. Ну, скажем в вычматы уйти и сидеть себе спокойно на фортране...
не, это не по адресу — во-первых я как раз наоборот всегда учу новое, даже когда не надо , а во-вторых я в общем-то давно только руковожу разработкой, а код пишу уже исключительно как хобби
проблема вся в том, что технологии разработки иногда меняются быстрее, чем пишутся приложения, что не очень эффективно с точки зрения рационального использования труда программистов
Здравствуйте, Erop, Вы писали:
E>Вроде как у дотнета нет проблем с интеромпом с нативом и с ОС...
Нету. Интероп в дотнете самый мощный из всего, с чем я когда либо сталкивался.
ЕА>>некоторым по-зарез были нужны — я особо не вникал, но насколько я помню, речь шла о интеграции в експлорер в 64-битной винде и подобных вещах E>Ну сделали бы переходник на более рассово-чистом компиляторе...
расово.
E>А разве 64-битный экспорер не умеет вызывать 32-е плагины?..
Нет вроде.
Re[2]: No mention of either Silverlight or .NET on Windows 8
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Здравствуйте, mtnl, Вы писали:
M>>Silverlight — жив и поддерживает новые фичи Windows 8,
НС>С SL, увы, не все так просто.
А я так не понял, на чем теперь предполагается писать дектопный ГУЙ:
— Silverlight сдох
— WinRT штука классная, но его еще нет, судя повсему он будет поддерживаться только на вин8 и позиционируется только для метро приложений
— Все что на базе Win32 — напрямую сказано что легаси, в новых шелах типа метро поддерживаться не будет
— WPF далеко не универсален (жрет много ресурсов, долго стартует и требует установку 4-го фреймворка, который до сих не часть виндовз) — т.е. не всегда подойдет. Про его развитие не слово не сказали.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Уже сто раз обсасывалось. С тех пор ничего не поменялось, разве только Гатри окончательно убрали, тем самым поставив точку в бодании.
На BUILD показывали как превратить WP7 app в Metro app заменой нескольких using. Т.е. на silverlight вполне можно писать Metro apps. Так что я по прежнему не вижу проблемы с silverlight.
Re[4]: No mention of either Silverlight or .NET on Windows 8
Здравствуйте, Евгений Акиньшин, Вы писали:
ЕА>- Silverlight сдох
С чего бы это?
ЕА>- WinRT штука классная, но его еще нет, судя повсему он будет поддерживаться только на вин8 и позиционируется только для метро приложений
Что может помешать использовать его из любого приложения?
ЕА>- Все что на базе Win32 — напрямую сказано что легаси, в новых шелах типа метро поддерживаться не будет
Старый шелл тоже развивают. Они будут оба доступны.
ЕА>- WPF далеко не универсален (жрет много ресурсов, долго стартует и требует установку 4-го фреймворка, который до сих не часть виндовз) — т.е. не всегда подойдет. Про его развитие не слово не сказали.
Метро приложения будут писаться судя по всему на silverlight (такомже как на WP7). Silverlight постепенно расширяют, добавляя фичи из WPF.
Re[5]: No mention of either Silverlight or .NET on Windows 8
Здравствуйте, nme, Вы писали:
nme>Здравствуйте, Евгений Акиньшин, Вы писали:
ЕА>>- Silverlight сдох
nme>С чего бы это?
Никаких перспектив дальнейшего развития не видно. В винду его так и не включили. Микрософт больше его не продвигает, т.е. адопшион будет падать.
По слухам, в метро интерфейсе в браузере не запускается, и не известно будет ли. На WindowsPhone в браузере не запускается и похоже никогда не будет.
Никто больше не обещает, что это кросс-платформенная технология, а раз так, то какой смысл мириться с его ограничениями и писать на нем новые приложения?
Т.е. старые проекты естественно будем развивать, но вот начинать на нем писать что-то новое мне сейчас не хочется.
ЕА>>- WinRT штука классная, но его еще нет, судя повсему он будет поддерживаться только на вин8 и позиционируется только для метро приложений
nme>Что может помешать использовать его из любого приложения?
Врать не буду, я пока сам не щупал (никак не могу на виртуалке вин 8 поставить), но в блогах пишут, что десктопная и WinRT-я модели изолированы. И даже если можно, но там все будет заточенно под метро, на десктопе это может выглядеть инородным элементом. И даже если нет, то завязывать десктопный софт на АПи, доступное только под восьмеркой можно будет не скоро.
Но тут действительно вопрос открытый, я надеюсь что я ошибаюсь.
ЕА>>- Все что на базе Win32 — напрямую сказано что легаси, в новых шелах типа метро поддерживаться не будет
nme>Старый шелл тоже развивают. Они будут оба доступны.
ЕА>>- WPF далеко не универсален (жрет много ресурсов, долго стартует и требует установку 4-го фреймворка, который до сих не часть виндовз) — т.е. не всегда подойдет. Про его развитие не слово не сказали.
nme>Метро приложения будут писаться судя по всему на silverlight (такомже как на WP7). Silverlight постепенно расширяют, добавляя фичи из WPF.
Не совсем — в каждой реализации свои тараканы, под каждую придется твикать.
Итого имеем 4 очень похожие, но на практике не совсем совместимые платформы: Silverlight, WPF, WinRT, WP7.
Здравствуйте, Евгений Акиньшин, Вы писали: nme>>С чего бы это?
ЕА>Никаких перспектив дальнейшего развития не видно. В винду его так и не включили. Микрософт больше его не продвигает, т.е. адопшион будет падать.
Silverlight это один из способов написания Metro приложений...
ЕА>По слухам, в метро интерфейсе в браузере не запускается, и не известно будет ли. На WindowsPhone в браузере не запускается и похоже никогда не будет.
Надо не слухи слушать, а презентации смотреть. Там silverlight запускали в браузере...
ЕА>Никто больше не обещает, что это кросс-платформенная технология, а раз так, то какой смысл мириться с его ограничениями и писать на нем новые приложения?
Тот silverlight что используется в для Win8 и WP7 не переносим, но он не так значительно отличается от того что в браузере, а браузерный silverlight как минимум работает на маках.
ЕА>Врать не буду, я пока сам не щупал (никак не могу на виртуалке вин 8 поставить), но в блогах пишут, что десктопная и WinRT-я модели изолированы. И даже если можно, но там все будет заточенно под метро, на десктопе это может выглядеть инородным элементом.
Мне непонятно каким образом использование Communication & Data API из WinRT может выглядеть инородно на десктопе.
nme>>Метро приложения будут писаться судя по всему на silverlight (такомже как на WP7). Silverlight постепенно расширяют, добавляя фичи из WPF.
ЕА>Не совсем — в каждой реализации свои тараканы, под каждую придется твикать. ЕА>Итого имеем 4 очень похожие, но на практике не совсем совместимые платформы: Silverlight, WPF, WinRT, WP7.
Как минимум опыт при разработке под них вполне переносим. Да и значительная часть кода тоже.
Re[3]: No mention of either Silverlight or .NET on Windows 8
Здравствуйте, Ночной Смотрящий, Вы писали:
M>>Silverlight — жив и поддерживает новые фичи Windows 8,
НС>С SL, увы, не все так просто.
Насколько вижу бегло пробежав по заголовкам http://channel9.msdn.com/Events/BUILD/BUILD2011,
XAML для создания интерфейса приложений продолжает использоваться,
C# продолжает использоваться.
Так что если даже конкретно Silverlight захоронят, есть надежда, что определенное время наработки и опыт на SL ещё будут актуальными.
А вообще, педалирование в HTML5/JS впечатляет, с учетом того, что и Apple уделяет большое внимание Web Applications (которые имеют такую же иконку как приложение и работают в офлайне со своей базой данных) и вообще для большинства актуальных платформ делалки приложений с HTML5/JS внутри появились (phonegap, appcelerator).
Re[7]: No mention of either Silverlight or .NET on Windows 8
Здравствуйте, nme, Вы писали:
ЕА>>По слухам, в метро интерфейсе в браузере не запускается, и не известно будет ли. На WindowsPhone в браузере не запускается и похоже никогда не будет.
nme>Надо не слухи слушать, а презентации смотреть. Там silverlight запускали в браузере...
Синофский с Хакамовичем, наверно эту презентацию не видели, а слухи слушали, вот и пишут всякую ерунду в официальном блоге:
Здравствуйте, quwy, Вы писали:
Q>Здравствуйте, LGB, Вы писали:
CS>>>HTML/CSS/JS наше всё теперь опять. LGB>>Шо, опять?! (с) LGB>>А хранимые процедуры в SQL Server будут тоже теперь на HTML/JS? %-) Q>Мелко берете. С таким подходом скоро сам MS SQL Server будет на JS написан, а данные хранить станет исключительно в XML. Это ведь модно, а железо и так слишком быстрое.
нет.... модно NoSql+JSON
Re[8]: No mention of either Silverlight or .NET on Windows 8
Здравствуйте, Евгений Акиньшин, Вы писали:
ЕА>Синофский с Хакамовичем, наверно эту презентацию не видели, а слухи слушали, вот и пишут всякую ерунду в официальном блоге:
ЕА>Metro style browsing and plug-in free HTML5
Уже в Phone 7 (около года на рынке) веб-браузер сильверлайт-плагина не имеет, как и флеша и остальных.
При этом сами приложения таки пишутся на сильверлайте. И на Build приложение под интерфейс metro переделовали сильверлайтовые.
Т.е. что ИМХО наиболее вероятно, что сильверлайт для веба будут захоранивать, для десктопа — он (или его развитие) будет жить.
Re[4]: No mention of either Silverlight or .NET on Windows 8
Здравствуйте, Евгений Акиньшин, Вы писали:
ЕА>- WinRT штука классная, но его еще нет, судя повсему он будет поддерживаться только на вин8 и позиционируется только для метро приложений
WinRT давно есть. А вот новой технологии на ее основе пока нет.
ЕА>- Все что на базе Win32 — напрямую сказано что легаси, в новых шелах типа метро поддерживаться не будет
Будет. Еще очень долго будет.
ЕА>- WPF далеко не универсален
И тоже может сдохнуть.
ЕА>
Рано пока о чем то предметно говорить.
Re[4]: No mention of either Silverlight or .NET on Windows 8
Здравствуйте, Евгений Акиньшин, Вы писали:
ЕА>Синофский с Хакамовичем, наверно эту презентацию не видели, а слухи слушали, вот и пишут всякую ерунду в официальном блоге:
ЕА>Metro style browsing and plug-in free HTML5
Да, только что глянул keynote ещё раз, они действительно запускали в десткопном варианте IE.
Re[5]: No mention of either Silverlight or .NET on Windows 8
Здравствуйте, LGB, Вы писали:
LGB>Здравствуйте, c-smile, Вы писали:
CS>>HTML/CSS/JS наше всё теперь опять.
LGB>Шо, опять?! (с) LGB>А хранимые процедуры в SQL Server будут тоже теперь на HTML/JS? %-)
MongoDb, CoutchDb — хранимые процедуры пишутся на JS
Re[6]: No mention of either Silverlight or .NET on Windows 8
Здравствуйте, nme, Вы писали:
НС>>XAML или его подобие — да. Но это малозначительная фиговинка. nme>Для тех, кто разрабатывает под Silverlight или WPF, далеко не малозначительная имхо.
Это только для тех, кто не очень понимает, как устроен SL или WPF.
Re[7]: No mention of either Silverlight or .NET on Windows 8
Здравствуйте, nme, Вы писали:
nme>Ты видимо очень понимаешь.
Перешел на личности — слил.
nme> Просвяти в чём дело.
Чтобы понять, что XAML это просто еще один формат сериализации, дружественный к рукопашному чтению, и что он составляет 0.1% от функционала SL/WPF, достаточно прочтения базовой документации. А все остальное, даже компонентная модель WFP — в нативном Metro свое собственное.
Re[9]: No mention of either Silverlight or .NET on Windows 8
Здравствуйте, Ночной Смотрящий, Вы писали:
НС> Перешел на личности — слил.
Не было никакого перехода на личности. Не надо выдёргивать фразы из контекста.
НС>Чтобы понять, что XAML это просто еще один формат сериализации, дружественный к рукопашному чтению, и что он составляет 0.1% от функционала SL/WPF, достаточно прочтения базовой документации. А все остальное, даже компонентная модель WFP — в нативном Metro свое собственное.
В Win8/WP7 поддерживаются стили/темплейты/биндинг?
Re[10]: No mention of either Silverlight or .NET on Windows
Здравствуйте, Ночной Смотрящий, Вы писали:
nme>>В Win8/WP7 поддерживаются стили/темплейты/биндинг?
НС>Документация на WP7 свободно доступна, а о Metro говорить рано. Впрочем, в последнем все одно реализация этих фич будет совершенно иная.
С точки зрения программиста пишущего XAML будут различия?
Re[12]: No mention of either Silverlight or .NET on Windows
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Здравствуйте, nme, Вы писали:
nme>>С точки зрения программиста пишущего XAML будут различия?
НС>Я не знаю кто такой "программист пишущий XAML", а с точки зрения разработчика под Metro — обязательно будут.
Ещё раз. Я хочу задать внешний вид приложения (оконное приложение на десктопе, полноэкранное в метро), для этого пишу XAML со стилями и теплейтами. Есть примеры когда XAML будет разный для WP7, Win8 и Silverlight (не считая различий в контролах)?
Re[19]: No mention of either Silverlight or .NET on Windows
Здравствуйте, nme, Вы писали:
nme>Здравствуйте, Ночной Смотрящий, Вы писали:
НС>>Здравствуйте, nme, Вы писали:
nme>>>С точки зрения программиста пишущего XAML будут различия?
НС>>Я не знаю кто такой "программист пишущий XAML", а с точки зрения разработчика под Metro — обязательно будут.
nme>Ещё раз. Я хочу задать внешний вид приложения (оконное приложение на десктопе, полноэкранное в метро), для этого пишу XAML со стилями и теплейтами. Есть примеры когда XAML будет разный для WP7, Win8 и Silverlight (не считая различий в контролах)?
Лучше скажи, есть ли примеры где код одинаковый, сложнее "Goodbye world"? Как раз Xaml не проблема сделать разный, все равно для разных форм факторов, чуть-чуть разный интерфейс получается. Хуже то, что объектные модели ГУИ тоже разные, хотя и похожие, и в результате попытка сделать например контрол, который скомпилиться для всех платформ, вылливается в IFDEF-ы на каждом шагу.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, c-smile, Вы писали:
CS>>Завершился очередной виток спирали. CS>>http://www.theregister.co.uk/2011/06/06/windows_tablets_without_silverlight_dot_net/ CS>>Вот такие вот дела. Sic transit gloria mundi... CS>>HTML/CSS/JS наше всё теперь опять.
VD>Спокойствие, только спокойствие. Почти уверен, что как и всегда это бывает с МС — это все домысли. VD>Ты очень точно предсказал слив IE, в свое время, но это не тот случай. Винда — это море кода. Переписать его в одночасье не под силу даже МС. VD>Думаю, что правду нужно читать не в Советских газетах блогах и желтой прессе, а в делах. VD>На мой взгляд в МС как всегда происходит одно и то же. С одной стороны клановая борьба разных групп разработки, хорошо описанная Роном Барком (бывшим редактором WDJ 10 лет назад): VD>С другой же стороны давит реальность и обратная совместимость. VD>С первым фактором все ясно, а вот второй стоит пояснить. VD>Даже в относительно отдельном продукте вроде Visual Studio много кода и много тех кто использует старые версии продукта. Переписать его в одночасье сложно и это может очень негативно повлиять на тех кто использовал продукт ранее. По сему процесс этот растягивается на долгие годы (а то и десятилетия). VD>Но процесс таки потихонечку идет. Студия с каждой версией избавляется от С++ заменяя его управляемым кодом. Думаю версии через 2-3 от С++ избавятся во все и после этого порвут со его наследием (совместимостью). COM поможет сгладить этот процесс (сделать обратную совместимость хоть в каком-то виде). VD>В случае успеха со студией дальше пойдут и другие продукты. К тому времени старая гвардия уйдет на пенсию и все расклады изменятся. Но будет это не скоро. VD>Теперь что касается Вынь АПИ. Ему вообще ничего не грозит. Винда останется анменеджед и с этим ужасным АПИ еще долгие десятилетия. Возможно будут появляться разные новые АПИ. Возможно что они будут предоставлять более приличный доступ к возможностям винды, но старый добрый CreateWindowEx умрет только с виндовс. VD>Так что все эти страхи — это всего лишь пурга поднятая разными пиарящимися товарищами. VD>Ну, будет какой-то новый АПИ на базе HTML 5 и жабастипте. Что это значит? А только то, что группа индусов, разработчиков IE нашла фатальный недостаток в других АПИ. Ну, вы знаете какой! (с)
Хочеться сделать несколько замечаний:
1. Насчет силверлайта в восьмерке — попробуйте воспользоваться сайтом с сильверлайтом и все станет на свои места.
2. Студия от С++ никогда не избавлялась вообще, и сейчас наоборот начала его развивать даже активней. Ренесанс и всякие такие штуки. Одно только впихивание xaml в разработку на нем чего стоит.
3. "АПИ на базе HTML 5 и жабастипте"
3.1 Речь в статье шла о подержке браузером плагинов и html5
3.2 Таки есть это новое api — WinRT. Но... и для C++ и для C# и для JS оно идентично. С первого взгляда не сразу осознаешь на каком же языке написан код — настолько похоже. И при этом имееться полная совместимость со старым кодом на этих языках.
Майкрософт в этот раз извернулся как никогда — использование новых апи может быть обусловленно только желанием использовать их фишки или необходимостью создания метро-интерфейса. Со старым кодом совместимость полная. За исключением некоторого проседания производительности в gdi. Но это dp, а не релиз.
Re: No mention of either Silverlight or .NET on Windows 8
Вы верно шутите приводя эту жолтую прессу.
1. Зайдите из браузера восьмерки на сайт с сильверлайтом — убедитесь, что оно работает. Или посмотрите презентации, где приложения для winPhone перекомпилируеться под win8.
2. В статье есть только вырваные из контекста цитаты и какой то выдуманый бред. А контекст он меняет о-очень многое.
3. HTML5 просто стало одной из трех технологий, одинаково подерживаемых майкрософтом. Все что есть в JS под Win8 — это WinRT. И в полной мере он есть и в C# и в C++. В дополнение ко всему тому, что там уже было.
4. Ну Майкрософт же выложил кучу видиозаписей докладов. Куча примеров в 11 студии из win8 dp уже есть и появляеться. Зачем вы читаете такой бред?
Кстати c-smile, вам багрепорт: sciter 2 developer preview (вроде как последний) имеет некоторую деградацию (раза в 2-3) в скорости анимации под восьмерку на приложеных к нему примерах (я на табах смотрел).
Re[15]: No mention of either Silverlight or .NET on Windows
Здравствуйте, Евгений Акиньшин, Вы писали:
nme>>Ещё раз. Я хочу задать внешний вид приложения (оконное приложение на десктопе, полноэкранное в метро), для этого пишу XAML со стилями и теплейтами. Есть примеры когда XAML будет разный для WP7, Win8 и Silverlight (не считая различий в контролах)?
ЕА>Лучше скажи, есть ли примеры где код одинаковый, сложнее "Goodbye world"? Как раз Xaml не проблема сделать разный, все равно для разных форм факторов, чуть-чуть разный интерфейс получается. Хуже то, что объектные модели ГУИ тоже разные, хотя и похожие, и в результате попытка сделать например контрол, который скомпилиться для всех платформ, вылливается в IFDEF-ы на каждом шагу.
Речь вообще не о идентичности кода, а о переносимости опыта разработки.. Я считаю, что тем кто работал с WPF/Silverlight будет довольно легко начать писать под Metro, особенно по сравнению с теми, кто не знаком с идеями лежащими в осове WPF.
Re[3]: No mention of either Silverlight or .NET on Windows 8
Здравствуйте, 11molniev, Вы писали:
1>Хочеться сделать несколько замечаний: 1>1. Насчет силверлайта в восьмерке — попробуйте воспользоваться сайтом с сильверлайтом и все станет на свои места. 1>2. Студия от С++ никогда не избавлялась вообще, и сейчас наоборот начала его развивать даже активней. Ренесанс и всякие такие штуки. Одно только впихивание xaml в разработку на нем чего стоит.
Речь не о поддержке С++ в студии, а о коде самой студии. Вот он постоянно переезжает на managed. Почти весь новый код — managed, а сейчас и старый начал активно переписываться. Редактор кода тому хороший пример. Ирония ситуации в том, что самый неприятный и большой массив unmanaged кода в студии — поддержка managed языков, а unmanaged С++ поддерживается заметно большим количеством managed кода.
1>3.2 Таки есть это новое api — WinRT. Но... и для C++ и для C# и для JS оно идентично.
И бинарное описание этого API тоже универсально, что важно. Скрещение этой универсальности и нового интеропа из 4 фреймворка обеспечивает очень прозрачную интеграцию. Но это не означает, что все вообще гладко — одно наличие/отсутствие GC уже вносит много интересных моментов.
Re[9]: No mention of either Silverlight or .NET on Windows 8
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Чтобы понять, что XAML это просто еще один формат сериализации, дружественный к рукопашному чтению, и что он составляет 0.1% от функционала SL/WPF, достаточно прочтения базовой документации. А все остальное, даже компонентная модель WFP — в нативном Metro свое собственное.
"not all of the .NET APIs are present (File I/O, Sockets), many were moved and others were introduced to integrate with WinRT."
"You might be thinking that you can use some trick (referencing the GAC library instead of the compiler reference or using reflection to get to private APIs, or P/Invoking into Win32). But all of those uses will be caught by AppStore review application and you wont be able to publish your app through Microsoft's store."
Re[2]: No mention of either Silverlight or .NET on Windows 8
Здравствуйте, 11molniev, Вы писали:
1>Кстати c-smile, вам багрепорт: sciter 2 developer preview (вроде как последний) имеет некоторую деградацию (раза в 2-3) в скорости анимации под восьмерку на приложеных к нему примерах (я на табах смотрел).
Драйвер дисплея поставь нормальный. Без него даже в MetroUI работать невозможно.
Re[3]: No mention of either Silverlight or .NET on Windows 8
Здравствуйте, c-smile, Вы писали:
CS>Здравствуйте, 11molniev, Вы писали:
1>>Кстати c-smile, вам багрепорт: sciter 2 developer preview (вроде как последний) имеет некоторую деградацию (раза в 2-3) в скорости анимации под восьмерку на приложеных к нему примерах (я на табах смотрел).
CS>Драйвер дисплея поставь нормальный. Без него даже в MetroUI работать невозможно.
VMWare Workstation 8 DP + VmWare Tools
Смутило, что метро и вся графика работает нормально. И да, вы правы насчет драйверов, в dp они ещё сырые — обновил tools на виртуалке с семеркой и получил такой же результат. Извиняюсь за беспокойство.
Успешной работы над sciter-ом!
Re[4]: No mention of either Silverlight or .NET on Windows 8
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Скрещение этой универсальности и нового интеропа из 4 фреймворка обеспечивает очень прозрачную интеграцию.
Похоже я что-то упустил. Что это за "новый интероп"?
Re[4]: No mention of either Silverlight or .NET on Windows 8
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Речь не о поддержке С++ в студии, а о коде самой студии. Вот он постоянно переезжает на managed. Почти весь новый код — managed, а сейчас и старый начал активно переписываться. Редактор кода тому хороший пример. Ирония ситуации в том, что самый неприятный и большой массив unmanaged кода в студии — поддержка managed языков, а unmanaged С++ поддерживается заметно большим количеством managed кода.
Кхм. Мне известно только о переписывании части, касающийся редактора на wpf. Сами компиляторы/линкеры/и прочии тулзы вроде как Сишные и менять это вряд ли будут. Хотя с удовольствием выслушаю иную информацию. Что же вообще касается переписывания студии на managet — то не думаю, что это будет что либо значить для разработчиков ближайшее десятилетие. Да и с учетом разницы между новым С++ и тем, что было раньше, он догоняет javabase языки.
НС>И бинарное описание этого API тоже универсально, что важно. Скрещение этой универсальности и нового интеропа из 4 фреймворка обеспечивает очень прозрачную интеграцию. Но это не означает, что все вообще гладко — одно наличие/отсутствие GC уже вносит много интересных моментов.
Можно подробней о интересных моментах с сборником мусора? Мне в голову не приходит пример возможных проблем, вроде как майкрософт неплохо извернулся и позаботился о подобных вопросах.
Re[5]: No mention of either Silverlight or .NET on Windows 8
Здравствуйте, MxMsk, Вы писали:
НС>>Скрещение этой универсальности и нового интеропа из 4 фреймворка обеспечивает очень прозрачную интеграцию. MM>Похоже я что-то упустил. Что это за "новый интероп"?
Здравствуйте, 11molniev, Вы писали:
1>Кхм. Мне известно только о переписывании части, касающийся редактора на wpf.
Т.е., скажем, про новый редактор в 10 студии ты не в курсе? И про Roslyn никогда не слышал?
1> Сами компиляторы/линкеры/и прочии тулзы вроде как Сишные и менять это вряд ли будут.
Компиляторы да, сишные. Тулзы — разные. MSBuild, к примеру (слышал про такую тулзу?) полностью managed. Насчет менять — компиляторы шарпа и VB переписывают. С++ вряд ли переписывать будут.
1>Что же вообще касается переписывания студии на managet — то не думаю, что это будет что либо значить для разработчиков ближайшее десятилетие.
Мысль непонятна.
1>Можно подробней о интересных моментах с сборником мусора?
Начнем с того, что для неуправляемых компонентных моделей нужен либо подсчет ссылок, либо какая нибудь хитрюще-специальная стратегия управления памятью. А в managed языках этого нафик не надо.
1> Мне в голову не приходит пример возможных проблем, вроде как майкрософт неплохо извернулся и позаботился о подобных вопросах.
Как не изворачивайся, а в unamanaged коде ничего принципиально лучше СОМ ты не получишь.
Re[6]: No mention of either Silverlight or .NET on Windows 8
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Здравствуйте, 11molniev, Вы писали:
1>>Кхм. Мне известно только о переписывании части, касающийся редактора на wpf.
НС>Т.е., скажем, про новый редактор в 10 студии ты не в курсе? И про Roslyn никогда не слышал?
Кхм. Выделил жирным, как бы в курсе. Про roslyn — к этому все идет ещё версии толи с первой толи со второй, от развития песочниц. И де факто, вопрос тут именно в предоставлении компилятора как части платформы, а не переписывании кода.
1>> Сами компиляторы/линкеры/и прочии тулзы вроде как Сишные и менять это вряд ли будут.
НС>Компиляторы да, сишные. Тулзы — разные. MSBuild, к примеру (слышал про такую тулзу?) полностью managed. Насчет менять — компиляторы шарпа и VB переписывают. С++ вряд ли переписывать будут.
Не только слышал, но и пользую такую тулзу. За Андресом вообще было замечено написание билдера на дельфях)) Компилятор языка на самом языке — это нормально + Андрес же хочет предоставлять его как часть платформы, что то же кажется интересным. Хотя с учетом этого да, я готов с вами согласиться о переписывании части студии на С#. Когда писал предыдущее сообщение в голову пришел одна оболочка и все.
1>>Что же вообще касается переписывания студии на managet — то не думаю, что это будет что либо значить для разработчиков ближайшее десятилетие.
НС>Мысль непонятна.
Я к тому, что влияния на вашу деятельность факт написания студии на C# или на C++ ближайшее десятилетие не повлияет никак.
1>>Можно подробней о интересных моментах с сборником мусора?
НС>Начнем с того, что для неуправляемых компонентных моделей нужен либо подсчет ссылок, либо какая нибудь хитрюще-специальная стратегия управления памятью. А в managed языках этого нафик не надо.
Вы смотрели доклады? Для WinRT в C++ активно юзаються C++0x + Ещё расширения МС (насчет второго не уверен, со стандартом ещё не знакомился детально). В стиле new ==> ref new. В итоге подсчет ссылок как раз такие есть и работает. Вообще С++ из 11 студии стал весьма близок к языкам со javabase языкам — только вместо gc области видимости и shared_ptr. Всякие фишки вроде автоматического выведения типов, прямого взаимодействия stl и winRT. В общем все выглядит весьма интересно.
Вообще то в managed подсчет ссылок вроде как нужен кстати. GC же должен как то работать). А стратегий WinRT насколько я понимаю является работа через деструктор.
1>> Мне в голову не приходит пример возможных проблем, вроде как майкрософт неплохо извернулся и позаботился о подобных вопросах.
НС>Как не изворачивайся, а в unamanaged коде ничего принципиально лучше СОМ ты не получишь.
Ну-у как поглядеть. Если сравнивать COM код и WinRT код, то выбор однозначный в пользу второго. Вопрос не принципов а поддержки со стороны языка.
Re[7]: No mention of either Silverlight or .NET on Windows 8
Здравствуйте, 11molniev, Вы писали:
НС>>Т.е., скажем, про новый редактор в 10 студии ты не в курсе? И про Roslyn никогда не слышал? 1>Кхм. Выделил жирным, как бы в курсе. Про roslyn — к этому все идет ещё версии толи с первой толи со второй
Жаль, тогда даже Хейлсберг об этом был не в курсе, и на прямой вопрос в 2007 году отвечал, что нет, не будет ничего похожего.
1>от развития песочниц
Каких песочниц?
1>. И де факто, вопрос тут именно в предоставлении компилятора как части платформы, а не переписывании кода.
Компилятор с первой версии — часть платформы, причем даже не студии, а рантайма. О чем ты? А Розлин это именно переписывание языковых пакетов для C# и VB и унификация их с новым компилятором. Больно тяжело стало поддерживать и править текущий вариант, релизы студии из-за этого на пару лет от компиляторов отстают.
1>Не только слышал, но и пользую такую тулзу.
Вот видишь
1> За Андресом вообще было замечено написание билдера на дельфях
Опять не понял мысль.
1>)) Компилятор языка на самом языке — это нормально + Андрес же хочет предоставлять его как часть платформы, что то же кажется интересным.
Тебя обманули — Андерс как раз не хочет. И CaaS это пока что предполагается частью студии, а не платформы.
1> Хотя с учетом этого да, я готов с вами согласиться о переписывании части студии на С#.
Да уж сложно не согласиться с очевидным — в полной студии managed кода процентов 80, не меньше. И с каждым релизом его доля растет.
1>Я к тому, что влияния на вашу деятельность факт написания студии на C# или на C++ ближайшее десятилетие не повлияет никак.
Смелое утверждение. И неверное. На мою деятельность точно повлияет. Но вот при чем тут моя деятельность — вот это вопрос.
НС>>Начнем с того, что для неуправляемых компонентных моделей нужен либо подсчет ссылок, либо какая нибудь хитрюще-специальная стратегия управления памятью. А в managed языках этого нафик не надо. 1>Вы смотрели доклады?
Да
1> Для WinRT в C++ активно юзаються C++0x + Ещё расширения МС (насчет второго не уверен, со стандартом ещё не знакомился детально).
Это никакого отношения к GC не имеет.
1> В стиле new ==> ref new. В итоге подсчет ссылок как раз такие есть и работает.
Верно. А для managed API никакого подсчета ссылок не нужно. Совсем.
1>Вообще то в managed подсчет ссылок вроде как нужен кстати
Для работы с unmanaged — да, нужен, хотя и довольно специфичный. А вот для managed — не нужен.
1>GC же должен как то работать
Т.е. что такое mark&sweep ты тоже не в курсе. Так и запишем.
1>). А стратегий WinRT насколько я понимаю является работа через деструктор.
А деструкторов в шарпе и VB нет, вот незадача.
Re[8]: No mention of either Silverlight or .NET on Windows 8
Здравствуйте, Ночной Смотрящий, Вы писали:
1>>). А стратегий WinRT насколько я понимаю является работа через деструктор.
НС>А деструкторов в шарпе и VB нет, вот незадача.
С чего это вдруг?
лэт ми спик фром май харт
Re[9]: No mention of either Silverlight or .NET on Windows 8
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Здравствуйте, 11molniev, Вы писали:
НС>>>Т.е., скажем, про новый редактор в 10 студии ты не в курсе? И про Roslyn никогда не слышал? 1>>Кхм. Выделил жирным, как бы в курсе. Про roslyn — к этому все идет ещё версии толи с первой толи со второй
НС>Жаль, тогда даже Хейлсберг об этом был не в курсе, и на прямой вопрос в 2007 году отвечал, что нет, не будет ничего похожего.
А в 2008 уже говорил, что все будет.
1>>от развития песочниц
НС>Каких песочниц?
Домены безопасности.
1>>. И де факто, вопрос тут именно в предоставлении компилятора как части платформы, а не переписывании кода.
НС>Компилятор с первой версии — часть платформы, причем даже не студии, а рантайма. О чем ты? А Розлин это именно переписывание языковых пакетов для C# и VB и унификация их с новым компилятором. Больно тяжело стало поддерживать и править текущий вариант, релизы студии из-за этого на пару лет от компиляторов отстают.
А я кстати не понял. Разве компилятор C# не написан на C#?: http://blogs.msdn.com/b/jmstall/archive/2005/02/06/368192.aspx
1>>Не только слышал, но и пользую такую тулзу.
НС>Вот видишь
1>> За Андресом вообще было замечено написание билдера на дельфях
НС>Опять не понял мысль.
До Microsoft-a работал этот очень замечательный человек в borlan-e. И был главным архитектором Delphi до 7 версии (после которой она загнулась). А когда все понравились первые версии делфи сделал C++ Builder. но вот плюснутый компилятор там вроде как писан на паскале. Ну сама иде и библиотеки точно во всяком случае.
1>>)) Компилятор языка на самом языке — это нормально + Андрес же хочет предоставлять его как часть платформы, что то же кажется интересным.
НС>Тебя обманули — Андерс как раз не хочет. И CaaS это пока что предполагается частью студии, а не платформы.
На всего, что выше посмотрю пруфы и отпишусь завтра/послезавтра. Может и правда путаю.
1>> Хотя с учетом этого да, я готов с вами согласиться о переписывании части студии на С#. НС>Да уж сложно не согласиться с очевидным — в полной студии managed кода процентов 80, не меньше. И с каждым релизом его доля растет.
Доступа к её исходникам не имею, так что могу развести руками — скока процентов не считал. 1>>Я к тому, что влияния на вашу деятельность факт написания студии на C# или на C++ ближайшее десятилетие не повлияет никак.
НС>Смелое утверждение. И неверное. На мою деятельность точно повлияет. Но вот при чем тут моя деятельность — вот это вопрос.
Действительно смело)) На деятельность большинства программистов не повлияет. Для нововведений требуется время. А если майкрософт совершит револючию и завтра откажется от С++, то многие могут отказаться и от майкрософта)) Да и совместимость опять же. Поэтому я предполагаю наличие у МС С++ ещё хотя б 9-10 лет.
НС>>>Начнем с того, что для неуправляемых компонентных моделей нужен либо подсчет ссылок, либо какая нибудь хитрюще-специальная стратегия управления памятью. А в managed языках этого нафик не надо. 1>>Вы смотрели доклады?
НС>Да
1>> Для WinRT в C++ активно юзаються C++0x + Ещё расширения МС (насчет второго не уверен, со стандартом ещё не знакомился детально).
НС>Это никакого отношения к GC не имеет.
WinRT gc и не нужен вроде как. Фактически память освобождается в деструкторах. За счет ухищрений с умными указателями и областями видимости утечки представляются возможными только при повышенной криворукости.
1>> В стиле new ==> ref new. В итоге подсчет ссылок как раз такие есть и работает.
НС>Верно. А для managed API никакого подсчета ссылок не нужно. Совсем.
1>>Вообще то в managed подсчет ссылок вроде как нужен кстати
НС>Для работы с unmanaged — да, нужен, хотя и довольно специфичный. А вот для managed — не нужен.
1>>GC же должен как то работать
НС>Т.е. что такое mark&sweep ты тоже не в курсе. Так и запишем.
Ндас. Ты не поверишь, но я такой алгоритм даже применял в сишном проекте))) Только не дерево с пометками а время последнего использования брал, плюс убиение в несколько этапов. Теперь хоть буду знать как называется. Хотя с gc в шарпе и правда промахнулся. Не приходилось как то активно взаимодействовать с сборкой мусора в дотнете.
1>>). А стратегий WinRT насколько я понимаю является работа через деструктор.
НС>А деструкторов в шарпе и VB нет, вот незадача.
Кхм. Параграф 10.13 спецификации шарпа просто в шоке. Вот так незатейливо вы его запамятовали, вот незадача. Нет деструктора с явным вызовом при выходе из области видимости. И есть деструктор (как называется в документации) или финализатор (как в умных книжках) который вызывает сам gc.
Re[9]: No mention of either Silverlight or .NET on Windows 8
Здравствуйте, 11molniev, Вы писали:
1> До Microsoft-a работал этот очень замечательный человек в borlan-e. И был главным архитектором Delphi до 7 версии (после которой она загнулась). А когда все понравились первые версии делфи сделал C++ Builder. но вот плюснутый компилятор там вроде как писан на паскале.
Это не так. Компиляторы там на сях написаны, и дельфийский тоже.
1> Ну сама иде и библиотеки точно во всяком случае.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Здравствуйте, mrTwister, Вы писали:
НС>>>А деструкторов в шарпе и VB нет, вот незадача.
T>>С чего это вдруг?
НС>Да вот так вот. На всякий случай — финалайзеры это не деструкторы.
Конечно. Зато IDisposable::Destroy вполне себе деструктор.
лэт ми спик фром май харт
Re[11]: No mention of either Silverlight or .NET on Windows
Здравствуйте, 11molniev, Вы писали:
1>>>от развития песочниц
НС>>Каких песочниц? 1>Домены безопасности.
Это чего еще за зверь? Про домены приложения знаю, про домены безопасности первый раз слышу.
1>А я кстати не понял. Разве компилятор C# не написан на C#?:
Который? Текущий нет, не на C#. На С++. Будущий да, на C#.
1>>> За Андресом вообще было замечено написание билдера на дельфях
НС>>Опять не понял мысль. 1>До Microsoft-a работал этот очень замечательный человек в borlan-e.
Все в курсе.
1> И был главным архитектором Delphi до 7 версии (после которой она загнулась). А когда все понравились первые версии делфи сделал C++ Builder.
История была несколько сложнее.
1> но вот плюснутый компилятор там вроде как писан на паскале.
Боюсь, там даже компилятор Дельфи не был на Паскале написан.
НС>>Смелое утверждение. И неверное. На мою деятельность точно повлияет. Но вот при чем тут моя деятельность — вот это вопрос.
1>Действительно смело)) На деятельность большинства программистов не повлияет. Для нововведений требуется время. А если майкрософт совершит револючию и завтра откажется от С++, то многие могут отказаться и от майкрософта))
Никто не говорил про отказ от С++. Речь про вполне конкретные вещи — код студии.
НС>>Это никакого отношения к GC не имеет. 1>WinRT gc и не нужен вроде как. Фактически память освобождается в деструкторах. За счет ухищрений с умными указателями и областями видимости утечки представляются возможными только при повышенной криворукости.
Ты опять не понял. В C# нет автоматических деструкторов и умных указателей там тоже нет.
НС>>А деструкторов в шарпе и VB нет, вот незадача. 1>Кхм. Параграф 10.13 спецификации шарпа просто в шоке. Вот так незатейливо вы его запамятовали, вот незадача. Нет деструктора с явным вызовом при выходе из области видимости. И есть деструктор (как называется в документации) или финализатор (как в умных книжках) который вызывает сам gc.
Финалайзер это не деструктор даже близко. В спецификации к шарпу — ошибка.
Re[12]: No mention of either Silverlight or .NET on Windows
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Здравствуйте, mrTwister, Вы писали:
T>>Конечно. Зато IDisposable::Destroy вполне себе деструктор.
НС>Тоже нет.
Почему нет? А создатели C++\CLI об этом знают?
лэт ми спик фром май харт
Re[13]: No mention of either Silverlight or .NET on Windows
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Здравствуйте, 11molniev, Вы писали:
1>>>>от развития песочниц
НС>>>Каких песочниц? 1>>Домены безопасности.
НС>Это чего еще за зверь? Про домены приложения знаю, про домены безопасности первый раз слышу.
Перепутал.
1>>А я кстати не понял. Разве компилятор C# не написан на C#?:
НС>Который? Текущий нет, не на C#. На С++. Будущий да, на C#.
Я привел ссылку на блог разработчика, где он рапортует "Source for a C# compiler written in pure C#.", за 2005 год. Откуда ваши сведения о написании компилятора C# на языке C++?
1>>>> За Андресом вообще было замечено написание билдера на дельфях
НС>>>Опять не понял мысль. 1>>До Microsoft-a работал этот очень замечательный человек в borlan-e.
НС>Все в курсе.
1>> И был главным архитектором Delphi до 7 версии (после которой она загнулась). А когда все понравились первые версии делфи сделал C++ Builder.
НС>История была несколько сложнее.
В двух предложениях не распишешь.
1>> но вот плюснутый компилятор там вроде как писан на паскале.
НС>Боюсь, там даже компилятор Дельфи не был на Паскале написан.
Пруфов не могу найти ни на первое ни на второе.
НС>>>Смелое утверждение. И неверное. На мою деятельность точно повлияет. Но вот при чем тут моя деятельность — вот это вопрос.
1>>Действительно смело)) На деятельность большинства программистов не повлияет. Для нововведений требуется время. А если майкрософт совершит револючию и завтра откажется от С++, то многие могут отказаться и от майкрософта))
НС>Никто не говорил про отказ от С++. Речь про вполне конкретные вещи — код студии.
Переписывание кода студии на C# — означает отказ С++ для студии. Отказ от подержи языка на котором написана среда разработки для него намекает на перспективу отказа от самого языка для платформы. В чем мои умозаключения неверны?
НС>>>Это никакого отношения к GC не имеет. 1>>WinRT gc и не нужен вроде как. Фактически память освобождается в деструкторах. За счет ухищрений с умными указателями и областями видимости утечки представляются возможными только при повышенной криворукости.
НС>Ты опять не понял. В C# нет автоматических деструкторов и умных указателей там тоже нет.
В C# есть деструкторы, вызываемые gc, при уничтожении объекта во время сборки мусора. Что я здесь не понял?
НС>>>А деструкторов в шарпе и VB нет, вот незадача. 1>>Кхм. Параграф 10.13 спецификации шарпа просто в шоке. Вот так незатейливо вы его запамятовали, вот незадача. Нет деструктора с явным вызовом при выходе из области видимости. И есть деструктор (как называется в документации) или финализатор (как в умных книжках) который вызывает сам gc.
НС>Финалайзер это не деструктор даже близко. В спецификации к шарпу — ошибка.
Не деструктор. Я специально разделил — как в документации и как в "умных книжках". Только скажите, а какая разница для WinRT в этом? Ресурсы утекать не будут, а большего вроде как и не требуется. Кстати сам дизайн WinRT способствует независимости между ресурсами, минимализирую сценарии блокировки.
Re[11]: No mention of either Silverlight or .NET on Windows
Здравствуйте, 11molniev, Вы писали:
НС>>Это чего еще за зверь? Про домены приложения знаю, про домены безопасности первый раз слышу. 1>Перепутал.
Что с чем? И какое отношение это имеет к Розлину?
НС>>Который? Текущий нет, не на C#. На С++. Будущий да, на C#. 1>Я привел ссылку на блог разработчика, где он рапортует "Source for a C# compiler written in pure C#.", за 2005 год.
Ты внимательно читал? Судя по всему — нет. Он пишет про какой то свой собственный компайлер.
1> Откуда ваши сведения о написании компилятора C# на языке C++?
Из первых рук. Я лично знаком с некоторыми из тех, кто его писал.
НС>>История была несколько сложнее. 1>В двух предложениях не распишешь.
В двух — нет. А подробнее вроде бы было в википедии.
НС>>Боюсь, там даже компилятор Дельфи не был на Паскале написан. 1>Пруфов не могу найти ни на первое ни на второе.
Не сомневайся. Если уж hattab пишет, что на С++
НС>>Никто не говорил про отказ от С++. Речь про вполне конкретные вещи — код студии. 1>Переписывание кода студии на C# — означает отказ С++ для студии.
Да, для студии. Но не от поддержки С++ в студии. Ты как думаешь, на чем пишется код Винды и Оффиса? Пока эти продукты приносят почти весь доход, никуда С++ не денется.
1> Отказ от подержи языка на котором написана среда разработки для него намекает на перспективу отказа от самого языка для платформы. В чем мои умозаключения неверны?
НС>>Ты опять не понял. В C# нет автоматических деструкторов и умных указателей там тоже нет. 1>В C# есть деструкторы, вызываемые gc
Финалайзеры — не деструкторы. Запомни это наконец.
1>Что я здесь не понял?
То, что счетчики ссылок в generational GC работают посредственно. И трах с подсчетом этих самых ссылок в CCW/RCW тому прекрасное доказательство. И в WinRT, как только там появится компонентная модель, весь этот СОМовский трах встанет в полный рост.
НС>>Финалайзер это не деструктор даже близко. В спецификации к шарпу — ошибка. 1>Не деструктор. Я специально разделил — как в документации и как в "умных книжках".
В документации вроде бы в более свежих версиях баг с деструкторами убрали. Но тут я могу ошибаться.
1> Только скажите, а какая разница для WinRT в этом? Ресурсы утекать не будут, а большего вроде как и не требуется.
Разница в компонентной модели. Ее придется адаптировать с COM-образным API, что приведет к некоторой чужеродности его для C# и VB. С этого, собственно, нитка эта и началась.
А по свежим слухам, в WinRT еще и асинхронность в полный рост (планшеты, оптить, мобилорастия в полный рост), что отдельный челлендж при разработке API.
Если нам не помогут, то мы тоже никого не пощадим.
Ну не напишут следующую винду на нем, но прикладникам-то не пофигу ли?
, такое ощущение, что вернулся лет на 15 назад во времена Borland C++ 3. Так что все хорошо в меру.
тоже если разобраться практически нативный продукт
