Несколько раз от разных людей за последнее время слышал, что Майкрософт собирается хоронить .NET. Не могу понять, откуда ветер дует и что будет вместо .NET'a?
Здравствуйте, 8086, Вы писали:
8>Несколько раз от разных людей за последнее время слышал, что Майкрософт собирается хоронить .NET. Не могу понять, откуда ветер дует и что будет вместо .NET'a?
Здравствуйте, Lloyd, Вы писали:
L>Здравствуйте, 8086, Вы писали:
8>>Несколько раз от разных людей за последнее время слышал, что Майкрософт собирается хоронить .NET. Не могу понять, откуда ветер дует и что будет вместо .NET'a?
L>Будет ",DA".
Здравствуйте, 8086, Вы писали:
8086>Несколько раз от разных людей за последнее время слышал, что Майкрософт собирается хоронить .NET.
Не собирается.
8086>что будет вместо .NET'a?
См. роадмап на C# 5 & 6
Здравствуйте, 8086, Вы писали:
8>Несколько раз от разных людей за последнее время слышал, что Майкрософт собирается хоронить .NET. Не могу понять, откуда ветер дует и что будет вместо .NET'a?
Здравствуйте, 8086, Вы писали:
8>Несколько раз от разных людей за последнее время слышал, что Майкрософт собирается хоронить .NET. Не могу понять, откуда ветер дует и что будет вместо .NET'a?
Для справки:
1) Весь Web Stack Microsoft работает на .NET
2) Windows Azure работает в основном на .NET
3) MS Exchange на .NET
4) MS SharePoint на .NET
5) Семейство Dynamics на .NET, не полностью, но все же
6) SQl Server имеет множество компонентов на .NET
7) Windows Phone 7 на .NET
9) Средства разработки на .NET
Теперь подумай сам во что выльется Microsoft отказ от .NET, И не задавай глупых вопросов.
Здравствуйте, gandjustas, Вы писали:
G>Для справки: G>4) MS SharePoint на .NET
Нет. На дотнете там веб-морда, плагины и обертки-API (OM, веб-сервисы). Базовые сервисы — COM, подозреваю, что на C++. Возьмите рефлектор и сами посмотрите. Официальные клиенты (все — Аутлук, Эксел, Аксесс, браузер, само собой) тоже на плюсах (а это же клиент-серверная архитектура, надо и клиентов рассматривать). Кому лень брать рефлектор, те могут воспользоваться этой или любой другой ссылкой:
Если бы это в самом деле был сплошной дотнет, разработка была бы похожей на сказку — знай себе просматривай исходники. Но даже такая вещь, как формулы, у них вычисляются в анменеджед коде.
Здравствуйте, SV., Вы писали:
SV.>Здравствуйте, gandjustas, Вы писали:
G>>Для справки: G>>4) MS SharePoint на .NET
SV.>Нет. На дотнете там веб-морда, плагины и обертки-API (OM, веб-сервисы). Базовые сервисы — COM, подозреваю, что на C++. Возьмите рефлектор и сами посмотрите.
Я-то как раз смотрел и людей обучал
Нативного в SharePoint: работа с БД в плане объектов SPSite\SPWeb\SPList (там внутри xml туда-сюда гуляет), парсер и генератор CAML, который умудряется дико глючить. Также на неуправляемом коде кажись часть Excel Services.
Веб-морда это примерно 60% всего sharepoint, инструментарий управления на PowerShell, Workflow, таймер с его задачами, поиск, Enterprise и Web content management, Performance Point Services, Business Connectivity Services, User Profile Services, Office Web Applications, Project Server, веб-сервисы — все на .NET.
Соотношение managed и unmanaged кода 10 к 1, возможно больше в сторону managed. Причем разработчики непосредственно с unmanaged кодом дела не имеют, новый функционал дописываетя исключительно на .NET
SV.>Официальные клиенты (все — Аутлук, Эксел, Аксесс, браузер, само собой) тоже на плюсах (а это же клиент-серверная архитектура, надо и клиентов рассматривать).
Вот только SharePoint Workspace (самый что ни на есть клиент для SharePoint) — на .NET, да и клиентская библиотека для BCS на .NET.
Да и Client Object Model на .NET, а не C++
SV.>Кому лень брать рефлектор, те могут воспользоваться этой или любой другой ссылкой: SV.>http://office12.blogspot.com/2007/03/sharepoint-sdk-net-managed-code-com.html
А о чем эта ссылка? что чувак открыл для себя рефлектор?
SV.>Если бы это в самом деле был сплошной дотнет, разработка была бы похожей на сказку — знай себе просматривай исходники. Но даже такая вещь, как формулы, у них вычисляются в анменеджед коде.
Тяжелое наследие однако. В Microsoft.SharePoint.dll есть классы для формул, потому что их надо валидировать в интерфейсе до передачи в unmagaged код,но так как соханение данных выполняется в unmanaged то формулы вычисляются там.
Надеюсь в следующей версии они выпилят полностью unmanaged, он очень сильно ограничивает развитие платформы и возможности программистов.
Здравствуйте, mrTwister, Вы писали:
T>Здравствуйте, gandjustas, Вы писали:
G>>3) MS Exchange на .NET
T>Ну это ты загнул. Только некоторый код на хабах под .NET T>Сторы нейтивные.
Здравствуйте, Sorc17, Вы писали:
S>Здравствуйте, gandjustas, Вы писали:
G>>инструментарий управления на PowerShell
S>Жалко вас, любителей микрософта.
А как мне жалко ненавистников Microsoft. Мне microsoft очень сильно помогает бабло зарабатывать, а те кто по политическим причинам не пользуются продуктами и услугами microsoft создают нереальные, глючные и низкокачественные велосипеды.
S>Что там, кстати, скоро ли PowerShell будет как bash?
А что значит "как на bash"?
Здравствуйте, Lloyd, Вы писали:
L>Здравствуйте, Sorc17, Вы писали:
S>>Что там, кстати, скоро ли PowerShell будет как bash?
L>Он уже на голову выше его.
Здравствуйте, 8086, Вы писали:
8>Несколько раз от разных людей за последнее время слышал, что Майкрософт собирается хоронить .NET. Не могу понять, откуда ветер дует и что будет вместо .NET'a?
Связано с тем, что в Windows 8 какую-то часть морды хотят сделать на HTML5/CSS/JS вместо WPF/сильверлайта, вот и заистерили, что это свидительствует об отказе от сильверлайта. Плюс там новые нативные API добавили, соответственно считают, что все вместе это свидетельствует об отказе о .Net.
т.е. пока обещают только async и compiler as service?
и то, и другое полезно — но мало меняет ситуацию.
первое, и так уже можно худо-бедно эмулировать через yield-ы, второе тоже есть, но через сторонние утилиты
Здравствуйте, DarkGray, Вы писали:
DG>т.е. пока обещают только async и compiler as service?
Пока что CaaS — это дальняя перспектива. Они вроде как не укладываются к релизу VS 2012 (и это, имхо, хорошо — там работы явно не на 2 года). Кстати, на февральских слайдах, что запостил QrystaL, Roslyn идёт в роадмапе для 6го шарпа.
DG>первое, и так уже можно худо-бедно эмулировать через yield-ы.
Не-не-не, Async-это очень классная задумка. Фактически, это CPS-движок, встроенный прямо в язык.
Вместо того, чтобы "вкладывать" делегаты друг в друга аля
var syncContext = CurrentContext;
var arg = "aaa";
web.DownloadAndInvoke("about:blank", downloadResult=>
{
syncContext.Post(()=>ProcessOnDownloaded(downloadResult, arg));
});
мы пишем обычный код и оставляем сохранение состояний на компилятор:
var arg = "aaa";
var downloadResult = await web.DownloadAsync("about:blank");
ProcessOnDownloaded(downloadResult, arg);
Одним махом МС добавляют сахар для асинхронности, синхронизации многопоточного кода, лёгких workflow и реактивного программирования. Велкам, Rx
Офф: лучшее введение в async из всего, что я видел — это вот эта презентация. Async разжёван с кучей деталей и у Липперта, и у Джо Скита, но в обоих сериях уделено крайне внимания самому подходу/типовым решаемым задачам.
Здравствуйте, Lloyd, Вы писали:
L>Здравствуйте, Sorc17, Вы писали:
S>>Что там, кстати, скоро ли PowerShell будет как bash?
L>Он уже на голову выше его.
Я в bash перенаправляю ввод вот так command < command. А чем может похвастаться PowerShell?
Для нас [Thompson, Rob Pike, Robert Griesemer] это было просто исследование. Мы собрались вместе и решили, что ненавидим C++ [смех].
S>Не-не-не, Async-это очень классная задумка. Фактически, это CPS-движок, встроенный прямо в язык.
это важно стратегически, так же как и CasS.
а по сравнению с yield-ами — это лишь добавление сахара, и доведение до ума того, что было.
сравни это
IEnumerable<TaskStep> F()
{
var arg = "aaa";
var asyncResult = web.BeginDownload("about:blank");
yield return new Wait(asyncResult);
var downloadResult = web.EndDownload();
ProcessOnDownloaded(downloadResult, arg);
}
с этим
var arg = "aaa";
var downloadResult = await web.DownloadAsync("about:blank");
ProcessOnDownloaded(downloadResult, arg);
причем первое доступно уже года 3 и его можно крутить в том числе и в однопоточном режиме без необходимости следить за синхронизацией, а вот что так можно со вторым сделать — я не уверен.
в итоге, async не сильно упрощает написание кода, потому что все равно приходится в рукопашную следить за правильностью синхронизации каждой запятой.
1)базовые сервисы (сборщик мусора, работа с памятью, портами, прерываниями) на ассемблере их корректность автоматически доказана статически с помощью Boogie, это если они не ошиблись с аннотациями
2)Ядро на C#, который компилируется в TAL (typed assembly language) и также верифицируется автоматически
3)Программ на C#, который также компилируется в .NET
То есть по сути почти вся система на C# с мощными статическими проверками.
Здравствуйте, Sorc17, Вы писали:
L>>Он уже на голову выше его.
S>Я в bash перенаправляю ввод вот так command < command. А чем может похвастаться PowerShell?
а почему бы просто не воспользоваться поиском?
если вы не знаете, по каким ключевым словам искать, то воспользуйтесь "command substitution powershell"
Здравствуйте, DarkGray, Вы писали:
DG>а по сравнению с yield-ами — это лишь добавление сахара, и доведение до ума того, что было.
Оно было, но использовалось так же часто, как и yield до linq.
DG>сравни это
Ну это же совсем не то — пассивный итератор, отсутствие шедулинга, грабли с комбинацией итераторов... Вот тут есть неплохой пример.
Разница та же, что и между IEnumerable|IObservable. По сути, Await — это и есть yield для Rx.
DG>причем первое доступно уже года 3 и его можно крутить в том числе и в однопоточном режиме без необходимости следить за синхронизацией, а вот что так можно со вторым сделать — я не уверен. Элементарно — там полный аналог с синтаксической привязкой linq/foreach: достаточно, чтобы у аргумента await был разрешим метод GetAwaiter(), а у того — методы Begin/EndAwait
DG>в итоге, async не сильно упрощает написание кода, потому что все равно приходится в рукопашную следить за правильностью синхронизации каждой запятой.
Async — это целиком и полностью сахар для continuation passing. Я не могу представить, какие там могут быть проблемы с синхронизацией
S> достаточно, чтобы у аргумента await был разрешим метод GetAwaiter(), а у того — методы Begin/EndAwait
вот если бы они сделали, чтобы такая возможность(дернуть метод по имени, но с резолвингом на этапе компиляции и с поддержкой статической типизации) была доступна для любой библиотеки, а не только для await — вот это было бы круто!... и дало бы толчок для появления кучи интересных библиотек
Здравствуйте, Lloyd, Вы писали:
L>Здравствуйте, Sorc17, Вы писали:
L>>>Он уже на голову выше его.
S>>Я в bash перенаправляю ввод вот так command < command. А чем может похвастаться PowerShell?
L>а почему бы просто не воспользоваться поиском? L>если вы не знаете, по каким ключевым словам искать, то воспользуйтесь "command substitution powershell"
Не увиливайте. Я вам задал вполне конкретный вопрос. От того как он решен в PowerShell, просто глаза с кровью вытекают. Очевидно поэтому вы и пытаетесь "отослать в гугл", но зря. Я-то в гугл ходил и работал с PowerShell. После попытки написать на нем что-то посложнее элементарного установочного скрипта у меня навсегда отпало желание использовать PowerShell. Даже cmd был лучше. cmd позволял делать простые вещи легко, но не позволял делать сложные вещи. PowerShell позволяет делать сложные вещи, но простые вещи теперь делаются так же сложно как и сложные. Шаг вперёд для майкрософт? Да. Стали ближе к bash? Да. Догнали или превзошли bash? Нет. Выбора-то у вас нет Сделал микрософт кактус? Все его едят. Поэтому мне вас и жаль.
Для нас [Thompson, Rob Pike, Robert Griesemer] это было просто исследование. Мы собрались вместе и решили, что ненавидим C++ [смех].
Здравствуйте, Sorc17, Вы писали:
L>>а почему бы просто не воспользоваться поиском? L>>если вы не знаете, по каким ключевым словам искать, то воспользуйтесь "command substitution powershell"
S>Не увиливайте. Я вам задал вполне конкретный вопрос.
А я вам дал вполне конкретный ответ. Ссылок — тыщи, зачем мне тут повторяться?
S>От того как он решен в PowerShell, просто глаза с кровью вытекают. Очевидно поэтому вы и пытаетесь "отослать в гугл", но зря. Я-то в гугл ходил и работал с PowerShell.
Я видимо чего-то недогоняю. Опыта большого ни с тем, ни с тем у меня нет, все как-то по мелочам.
Не могли бы вы привести пример няшного bash-скрипта c substitution-ом, который у вас не получатся воспроизвести в PS?
S>После попытки написать на нем что-то посложнее элементарного установочного скрипта у меня навсегда отпало желание использовать PowerShell. Даже cmd был лучше. cmd позволял делать простые вещи легко, но не позволял делать сложные вещи. PowerShell позволяет делать сложные вещи, но простые вещи теперь делаются так же сложно как и сложные. Шаг вперёд для майкрософт? Да. Стали ближе к bash? Да. Догнали или превзошли bash? Нет. Выбора-то у вас нет Сделал микрософт кактус? Все его едят. Поэтому мне вас и жаль.
Одни эмоции и никаких фактов. Типичный юниксоид со стажем.
Здравствуйте, DarkGray, Вы писали:
DG>вот если бы они сделали, чтобы такая возможность(дернуть метод по имени, но с резолвингом на этапе компиляции и с поддержкой статической типизации) была доступна для любой библиотеки, а не только для await — вот это было бы круто!... и дало бы толчок для появления кучи интересных библиотек
Оно не имеет смысла без произвольного расширения синтаксиса языка и поддержки сторонних реврайтеров, а это, по мнению Хейлсберга, too big gun. Впрочем, Липперт на что-то такое намекал с месяц назад
Здравствуйте, Sinix, Вы писали:
DG>>а по сравнению с yield-ами — это лишь добавление сахара, и доведение до ума того, что было. S>Оно было, но использовалось так же часто, как и yield до linq.
Ты забыл добавить "мной" (т.е. тобой).
Я как-то его сразу использовал и довольно часто.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, DarkGray, Вы писали:
S>> достаточно, чтобы у аргумента await был разрешим метод GetAwaiter(), а у того — методы Begin/EndAwait
DG>вот если бы они сделали, чтобы такая возможность(дернуть метод по имени, но с резолвингом на этапе компиляции и с поддержкой статической типизации) была доступна для любой библиотеки, а не только для await — вот это было бы круто!... и дало бы толчок для появления кучи интересных библиотек
Да, не вопрос. В Nemerle и F# это уже давно есть.
ЗЫ
Ну, а вы ждите от моря погоды .
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Sinix, Вы писали:
S>Оно не имеет смысла без произвольного расширения синтаксиса языка и поддержки сторонних реврайтеров, а это, по мнению Хейлсберга, too big gun. Впрочем, Липперт на что-то такое намекал с месяц назад
Про биг-ган — это были слова о синтаксических макросах. В прочем, похоже с тех пор его мнение немного пообмякло.
Тут же достаточно F#-ного решения — билдеров для монойдов.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Abyx, Вы писали:
8>>Несколько раз от разных людей за последнее время слышал, что Майкрософт собирается хоронить .NET. Не могу понять, откуда ветер дует и что будет вместо .NET'a?
A>нативный немерле будет.
Мечтать не вредно.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, gandjustas, Вы писали:
G>Для справки: G>1) Весь Web Stack Microsoft работает на .NET G>2) Windows Azure работает в основном на .NET G>3) MS Exchange на .NET G>4) MS SharePoint на .NET G>5) Семейство Dynamics на .NET, не полностью, но все же G>6) SQl Server имеет множество компонентов на .NET G>7) Windows Phone 7 на .NET G>9) Средства разработки на .NET
+1
G>Теперь подумай сам во что выльется Microsoft отказ от .NET, И не задавай глупых вопросов.
А вот с этим не согласен! Задавать глупые вопрос можно и нужно. Среди ни иногда проскакивают революционные идеи.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Я как-то его сразу использовал и довольно часто.
Не, я тоже игрался, но в продакшн, да ещё и в таком объёме, как linq — без лямбд и extension-ов выглядело извратом.
Здравствуйте, Sorc17, Вы писали:
S>Здравствуйте, Lloyd, Вы писали:
L>>Здравствуйте, Sorc17, Вы писали:
S>>>Что там, кстати, скоро ли PowerShell будет как bash?
L>>Он уже на голову выше его.
S>Я в bash перенаправляю ввод вот так command < command.
Это че значит?
S>А чем может похвастаться PowerShell?
1) Как минимум тем что я могу встроить в свое приложение скриптинг на Power Shell с помощь десятка строк
2) Тем что есть автозавершение по tab, причем не только путей и команд, но и параметров этих команд
3) тем что в комплекте с windows идет вполне достойная IDE с поддержкой repl для powershell
4) Тем что можно красиво работать с xml (через точку)
5) Вот таким и подобными репозитариями
6) И тем что PowerShell может использовать всю мощь библиотеки .NET
Здравствуйте, Sorc17, Вы писали:
S>PowerShell позволяет делать сложные вещи, но простые вещи теперь делаются так же сложно как и сложные.
Это от незнания. Я тоже сначала так думал, но на самом деле всё что можно делать просто в cmd — в PS тоже делает просто.
Здравствуйте, Sinix, Вы писали:
AVK>>Задумка то классная, но вот задач, где от нее будет существенный эффект, не очень много.
S>Насколько помню, то же самое писалось про yield.
А так оно и было до следующей версии компилятора. Да и сейчас yield не так чтобы часто используемая фича. Ну и async все таки более специальная вещь чем yield.
... << RSDN@Home 1.2.0 alpha 5 rev. 1530 on Windows 7 6.1.7601.65536>>
Здравствуйте, AndrewVK, Вы писали:
AVK>А так оно и было до следующей версии компилятора. Да и сейчас yield не так чтобы часто используемая фича. Ну и async все таки более специальная вещь чем yield.
Насчёт последнего не уверен. Написать (псевдокод)
var mouseDown = control.MouseDown.ToAsync();
var mouseMove = control.mouseMove.ToAsync();
var mouseUp = control.mouseUp.ToAsync();
Point dragStart = (await mouseDown).Position;
// петля с IsDragDelta слегка некорректна - нет отмены по Esc/MouseUpwhile (!IsDragDelta(dragStart, await mouseMove))
{
}
Point dragEnd = (await mouseUp).Position;
ProcessDragDrop(dragStart, dragEnd);
явно приятнее, чем возиться с отдельными обработчиками или комбинировать события через Rx.
Да, сейчас в таком стиле никто не пишет — слишком много лишнего кода. Аналогично, никто не использовал ленивые итераторы до лямбд и extension-методов.
Здравствуйте, Sinix, Вы писали:
S>явно приятнее, чем возиться с отдельными обработчиками или комбинировать события через Rx.
Насчет последнего не уверен вовсе. Прок от async есть, когда в method chain записи есть вложенные лямбды, а почти все сценарии использования Rx, с которыми я сталкивался, обходились без этого.
... << RSDN@Home 1.2.0 alpha 5 rev. 1530 on Windows 7 6.1.7601.65536>>
Здравствуйте, Ziaw, Вы писали:
Z>По твитеру ходит слух, что в своем апсторе они не желают видеть программ на .net, развеешь?
Сильверлайт не взлетел толком, он даже не ускорен аппаратно, впф всё еще взлетает, время загрузки как было слишком большим, таким и осталось, иис усох, асп.нет усох(микрософт сам не умеет им пользоваться), шарепоинт как то слабенько востребован, куча телодвижений в сторону html4 и js, расширение возможностей нативной разработки, куча дотнетовских аппликаций от микрософта страдает хроническими болезнями по нескольку версий кряду, xna как то не выстрелил, мобильный дотнет вернулся в зачаточное состояние
Не уверен, что слухи правдивые про апстор, но точно знаю что в дотнет большие проблемы — вместо устранения хронических болезней челы рожают технологии-однодневки. Похоже решения принимают исключительно девелоперы.
Здравствуйте, AndrewVK, Вы писали:
AVK>Задумка то классная, но вот задач, где от нее будет существенный эффект, не очень много.
Ну, видимо будет больше... WinRT обещают делать асинхронным, где только можно, и вызовы этого API не надо будет ни во что оборачивать.
Мы уже победили, просто это еще не так заметно...
