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

Question

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

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

Итак, мой вопрос:

1. Может ли PAR, Perl2exe или эквивалентный компилировать больше, чем базовые тестовые случаи?
2. Скорость и компиляция в стороне, почему я должен использовать C ++ вместо Perl?

---

Edit: Некоторые из моих спецификаций проекта.

• Мультиплатформа. Я ожидаю, что 50% или более моих пользователей будут владеть маками, при этом большинство остальных пользователей будут пользователями Windows. Если возможно, я также хочу поддерживать Linux, так как это моя повседневная операционная система.
• Поскольку он мультиплатформенный, мне нужен единый инструмент для создания графического интерфейса. Он должен уметь использовать базовые типы и позволять мне создавать собственные обработчики событий и пользовательские объекты графического интерфейса.
• Требуется обработка звука. Читайте и играйте, wav и / или mp3. Также я буду использовать некоторые собственные алгоритмы для определения специальных свойств аудиофайлов; такие вещи, как темп, шаблоны и т. д.
• Мне бы хотелось, но не требуется поддержка SDL / OpenGL.

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

Answer 1

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

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

1. PAR, perlapp и perl2exe не являются компиляторами. Они упаковщики. Perl-компилятора не существует, кроме самого perl. Если вам нужна какая-то форма байт-кода Perl-кода, вам придется подождать Perl 6 в Parrot.
2. Я использовал PAR для упаковки приложения с общим количеством SLK около 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.

Answer 2

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

Answer 3

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

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

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

Answer 4

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

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

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

Answer 5

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

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

Answer 6

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

Answer 7

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

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

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

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

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

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

Answer 8

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

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