Десктопная программа что это
Да, я пишу десктопные приложения под Windows
Здравствуйте, меня зовут Владимир и я анонимный разработчик десктопных приложений под Windows. В этом месте все должны сказать «Здравствуй, Владимир!», а кто-то может быть добавит «Молодец, что осознал!». А потом все похлопают. Нет, правда, иногда от чтения Хабра у меня возникают именно такое ощущение, что нормально, нет, даже не «нормально», а допустимо и одобряемо сегодня писать только микросервисы для каких-то стартапов, которые будут по какому-то REST API отдавать данные какому-нибудь фронтенду на Ангуляре, который и будет, наконец, показывать пользователю что-то невероятно полезное, вроде таблицы с аггрегированными отзывами о стрижках пуделей с возможностью посмотреть на гуглокартах где бы в вашем городе можно было сделать именно такую стрижку вашему пуделю (несуществующему). А никаких других программ писать уже нет-нет, никак нельзя! Что за чушь?!
Да, многое сегодня происходит в вебе и на мобильных устройствах, но, знаете ли, далеко не всё. Значительная часть приложений по-прежнему является десктопным софтом. И даже (о, ужас!) не под Mac Os или Linux, а под тот самый богомерзкий Windows. И, знаете ли, софт этот живёт, развивается, поддерживается и является ежедневным рабочим инструментом миллионов людей. И никуда он мигрировать не собирается, потому что есть причины, по которым иногда именно десктопное приложение является лучшим вариантом.
Десктопный софт работает без интернета
Работа пользователя не прервется от падения столба на датацентр Амазона или умелого тракториста в соседнем дворе. Вся мощь криворуких сисадминов провайдера, Великих Правительственных Файрволов, горе-хакеров, облачных сервисов, которые на самом деле ни разу не облачные — всё это бессильно перед ПО, которому не нужен интернет, чтобы работать. Пользователь приходит на работу, открывает свой Autocad\Maya\ПО_по_рассчёту_дырчатости_бубликов — и получаёт свой результат, который принесёт его фирме деньги. А больше ничего и не надо.
Лицензирование десктопного софта просто и понятно
Нет, бывают, конечно оригиналы, которые невероятно удачную модель лицензирования «ваша программа через год превратиться в тыкву» заменяют на ещё более удачную «ваша программа через год откатит все апдейты и превратится в семена тыквы». Но это редко. В основном вы покупаете программу, активируете лицензию — и она работает. Всё, что бы там дальше не стрельнуло в голову её авторам — уж по крайней мере эта версия у вас работать не перестанет! 100% гарантия того, что завтра вы включите компьютер и вот этот вот ярлык запустит то же самое, что работало вчера — не прекрасно ли это? Можете ли вы рассчитывать на такую же гарантию у веб-сайта? Да черта с два — вспоминаем недавнюю историю с некоторым популярным сервисом про кино. Ну так ладно кино, а если бы что-то подобное произошло с ресурсом, на который завязана ваша работа и зарплата?
Десктопный софт выглядит одинаково каждый день
Установив некоторую версию софта, человек может научиться работать в ней быстро и эффективно. Со временем ты изучаешь быстрые клавиши, уже не ищешь ту или иную кнопку, ты знаешь что сейчас произойдёт и сколько времени это займёт. Работа становится предсказуемой. Если менеджер в фирме по установке пластиковых окон уже рассчитал в некоторой специализированной программе 100 окон, то время рассчёта 101-го окна он может вам назвать с точностью до пары секунд. И будет прав. Можем ли мы рассчитывать на что-то похожее с веб-сервисами? Ага, разогнались. Как же меня в своё время бесил Gmail, который к такой элементарной вещи как почта каждые 2 недели придумывал то фильтры, то теги, то категории, то 5 разных видов UI, то чат, то ещё какого-то черта лысого. Просто дай мне мою почту и ничего не меняй! Нет, так нельзя, надо вот сюда рюшечку и сюда иконочку. Ну и ладно, пойду-ка я в Outlook. С десктопным софтом вы сами, по крайней мере, решаете когда именно он будет обновляться и до какой версии.
Десктопный софт доступен для расширения
Частенько у десктопного софта есть система плагинов и есть уже готовые плагины, которые можно скачать и поставить. Ну или есть SDK и можно написать плагин самому. Или заплатить за его разработку. А даже если системы плагинов нет, то всё равно что-то да есть: есть интерфейс, который можно автоматизировать с помощью чего-то типа AutoIt, есть входные и выходные форматы данных, которые можно парсить, есть в конце-концов, бинарники, которые можно дизассамблировать и что-то подправить\понять\добавить. Нет, такое, конечно, по лицензии часто делать нельзя, но если очень надо, вот вопрос жизни и смерти человечества, то это по крайней мере физически возможно. А что с сайтом? Зачастую у нас либо нет вообще ничего, поддающегося расширению, либо есть API, который ограничен ровно настолько, чтобы ничего толком полезного с ним было сделать нельзя. Ну, спасибо большое.
Десктопный софт работает
В десктопной программе мне не нужно рассказывать пользователю, что у него старая версия IE или нет Flash или заблокировна Java — я просто поставлю инсталлятором всё необходимое. Мне не нужно его разрешение на геолокацию или доступ к папке с фотографиями — я пропишу его согласие на это в том лицензионном соглашении, которое все принимают не читая. У меня есть доступ к железу. У меня есть доступ к диску. Я могу написать всё, что угодно и не заниматься героическим решением задач типа «как передать данные из одной вкладки браузера в другую» или «как подписать платёж с помощью аппаратного криптоключа».
С десктопным софтом быстрее начать работать
Это кажется парадоксальным — ведь устанавливаемое ПО нужно скачать и установить, а сайт можно просто открыть в браузере. Но давайте посмотрим, что будет дальше: десктопное ПО запустится по двойному клику на иконке и сразу готово к работе. В то время как сайт, скорее всего, попросит вас зарегистрироваться (нудная процедура, ещё небось и капчу разгадывать заставят), потом пришлёт вам письмо для подтверждения почты, потом попросит авторизоваться. Если мы говорим о платных сервисах, то за десктопную программу нужно заплатить 1 раз, а сайт скорее всего попросит подписаться на регулярные взносы. В итоге скачать пару мегабайт и 2 раза нажать «Next» в инсталляторе получается куда быстрее пробежки по граблям при попытке начать пользоваться модным сайтом.
Десктопный софт работает быстро
Да-да, я знаю что Javascript по бенчмаркам работает уже в 2 раза быстрее ассемблера. Да хоть в 10 раз бенчмарки эти ваши будут показывать — что-то не выходят пока что последние Call of Duty и GTA в браузерах. По-старинке гоняют байтики древним нативным кодом. И чего это они? Не понимают ничего, видимо.
Десктопный софт можно контролировать
Саму инсталяху можно проверить антивирусом. И установленную программу можно. А ещё её можно запустить от юзера с ограниченными правами. Или в виртуалке. Или ограничить файрволом. Данные из неё можно сохранить локально, а можно — на удалённый диск. Можно забекапить. Удалить можно. Что из этого всего можно сделать с веб-сайтом? Вы понятия не имеете, что он сделает с вашими данными, куда сохранит, кому продаст, когда потеряет, почему не забекапит и зачем оставит после удаления вашего аккаунта.
Почему же в окружающей нас хабрареальности (и не только) так мало уделяется внимания десктопному ПО и так много информации о веб- и мобильной разработке?
Десктопное или веб-приложение: плюсы и минусы
Сегодня поговорим об отличиях десктопных и веб-приложений. Не обещаем, что сможем быть полностью непредвзятыми, но постараемся честно рассмотреть плюсы и минусы.
Итак, веб-приложение работает через браузер, используя его как среду выполнения, десктопное— устанавливается, запускается и работает локально. Сравним их по основным характеристикам.
Веб-приложение не требует установки, все обновления происходят на сервере, доставляются пользователям сразу — достаточно просто перезагрузить страницу или выйти, а потом снова зайти в аккаунт. Но иногда для его работы нужно установить дополнительные библиотеки или использовать защищенные сетевые протоколы.
Десктопное нужно устанавливать на компьютере или мобильном устройстве, обновлять каждый раз, как выходит новая версия. Несмотря на то, что чаще всего процесс автоматизирован — все равно это занимает время пользователей и ресурсы устройств. Дополнительно придется отслеживать версии на каждом компьютере, смартфоне и планшете.
Веб-приложение публикуется на локальном или облачном сервере, там же происходит процесс обновления. При этом сервер нужен в любом случае, даже если решение совсем простое. Ведь кроме фронтенда, с которым пользователи будут работать через браузер, нужно где-то размещать бэкенд.
Десктопное придется устанавливать вручную на каждом устройстве. В компании, где много рабочих мест, это может занять достаточно много времени. Плюс в том, что не обязательно выбирать сервер или искать ресурсы для публикации, если речь не идет о клиент-серверном решении.
Работа веб-приложения зависит не только от того, насколько грамотно оно разработано и характеристик пользовательского устройства, но также от скорости интернет-соединения, работоспособности удаленного сервера.
Десктопное работает автономно, поэтому главное — качество кода и стабильность оборудования, на котором этот код выполняется. Но если связь с сервером необходима — то возникают те же проблемы, что у «конкурента».
Веб-приложение доступно из любой точки мира, с любого устройства, а пользовательские файлы всегда будут под рукой. Но только если есть интернет-соединение или реализована возможность работы офлайн и загрузки-выгрузки данных.
Десктопное доступно всегда — но только с устройства, на котором оно установлено. Чтобы работать с разных устройств, его придется установить на каждом, а также придумать, где хранить файлы, чтобы всегда иметь к ним доступ.
Веб-приложение одинаково хорошо будет работать на любом устройстве, будь то стационарный компьютер, ноутбук, планшет или смартфон — ведь оно практически не зависит от «железа» или операционной системы. Главное — подходящий браузер. Как правило, для работы большинства веб-клиентов подходят Google Chrome, Mozilla Firefox, Safari от Apple или Windows-браузер (Microsoft Edge / Internet Explorer).
Десктопное зависит от операционной системы, процессора, видеокарты, ряда других параметров. Приходится учитывать нюансы каждой среды (в том числе при «отлове» ошибок), писать код с учетом возможных вариантов, нанимать отдельных разработчиков или даже целые команды для версий под разные ОС.
Веб-приложение полностью зависит от браузера и технологий его работы. Поэтому есть ряд ограничений, например — в доступе к аппаратному обеспечению вашего устройства. Это и некоторые другие ограничения обойти невозможно (во всяком случае, сейчас). Но целый ряд задач можно решить по принципу «что нельзя переписать, можно надстраивать или расширять». Редакторы документов, изображений, аудио, видео, 3D графики; системы управления проектами; хранилища файлов; no-code конструкторы — успешно работают в браузерах. Инструменты быстрой интеграции сервисов, а также интерфейсные библиотеки еще больше расширяют существующие возможности.
Десктопное позволяет реализовать буквально любые функции — в этом оно однозначно превосходит web. Во всяком случае, полноценного онлайн аналога Photoshop или Sony Vegas еще никто не разработал. Системные утилиты — определенно сфера десктопной разработки. Как и программы, которые должны долго работать в фоновом режиме — например, чаты или торрент-клиенты — через браузер с ними просто неудобно будет работать. Также такое ПО чаще используется для специфических проектов, с нестандартными интерфейсами или функциями. Поэтому web разработка пока не представляет опасности для desktop программистов— эти технологии будут развиваться параллельно, просто под разные задачи.
По поводу скорости работы все не так однозначно, как может показаться. Несмотря на то, что браузерный клиент постоянно обменивается данными с сервером, быстродействие будет во многом будет зависеть от того, насколько грамотно он спроектирован, «чистоты» кода, возможностей оборудования, стабильности канала связи. Разница в быстродействии, которая очевидна при тестировании, зачастую незаметна для пользователей.
Веб-приложение, разработанное с использованием современных протоколов и средств защиты, способно полноценно обеспечивать сохранность данных. Однако на некоторые моменты разработчики не могут повлиять: браузер, облачный сервер, канал связи — могут повысить уровень безопасности за счет дополнительных средств проверки, но также снизить его за счет своих уязвимостей. Несомненный плюс для пользователей: такое ПО проще контролировать. Ограничения среды снижают вероятность, что оно скрыто получит доступ к файлам или запустит какой-либо процесс.
Десктопное настраивается более гибко, а значит — теоретически при его разработке можно предусмотреть все потенциальные уязвимости. На практике — вряд ли. Впрочем, сделать его полностью безопасным все же можно. Но только если устройство, на котором оно установлено, не будет никуда подключаться, даже к защищенной локальной сети. В противном случае — риск все равно будет.
Однозначно сказать, что безопаснее — сложно (если вообще возможно). На это влияют много факторов, прежде всего — человеческий. А ведь именно в защите от человеческого фактора, в различных его проявлениях, заключается смысл всех мер безопасности.
Но очевидно, что доверие к десктопному ПО выше. Некоторые организации принципиально не соглашаются работать в браузерах, многие пользователи все еще относятся к ним настороженно. Однако ситуация меняется — с развитием технологий растет лояльность людей к ним.
Возможности браузерной разработки огромны, ее потенциал раскрыт далеко не полностью. Технологии развиваются, рынок ИТ растет, предлагая все новые приложения — при прочих равных пользователи будут выбирать web просто потому, что это удобнее. Если говорить о решениях для корпоративных клиентов, то тут браузерные приложения незаменимы. Они гибкие, универсальные, не требуют предварительной подготовки среды, позволяют сэкономить финансы компании, аппаратные ресурсы, время сотрудников.
Но рассмотрим другое мнение. Некоторые разработчики считают, что перспективы далеко не безоблачные. Слишком несовершенны технологии работы браузеров, слишком много некачественного ПО уже «накодили». Поэтому пользователи браузерных решений будут возвращаться обратно к десктопным. Такая тенденция будет продолжаться, пока разработчики браузеров массово используют Java Script. Только когда появится реальная альтернатива — можно будет делать прогнозы на будущее.
Веб-приложения уже сейчас подходят для решения многих задач — как бизнеса, так и обычных пользователей. Если вы решили разработать свое — используйте no-code платформу AppMaster.io.
Готовые блоки кода и визуальные инструменты для работы с ними помогут вам создать готовое веб-приложение и его серверную часть гораздо проще и быстрее, чем методы классического программирования!
Десктопное приложение или веб-клиент – вот в чем вопрос!
Захотелось мне что-то провокационной статьи, так сказать взбодрить чем-то наше профессиональное сообщество. Хватит заумных статей и философских рассуждений. Итак, делимся на две команды: «любители Соса-Cola – горнолыжники – виндсерферы» против «любители Pepsi – сноубордисты – кайтеры». Счет на табло 0-0, начинаем!
«То о бэнтли я мечтал, то о мазерати,
То рыбалка, то футбол, то с друзьями пати…»
Группа Жуки
Захотелось мне что-то провокационной статьи, так сказать, взбодрить чем-то наше профессиональное сообщество. Хватит заумных статей и философских рассуждений. Итак, делимся на две команды: «любители Соса-Cola – горнолыжники – виндсерферы» против «любители Pepsi – сноубордисты – кайтеры». Счет на табло 0-0, начинаем!
Правила игры и критерии оценок
Сначала давайте определимся, что же будем считать десктопным приложением, а что – веб-клиентом:
При использовании любого из перечисленных клиентских приложений может применяться трехзвенная архитектура. Аллилуйя! Термины «толстый» и «тонкий» клиент сюда не вплетаем. Веб-клиент можно создать совсем не «тонким», ровно также как и с десктопного приложения по максимуму снять обработку бизнес-логики.
Что каждый из пользователей, владельцев системы, архитекторов и сотрудников служб безопасности ждет от программного продукта и клиентского приложения:
Для простоты будем считать, что каждое удачное попадание – 1 очко, так как бессмысленно сравнивать, что важнее – мобильность или безопасность.
Надеюсь, разобрались, и можно начинать «играть». Звучат гимны команд, понеслась…
Первый период
В каждой второй конкурсной документации (если не чаще) в разделе технических требований можно заметить требования к наличию веб-клиента или веб-доступа. Возникает резонный вопрос «Вам вот это зачем, помимо того, что это модно?»
Как правило, обоснования такие:
Безопасность и надежность – очень серьезный вопрос. Некоторые организации принципиально не хотят и не предоставляют возможность работы в корпоративных системах за пределами своего домена. Необходимость применения средств криптографической защиты информации (СКЗИ) и электронной подписи (ЭП) уже давно никому доказывать не надо, за нас это делают регуляторы. Для использования данных технологий необходимо обращаться к сторонним библиотекам, не все веб-приложения это «любят» и имеют ограничения. Стабильность работы самих браузеров также является потенциально узким местом, причем повлиять на это разработчик бизнес-приложения может не всегда. Оффлайн работа, объективно, чаще и проще реализуются с использованием десктопных приложений. В принципе отдельных организаций пока еще пугает работа в браузере (да-да в том самом, в котором сотрудники просиживают часами в социальных сетях, выкладывая туда всю свою подноготную). Это прорыв по флангу и счет 1-1. Звучит свисток, первая половина игры закончена, команды уходят в свои СЭД закрывать накопившиеся поручения.
Второй период
Все покупатели хотят видеть «свой» продукт, отличный от множества других. Конечно, сложно на это надеяться, покупая массовый коробочный продукт. А сделать его «под заказ» значительно дороже и рисково. Но только не в IT области.
Повальная мода на скины, по-моему, уже прошла, или я постарел, и иметь не классическую «морду» аудио-проигрывателя мне уже не принципиально. Тем не менее, возможность изменить цветовую раскраску, логотипы, иконки, шрифты базовых интерфейсов – хороший бонус для клиента. Десктопные приложения могут предоставлять возможность применения цветовой темы, настройки отдельных интерфейсных элементов, но веб-приложения, применяя каскадные таблицы стилей, с этим справляются явно лучше. Возможность кастомизации определяется степенью развития самого программного продукта и тип клиентского приложения тут не должно иметь особой роли. Счет 2-1 и «браузерники» вырываются вперед.
Функциональность – важнейшее требование к любому программному продукту. Исторически считается, что десктопные приложения более функциональны и эргономичны. Если пытаться разрабатывать веб-клиент с нуля, то так оно и будет. Но с годами были разработаны целые интерфейсные библиотеки, позволяющие творить «чудеса»:
Про визуальную красоту реализации я и говорить не буду – там все очень достойно. Подозреваю, что компании больше и охотнее разрабатывают новые интерфейсные элементы под браузеры, чем для традиционных win32-приложений.
Современный пользователь компьютера не меньше времени проводит в браузере, чем тратит его на работу с десктопным приложением. И первый вариант работы сложнее ему не кажется. Зато возможность масштабирования в браузере, отдельным категориям пользователей, приносит ощутимую пользу. Опасность у ворот команды веб-клиента была устранена. Счет по-прежнему 2-1.
Корпоративная информационная система растет вместе с компанией. А значит, количество рабочих мест увеличивается, расширяется линейка клиентских устройств для работы в системах. Мировые лидеры разрабатывают новые операционные системы и платформы, и угнаться за ним не так просто. А надо ли? Может быть, доверим им обеспечить совместимость распространенного программного обеспечения, а если такая совместимость не возможна, в их же интересах предоставить альтернативу. Вот такими финтами и перепасовками в центре поля одна из команд пробирается к воротам соперника.
Разрабатывая веб-приложения с соблюдением стандартов можно надеяться, что программное обеспечение будет корректно работать во всех браузерах, по крайней мере, в первой пятерке. Чуда тут не происходит, и существует масса нюансов связанных с различной интерпретацией одной и той же разметки. Разработчики каждый день видят в системах баг-трекинга заявки из разряда «функция А не корректно работает в браузере Б, а в остальных браузерах все ОК». Но эти труды стоят получаемых бонусов.
Когда пользователь заходит на рядовой публичный сайт в Интернете он надеется увидеть корректное представление страниц с сохранением всей заложенной функциональности. Причем, посетитель сайта не хочет знать «под какие устройства» сайт создавался (стационарный компьютер или ноутбук, планшет или смартфон), это его вообще не должно беспокоить. Почему же ровно также не рассуждать пользователю корпоративной информационной системы. Зачем пользователю, находящемуся вне офиса и имеющему на руках планшет за 1000$ переживать, что он не сможет исполнить поручение, выданное ему в СЭД. Надо ли сотруднику при выборе планшета изучать вопрос, а сможет ли он конкретно с этого планшета (с его операционной системой), корректно работать в десятках корпоративных систем своей организации. А если завтра он купит другой планшет (с другой программной платформой), система на нем будет ровно такой же, к которой он привык или уже другой, а придется что-то заново скачивать и устанавливать?
В идеале, я бы хотел, что бы разработчики бизнес-приложений сосредоточились на самих продуктах, а не тратили время на разработку одного и того же под разные платформы (те же яйца только в профиль). И одним из путей вижу применение в качестве клиентских приложений полнофункциональных веб-клиентов с адаптивным веб-дизайном. Это красивая комбинация заканчивается неберущимся ударом, и счет становится 3-1. Веб-клиент заслуженно побеждает десктопное приложение. Крики радости, брызги шампанского, смазливые девицы окружают победителей.
Послесловие
После матча болельщики еще долго спорили, обсуждали острые моменты и не объективное судейство, но счет на табло уже ничто не изменит. Ставки сделаны господа, ставок больше нет!
На чем писать мультиплатформенное desktop-приложение? Взгляд менеджера
Сегодня авторы большинства приложений уже не могут позволить себе выпускаться под одну платформу. Early adopters сидят под маками, мейнстрим сидит под Win32, а гики и адепты open source предпочитают Linux. Каждая из этих аудиторий обладает уникальными свойствами, а поэтому важна для большинства проектов.
Данная статья задумывалась как открытая попытка разобраться, на чем стоит писать мультиплатформенное desktop-приложение. Приглашаю высказать свое мнение людей с опытом создания таких приложений.
Изначально определим критерии, по которым будем оценивать различные платформы. В первую очередь — это удобство пользователя. Уверен, что вы замечали общие черты у приложений, написанных под разные платформы. Во вторую — это интересы проекта. Моя задача — построить успешный бизнес, а не играться с различными инструментами.
Обозначим рамки исследования. Мое приложение — небольшая утилита для пользователя-«чайника», которая качает файлы из интернета: минимум GUI, небольшой набор функциональности, использование внешних С++ библиотек.
Ну что, начнем. Какие есть варианты? Я рассмотрю Java, C#, C++, Python. Буду рад, если вы расскажите о других альтернативах.
Данный язык/среда изначально задумывались как нечто мультиплатформенное. На Java написано большое количество приложений, крупные проекты вроде Eclipse используют именно этот фреймворк.
Все приложения, которыми мне доводилось пользоваться, не использовали «родной» интерфейс Win32. Не знаю, чем руководствовались разработчики, но с точки зрения конечного пользователя это выглядит очень не симпатично.
Примеры приложений: Eclipse, ZDE, клиент для Gnutella Limewire.
Плюсы: мультиплатформенность, большое количество кадров, развитость фреймворка.
Минусы: необходимость установки фреймворка, кривость GUI, низкая производительность.
Аналогично с Java, приложения на C# имеют большой минус — необходимость устанавливать фреймворк. Я сам отказался от установки несколько приложений, которые требовали этого фреймворка. Менее продвинутые пользователи будут ещё более требовательными.
В остальном — сплошные плюсы, на мой взгляд.
Примеры приложений😕
Плюсы: мультиплатформенность, большое количество кадров, хорошая производительность, развитость фреймворка.
Минусы: необходимость установки фреймворка.
Старичок дотянул до наших дней и замечательно себя чувствует. Много приложений под платформы Linux и Windows до сих пор пишутся на этом языке.
Программы, написанные на C++, являются примером для других по размеру дистрибутива и экономному использованию системных ресурсов (процессор, память). Тем не менее у разработчиков есть масса претензий к С++. По моему мнению, язык является «устаревшим» и его популярность в дальнейшем будет снижаться, что подтверждается индексом TIOBE.
С точки зрения развития проекта, по сравнению с динамическими интерпретируемыми языками (вроде Ruby и Python), разработка на данном языке может иметь менее высокую скорость и более высокие издержки изменения проекта. Для стартапа, которому не столь важна производительность приложения, это может стать существенным минусом.
Примеры: Firefox.
Плюсы: отличная производительность, большое количество кадров, большое количество библиотек.
Минусы: невысокая скорость разработки.
Python
Взглянуть на Python в качестве платформы для desktop-приложений меня заставила программа MusicBrainz Picard. Несмотря на свою скриптовую сущность, Python легко собирается в один exe-файл, не требуя от пользователя установки дополнительных компонентов.
В случае разработки небольшого приложения, интерпретируемые языки вроде Python будут большим плюсом. Легкость написания и высокая скорость изменения приложения пригодится любому стартапу.
Огромным минусом различных «модных» технологий является их низкое распространение, а значит серьезные проблемы в поиске квалифицированных кадров. Ситуация с поиском программистов итак плачевная, а если ограничиться узким языком — можно вообще никого не найти. С другой стороны, храбрость перейти на новый язык имеют наиболее прогрессивные разработчики. Может получиться так, что выбрав «перспективный» язык, мы сразу отсечем миллионы середнячков, оставив себе выбор из нескольких перспективных разработчиков.
Пример: MusicBrainz Picard, оригинальный BitTorrent.
Плюсы: высокая скорость разработки и изменений, хорошая интеграция с библиотеками на С и С++.
Минусы: мало кадров, низкая производительность.
Выводы
К сожалению, любая из вышеперечисленных платформ имеет свои плюсы и минусы, однозначного решения найти не удалось. Выбор одной из них сегодня принесет преимущества и недостатки, влияние которых на проект мы увидим только завтра.
Я пока выбираю между С++ и Python. Первый является «надежным» решением с известными недостатками. Второй является «рискованным», но интересным и перспективным. Надеюсь, ваши отзывы помогут мне сделать окончательный выбор. Какую платформу выбрали бы вы на моем месте?
PS. Я сейчас ищу программистов в этот стартап (с++/python/php), поэтому если кому интересно — присылайте свое резюме.