Новый проект: у меня проблемы с выбором языка для использования

Выбирайте C++. Таймеры, многопоточность, аудио, SDL, wxwidgets - это все, что Perl может делать, но не особо в этом преуспевает. Кроме того, PAR или perl2exe - неуклюжие механизмы для распространения. Они работают, но не идеальны. Между тем, C++ (и я настоятельно рекомендую вам взглянуть на использование Способствовать росту) прекрасно вписался бы в эту роль.

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

Я бы предложил комбинацию Lua / C++ или Python / C++ (я не уверен, насколько хорошо работает комбинация Perl / C++, но это тоже может быть хорошим вариантом).

Лично я сделал много работы с комбо Lua / C++, и это довольно фантастично.

Я использую PAR, чтобы упаковать значительную программу Perl / Tk для Windows. Потребовалось немного повозиться, но это сработало.

Если у вас есть хотя бы такой же опыт работы с Perl, как и с C++, разработка на Perl должна быть быстрее. Но скорость выполнения эквивалентной программы будет ниже. Все остальные критерии могут быть удовлетворены любым из них, поэтому я бы сказал, что все сводится к личному выбору.

Лично? Я говорю, не зацикливайтесь на этом слишком долго. У любого пути есть свои плюсы и минусы, но похоже, что вы опасно близки к тому, чтобы застрять в «аналитическом параличе». Если ничего другого, подбросьте монетку или выберите ту, которая, по вашему мнению, имеет самое красивое имя.

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

Пара комментариев:

1. PAR, perlapp и perl2exe не являются компиляторами. Они упаковщики. Не существует компилятора Perl, кроме самого perl. Если вам нужна какая-то форма кода Perl в виде байт-кода, вам придется дождаться Perl 6 на Parrot.
2. Я использовал PAR для упаковки приложения с общим количеством SLOC около 500 тыс., Не считая самого perl. Он работал нормально, работал с той же скоростью, что и сам Perl, но запуск был медленнее. Это был 2005 год. С тех пор производительность при запуске значительно улучшилась, если вы установили модуль Archive :: Unzip :: Burst на машине разработки, на которой вы упаковываете программу. Я успешно использовал PAR для различных приложений, размер которых варьировался от крошечных до вышеупомянутых 500 тыс. Строк. Если вам нужна помощь с PAR, есть активный и удобный список рассылки. Просто сделайте одолжение нам и себе, не вмешивайтесь в слова «OMG, ничего не работает, помогите мне, kthx!». Люди делают это все время (а иногда все равно получают помощь). :)
3. Многопоточность Perl не очень хороша. Вместо этого проверьте, подходит ли вам что-то вроде POE. Я пользователь threads.pm, но не хочу им быть. Приносим извинения трудолюбивому сопровождающему Джерри Д. Хеддену.
4. wxPerl находится в довольно хорошей форме, и вокруг него есть сообщество. Естественно, поскольку wxWidgets - это C++, он всегда немного актуальнее и полнее.
5. SDL Perl - это прямая оболочка библиотеки. (Небольшая) документация предполагает, что вы это уже знаете. По моему опыту, чтение документации для библиотеки на другом языке может быть немного хлопотным.
6. Таймеры в perl подойдут: Время :: HiRes
7. Переносимость - это сложно. В большей степени в C++, чем в Perl, но на самом деле все сводится к дисциплине и возможности тестирования на многих платформах.
8. Для Perl в Windows обязательно проверьте Strawberry Perl.

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

Есть аргумент, что разработка на динамических языках займет меньше времени. В Perl и C++ есть аналогичные проблемы, связанные с получением раскрывающегося списка в нужном месте, заполнением его правильными значениями, внесением правильного изменения в состояние программы из пользовательского ввода.

Если Perl не работает на определенных платформах, преобразуйте код на C++.

Вероятно, есть несколько указателей, которые помогут в этом подходе:

1. Это означает, что вы, вероятно, напишете прототип на OO Perl. Если у вас есть высокоуровневые функциональные возможности, прибитые к одной платформе - при условии, что вы сможете продвинуться так далеко в Perl - тогда C++ станет более или менее оптимизацией.

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

Напишите свою основную функциональность на C++, а затем напишите интерфейс для вашего приложения в инструменте для рассматриваемой платформы, например, Cocoa для Mac OS X, .NET / Delphi / MFC для Windows и т. д.

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

Отличная причина использовать Perl - метапрограммирование.

Perl достаточно гибок, чтобы вы могли писать код для написания кода (вот как Moose творит свою магию). Вы сэкономите время и уменьшите количество ошибок, которые вам нужно устранить.

Отличная причина использовать Perl - это CPAN.