Как «ориентированное на язык программирование» сравнивается с ООП/функционал в реальном мире
https://stackoverflow.com/questions/1703869
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianВопрос
Недавно я начал читать литературу, связанную с F#, говоря о «реальном функциональном программировании» и «Эксперте F#», например. Вначале это легко, потому что у меня есть некоторый опыт работы в Хаскелле, и я знаю C#. Но когда дело доходит до "Языковое программирование«Я просто не понимаю. - Я прочитал некоторые объяснения, и это все равно, что читать академическую статью, которая становится более абстрактной и странной с каждым предложением.
У кого -нибудь есть простой пример для такого рода вещей и как он сравнивается с существующими парадигмами? Это не просто академическая фантазия, не так ли? ;)
Спасибо, wishi
Решение
F# имеет несколько механизмов для выполнения программирования в стиле, который можно назвать «языковым ориентированием».
Во-первых, синтаксические тонкости (функциональные вызовы не нуждаются в скобках, могут определить собственных операторов Infix, ...) сделать так, чтобы многие пользовательские библиотеки имели вид встроенных DSL.
Во -вторых, механизм цитат F# "может позволить вам процитировать код, а затем запустить его с помощью альтернативной семантики/механизма оценки.
В -третьих, F# «Вычислительные выражения» (он же рабочие процессы, Monads, ...) также предоставляют способ предоставить тип альтернативной семантики для определенных блоков кода.
Все это вроде в категории EDSL.
Другие советы
Языковая программа (LOP) может использоваться для описания любого из следующего.
Создание внешнего языка (DSL)
Это, пожалуй, наиболее распространенное использование LOP, и у вас есть определенный домен - такой как пакеты доставки UPS через типы транзитов через маршруты и т. Д., Вместо этого пытаться кодировать все эти специфичные для домена сущности внутри кода программы, вы Скорее создайте отдельный язык программирования только для этого домена. Таким образом, вы можете кодировать свою проблему на отдельном внешнем языке.
Создание внутреннего языка
Иногда вы хотите, чтобы ваш программный код был менее похожим на «код» и более внимательно сопоставляется с проблемным доменом. То есть иметь код «читать более естественно». Беспроводной интерфейс является примером этого: Беглый интерфейс. Анкет Кроме того, F# имеет активные шаблоны, которые поддерживают это довольно хорошо.
я написал пост в блоге На некоторое время назад на LOP, который предоставляет некоторые примеры кода.
В объектно -ориентированном программировании вы пытаетесь моделировать проблему с использованием объектов. Затем вы можете соединить эти объекты вместе для выполнения функций ... и в конце решить исходную проблему.
В языковом программировании, вместо того, чтобы использовать существующий объектно -ориентированный или функциональный язык программирования, вы разрабатываете новый язык, специфичный для домена, который лучше всего подходит для эффективного решения вашей проблемы.
Термин, ориентированное на языко, может быть перегружено тем, что оно может иметь разные значения для разных людей.
Но с точки зрения того, как я его использовал, это означает, что вы создаете DSL (http://en.wikipedia.org/wiki/domain_specific_language) Прежде чем начать решать свою проблему.
Как только ваш DSL будет создан, вы отправите свою программу с точки зрения DSL.
Идея состоит в том, что ваш DSL больше подходит для выражения проблемы, чем язык общего назначения.
Некоторым примером будет синтаксис файла Make или Ruby на классе Activerecord Rails.
Я не знаю напрямую Используемые языковые программирование в реальных ситуациях (создание реального языка), но полезно думать и помогает разрабатывать более управляемые доменом объекты.
В некотором смысле, Любые Развитие реального мира в LISP или схеме можно считать «языковым ориентированием», поскольку вы разрабатываете «язык» своего приложения и его абстрактное дерево, когда вы кодируете. Огурец это еще один пример реального мира, о котором я слышал.
Обратите внимание, что есть некоторые проблемы с этим подходом (и любого подхода, управляемого доменом) в реальном развитии. Одной из основных проблем, с которыми я сталкивался ранее, является несоответствие между логикой, которая имеет смысл в домене и логикой, которая имеет смысл в программном обеспечении. Логика домена (бизнес) может быть чрезвычайно запутанной и бессмысленной - и приводит к разрушению доменных моделей.
Простой пример языка, специфичного для домена, упомянутого здесь, это SQL. Также: сценарии оболочки Unix.
Конечно, если вы делаете много основных OPS и имеете много совпадений с основным языком, это, вероятно, перегружено.
