Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 137
Скажите, а что из этого последует и повлияет на разработку на C#? Извините за возможно глупый вопрос.
На мой взгляд это поможет Mono сообществу. На C# будет удобнее разрабатывать софт под *nix и Android.
А сейчас Mono не Xamarin? Извините за возможно глупый вопрос.
Да, разработчик Mono компания Xamarin. После ребрендинга Mono переименовали.
Возможно появятся и другие компиляторы, и под другие ОС.
Возможно появятся и другие компиляторы, и под другие ОС.
Mono — открытая реализация CLR и BCL. Xamarin — контора во главе с Мигелем, которая всё это дело координирует и пилит, попутно имея гешефт с мобильных разработок.
Как уже выше писали Xamarin — компания, которая развивает открытый проект Mono. При этом она поверх моно развивает такие коммерческие продукты, как Xamarin.iOS, Xamarin.Android и Xamarin.Mac. Когда говорят, что пишут на Xamarin, имеют ввиду эти коммерческие проекты.
Скажите, а что из этого последует и повлияет на разработку на C#?
Опенсорсность на C# вряд ли повлияет, а вот что компилятор переписан с нуля и теперь со всех сторон облепляем — должно дать толчок к стремительному развитию языка и инструментов.
В офис Microsoft прокрался Столлман и покусал там кучу народу. Иначе это объяснить невозможно.
Он не просто в офис прокрался, он прокрался на самый верх. Правда, пришлось прикинуться индусом.
В офис Microsoft прокрался Столлман и покусал там кучу народу.
Кто-то пострашнее Столлмана прокрался. Там лицензия Apache, а не GPL.
ПФФ, большинство того, что в списке открыто довольно давно.
Ждем IDE от JetBrains. :)
Зачем, если есть ReSharper?
Дык, для разработки не под виндой же. Всяко лучше Xamarin Studio будет. Да и на JetBrains-овские продукты стоимость далеко не так кусается, как у Visual Studio.
Да ладно, 500 баксов (+ $150 за решарпер) — не такая уж и большая сумма. А вот заменить весь пакет расширений к студии будет весьма проблематично.
Лицензия для личного пользования сред разработки JetBrains стоит 200 баксов. Там будет встроенный решарпер. 350-400 баксов уже не такая маленькая разница, для кого-то может оказаться существенной, да и одна среда разработки на всех трех платформах тоже немаленькая плюшка.
По моим наблюдениям за собой, коллегами и знакомыми, кто тоже на шарпах пишет, большинство пользуются голой студией + решарпером + (опционально) плагином какой-либо системы контроля версий. Под голой студией я понимаю блокнот с подсветкой кода и автодополнением, проекты, интеграцию с дебаггером и графические редакторы для windows forms и wpf. Все это есть и в Jetbrain-овских средах.
Все это не холивара ради, просто не вижу, что такого еще народ накручивает в студию (если это не фирмоспецифичные внутренние плагины), что существенно увеличило бы удобство вышеназванного варианта.
По моим наблюдениям за собой, коллегами и знакомыми, кто тоже на шарпах пишет, большинство пользуются голой студией + решарпером + (опционально) плагином какой-либо системы контроля версий. Под голой студией я понимаю блокнот с подсветкой кода и автодополнением, проекты, интеграцию с дебаггером и графические редакторы для windows forms и wpf. Все это есть и в Jetbrain-овских средах.
Все это не холивара ради, просто не вижу, что такого еще народ накручивает в студию (если это не фирмоспецифичные внутренние плагины), что существенно увеличило бы удобство вышеназванного варианта.
Для os x — добавляем стоимость собственно винды и parallels/vmware, и совсем печально.
Мне даже страшно представить, чего ожидать дальше. OpenWindows? Все равно Win9 следующую версию не назовут, чтобы не путаться с Win9x.
Это не та Windows, что вы ищите.
Я удивляюсь, вы в каждый топик лезете с рекламой ReactOS, и каждый раз вас минусуют, но вы все равно продолжаете. Остается только поражаться, откуда у вас берется положительная репа, чтобы не попасть в R/O.
Что касается бесплатной винды, пока только WinPhone (на днях была инфа, что мобильная винда теперь будет бесплатной), но дело движется в правильном направлении
Что касается бесплатной винды, пока только WinPhone (на днях была инфа, что мобильная винда теперь будет бесплатной), но дело движется в правильном направлении
На конференции объявиили о бесплатной винде для девайсов с диагональю экрана меньше 9 дюймов уже сейчас, и о том, что винда станет вообще бесплатной после выхода Windows для Intel Galileo и подобных.
Не совсем. Есть WinPE, ниже вот про WRK довели сведения. Так что теоретически бесплатная винда могла бы существовать, насколько я понимаю. Но нужно дописать под все это оболочку и довести до ума. А люди, умеющие и желающие делать подобное, скорее пойдут пилить любимый дистрибутив линукса, чем ковыряться в винде.
Винда не вечна, и скорее на последнем издыхании, чем в начале жизни. Будет принициально новая ось от МС, вопрос только в сроках. Я ставлю что примерно через 5 лет будет отход от винды, как было DOS -> WIN.
А зачем?
В данный момент я не вижу необходимости в какой-то революционной ОС, а обои я почти никогда не вижу, так что нескучными ими меня не завлечешь.
Если говорить серьезно, то, касаемо операционных систем от MS, я был бы рад видеть развитие ветки XP. Но, так как это маловероятно (если чудом не произойдет перевод и ее в разряд Open Source), то приятно было бы увидеть именно развитие пусть даже текущих веток. Именно развитие, а не постоянное переделывание всего с нуля. Не думаю, что в современных версиях ОС все настолько плохо, что опять нужно все делать заново.
В данный момент я не вижу необходимости в какой-то революционной ОС, а обои я почти никогда не вижу, так что нескучными ими меня не завлечешь.
Если говорить серьезно, то, касаемо операционных систем от MS, я был бы рад видеть развитие ветки XP. Но, так как это маловероятно (если чудом не произойдет перевод и ее в разряд Open Source), то приятно было бы увидеть именно развитие пусть даже текущих веток. Именно развитие, а не постоянное переделывание всего с нуля. Не думаю, что в современных версиях ОС все настолько плохо, что опять нужно все делать заново.
То есть винапи это круто?
Нет, для пользователей-то может и все равно, только вот для разработчиков это просто ужас. Половина параметров — необязательная, вторая половина — аргументы, в которые нужно передать определенные значения иначе будет ошибка, третья половина — 100500 странных структур, передающихся по указателю. Не говоря про зоопарк функций: почти каждая функция существует в двух вариантах: aaa и aaaEx, кроме того, и это количество удваивается для функций с «юникод» и «не-юникод» строками, из-зачего винапи чуть более, чем полностью использует макросы, чтобы хоть как-то справится с этим адом.
И вы хотите сказать, что все это менять не надо?
Нет, для пользователей-то может и все равно, только вот для разработчиков это просто ужас. Половина параметров — необязательная, вторая половина — аргументы, в которые нужно передать определенные значения иначе будет ошибка, третья половина — 100500 странных структур, передающихся по указателю. Не говоря про зоопарк функций: почти каждая функция существует в двух вариантах: aaa и aaaEx, кроме того, и это количество удваивается для функций с «юникод» и «не-юникод» строками, из-зачего винапи чуть более, чем полностью использует макросы, чтобы хоть как-то справится с этим адом.
И вы хотите сказать, что все это менять не надо?
Если за два десятка лет переписывания ничего толком не поменялось в этом плане, кто даст гарантии, что через 5 лет оно окажется чем-то кардинально иным изнутри?
Такая ситуация, кстати, не только относительно ОС. Если в вашем комментарии заменить винапи на PHP, то получится типичный комментарий пэхэпэ-хейтера в треде про веб-разработку. Там тоже уже который год пророчат смерть данному языку. Но пока сфера применения удерживает свои позиции, реальные изменения в объеме использования не так уж значительны.
Такая ситуация, кстати, не только относительно ОС. Если в вашем комментарии заменить винапи на PHP, то получится типичный комментарий пэхэпэ-хейтера в треде про веб-разработку. Там тоже уже который год пророчат смерть данному языку. Но пока сфера применения удерживает свои позиции, реальные изменения в объеме использования не так уж значительны.
То есть винда будет вечной? Потому что это единственное утверждение, противоречащее моему «когда-нибудь винда умрет».
А к тому, что это случится скоро — скажем так, есть симптомы. Тем более, что активно пилятся в research операционки-претендентки.
А к тому, что это случится скоро — скажем так, есть симптомы. Тем более, что активно пилятся в research операционки-претендентки.
А Как же Windows Runtime? Хотя как я понимаю это не совсем то…
У WRT таких проблем нет. API четкое, хотя уже стали появляться deprecated. С юникодом проблем нет, все строки представлены в UCS-2. Макросов никаких нет (мне не встречались). С Component Extensions отпадает нужда возиться с COM.
Это как раз то, что нужно. АПИ очень изящное, все методы, выполняющиеся дольше 50мс обязаны быть асинхронными и не вешать комп… Но, есть один нюанс — все современные хитросделанные программы используют различные костыли этого самого винапи и гвоздями к нему прибиты, поэтому не идут. Сами посмотрите, насколько успешны Surface с WinRT, на которых не идет какая-нибудь KB2. А раз не идет RB2, то система — фигня… Примерно так думает рынок. Я, наоборот, всеми руками ЗА WRT. Но, селяви. Без обратной совместимости с ненавистным апи платформа не взлетит.
WinRT — это прекрасное general purpose API, однако с некоторыми его недоработками на практике приходится сталкиваться. Например, не всегда хорошо иметь только асинхронные методы, а сделать из ассинхронных синхронные — это местами вытекает в серьезные проблемы с контролем ошибок.
Никогда не испытывал проблем с контролем ошибок в многопотоке после появления async/await…
из ассинхронных синхронные. Ваш async/await асинхронный.
Простите, а зачем? Добиться синхронизации же не так уж и сложно, делать методы полностью синхронными не самая лучшая затея как по мне.
await позволяет ожидать асинхронную задачу, причем если она свалится, то эксепшн будет передан в вызывающий поток, как будто оно произошло синхронно. Подробнее можно ознакомиться тут
Не в вызывающий поток :) А в поток, который задан текущим SynchronizationContext — это раз. Я знаю предмет лучше Вас — это два. Вы суть проблемы не понимаете. Вы не о том.
Ну тогда поделитесь опытом, в чем же суть проблемы? Рад буду узнать что-нибудь новенькое. Комментарии за этим же и нужны, не для срача же, право?
афайк контекст выставляется в таске, но как правило опускается, и используется контекст вызывающего кода — разве нет?
А в поток, который задан текущим SynchronizationContext — это раз.
афайк контекст выставляется в таске, но как правило опускается, и используется контекст вызывающего кода — разве нет?
Суть проблемы в том, что если нужно вам дропнуть в WinRT специфический конкретный асинхронный таск, то вместе с этим таском дропнется и COM объект (и не один), который дропаться никак не должен. Это кстати и есть пример abstraction leak.
Про SС — вызывающий код может находится в потоке, который создал я сам. В этом случае то, что стоит после await не будет выполнено в вызывающем потоке, если это явно не написали такую логику.
Про SС — вызывающий код может находится в потоке, который создал я сам. В этом случае то, что стоит после await не будет выполнено в вызывающем потоке, если это явно не написали такую логику.
Уже заменили. Используйте .net. Для большей части вообще можно забыть о том, что такое winapi, для оставшейся небольшой части можно спокойно найти P/Invoke обертки.
Не заменили, а спрятали под ковер.
И да, я .Net-программист. И именно по этим соображениям. Как рекламировала Java: Write once, run anywhere
И да, я .Net-программист. И именно по этим соображениям. Как рекламировала Java: Write once, run anywhere
> Не заменили, а спрятали под ковер.
Вы хотите поговорить об этом? Часто ли вас беспокоит, что находится под коврами и в фундаментах помещений, где вы находитесь?
Вы хотите поговорить об этом? Часто ли вас беспокоит, что находится под коврами и в фундаментах помещений, где вы находитесь?
Когда-нибудь слышали о законе дырявых абстракций?..
Не знал, что он именно про винапи…
Он применим к любым абстракциям, а весь прикладной софт и большая часть системного построены на абстракциях. Чтобы система адекватно функционировала, она должна знать об абстракциях, используемых уровнем выше и ниже. Поэтому няшность .Net лишь частично компенсирует кривость винапи.
Одним словом, на кривом фундаменте прочный и красивый дом не выстроить.
Одним словом, на кривом фундаменте прочный и красивый дом не выстроить.
Как вы думаете, сколько программистов знают об абстракциях уровнем ниже WinApi? Уровнем ниже WinRT? Уровнем ниже Qt?
Есть ли у вас другой глобус?
Есть ли у вас другой глобус?
Программисты WinAPI обязаны знать об абстракциях ниже WinAPI, по этому же правилу, представлять, что такое HAL и пр.
Ну а прикладные программисты работают с АПИ системы, поэтому лезть глубже него им не нужно, хотя и полезно.
Все это никак не противоречит изначальному утверждению, что на кривом винапи нельзя построить изящного программного интерфейса. А вот на WinRT можно, вопрос только в том, чтобы на него пересадить пользователей.
Ну а прикладные программисты работают с АПИ системы, поэтому лезть глубже него им не нужно, хотя и полезно.
Все это никак не противоречит изначальному утверждению, что на кривом винапи нельзя построить изящного программного интерфейса. А вот на WinRT можно, вопрос только в том, чтобы на него пересадить пользователей.
Всё это никак не противоречит.
А вот это противоречит — www.hanselman.com/blog/content/binary/Windows-Live-Writer/How-to-call-WinRT-APIs-in-Windows-8-from_12FB4/image_14.png
А вот это противоречит — www.hanselman.com/blog/content/binary/Windows-Live-Writer/How-to-call-WinRT-APIs-in-Windows-8-from_12FB4/image_14.png
В .Net закон дырявых абстракций обычно не из-за WinAPI проявляется, ИМХО. К тому же, где, например в Silverlight WinAPI?
Еще раз, закон дырявых абстракций применим к любым абстракциям, а любое АПИ — это набор абстракций, сгруппированных для решения какой-либо задачи.
Насчет Silverlight не очень понял, что имелось ввиду…
Насчет Silverlight не очень понял, что имелось ввиду…
Вы говорите очень общими словами, они не отражают истину.
Давайте сначала формально объясним, что такое «закон применим» :) Иначе из его применимости не следует, что какое-то явление имеет место.
На счет Silverlight все просто: это не только не WinApi, но и не .Net даже. Поэтому, говорить, что из .Net торчит WinAPI — это неверно.
Давайте сначала формально объясним, что такое «закон применим» :) Иначе из его применимости не следует, что какое-то явление имеет место.
На счет Silverlight все просто: это не только не WinApi, но и не .Net даже. Поэтому, говорить, что из .Net торчит WinAPI — это неверно.
Давайте сначала формально объясним, что такое «закон применим»
Очень просто. Закон применим, в данном случае: «для грамотного проектирования своего уровня разработчику нужно знать уровень ниже (апи ОС) и уровень выше (кейсы использования разрабатываемого слоя).
На счет Silverlight все просто: это не только не WinApi, но и не .Net даже. Поэтому, говорить, что из .Net торчит WinAPI — это неверно.
Из .Net торчит винапи хотя бы в том смысле, что он гвоздями прибит к нему. Конечно, есть Mono, который в этом плане свободен, но в нем 50% функционала обычного фреймворка в стадии coming soon.
Хотя после последних заявлений МС об опен-сорсовости и слухов о покупке Xamarin можно надеяться на постепенный переход в стадию большей мобильности.
При чем тут Silverlight до сих пор не ясно :)
Это пустословие, коллега :)
Вы сначала определите, что такое грамотный уровень, а что такое — неграмотный :) Но я думаю мы эту цепочку будем долго раскручивать.
Гораздо проще здесь опираться на то, что говорит опыт. А опыт говорит мне, что WinAPI в .Net торчит там, куда разработчик залез сам по ошибке. Классический пример — это попытки низкоуравневой работы с Windows Forms, вызов всяких API функций для этого, итд. В этом случае не нужно использовать технологии, которые не предназначены для такого. Есть WPF, есть Silverlight.
Вы сначала определите, что такое грамотный уровень, а что такое — неграмотный :) Но я думаю мы эту цепочку будем долго раскручивать.
Гораздо проще здесь опираться на то, что говорит опыт. А опыт говорит мне, что WinAPI в .Net торчит там, куда разработчик залез сам по ошибке. Классический пример — это попытки низкоуравневой работы с Windows Forms, вызов всяких API функций для этого, итд. В этом случае не нужно использовать технологии, которые не предназначены для такого. Есть WPF, есть Silverlight.
Вы сначала определите, что такое грамотный уровень, а что такое — неграмотный :)
ИМХО это понятие интуитивно-аксиоматическое, у каждого свое, и как-то конкретно его определить не получится (как точка в геометрии, все множество фигур сводится к точке, но сама точка вводится аксиоматически и определения не имеет).
Гораздо проще здесь опираться на то, что говорит опыт. А опыт говорит мне, что WinAPI в .Net торчит там, куда разработчик залез сам по ошибке.
Согласен, но так ведь случается не всегда.
Самый простой пример — нужно показать что-нибудь на определенном мониторе в многоэкранной конфигурации. Я не спорю, что предусмотреть в .Net весь возможный функционал невозможно, а если бы это и было, то он бы разбух и стал бы похожим на винапи монстром, весом в гигабайты, но потребность в подобном иногда встречается.
Я считаю, что так или иначе винапи отжил свое, и хотя его полуразвалившееся тело запихали под ковер, запах из-под него периодически доносится. Я очень надеюсь на дальнейшее развитие Singularity, Midori и прочих проектов в лице Drawbridge, на C# в качестве системного ЯП и продуманный микроядерный дизайн ОС. Пока что все это лишь в мечтах/исследовательских проектах.
Несмотря на то, что я и C++ программист, я считаю, что C# и .Net придумали не для того, чтобы думать много о том, как он работает. Какие абстракции создает, что там внутри сидит, какой там там ассемблер генерится, если я P/Invoke сделаю для memcpy, итд. Если об этом думать, то получится программирование еще сложнее, чем на С++. Основной критерий тут, имхо, — это трудозатраты и расширяемость. Если мы можем писать на C# код, который нас устраивает по функциональной корректности, производительности и расширяемости — это даже вредно знать, что там внутри сидит.
Несмотря на то, что я C# программист, я считаю, что полезно знать, что сидит внутри, потому что хотя преждевременные оптимизации и зло, при прочих равных лучше выбрать лучший с ТЗ производительности алгоритм, а о критериях этой «лучшести», как правило, приходится судить, учитывая особенности нижележащего уровня.
А я наоборот считаю, что знать что сидит внутри — никогда не лишне, даже если не пригодится.
Впрочем, я полагаю, конструктивная часть диалога закончилась, а срач в комментах никому еще не помог. Был рад обсудить эту тему. Удачи.
Если мы можем писать на C# код, который нас устраивает по функциональной корректности, производительности и расширяемости — это даже вредно знать, что там внутри сидит.
А я наоборот считаю, что знать что сидит внутри — никогда не лишне, даже если не пригодится.
Впрочем, я полагаю, конструктивная часть диалога закончилась, а срач в комментах никому еще не помог. Был рад обсудить эту тему. Удачи.
А зачем вам C# тогда? Используйте C++ и вы получите лучший код за ту же цену.
Мне не нравится С++ как язык. Мне он кажется перегруженым.
В то время в шарпе я нахожу то, что мне нравится. Не гнушаюсь и фунциональным стилем программирования, linq-ом и прочим, чего в С++ отродясь не было и когда введут в стандарт — не ясно. Не говоря про то, что я не десктоп-разработчик, а ASP.Net/SP.
В то время в шарпе я нахожу то, что мне нравится. Не гнушаюсь и фунциональным стилем программирования, linq-ом и прочим, чего в С++ отродясь не было и когда введут в стандарт — не ясно. Не говоря про то, что я не десктоп-разработчик, а ASP.Net/SP.
Не гнушаюсь и фунциональным стилем программирования, linq-ом и прочим, чего в С++ отродясь не было и когда введут в стандарт — не ясно.
Пока вы там спите, уже 2 стандарта вышло с функциональным программированием в С++
Пока вы там спите, уже 2 стандарта вышло с функциональным программированием в С++
Хуже лямбд в С++ только лямбды в VB.Net :)
А вот LINQ нежданчик. Спасибо за наводку.
Однако остальные проблемы это не решает. Лично для меня код на плюсах абсолютно нечитаем. Я не говорю, что язык плох, но персонально для меня он не подходит. К тому же он больше подходит для системной разработки, когда как .Net — универсальный, хочешь — консольки клепай, а хочешь — веб-части для SP ваяй, язык один. Единственный язык с подобной свободой — Java. Но так уж вышло, что .Net мне подошел больше. Да и из-за него я попал туда, где работаю сейчас. И я очень рад, что так произошло, что руководство на просьбу «можно мне хард заменить, а то что-то дурит» отвечает «а давай мы тебе SSD поставим, чтоб больше не мучался», когда коллеги рады помочь, и у них есть чему поучиться, когда сис.админ оперативно решает задачи и помогает со всякими настройками, когда тебе дают задачу, и ты волен писать что хочешь и как хочешь (сообразно code style команды, офк), но решить поставленную задачу — если не это программировать себе в удовольствие, то даже не знаю, что тогда назвать :) Выбрал бы я другой язык — кто знает, было бы так же или нет, но я рад тому, как все сложилось. Но интуиция подсказывает мне, что на плюсах я не был бы так рад прогать.
Для меня два любимых языка: С и С#. С — очень производительный, низкоуровневый, никаких тебе объектов, перекладывай байтики да радуйся. Шарп — уже ответил, многогранность и ортогональность, любая задача решается сообразно своей сложности. Плюсы же — что-то среднее. Кто-то скажет — золотая середина, мощь ООП с производительностью С, однако для меня скорее ни рыба, ни мясо. Тем более, после обещания МС сделать шарп не медленнее, чем С++.
А вот LINQ нежданчик. Спасибо за наводку.
Однако остальные проблемы это не решает. Лично для меня код на плюсах абсолютно нечитаем. Я не говорю, что язык плох, но персонально для меня он не подходит. К тому же он больше подходит для системной разработки, когда как .Net — универсальный, хочешь — консольки клепай, а хочешь — веб-части для SP ваяй, язык один. Единственный язык с подобной свободой — Java. Но так уж вышло, что .Net мне подошел больше. Да и из-за него я попал туда, где работаю сейчас. И я очень рад, что так произошло, что руководство на просьбу «можно мне хард заменить, а то что-то дурит» отвечает «а давай мы тебе SSD поставим, чтоб больше не мучался», когда коллеги рады помочь, и у них есть чему поучиться, когда сис.админ оперативно решает задачи и помогает со всякими настройками, когда тебе дают задачу, и ты волен писать что хочешь и как хочешь (сообразно code style команды, офк), но решить поставленную задачу — если не это программировать себе в удовольствие, то даже не знаю, что тогда назвать :) Выбрал бы я другой язык — кто знает, было бы так же или нет, но я рад тому, как все сложилось. Но интуиция подсказывает мне, что на плюсах я не был бы так рад прогать.
Для меня два любимых языка: С и С#. С — очень производительный, низкоуровневый, никаких тебе объектов, перекладывай байтики да радуйся. Шарп — уже ответил, многогранность и ортогональность, любая задача решается сообразно своей сложности. Плюсы же — что-то среднее. Кто-то скажет — золотая середина, мощь ООП с производительностью С, однако для меня скорее ни рыба, ни мясо. Тем более, после обещания МС сделать шарп не медленнее, чем С++.
Как можно не любить С++, но при этом любить С, а самому программировать на Сишарпе — для меня загадка. Странные у вас предрасположенности. Язык С, я считаю, не имеет права находится вообще в этом обсуждении, поскольку имеет ограниченную сферу применения.
C# не решает любую задачу соразмерно своей сложности, поскольку содержит overhead и набор протекающих абстракций, о которых вы сами здесь и говорите. Вообще, я бы сначала подождал, пока вы сделаете несколько проектов разноплановых, и потом я бы с вами поговорил. У вас есть некоторое знание технологий, но только этого мало, чтобы на столько категорично рассуждать.
C# не решает любую задачу соразмерно своей сложности, поскольку содержит overhead и набор протекающих абстракций, о которых вы сами здесь и говорите. Вообще, я бы сначала подождал, пока вы сделаете несколько проектов разноплановых, и потом я бы с вами поговорил. У вас есть некоторое знание технологий, но только этого мало, чтобы на столько категорично рассуждать.
> Я не спорю, что предусмотреть в .Net весь возможный функционал невозможно, а если бы это и было, то он бы разбух и стал бы похожим на винапи монстром
Коллега, определитесь, вы или крестик снимите… Или System.Windows.Forms.Screen.AllScreens возьмите.
Коллега, определитесь, вы или крестик снимите… Или System.Windows.Forms.Screen.AllScreens возьмите.
Предлагаете в консоль или WPF-приложение тащить System.WIndows.Forms.dll?..
Предлагаю не жаловаться на несправедливость мира в стиле «А вы на шкаф залезьте!»
но, кстати, консоль рисующпя в мультимониторной конфигурации — это здорово.
Для исследовательских целей есть WRK — ядро WinXP
Да, и будут продавать к нему забавные обои, иконки по 0.99$, а так же буст производительности на 24 часа за 5$.
Вес теперь упирается в CLR. Mono как я слышал открыта только для Линукса, а для айОсов и Андроидов нужно платить.
Подскажите, как завязаны новые фишки шарпа с CLR? Скомпилированный Roslyn'ом код будет без проблем работать в mono runtime, или ее еще допиливать?
Подскажите, как завязаны новые фишки шарпа с CLR? Скомпилированный Roslyn'ом код будет без проблем работать в mono runtime, или ее еще допиливать?
В CLR уже очень давно ничего такого не добавляли. Там до смешного иногда доходило — например, вариантные параметры у дженериков (in/out) появились в C# 4, но при этом на уровне CLR поддержка для них была еще в 2.0…
Mono как я слышал открыта только для Линукса, а для айОсов и Андроидов нужно платить.Открыто всё. Просто если код реализации фреймворка под MIT-лицензией, то рантайм (реализация CLR) под LGPL. На iOS вам LGPL не позволит слинковаться статически (то есть, в магазин эппловский это уже не попадёт), а под проприетарной лицензией дают только за денежку. На андройде использовать бесплатно можно, но без платных инструментов это долгое и муторное занятие.
Из непосредственно более интересного для многих здесь — language design notes по C# и VB выложены на CodePlex. Причем в режиме дискуссии, т.е. можно конструктивно предлагать :)
Проекту Roslyn уже сто лет в обед. И с самого начала его собирались делать open source. Уход Балмера тут совершенно ни при чем.
Круто, что они его, наконец, доделали!
Круто, что они его, наконец, доделали!
Здорово, конечно, но что-то я не нашел там System.Web.UI.TemplateParser класс на aspnetwebstack.codeplex.com. Этот зверь парсит aspx/ascx язык. Его переписали, видимо?
Это часть классического ASP.NET, а не MVC — её пока не опенсорсили.
Да, но оно под MS Reference source licence То есть вот мне нужно было переписать тот класс для себя, а взять его оттуда я не мог по лицензии. Пришлось что-то свое писать.
Вчера на Build Keynote показывали VS со встроенным Roslyn. Как раз когда пришел Мигель. Подсветка неиспользуемых конструкций и меню рефакторинга (с лампочкой) выглядело очень-очень похоже на Resharper. Неужели они решили реализовать все фичи Reshrpera и как на это реагирует JetBrains?
Пробую так:
git clone git01.codeplex.com/roslyn
Но не получается, есть идеи, что пошло не так?
P.S. гугл говорит, что нужно собрать git из сорцов с libcurl, но есть же более простой путь? Может кто поделится архивом, если смог скачать?
git clone git01.codeplex.com/roslyn
Но не получается, есть идеи, что пошло не так?
Cloning into 'roslyn'...
remote: Counting objects: 10574, done.
remote: Compressing objects: 100% (4431/4431), done.
remote: Total 10574 (delta 6223), reused 10359 (delta 6091)
Receiving objects: 100% (10574/10574), 16.94 MiB | 223.00 KiB/s, done.
error: RPC failed; result=56, HTTP code = 200
Resolving deltas: 100% (6223/6223), done.
P.S. гугл говорит, что нужно собрать git из сорцов с libcurl, но есть же более простой путь? Может кто поделится архивом, если смог скачать?
На вкладке Source Code на сайте codeplex есть кнопочка Download, если я правильно вас понял.
Да, спасибо, я почему-то не обратил внимание на вкладки, ибо на самой странице предлагалось качать git'ом.
P.S. Есть одна вещь, которую я, тем не менее, никогда не пойму. За что кто-то поставил мне минус в карму? Я не мог не заметить, ибо у меня было пограничное значение в 10 единиц, позволяющее голосовать. Это надо взять, не полениться, зайти на страницу, и нажать минус. Поразительно.
P.S. Есть одна вещь, которую я, тем не менее, никогда не пойму. За что кто-то поставил мне минус в карму? Я не мог не заметить, ибо у меня было пограничное значение в 10 единиц, позволяющее голосовать. Это надо взять, не полениться, зайти на страницу, и нажать минус. Поразительно.
Codeplex поддерживает хостиг исходников в TFS либо Mercurial, Git не поддерживался.
Ух, кажется в документации даже есть полный список новых возможностей C#
roslyn.codeplex.com/wikipage?title=Language%20Feature%20Status&referringTitle=Documentation
Количество со статусом Done и Planned радует =)
roslyn.codeplex.com/wikipage?title=Language%20Feature%20Status&referringTitle=Documentation
Количество со статусом Done и Planned радует =)
Что за «indexed member» с баксами, кто в курсе?
Эх, string interpolation только «maybe»…
Эх, string interpolation только «maybe»…
Я так понял, что это полный аналог обычного индексатора.
roslyn.codeplex.com/discussions/540569
roslyn.codeplex.com/discussions/540569
var payload = new JsonObject
{
["first name"] = "Donald",
["last name"] = "Duck",
$city = "Duckburg" // equivalent to ["city"] = "Duckburg"
};Бред какой-то. Укуренный синтаксис ради экономии двух-трёх символов. Неужели это так часто используется?
Возможно, что это будет работать как «Lightweight dynamic member access»
roslyn.codeplex.com/discussions/540574
roslyn.codeplex.com/discussions/540574
payload.$city = "Duckburg"; // ((dynamic) payload).city = "Duckburg"Maybe, и синтаксис какой-то странный (с обратным слешем).
Или это только мне так кажется?
Зато обсуждается метапрограммирование!
roslyn.codeplex.com/discussions/541131
var message = "Hello, \{name}!"Или это только мне так кажется?
Зато обсуждается метапрограммирование!
roslyn.codeplex.com/discussions/541131
Не знаю как вы, а я прям сплю и вижу: когда уже Майкрософт сделает качественный собственный инструментарий для разработки под IOS, Android и Linux. Я считаю, что это взорвет распространенность C# до небывалых пределов и значительно облегчит жизнь многим разработчикам.
Зачем MS поддерживать конкурентные платформы? Особенно Android? Мне кажется, что слухи о покупки Xamarin закончатся блокированием возможности разработки на C# под Android. Про разработку под iOS сложный случай, т.к. MS & Apple делают вид что конкурируют, а по факту разделили рынки и продвигаются слаженно, олигопольно. Патентные споры разрешают переговорным путем через взаимное лицензирование патентов и технологий. Совместно воюют против гугла.
Возможность разработки на C# для всех платформ => возможность для разработчиков охватить аудиторию побольше при минимуме кода => больше разработчиков на C# => больше разработчиков под винду => больше приложений под метровую винду => меньше возмущений про малое количество приложений => больше покупателей => больше бабла => метро не провалилось.
Майкрософту очень нужно отхапать кусок этого рынка. Любой ценой.
«Поддержка» андроида шарпом на андроиде не очень-то скажется, потому что там и так приложений дофига, никто не заметит разницы.
Майкрософту очень нужно отхапать кусок этого рынка. Любой ценой.
«Поддержка» андроида шарпом на андроиде не очень-то скажется, потому что там и так приложений дофига, никто не заметит разницы.
На самом деле Xamarin-овское дополнение к студии вполне себе неплохо работает в этом качестве. Стоит, правда, как авианосец, но это детали уже.
>> После ухода Стива Балмера компания Microsoft продолжает радовать приятными новостями: спустя несколько лет наконец-то вышел MS Office для iPad
Как-то наивно думать, что это зависимые события…
Как-то наивно думать, что это зависимые события…
Может быть, что события и связаны. Смена руководства частенько приносит большие перемены.
А не получится ли так, что MS просто возьмет и купит Xamarin?
Рихтер в недавнем интервью упоминал о подобных слухах.
Пока Xamarin просто берет и скупает разрабов делающих хоть что-то значимое для Xamarin в open source. Бывет откроешь проект на github, он бурно развивался и вдруг застыл, а через несколько месяцев автор светится в сети как сотрудник Xamarin.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Microsoft раскрыла исходный код компилятора С#