Выпустив версию Typescript 1.3, мы сфокусировались на усовершенствовании системы типов и добавлении функционала ECMAScript 6 в TypeScript. Давайте рассмотрим некоторые новые возможности, которыми вы сможете пользоваться в новой версии.

Все описанные в статье вещи уже реализованы в мастер-ветке нашего репозитория на Github — вы можете выкачать ее и попробовать их уже сейчас.



Новые возможности позволяют более аккуратно и легко работать с переменными, которые имеют различный тип во время исполнения. Они сокращают количество мест, где нужно явно указывать тип, проверять его или использовать тип any. Авторы типизирующих файлов (.d.ts) могут также использовать эти возможности для описания внешних библиотек. Те, кто следят за развитием компилятора, могли заметить, что мы сами тоже ими пользуемся.

Как писал Роб Напьер, мы не знаем Swift. И ничего страшного — на самом деле, это даже здорово: у нас есть возможность самим решать, каким этот молодой мир станет дальше. Мы можем (и должны) оглядываться на аналогичные языки в поисках идей, хотя множество практик хорошего тона — скорее предпочтения сообщества, нежели объективная истина. Судя по длинным и напряженным беседам в форумах разработчиков о том, когда и как лучше использовать опциональные типы, я все больше предпочитаю с ними вообще не связываться.

Опциональные типы — такой же инструмент, как и все остальные. По закрепившейся на Objective C привычке, мы используем nil где ни попадя — в качестве аргумента, значения по умолчанию, логического значения и так далее. С помощью приятного синтаксиса для опциональных типов, который дает Swift, можно превратить в опциональный тип практически что угодно, и работать с ним почти так же. Поскольку опциональные типы распаковываются неявно, все еще проще: можно использовать их и даже не догадываться об этом. Но возникает вопрос — а разумно ли это?

Я бы сказал, что нет. Даже кажущаяся легкость использования обманчива — Swift был разработан как язык без поддержки nil, а концепция «отсутствия значения» добавлена в виде перечисления. nil не является объектом первого рода. Более того, работа с несколькими значениями опционального типа в одном методе зачастую приводит к такому коду, на который без слез не взглянешь. Когда что-то было настолько фундаментальным в Objective C, а теперь изгоняется из списка объектов первого рода, интересно разобраться в причинах.

Если издали видно общую картину, то вблизи можно понять суть. Концепции, которые казались мне далекими и, прямо скажем, странными во время экспериментов с Haskell и Scala, при программировании на Swift становятся ослепительно очевидными решениями для широкого спектра проблем.

Взять вот обработку ошибок. Конкретный пример – деление двух чисел, которое должно вызвать исключение если делитель равен нулю. В Objective C я бы решил проблему так:

NSError *err = nil;
CGFloat result = [NMArithmetic divide:2.5 by:3.0 error:&err];
if (err) {
    NSLog(@"%@", err)
} else {
    [NMArithmetic doSomethingWithResult:result]
}

Со временем это стало казаться самым привычным способом написания кода. Я не замечаю, какие загогулины приходится писать и как косвенно они связаны с тем, что я на самом деле хочу от программы:

Верни мне значение. Если не получится – то дай знать, чтобы ошибку можно было обработать.

Я передаю параметры, разыменовываю указатели, возвращаю значение в любом случае и в некоторых случаях потом игнорирую. Это неорганизованный код по следующим причинам:

• Я говорю на машинном языке – указатели, разыменование.
• Я должен сам предоставить методу способ, которым он уведомит меня об ошибке.
• Метод возвращает некий результат даже в случае ошибки.

Каждый из этих пунктов – источник возможных багов, и все эти проблемы Swift решает по-своему. Первый пункт, например, в Swift вообще не существует, поскольку он прячет под капотом всю работу с указателями. Остальные два пункта решаются с помощью перечислений.

В рамках моей «работы» над стандартизацией C# 5 в технической группе ECMA-334 TC49-TG2 мне посчастливилось увидеть несколько интересных способов, которыми Владимир Решетников проверял C# на прочность. В данной статье описана одна из проблем, которые он поднял. Разумеется, она, скорее всего, никак не затронет 99.999% C#-разработчиков… но разобраться все равно любопытно.

Спецификации, используемые в статье:

• Стандарт Unicode 7.0.0 – в особенности, глава 3
• C# 5 (Документ Word)
• ECMA-335 (Спецификация CLI)

Что такое строка?

Как бы вы объявили тип string (или System.String)? Я могу предположить несколько вариантов ответа на данный вопрос, от расплывчатых до довольно конкретных:

• «Какой-нибудь текст в кавычках»
• Последовательность символов
• Последовательность символов Юникода
• Последовательность 16-битных символов
• Последовательность слов UTF-16

Только последнее утверждение полностью верно. Спецификация C# 5 (раздел 1.3) гласит:

Обработка строк и символов в C# использует UTF-16. Тип char представляет слово UTF-16, а тип string – последовательность слов UTF-16.

Пока всё в порядке. Но это C#. А как насчет IL? Что используется там, и имеет ли это значение? Оказывается, что имеет… Строки должны быть объявлены в IL как константы, и природа этого способа представления важна – не только кодировка, но и интерпретация этих закодированных данных. В частности, последовательность слов UTF-16 не всегда может быть представлена в виде последовательности слов UTF-8.

С момента анонса языка Swift скорость была ключевым элементом маркетинга. Еще бы – она упоминается в самом названии языка (swift, англ. — «быстрый»). Было заявлено, что он быстрее динамических языков наподобие Python и Javascript, потенциально быстрее Objective C, а в некоторых случаях даже быстрее, чем C! Но как именно они это сделали?

Спекуляции

Несмотря на то, что сам язык предоставляет огромные возможности для оптимизации, у нынешней версии компилятора с этим не все в порядке, и получить хоть какие-то успехи в тестах производительности стоило мне немало сил. В основном это происходит из-за того, что компилятор генерирует массу излишних действий retain-release. Думаю, что это быстро поправят в следующих версиях, но пока мне придется говорить о том, благодаря чему Swift может быть потенциально быстрее Objective C в будущем.

Более быстрая диспетчеризация методов

Как известно, каждый раз, когда мы вызываем метод в Objective C, компилятор транслирует его в вызов функции objc_msgSend, которая занимается поиском и вызовом нужного метода в рантайме. Она получает селектор метода и объект, в таблицах методов которого производится поиск непосредственного куска кода, который будет обрабатывать этот вызов. Функция работает очень быстро, но зачастую делает куда больше работы, чем действительно нужно.

Передача сообщений удобна тем, что компилятор не делает никаких предположений относительно того, какой объект попадется ему в рантайме. Это может быть экземпляр типа выражения, дочерний класс, или вообще абсолютно другой класс. Компилятор можно обмануть, и все будет работать как положено.

С другой стороны, в 99.999% случаев вы не будете врать компилятору. Когда объект объявлен как NSView *, это либо непосредственно NSView, либо дочерний класс. Динамическая диспетчеризация необходима, а вот настоящая пересылка сообщений практически не нужна, но природа Objective C заставляет всегда использовать самый «дорогой» вид вызовов.

Ущербно-ориентированное программирование — это набор подходов, поощряющий повторное использование кода и гарантирующий долгосрочное использование производимого программистами кода в боевых системах. Количество строк кода является повсеместно применяемым показателем значимости приложения, а количество строк, которые программист пишет за рабочий день — полезная метрика, применяемая при планировании проектов и распределении ресурсов. Ущербно-ориентированное программирование — это один из наиболее эффективных способов получить наиболее объемный исходник в кратчайшие сроки.

Ущербный — имеющий изъян, неполноценный. Вредный, недостаточный.

Наследование

Наследование — это способ получить возможности старого кода в новом коде. Программист наследуется от существующей функции или блока кода, копируя этот кусок к себе и внося правки. Унаследованный код, как правило, конкретизируется под новые нужды с помощью возможностей, которые не поддерживал старый код. В таком смысле, старый код остается нетронутым, но новый наследуется от него.

В прошлом топике я рассказывал о том, как мы с другом решили ради развлечения написать свой встраиваемый язык программирования для платформы .NET. У первой версии был серьезный недостаток — парсер был реализован на F# с помощью сторонней библиотеки. Из-за этого требовалась куча зависимостей, парсер работал медленно, а поддержка его была крайне муторным занятием.

Очевидно, что парсер нужно было переписать на C#, но при мысли о написании парсера с нуля вдруг находилась дюжина других срочных дел. Таким образом таск перекидывался и откладывался практически полгода и казался непосильным, а в итоге был сделан за 4 дня. Под катом я расскажу об удобном способе, позволившим реализовать парсер достаточно сложной грамматики без использования сторонних библиотек и не тронуться умом, а также о том, как это позволило улучшить язык LENS.

Но обо всем по порядку.

В феврале этого года бостонская компания WobbleWorks представила на Kickstarter проект 3D-принтера в виде ручки, который позволяет рисовать пластиком и создавать объемные фигуры под названием 3Doodler. Кампания завершилась оглушительным успехом — вместо ожидаемых 30 тысяч долларов было собрано больше 2 миллионов. О проекте несколько раз писали на хабре — собственно, из этой статьи я и узнал про него и успел заказать одним из первых.

Сегодня девайс наконец-то доставили. Под катом — несколько фотографий и субъективные ощущения, полученные за полчаса использования.

Предисловие

Случается, что навязчивая идея так прочно заседает в голове, что ты возвращаешься к ней снова и снова на протяжении многих лет. Пытаешься подойти к проблеме с другой стороны, воспользоваться новыми знаниями, или же просто начать все еще раз с чистого листа — и так до тех пор, пока вопрос не будет исчерпан раз и навсегда. Для меня такой идеей-фикс стали языки программирования. Сам факт того, что одна программа позволяет создавать другие программы, в моих глазах наделял ее непостижимой фрактальной красотой. Написание такой программы самому стало лишь вопросом времени.

Серьезно, прекратите. Это пустая трата времени и сил. Поищите регулярку для проверки Email в Google, взгляните на нее — и захочется отойти подышать свежим воздухом. Вспоминается одна очень известная цитата:

Некоторые люди, сталкиваясь с проблемой, думают: «О, я воспользуюсь регулярными выражениями».
Теперь у них две проблемы.

Джэйми Завински, regex.info

В этой статье я хочу рассказать о своем опыте написания игры под платформу Windows Phone. Несмотря на кажущуюся простоту, путь от идеи до принятия игры в Windows Phone Store занял практически год и был полон неожиданных подводных камней — как с технической, так и с организационной сторон. Статья рассчитана на начинающих разработчиков, которые имеют представление о .NET / C#, но не пробовали делать полноценных игр.

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

Большинство начинают с собственных интерпретаторов, которые представляют собой в общем виде огромный свитч команд в цикле. Интересно, вольготно, но муторно и весьма медленно. Хочется чего-то более шустрого, чтобы JIT'ить умело и, желательно, само следило за памятью.

Отличным решением данной проблемы является выбор .NET в качестве целевой платформы. Оставим лексический разбор на следующий раз, а сегодня давайте попробуем сделать простейшую программу, которая создает работающий исполняемый экзешник: