Главная
Блог разработчиков phpBB
 
+ 17 предустановленных модов
+ SEO-оптимизация форума
+ авторизация через соц. сети
+ защита от спама

C# для системного программирования

Anna | 17.06.2014 | нет комментариев
От переводчика. Незадолго на Прогре была опубликована статья «Грядущее C#», описывающая новые фичи, которые, скорее каждого, попадут в C# 6.0. Мне, как программисту .NET, эта статья дюже понравилась, и я решил поискать дополнительную информацию о том, куда идёт C#/.NET. И вот, как словно прислушиваясь к моим новогодним пожеланиям, 27 декабря Джо Даффи (Joe Duffy) опубликовал в своём блоге статью «C# for Systems Programming», рассказывающую об исследовательском плане под его начальством, направленном на создание нового языка и платформы на основе C#/.NET. Славно впечатлённый статьей, я решил опубликовать её несколько свободный перевод на Прогре.

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


На 1-й вопрос «Для чего необходим новейший язык?» я с готовностью признаю, что в мире и без того существует куча языков программирования. Но вот как я это поясняю. Если обрисовать спектр всех знаменитых языков на координатной площади, где ось абсцисс обозначает «Продуктивность», а ось ординат — «Безопасность и производительность», то вот что мы получим.

Пожалуйста, отнеситесь к этому рисунку с долей понимания и снисхождения. Я понимаю, что безопасность (Safety) не равна производительности (Productivity), что безопасность дозволено понимать и толковать во многих различных смыслах и т.д. Тем не менее, безопасность и производительность Зачастую идут рука об руку — припомните, сколько времени и усилий разработчики, как правило, тратят на ошибки безопасности, комплекты инструментов, так либо напротив помогающие улучшать код, и т.д.

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

В верхнем левом квадранте мы имеем языки со сборкой мусора, которые главенствуют в плане производительности разработчика, их использующих. За последние несколько лет эффективность JavaScript значительно выросла, в чём спасибо компании Google. Незадолго сходственное случилось и с PHP. Абсолютно ясно, что возникла целая группа динамически типизированных языков, которые энергично соперничают с C# и Java. Таким образом, теперь выбор сместился с вопроса продуктивности на вопрос предпочтения динамической либо статической системы типов.

А это значит, что языки типа C# всё больше и больше «страдают» от Закона исключающего среднего (Law of the Excluded Middle). Нахождение посередине добросердечном не закончится.

В нижнем правом квадранте расположились языки, которые выжимают из себя последние капли продуктивности. Будем Добросовестными: множество программистов не разместит C# и Java в данный квадрант, и я с ними согласен. Я видел уйма людей, которые с кислым послевкусием во рту удирали от языков со сборкой мусора обратно к C . (Буду Добросовестен и скажу, что сама сборка мусора повинна лишь отчасти; сходственное «бегство» в существенной степени обусловлено дрянными образцами проектирования, фреймворками и упущенными вероятностями сделать язык ещё отменнее.) Java находится ближе к «квадранту продуктивности», чем C#, в первую очередь вследствие великолепной работе HotSpot-сходственных виртуальных машин, которые применяют подачу кода (code pitching) и выделение стека (stack allocation). И, тем не менее, множество хардкорных системных программистов выбирает C взамен C# и Java экстраординарно из-за превосходства первого в продуктивности. И правда C 11 немножко приблизился к языкам подобно C# и Java в плане производительности и безопасности, он всё ещё показывает очевидное «нежелание» добавить гарантированную безопасность типов к C . Да, теперь у вас теснее гораздо поменьше точек пересечения с небезопасностью, но я твёрдо верю, что, как и с беременностью, невозможно быть «наполовину неопасным». Наличие в языке небезопасности обозначает, что вы обязаны неизменно рассчитывать на наихудший из допустимых сценариев и применять инструменты для поправления безопасности теснее по факту её нарушения, взамен того, Дабы положиться на безопасность системы типов.

Нашей первоочерёдной целью было удостовериться в реальности дихотомии, безусловного возражения и несовместимости между этими двумя квадрантами. Другими словами, мы хотели узнать, может ли в тезисе что-то существовать в правом верхнем квадранте. И по итогам нескольких лет работы, включая использование данных принципов к большой кодовой базе, я считаю, что результат будет «Да!».

Итог должен быть выражен в комплекте дополнений (extensions) к языку C#, затрагивающих сам язык в минимальной степени, а не в абсолютно новом языке.

Дальнейший вопрос: «Для чего основываться на C#?» В том языке, тот, что мы хотим разработать, безопасность типов является «железобетонным» аспектом, а C# предоставляет чертовски классное полотно в жанре «теперешний типобезопасный C », на котором мы начнём рисовать свою картину. C# ближе к тому, чего мы хотим, по сопоставлению с, скажем, Java, так как содержит такие современные вещи, как делегаты и лямбда-выражения. Сейчас есть и другие кандидаты, такие как D, Rust и Go. Но когда мы начинали свою работу, эти языки ещё не возникли либо не стали довольно полновесными для применения. К тому же, моя команда работает в Microsoft, где куча гениальных C#-разработчиков доступна на расстоянии вытянутой руки. Я готов сотрудничать с специалистами в других рассматриваемых языках, перечисленных выше, и даже поделился идеями с несколькими ключевыми людьми из сообществ этих языков. Отличной новостью является то, что все рассматриваемые нами языки имеют всеобщие корни, заложенные в C, C , Хаскелле и т.д.

Наконец, вы можете поинтересоваться, «Отчего бы не базироваться на C ?». Должен признать, что в процессе работы я Зачастую задавался вопросом, а не обязаны ли мы начать с C и вырезать из него «неопасное подмножество» функциональности. Мы Зачастую обнаруживали, что занимаемся «тасованием C# и C в блендере, пытаясь увидеть, что же получится», и я признаю, что порой C# тянул нас назад. В частности, когда вы начинаете думать о RAII, детерминистических деструкторах, ссылках и т.д. Тонкости между обобщениями (generics) и образцами (templates) заслуживают отдельного поста. Я подлинно жду рано либо поздно разглядеть переход на C по двум причинам: (1) такой шаг приведёт к увеличению числа пользователей языка (в мире живёт гораздо огромнее программистов, знающих C , нежели знающих C#) и (2) я мечтаю о стандартизации, Дабы open source-сообществу также не требовался выбор между «безопасность и производительность» и «эффективность». Но в рамках первоначальных целей плана я рад применять C#, и не по последней причине вследствие богатой функциональности .NET Framework.

На протяжении конечный нескольких лет я теснее несколько раз давал намёки на наш план (скажем, тут итут). В ближайшие месяцы я начну делиться ещё больше подробной информацией. Моей финальной целью является передача итогов нашего плана в open source, но до этого нам нужно привести в порядок некоторые аспекты языка, а также, что больше значимо, перейти на применение кодовой базы плана Roslyn. Верю, что эта цель будет достигнута в 2014 году.

На высоком ярусе я систематизирую функционал создаваемого языка по шести основным категориям.

  1. Осознавание жизненного цикла (Lifetime understanding). C содержит RAII, детерминистические деструкторы и результативную аллокацию объектов. C# и Java стимулируют разработчиков во всём полагаться на управляемую сборщиком мусора кучу, и поддерживают только нечёткую/слабую (loose) поддержку детерминистического разрушения объектов через IDisposable. Часть моей команды непрерывно конвертирует программы, написанные на C#, на наш новейший язык, и для нас не редкость, что 30-50% времени выполнения программы «отъедает» сборщик мусора. Для серверных приложений данный факт «убивает» пропускную способность, для заказчиков — приводит к деградации ощущений применения, так как снижает отзывчивость интерфейса во время его применения. Дозволено сказать, что мы «украли» часть вероятностей C , а именно rvalue-ссылки (rvalue references), семантику переноса (move semantics), деструкторы, ссылки и заимствования (references / borrowing). Наравне с этим, мы сберегли безопасность языка, а также объединили идеи, взятые от C , с идеями функционального программирования. Всё это разрешает нам использовать враждебную аллокацию объектов на стеке, детерминированно уничтожать их и многое другое.
  2. Осознавание побочных результатов (Side-effects understanding). Данный пункт является эволюцией тех идей, которые мы опубликовали на OOPSLA 2012. Он подразумевает вступление в язык части функционала оператора const из C (вновь-таки, неопасным образом), а также неизменяемость (immutability) и изолированность первого класса.
  3. Асинхронное программирование в масштабе (Async programming at scale). Сообщество непрерывно вращается вокруг этого вопроса, определяясь, применять ли передачу продолжений (continuation-passing) либо облегчённые блокирующие сопрограммы (lightweight blocking coroutines). Данный вопрос затрагивает не только C#, но и в существенной степени все существующие языки. Ключевой инновацией тут является компонуемая система типов, которая «агностична» (равнодушна) по отношению к модели выполнения, и может результативно взаимодействовать с всякий из них. Было бы самонадеянно утверждать, что мы имеем только один подход к решению данной задачи, но, опробовав уйма других подходов, могу сказать, что мне нравится тот, что мы предпочли.
  4. Типобезопасное системное программирование (Type-safe systems programming). Зачастую дозволено услышать заявления, что система типов и потеря продуктивности идут рука об руку. Бесспорно, что проверка границ требует времени, а также то, что мы выбираем, Дабы проверка переполнений была включена по умолчанию. Но чудесно, как много дозволено достичь при помощи отменного оптимизирующего компилятора в противовес JIT-компиляции. Мы также дозволим вам делать огромнее пророческой без аллокаций, типа основанные на лямбдах API, вызов которых не сопровождается никакими аллокациями (теперь, как правило, требуются две аллокации: одна для делегата и вторая для отображения). Ещё одна «фича» — вероятность «вырезать» подмассивы и подстроки без аллокаций.
  5. Современная модель ошибок (Modern error model). Данный пункт — ещё один, с которым сообщество несогласно. Мы остановились на том, что я рассматриваю как наилучший из допустимых вариантов: всевозможное и полное задействование контрактов (предусловия, постусловия, инварианты, заявления и т.д.), стремительная обработка сбоев как базовая установка среды, исключения только для редких динамических сбоев (парсинг, ввод-итог, другое), и типизированные исключения только при безусловной необходимости в расширенной информации об исключении. Всё это интегрировано в систему типов как объекты первого класса, так что вы получите всё нужное в целостности и сохранности.
  6. Современные фреймворки (Modern frameworks). Сюда входит целая куча пророческой, включая асинхронные LINQ-выражения и усовершенствованная помощь перечислителей (enumerator), которые будут соперничать с итераторами из C в плане продуктивности и не будут требовать двойную диспетчеризацию интерфейсов (double-interface dispatch) для извлечения элементов. Если быть Добросовестным, то в этой области мы имеем крупнейший список пророческой со рангом «спроектировано, не ещё не реализовано». Сюда также попадают: тип void как объект первого класса, non-null-типы, типажи (traits), 1st class effect typing и другое. Я жду, что мы поспеем к середине 2014-го реализовать небольшую часть из этого списка.

Я предполагаю, что наш план вас заинтересует, и я хочу услышать, что вы думаете по этому поводу, каковы ваши суждения как касательно плана в всеобщем, так и касательно его составляющих, а также хочу узнать, какие его аспекты вас заинтересовали огромнее каждого. Я весьма рад делиться с вами информацией, впрочем реалии таковы, что в меня нет кучи времени для ведения блога, да и работы в нас выше крыши (кстати, we’re hiring). Но я непременно учту ваше суждение касательно того, о чём мне рассказывать и в каком порядке. В конце концов, я с нетерпением ожидаю того дня, когда сумею поделиться с вами реальным кодом, а не текстами. А пока что хочу вам Happy Hacking!

Обновление поста

То, что задумывалось как девственная запись в блоге с целью облегчить открытый диалог с сообществом, переросло в кое-что определённо большее.

Как, верю, ясно из моей автобиографии, язык, тот, что описан в этом посте, является исследовательскимпланом, ни огромнее, ни поменьше. Считайте меня парнем из Microsoft Research, тот, что опубликовал свой отчет в блоге, а не на PLDI. Я легко не настоль гениален, Дабы выступать на PLDI.

Я дюже верю, что в ближайшие месяцы я буду писать что-то новое о плане, но только в духе открытого сотрудничества с сообществом, а не ради копания в «глубоком смысле» либо в «высоких материях». Не необходимо столько домыслов!

Мне нравится ваш энтузиазм, следственно, пожалуйста, придерживайтесь технической стороны диалога. Если все остальные размышлизмы и разглагольствования исчезнут, я стану радостным человеком!

Послесловие от переводчика

Невзирая на касательно маленький размер, данная статья была достаточно трудной для перевода. Многие термины легко не имеют адекватного перевода, многие технические вещи не до конца внятны. Я попытался снабдить гиперссылками все термины, пояснение которых сумел обнаружить (либо предполагаю, что верно обнаружил). Тем не менее, я уверен, что в статье содержится много неточностей/ошибок/искажений перевода, как «классического», так и технического нрава. Следственно буду весьма признателен любым вашим замечаниям/комментариям/предложениям, выраженным где вам комфортно и как вам комфортно.

Если вы заинтересовались загадочным и монументальным планом Даффи, советую почитать комментарии к подлинной статье. Даффи Зачастую отвечает на вопросы читателей блога, и из его результатов дозволено узнать много увлекательного, не освещённого в самой статье.

Также рекомендую ознакомиться с переводом интервью с Джо Даффи «10 вопросов о параллельном программировании и потоках в .NET», опубликованным на RSDN. Правда интервью и датируется 2007-м годом, предполагаю, что результаты Даффи нисколечко не устарели.

Также существует ещё одно, не менее увлекательное интервью с Даффи «Joe Duffy on Uniqueness and Reference Immutability for Safe Parallelism», датируемое апрелем 2013 года и опубликованное источником InfoQ. Помимо вопросов параллелизма, Даффи также коротко упоминает план, описанный в данном посте. Я могу исполнить его перевод, впрочем, исходя из размера и трудности этого интервью, мне не хочется делать перевод, не зная, заинтересовано ли в этом сообщество Програ. Мне не хочется повторения обстановки с моими последними переводами статей Джона Скита, которые были увлекательны лишь нескольким людям. Следственно ожидаю вашего суждения.

Источник: programmingmaster.ru
Оставить комментарий
Форум phpBB, русская поддержка форума phpBB
Рейтинг@Mail.ru 2008 - 2017 © BB3x.ru - русская поддержка форума phpBB