Журнал «Компьютерра» - Журнал «Компьютерра» N 8 от 27 февраля 2007 года (Компьютерра - 676) Страница 14
- Категория: Компьютеры и Интернет / Прочая околокомпьтерная литература
- Автор: Журнал «Компьютерра»
- Год выпуска: неизвестен
- ISBN: нет данных
- Издательство: неизвестно
- Страниц: 28
- Добавлено: 2019-05-28 16:04:35
Журнал «Компьютерра» - Журнал «Компьютерра» N 8 от 27 февраля 2007 года (Компьютерра - 676) краткое содержание
Прочтите описание перед тем, как прочитать онлайн книгу «Журнал «Компьютерра» - Журнал «Компьютерра» N 8 от 27 февраля 2007 года (Компьютерра - 676)» бесплатно полную версию:Журнал «Компьютерра» - Журнал «Компьютерра» N 8 от 27 февраля 2007 года (Компьютерра - 676) читать онлайн бесплатно
То же самое — с концепциями «программа — это данные, изменяемые в любой момент» (здравствуй, Lisp) и «все в программе суть объекты, обменивающиеся сообщениями» (здравствуй, Smalltalk). Время программиста и его fun — главная ценность; ради этих «высоких идеалов» можно и идейные столпы пошатать.
Забавно, что в этом стремительном выходе скриптов на передний план главное назначение «языка сценариев» — написание одноразовых программ сомнительного качества — как-то потерялось. Что породило забавные казусы «самоопределения» — тем паче, что и другие типично скриптовые свойства (вроде интерпретируемости) многим сегодняшним «скриптам» несвойственны (Python, как Java, компилируется в байт-код и выполняется на виртуальной машине; виртуальные машины для Perl и Ruby сейчас разрабатываются соответствующими сообществами и находятся в районе «альфа» и «бета» версий).
Платформа 200NЦитата
Это здорово, что популярность Ruby резко взлетела, и еще более здорово, что я приложил к этому палец. Не то чтобы я много об этом размышлял, но думаю об этом с гордостью.
Д. Хеймер Ханссен, создатель ruby on railsОчередная «дырка в заборе» мэйнстрима — как ни странно, Microsoft. Шаткое положении как-бы-лидера — только и успевай крутиться, и Джаву надо переджавить, и с поднимающими голову скриптами совладать, и Гуглу настучать, и Виндов побольше продать — поневоле вынуждает к инновационности и нос-по-ветру. Отсюда — появление во второй версии C# анонимных делегатов (они же — переменные-функции) и связанных с этим элементов функционального программирования; отсюда же — подъязык LINQ, вводящий в C# 3.0 декларативную нотацию, подобную SQL.
Но важнее даже не это, а принципиальная изначальная многоязычность. Net’а и, соответственно, поощряемые и приветствуемые попытки существующие языки на микрософтовскую платформу портировать и новые, невиданные, создать. Эффект симбиоза ново-старых языковых идей и платформы промышленного качества понятен: для платформы выгода в том, что даются новые инструменты программистам и «импортируется» сообщество соответствующего языка; для самого языка становятся доступными богатые библиотеки. Net’а (особенно актуально для языков с привкусом «академичности», зачастую страдающих от отсутствия элементарных библиотек для индустриальных задач) и — огромное количество готовых пользователей [Все эти выкладки в большой степени относятся и к платформе Java. Понятно, что изначально платформа была «одноязычной», но сейчас (не в последнюю очередь — в результате «гонки платформ» с Microsoft) Sun уделяет много внимания развитию и поддержке других языков на своей платформе].
Одной из целей. Net’а было облегчение интеграции кода на разных языках, а значит, многоязычные проекты на этой платформе более распространены, и теоретически можно основную часть проекта оставить на C#, алгоритмически сложную часть написать на каком-нибудь Haskell.Net или F# (ML-подобный язык), а разные быстрые тесты и служебные задачи, требующие «быстрого и грязного» кода, решать, к примеру, на IronPython.
Понятно, что чем дальше отстоит портируемый язык от традиционных, тем сложнее его бесшовная интеграция с другими языками платформы. Отсюда — некоторые интересные проекты, которые революционные (для мэйнстрима) идеи скрещивают с естественной объектной моделью и привычным синтаксисом платформ Java/.Net. Таких проектов уже немало: к примеру, для. Net’а — питонообразный Boo и многоконцептуальный Nemerle, совмещающий традиционный ОО-подход с функциональными возможностями и выводом типов в духе ML и синтаксическими макросами вроде Lisp’овых [Из не-Lisp’образных языков Nemerle, кажется, единственный, предоставляющий средства такого уровня]; для Java — объектно-функциональный гибрид Scala и Ruby-подобный Groovy [Это не считая экспериментальных языков, являющихся расширениями-надмножествами C# и Java (C-omega, Pizza/PJ) и использующихся в основном для обкатки идей, которые впоследствии войдут (или не войдут) в основной язык].
О широкой известности и применимости таких языков говорить рано, но кое-какие предположения об их судьбе сделать можно.
Языки рода Boo и Groovy, чьи авторы стоят на позициях «скриптовых» (в смысле лаконичности программ и богатого набора «фенечек»), на позицию «скриптов в рамках платформы» как раз и метят. Их роль — быть «клеем» между компонентами, инструментом для «условно одноразовых» программ (тестов для отладки компонентов на «серьезных» языках) и вообще инструментом для «гибких» подходов. В этом контексте их будущее видится относительно безоблачным, как и будущее «портированных» IronPython/Jython, JRuby/RubyCLR.
Nemerle и Scala — это совсем другой коленкор, «модернизм в миниатюре». С их «продвинутыми» идеями связаны те же надежды и проблемы, что некогда были характерны для Haskell, Lisp, Smalltalk — «вроде и круто, но больно хитро». Можно предположить, что и судьба «больно хитрых» языков сложится похожим образом и они станут генераторами идей для C#/Java и прибежищем немногих «понимающих». Впрочем, расстояние от этого «мини-модернизма» до мэйнстрима не так уж велико, а компонентный подход накладывает меньше ограничений на взаимодействие разноязыковых модулей; так что «продвинутые» языки может ждать и более счастливая судьба. Остается пожелать им удачи.
Разработчики HaskellСаймон Пейтон Джонс (Simon Peyton Jones), один из разработчиков Haskell, архитектор Glas-gow Haskell Compiler (GHC); Кейл Гиббард (Cale Gibbard), популяризатор Haskell, автор нескольких руководств.
О целях и перспективах
Гиббард: Haskell всегда был и остается исследовательским языком. Множество студентов и ученых думают о расширениях языка и новых библиотеках, на основе которых можно было бы опубликовать научную работу. Так что прогресс идет довольно быстро, и некоторые библиотеки так же сложны и красивы, как сам язык.
Джонс: С практической точки зрения, развитие Haskell идет путем воплощения экспериментальных возможностей в разных компиляторах.
Иногда сообщество хаскелистов садится и собирает эти анархические расширения в единые стройные концепции. Сейчас мы работаем над новой версией — Haskell Prime, чтобы можно было сказать «эта программа написана на Haskell Prime» вместо "эту программу можно скомпилировать с помощью GHC 6.8.
Гиббард: Мы рассматриваем противоречивые места предыдущего стандарта [Haskell ‘98] и изучаем, как люди жили с ними последние несколько лет.
Об использовании и распространении
Гиббард: Один из главных факторов, мешающих популярности Haskell, — инерция. В конце концов, объектно-ориентированному программированию тоже понадобилось лет двадцать-тридцать, чтобы завоевать популярность. Haskell старше Java — почему же он до сих пор не добился аналогичных успехов в своем распространении? Дело в том, что Haskell — гораздо более «продвинутый», чем Java/C++ или даже Python и Ruby. Для программистов, знающих только объектно-ориентированное и императивное программирование, — это вроде как учиться программировать заново. Другая причина — долгое время Хаскеллу очень не хватало всяких штук, нужных для практического программирования. Впрочем, качество и количество библиотек в последнее время сильно возросло. Еще одна причина — недостаточная производительность функциональных языков, но в сегодняшних условиях это скорее миф.
Джонс: Чем больше люди будут интересоваться написанием работающих программ, особенно с использованием параллелизма, тем более популярны будут функциональные языки. С другой стороны, хотя истоки функциональной парадигмы — в академическом сообществе, такие языки становятся все более практичными.
Обращение к народуДжонс: Попробуйте функциональное программирование! Даже если вы не начнете активно использовать его, ваше представление о программировании существенно изменится.
Гиббард: Начинающему функциональному программисту я в первую очередь советую освоиться со списками — это то, что заменяет большинство циклов из императивного программирования. В конце концов, каким бы пугающим ни казался Haskell поначалу, на самом деле не так уж все страшно — стоит взять какое-нибудь руководство и просто попробовать. Оно того стоит.
Беседовал Дмитрий Антонюк
…И другиеПроанализировав набирающие популярность гибриды, можно заметить, что господство императивного программирования по-прежнему сохраняется. Как бы ни изменялось отношение к объектам и коду в целом, какие бы функциональные возможности ни появлялись, структура программы на микроуровне остается тем же набором последовательных инструкций, ветвлений и вызовов функций. Понятно, что привычные паттерны так просто своего не уступят.
Тем не менее существуют, конечно, и более экстремальные «постмодернистские» системы; самая известная и успешная из них, пожалуй, Erlang. Язык/платформа (производные сразу от нескольких декларативных языков программирования и концепций), созданная суровыми шведскими практиками из фирмы Ericsson для нужд телекома, — Erlang не то чтобы пробивается в мэйнстрим, но в своей области (написание распределенных приложений с серьезными требованиями к производительности и устойчивости) чувствует себя весьма уверенно. Вообще, в области распределенных приложений, в телекоммуникациях и смежных областях совмещение красивой теоретической модели и мощной платформы — решение, набирающее вес. Помимо Erlang, на похожих позициях стоят Oz/Mozart и с-пылу-с-жару новый язык Corn (также рожденный в телекоме, на сей раз — польском).
Жалоба
Напишите нам, и мы в срочном порядке примем меры.