Пользователь
250,2
рейтинг
3 апреля 2014 в 23:11

Разработка → Microsoft раскрыла исходный код компилятора С#

После ухода Стива Балмера компания Microsoft продолжает радовать приятными новостями: спустя несколько лет наконец-то вышел MS Office для iPad, опубликован исходный код JS-библиотеки WinJS (Windows Library for JavaScript), и даже в IE11 внедрили достойные инструменты веб-разработки.

А вот теперь самый большой сюрприз: сегодня запущен сайт .NET Foundation, на котором «для начала» собрано 24 проекта с открытыми исходными кодами, в том числе недавно вышедший .NET Compiler Platform (Roslyn)!



Проект Roslyn — это open-source компиляторы Visual Basic и C#, с богатыми API для анализа кода. Над API надстраивается множество полезных сервисов. Это такие же интерфейсы, которые используются в Visual Studio.



Исходный код (под лицензией Apache 2)
Документация
FAQ
Анатолий Ализар @alizar
карма
739,5
рейтинг 250,2
Пользователь
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Разработка

Комментарии (137)

  • +17
    Скажите, а что из этого последует и повлияет на разработку на C#? Извините за возможно глупый вопрос.
    • +17
      На мой взгляд это поможет Mono сообществу. На C# будет удобнее разрабатывать софт под *nix и Android.
      • +9
        А сейчас Mono не Xamarin? Извините за возможно глупый вопрос.
        • 0
          Да, разработчик Mono компания Xamarin. После ребрендинга Mono переименовали.
          Возможно появятся и другие компиляторы, и под другие ОС.
        • +8
          Mono — открытая реализация CLR и BCL. Xamarin — контора во главе с Мигелем, которая всё это дело координирует и пилит, попутно имея гешефт с мобильных разработок.
        • +2
          Как уже выше писали Xamarin — компания, которая развивает открытый проект Mono. При этом она поверх моно развивает такие коммерческие продукты, как Xamarin.iOS, Xamarin.Android и Xamarin.Mac. Когда говорят, что пишут на Xamarin, имеют ввиду эти коммерческие проекты.
      • –3
        когда Microsoft открыла WinCE 3.0 то довольно скоро виндовс телефоны приказали долго жить
    • +1
      Скажите, а что из этого последует и повлияет на разработку на C#?

      Опенсорсность на C# вряд ли повлияет, а вот что компилятор переписан с нуля и теперь со всех сторон облепляем — должно дать толчок к стремительному развитию языка и инструментов.
    • +3
      Насколько я знаю, у Mono (Xamarin) есть проблемы с лицензией, вследствие чего та же Unity использует старую версию его рантайма.
      А тут получится, что версия от Microsoft будет более свободной, чем версия от opensource-комьюнити :)
      • +1
        Mono — это CLR, а не только реализация самого c#. Так что…
        • +3
          Надеемся, что CLR тоже откроют в ближайшее время.
          • –1
            CLR, скорее всего, не откроют. Windows Server должен жить.
  • +111
    В офис Microsoft прокрался Столлман и покусал там кучу народу. Иначе это объяснить невозможно.
    • +19
      Он не просто в офис прокрался, он прокрался на самый верх. Правда, пришлось прикинуться индусом.
      • +12
        Или заранее покусал индуса.
      • +3
        Вас не уволят за раскрытие тайны?)
        • +6
          Нет, information wants to be free же.
          • +1
            А по мне так смахивает на инсайдерскую информацию.
          • +1
            Но за политнекорректность могут ;)
      • –1
        Был IGNUcius, а теперь INDUSius.
    • +3
      В офис Microsoft прокрался Столлман и покусал там кучу народу.

      Кто-то пострашнее Столлмана прокрался. Там лицензия Apache, а не GPL.
      • +3
        Наоборот… если бы Столлман прокрался — все производные тоже были бы GPL opensource, а теперь не факт.
        • +3
          Даже укус Столлмана не способен творить такие чудеса.
    • +2
      ПФФ, большинство того, что в списке открыто довольно давно.
    • 0
      в принципе а зачем их на данном этапе развития прятать? и от кого?
  • +10
    Ждем IDE от JetBrains. :)
    • +8
      Зачем, если есть ReSharper?
      • +5
        Дык, для разработки не под виндой же. Всяко лучше Xamarin Studio будет. Да и на JetBrains-овские продукты стоимость далеко не так кусается, как у Visual Studio.
        • 0
          Да ладно, 500 баксов (+ $150 за решарпер) — не такая уж и большая сумма. А вот заменить весь пакет расширений к студии будет весьма проблематично.
          • +1
            Лицензия для личного пользования сред разработки JetBrains стоит 200 баксов. Там будет встроенный решарпер. 350-400 баксов уже не такая маленькая разница, для кого-то может оказаться существенной, да и одна среда разработки на всех трех платформах тоже немаленькая плюшка.

            По моим наблюдениям за собой, коллегами и знакомыми, кто тоже на шарпах пишет, большинство пользуются голой студией + решарпером + (опционально) плагином какой-либо системы контроля версий. Под голой студией я понимаю блокнот с подсветкой кода и автодополнением, проекты, интеграцию с дебаггером и графические редакторы для windows forms и wpf. Все это есть и в Jetbrain-овских средах.

            Все это не холивара ради, просто не вижу, что такого еще народ накручивает в студию (если это не фирмоспецифичные внутренние плагины), что существенно увеличило бы удобство вышеназванного варианта.

            • 0
              IDEA стоит ~$500 тех же, не думаю что среда разработки под .NET будет стоить дешевле.
              • +1
                200 же, если персональная.
                • +5
                  Бесплатно же, если Community edition.
            • 0
              Но и не такая большая, чтобы менять. Это может привлечь людей, которые только начинают писать на C#, если у них нет давления со стороны коллег и/или работодателя.
          • +1
            Для os x — добавляем стоимость собственно винды и parallels/vmware, и совсем печально.
            • +1
              +200$ — печаль для человека, который купил мак/макбук? Действительно, печаль
              • 0
                В итоге 40% стоимости моего макбука по его цене пятилетней давности (в рублях)… Не, я не готов.
        • +4
          Они открыли только компилятор. Вся же прелесть заключается в виртуальной машине, которая, насколько я понимаю, остается закрытой.
          • +3
            Все же количество людей, желающих поковырять стандартные библиотеки и компилятор в разы больше, чем тех, кто будет подкручивать JIT :)
  • +8
    Мне даже страшно представить, чего ожидать дальше. OpenWindows? Все равно Win9 следующую версию не назовут, чтобы не путаться с Win9x.
    • –10
      • +19
        Это не та Windows, что вы ищите.
      • +1
        Я удивляюсь, вы в каждый топик лезете с рекламой ReactOS, и каждый раз вас минусуют, но вы все равно продолжаете. Остается только поражаться, откуда у вас берется положительная репа, чтобы не попасть в R/O.

        Что касается бесплатной винды, пока только WinPhone (на днях была инфа, что мобильная винда теперь будет бесплатной), но дело движется в правильном направлении
        • 0
          На конференции объявиили о бесплатной винде для девайсов с диагональю экрана меньше 9 дюймов уже сейчас, и о том, что винда станет вообще бесплатной после выхода Windows для Intel Galileo и подобных.
        • –1
          Не совсем. Есть WinPE, ниже вот про WRK довели сведения. Так что теоретически бесплатная винда могла бы существовать, насколько я понимаю. Но нужно дописать под все это оболочку и довести до ума. А люди, умеющие и желающие делать подобное, скорее пойдут пилить любимый дистрибутив линукса, чем ковыряться в винде.
          • –1
            Винда не вечна, и скорее на последнем издыхании, чем в начале жизни. Будет принициально новая ось от МС, вопрос только в сроках. Я ставлю что примерно через 5 лет будет отход от винды, как было DOS -> WIN.
            • +2
              А зачем?

              В данный момент я не вижу необходимости в какой-то революционной ОС, а обои я почти никогда не вижу, так что нескучными ими меня не завлечешь.

              Если говорить серьезно, то, касаемо операционных систем от MS, я был бы рад видеть развитие ветки XP. Но, так как это маловероятно (если чудом не произойдет перевод и ее в разряд Open Source), то приятно было бы увидеть именно развитие пусть даже текущих веток. Именно развитие, а не постоянное переделывание всего с нуля. Не думаю, что в современных версиях ОС все настолько плохо, что опять нужно все делать заново.
              • 0
                То есть винапи это круто?

                Нет, для пользователей-то может и все равно, только вот для разработчиков это просто ужас. Половина параметров — необязательная, вторая половина — аргументы, в которые нужно передать определенные значения иначе будет ошибка, третья половина — 100500 странных структур, передающихся по указателю. Не говоря про зоопарк функций: почти каждая функция существует в двух вариантах: aaa и aaaEx, кроме того, и это количество удваивается для функций с «юникод» и «не-юникод» строками, из-зачего винапи чуть более, чем полностью использует макросы, чтобы хоть как-то справится с этим адом.

                И вы хотите сказать, что все это менять не надо?
                • +1
                  Если за два десятка лет переписывания ничего толком не поменялось в этом плане, кто даст гарантии, что через 5 лет оно окажется чем-то кардинально иным изнутри?

                  Такая ситуация, кстати, не только относительно ОС. Если в вашем комментарии заменить винапи на PHP, то получится типичный комментарий пэхэпэ-хейтера в треде про веб-разработку. Там тоже уже который год пророчат смерть данному языку. Но пока сфера применения удерживает свои позиции, реальные изменения в объеме использования не так уж значительны.
                  • 0
                    То есть винда будет вечной? Потому что это единственное утверждение, противоречащее моему «когда-нибудь винда умрет».

                    А к тому, что это случится скоро — скажем так, есть симптомы. Тем более, что активно пилятся в research операционки-претендентки.
                    • 0
                      Ничто не вечно. Но если ту самую «принципиально новую ось» MS назовут очередной Windows, можно ли будет считать винду умершей?
                      • 0
                        Не назовут :) Почти уверен. Нужно же показать, что это «принципиально новая технология (но с возможность запуска старых приложений)™»

                        но если будет называться также… Я все равно буду считать её не-виндой, как ->NT
                • 0
                  А Как же Windows Runtime? Хотя как я понимаю это не совсем то…
                  • +1
                    У WRT таких проблем нет. API четкое, хотя уже стали появляться deprecated. С юникодом проблем нет, все строки представлены в UCS-2. Макросов никаких нет (мне не встречались). С Component Extensions отпадает нужда возиться с COM.
                  • 0
                    Это как раз то, что нужно. АПИ очень изящное, все методы, выполняющиеся дольше 50мс обязаны быть асинхронными и не вешать комп… Но, есть один нюанс — все современные хитросделанные программы используют различные костыли этого самого винапи и гвоздями к нему прибиты, поэтому не идут. Сами посмотрите, насколько успешны Surface с WinRT, на которых не идет какая-нибудь KB2. А раз не идет RB2, то система — фигня… Примерно так думает рынок. Я, наоборот, всеми руками ЗА WRT. Но, селяви. Без обратной совместимости с ненавистным апи платформа не взлетит.
                    • 0
                      WinRT — это прекрасное general purpose API, однако с некоторыми его недоработками на практике приходится сталкиваться. Например, не всегда хорошо иметь только асинхронные методы, а сделать из ассинхронных синхронные — это местами вытекает в серьезные проблемы с контролем ошибок.
                      • 0
                        Никогда не испытывал проблем с контролем ошибок в многопотоке после появления async/await
                        • 0
                          из ассинхронных синхронные. Ваш async/await асинхронный.
                          • 0
                            Простите, а зачем? Добиться синхронизации же не так уж и сложно, делать методы полностью синхронными не самая лучшая затея как по мне.
                            • 0
                              Это очень редкий случай, но я через это проходил.При определенных условиях — это не только сложно, но и невозможно. API не все умеет для таких сценариев. Зачем: чтобы не переписывать много зависимого кода, который работает в рамках синхронной модели.
                          • 0
                            await позволяет ожидать асинхронную задачу, причем если она свалится, то эксепшн будет передан в вызывающий поток, как будто оно произошло синхронно. Подробнее можно ознакомиться тут
                            • 0
                              Не в вызывающий поток :) А в поток, который задан текущим SynchronizationContext — это раз. Я знаю предмет лучше Вас — это два. Вы суть проблемы не понимаете. Вы не о том.
                              • 0
                                Ну тогда поделитесь опытом, в чем же суть проблемы? Рад буду узнать что-нибудь новенькое. Комментарии за этим же и нужны, не для срача же, право?

                                А в поток, который задан текущим SynchronizationContext — это раз.

                                афайк контекст выставляется в таске, но как правило опускается, и используется контекст вызывающего кода — разве нет?
                                • 0
                                  Суть проблемы в том, что если нужно вам дропнуть в WinRT специфический конкретный асинхронный таск, то вместе с этим таском дропнется и COM объект (и не один), который дропаться никак не должен. Это кстати и есть пример abstraction leak.

                                  Про SС — вызывающий код может находится в потоке, который создал я сам. В этом случае то, что стоит после await не будет выполнено в вызывающем потоке, если это явно не написали такую логику.
                • 0
                  Уже заменили. Используйте .net. Для большей части вообще можно забыть о том, что такое winapi, для оставшейся небольшой части можно спокойно найти P/Invoke обертки.
                  • 0
                    Не заменили, а спрятали под ковер.

                    И да, я .Net-программист. И именно по этим соображениям. Как рекламировала Java: Write once, run anywhere
                    • +1
                      > Не заменили, а спрятали под ковер.

                      Вы хотите поговорить об этом? Часто ли вас беспокоит, что находится под коврами и в фундаментах помещений, где вы находитесь?
                      • 0
                        Когда-нибудь слышали о законе дырявых абстракций?..
                        • 0
                          Не знал, что он именно про винапи…
                          • 0
                            Он применим к любым абстракциям, а весь прикладной софт и большая часть системного построены на абстракциях. Чтобы система адекватно функционировала, она должна знать об абстракциях, используемых уровнем выше и ниже. Поэтому няшность .Net лишь частично компенсирует кривость винапи.

                            Одним словом, на кривом фундаменте прочный и красивый дом не выстроить.
                            • 0
                              Как вы думаете, сколько программистов знают об абстракциях уровнем ниже WinApi? Уровнем ниже WinRT? Уровнем ниже Qt?

                              Есть ли у вас другой глобус?
                              • 0
                                Программисты WinAPI обязаны знать об абстракциях ниже WinAPI, по этому же правилу, представлять, что такое HAL и пр.

                                Ну а прикладные программисты работают с АПИ системы, поэтому лезть глубже него им не нужно, хотя и полезно.

                                Все это никак не противоречит изначальному утверждению, что на кривом винапи нельзя построить изящного программного интерфейса. А вот на WinRT можно, вопрос только в том, чтобы на него пересадить пользователей.
                        • 0
                          В .Net закон дырявых абстракций обычно не из-за WinAPI проявляется, ИМХО. К тому же, где, например в Silverlight WinAPI?
                          • 0
                            Еще раз, закон дырявых абстракций применим к любым абстракциям, а любое АПИ — это набор абстракций, сгруппированных для решения какой-либо задачи.

                            Насчет Silverlight не очень понял, что имелось ввиду…
                            • 0
                              Вы говорите очень общими словами, они не отражают истину.
                              Давайте сначала формально объясним, что такое «закон применим» :) Иначе из его применимости не следует, что какое-то явление имеет место.

                              На счет Silverlight все просто: это не только не WinApi, но и не .Net даже. Поэтому, говорить, что из .Net торчит WinAPI — это неверно.
                              • 0
                                Давайте сначала формально объясним, что такое «закон применим»

                                Очень просто. Закон применим, в данном случае: «для грамотного проектирования своего уровня разработчику нужно знать уровень ниже (апи ОС) и уровень выше (кейсы использования разрабатываемого слоя).

                                На счет Silverlight все просто: это не только не WinApi, но и не .Net даже. Поэтому, говорить, что из .Net торчит WinAPI — это неверно.

                                Из .Net торчит винапи хотя бы в том смысле, что он гвоздями прибит к нему. Конечно, есть Mono, который в этом плане свободен, но в нем 50% функционала обычного фреймворка в стадии coming soon.

                                Хотя после последних заявлений МС об опен-сорсовости и слухов о покупке Xamarin можно надеяться на постепенный переход в стадию большей мобильности.

                                При чем тут Silverlight до сих пор не ясно :)
                                • 0
                                  Это пустословие, коллега :)
                                  Вы сначала определите, что такое грамотный уровень, а что такое — неграмотный :) Но я думаю мы эту цепочку будем долго раскручивать.

                                  Гораздо проще здесь опираться на то, что говорит опыт. А опыт говорит мне, что WinAPI в .Net торчит там, куда разработчик залез сам по ошибке. Классический пример — это попытки низкоуравневой работы с Windows Forms, вызов всяких API функций для этого, итд. В этом случае не нужно использовать технологии, которые не предназначены для такого. Есть WPF, есть Silverlight.
                                  • 0
                                    Вы сначала определите, что такое грамотный уровень, а что такое — неграмотный :)

                                    ИМХО это понятие интуитивно-аксиоматическое, у каждого свое, и как-то конкретно его определить не получится (как точка в геометрии, все множество фигур сводится к точке, но сама точка вводится аксиоматически и определения не имеет).
                                    Гораздо проще здесь опираться на то, что говорит опыт. А опыт говорит мне, что WinAPI в .Net торчит там, куда разработчик залез сам по ошибке.

                                    Согласен, но так ведь случается не всегда.

                                    Самый простой пример — нужно показать что-нибудь на определенном мониторе в многоэкранной конфигурации. Я не спорю, что предусмотреть в .Net весь возможный функционал невозможно, а если бы это и было, то он бы разбух и стал бы похожим на винапи монстром, весом в гигабайты, но потребность в подобном иногда встречается.

                                    Я считаю, что так или иначе винапи отжил свое, и хотя его полуразвалившееся тело запихали под ковер, запах из-под него периодически доносится. Я очень надеюсь на дальнейшее развитие Singularity, Midori и прочих проектов в лице Drawbridge, на C# в качестве системного ЯП и продуманный микроядерный дизайн ОС. Пока что все это лишь в мечтах/исследовательских проектах.
                                    • 0
                                      Несмотря на то, что я и C++ программист, я считаю, что C# и .Net придумали не для того, чтобы думать много о том, как он работает. Какие абстракции создает, что там внутри сидит, какой там там ассемблер генерится, если я P/Invoke сделаю для memcpy, итд. Если об этом думать, то получится программирование еще сложнее, чем на С++. Основной критерий тут, имхо, — это трудозатраты и расширяемость. Если мы можем писать на C# код, который нас устраивает по функциональной корректности, производительности и расширяемости — это даже вредно знать, что там внутри сидит.
                                      • 0
                                        Несмотря на то, что я C# программист, я считаю, что полезно знать, что сидит внутри, потому что хотя преждевременные оптимизации и зло, при прочих равных лучше выбрать лучший с ТЗ производительности алгоритм, а о критериях этой «лучшести», как правило, приходится судить, учитывая особенности нижележащего уровня.

                                        Если мы можем писать на C# код, который нас устраивает по функциональной корректности, производительности и расширяемости — это даже вредно знать, что там внутри сидит.

                                        А я наоборот считаю, что знать что сидит внутри — никогда не лишне, даже если не пригодится.

                                        Впрочем, я полагаю, конструктивная часть диалога закончилась, а срач в комментах никому еще не помог. Был рад обсудить эту тему. Удачи.
                                        • 0
                                          А зачем вам C# тогда? Используйте C++ и вы получите лучший код за ту же цену.
                                          • +1
                                            Мне не нравится С++ как язык. Мне он кажется перегруженым.

                                            В то время в шарпе я нахожу то, что мне нравится. Не гнушаюсь и фунциональным стилем программирования, linq-ом и прочим, чего в С++ отродясь не было и когда введут в стандарт — не ясно. Не говоря про то, что я не десктоп-разработчик, а ASP.Net/SP.
                                            • 0
                                              Не гнушаюсь и фунциональным стилем программирования, linq-ом и прочим, чего в С++ отродясь не было и когда введут в стандарт — не ясно.

                                              Пока вы там спите, уже 2 стандарта вышло с функциональным программированием в С++
                                              • 0
                                                Хуже лямбд в С++ только лямбды в VB.Net :)

                                                А вот LINQ нежданчик. Спасибо за наводку.

                                                Однако остальные проблемы это не решает. Лично для меня код на плюсах абсолютно нечитаем. Я не говорю, что язык плох, но персонально для меня он не подходит. К тому же он больше подходит для системной разработки, когда как .Net — универсальный, хочешь — консольки клепай, а хочешь — веб-части для SP ваяй, язык один. Единственный язык с подобной свободой — Java. Но так уж вышло, что .Net мне подошел больше. Да и из-за него я попал туда, где работаю сейчас. И я очень рад, что так произошло, что руководство на просьбу «можно мне хард заменить, а то что-то дурит» отвечает «а давай мы тебе SSD поставим, чтоб больше не мучался», когда коллеги рады помочь, и у них есть чему поучиться, когда сис.админ оперативно решает задачи и помогает со всякими настройками, когда тебе дают задачу, и ты волен писать что хочешь и как хочешь (сообразно code style команды, офк), но решить поставленную задачу — если не это программировать себе в удовольствие, то даже не знаю, что тогда назвать :) Выбрал бы я другой язык — кто знает, было бы так же или нет, но я рад тому, как все сложилось. Но интуиция подсказывает мне, что на плюсах я не был бы так рад прогать.

                                                Для меня два любимых языка: С и С#. С — очень производительный, низкоуровневый, никаких тебе объектов, перекладывай байтики да радуйся. Шарп — уже ответил, многогранность и ортогональность, любая задача решается сообразно своей сложности. Плюсы же — что-то среднее. Кто-то скажет — золотая середина, мощь ООП с производительностью С, однако для меня скорее ни рыба, ни мясо. Тем более, после обещания МС сделать шарп не медленнее, чем С++.
                                                • 0
                                                  Как можно не любить С++, но при этом любить С, а самому программировать на Сишарпе — для меня загадка. Странные у вас предрасположенности. Язык С, я считаю, не имеет права находится вообще в этом обсуждении, поскольку имеет ограниченную сферу применения.

                                                  C# не решает любую задачу соразмерно своей сложности, поскольку содержит overhead и набор протекающих абстракций, о которых вы сами здесь и говорите. Вообще, я бы сначала подождал, пока вы сделаете несколько проектов разноплановых, и потом я бы с вами поговорил. У вас есть некоторое знание технологий, но только этого мало, чтобы на столько категорично рассуждать.

                                                  • 0
                                                    По идее мне следовало бы просто лайкнуть пост и на этом закончить диалог, но репы недостаточно, поэтому отвечу текстом. Рад был пообщаться, мир тесен, авось на какой-нибудь конфе встретимся и продолжим дискуссию. Au revoir.
                                    • 0
                                      > Я не спорю, что предусмотреть в .Net весь возможный функционал невозможно, а если бы это и было, то он бы разбух и стал бы похожим на винапи монстром

                                      Коллега, определитесь, вы или крестик снимите… Или System.Windows.Forms.Screen.AllScreens возьмите.
                                      • 0
                                        Предлагаете в консоль или WPF-приложение тащить System.WIndows.Forms.dll?..
                                        • 0
                                          Предлагаю не жаловаться на несправедливость мира в стиле «А вы на шкаф залезьте!»
                                        • 0
                                          но, кстати, консоль рисующпя в мультимониторной конфигурации — это здорово.
                                          • 0
                                            Ну а если взять WPF-приложение? У него голова с ума сходить начинает, юзать System.Windows.Media или System.Windows.Drawing, т.к. типы там одни и те же, а писать алиасы на каждый чих задолбаешься.
                                            • 0
                                              Вы мне предлагаете по этому скудному описанию угадать что именно вы делаете непраильно, что в одном файле нужно добавлять эти 2 неймспейса в using?
    • +1
      Для исследовательских целей есть WRK — ядро WinXP
      • 0
        И там прям открыт код? Или как с WinPE, начиная с Vista: вот вам бесплатное ядро Win, обвязывайте его чем хотите и как хотите?
        • +1
          Там открытый код с ассемблером, но без графической подсистемы и всего того, что лежит в Win32k.sys
    • –2
      Да, и будут продавать к нему забавные обои, иконки по 0.99$, а так же буст производительности на 24 часа за 5$.
  • +1
    Вес теперь упирается в CLR. Mono как я слышал открыта только для Линукса, а для айОсов и Андроидов нужно платить.
    Подскажите, как завязаны новые фишки шарпа с CLR? Скомпилированный Roslyn'ом код будет без проблем работать в mono runtime, или ее еще допиливать?
    • +2
      В CLR уже очень давно ничего такого не добавляли. Там до смешного иногда доходило — например, вариантные параметры у дженериков (in/out) появились в C# 4, но при этом на уровне CLR поддержка для них была еще в 2.0…
    • +3
      Mono как я слышал открыта только для Линукса, а для айОсов и Андроидов нужно платить.
      Открыто всё. Просто если код реализации фреймворка под MIT-лицензией, то рантайм (реализация CLR) под LGPL. На iOS вам LGPL не позволит слинковаться статически (то есть, в магазин эппловский это уже не попадёт), а под проприетарной лицензией дают только за денежку. На андройде использовать бесплатно можно, но без платных инструментов это долгое и муторное занятие.
      • +2
        Мигель хитропопый. Как по мне, так это один из самых удачных примеров монетизации opensource-проекта.
  • +2
    Из непосредственно более интересного для многих здесь — language design notes по C# и VB выложены на CodePlex. Причем в режиме дискуссии, т.е. можно конструктивно предлагать :)
  • +4
    Проекту Roslyn уже сто лет в обед. И с самого начала его собирались делать open source. Уход Балмера тут совершенно ни при чем.
    Круто, что они его, наконец, доделали!
  • 0
    Здорово, конечно, но что-то я не нашел там System.Web.UI.TemplateParser класс на aspnetwebstack.codeplex.com. Этот зверь парсит aspx/ascx язык. Его переписали, видимо?
  • 0
    Вчера на Build Keynote показывали VS со встроенным Roslyn. Как раз когда пришел Мигель. Подсветка неиспользуемых конструкций и меню рефакторинга (с лампочкой) выглядело очень-очень похоже на Resharper. Неужели они решили реализовать все фичи Reshrpera и как на это реагирует JetBrains?
  • –2
    Пробую так:
    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, но есть же более простой путь? Может кто поделится архивом, если смог скачать?
    • +1
      На вкладке Source Code на сайте codeplex есть кнопочка Download, если я правильно вас понял.
      • –1
        Да, спасибо, я почему-то не обратил внимание на вкладки, ибо на самой странице предлагалось качать git'ом.

        P.S. Есть одна вещь, которую я, тем не менее, никогда не пойму. За что кто-то поставил мне минус в карму? Я не мог не заметить, ибо у меня было пограничное значение в 10 единиц, позволяющее голосовать. Это надо взять, не полениться, зайти на страницу, и нажать минус. Поразительно.
    • +1
      Codeplex поддерживает хостиг исходников в TFS либо Mercurial, Git не поддерживался.
      • +1
        Сто лет как поддерживается. Примерно с тех пор, когда в студию поддержку Git добавили.
  • +1
    Ух, кажется в документации даже есть полный список новых возможностей C#
    roslyn.codeplex.com/wikipage?title=Language%20Feature%20Status&referringTitle=Documentation

    Количество со статусом Done и Planned радует =)
    • 0
      Что за «indexed member» с баксами, кто в курсе?

      Эх, string interpolation только «maybe»…
      • 0
        Я так понял, что это полный аналог обычного индексатора.
        roslyn.codeplex.com/discussions/540569

        var payload = new JsonObject
        {
            ["first name"] = "Donald",
            ["last name"] = "Duck",
            $city = "Duckburg" // equivalent to ["city"] = "Duckburg"
        };
        • 0
          Бред какой-то. Укуренный синтаксис ради экономии двух-трёх символов. Неужели это так часто используется?
          • 0
            Возможно, что это будет работать как «Lightweight dynamic member access»
            roslyn.codeplex.com/discussions/540574
            payload.$city = "Duckburg"; // ((dynamic) payload).city = "Duckburg"
      • 0
        Maybe, и синтаксис какой-то странный (с обратным слешем).
        var message = "Hello, \{name}!"

        Или это только мне так кажется?

        Зато обсуждается метапрограммирование!
        roslyn.codeplex.com/discussions/541131
        • 0
          Ой, нет, не обсуждается =(
          Это дискуссии, а не документация…
        • 0
          Да ничего, вроде, синтаксис. Непривычно, но логично.

          Эх, метапрограммирование… Очень надеюсь, что с новым компилятор наконец-то всерьёз за него возьмутся.
  • +4
    Не знаю как вы, а я прям сплю и вижу: когда уже Майкрософт сделает качественный собственный инструментарий для разработки под IOS, Android и Linux. Я считаю, что это взорвет распространенность C# до небывалых пределов и значительно облегчит жизнь многим разработчикам.
    • 0
      Зачем MS поддерживать конкурентные платформы? Особенно Android? Мне кажется, что слухи о покупки Xamarin закончатся блокированием возможности разработки на C# под Android. Про разработку под iOS сложный случай, т.к. MS & Apple делают вид что конкурируют, а по факту разделили рынки и продвигаются слаженно, олигопольно. Патентные споры разрешают переговорным путем через взаимное лицензирование патентов и технологий. Совместно воюют против гугла.
      • +2
        Возможность разработки на C# для всех платформ => возможность для разработчиков охватить аудиторию побольше при минимуме кода => больше разработчиков на C# => больше разработчиков под винду => больше приложений под метровую винду => меньше возмущений про малое количество приложений => больше покупателей => больше бабла => метро не провалилось.

        Майкрософту очень нужно отхапать кусок этого рынка. Любой ценой.

        «Поддержка» андроида шарпом на андроиде не очень-то скажется, потому что там и так приложений дофига, никто не заметит разницы.
    • +1
      На самом деле Xamarin-овское дополнение к студии вполне себе неплохо работает в этом качестве. Стоит, правда, как авианосец, но это детали уже.
      • 0
        Неплохо, что вообще работает, если быть точным.
        Но как-то задачи свои выполняет, это да.
  • +2
    >> После ухода Стива Балмера компания Microsoft продолжает радовать приятными новостями: спустя несколько лет наконец-то вышел MS Office для iPad

    Как-то наивно думать, что это зависимые события…
    • 0
      Может быть, что события и связаны. Смена руководства частенько приносит большие перемены.
      • +1
        Я бы согласился на связь «выход давно ожидаемого продукта даст очки новому CEO»
        Но ведь ясно, что офис для IPad стали разрабатывать еше при Балмере.
        • 0
          Про Office for iPad — согласен, его явно невчера решили разрабатывать :)

          Я скорее про решение открыть исходники.
          • +1
            Исходники уже несколько лет как открывают. Большинство из описанных в статье были открыты за долго до Build 2014, тоже ещё при Баллмере
      • 0
        Принимает решения совет директоров. CEO скорее выполняет их поручения.
  • +2
    А не получится ли так, что MS просто возьмет и купит Xamarin?
    • +1
      Рихтер в недавнем интервью упоминал о подобных слухах.
    • +2
      Пока Xamarin просто берет и скупает разрабов делающих хоть что-то значимое для Xamarin в open source. Бывет откроешь проект на github, он бурно развивался и вдруг застыл, а через несколько месяцев автор светится в сети как сотрудник Xamarin.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.