Является ли функциональный язык хорошим выбором для Flight Simulator? Как насчет Lisp?

Ответ 1

Общей ошибкой считается "Lisp" как функциональный язык. На самом деле его лучше всего рассматривать как семейство языков, возможно, но в наши дни, когда люди говорят Lisp, они обычно означают Common Lisp.

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

Что касается вашего вопроса, это хороший выбор? Это действительно зависит от ваших планов. Обычный Lisp особенно имеет некоторые реальные сильные стороны для такого рода вещей. Это интерактивно и интроспективно на уровне, который вы обычно видите на так называемых языках сценариев, что делает его очень быстрым для разработки. В то же время его скомпилированные и эффективные компиляторы, поэтому вы можете ожидать, что производительность в том же самом шаге, что и другие эффективные компиляторы (с коэффициентом два из с является типичным ime). В то время как большой язык, он имеет гораздо более последовательный дизайн, чем такие, как С++, и возможности метапрограммирования могут сделать очень чистый, понятный код для вашего конкретного приложения. Если вы посмотрите только на эти аспекты общий Lisp выглядит потрясающе.

Однако есть и недостатки. Сообщество мало, вы не найдете много людей, чтобы помочь, если это то, что вы ищете. Хотя встроенная библиотека большая, вы не найдете столько сторонних библиотек, чтобы вы могли написать больше об этом с нуля. Наконец, в то время как это ни в коем случае не огороженный сад, CL не имеет такой гладкой интеграции с зарубежными библиотеками, которые говорят, что python делает. Это не значит, что вы не можете вызвать c-код, для этого есть хорошие инструменты.

Кстати, CLOS - это самая мощная система OO, о которой я могу думать, но это совсем другой подход, если вы исходите из основного С++/java/С#/etc. OO (да, они отличаются друг от друга, но за пределами одиночного или множественного количества, не так много), вы можете сначала немного поначалу немного странно вывернуться наизнанку.

Если вы пройдете этот маршрут, вам придется следить за некоторыми проблемами с производительностью фактического конвейера рендеринга, если вы пишете это самостоятельно с помощью CLOS. Система класса имеет невероятную гибкость во время выполнения (т.е. Обновление определений классов во время выполнения, а не через патч обезьяны и т.д., Но путем фактического изменения класса и экземпляров обновления), однако вы платите за это стоимость доставки.

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

В целом, это может быть прекрасный выбор языка для этого проекта, но не единственный. Если вы не используете язык с высокоуровневыми аспектами и хорошей производительностью (например, CL, как и OCaml, и некоторые другие), я определенно посмотрю на возможность двухуровневого подхода с использованием языка lua или, возможно, python (множество libs) поверх некоторого кода c или С++, делающего тяжелую работу.

Ответ 2

Если вы посмотрите на игру или симулятор, вы найдете много С++ плюс, возможно, некоторый добавленный компонент сценариев. Также могут быть инструменты, написанные на других языках для оформления декораций или связанных с ними задач. Но в этом домене используется только очень мало Lisp. Вы должны быть хорошим хакером, чтобы получить необходимую производительность из Lisp и иметь возможность доступа или записи низкоуровневого кода. Как вы получаете это ноу-хау? Попытайтесь, потерпите неудачу, учитесь, старайтесь, терпите неудачу, учитесь,... Нет ничего, кроме написания кода и экспериментов с ним. Lisp действительно полезен для хороших инженеров-программистов или тех, кто может быть хорошим инженером-программистом.

Одним из основных препятствий является сборщик мусора. Либо у вас очень простой (тогда у вас проблемы с производительностью со случайными паузами), либо у вас сложный (тогда у вас есть проблема с правильной работой). Существует только несколько сборщиков мусора, которые были бы подходящими - большинство реализаций Lisp имеют хорошие реализации GC, но все же они не настроены для использования в реальном времени или почти в режиме реального времени. Исключения существуют. С С++ вы можете забыть GC, потому что обычно нет.

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

Ближе всего, что было разработано в этой области, была игра Crash Bandicoot (а также более поздние игры) для Playstation я (более поздние игры были для Playstation II) от Naughty Dog. Поскольку они были куплены Sony, они перешли на С++ для Playstation III. Их среда разработки была написана в Allegro Common Lisp и включала в себя компилятор для варианта Scheme (a Lisp). В системе разработки код компилируется, а затем загружается на Playstation во время разработки. У них был собственный 3D-движок (очень впечатляющий, он всегда получал отличные отзывы от игровых журналов), инкрементную загрузку уровня, сложный контроль поведения для множества разных участников и т.д. Таким образом, Playstation действительно выполняла код схемы, но управление памятью не выполнялось через GC (afaik). Им пришлось разрабатывать все технологии самостоятельно - никто не предлагал инструменты на основе w137 > , но они могли, потому что они были отличными разработчиками программного обеспечения. С тех пор я не слышал о подобном проекте. Обратите внимание, что для скриптов это было не просто Lisp - это было Lisp до конца.

На стороне схемы есть также новая интересная реализация, называемая Ypsilon Scheme. Он разработан для игры в пинбол - это тоже может быть основой для других игр.

На общей стороне Lisp были приложения Lisp, говорящие с имитаторами полета и контролирующими их аспектами. Существуют библиотеки игр, основанные на SDL. В OpenGL есть интерфейсы. Существует также нечто вроде "Open Agent Engine". Также есть некоторые 3D-графические приложения, написанные в Common Lisp - даже некоторые сложные. Но в области моделирования полета очень мало предшествующего уровня техники.

По теме CLOS против функционального программирования. Наверное, нельзя было использовать ни того, ни другого. Если вам нужно выжать всю возможную производительность из системы, CLOS уже имеет некоторые накладные расходы, которые можно было бы избежать.

Ответ 3

Взгляните на Функциональное реактивное программирование. В Haskell существует ряд фреймворков (не знаю о других языках), большинство из которых основаны на стрелках. Основная идея заключается в представлении отношений между изменяющимися во времени значениями и событиями. Так, например, вы бы записали (в обозначении стрелки Haskell без использования конкретной библиотеки):

   velocity <- {some expression of airspeed, heading, gravity etc.}
   position <- integrate <- velocity

Вторая строка объявляет взаимосвязь между положением и скоростью. Операторы < - arrow представляют собой синтаксический сахар для множества вызовов библиотеки, которые связывают все вместе.

Затем позже вы можете сказать что-то вроде:

   groundLevel <- getGroundLevel <- position
   altitude <- getAltitude <- position
   crashed <- liftA2 (<) altitude groundLevel

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

IO не является проблемой в этой парадигме. Входы представляют собой изменяющиеся во времени значения, такие как джойстик X и Y, а изображение на экране - это просто другое изменяющееся время. На самом верхнем уровне весь ваш симулятор является стрелкой от входов к выходам. Затем вы вызываете функцию "run", которая преобразует стрелку в действие IO, которое запускает игру.

Если вы напишете это в Lisp, вы, вероятно, обнаружите, что создаете кучу макросов, которые в основном заново изобретают стрелки, поэтому, возможно, стоит просто узнать о стрелках для начала.

Ответ 4

Я ничего не знаю о симах полета, и вы не указали ничего, в частности, из них, поэтому это в основном предположение о написании FS в Lisp.

Почему бы и нет:

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

• Полетные симы в основном (я угадываю), написанные на статичных, изначально компилированных языках. Если вы ищете чистую производительность во время выполнения, то в Lisp это означает объявления типов и другие не-подобные Lispy-конструкции. Если вы не получите требуемую производительность с наивными подходами, ваш оптимизированный Lisp может оказаться очень похожим на C, а Lisp не так хорош в C при написании C.

• Многие FS, я предполагаю, взаимодействуют с графической библиотекой, такой как OpenGL, которая написана на C. В зависимости от того, как ваши привязки FFI/OpenGL, это может также сделать ваш код выглядят как C-in Lisp. У вас может не быть большой выигрыш, который Lisp делает, скажем, в веб-приложении (которое состоит из генерации древовидной структуры обычного текста, в котором Lisp отлично).

Почему:

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

• Они используют строки для ключей повсюду (С++ не имеет символов). Они используют XML для полу-человекочитаемых конфигурационных файлов (С++ не имеет считывателя времени исполнения). Простое переключение на собственные конструкторы Lisp здесь может быть большой победой для минимальных усилий.

• Ничто не выглядит сложным, даже "AI". Это просто вопрос сохранения всего организованного, и Lisp будет большим в этом, потому что это будет намного короче.

Но опрятная вещь о Lisp заключается в том, что это мультипарадигма. Вы можете использовать OO для организации "объектов" и FP для вычисления внутри каждого объекта. Я говорю, просто начните писать и посмотрите, куда он вас доставит.

Ответ 5

Я бы не сказал, что функциональное программирование особенно хорошо подходит для моделирования полета. В общем, функциональные языки могут быть очень полезны для написания научных симуляций, хотя это немного специализированный случай. Действительно, вам, вероятно, будет лучше со стандартным императивным (желательно ООП) языком, таким как С++/С#/Java, поскольку у них будут лучшие библиотеки физики, а также графические API, которые вам нужно будет использовать очень сильно. Кроме того, подход ООП может облегчить представление вашей среды. Еще один момент, который следует учитывать, заключается в том, что (насколько мне известно) популярные симуляторы полета на рынке сегодня написаны почти полностью на С++.

По сути, моя философия заключается в том, что если нет особо веских оснований для использования функциональных парадигм, тогда не используйте функциональный язык (хотя вам нечего прекращать использовать функциональные конструкции в ООП/смешанных языках). Я подозреваю, что у вас будет намного менее болезненный процесс разработки, используя проверенные API для С++ и языки, более часто связанные с развитием игры (что имеет много общих черт с симулятором полета). Теперь, если вы хотите добавить какой-то сложный AI в симулятор, Lisp может показаться скорее более очевидным выбором, хотя даже тогда я бы совсем не прыгал за него. И, наконец, если вы действительно заинтересованы в использовании функционального языка, я бы порекомендовал вам пойти с одним из наиболее общих целей, таких как Python или даже F # (на самом деле оба смешанных императивно-функциональных языка), в отличие от Lisp, который может оказаться довольно уродливым для такого проекта.

Ответ 6

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

Теперь, как боковая точка, haskell не будет хорошим IMHO, потому что он слишком абстрактный для "игры", это приложение похоже на Input/Output, но Haskell избегает ввода-вывода, поэтому он станет монадский кошмар, и вы будете работать против языка. Lisp - лучший выбор, или Lua или Javascript, они также функциональны, но не являются чисто функциональными, поэтому для вашего случая попробуйте Lisp. В любом случае на любом из этих языков ваша графика будет C или С++.

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

Ответ 7

Сначала я подумал о характере моделирования.

Некоторые симуляции требуют взаимодействия, как симулятор полета. Я не думаю, что функциональное программирование может быть хорошим выбором для интерактивного (читай: интенсивного процессора/критического) приложения. Конечно, если у вас есть доступ к 8 PS3, подключенным вместе с Linux, вам будет не так много внимания в производительности.

Для симуляций, таких как эволюционное/генетическое программирование, где вы его настраиваете и позволяете "er rip", functioonal lauguage может помочь моделировать проблемную область лучше, чем язык OO. Не то, чтобы я был экспертом в функциональном программировании, но простота рекурсии кодирования и идея ленивой оценки, характерной для функциональных языков, мне хорошо подходят для "пусть ее разрывают" вроде симов.