Заспорили мы однажды с Хейзером…

Программирование

… А можно ли сделать игру на декларативном языке программирования?

В университете это было примерно так

Единственным декларативным языком программирования, на котором я программировал некоторое время, был Пролог (об уникальности коего можно читануть на Хабре, и на нём же ещё подробней). Что до Хейзера, то не знаю — пусть он сам нам поведает, какие языки ему были известны. Только не «просто известны», потому что слова «Хаскель» и «Лисп» я тоже знаю. А известны на практике, и опять же не примерно, а в реальной задаче, желательно всё-таки где-то возле программирования компьютерных игр.

Сошлись мы тогда на том, что если я создам 3Д-шутер на декларативном ЯП, то Хейзер будет должен мне купить лицензию на Гамак. Думаете, я остался доволен этим уговором? Нихрена подобного.

Естественно, никакого 3Д-шутера я не написал, а лицензию на ГМ Студию получу через недавний Humble Bundle, когда сайт ЙоЙоГеймс наконец-то перестанет виснуть от бешеного потока желающих прикупить лицензию за жалкие 12 долларов.

Объяснять разницу между декларативным и императивным программированием я не считаю нужным — достаточно констатировать, что первое не пользуется какой-либо особой популярностью в геймдеве. «Так в чём же суть?», спросите вы.

Суть в том, что Хейзер плохо очертил вопрос, который нужно решить. Вот есть игра на Гейм Мейкере (8.1, до-Студийный). Сам раннер (интерпретатор) ГМ написан на Дельфи, DirectX и прочее — на C/C++, хотя местами возможно тоже на Дельфи, а игра тем временем интерпретируется из скриптового языка GML, который Game Maker Language. На чём создана игра? На GML.

Это значит, что, подключи я DirectX/OpenGL (а там на пару и какой-нибудь аудио-движок) к Прологу, я бы уже получил прототип игры «на Прологе». Это конечно был бы ещё не шутер, и много возни было бы с 3Д — но эта возня была бы с любым языком, в любом движке. Чисто техническая не-языковая проблема, не теоретическая. Описать логику игровых объектов простенького шутера я могу легко, у них там всего пара состояний в зависимости от которых они меняют свой внешний вид, появляются и исчезают. Хейзер-то небось думал, что я должен буду писать драйвера (что было бы полным провалом на Прологе) — но я по такой постановке вопроса делать этого вовсе не должен.

Соответственно задачу считаю тривиальной, и спор — концептуально решённым в мою сторону.

Впрочем, разрабатывать 3Д-шутер на Прологе — всё ещё сомнительная идея.

Похожие статьи

  • MiniTekx
    Зашёл я значит сегодня в АндерГамин, а там мне и говорят:[26 сен 15 21:32] * Каждый день праздник * Xitilon: спорим твой tekx не может генерировать шум наподобие http://imgs....
  • Аудио-спектральный принтер
    Вы когда-нибудь слышали о скрытых посланиях в музыке? Я слышал. Больше всего меня заинтересовало, каким образом можно вставить изображение в трек, как в этих случаях. Я узнал,...
  • Tekx — что под капотом?
    Некоторых людей заинтересовал принцип работы моего процедурного генератора графики, результаты которого были показаны мной в начале этого года, вместе со ссылкой на сам Tekx 0....
  • Tekx — процедурный графический генератор
    Попал однажды в мои руки алгоритм процедурной генерации шума Ворли.А потом я подумал, что можно его расширить и разнообразить.И заверте...
214 комментариев
z17
Так, с 3Д-шутером на Прологе разобрались. Теперь очередь за рогаликом на Брейнфаке.
Hrenzerg
Не-не-не. Давайте сперва шахматы на Malbolge.
Yuuri
Но ведь они оба императивные…
Xitilon
Тут идея типа в том, что это очень_сложно. (ваш Кэп)
Hrenzerg

Так дело не пойдёт.

Это значит, что, подключи я DirectX/OpenGL (а там на пару и какой-нибудь аудио-движок) к Прологу, я бы уже получил прототип игры «на Прологе».

Это нихрена не значит. Потому что непонятно как подключать. Можно ли вообще создать какие-то интерфейсы для этого дела?

Я понимаю откуда ноги растут — дескать Гамак юзает диркетиксы и кучу готовых либ для рендера. Но игровую логику создаёт разработчик в среде GML. Ты что, готов создать игровую логику в среде prolog? Клавиатура не треснет, а?

Соответственно задачу считаю тривиальной, и спор — концептуально решённым в мою сторону.

Спор будет решён в твою сторону когда ты мне покажешь 3Д шутер и скажешь «он сделан на прологе». Тогда я вдоволь наудивляюсь, вращая глазами в разные стороны, и побегу пытать разработчика не тему «КАК». А так какой смысл в твоём решении. Выглядит как «приладим вот это сюда, вот тут как-то так, ну и всё, последний пинок и заработает». У меня после этих мыслей на практике обычно «А оно нифига не так!», «А это почему не фурычит?», «А я то думал, сработает».

Xitilon

Давай тезисно, растекаться мыслью по древу мы все умеем.

Непонятно как подключать? Смотри:

OpenGL + Пролог есть? Есть. Значит как-то да подключается.

Игровая логика может оказаться на Прологе даже проще, чем на GML, особенно в областях ИИ и логических задач. Согласен, крестики-нолики в 3Д это не шутер. Вопрос — что именно ты понимаешь под 3Д-шутером, что ж там такого непрограммируемого декларативно?

Я понимаю 3Д-шутер так:

  • Объект игрока. Ходит, прыгает, падает под действием гравитации. Хранит жизнь, стреляет пулями игрока.
  • Объект врага. Стреляет в игрока пулями врага.
  • Пуля врага. Врезаясь в игрока повреждает его и убивает если у него меньше 0 жизни.
  • Пуля игрока. То же с врагом.
  • Аптечка. Подбирается игроком, лечит.
  • Ну там всякая хрень по мелочи — ключи, двери.

Приведи мне конкретное проблемное место.

Hrenzerg

Для начала нужно понять есть ли в прологе ООП. Парадигма-то у пролога декларативная, т.е. совсем другая. Как ты собрался эти объекты реализовывать? Я сам с прологом работал, но лет 5-7 назад. Так что не очень помню конкретный синтаксис. Но по идеологии они не отличается от поиска в базе данных. То есть программист задаёт шаблон при помощи языка, а язык при выполненни команд выдаёт результат по шаблону. Твой набор действий нихрена не декларативный.

Термины должны быть в духе «повреждённый враг», «прыгающий игрок» и т.д. Ты оперируешь состояниями объектов.

Xitilon

Для начала нужно понять есть ли в прологе ООП. Парадигма-то у пролога декларативная

Prolog++

Logtalk

Костыль для подключения Пролога с помощью C++

Твой набор действий нихрена не декларативный.

Я тебе список составляющих игровой механики приводил, а не набор действий. Тем более это не список того что прямо пишется в исходный код, ни на Прологе, ни на GML. Я у тебя спросил — как ты видишь модель 3Д-шутера, и попросил привести проблемное место. В ответ я получаю что-то вроде «Ты не прав, а проблема везде».

Как ни странно, Пролог оперирует литералами предикатов ничуть не хуже, чем GML состояниями объектов — и то и другое это просто переменные, принимающие какие-то величины. Просто в Прологе обычно ищут строковый осмысленный ответ на запрос, а вычисления типа i=i+1 и состояние=следующее(состояние) являются в нём побочными, но не являются невозможными в принципе.

Hrenzerg

Я у тебя спросил — как ты видишь модель 3Д-шутера, и попросил привести проблемное место. В ответ я получаю что-то вроде «Ты не прав, а проблема везде».

Проблемное место конкретно в описании игровой логики декларативно.

Xitilon
Ну, тогда я тебе сообщаю, что такой проблемы нет.
Hrenzerg

Сказал — как в лужу пёрнул.

Ну так давай покажи что её нет этой проблемы. Пока что ты даже не придумал как декларативно описать объекты, как опсиать состояния их и переход от одного состояния к другому.

Xitilon
Зачем мне доказывать обратное, если ты не доказал прямое, при том что я (кстати и не только я, см. ниже) привёл довольно много фактов, свидетельствующих в обратную сторону?
Hrenzerg

В том что отрицающая теория в 99% случаев более сильная. Проще сказать что что-то невозможно. Поэтому я и принял такую удобную позицию с которой методично поплёвываю. Т.к. этот случай как раз в этих 99%. Ччтобы доказать возможность создания чего бы то ни было — нужно это создать.

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

Вот смотрите вот так можно сделать из живой мухи мёртвую [ВИДЕО]. Потом нужно всего-то сделать конвертор мёртвой мухи в слона и всё. Но это слишком хлопотно так что я не буду этого делать. Таким образом, спор выигран в мою сторону.

Как бы как раз то что ты называешь «хлопотно», «я не нерд» и т.д. — это то самое интересное. И не факт что оно получится. А так то конечно легко сказать что ты не собираешься выполнять тяжёлую работу и дескать ты потому и победил.

Xitilon

Поэтому я сказал что спор концептуально решён в мою сторону, а не что я победил.

Так как игру на Прологе уже создали, и не одну, что ты можешь видеть по ссылке, то просто поплёвывать с твоей позиции уже не получится.

Hrenzerg

Но я тебе могу облегчить задачу. Плюнь пока на пролог. Попробуй придумать сперва как написать 3Д шутер на регулярных выражениях. Это тоже декларативный язык и его логика проще. Ну или что совсем близко было бы тебе, наверное можешь подумать ту же самую задачу на SQL.

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

Xitilon
Так ведь одно дело что не знаешь — другое дело, возможно ли это. Я нахожу что возможно, и для доказательства не обязательно делать это на практике. На практике это много дурной работы, а я не настолько нерд.
Hrenzerg

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

Вот и вопрос теперь как ты будешь в строчках представлять свои объекты? Как ты будешь составлять выражения и гарантировать что получишь нужный результат?

Xitilon

Что значит «как работают регулярные выражения»? Регулярные выражения никак не «работают», это форма записи и способ парсить то или иное из вводимых данных. Ты наверное имеешь в виду форму Бэкуса-Наура? В любом случае непонятно зачем мне отвечать на этот сторонний вопрос.

Гарантировать нужный результат это не моя задача, а задача целой теории нахождения резольвенты - о том, как Пролог ищет противоречия в высказываниях. Уж если Пролог используют для автоматизированного доказательства теорем, в чём ты конкретно тут хочешь усомниться? Наоборот, декларативные подходы славятся своей «очищенностью» от сторонних состояний и порчи глобальных переменных. Во всяком случае, когда программа действительно написана — а написать её сложней, чем в императивной парадигме.

Hrenzerg
Ну вообще ты не прав, регулярные выражения очень даже работают. Ты знаешь хоть что там есть даже управляющие конструкции? На самомо деле написать раннер на регулярных выражениях в связке с каким-нибудь Си я могу себе смутно представить. Но это не много не то что должно относиться к проблеме.
Xitilon
Если ты под управляющими конструкциями регулярных выражений понимаешь метасимволы, квантификаторы, или что-то ещё для выделения шаблонов, то это там есть. Но «управляющих конструкций» типа присвоения величины переменной там нет. Поэтому задача написать игру якобы «на регулярных выражениях» носит более абсурдный характер, чем она же на Прологе.
Hrenzerg

Ну вообще там есть что-то типа присвоения величины пременной =) Это очень хитро реализовано. Что-то в духе запоминания позции последнего поиска. Я примерно год назад штудировал регулярки потому что мне нужно было распарсить ОЧЕНЬ хитрый документ. Получались конструкции в духе:

<big","(?:.*?<big>|\G)[^<]*?(?:<pic>([\d\w_\.\-\+\s]+?)<\/pic>[^<]*?<\/big>\z|<pic>([\d\w_\.\-\+\s]+?)<\/pic>)

Там было что-то типа выбрать все тэги pic внутри тега big. Количество тегов pic и big непредсказуемо. Отюсда как раз всплывают управляющие символы \G и \z. Которые правда не во всех реализациях regex есть.

Xitilon
Я работал с регулярными выражениями года два назад, в том числе с запоминанием позиций и номеров встреченных паттернов. Это всё же из другой оперы.
Hrenzerg

Номера встреченных паттернов — это совсем не то!

Тут речь идёт о том что функция regex_match находит ВСЕ паттерны. Если пользовать её в стандартном виде. То есть при анализе строки она будет идти по ней и говорить «вот тебе один, вот тебе второй и т.д.». Вся сложность в том, чтобы оно говорило «так, я внутри big и вот тебе один», «вот тебе второй», «так я теперь не внутри big и это не считается». Вот в чём обычно проблема — распознавание кусков внутри кусков без дробления строки исключительно синтаксисом regex. А в моём случае искуственное дробление строки было недопустимым.

Xitilon
А, ну понятно. Замороченный момент.
pevzi
Это был XML что ли? А не проще было взять парсер XML собсно?
Hrenzerg

Это не просто XML, а салат из нескольких XML. Задача была в синхронизации информации со складами поставщиков. То есть нужно ежедневно брать файлы у поставщиков и обрабатывать. Основная проблема — способ представления информации у всех разный, а порой ещё и запутанный, т.к. инфа по одному товару может быть размазана по нескольким XML. А может прилететь от поставщика и вовсе не XML, а какой-нибудь CSV или SQL-дамп.

Обработка происходит в два этапа.

На первом — действительно разбираются XML файлы при помощи парсера, но тут скорее выделяются общие куски по товарам. Вычленять отдельные параметры здесь довольно хлопотно. К тому же есть ограничение на время работу скрипта. Поэтому и нужна данная обработка для того, чтобы рассортировать инфу по товарам.

Затем этот винегерет сваливается в пул-таблицу из которой парсер CRON-скриптом одинаковым образом обрабатывает все товары последовательно из этой таблицы. Берётся товар и к нему применяется пачка регулярок для этого поставщика. На выхлопе я сразу получаю нужный массив, который отправляется в апдэйты по товару. Сам товар после обработки удаляется из пул-таблицы.

Возможно, это не самая эффективная организация с точки зрения производительности, но она более эффективна с другой точки зрения. Собственно, раньше-то как раз и произодился разбор каждого XML-я своим парсером. Но практика показала что у такого подхода плохая отказоустойичость. То есть если прилетел кривой XML (а такое бывает регулярно) — то он и сам не разобрался, и другим не дал, а если ещё и инфа напрямую с него в БД пишется то полный абзац может настать. Обновления товаров на сайт не приехали, менеджеры бегают в панике. А при такой реализации XML может сколь угодно кривой приехать и ничего не случится. Навернётся только скрипт-разобрщик для XML-ей конкретного поставщика. Ну в пул-таблицу не приедут для него товары. Зато всё остальное работает. Но самое лакомое — при добавлении нового поставщика в систему синхронизации(а такое уже было несколько раз) достаточно написать несложный XML-парсер для первоначального разбора и пачку регулярок. Всё остальное обрабатывает данные универсальным образом и хорошо отлажено. Если у поставщика меняется формат XML (добавляются новые параметры, например) то изменения вносятся обычно только в список регулярок, а не в XML-парсер.

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

Xitilon

А при такой реализации XML может сколь угодно кривой приехать и ничего не случится.

Так а может надо было просто обернуть всё в try-catch? Или в чём конкретно тут решение? На чём написано?

Hrenzerg
На php + mysql + bash script. Я бы с радостью писал обработку XML-ей не на php, но лучшего решения для серверной части линуха я не нашёл.
Xitilon
Хм… Да, наверное это решение было уместным тогда.
pevzi
Как-то уж крайне костыльно звучит. Так и хочется поубирать лишние сущности.
То есть если прилетел кривой XML (а такое бывает регулярно) — то он и сам не разобрался, и другим не дал

Вот это немного странно. Пусть бы падал только тот, что кривой, зачем остальные-то ронять? Регулярки же почему-то не роняют при тех же условиях.

Hrenzerg

Потому что ту конструкцию реализовал не я и обработка всех XML-ей была одним php-скриптом.

Так регулярки распарсивают уже раздробленный на первом этапе XML. И если падает кусок регулярки то не обрабатывается всего один товар из выгрузки, а не вся выгрузка.

Если обрабатывать всё разом, то придётся ловить экспешены (на PHP-то LOL) и то нет гарантии что скрипт откажется работать по какой-то другой причине. Поэтому я всё это максимально разделил и затолкал в расписание crontab. Чтобы если падал php-скрипт, то его падение не причиняло бы ущерба, потому что по CRON расписанию вскоре запустится новый и он будет где-то там себе падать до тех пор пока от поставщика не приедет нормальный XML. Но это уже проблемы поставщиков что они там подсовывают.

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

Yuuri
Кстати, «последовательно применяемые выражения к каким-то строчкам» – это языки переписывания термов, вроде РЕФАЛа.
Hrenzerg
И что с того?
Yuuri
С того, что регулярки тут приплетать не в тему, потому что они даже не язык программирования, а вот term rewriting – вполне.
Hrenzerg

Почему не язык программирования? Что такое язык программирования по-твоему?

Hrenzerg

Я не знаю можно ли живой писькой танк проткнуть. А ты мне смело можешь сказать:

Так ведь одно дело что не знаешь — другое дело, возможно ли это. Я нахожу что возможно, и для доказательства не обязательно делать это на практике. На практике это много дурной работы, а я не настолько нерд.

Вот как выглядят примерно твои слова. Без практики это пустой сотрясание воздуха. Мы же не о сущестовании бога теоретизирем, а о том что можно проверить экспериментом. Ну допустим не 3Д шутрер, попробуй для начала описать как ты декларативно будешь описывать простейшую игровую логику. Бег с препятствиями, например. Канабалта того же. Реализация на прологе, регулярках или сиквеле =)

Xitilon

Так ты это погоди. Речь шла именно о 3Д-шутере, а теперь ты его низводишь в класс задачи типа «создать раннер»? То есть по-твоему тогда получается что в декларативной парадигме вообще нельзя создать никакой реалтаймовой нелогической игры? Или какой класс игр ты хочешь выделить? Шахматы там сделать можно, я тебя уверяю, да и сам ты наверняка об этом догадываешься.

Xitilon

Мы как-то с тобой неправильно спорим. Вот есть список, нарытый нашим местным динозавром: (я не забыл про Андроид, скоро наконец получу нормальную машину)

  • «Угадай число от 0 до 9» это игра? Игра. Сделать её можно на Прологе? Определённо можно.
    Внимание — что «делает игру»? Да ничего её такого удивительного не делает, что требовало бы ООП или каких-то современных измышлений и обёрток. Как делали игры до ООП? Они что, были не реалтаймовыми? Или не играми? Но ближе к теме...
  • Крестики-нолики это игра? Сделать её можно, с ИИ. Думаю, спорить не будешь — вон даже есть механический компьютер на спичках с ИИ для этой игры, какое нахрен ООП? Идём дальше.
  • Арканоид — а вот это уже интересно. Знаете, чем? Да тем, что, сделав Арканоид, мы уже по аналогии (располагая условно бесконечным ресурсом прямых рук и времени) можем сделать любую следующую игру в списке, единственная проблема там будет — бутылочное горлышко скорости обработки информации и того, какие данные быстрее обрабатывает Пролог, а какие — «объектно-ориентированное средство разработки Икс».

    Итак — на Прологе нельзя написать Арканоид по-твоему? (ну или Канабальт, если в твоей формулировке)
Xitilon

Ну давай разберём по частям тобой написанное

Арканоид состоит из 2-мерного массива кирпичей, координат шарика (шариков), координат и размера платформы игрока, координат бонусов, и больше толком ни из чего.

Массивов в Прологе нет — там есть списки, реализованные как частный случай бинарного дерева (это не имеет никакого значения для рассматриваемой проблемы), соответственно для двух измерений используем список списков.

Циклов в Прологе нет — там есть рекурсия, соответственно используем рекурсию рекурсии.

Операции сложения, вычитания, сравнения переменной с числом (проверка коллизий же) — в Прологе есть.

Связку с OpenGL я уже привёл выше.

Твои аргументы?

Hrenzerg

Мои аргументы — заставить это работать. Наличие всех ингредеиентов ещё не гарантирует что салат будет съедобным и что вообще будет какой-то салат.

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

Xitilon

В приведенном мной выше Logtalk есть и ООП, и даже «event-driven programming», то есть по теории всё «как в GML», только синтаксис другой.

Вот тебе пример исходников игры с игровой логикой написанной на Logtalk. Вывод — декларативной логикой можно описать игровую логику. Принципиальной разницы между реалтаймом и походовым хождением в текстовой строке нет — нужно всего лишь технически добиться запуска процедур, обрабатывающих один шаг, 30, 50 или там 60 раз в секунду. Ты, я думаю, это прекрасно знаешь.

Эта игра, кстати, древний прародитель нашей с Эсдиром (а потом и Дрейком) игры Castle of no Escape. И соответственно также Замка Лейгрефа - игры, от которой я отталкивался при создании.

Hrenzerg
Вот это уже другой разговор. Погляжу, поразбираюсь.
buntarsky
Вот тебе пример исходников игры с игровой логикой написанной на Logtalk. Вывод — декларативной логикой можно описать игровую логику.
Декларативной логики в этом примере ра, два и обчелся. Остальное — императивная процедурная, косящая под декларативную.
Xitilon
Я не обращал на это внимания в данном случае. Впрочем, пример не единственный — намного больше хотелось бы услышать критику по Frag'у.
buntarsky
Я нахожу что возможно, и для доказательства не обязательно делать это на практике. На практике это много дурной работы, а я не настолько нерд.
Верно мыслите, на Prolog-е гораздо проще написать доказательство возможности написания на нем 3Д-шутера, нежели собственно сам 3Д-шутер. Так за чем же дело встало?
Xitilon
Построенная модель скорее всего окажется недостаточно точной для Хейзера, а потом окажется, что без практики это всё равно ничего не значит.
buntarsky
В комментариях вы строите эту же (недостаточно точную) модель, но только на русском языке, совершенного для того не предназначенном. Сизифов труд.
Xitilon
Я уже в общем-то закончил. В Прологе он будет не менее Сизифов.
Yuuri
Сошлись мы тогда на том, что если я создам 3Д-шутер на декларативном ЯП

Ты путаешь декларативные и предметные языки (DSL), которые заточены на какую-то предметную область, вроде тех же запросов. Большинство вторых являются первыми – потому что так действительно удобнее. Тем не менее, полно и декларативных языков общего назначения – и логических, как пролог (правда, они всё-таки узковаты), и особенно функциональных (хаскель, эрланг, некоторые лиспы), на которых можно сделать как минимум всё то же, что и на каких-нибудь C++ или Java.

Xitilon
Что тут значит «как минимум»? И, если это правда, то новые возможности, выходящие за рамки «каких-нибудь C++ или Java», могут ли нам пригодиться в контексте геймдева?
iji
Скорее не «новые возможности», а «альтернативные», и более высокий уровень абстракции при программировании.
Hrenzerg

Могут. Одни «ленивые последовательности» чего только стоят. Ну да ладно.

Только вот загвоздка — «новые уровни абстракции» означает что если раньше исходиники на С++ были просто тяжело читаемые, то «новые уровни абстракции» превращают наш код в соврешенно сумасшедшую ахинею. Потом собирается толпа программистов и думает над тем как работает очередная закорючка

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

iji

Скорее дело в мышлении. Тяжело перестроиться, когда изучаешь функциональный язык после императивного.

соврешенно сумасшедшую ахинею.

О да, и все это для того, чтобы подружить императивность и функциональность. Одно функциональное реактивное программирование чего стоит. Про монады вообще молчу. Хотя при правильном подходе все выглядит прилично, вроде как.

Зато на этих «новых уровнях» становится очень весело.

Xitilon
О да, и все это для того, чтобы подружить императивность и функциональность. Одно функциональное реактивное программирование чего стоит. Про монады вообще молчу. Хотя при правильном подходе все выглядит прилично, вроде как.Зато на этих «новых уровнях» становится очень весело.

Честно пытался понять что-то из этого.

Нет, это за гранью добра и зла. Особенно про moeb-loeb.

Yuuri
«новые уровни абстракции» означает что если раньше исходиники на C++ были просто тяжело читаемые, то «новые уровни абстракции» превращают наш код в соврешенно сумасшедшую ахинею

Ндык пиши на ассемблере, там никаких сумасшедших абстракций. Алсо, тот же хаскель гораздо проще C++.

но количество скрытого смысла не единицу языка растёт экспоненциально при этом

Даже если это правда ([citation needed]), тащемта вся прелесть в том, что влазить в этот скрытый смысл не нужно, на то они и абстракции.
Hrenzerg

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

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

Yuuri

А функциональные языки слишком далёки от естественного мышления.

ВСЕ языки программирования далеки от естественного мышления. Можно подумать, императивные ближе, с их-то микроменеджментом.

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

А что, ты каждый раз следишь, во что превращается твой код, чтобы понимать, как оно работает?
Разумеется, тут соглашусь, что понимать абстракции важно, но понять их достаточно один раз, а дальше спокойно применять, а разбираться только в тех редких (если абстракция хорошая) случаях, когда они начинают течь. И тут функциональные абстракции ничуть не хуже, чем любые другие.

Hrenzerg

Ну вообще-то ООП концепция для того и создавалась чтобы быть ближе к естественному мышлению. Люди оперируют образами. Классы и есть эти образы.

Xitilon
Люди не оперируют инкапсулированными полями и образы не читают один другой. ООП сложней чем то что ты говоришь, а для описания образов достаточно обычных структур данных. Собственно, 99% нубов используют классы ООП в качестве структур данных для хранения Person.Name, и все методы у них public static, потому что много чего в ООП избыточно.
buntarsky
Можно подумать, императивные ближе, с их-то микроменеджментом.
Конечно. Императивные языки на порядок ближе к естественному мышлению. Естественному для программирования машины, обрабатывающей информацию императивным способом.
Yuuri
Ещё раз говорю, прогайте на ассемблере тогда, ведь это естественно для машины.
buntarsky
Ещё раз говорю, прогайте на ассемблере тогда, ведь это естественно для машины.
Доводите до абсурда.
ООП — это парадигма близкая как человеку, мыслящему в предметах того, что «осязает» — объектов и их свойств, так и машине, как не сложная в понимании абстракция над процедурным. Эта взаимная «близость», золотая середина, и определила ее популярность.
Функциональная парадигма — это не просто на один уровень абстракции выше, это еще и смена парадигмы на такую, что не понятна ни человеку, мыслящему императивно, от задачи, ни машине, «мыслящей» императивно в силу природы ее создания императивно мыслящим человеком. То есть применима в задачах, императивным путем не решаемых (экспертные системы, математический анализ). Но в задачах, легко алгоритмизируемых человеком, она превращается в интуитивно не понятный ребус.
iji

По моему мнению, нет градации «хороший\плохой», есть «удобный\неудобный».

Мне очень нравится Хаскелл, стараюсь прикладные задачи (не игры), реализовывать на нем. Когда перестроишь свое мышление, становится очень удобно программировать. И да, он дает множество новых способов более элегантно решить старые проблемы.

Но возникает другая проблема: удобность сред разработки и документации. Здесь C# и прочая уделывают все ФП вместе взятое. Попробуйте под Windows настроить Gtk для Haskell и написать пример интерфейса! После копания в кучах устаревших мануалов находишь пару строк актуальных примеров.

А для того же C# в Unity есть автодополнение, рефакторинг, и самое главное — актуальный и подробный мануал.

В итоге, при разработке более серьезных проектов (того же 3D) Хаскелл остается уделом посвященных. Но, повторюсь, лишь из-за скудности документации и отсутствия внятной среды разработки.

 

Не надо забывать еще про фреймворки над языком. Меня не хватило на платформер на Love2D, например.

Hrenzerg

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

В итоге, при разработке более серьезных проектов (того же 3D) Хаскелл остается уделом посвященных. Но лишь из-за скудности документации и отсутствия внятной среды разработки.

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

Вот, допустим есть Javascript, на котором можно писать в функциональном стиле. Этот язык используется в Unity. Вот и вопрос — почему именно он, а не Haskell или Lisp?

iji
Помимо причины «все так сложилось само по себе, в течение истории» (как споры windows vs linux, game maker vs multimedia fusion и т. п.), единственное, что на ум приходит, —
Хороший язык — тот который близок к естественному мышлению.

В этом я с тобой согласен.

Но если бы на заре программирования все повернулось в сторону функционального программирования, я уверен, мы бы сейчас сидели в UnityFP и Gλme Mλker. Но это уже к первому варианту.

Yuuri

Извини, но ты не разбираешься в том, что пишешь.
1. Нет языка Lisp, есть целое большое семейство лиспов, похожих синтаксически, но разных семантически. Первый LISP был в 1960-м. Common Lisp, который нынче чаще всего подразумевают под лиспом, таки ровесник C++.

2. Лиспы не функциональные, точнее, не эксклюзивно функциональные, как хаскель. Они поддерживают ФП, но ровно как и все прочие парадигмы. Сильнее всего на нём акцентируется весьма молодой Clojure.

3. Точно так же, лиспы и объектно-ориентированные. CLOS, Common Lisp Object System – возможно, самая мощная ООП-система эвар.

4. Если ты не знаешь про IDE, это не значит, что их нет. Для CL есть коммерческие LispWorks и Allegro, есть Emacs+Slime (бывалые лисперы говорят, что традиционные IDE и рядом не стояли, не знаю, не пользовался).

5. Про выбор человечеством – почему оно также выбрало джаву, PHP, Одноклассников, органик-еду и Дом-2? Тому есть множество причин, и качество и полезность продукта – далеко не первая из них.

iji

А ты пользовался этими IDE?

К сожалению, в случае с Haskell не все так гладко. Решил писать не в Notepad++, зашел в нет: «Ого, как много разных IDE! Попробую-ка самую рекомендуемую». (Это была EclipseFP) Через пару дней чистого программирования (вывод консольный) все относительно ок. Как я писал раньше, решил сделать интерфейс, нашел gtk3, начал подключать, и понеслось...

Библиотека требовала посторонних утилит и танцев с бубном (из 10 руководств в интернете по установке  - 9 устаревших), и на ее установку я потратил два дня. Что потом? Повисла IDE с концами.

Установил новую IDE (Leksah), та висла и просто так.

А, ну еще FP Complete, редактор которой работал (он встроен в веб-страницу), а серверы которой мне не отвечали и не давали сохранять проект.

Вернулся к Notepad++ и WinGHCi (интерпретатор под Windows, идет вместе с компилятором в сборке Haskell Platform). Интерфейс там еще не писал.

К чему я веду. Здесь Hrenzerg прав — все выглядит красиво со стороны. А подводных камней куча. Спор зашел до точки, когда нужна практика в подтверждение, а не только теория. А тут ты проигрываешь, как я понимаю.

Yuuri
Ты сейчас подменяешь предмет обсуждения. Хейзер в своём посте допустил несколько фактических ошибок про лисп, я их исправил. Всё. При чём тут чья-то практика?
iji
Ок, не в ту ветку. Я к спору «функциональное\императивное».
Hrenzerg

В том что я пишу — я разбираюсь, но не настолько глубоко насколько тебе бы хотелось это так. Сообщество программистов — это далеко не быдло, а люди в подавляющем большинстве сообразительные и с хорошим образованием, и ИМЕННО ОНИ выбрали те или иные пути развития сферы программирования. Поэтому эти аналогии совсем неуместны.

Ладно, если тебе не нравится пример с LISP-ом. Тогда возьём возлюбленный ваш Haskell. Историческая справка гласит что он появился в 1990 году. То есть 25 лет назад. Так что списывать на молодое сообщество смысла нету. А тот же JavaScript появился в 1995-ом.

Вопрос примено тот же: Почему в Unity использовали C#, непонятный и мало известный BooScript, Javascript, а не Haskell?

Я к чему всё это пишу то. Придерживаюсь мнения что эффективность разработки склоняет к выбору тех или иных средств  гораздо сильнее чем другие факторы. И если Хаскель за 25 лет не был выбран основным языком для разработки видеоигр — значит на то были причны и вряд ли они они кроются в отсутсвии документации и хорогих IDE. Если бы он был годен — это всё привалило бы само собой.

Xitilon

Да погоди ты про видеоигры, давай хотя бы просто про программы. Первые ведь частный случай вторых.

Я лично в жизни не видел ничего в работе ни одного университета, библиотеки и офиса где я был, что было бы написано на Хаскеле. Может, оно всё секретное? Не знаю. Я видел программы для работы с БД, написанные на Pick/BASIC. Видел TCL (не тот, а этот). Но никогда не Хаскель.

Мейнстримные серверные Джава-апплеты и прочее я не называю, это и так понятно.

Yuuri
Полагаю, у меня наберётся далеко не нулевое число знакомых, никогда в жизни не видевших игр, написанных на GM.
Xitilon
Увидеть их легко — открываешь ГеймДжолт, и всё, 9 3 из 10 на нём сделаны. А Хаскель?
Hrenzerg
В стиме давно уже тусуется целая пачка игр, написанная на GM. Hotline Miami, Risk Of rain, Valdis Story, Stealth Bastard, Super Crate Box и т.д…
Yuuri

Извини, имелось в виду «ты не разбираешься в теме, которую критикуешь», но ведь правда же.

Программисты – свободное небыдло… да, да, хотелось бы мне тоже так думать. (тут должна быть фотка типичного индусского кодера). Начинающие программисты ничего не выбирают, а берут что оказалось под рукой (какой-нибудь BASIC с ZX Spectrum) и чему их научили в школах (си, паскаль), а дальше десяток лет идут по проторенной дорожке, а потом говорят «Нам проще выучить джаваскрипт, чем хаскель, поэтому виноват хаскель».

Хотя… почему опять съехали с темы на детали, при чём тут вообще хаскель?! Это изначально академический язык с довольно специфичной семантикой, естественно, для игр он не оч. Речь была про декларативщину VS императивщину вообще. А основным языком для разработки видеоигр 25 лет были си и сиплюсплюс, которые вовсе не отличаются эффективностью разработки, и для которых ровно так же нет ни удобных игроIDE, ни даже редакторов формочек.

Hrenzerg

Ну так нчинающие программисты и не создают фрэймворков и других ЯП. Историю то творят люди толковые. Впрочем и это не аргумент если говорить о начинающих людях. Народ с удовольствием переучивается с прочих ЯП-ов на C# и Javascript чтобы срздавать игры на той же Unity. Эффективность разработки сильнее чего бы то ни было ещё.

Я считаю что если бы появился чел который бы сделал на хаскеле рилтаймовую стратегию за неделю, а затем появлился бы ещё один такой чел — народ бросился бы учить хаскель. Но такие чудеса происходят почему-то не с хаскелем, а с Unity и GameMaker.

То что программисты привязаны к одному и тому же языку — это уже несколько лет как миф. Всё больше и больше людей готовы изучать более эффективнын новые решения. Потому что это мир капитализма. Если твой конкурент проще и быстрее пишет программы на Хаскеле — значит и ты вскоре будешь писать на Хаскеле. А за тобой и другие господа. Какой смысл работать с менее эффективным инструментом себе в убыток?

 

Почему мы всё время съезжаем на Хаскель поясню. Мне очень не понравилась твоя агтитаця:

Ну есть множество полезных концепций, которые в традиционных языках выражаются через жопу или вообще никак. Вот например,традиционное «классовое» ООП, которым вы тут размахиваете, для описания игровых иерархий годится заметно хуже компонентных систем, которые делаются через трейты или мультиметоды (вот отличный пример на Scheme). Описывать  динамические и интерактивные системы, где всё течёт и всё меняется, на чистых языках вроде хаскеля может быть очень неудобно – если не знать, что там есть линзы, которые позволяют не только имитировать присвоение, но и вытворять штуки, которые императивщине и не снились. Ну и к тому же это не единственный подход – есть FRP, которое, кстати, активно применяется во вполне мейнстримном вебе.

Прозвучало как «нормальные люди давно делают игры на Хаскеле, а вы — быдло, до сих пор юзающее ООП». Так что вся моя агрессия направлена против этой мысли. Потому я и пытаюсь выяснить если это так, то где тому подтверждения на «историях успеха»? Я, как и большинство людей примитивно устроены по описанной мной выше схемы «Если твой конкурент проще и быстрее пишет программы на Хаскеле — значит и ты вскоре будешь писать на Хаскеле.»

Я пытаюсь выяснить «если это всё действительно так круто, давайте покажите мне как это круто работает на практике чтобы я мог пощупать». С Unity у меня так и было. Я в то время давно видел эту штуку, но тем что на нём было сделано не особо впечатлился. А потом я увидел игру Rochard и за полгода освоил новый инструмент.

А пока что я слышу только «Вы недостаточно умны чтобы всё это понять, чтобы понять всю крутизну этого подхода, понять что делать становится проще и быстрее». Разумеется, мне это не нравится. Да ещё и в некомпетентности обвиняют :C Если программисты на Хаскеле пытаются ТАК замотивировать программистов начать осваивать новые абстракции… Как это не очень метод, не находите?

Hrenzerg

Если твой конкурент проще и быстрее пишет программы на Хаскеле — значит и ты вскоре будешь писать на Хаскеле. А за тобой и другие господа. Какой смысл работать с менее эффективным инструментом себе в убыток?

Здесь ещё поясню. Имеется ввиду и сфера деятельности. Я уверен что есть некоторая сфера в которой такое с хаскелем произошло. Кто-то увидел что задача решается им хорошо и аналогичные задачи начали решать им. Но в мире игр такой революции не было. Но согласно той цитате про размахивание ООП выходит что она была эта революция, а её все пропустили, так что ли?

Xitilon
По-моему Юрри про игры на Хаскеле вообще не задвигал никаких телег, что-то тут за уши уже притащено.
Hrenzerg

Может быть. Но мне показалось, что имело место следующее:

1) Юрри увидел как мы тут «на ООП делаем игры»
2) Он сказанул типа «Зачем вам для игр ООП, когда есть крутые компонентные системы? Да и тут ещё на хаскеле можно много чего сделать». Правда непонятно Хаскель последовал просто за компанию или действительно в контексте разработки игр. Но я воспринял как второй вариант.
3) Тема набухла комментами под напором моей ярости.

Yuuri

Эм.
Ксит спросил «новые возможности, выходящие за рамки «каких-нибудь C++ или Java», могут ли нам пригодиться в контексте геймдева?», я привёл несколько разнообразных примеров из разных языков, из которых хаскель-специфик ровно один, и из этого вдруг следует, что я пропагандирую его для геймдева? Ну извините.

Hrenzerg

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

1) Я сурово вопрошаю «Кто посмел эффективно делать игры на Хаскеле? Быстро показали мне как вы это делаете!»

Далее два варианта:

2.а) Мне быстро приводят живой пример или историю успеха или рецепт из трёх пунктов. Я затыкаюсь и иду изучать материалы.
2.б) Мне говорят «ну вообще никто на Хаскеле игры делать не собирался — не годится он для этого». Тогда я тоже затыкаюсь, но уже просто так — на правах победителя.

Но нет. Мне начали рассказывать что я ничего не понимаю. Что я к тому же ограничен интеллектуально. И что вообще я не в теме.

Yuuri
Мне начали рассказывать что я ничего не понимаю. Что я к тому же ограничен интеллектуально

[citation needed]

Xitilon
Давайте ближе к теме, что ли. Пора заканчивать этот балаган и делать игры наконец.
Hrenzerg

Наздоровье. Мне не лень скопировать.

Извини, но ты не разбираешься в том, что пишешь.

См. «Blub paradox» и «Golden hammer».

Xitilon
«Golder hammer» это более-менее про меня. Вот Хейзер действительно может достать из-за пояса серебряный, бронзовый, и даже платиновый молоток. Которыми обычно, правда, ничего не делает. 
Xitilon

Ты, конечно, разбираешься в теме, но пункты 1-3 тут полезного ничего не привнесли, хоть и являются занимательной исторической справкой — в этой ветке речи про ООП не идёт, она идёт про выбор большинства / типа эволюцию (о чём тут пункт 5).

По пункту 4 — вопрос был, почему соответствующие IDE не распространены, а не почему их нет.

А что за органик-еда?

buntarsky
Среды, документация и поддержка платформ — важный фактор в игровой индустрии, т.к. обеспечивают скорость разработки и распространение проукта.

В игровой индустрии главный фактор — производительность (если мы говорим о ААА). То есть качественная графика и физика, но не ценой количества поддерживаемых машин. Тут функциональные языки проигрывают в сухую.
Помимо этого, игра — прежде всего взаимодействие с пользователем, то есть опять мимо функциональных языков с их «чистотой» и костылями для ее обхода.

Каждому делу свой инструмент.

Yuuri

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

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

Hrenzerg

С другой стороны, нынче не девяностые, компы уже совсем другие, и игры активно делают на managed-платформах, с которыми нативно компилируемая функциональщина вполне сравнима по скорости (даже ленивый хаскель, но там надо быть очень внимательным), а про скриптовые штуки и веб я вообще молчу.

А я всё думал-гадал зачем смартфоны с 6Гб оперативки выпускать:

(Новость о 6 ГБ RAM в смартфонах Samsung)
xxx: Зачем там столько оперативки? ЗАЧЕМ?! Смысл? Что там, серверную ОС катать будут? Или, может, зоопарк виртуалок?
yyy: Там будет сервер 1С.

Но я теперь точно уверен что там будут запускать программы написанные на функциональных языках… Возможно, даже игры!

Yuuri
Вах, зачэм функционалных, там и сейчас джава неплохо всё сжирает.
Yuuri

Ну есть множество полезных концепций, которые в традиционных языках выражаются через жопу или вообще никак. Вот например, традиционное «классовое» ООП, которым вы тут размахиваете, для описания игровых иерархий годится заметно хуже компонентных систем, которые делаются через трейты или мультиметоды (вот отличный пример на Scheme). Описывать  динамические и интерактивные системы, где всё течёт и всё меняется, на чистых языках вроде хаскеля может быть очень неудобно – если не знать, что там есть линзы, которые позволяют не только имитировать присвоение, но и вытворять штуки, которые императивщине и не снились. Ну и к тому же это не единственный подход – есть FRP, которое, кстати, активно применяется во вполне мейнстримном вебе.

Это я уже не говорю о маленьких штучках вроде foreach, лямбд, LINQ или даже монад, которые облегчают жизнь, будучи встроенными в любой язык, и которыми вы все активно пользуетесь, даже если не осознаёте, что за ними скрывается.

P.S. Я всегда буду обновлять страницу перед отправкой комментария… >_<

Hrenzerg

Предположим… И сколько игр ты на Хаскеле написал?

А вообще вот такой вот вопрос

Если какая-то концепция лучше подходит для тех или иных задач то почему все продолжают писать на размахиваемом в треде ООП?

Yuuri

Миллионы мух не могут ошибаться, да?

И сколько игр ты на Хаскеле написал?

Три, а что? А сколько игр ты написал на C++/C#/Java?

P.S. Я игры вообще теперь почти не делаю. Прочего кода на хаскеле я написал довольно много, он рулит.

Hrenzerg

Причём здесь мухи? Раз ты писал на Хаскеле и, видимо, действительно применял всё что ты описал в том своём посте интересно выяснить под «годится» понимается что? Просто удобство описания? Или удобство пихания кода интерпретатору без дополнительных приседаний? Или всё-таки оно реально ускоряет работу над проектом?

Какя либо концепция может быть очень годной теретически, выходит что всё так складн оскладывается и должно быстро работать и всё такое. Но сколько сил при этом уходит на это? Сколько сил уходит на то чтобы эту концепцию понять? Сила ООП подхода в том, что он очень близок к реальной жизни и естественному мышлению. И программисту, который такой подход применяет не нужно затрачивать усилий, на то, чтобы перевести логику естественного мышления на «новые уровни абстракции». В этом и суть изначального обсуждения.

А сколько игр ты написал на C++/C#/Java?

К сожалению, С++/С#/Java — имеют слишком низкоуровневые для меня IDE. Поэтому я создал более 20 игр на GML в среде Game Maker, который, впрочем, тоже ООП. Поэтому мне совершенно плевать на новые уровни абстракции. Я то игры делаю, а не хернёй страдаю. GML содержит всё что нужно для реализации моих творческих идей, а что ещё для счастья надо то?

Yuuri
Сила ООП подхода в том, что он очень близок к реальной жизни и естественному мышлению.
GML содержит всё что нужно для реализации моих творческих идейа

См. «Blub paradox» и «Golden hammer».

К сожалению, С++/С#/Java — имеют слишком низкоуровневые для меня IDE.

Ну то есть, им опять-таки недостаёт нужных абстракций, amirite? Но тогда беседа не о «императивные языки лучше подходят для создания игр», а «языки, заточенные под создание игр, лучше подходят для создания игр», слава Кэпу. Что, кстати, лишний раз доказывает пользу DSL.

Hrenzerg

Я практик, а не теоретик. В том плане что, я делаю игры, а не рассуждаю на тему «как делать игры лучше и проще» =)

О! давай так. В декабре будет лудум. Я пишу игру за два дня на GML, а ты — на Haskell. Вот и проверим НА ПРАКТИКЕ какая парадигма круче, ок?

Ну то есть, им опять-таки недостаёт нужных абстракций, amirite?

Дело не в абстракциях, а в переизбытке рутины. IDE должна автоматизировать процессы разработки, а не усложнять.

Но тогда беседа не о «императивные языки лучше подходят для создания игр», а «языки, заточенные под создание игр, лучше подходят для создания игр», слава Кэпу.

Вообще беседа была о «А что, есть парадигмы которые позволяют проще и быстрее создавать игры?». По крайней мере такую телегу задвигает Кситилон, дескать на прологе то создавать даже легче чем на чём либо ещё.

Yuuri
В том плане что, я делаю игры, а не рассуждаю на тему «как делать игры лучше и проще» =)

То есть ты даже и не пытаешься искать, можно ли делать лучше и проще? Окей.

Дело не в абстракциях, а в переизбытке рутины.

 

… который решается введением абстракций. Ресурсы, объекты, эвенты и прочее в GM – это самые что ни на есть абстракции. Именно они облегчают жизнь, а не GML, на месте которого могло быть что угодно.

Я пишу игру за два дня на GML, а ты — на Haskell. Вот и проверим НА ПРАКТИКЕ какая парадигма круче, ок?

Ок! Если мы сравниваем парадигмы, а не инструменты, то ты пишешь на GML без GM. Иначе это сравнение тёплого с мягким.

Xitilon
То есть ты даже и не пытаешься искать, можно ли делать лучше и проще? Окей.

Ну ты как будто в первый раз с этим сталкиваешься. Аргумент очень простой — это слишком затратно.

Что до написания игры на GML без GM, то это тоже мимо — вся внутренняя часть GM XD (то что обеспечивает внутри игры работу всего того что можно накликать и написать в форме написанной на C#) - напечатана мной в обычном Блокноте.

Вы не можете ничего адекватно сопоставить на уровне парадигм из такого положения. По крайней мере такими странными мерами.

Впрочем, если ты имел в виду не использовать ни компилятор, ни раннер GM, которые легче написать на Хаскеле, то ты находишься в некоем выигрыше — но это не называется «писать игру».

Hrenzerg

Я в этом треде и перетираю как раз потому что пытаюсь искать что лучше и проще. В Game Maker я фактически жму на волшебные кнопки «сделайте мне охуенно» и мне делают охуенно. В прологе, выясняется, что непонятно как описывать игровую логику. А для Haskell, оказывается, нету нормальной IDE и документации. Выходит что я пока не могу найти лучшего решения. Я пробовал Unity и умею и в нём (создал пяток игр) — хорошая штука для 3Д игр. Я пробовал Stencyl который не способен переваривать столкновения. Я пробовал и флеш с IDE flashdevelop, которая не отличается особо от самых разных виденных мною ранее IDE в которых нету нормальной системы организации игровых ресурсов. UT3 не пробовал, но учитывая что рабочее на них могут осилить разве что команды разработчиков — решил что пока не стоит.

По сути и выходит пока что, что эффективно разрабатывать игры у меня выходит только с GameMaker и Unity. А Ludum Dare и позволяет мне проверить эффективность разработки. Если я могу при помощи инструмента воплотить свою задумку за два дня — значит инструмент эффективный.

который решается введением абстракций. Ресурсы, объекты, эвенты и прочее в GM – это самые что ни на есть абстракции.

Ты не прав. В GML ровно столько же абстракций(даже меньше) чем в тех же C++, C#. Преимущество именно в IDE, которая позволяет быстрее манипулировать частями проектов. Если там и появляются какие-то абстракции то они никак не относятся к программированию.

Ок! Если мы сравниваем парадигмы, а не инструменты, то ты пишешь на GML без GM. Иначе это сравнение тёплого с мягким.

С чего это? А ты тоже готов писать на Haskell без интерпретатора Haskell, так что ли? GM — это интерпретатор GML + фрэймворк. Ко всему прочему как раз в GM я и занимаюсь чисто ООП парадигмой — как раз то что нужно ТЕБЕ. Я создаю классы и наследую друг от друга, использую базовый полиморфизм, я назначаю им события и описываю взаимодействие объектов друг с другом. Если твоя парадигма вынуждена работать с кодом напрямую — это уже чисто твои проблемы, и к слову, не свидетельствующие о том, что функциональное программирование так уж годно для разработки игр.

Xitilon

Я пробовал Stencyl который не способен переваривать столкновения.

Кстати я тоже пробовал — лажа была, но это было давно. У тебя за какой год тест?

В GML абстракций больше, но их не обязательно знать. (проклятье, мы ходим по кругу с одинаковыми аргументами в каждую из рассматриваемых сторон)

Преимущество именно в IDE

Не согласен совершенно. Главное преимущество в интерпретирующем на лету движке, но оно было безнадёжно про… утрачено с переходом на Студию. После этого без IDE уже работать стало невозможно, и поэтому без него задница. Второе главное преимущество в ограниченном мета-программировании — можно собирать объекты на лету из ничего. Но и это в Студии уже не существует.

По-моему Юрри считает что его кунг-фу круче у него ООП лучше, так как там есть множественное наследование, миксины и ещё много всяких свистелок.

Отсутствие множественного наследования в ГМ меня раздражает уже долго время, и поэтому я придумал скрипты, которые собирают объект из нескольких прото-объектов, совмещая их события. Я придумал систему макросов-подстановок, чтобы ре-юзать участки одинакового кода. А потом это всё просрали.

Ладно, это я так.

Hrenzerg

Не согласен совершенно. Главное преимущество в...

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

Я то имел в виду преимущество именно этой IDE перед традиционными IDE для написания кода, которые пытаются выставляться «бывалыми программистами» в качестве полноценной IDE для разработки игр. По крайней мере в случае со всякими MVS, Flashdevelop, Eclipse, Netbeans и прочими которые заточены под написание кода а не разработки. Моя мораль в том что IDE для разработке игры должна обеспечивать не только удобство работы с кодом но и со всеми игровыми ресурсами и игровой логикой, игровым пространством и т.д. IDE типа GameMaker, Stencyl, Unity обладают этими качествами и тем самым выигрывают в эффективности разработки.

Xitilon
которого нет у старой среды GM

Наоборот — у старой есть, а у новой нет. Я, считай, сам дописал IDE, а с приходом Студии на ней это всё стало бесполезным. Не потому что там есть такое же — да я был бы рад этому невероятно — а потому что отвалился интерпретатор. Так что это прямым образом затрагивает мою методологию разработки именно игр.

А ты говоришь насчёт того что GM это не компилятор-переросток с подсказками кода (которых там почти нет), а инструмент для сборки продукта по конкретным частям, рабочий станок. Тут нечего добавить, это отлично, эффективность от этого выше, и аналога для Хаскеля или Пролога такого не существует.

Yuuri

Вот, и тебе не хватило возможностей конвенционального ООП, предоставляемых GM.

Главное преимущество в интерпретирующем на лету движке.

Преимущество?! Это не преимущество, это источник бесконечных тормозов. То, что его местами можно было использовать для расширения возможностей языка – не преимущество, а костыль.

Xitilon

Ну чего ты опять разжигаешь. Ты эти «бесконечные» тормоза в глаза видел? Я до сих пор использую все эти модули, потому что с ними я могу в пару кликов и десяток замен в коде переделать всё с управления клавиатурой на управление клавиатурой или джойстиком. И любыми кнопками при этом, всё кастомно. Пример не голый, а проверенный на практике, так работает и управляется Castle of no Escape.

И работает оно так:

to_execute+=«input[»+string(cmd)+"]|=keyboard_check("+ctrl_check[cmd,ctrl]+")"
to_execute+=«input[»+string(cmd)+"]|=(joystick_direction(1)="+ctrl_check_argument[cmd,ctrl]+")"
и так далее
execute_string(to_execute)

Каждый кадр, 60 раз в секунду.

А костыль или не костыль — это своей бабушке можно рассказывать.

Ещё немного подпилю, и будет автоматическая запись действий игрока прямо с потока управления. Я уже там и RLE-сжатие закодил.

pevzi
to_execute+=«input[»+string(cmd)+"]|=keyboard_check("+ctrl_check[cmd,ctrl]+")"
to_execute+=«input[»+string(cmd)+"]|=(joystick_direction(1)="+ctrl_check_argument[cmd,ctrl]+")"
Кошмар какой-то.
Xitilon

Кавычки-ёлочки это Коленка ставит, если что.

Так работает же. Один раз написал, и работает. Причём это в разы более читаемо для меня, чем Хаскель тот же.

pevzi
Кавычки-ёлочки это Коленка ставит, если что.
Не, это-то ясно. Я про то, что это в целом нечитабельно и трудноподдерживаемо, к тому же без пробелов между лексемами, что еще больше усугубляет. Да и вообще, неужели нельзя было решить задачу… изящнее? Как-нибудь без execute_string.
Причём это в разы более читаемо для меня, чем Хаскель тот же.
Ну, Хаскель вообще не эталон в данном случае
Xitilon
Это как раз весьма изящное решение - управление можно перенастраивать в любой момент, соответственно исполняемый код должен быть каждый раз разным. Строки транслируются прямо из инициализации в исполняемый код. Если я что-то упрощу, потеряется гибкость.
Xitilon
не рассуждаю на тему «как делать игры лучше и проще»

Замечу, что обсуждение было — можно ли делать игры «в декларативной парадигме» вообще. Плавно перешедшее в «как лучше писать программы».

На практике же ты проверишь, кто лучше владеет разработкой игр, а не какая парадигма лучше. Учитывая, что Юрри делает игры редко и мало, это странная затея.

iji
«Blub paradox» здесь неуместен. Либо ты Пол Грэм, либо у тебя есть аналог Game Maker для Lisp/Haskell/т.п.
Yuuri
Либо у вас есть аналог Game Maker для C++ и Java, либо императивщина тут всё-таки не при чём и парадокс очень даже уместен.
iji
Речь-то про ООП в GameMaker.
Yuuri
Если то, что есть в GameMaker, вы называете ООП, то в C и Haskell тоже есть ООП.
Xitilon

GML это скриптовый язык для движка написанного на Delphi, который, как мы все знаем, является Паскалем с прикрученным к нему ООП.

Впрочем, о чём это я. Поведай мне тогда, какой именно фичи из ООП в GML нету.

Yuuri

Проблема с ООП в том, что никто не знает, что же это такое.
Ну окей. Если брать мейнстрим, то и симулоподобное (C++, Java и иже с ними), и смоллтокоподобное (ObjectiveC, Ruby), и прототипное (Javascript), например, позволяют добавлять произвольные методы к объекту/классу, в отличие от.

Ещё очень доставляет, что ресурсы и встроенные структуры данных в GML не объекты нихрена, из-за чего приходится городить зоопарк глобальных функций с весёлыми префиксами.

Hrenzerg

Что значит не знает?

ООП — это инкапсуляция, наследование, полиморфизм по классическому же определению. В универе говорили что там ещё что-то есть но я уже не помню… Абстракция, кажется.

Yuuri

И это ты называешь определением? Это даже не необходимо-достаточный список.

В джаваскрипте нет наследования. ООП там есть.

В го и расте нет наследования. ООП там тоже есть, но не такое, как в JS.

В хаскеле есть и инкапсуляция, и наследование, и полиморфизм. ООП там нет, потому что это не то наследование и не тот полиморфизм.

Ни в одном из динамических ОО-языков нет той половинки инкапсуляции, которая ответственна за сокрытие (по одному из определений).

Определением скорее могло быть что-то вроде «представление данных в виде объектов со внутренним состоянием, и потока выполнения в виде пересылки сообщения между объектами, меняющими их состояние», под которое действительно все вышеуказанные (кроме хаскеля) подпадают, но оно какое-то слишком мутное.

Xitilon

Так ты сам не можешь привести определение. Чего махать-то руками?

Я знаю то же что и Хейзер, потому что наличие или отсутствие ООП для меня глубоко вторично, в отличие от нужды мыслить «математическими категориями». Пролог я ещё понимаю. Хаскель — извините.

Yuuri
Так ты сам не можешь привести определение.
Так я сразу сказал – никто точно не знает, что это такое. В разных языках есть разные и иногда противоречащие друг другу наборы фич, но их всех почему-то зовут ООП. Это как с определением Бога в религиях.
Xitilon
Ладно.
Hrenzerg

В джаваскрипте нет наследования. ООП там есть.

Как -то не очень убедительно. Или я чего-то не понимаю.

В хаскеле есть и инкапсуляция, и наследование, и полиморфизм. ООП там нет, потому что это не то наследование и не тот полиморфизм.

Не приходило в голову что если там «не то наследование» и «не тот полиморфизм» — значит это и не наследование и не полиморфизм вовсе, а разработчики Хаскеля просто поленились придумать для этого новые слова, внося тем самым путаницу во всю и вся? Наследование, покрайней мере, это не тот термин, который мог б вызвать трудности трактовки. По-моему он совершенно однозначно говорит о том что должен говорить. Вот с полиморфизмом сложнее, да.

Xitilon

Как -то не очень убедительно. Или я чего-то не понимаю.

inb4: там нет какого-нибудь «нативного» наследования, а это костыль.

Yuuri
Или я чего-то не понимаю.
Например, то, что там нет классов? (по крайней мере, до версии ES6) А если нет классов – что же наследуется в классическом смысле? А если не в классическом – то кто-то поленился придумать для этого новые слова, внося тем самым путаницу?
Hrenzerg

Так это и не я говорил, что в javascript есть ООП =)

Или ты тоже не понимаешь того, о чём пишешь, а?

Yuuri

*facepaw*

Ты говорил, что ООП – это «инкапсуляция, наследование, полиморфизм». Подучи матчасть уже, чтобы убедиться, что традиционного наследования в JS, Go и Rust нет, а ООП есть, а сл-но, либо неверно твоё определение, либо оно требует расширения некоторых понятий, но тогда под него начинают подпадать не-ОО-языки. Ну или разверни свои определения, чтобы уточнить, что имел в виду.

Hrenzerg

Пфф. А откуда ты тогда взял что там есть ООП? Может быть там опять же есть что-то другое, что ты и кто-то ещё называет ООП, но это не ООП по факту? Какой смысл вообще вводить какие-то опредления, если они имеют неоднозначную трактовку?

Зачем вот так делать:

хммм, вот это похоже на ООП — тогда напишем в спецификации, что язык поддерживает ООП.

И всё только ради того чтобы потом где-нибудь сказать

Проблема с ООП в том, что никто не знает, что же это такое.

Это даже не смешно. Это глупо. Мне вот насрать на все эти околотемы. Мне достаточно классического определения с инкапсюляцией, наследованием и полиморфизомом. Есть это в языке — значит он поддерживает ООП парадигму. Нету — значит не поддерживает, а все эти выебоны на тему «Оно там как бы есть, но как бы его нет потому что наследование там — не такое наследование и вообще...» — можете засунуть себе в задницу и прокрутить. Программирование — это формальная логика на формальных языках, а не какие-то непонятные пвседо-мета-рассуждения.

pevzi
Мне достаточно классического определения с инкапсюляцией, наследованием и полиморфизомом

А кто сказал, что именно оно «классическое»? Мне вот например нравится определение из википедии:

Object-oriented programming (OOP) is a programming paradigm based on the concept of «objects», which are data structures that contain data, in the form of fields, often known as attributes; and code, in the form of procedures, often known as methods. A distinguishing feature of objects is that an object's procedures can access and often modify the data fields of the object with which they are associated (objects have a notion of «this» or «self»).

Какие-то другие особенности (инкапсуляция, наследование, классы, прототипы, примеси и т.д.) — это уже дело конкретных языков.

Xitilon
Кстати мне оно тоже нравится. Тогда действительно, зачем классы, если можно наследовать поля и методы объектов?
pevzi
В прототипно-ориентированных языках (типа JS или Lua) так и делают.
Yuuri

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

А так он вполне имеет право на жизнь, как справедливо заметил pevzi выше.

Hrenzerg

Аналог Game Maker для C# и Javascript — это Unity. И с этой средой я тоже периодически работаю. Она выигрывает по удоству разработки у GM, но из рук вон плохо работает с 2D. А я делаю в основном именно 2D игры — потому и выбрал Game Maker.

Аналог Game Maker для AS3 — это Stencyl. И с этой средой я работал. Очень тормозной выхлоп получается.

Что касается попытки преодолеть ограничения инструмента — я пытался делать игры на фрэймворке AS. На практике же (заметь, я проверяю на практике) у меня это заняло больше времени чем разработка ТОЧНО ТОГО же на Stencyl. Причина — лучшая организация ресурсов и экономия времени на написание однообразного кода, который создаётся автоматом в нормальной IDE за один клик. Значит я нашёл более эффективный инструмент.

Так что парадокс нихрена неуместен =)

Yuuri
Ты читать умеешь? Я просил для C++ и Java. Какие тут C# и JS, на плюсах [и их подмножестве], наверное, написано больше игр, чем на всех остальных языках вместе взятых, по крайней мере если не считать мобильные платформы.
Xitilon
Я что-то потерял нить дискуссии. Если будет приведен «Гейм Мейкер для C++/Java», что это докажет или опровергнет тут?
Hrenzerg
А какая разница? Разве суть спора не в существовании альтернативных решений для других языков?
Xitilon
Я не знаю, куда суть спора зашла в этой ветке, но интересно, как вообще был осуществлён этот смысловой переход. Если бы даже сейчас и был приведен ГМ для C++/Java, очевидно, что его почти никто не использует. Что бы это означало?
Xitilon

«Blub paradox»

«Парадокс Блаба» состоит в том, что программист, знающий некоторый язык (для него Грэм и вводит условное наименование «Блаб»), как правило, хорошо понимает, чем Блаб лучше, чем любой менее мощный язык, поскольку в состоянии назвать механизмы, имеющиеся в Блабе и отсутствующие в менее мощных языках и понимает, как именно эти механизмы облегчают программирование. В то же время он не в состоянии заметить разницу между Блабом и более мощными языками, поскольку «думает на Блабе» — решение любой задачи автоматически представляет на Блабе, естественно, ограничиваясь теми средствами, которые в Блабе есть. Имеющиеся в более мощном языке дополнительные средства в его глазах ничего не стоят, так как он не умеет их применять и, естественно, не понимает, что они облегчат ему жизнь. И лишь когда программист по каким-то причинам изучит более мощный язык, он получит возможность смотреть на Блаб «сверху вниз» и видеть его ограниченность. Ссылки на «Парадокс Блаба» можно нередко встретить в Интернете, в особенности — на ресурсах, посвящённых обсуждению новых и ограниченно популярных языков и механизмов программирования.

«Golden hammer»

Золото́й молото́к (англ. Golden hammer) — анти-паттерн проектирования, заключающийся в использовании одного и того же решения везде.

Но вообще хорошим тоном было бы приводить свои аргументы напрямую. Мало ли какая Википедия как описывает тот или иной термин. В английской версии пишут про золотой молоток, что «golden hammer[a] is an over-reliance on a familiar tool», что уже немного другая мысль, более близкая к текущему обсуждению.

iji
Хаскель — это как ламборджини в деревне. Немного подрочил — и пошел работать на тракторе. lurk
Hrenzerg

Вспомнилась цитата с баша:

с линуксорга

shimon:
Ага, нормальные люди пишут на сях, и у них все течет да сегфолтится, зато очень быстро.
А если поменять порядок копирования байтиков в memcpy(3) на обратный, то у них КРОВЬ КИШКИ РАСП-ДОРАСИЛО...

А вот нормальные люди, которые пишут на PHP. У них всегда все как-то работает, но никто не знает, что будет в пограничных случаях: возможно, сообщение будет отправлено случайному пользователю, возможно, на сервере закончится место. Что стрясется — не знает никто, но все делают вид, что все в порядке.

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

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

А еще есть нормальные люди, программы которых, по их словам, не глючат, не тормозят и потребляют отрицательное количество памяти, но они слишком заняты срачами на ЛОРе, чтобы показать хоть одно свое творение.

Xitilon

А если поменять порядок копирования байтиков в memcpy(3) на обратный

Один вопрос — кто в здравом уме будет это делать-то?..

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

Что-то я Некроса вспомнил (нет, про стартапы не знаю, скорее всего к нему не относится). Ну, вы знаете, о ком я, господа ММВшники.

программы которых, по их словам, не глючат, не тормозят и потребляют отрицательное количество памяти

Проиграл.

Yuuri

Один вопрос — кто в здравом уме будет это делать-то?..

У, это была целая былинная история.

Xitilon

Даже так.

Дичь.

Xitilon
но и вытворять штуки, которые императивщине и не снились
Что меня всегда выбешивает в подобных «игровых» примерах, так это то, что даже если код представляет из себя какую-то часть механики какой-то там игры, то ценности в реальной разработке игры он не имеет практически никакой. Так, солдатиков подвигать туда-сюда.
buntarsky
Вот например, традиционное «классовое» ООП, которым вы тут размахиваете, для описания игровых иерархий годится заметно хуже компонентных систем, которые делаются через трейты или мультиметоды.
Странное противопоставление ООП и ECS — его возможного частного случая.
Это я уже не говорю о маленьких штучках вроде foreach, лямбд, LINQ или даже монад, которые облегчают жизнь, будучи встроенными в любой язык, и которыми вы все активно пользуетесь, даже если не осознаёте, что за ними скрывается.
И что же за ними скрывается? Императивный код с чуть большей степенью абстракции, вестимо. А не то, на что вы так лукаво намекаете.
Yuuri
ООП – частный случай процедурного программирования, что не мешает их противопоставлять.
И что же за ними скрывается?

Зависит от реализации.

А не то, на что вы так лукаво намекаете.

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

Xitilon
Кстати, foreach на C# был мне бесполезен чуть более чем полностью. Везде, где, казалось бы, его удобно использовать, мне нужно было получить ту самую переменную цикла i… которой нет! Что ты на это скажешь, что сама программа должна быть построена без нужды использовать итератор вручную?
Hrenzerg
Ну вот не знаю как насчёт C#, а вот на PHP foreach — штука очень полезная.
qb60
нужно было получить ту самую переменную цикла i
А зачем? Кроме как для вывода на экран/в файл/куда либо ничего на ум не приходит.
Xitilon
В моём генераторе графики Tekx например повсеместно требуется работать не только с текущим элементом, но и с i-1, i+1, и вообще с array[8 * num8 + l]. Разумеется, с вводом/выводом в файлы и просто со строками я тоже постоянно работаю, и там очень часто важно смещение относительно некоей точки в массиве.
Yuuri

Опять это «чё-т я сомневаюсь в его полезности, мне ни разу не пригодилось».

Массивы – далеко не единственный вид коллекций, которые можно фурычить. Попробуй с i±1 обойти словарь, например. Вот в C++ для этого использовали пары итераторов, и выглядело монструозно, пока над ними range-based for не запилили, наконец.

P.S. Если у тебя эти соседние пиксели использовались для расчёта текущего, возможно, код бы упростился использованием матричных операций и сечений.

P.P.S. А итерироваться вручную действительно не стоит. Вот так это заполнение нового массива выглядело бы на хаски (и на любом другом языке с генераторами списков, хоть питоне; и на C# с LINQ это делается очень похоже):

newArray = [ Point (x + offX * sizeWidth) (x + offY * sizeHeight)
           | Point x y <- array, offX <- offsets, offY <- offsets ]
    where offsets = [-1, 0, 1]

P.P.P.S. Кстати, это наглядный пример превосходства декларативности – вместо длинной инструкции, как обойти массив и его заполнить, мы делаем кратенькое описание, что в нём должно лежать, а детали пусть компилятор решает.

Xitilon

Для словаря я использовал foreach, действительно. Использовал и забыл. Если словарь предполагается обходить только с этой конструкцией, чего её и запоминать-то.

Я не знаю что именно ты понимаешь под матричными операциями и сечениями. В смысле, я знаю как работают с матрицами, но куда это приткнуть тут — непонятно.

Это пример превосходства по длине кода, но мне лично не сильно понятно, что он делает. Точнее, понятно только потому что я писал тот код, с которого это взято. Какие именно детали тут решает компилятор, кстати?

Ах да. Производительность от этого ведь ещё может пострадать.

Yuuri

Насчёт матриц: вроде бы в подобных программах частенько бывают фрагменты типа «обойти все пиксели, взять у каждого левых и правых соседей пикселя, взять максимальную яркость, бла-бла», для чего действительно нужны i±1. Но часто эти операции можно выразить в виде короткого «взять сечение матрицы NxN, помножить на другую, сложить с третьей», и индексации тогда вообще не останется.

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

pevzi
обойти все пиксели, взять у каждого левых и правых соседей пикселя, взять максимальную яркость, бла-бла
Такое нужно вообще писать на GLSL.
Xitilon
Я не хочу отягощать свою программу на C# какими-то сторонними модулями.
Xitilon
«взять сечение матрицы NxN, помножить на другую, сложить с третьей»

Это в терминах математики. Сечение матрицы что-то плохо гуглится вообще в принципе.

Так вот да, порядок мне во многих случаях важен строго по очереди. Там где он не важен, я распараллеливаю свою программу сам, создавая M x N потоков. Согласен что там есть пространство для манёвра, но это только общая теория, опять же.

qb60

О матрицах свёртки идёт речь, по всей видимости. Или что-то типа того. 

Читаю тут на досуге книжку по этой теме, очень интересная, советую.

Xitilon
А, это. Статья конечно не фонтан, но да, я припоминаю такие штуки. В Tekx не используется ничего подобного, потому что это всё фильтры пост-обработки. Там есть некий Blur, но это глубоко вторичная часть программы, которую оттуда надо вообще выкинуть.
iji
А как вам QML и VPlay для него?
Xitilon
Для кого, 3Д-шутера? Кто знает, надо пробовать, что оно такое.
iji
Та часть, которой касался я — была про 2D. Но в блоге у них есть и про 3D.
Xitilon
В общем, пока что никак. Надо подробно рассматривать, чтобы сделать вывод. Пролог-то я уже видел в действии.
iji
Язык декларативный, есть фреймворк игровой, есть поддержка 3d (причем не из фреймворка, а из qml) — можно и пробовать.
qb60

Ну, на Хаскеле, например, 3D-шутан есть (там же неплохой документик по поводу программирования игр на функциональном языке).

Можт кто из разбирающихся в видах программирования подскажет, является ли Verilog декларативным языком?

Xitilon
для языка Verilog не применим термин «выполнение программы».

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

Выходит, игру как программу написать на нём нельзя. Но что-то вроде этого создать можно.

Класс языка: Язык описания аппаратуры

Типа как HTML для гипертекста, так это для железа.

mylittlekafka
Так будет игра или у вас чисто словесный спор?
Xitilon

Ну, спор у нас довольно важный, потому что упирается он примерно в следующее: зачем программировать императивно (C#, GML, остальное), если можно проще программировать декларативно (Пролог, Хаскель, что-то ещё)? Описывать игровые состояния может оказаться проще, если конечно упростить работу с синтаксисом и забыть о том что в исходной математической задаче это предикаты, а не объекты игровой логики.

А игра, если и будет, то не в ближайшее время. Пока это тяжёлая академическая тема.

Впрочем, выше есть исходный код другой игры, но чтобы её запустить, нужно качать интерпретатор Пролога, который надо отыскать в Гугле.

mylittlekafka
Скучно
Hrenzerg
А ты знал, что инвентарь в тёмном соусе написан на прологе?
Yuuri
Емнип, при разработке The Last of Us весьма активно использовался Racket (один из современных диалектов лиспа), на котором был реализован eDSL для описания игровых объектов, сценариев, локаций и т. д., а они потом кодогенерировались во что-то более машиноориентированное. Вот тут видео доклада есть.
Hrenzerg

Тогда уже спор может принять оборот «А действительно ли проще программировать игры декларативно?»

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

Xitilon
А чего спорить — и так понятно, что проще!
Hrenzerg

Ну так давай, программируй. Чего же ты ждёшь?

Займись делом тогда, а то что-то тут мямлишь «я не нерд», «много хлопот»...

 

Давай так — аналог квэйка к завтрешнему утру на прологе. Механика, один моб, одно ружие, обычные стены + тестовый уровень. С тебя ещё и редактор.

Xitilon
А с тебя — губозакатывательную машинку, для тебя же!
Hrenzerg

Ок. Только мне нужно знать для каких тебе целей. Для домашнего пользования или офиса.
От этого будет зависеть выбор модели — время работы, размер экрана, поддерживаемые форматы, qwerty клавиаутра в конце-концов! Это ведь очень ответственное дело!

А вообще уже утро. Гони аналог квэйка на прологе.

Xitilon

Да, а ещё лицензии на коммерческое её использование продаются с другим соглашением и по другой цене.

У меня не получилось открыть исходник на Хаскеле, пишет «ты не Юрри, пшёл вон отсюда».

buntarsky
зачем программировать императивно (C#, GML, остальное), если можно проще программировать декларативно (Пролог, Хаскель, что-то ещё)?
Зачем программировать единообразно, если можно программировать и так, и так, совмещая где как удобно.
Xitilon
Кстати да, это отличная идея. И, обращая внимание на то как всё технически работает, всё декларативное в итоге базируется на императивном. Уж по крайней мере пока процессоры у нас не умеют размышлять в терминах человеческой логики.
Xitilon

Есть мнение, что в 2005 году (!) некто Mun Hon Cheong написал на Хаскеле простенький клон Квейка 3. По-моему я даже приводил этот пример тебе ещё тогда. Правда, совершенно не помню, что мне на это было отвечено. В любом случае, теперь ты уже от ответа уйти вряд ли сможешь, так что милости просим.

Тьфу ты, это тот же, что приведен выше qb60.

Hrenzerg
Один хрен, На Хаскеле давно написана одна из игр про кошку и об этом ещё Джаз на гамине говорил. Так что создание игры в терминах функционального языка — давно не проблема.
Xitilon
Что ещё за игра про кошку?
Yuuri
Nikki and the Robots
pevzi
Хм, а мне почему-то вспомнилась эта.
Hrenzerg
Я игру Nikki имел в виду =)
DarkDes
Помнится как-то сталкивался с Прологом и Лиспом… (лучше (бы (не встречался)))

Да и было это всё для галочки — никакого применения не показали только говорили «используется для искусственного интеллекта»
Hrenzerg
Скорее для построения экспертных систем, а это не ИИ.
iji

Парни, давайте скорее писать игры, а не брезжить слюной с лямбдами и интерфейсами под мышками!

Всем до свидания!

Xitilon
Дай угадаю — тебе тоже надоело, что счётчик новых сообщений только увеличивается каждый раз, и тебя кидает то вверх то вниз по теме?
iji
Надоело что дискуссия драматически приблизилась к третьему тегу поста.
Kozinaka
Темой моего диплома было написание стратегии на С++ и мозгов к ней на Прологе. В итоге я так долго потрошил Старкрафт на ресурсы и программировал саму стратежку, что на мозги времени не осталось, хотя и мог их написать, т.к. Пролог уже к тому моменту достаточно освоил. На Visual Prolog я писал — там всё, что на Дельфи можно было — и формы и кнопки и игры, если хотите. В итоге у меня всё было на С++, а наличие AI на прологе я сымитировал просто пустым подключением либы на Прологе (там баннер бесплатной версии выскакивает). Впрочем вру, мозги на Прологе должны были стать ключевой фишкой, а просто не стали, я мельком обмолвился, что мозги на Прологе, а нажимал на защите на конечные автоматы и поиск пути.
Xitilon

Ты писал вручную экстрактор графики из ресурсов игры что ль?

Ну короче игра у тебя была не на Прологе, но этот пример нам не показывает ничего ни позитивного, ни негативного по сути темы.

Kozinaka
Комментом ниже глянь. Это игра, просто примитивная.
Kozinaka

А в дипломе у меня был не экстрактор, это была игра на С++, внутрь которой было встроено ядро с мозгами на Прологе. Visual Prolog dll'ки умеет формовать.

Но в любом случае, программируя прикладные вещи на Прологе от декларативности немного отходишь, представляешь каким образом интерпретатор проходит твой список правил и всё такое. Можно программировать на Прологе императивно, как того требуют задачи отрисовки картинок и прочего.
Xitilon

Я понял, что у тебя было в дипломе. Значит, таки писал экстрактор — лови респект из нашей артели фанатских хако-переводчиков!

Kozinaka

Не, экстрактор был сторонний — ресурсы из игры у меня были. Сложность была в том, что графические ресурсы там в своём формате, аналоге GIF'а, а полупрозрачные взрывы вообще в 256-цветной палитре интересно через квадратные картинки-матрицы реализовывалось. Короче, ресурсы были, но чтобы заставить их работать и собрать редактор карт, я потратил год подготовки диплома. :)

Xitilon
Ну, тоже работа!
Kozinaka

Вот, кстати, моя «игра» на Visual Prolog (её в официальный список демок поместили): http://www.visual-prolog.com/vip/example/userExample/alchemist/alchemist.htm

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

Xitilon
Во как. Прикольно.
markertat

Чел какой-то на Haskell'е 3D шутер запилил.

Xitilon
И ты третий, кто его привёл в этой теме. Второй — я.
markertat
Да ладно?)))В принципе, уже не так важно.
WingedRat

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

Как пример, почитал про полиморфизм и понял некоторые свои ошибки. Пора уже учить ООП по-человечески.

Xitilon

А это и был повод к нему, который Хейзер заготовил ещё года три назад в нашем разговоре.

Правда, я не знаю, что полезного можно было извлечь из комментариев, какие именно ошибки понять.

ООП, если его знание не является требованием непосредственно по работе, нахрен не нужно. В ГМ я его использую просто потому что оно есть. На Паскале я писал без него, за 5-10 лет до того.

WingedRat

1) Ну, обычно, является.

2) Согласись если писать, следуя какой-то парадигме (ООП, ФП, неважно) код получится лучше, чем если писать совсем от балды.

UPD, 3) А Паскаль у меня ассоциируется со школьными годами и только. Ну, и опыт соответствующий (отрицательный).

Xitilon
2) Скорее да чем нет.
Hrenzerg

Кстати, тут какой-то чел на Хаскеле 3Д шутер сделал.

Вот оно как бывает.

Xitilon

Ого, никогда не видел, вот это ты круто нашёл!

Вот видишь, а ты говорил — невозможно, невозможно!

Hrenzerg

Я не говорил такого. Просто решил приобщиться к Элите. К тем людям, которые привели в этом треде ссылку на эту игру если ты её ещё не видел.

Xitilon
Хм, не видел. У тебя всё новые и новые ссылки, я вижу!
Hrenzerg
Да. Вот ещё один шутер на Хаскеле, кстати.
Xitilon
Где ты их только берёшь! У тебя самописный Гугл какой-то что ль в кармане?!
Hrenzerg
Нет же, просто я нашёл классный сайт, где много таких ссылок.
Xitilon
Теперь-то понятно! Придётся подписаться!
pevzi
Хотел поучаствовать в споре, но не понял, о чем он.
Xitilon
Там много разных веток было. Пролог против ГМ, Хаскель против ГМ, Хейзер против всех, Юрри против всех кто не знает Хаскель, и прочее.
Hrenzerg
Спасибо, проиграл.
Только зарегистрированные и авторизованные пользователи могут оставлять комментарии.