Сущность метапрограммного интервью: Мета-программное интервью. Основные вопросы Мета-программного интервью.

Если вы хотите еще больше углубиться в метамодель, книга «Magic DeMystified» — отличный источник. И, естественно, вы можете получить всестороннее обучение с помощью нашего курса «Взломай свой мозг с помощью НЛП».

Интервью с Доном Саймом

Как упоминалось в предыдущем посте, я имел большое удовольствие провести день в Microsoft Research в Кембридже на прошлой неделе. Мой хозяин, Дон Сайм, очень заботился обо мне и был очень щедр на свое время и знания.

Немного предыстории того, почему я решил попросить о встрече с Доном: Дон — человек, стоящий за F#, новым языком программирования, который за последний год или около того превратился из исследовательского проекта в полноценный язык .NET. с полной поддержкой в ​​средствах разработки Microsoft. Ожидайте увидеть возможность создавать проекты F# (так же, как сегодня вы можете это делать с VB и C#) в Visual Studio в ближайших выпусках. Я не видел официального объявления о том, что F# будет частью выпуска Visual Studio 2010, но я должен верить, что это план. (Для ясности: это не вопрос, который я задавал Дону, это чистая спекуляция с моей стороны.)

Раньше я называл Дона и «отцом F#», и «мистером F#», но, учитывая его скромность, он предпочитает титул «дизайнер» или «исполнитель» F#. Ясно одно: Дон был значительной движущей силой F# и в значительной степени руководил как его разработкой, так и его переходом на полную поддержку со стороны Microsoft.

За последний год или около того я несколько раз писал о F#. В этом раннем посте упоминаются некоторые причины, по которым функциональное программирование (и F#) стало интересным для индустрии программного обеспечения, и почему я считаю, что это особенно важно для области дизайна.

Рискуя повториться, я еще раз кратко пройдусь по некоторым основам…

F# — это прежде всего функциональный язык программирования, что означает, что его синтаксис сильно отличается от языков, с которыми в настоящее время работает большинство из нас. самый знакомый. В вашем коде вы определяете ряд значений с помощью вездесущего оператора «let», а значения, которые принимают аргументы, являются функциями. Каждое определяемое вами значение основано на входных данных или значениях, которые вы назначили ранее. И последнее значение, указанное в функции, является ее выходом. Это очень упрощенная точка зрения: в то время как код C# или VB, который следует этому шаблону, в значительной степени можно написать, возможности функциональных языков означают, что определенные типы операций намного проще выполнять: как Дон упоминает в интервью, F# очень хорош для например, работа с большими наборами данных.

Вы также можете использовать F# для написания чистого кода . Чистый код, с функциональной точки зрения, не содержит побочных эффектов (которые включают, например, запись в файл или вывод на экран), и не изменяет изменяемое состояние (т. е. он не содержит переменных: вы присваиваете значения символам, но эти значения не меняются, они неизменны ). Чистый код имеет определенные преимущества в мире, в котором мы живем сегодня: с крахом закона Мура (или, говоря более широко, с его переходом к производителям чипов, поставляющим несколько ядер, а не пытаясь продолжать увеличивать тактовую частоту) и с переходом По отношению к облачным вычислениям чистый код дает много преимуществ, поскольку его гораздо проще распараллелить. Еще одной полезной особенностью чистого кода является его потенциал для запоминания: чистая функция будет при одних и тех же входных данных всегда генерировать один и тот же результат, и, поскольку у нее нет побочных эффектов или состояния, мы не получаем никакой выгоды от вызова функцию несколько раз. Что в основном означает, что мы можем хранить результаты и использовать их напрямую, а не повторять избыточные (и, возможно, дорогостоящие) вызовы функций.

Чисто функциональное программирование по-прежнему используется в основном в академических кругах: реальные реализации, как правило, время от времени должны выполнять побочные эффекты (классическая шутка заключается в том, что вы можете сказать, что чисто функциональные программы работают только потому, что коробка нагревается:- ), поэтому Дон отстаивал — на мой взгляд, очень мудро — разработку прагматичного функционального языка , который, хотя и способен создавать чистый код, не ограничивает вас в сохранении состояния и создании побочных эффектов. В первую очередь F# — помимо OCaml, прагматичного языка, на котором он основан, — это его способность работать поверх Common Language Runtime (CLR) и взаимодействовать как с компонентами .NET, так и с кодом, написанным на других .NET. языки.

Так почему я считаю, что это важно для нашей работы? Функциональное программирование действительно хорошо подходит для научного программирования в целом, и потребность в нем возрастает по мере того, как инженерный анализ и моделирование все теснее интегрируются в процесс проектирования. И у нас также есть все более полноценный набор инструментов на основе .NET, предоставляемый нашими различными продуктами, что означает, что код F # может быть интегрирован с — например. используется для анализа и модификации моделей почти во всех продуктах Autodesk для проектирования на базе Windows, будь то AutoCAD, Revit, Inventor или что-то еще.

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

В качестве недавнего дополнительного материала по этой теме я настоятельно рекомендую эти два видео, снятых на прошлой неделе на конференции JAOO в Дании. Первый — это основной доклад Андерса Хейлсберга, а второй — интервью с Андерсом Хейлсбергом и Гаем Стилом на канале MSDN 9. .

А теперь интервью с Доном.

[Типографские соглашения: мои собственные слова выделены жирным шрифтом , слова Дона выделены обычным текстом. Я приложил редакционные комментарии [жирным курсивом в квадратных скобках] .]

Откуда взялась идея F#?

Основная предпосылка F# — убедиться, что типизированное функциональное программирование имеет место на платформе .NET. Это парадигма с огромным количеством возможностей, о чем уже давно знают пользователи таких языков, как Miranda, OCaml и Haskell. На меня также сильно повлияло то, что Intel хорошо использует типизированный функциональный язык (называемый FL) внутри компании. Они используют это при проверке своего оборудования и некоторых конвейерах проектирования.

Зачем использовать OCaml в качестве основы?

Типизированное функциональное программирование — это простые, композиционные высокоуровневые манипуляции с данными с использованием основных ортогональных строительных блоков. OCaml — отличный пример системы функционального программирования с типизированными данными, оказавший большое влияние на направление работы в этой области. Подход OCaml к разработке языка имеет правильный характер для создания практичного функционального языка, а базовый язык хорошо известен и хорошо протестирован и часто используется в качестве основы для экспериментов. Сам OCaml стал результатом такого рода экспериментов, основанных на системе под названием Caml-Light.

С 1999 по 2003 год мы закладывали основы F#. В 1999 году мы начали проект 7, в рамках которого мы работали с исследовательскими группами по всему миру, чтобы ориентироваться на различные языки в .NET Common Language Runtime (CLR). Проект 7 привел непосредственно к включению .NET Generics в C# 2.0. Следующим логическим шагом была непосредственная реализация языка в стиле OCaml, и разработчики OCaml были очень воодушевлены, когда мы говорили с ними о переносе этого класса языков в пространство .NET. Это привело к ранним версиям F#.

Могут (и делают) ли люди выполнять кросс-компиляцию между F# и OCaml? Это возможно?

На практике кросс-компиляция не так важна: часто мешают различия в библиотеках между .NET и OCaml. Это больше касается перехода и повторного использования методов, а иногда и основных механизмов, таких как пример обработки PDF.

Тем не менее, это возможно, и мы делаем это в нашей группе для некоторых компонентов. Этот метод также используется в коммерческих целях — есть компания, которая создает инструменты для работы с PDF на основе OCaml — отличное применение функционального программирования — они выполняют кросс-компиляцию между F# и OCaml.

Каковы преимущества «функционального мышления» или «мышления FP» для людей, кодирующих на других языках (C++, C#, VB.NET)?

Вы должны посмотреть на проблемный домен, чтобы понять, применима ли FP. Мне нравится характеризовать области, в которых функциональное программирование наиболее применимо, либо как с интенсивным использованием данных , либо как с интенсивным управлением . Программирование AutoCAD является примером работы с интенсивным использованием данных. Символьное программирование также требует больших объемов данных: например. манипулировать PDF как форматом — всасывать его, анализировать, преобразовывать. Параллельное и асинхронное программирование требуют интенсивного управления и хорошо подходят для функционального программирования.

Есть места, где FP не даст вам преимущества. Программировать ядро? Тогда не используйте функциональное программирование. Программирование графического интерфейса или какая-то другая работа, очень ориентированная на презентацию? Тогда может быть неважно, какой язык вы используете: важнее всего инструменты дизайнера.

Первое, что замечают программисты на C# или C++, когда переходят к F#, — это то, как функциональное программирование меняет «программирование в малом»: их удивляет отказ от шаблонного кода и снижение сложности реализации объектов и функций. Следующее, что замечают люди, — это ориентация на неизменность. Я видел, как люди проводили целые доклады о том, как неизменность меняет ваш взгляд на программирование.

Верно и то, что концепции функциональных языков определенно оказывают влияние и на другие языки .NET.

Мне нравится говорить, что почти все, что мы добавили к платформе .NET в отношении языков начиная с версии 1.0, было функциональным программированием. Если мы посмотрим на дополнения к C#: дженерики, добавленные группой функционального программирования, основанные на принципах функционального программирования. Анонимные функции, синтаксис запросов в C# 3.0, метапрограммирование на основе дерева выражений — на все это сильно повлияло функциональное программирование. Даже итераторы C# ближе к функциональному программированию, чем к объектно-ориентированному программированию, что ясно проявляется в версии F# этой языковой функции.

.NET сама по себе также хорошо подходит для функционального программирования. Вы заметите, что в .NET нет действительно глубоких иерархий наследования; он больше ориентирован на делегатов и интерфейсы. Также многие типы являются неизменяемыми — например, System.DateTime. В целом я вижу в этом часть долгой тенденции к интеграции функциональных идей в объектно-ориентированное программирование.

Некоторые функции .NET 2.0 в значительной степени позволили вам реализовать F#, одним из которых являются дженерики. Предвидели ли вы это, реализовали ли вы дженерики, чтобы реализовать F#?

Да, безусловно. Это определенно был фактор. Первая версия F# — самая, самая первая версия — была выпущена в 2003 году, когда мы еще работали над дженериками .NET.

Так что это определенно было частью плана.

Это был план, чтобы убедиться, что мы сможем поддерживать этот класс языков. Мы получили то, что нам нужно, в .NET 2.0.

Кем вы себя считаете пуристом или прагматиком?

Меня никогда раньше об этом не спрашивали. 🙂  Для пуриста я прагматик, для прагматика я, наверное, пурист. Я, наверное, как раз посередине. 🙂

Моя работа определенно заключалась в преодолении разрыва между академически ориентированным миром программирования и промышленностью. Если вы вернетесь в 2004 год, то в наших сводных докладах по дженерикам .NET у нас есть эти слайды, на которых с одной стороны были научные круги, а с другой — промышленность, а между ними огромная пропасть. До Проекта 7 между этими лагерями было очень мало общения, за некоторыми заметными исключениями, такими как работа с дженериками Java. Было очень весело иметь возможность помочь преодолеть этот разрыв.

И у вас есть коллеги из Microsoft Research, которые очень консервативны.

Да, мы делаем все: в самой Microsoft у нас есть все, от ультра-пуристов до ультра-прагматиков.

И у вас все ладится?

Мы все ладим. Это правда. 🙂

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

Есть ли компромиссы при разработке прагматичного (по сравнению с чистым) функционального языка?

Да, очень. Было очень интересно послушать на прошлой неделе пользователей на конференции «Коммерческие пользователи функционального программирования» от Говарда Мэнселла из Credit Suisse. Credit Suisse широко использует F# в своей глобальной группе моделирования и анализа. Они описали, почему они используют F#, и это было очень забавно, их описания того, что люди думают о F# [см.0018 этот документ для заметок, которые случайно сделал мой старый профессор во время конференции] .

Они обсудили пару возможных будущих расширений F#, которые они хотели бы увидеть, например, предварительные условия. Что меня заинтересовало, так это то, что они поняли, почему мы не делаем этого, по крайней мере, в F# V1: часть нашей цели с F# состоит в том, чтобы все было просто. Это означает, что команда разработчиков F# сделала несколько преднамеренных ограничений в дизайне F#, чтобы сделать его простым и доступным.

Это важно: когда вы встретите другого программиста F#, он, вероятно, будет использовать одни и те же языковые устройства аналогичным образом. Языки — это не только мощь и выразительность: они также предназначены для совместного использования и согласованности.

С F# у вас есть прагматичная среда разработки, в которой вы можете создавать побочные эффекты по своему усмотрению. Изменчивость не используется по умолчанию, и вы сообщаете, когда переменные изменяются, потому что у вас есть явный оператор для этого… Ожидаете ли вы ситуацию, когда чистота будет проверяться автоматически, а код будет профилирован и развернут соответствующим образом?

Имеется в виду какое-то автоматическое распараллеливание?

Да, на самом деле это то, что я записал в первоначальном вопросе. 🙂

Внедрение чистого подмножества в F# — это не то, что мы будем делать в первой версии F#, но это направление разработки, которое мы будем рассматривать в будущем. Нашим главным приоритетом является гладкое взаимодействие без барьеров. Если вы посмотрите на пример программирования AutoCAD, который вы мне показывали, где вы перешли от данных к объектам AutoCAD: взаимодействие имеет важное значение. Эти объекты AutoCAD не имеют никакой гарантии чистоты, но крайне важно не ставить барьеры на пути создания этих объектов и управления ими.

Что касается распараллеливания, основное внимание в F# V1 уделяется явному распараллеливанию, чтобы дать вам инструменты для управления сложностью явного распараллеливания. Шаблон управления Async.Parallel fork-join, который вы использовали, является одним из примеров этого [Дон имел в виду пример в этого поста ] . Точно так же вы можете зафиксировать суть архитектуры на основе агентов, отправив результаты обратно в поток визуализации. Например, архитектура моделирования.

Автоматическое распараллеливание в конце концов дойдет до промышленности. Мы увидим сочетание технологий компиляции и распараллеливающих движков: база данных, такая как SQL Server, извлекает все виды параллелизма в движке, как это делает веб-сервер, как и графический конвейер. Компиляторы исходного языка могут обрабатывать относительно простые случаи, такие как автоматическое распараллеливание циклов for, интенсивно использующих ЦП, над чистыми объектами. Мы собираемся укротить параллелизм с помощью сочетания методов: ни один из них не станет серебряной пулей для решения проблемы параллелизма.

Чем вас привлекла парадигма функционального программирования?

Моим первым программированием был AppleBasic, потом много разных языков, LOGO был один, так что я был рад увидеть ваш переводчик. Моя первая реальная работа по программированию была связана с PROLOG, где я увидел ценность языка символов высокого уровня в контексте систем поддержки принятия решений для государственных служб. Затем я использовал функциональный язык на постоянной основе в течение 5 лет для символьных манипуляций и задач проверки. Это была просто удивительно мощная парадигма. Итак, мое увлечение функциональным программированием во многом основывалось на опыте. Это отличная парадигма для информационного программирования.

Промышленность тоже начинает соглашаться.

Да, забавно, как все происходит. Для меня ключевым моментом является то, что такие платформы, как .NET, действительно позволяют вам взглянуть на мир на нескольких языках, что открывает возможности повторного использования и использования подходящего инструмента для работы. Сам F# реализован на смеси F#, C# и Visual Basic. Мы можем просто добавить эти компоненты, внести некоторые изменения, и они заработают.

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

Вы не увидите, чтобы F# захватил мир в смысле вытеснения C# и VB.NET.

Верно. Я сказал, что F# очень хорош для приложений с большими объемами данных или для таких задач, как параллельное программирование, где важную роль играет управляющая логика. Однако есть много вещей, которые не охватываются этим, например работа с большим количеством презентаций: написание графического интерфейса или разработка веб-сайта. Мы не считаем это основной ролью F# в мире. F# — хороший язык для работы с большим количеством презентаций, но это не его основная сила.

Презентация означает разработку пользовательского интерфейса.

Верно. Для многих приложений F# уровень представления использует инструменты конструктора C# и Visual Basic с основными вычислительными и алгоритмическими компонентами в F#. Это не означает, что компоненты F# просто обрабатывают числа и символы — например, они могут обрабатывать асинхронное программирование — но реальная работа дизайнера презентаций, мы очень рады видеть, что это делается с использованием инструментов, которые генерируют, скажем, C# или VB. .

Судя по всему, к F# проявляли интерес в секторе финансовых вычислений. В каких других областях вы ожидаете найти F# привлекательным?

На ум приходят инженерные области. Они связаны с основными приложениями, такими как AutoCAD и ГИС, и традиционно эти приложения не имеют хорошей расширяемости с помощью типизированного функционального языка программирования. Таким образом, F# — это первый случай, когда люди смогут использовать типизированное функциональное программирование в сочетании с этими инструментами.

В более широком смысле мы видим большой интерес со стороны технических областей вычислений, то есть науки, технологии, инженерии, математики. Еще одна область — статистическое машинное обучение. Посмотрите, что делает такая компания, как Google: умные веб-приложения и реклама, основанная на статистической обработке массивных наборов данных. Поначалу не так уж очевидно, зачем веб-рекламная компания нанимает так много программистов, но программирование лежит в основе их бизнеса, и это своего рода программирование, в котором F# превосходит другие. У нас было несколько тематических исследований внутри Microsoft, использующих F# для обработки данных веб-рекламы, и он был чрезвычайно успешным в этой роли. Поэтому, когда я говорю «статистическое машинное обучение», это звучит как какая-то нишевая сфера: но на самом деле на хороших алгоритмах теперь можно строить целые предприятия.

Часто ли F# используется на стороне сервера?

Хороший вопрос. Да, я бы сказал, что это довольно равномерное распределение между компонентами для сервера и компонентами для настольных приложений. Большинство развернутых приложений сейчас будут на стороне сервера. Вот где часто находятся данные.

Я полагаю, что после того, как F# превзойдет стадию CTP и станет более доступным, его внедрение на стороне клиента будет более широким.

Случаи типа AutoCAD интересны, так как данных больше на клиентской машине. На самом деле, я бы не обязательно классифицировал F# как клиент или сервер: на самом деле речь идет о том, где находятся данные. Например, внутри Microsoft используется F# для анализа списков управления доступом (ACL) на компьютерах во внутренней сети. ACL очищаются процессом системного администратора и анализируются программой F#. Программы F# выполняются в момент объединения данных.

Давайте посмотрим, как F# используется, скажем, в группе количественного финансирования. Код F# начинает свою жизнь как исследование проблемы на клиентском компьютере аналитика в сравнении с локальными наборами данных или текущими рыночными данными, поступающими из какой-либо программной службы. Если алгоритм доберется до производственной системы, он в конечном итоге будет работать как алгоритм оценки на ночных серверах.

Итак, когда вы спрашиваете «где находится код F#?» это весь путь от разработки концепции до фактического исполнения на серверах. Так что это на стороне сервера, но пользователи не думают об этом таким образом: они будут думать о себе как о парнях, занимающихся количественными финансами, которые пишут алгоритм.

Типичное использование F# очень ориентировано на предметную область. Пользователи F# могут быть не так хорошо знакомы с концепциями информатики. Они просто сосредоточатся на своей области, например, на инженерном анализе в AutoCAD или на вероятностном моделировании. Где он работает, не является ключевым фактором: люди, выполняющие развертывание, обычно заботятся о таких вещах.

Что вы чувствовали, когда было принято решение о выпуске F#?

Очень рад. Очень взволнован. Я горжусь коллективным процессом принятия решений внутри Microsoft. Процесс принятия решения о доведении F# до качества продукта был во многом одним из тех, которые лучше всего демонстрируют Microsoft Research. Это также показывает лучшие стороны команды Microsoft: было много открытых дверей, чтобы поговорить с командами разработчиков о наших исследованиях и о том, почему мы их проводим. Мы сделали этот проект, потому что это было отличное исследование, но тот факт, что оно оказалось достаточно ценным, чтобы довести его до качества продукта: это фантастика.