Как всегда хочется несферических примеров. Я своим студентам контрольные генерировал скриптом. Это действительно удобно и здорово. Но увы, получалось все-таки не так сказачно, как в примере с Аней-Светой-Мариной, потому что воросы касались вещей весьма конкретных, например, делегатов C#, и пространства для рандомизации вопросов фактически не получалось.
Даже просто перемешать вопросы по билетам, чтобы билеты не повторялись — уже не вполне автоматизируемая задача. Некоторые вопросы просто не должны стоять рядом, потому что один является ответом на второй. Я обычно билеты генерировал с запасом, а потом фильтровал выдачу вручную, как Лукашенко в анекдоте. Вот поэтому было бы здорово посмотреть, как ваш метод работает на практике.
И еще отдельный вопрос. Там где, например, решить уравнение. Задание я построю, ок. А решение? Ну ладно линейное уравнение, а если что-то поинтересней?
Да, это я в курсе. Но J по большому счету и нужен для того, чтобы можно было в ASCII. А вот APL потрогать (буквально!) было бы по меньшей мере забавно.
Кажется, я где-то слышал про попытки возродить APL на планшетах. Нет клавиатуры — нет проблемы с символами, стилом или пальцем можно нарисовать что угодно.
Первая мысль — написать свой интерпретатор своего скриптового языка, выкидывается из мозга через несколько секунд. Логика игрока определенно не стоит таких жутких затрат.
Тут есть подвох. Ядро языка писать несложно, никаких больших затрат там не случается. А вот «вывести концы» собсвтенно объектной модели так, чтобы ей мог с удовольствием пользоваться скриптер, — вот это задача намного более сложная и интеллектоемкая. И она не решается простой прикруткой Луа, Питона или чего угодно еще.
Первый мой опыт в этой области касался AngelScript. Ну, это было давно, Луа еще был не на слуху, а вот этот ангельский скриптец казался нам тогда вполне годным. К тому же у него был сиподобный синтаксис, что с нашей программистской точки зрения было несомненным плюсом. Мы прикрутили скриптовый движок и тупо вывели интерфейсы один в один, но не все. Получилось, что у нас есть язык, на котором предполагается писать логику игры, который хуже чем плюсы, имеет меньше возможностей, чем плюсы, но при этом похож на плюсы и чтобы пользоваться им, надо знать плюсы. Скриптеры посмотрели на это дело, сказали: «как-нибудь в другой раз». В итоге сцены на всем этом мы же и писали, потому что больше некому.
Следующий опыт касался как раз Луа. Прикрутили Луа, дали скриптерам, они засели и быстро-быстро настрочили тонну говнокода. Им положено, они не программисты, они геймдизайнеры, им по штату положено делать сцены, а не код рефакторить. Естественно, вскоре застряли во всем этом и опять же разгребать все пришлось нам, программистам.
А вот в третий раз от меня ненадолго отвернулось начальство, и, пока никто не видит, я внезапно написал собственный язык с блекджеком и шлюхами. Точнее, писал его не я, я только программировал. Сам язык создавал по-сути Женя Гомельский, геймдизайнер, который просто знал, чего хочет и умел это сформулировать. Язык получился местами очень даже ничего. Там были предлоги, похожие на именнованные параметры в Обджектив-Си, местоимение «it», как в Хаскелевском ghci, метапрограммирование в стиле миксинов Ди, и даже некоторые уникальные вещи, как, например, переменная по умолчанию. Ну, можно было, например, написать цикл так: [for {i=0} {i++; i<10}], а можно так: [10x]. Во втором случае счетчиком цикла считалась переменная по умолчанию "?".
Мы выпустили с ним пару проектов, вполне между прочим успешных, а потом перешли на новую платформу и забросили скрипты вообще в пользу машины состояний и визуального программирования. И, честно сказать, это было определенное облегчение. Писать языки надо уметь, я не умею. Кроме красивых фичей, он закономерно оброс костылями и велосипедами. Если код на языке был вполне даже читаем, то код самого интерпретатора заболотило по самые осины. Его стало очень сложно поддерживать. Причем, не само ядро, конечно, там-то как раз ничего сложного изначально не было, а вот все эти «концы». Например, в одном проекте меню выезжает справа, в другом — снизу, и в язык попадают, условно говоря, две взаимоисключающие функции для красивого выезда меню. И вот так вот все.
То есть, какой вывод я хочу сделать. Программировать сложно. Без опыта и усердия любой выбор скриптового решения приведет к говну и костылям.
Деление флота на ноль вполне соотвествует IEEE 754. Именно поэтому в HICPP рекомендуется в таком случае вводить какие-нибудь предусловия. Пусть лучше грациозно падает прямо сейчас, чем когда-нибудь еще.
Ни в коей мере не склоняю! Уж что-что, а второй Cppcheck никому точно не нужен. Наоборот, пытаюсь сказать, что конкуренция на поле статических анализаторов из коробки бесполезна, потому что с одной стороны PRQA и LDRA с огромным штатом и десятилетиями научной работы, а с другой стороны подпирает Cppcheck, который становится лучше и лучше и привлекает все больше людей. Надо выходить за рамки этого поля.
На самом деле, практически все крупные игроки уже предлагают инжениринговые услуги того или иного рода, но на этом поле вполне реально с ними потягаться. Например, в случае адаптации того же анализатора под внутренние стандарты большинству отечественных контор старой школы банально проще составить ТЗ на русском и по ЕСПД, чем залазить в дебри международного сотрудничества.
Это может взлететь как рекламная акция. Действительно отказаться от препроцессирования для гитхаба, собрать пауком 100500 проектов, загрузить ими свободное время сервера, отчеты с дефектами разослать авторам с объяснением, почему с препроцессированием (и регулярное использование, раз уж речь зашла) было бы еще круче.
Если бы мне пришло на почту, мол, в таком-то файле на такой-то строке дескриптор потек, я бы заинтересовался.
В Джулии просто целый зоопарк разложений, там писать и писать :-)
Ок, почитаю-поиграюсь с языком, в понедельник определюсь окончательно. Кое-что я уже переписывал на плюсах, питоне и шарпе, — в принципе видение задачи есть. Меня, конечно, смущает, что про D я пока только введение Александреску читал, но с другой стороны не боги горшки обжигают: будет востребовано — будет комьюнити, будет комьюнити — научат как надо.
У нас в отраслевом стандарте прописана независимая верификация. То есть исходники не просто можно, а обязательно необходимо показать независимым специалистам.
Самый ваш опасный конкурент — не Gimpel и Coverity, а CppCheck, как ни странно. Он открытый и у него 77 контрибьюторов. Да, он кривоват, и ложных срабатываний там многовато, и не все проверяется достаточно хорошо, но это живой проект, в который имеет смысл инвестириовать время и деньги. Лучше вложить в проект, который развивается сообществом и кастомизируется под наши нужды, чем в коммерческий проект, который сегодня есть — завтра кризис.
С другой стороны, определенная ниша CppCheck не покрывается. Например, у нас на фирме ветер дует в сторону внутреннего стандарта на С++. Потребуется инструмент для поддержки этого несуществующего стандарта. Вот перепилить Cppcheck под него можно, конечно, но получится плохо, долго и дорого. Потому что хорошо мы делаем железки для АЭС, а не статические аназизаторы. Нам проще, соотвественно, купить статический анализатор с грамотно кастомизированной сборкой правил, чем делать ее самостоятельно. И за это уже можно и заплатить хороших денег.
А что именно вам нужно от библиотеки ЛА? От предметной области сильно зависит скоуп такой библиотеки. В геймдеве, например, не нужны обобщения векторных произведений, а в деформативном моделировании — суперскалярные операции.
Вообще, я давно хотел попробовать D, ну и с линейной алгеброй немного знаком. Если это кому-то надо, могу попробовать заняться.
Например, map. Функция, которая применяет функцию к каждому элементу чего-либо. Как for-each. Разницы на самом деле немного. В Питоне, например, циклы сделаны в императивном стиле, но фактически работают над ленивыми списками.
Ну и классика — рекурсия. В теле функции проверям: если счетчик дошел до конца, ничего не делаем, если нет — делаем что-то, запускаем саму же функцию с подвинутым счетчиком. Сперва выглядит неуклюже, но это дело привычки.
Имеем функцию, принимаем объект константно по значению, создаем новый объект в контексте, делаем с ним все что угодно, возвращем по значению (кстати, перемещение тут работает норм). GC не нужен.
В принципе мы можем вообще не создать ни одного объекта вне контекста той или иной функции.
Даже просто перемешать вопросы по билетам, чтобы билеты не повторялись — уже не вполне автоматизируемая задача. Некоторые вопросы просто не должны стоять рядом, потому что один является ответом на второй. Я обычно билеты генерировал с запасом, а потом фильтровал выдачу вручную, как Лукашенко в анекдоте. Вот поэтому было бы здорово посмотреть, как ваш метод работает на практике.
И еще отдельный вопрос. Там где, например, решить уравнение. Задание я построю, ок. А решение? Ну ладно линейное уравнение, а если что-то поинтересней?
Одно но, я не уверен, что это мне не приснилось.
Тут есть подвох. Ядро языка писать несложно, никаких больших затрат там не случается. А вот «вывести концы» собсвтенно объектной модели так, чтобы ей мог с удовольствием пользоваться скриптер, — вот это задача намного более сложная и интеллектоемкая. И она не решается простой прикруткой Луа, Питона или чего угодно еще.
Первый мой опыт в этой области касался AngelScript. Ну, это было давно, Луа еще был не на слуху, а вот этот ангельский скриптец казался нам тогда вполне годным. К тому же у него был сиподобный синтаксис, что с нашей программистской точки зрения было несомненным плюсом. Мы прикрутили скриптовый движок и тупо вывели интерфейсы один в один, но не все. Получилось, что у нас есть язык, на котором предполагается писать логику игры, который хуже чем плюсы, имеет меньше возможностей, чем плюсы, но при этом похож на плюсы и чтобы пользоваться им, надо знать плюсы. Скриптеры посмотрели на это дело, сказали: «как-нибудь в другой раз». В итоге сцены на всем этом мы же и писали, потому что больше некому.
Следующий опыт касался как раз Луа. Прикрутили Луа, дали скриптерам, они засели и быстро-быстро настрочили тонну говнокода. Им положено, они не программисты, они геймдизайнеры, им по штату положено делать сцены, а не код рефакторить. Естественно, вскоре застряли во всем этом и опять же разгребать все пришлось нам, программистам.
А вот в третий раз от меня ненадолго отвернулось начальство, и, пока никто не видит, я внезапно написал собственный язык с блекджеком и шлюхами. Точнее, писал его не я, я только программировал. Сам язык создавал по-сути Женя Гомельский, геймдизайнер, который просто знал, чего хочет и умел это сформулировать. Язык получился местами очень даже ничего. Там были предлоги, похожие на именнованные параметры в Обджектив-Си, местоимение «it», как в Хаскелевском ghci, метапрограммирование в стиле миксинов Ди, и даже некоторые уникальные вещи, как, например, переменная по умолчанию. Ну, можно было, например, написать цикл так: [for {i=0} {i++; i<10}], а можно так: [10x]. Во втором случае счетчиком цикла считалась переменная по умолчанию "?".
Мы выпустили с ним пару проектов, вполне между прочим успешных, а потом перешли на новую платформу и забросили скрипты вообще в пользу машины состояний и визуального программирования. И, честно сказать, это было определенное облегчение. Писать языки надо уметь, я не умею. Кроме красивых фичей, он закономерно оброс костылями и велосипедами. Если код на языке был вполне даже читаем, то код самого интерпретатора заболотило по самые осины. Его стало очень сложно поддерживать. Причем, не само ядро, конечно, там-то как раз ничего сложного изначально не было, а вот все эти «концы». Например, в одном проекте меню выезжает справа, в другом — снизу, и в язык попадают, условно говоря, две взаимоисключающие функции для красивого выезда меню. И вот так вот все.
То есть, какой вывод я хочу сделать. Программировать сложно. Без опыта и усердия любой выбор скриптового решения приведет к говну и костылям.
А туториал годный, кстати.
На самом деле, практически все крупные игроки уже предлагают инжениринговые услуги того или иного рода, но на этом поле вполне реально с ними потягаться. Например, в случае адаптации того же анализатора под внутренние стандарты большинству отечественных контор старой школы банально проще составить ТЗ на русском и по ЕСПД, чем залазить в дебри международного сотрудничества.
Если бы мне пришло на почту, мол, в таком-то файле на такой-то строке дескриптор потек, я бы заинтересовался.
Ок, почитаю-поиграюсь с языком, в понедельник определюсь окончательно. Кое-что я уже переписывал на плюсах, питоне и шарпе, — в принципе видение задачи есть. Меня, конечно, смущает, что про D я пока только введение Александреску читал, но с другой стороны не боги горшки обжигают: будет востребовано — будет комьюнити, будет комьюнити — научат как надо.
С другой стороны, определенная ниша CppCheck не покрывается. Например, у нас на фирме ветер дует в сторону внутреннего стандарта на С++. Потребуется инструмент для поддержки этого несуществующего стандарта. Вот перепилить Cppcheck под него можно, конечно, но получится плохо, долго и дорого. Потому что хорошо мы делаем железки для АЭС, а не статические аназизаторы. Нам проще, соотвественно, купить статический анализатор с грамотно кастомизированной сборкой правил, чем делать ее самостоятельно. И за это уже можно и заплатить хороших денег.
Вообще, я давно хотел попробовать D, ну и с линейной алгеброй немного знаком. Если это кому-то надо, могу попробовать заняться.
Ну и классика — рекурсия. В теле функции проверям: если счетчик дошел до конца, ничего не делаем, если нет — делаем что-то, запускаем саму же функцию с подвинутым счетчиком. Сперва выглядит неуклюже, но это дело привычки.
В принципе мы можем вообще не создать ни одного объекта вне контекста той или иной функции.