Функциональные языки: вести с полей

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

Haskell

Мейнстримом, понятно, ему не быть, слишком много сложных экспериментальных фич, язык, крутая learning curve -- учитывая все это, можно сказать что хаскель уже популярен донельзя. Кое-где даже встречается в объявлениях о поиске сотрудников, у "них" вот Credit Suisse его использует. Pugs тоже сыграл большую роль в том что название "хаскель" слышали даже не очень сильно интересующиеся вопросом товарищи. Насчет того чтоб он как-то серьезно применялся в России -- не слышно и не видно.

O'Caml

Окемлу лет тоже уже много, так что резкие всплески популярности он уже пережил -- самый прагматичный язык, с замечательным оптимизирующим компилятором. В Jane's Capital вроде как его активно любят (почитать можно тут). Рекрутеры продвинутые тоже знают. Вот тут  люди в Москве на нем даже игры разрабатывают.

F#

Бурно развивающийся диалект Ocaml'а для .net. Точнее от ocaml он уже довольно-таки далеко. Огромный плюс в том что засчет использования .net нахаляву получаем интеграцию с C#, гуи и IDE. В этом году выходят сразу три книжки по F#,  активно пиарятся две консалтинговые конторы специализирующиеся на F#: вот и вот. ИМХО вполне себе положительный знак. Программеров на F# правда пока никто не ищет.

Scala

Новый язык, на базе JVM, поддерживает кучу интересных фишек, типа GADT, ОО модель плотно интегрирована с функциональщиной. Больше всего сейчас слышно про веб-фреймворк на scala -- lift. В качестве killer app приводится клон вебдваноль сервиса twitter в 800 строчек, вроде как способный обслуживать до миллиона юзеров с одного сервера. В общем, по мне так -- язык просто замечательный, даже приятнее окемла.

Становится все популярнее и популярнее -- у меня в google alerts уже половина упоминаний scala относится к языку программирования, а не к одноименному оперному театру. Полгода назад показатель составлял 20%.

Erlang

Эрлэнг это, кажется, наиболее успешный функциональный язык после excel'я -- потому что изначально создавался для решения практических задач, и рассчитан на относительно низкий порог вхождения для обучаемых программистов. Killer App из мира open source это jabber-сервер ejabberd. Ну и хрестоматийный пример про маршрутизатор AXD301 на эрланге.

В плане работы -- есть несколько организаций в России которые, похоже, используют Erlang вполне промышленно. Судя по объявлениям о приеме на работу в Питере это StanaPhone (российское отделение крупной американской компании, разрабатывающей VoIP приложения). А в Москве прям сейчас ищет Erlang-программистов довольно крупная медиа-компания A1.

Читать дальше..

Новый C++09 ISO Standard Draft

..если кому интересно, можно взять тут.

Тут вот также пост Герба нашего Саттера, а так же видео (по ссылкам от aruslan   ). Те, кто немного следит за процессом, вряд ли увидят там что-то новое — Саттер вот пишет про typedef templates и темплейты с произвольным количеством параметров. Для меня правда новостью было нечто под названием programmer-directed garbage collection.

 

В затихших нынче holy wars на тему C#(Java) vs C++ обычно рано или поздно всплывал тезис "да в C++ можно с полпинка сделать gc, тока кому это надо?" — поэтому почитать proposal на эту тему вдвойне интересно.

Авторы, в лучших традициях C++, подошли к вопросу аккуратно, чтобы никакой имеющийся код не поломать — и у них получилось, но, как обычно, те, кто будет этот самый GC все-таки использовать, получают дополнительный лес граблей.

В двух словах — сборщик мусора тупо сканит все объекты на наличие указателей (на уровне бинарного представления, независимо от типа). А чтобы он не надорвался, программист может ему поклясться в type safety для конкретного класса/структуры/модуля/переменной — то есть обещает с поинтерами никаким сексом не заниматься (прежде всего в int'ы, char[] и другие неподходящие места их не записывать). Тогда сборщик мусора будет обрабатывать только переменные, имеющие C++-тип указателя.

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

Плюс к этому, не совсем ясно будет ли gc двигать в памяти объекты — если не будет, то эффективность его под вопросом, если будет — всплывет изрядное количество всяких неочевидных проблем. Например, непонятно что будет с конструкциями типа std::map<Foo *, ...> в случае если объект может "плавать" в памяти.

В общем Саттеру с Мейерсом и Александреску материала для книжек "как обойти все подводные грабли C++" хватит еще надолго.

Читать дальше..

Компилятор C++ MADE IN RUSSIA

Конечно, новость не очень свежая, но я вот только недавно узнал о существовании натурального компилятора C++, полностью разработанного в России для нужд военных и всяких ФГУПов.

Компилятор в довольно-таки большой степени соответствует стандарту (ну, по крайней мере, явных косяков не видно). Плюс IDE на базе Eclipse/CDT. Плюс к нему прилагается набор тулзов для анализа программ, включая реверс-инжиниринг исходник->UML.

Есть онлайн-компилятор (а-ля comeau), сам компилятор скачать нельзя (а так хотелось проверить — вдруг там и export template реализован?).

Забавно: это все разрабатывалось для нужд разных государственных предприятий, и этот факт наложил таки отпечаток: во всех мануалах абсолютно все термины переведены на русский ("компилятор переднего плана"), а в самом компиляторе есть даже возможность заменить все ключевые слова на русские эквиваленты ("конст_прив" это const_cast, например). Но тут по-моему это только придает некоторый шарм :)

Единственный(похоже) реализованый пока back-end для компилятора тоже заслуживает внимания — он генерит код для российского сигнального процессора "Мультикор" ([имхо] наивысшее достижение отечественной микроэлектроники за последние 15 лет).

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

Читать дальше..

Динамические языки внутри .net и JVM

В продолжение к предыдущему посту — а собственно почему столько шума? Зачем столько пафоса при релизе DLR?

А дело все в том, что и sun и microsoft последние несколько лет внимательно смотрят в сторону динамических языков. Потому как различные php, python'ы и ruby играют нынче мощную роль на рынке — и на этот рынок, конечно, хочется влиять.

Когда создавались .net и JVM основной их задачей было соответственно выполнение C# и Java программ, об остальном их создатели думали не столь внимательно. Как заметил автор этой презентации, по аналогии с известным высказыванием Г. Форда, "вы можете запустить на .net любой язык, если это C#".

Однако вскоре стало понятно что одной явой и C# при написании веб-приложений сыт не будешь, тут-то собственно языки тоже заинтересовали и sun, и ms — последняя наняла Jim Huguin'а, автора JPython, а sun прошлым летом наняла авторов JRuby.

Проблемы реализации прежде всего вырастают из того факта, что и CLI, и JVM прежде всего ориентированы на языки со статической типизацией — у них даже байт-код строго статически типизированный. А динамическому языку нужно позднее связывание (оно же динамическая диспетчеризация) — при вызове a.someMethod() какой именно метод вызывать выясняется во время выполнения, основываясь на динамическом типе значения a. Причем a вообще может не иметь такого метода — это заранее неизвестно.

А при вызове call, callvirt в .net мы должны заранее, статически, знать класс объекта (как и при вызове метода — обычном или виртуальном — в C++).

Конечно, проблема решается довольно-таки очевидным способом — в CLR и java все классы наследуются от корневого Object — соответственно процедуры в динамическом языке получают тип Object someMethod(Object[] args), и в местах вызова вставляется код который ищет в словаре соответствующий метод у объекта. С одной стороны тут возникает некоторое количество сложностей, с другой — благодаря развитому reflection'у и генерации кода на лету — все проблемы решаются, и даже получается оптимизировать такие вызовы — если в o.someMethod() значение переменной o имеет всегда один и тот же тип, каждый раз тратить O(logN) времени на поиск по словарю не надо, и т.п.

Эффективные, обкатанные на IronPython решения для этой и других (динамическая типизация, изменение классов на лету, closures...) проблем как раз и предоставляет DLR. Для JVM кстати что-то похожее уже создавалось — однако то ли эту библиотеку вообще не релизили, то ли я плохо искал. А вообще уже несколько лет тянется процесс добавления в яву байт-кода invokedynamic — который будет как раз реализовывать позднее связывание на уровне виртуальной машины.

Теперь интересные линки:
Итого, что мы имеем из динамических языков, компилируемых в байт-код:
на JVM: JPython, JRuby, Groovy на CLI: IronPython, JScript.Net, VB.NET, PHP (На самом деле динамических языков намного больше, но остальные вроде как в байт-код напрямую не компилируются).

JVM:

• презентация про invokedynamic
• Серия интервью с разработчиками JRuby
• Интервью с руководителем группы по добавлению invokedynamic в JVM

.NET:

• Блог разработчика IronPython и JPython Jim'а Huhunin'а
• Joel Pobar: CLR Dynamic languages under the hood
• CLR Inside Out: IronPython

Читать дальше..

Microsoft Dynamic Language Runtime

Сегодня наш любимый большой брат microsoft сделал еще шаг навстречу динамическим языкам на платформе .net: на конференции mix'07 объявил о релизе DLR -- Dynamic Language Runtime, по аналогии с известным всем Common Language Runtime.

После пропуска постов, подкастов и интервью через антимаркетинговый фильтр, получаем на выходе действительно большую и полезную библиотеку, призванную сильно облегчить написание компиляторов для динамически типизированных языков под .net.

А библиотека эта выросла из проекта IronPython -- реализации Python под .net созданной CLR Team. Основной в этой команде инжынер Jim Hugunin, до того как его взяли в майкрософт, написал на досуге компилятор Python под JVM. Дядька, в общем, в высшей степени интересный, блог его тут.

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

Да, все это происходит в контексте усиленного продвигания майкрософтом своего веб2десктоп фреймворка Silverlight, так что по ссылкам он упоминается очень интенсивно -- не удивляйтесь :)

Еще пара ссылок:

• A Dynamic Language Runtime (DLR) -- пост Jim'а Hugunin'а
• Подкаст с другим разрабочиком IronPython -- Джоном Лэмом
• Интервью с обоими

Читать дальше..