Комментарии 328
Mono помоему еще не до конца доросла до того, чтобы обеспечить совместимость 1 в 1 .net приложений =(
Mono сейчас между .NET 1.1 и 2.0 - полная поддержка первого, часть второго
Они вчера заявили о полной поддежке 2.0, если я ничего не путаю.
Путаете, пока что "the last release before Mono reaches its 2.0 level"
Судя по всему!
http://tirania.org/blog/archive/2008/May-13.html
*Радостный ушел ставить ubuntu и тестировать*
http://tirania.org/blog/archive/2008/May-13.html
*Радостный ушел ставить ubuntu и тестировать*
Советую собирать из сурсов (http://www.mono-project.com/AnonSVN). По крайней мере в debian lenny хоть версия и 1.9, но явно какие-то проблемы со сборкой, например, в xsp нет fastcgi-mono-server.
У них графический интерфейс разный, так что говорить об кроссплатформенности нельзя. Mono использует gtk#
Сколько я ковырялся с Mono - это не совсем так. Gtk# - это нативный интерфейс, разработанный самими участниками проекта. Он, кстати, есть и под винду. А вот Winforms - реализация оригинального интерфейса, используемого для отрисовки форм в .NET. Так что, как только он будет полностью допилен, мы получим возможность запускать .NET приложения, собранные в VS 2005+. И работать они должны будут без каких-либо доводок, т.е. как родные. Единственный момент, который меня настораживает - как winforms компоненты будут выглядеть в разных ОС...
На виджеты, кстати, вроде распространяются авторские права.
Кстати, я не видел ещё ни разу, что приложения из .Net использовались в Mono. Миры эти как-то совершенно независимо существуют.
Кстати, я не видел ещё ни разу, что приложения из .Net использовались в Mono. Миры эти как-то совершенно независимо существуют.
Если говорить о Winforms 2.0, то он тогда был еще попросту не доделан и большинство .NET приложений, на его основе, банально не запускались. Вот народ и использовал Gtk#, чтобы не париться. Да и в интерфейс он лучше вписывался, т.к. использовал нативные библиотеки Gtk для отрисовки. Для Маков CocoaSharp сделали с той же целью. А вот приложения, основанные на первой версии фреймворка, вполне себе работали, хоть и выглядели не очень. У меня получалось запускать по крайней мере.
А на данный момент Gtk# и сам уже стал вполне взрослой библиотекой и сам по себе представляет интерес для разработчика.
Но как и GTK+ для Python и Ruby весит она много для Windows и Mac OS X.
Думаю, что весит примерно столько же, как и для линукса. Просто большинство библиотек, необходимых для Gtk#, уже есть в большинстве дистрибьютивов, использующих GNOME. Именно поэтому размер самого Gtk# и кажется небольшим.
Ну у Линукса ещё есть пакетные менеджеры, так что для двух Mono программ Gtk# будет качаться только один раз.
Ну что тут поделаешь. Пакетные менеджеры и централизованная установка пакетов - одна из сильных сторон современных открытых систем вообще. Тут ничего не поделать. С другой стороны, устанавливая очередную программку, никогда не знаешь наверняка почему установщик столько весит и какие библиотеки будут установлены (можно только посмотреть постфактум). Я вообще полагаю, что народ не напрягаясь использует для своего софта наиболее удобные библиотеки, не сильно переживая за увеличение объема исталятора.
BTW, за размер можно беспокоится только если программа совершенно не нужная и не интересная. Если прога одна из лучших в своем классе либо имеет какие-то ооочень "вкусные" функции, то лишние 10-20 мегабайт пользователей не остановят, чтобы ее скачать. Хотя, слишком сильно увлекаться с объемом установки тоже не стоит. Но если сторонний фреймворк сделает написание или поддержку приложения гораздо проще и удобнее (а это значит, что программисты смогут больше сосредоточиться на вопросах функциональности и надежности не забивая себе головы изобретением велосипедов), то можно (и даже нужно) его использовать. ИМХО.
BTW, за размер можно беспокоится только если программа совершенно не нужная и не интересная. Если прога одна из лучших в своем классе либо имеет какие-то ооочень "вкусные" функции, то лишние 10-20 мегабайт пользователей не остановят, чтобы ее скачать. Хотя, слишком сильно увлекаться с объемом установки тоже не стоит. Но если сторонний фреймворк сделает написание или поддержку приложения гораздо проще и удобнее (а это значит, что программисты смогут больше сосредоточиться на вопросах функциональности и надежности не забивая себе головы изобретением велосипедов), то можно (и даже нужно) его использовать. ИМХО.
Mono сейчас между .NET 1.1 и 3.5: вывод типов работает, лямбда работает, linq не пробывал, но в sources самого mono видел, усеченное объявление свойств есть. Moonlight (аналог Silverlight) обновляется чуть ли не каждый день - сижу на svn версии. Динамика поражает, но что действительно круто, так это открытые исходники: если что-то ведет себя не так, как я ожидал - смотрю сурсы и правлю свой код. Три раза уже спасало.
Mono никогда не доростет, если не заручится поддержкой MS, т.к. в мелкософте выпускают новые версии фреймворков намного быстрее чем программисты mono могут портировать старые
Очень поверхностный обзор. Складывается ощущение, что автор статьи знаком со всем, что здесь перечислил лишь поверхностно, в лучшем случае на уровне пользователя.
В качестве платформы бы я посоветовал "МОЗГ". Использование данной платформы обеспечивает почти 100% верный успех.
В качестве платформы бы я посоветовал "МОЗГ". Использование данной платформы обеспечивает почти 100% верный успех.
Я не программист, поэтому знакомство действительно очень поверхностное. Тем не менее, вопрос выбора стоит прямо сейчас - именно поэтому я написал эту статью. С просьбой к экспертам высказаться.
Вы не программист, а выбираете. В целях маркетинга что ли?
Я руководитель проекта. А кто по-вашему должен выбирать фреймворк? Программисты, как в том анекдоте - каждый болеет за своих :)
выбирать фрэймворк должен профессионал. Например - архитектор системы.
иногда, особенно в маленких компаниях руководитель проекта: програмист, архитектор и руководитель. И как все люди, не идеален во всем. Как я понимаю, для этого этот разговор здесь и начался
мой партнер по бизнесу, который одновременно технический директор, предлагает разрабатывать на C++. я написал эту статью, чтобы послушать мнения людей с опытом решения похожих задач.
НЛО прилетело и опубликовало эту надпись здесь
Если я не путаю, то программы, использующие GPL версию Qt должны быть на GPL. А проприетарная версия библиотеки стоит недешего.
НЛО прилетело и опубликовало эту надпись здесь
Ты не ошибаешься
Купите одну копию и поставьте на комп к одному разработчику. Все остальные разрабатывают внутренний GPL-продукт с использованием GPL Qt и никому его не дают. Проблем с лицензиями нет. Сборка же "для чужих" делается же все равно обычно кем-то одним...
Теперь нет, последняя QT под LGPL.
Если у вас есть технический директор, то пускай он и выбирает! Профессионал должен заниматься своим делом, иначе все плохо кончится, примеров — море.
Если для приложения критична скорость: C++ & Qt, если по каким то причинам нет желания покупать Qt можно попробовать C++ & WxWidgets, хотя проблем скорее всего будет больше. Можно конечно и совсем в дебри податься, только осторожно: FOX, FLTK, платформа Mozilla, GTKmm.
Если не очень важна: Java + SWT (как вариант Java + Swing, но это хуже). JRE весит всего 15 МБ, если его встроить в приложение и выкинуть ненужные библиотеки - будет довесок всего мегабайт в 10, мелочь по современным меркам.
Python стоит использовать если скорость совсем не критична и, самое главное, удасться найти программистов.
.NET сразу отбрасывается, у него другие цели.
Если не очень важна: Java + SWT (как вариант Java + Swing, но это хуже). JRE весит всего 15 МБ, если его встроить в приложение и выкинуть ненужные библиотеки - будет довесок всего мегабайт в 10, мелочь по современным меркам.
Python стоит использовать если скорость совсем не критична и, самое главное, удасться найти программистов.
.NET сразу отбрасывается, у него другие цели.
Ну откуда такая убеждённость, что "Java + Swing" хуже, чем "Java + SWT"? Вы сравнивали? По каким критериям?
Я сравнивал на примере Eclipse 3.2 и Netbeans 6.0.
На Windows приложения Java+Swing работают не медленнее, чем приложения Java+SWT.
На FreBSD 6.2 приложения Java+Swing работают заметно медленнее, чем приложения Java+SWT, но после замены JRE 1.5 на JRE 1.6 всё чудесным образом преображается — Swing-приложения ускоряются и не оставляют шанса SWT-приложениям. Из-за этого я уже не смотрю в сторону системно-зависимой Eclipse IDE, а использую NetBeans, развёртывая среду из одного ZIP-архива, чтобы работать с проектами на Java и во FreeBSD, и в WindowsXP.
Я сравнивал на примере Eclipse 3.2 и Netbeans 6.0.
На Windows приложения Java+Swing работают не медленнее, чем приложения Java+SWT.
На FreBSD 6.2 приложения Java+Swing работают заметно медленнее, чем приложения Java+SWT, но после замены JRE 1.5 на JRE 1.6 всё чудесным образом преображается — Swing-приложения ускоряются и не оставляют шанса SWT-приложениям. Из-за этого я уже не смотрю в сторону системно-зависимой Eclipse IDE, а использую NetBeans, развёртывая среду из одного ZIP-архива, чтобы работать с проектами на Java и во FreeBSD, и в WindowsXP.
Команда разработчиков уже есть или только будет набираться? Если уже есть — самым логичным было бы предоставить выбор средства разработки именно команде.
Все беды от таких "руководителей проектов"...
Вы обогнали время. Запускаете программы прямо в мозгу? У вас в голове какая ОС стоит? =)
ОС "РАЗУМ".
Вообще, что можно посоветовать человеку, который в качестве средства кроссплатформенной разработки выбирает C++ или Python. Это все равно что в качестве молотка выбирать либо железо либо титан. К тому же, человек хочет совета по выбору платформы, не рассказав объем и хотябы примерные характеристики проекта.
Вообще, что можно посоветовать человеку, который в качестве средства кроссплатформенной разработки выбирает C++ или Python. Это все равно что в качестве молотка выбирать либо железо либо титан. К тому же, человек хочет совета по выбору платформы, не рассказав объем и хотябы примерные характеристики проекта.
Utorrent работает только на win платформе. Какое же оно мультиплатформенное?
Я думаю, что всетаки Java , но все зависит от апликации, а то будем до утра спорить кто сильнее - слон или кит.
к сожалению, ява требует установки фреймворка, что для меня неприемлимо.
так зачем было начинать дискуссию и ставить ее(яву) как вариант? Надо было создать тему - поиск програмистов питон/пхп.. и всем было-бы все ясно. И еще, я не очень понимаю проблемы установки виртуальной машины. Всегда можно интегрировать в инсталяционный пакет.
для "тяжелых" приложений Ява - в самый раз. для утилиты, которая сама весит 1мб, цеплять к ней ещё 30мб инстяллятора виртуальной машины - это слишком.
кроме виртуальной машины у меня есть другие замечания к софту на Яве. все приложения, которыми я пользовался, были субъекивно "глючными". это больше вопрос качества этих приложений и моего восприятия, но тем не менее.
кроме виртуальной машины у меня есть другие замечания к софту на Яве. все приложения, которыми я пользовался, были субъекивно "глючными". это больше вопрос качества этих приложений и моего восприятия, но тем не менее.
Можно попробовать Adobe AIR или что-то подобное. Можно сделать программу переносимой на уровне исходников и делать разные версии под основные платформы
Если речь изначально идет об утилите размером в 1мб, то сильно много пафоса и раздумий на эту тему. Если о нормальном серьезном rich desktop app — то jre отлично интегрируется в пакет. Кстати, почему минус "необходимость установки фреймворка" был забыт для варианта с питоном?
ну не могу согласиться - сегодня утилита в 1мб, завтра на её основе может вырасти большое приложение. от фундамента многое зависит, переписывать потом никто не будет.
для питона, насколько мне известно, существуют утилиты, которые компилируют программы на питоне в EXE, которая не требует установленного Python-окружения. у меня вот Питона нет, а MusicBrainz Picard работает.
для питона, насколько мне известно, существуют утилиты, которые компилируют программы на питоне в EXE, которая не требует установленного Python-окружения. у меня вот Питона нет, а MusicBrainz Picard работает.
Ну не соглашайтесь, дело ваше :) "Утилита, компилирующая в exe", есть и для java. Работают они — одинаково, и технический специалист объяснит вам, как именно. Это хорошая такая ирония от мира IT. :)
Может быть Вы объясните? Насколько я понимаю, для Java необходимо устанавливать фреймворк, для Питона - просто положить DLL'ку в папку. Где я неправ?
"Компиляция" в бинарник для динамического языка бывает ровно одного вида: мы берем необходимые платформозависимые бинарники, платформонезависимый стафф типа .py-библиотек или jar-ников, все это сваливаем в одну кучу в один файл, тупо зипом, и вначале втыкаем код, который умеет все это на лету разворачивать и запускать. По сути дела, это _выглядит_ как запускаемый бинарник, но в реальности компиляции в машинный код не происходит, да и не может произойти, для динамически-то типизируемого языка. Ну и для Java то же самое. Такого рода "упаковка" выглядит для некоторых людей неким психологическим преимуществом, потому такие утилиты и появились. Опять же, это, технически, ничем не отличается от простого запускающего скрипта, который берет ваш питон/яву из некоей подпапки myproject/bin, указывает ей, что ее любимые библиотеки лежат в некоей подпапке myproject/libs, и запускает. И кстати, для этого не требуется "устанавливать" (в вашей терминологии) фреймворк - его достаточно "просто положить в папку", опять же, вашими словами. Я не готов биться за дотнет, но с питоном и java это точно так.
Далее, логично предположить, что статически типизируемый, компилируемый язык типа Java теоретически можно было бы компилировать не в байткод для JVM, а напрямую в честные бинарники. И оказывается, что это предположение уже дважды реализовано на практике: опенсорсным/кросплатформенным gcj, и еще какой-то проприетарной утилитой под win32. Это, в общем-то, "честная" компиляция, которой значительно сложнее добиться на базе динамического языка, но что самое интересное — это неправильный метод употребления интерпретируемых языков. Но, опять же, возможно есть задача, в которой это принципиально, тогда почему бы нет.
Примерно так, если вкратце.
Далее, логично предположить, что статически типизируемый, компилируемый язык типа Java теоретически можно было бы компилировать не в байткод для JVM, а напрямую в честные бинарники. И оказывается, что это предположение уже дважды реализовано на практике: опенсорсным/кросплатформенным gcj, и еще какой-то проприетарной утилитой под win32. Это, в общем-то, "честная" компиляция, которой значительно сложнее добиться на базе динамического языка, но что самое интересное — это неправильный метод употребления интерпретируемых языков. Но, опять же, возможно есть задача, в которой это принципиально, тогда почему бы нет.
Примерно так, если вкратце.
вот спасибо, прояснили.
это понятно, что компиляции динамических языков не бывает. пользователю плевать на компиляцию - главное, чтобы инсталлятор был из одного файла. чем проще, тем больше пользователей пройдут вперед по воронке продаж, понимаете?
это понятно, что компиляции динамических языков не бывает. пользователю плевать на компиляцию - главное, чтобы инсталлятор был из одного файла. чем проще, тем больше пользователей пройдут вперед по воронке продаж, понимаете?
Понимаю. И эта-то проблема вообще никак не связана с компиляцией. То есть, если вы боитесь окошка с непонятной простому деревенскому валенку надписью "нажмите Next, чтобы установить JRE 1.6.0_u6", то не бойтесь — ее не будет. Вообще, самой "установки", как таковой, не будет — просто jre будет несколькими из тех файлов, которые юзер получит вываленными на винт, когда пройдет процесс инсталляции продукта. Если вы не назовете эту подпапочку "jre" — он может вообще так никогда и не узнать, на чем работает его софтина.
Компиляция динамических языков очень бывает. Есть компилер PHP, называется pcc. И даже работает. За одним исключением - не может обработать функцию eval(), но если ее не использовать - то вперед.
http://www.roadsend.com/home/index.php?pageID=compiler
http://www.roadsend.com/home/index.php?pageID=compiler
У меня Java тоже нет, точнее я ее не устанавливал. А minecraft прекрасно работает. Так что Java тоже как бы собирается в пакет.
Но лично я бы посоветовал вам все-таки C++. Про скорость разработки у Вас неполная информация. Общее число строк кода на специфические функции для приложения займут примерно одинаковый объем что на питоне, что на си. Но на си вы будете иметь всегда свежие версии библиотек, а на питоне только те, которые кто-то не поленился портировать.
Хотите пример — пожалуйста: на Python для работы с OpenGL наиболее активно используется библиотека pyglet, которая основана на сишной glut/freeglut. И никто особо не волнуется по поводу того, что в последних версии OpenGL большая часть функций glut объявлена устаревшей и рекомендовано использовать glm.
Смысл примера в том, что на C++ ваш проект будет всегда «в тонусе», не будет использовать устаревшие библиотеки уже с этапа проектирования.
Но лично я бы посоветовал вам все-таки C++. Про скорость разработки у Вас неполная информация. Общее число строк кода на специфические функции для приложения займут примерно одинаковый объем что на питоне, что на си. Но на си вы будете иметь всегда свежие версии библиотек, а на питоне только те, которые кто-то не поленился портировать.
Хотите пример — пожалуйста: на Python для работы с OpenGL наиболее активно используется библиотека pyglet, которая основана на сишной glut/freeglut. И никто особо не волнуется по поводу того, что в последних версии OpenGL большая часть функций glut объявлена устаревшей и рекомендовано использовать glm.
Смысл примера в том, что на C++ ваш проект будет всегда «в тонусе», не будет использовать устаревшие библиотеки уже с этапа проектирования.
Гляньте сюда - https://jdk6.dev.java.net/6u10ea.html
Да и, кстати, можно вставлять java фреймворк в инсталлер своего приложения.
Для нашей корпоративной софтины такой инсталлер вместе с самим приложением весит 30 мб.
Что по сути не так уж и много.
Для нашей корпоративной софтины такой инсталлер вместе с самим приложением весит 30 мб.
Что по сути не так уж и много.
Большой минус Java с точки зрения пользователя - необходимость устанавливать фреймворк. Это безусловно сложнее установки Flash player'а и часто становится pain in the ass. И размер инсталлятора (я качал 80+ мб), и постоянная путаница в названиях (JRE, J2SE, JDK, JVM, ...) не играют на руку разработчикам приложений под Java.
Боюсь тут вы не совсем правы. Обычный пользователь редко качает сырой исходник, а целиком инсталляционный пакет под свою систему. И вопрос как поставить JRE ложиться на инсталлятор не затрагивая пользователя. Тоже можно сказать и про .NET .
В качестве примера подобного пакета я могу привести Flex Builder 3.
Не соглашусь. Я сам ставил себе много софта, который использует Java, и несколько раз был в тупике. Меня отсылали на сайт Sun, разобраться в котором мне было очень сложно - около 30 минут скачивания и установки различных пакетов.
Кроме того, размер самого фреймворка тоже играет негативную роль. Если инсталлятор начинает качать что-то из интернета, то часто закрывается мной.
На мой взгляд, Java отличный выбор для "крупного" софта вроде сред разработки. Но для маленькой утилитки скачивание Java может быть препятствием.
Кроме того, размер самого фреймворка тоже играет негативную роль. Если инсталлятор начинает качать что-то из интернета, то часто закрывается мной.
На мой взгляд, Java отличный выбор для "крупного" софта вроде сред разработки. Но для маленькой утилитки скачивание Java может быть препятствием.
Если вы сталкивались с подобным софтом это не значит что в инсталлятор нельзя включить полную версию JRE. Я специально привел пример.
Могу привести еще один. В свое время опера предлагала 2 версии для скачки (как сейчас не знаю, не пользуюсь ей) 1 версия чистый дистрибутив для продвинутых пользователей. И второй, рекомендованный, с JRE в комплекте.
Что считать маленькой утилитой? Azereus (битторрент клиент) большая или маленькая утилита?
Могу привести еще один. В свое время опера предлагала 2 версии для скачки (как сейчас не знаю, не пользуюсь ей) 1 версия чистый дистрибутив для продвинутых пользователей. И второй, рекомендованный, с JRE в комплекте.
Что считать маленькой утилитой? Azereus (битторрент клиент) большая или маленькая утилита?
Azureus - недавно ставил. Для меня - скорее средняя утилита, так как в ней есть много GUI, но её далеко до скажем Eclipse. Azureus написан на Java?
Угу. Причем он имеет общие корни с эклипосом.
>> Для меня - скорее средняя утилита, так как в ней есть много GUI
А что, "большая-маленькая" определяется по кол-ву GUI?
Например, у меня есть система, у которой GUI - три экрана web-интерфейса. А в бэкэнде этого всего - огромный процессинг данных. Большая или маленькая получается у меня система? ;)
А что, "большая-маленькая" определяется по кол-ву GUI?
Например, у меня есть система, у которой GUI - три экрана web-интерфейса. А в бэкэнде этого всего - огромный процессинг данных. Большая или маленькая получается у меня система? ;)
насчет 80 Mb - размер JRE - 14 метров. В принципе его еще можно сократить, ну и как уже обсуждалось ниже добавить в дистрибутив.
Кстати - если на то пошло, то есть даже программки, которые вшивают JRE прямо в exe файл. Тоесть на врод - jar файл - выход exe. Сам не пользовалься ибо windows не сталкивался, а весь софт распространяем просто с jre, но как вариант народ пробовал - нравиться.
Кстати - если на то пошло, то есть даже программки, которые вшивают JRE прямо в exe файл. Тоесть на врод - jar файл - выход exe. Сам не пользовалься ибо windows не сталкивался, а весь софт распространяем просто с jre, но как вариант народ пробовал - нравиться.
Не обижайтесь конечно, но я считаю что руководитель проекта должен быть профессионал, кем вы не являетесь, и не надо портить жить вашего стартапа в самом начале - дайте возможность выбора платформы и системы профессионалам, прогарммистам, архитекторам, и т.д., потому что почти в каждом вашем посте одни заблуждения и маллленькая доля правды. Вы говорите что надо устанавливать фраймворк для джавы - но их надо и для .нет и для питона, только для c++ не надо. Если приложение маленькое то возможно вы не наступите на грабли в c++, если конечно будете иметь более или менее толкового программиста, но время разработки будет увеличено как минимум в два раза, т.к. надо будет как минимум 3 платформенно зависимых приложения
я не обижаюсь, век живи - век учись.
что касается профессионализма - предел не достижим, да и существует огромное количество зайцев, за которыми невозможно угнаться. я предпочитаю нанимать профессионалов на работу, чем самому вешать на себя этот ярлык.
для .NET фреймворк устанавливать нужно - я об этом написал. для Python - не нужно, посмотрите программы на нем. он переписывает в директорию приложения DLL'ку, которая дальше всё запускает.
такой же вариант меня полностью устроит в случае C# и Java, но его нет.
что касается профессионализма - предел не достижим, да и существует огромное количество зайцев, за которыми невозможно угнаться. я предпочитаю нанимать профессионалов на работу, чем самому вешать на себя этот ярлык.
для .NET фреймворк устанавливать нужно - я об этом написал. для Python - не нужно, посмотрите программы на нем. он переписывает в директорию приложения DLL'ку, которая дальше всё запускает.
такой же вариант меня полностью устроит в случае C# и Java, но его нет.
кстате если пошла такая пьянка до и для С++ надо доставлять рантайм (по крайне мере С++ скомпилированный в VS8.0)
Рантайм можно просто положить рядом, а можно (не всегда правда) слинковать статически.
C++, скомпилированный в VS8.0 - Managed C++, а рантайм для него - .NET
Да, нужно, если используется STL, или MFC.
Но только в том случае, если проект требует их включения как DLL, в обратном случае можно статически включать.
Но только в том случае, если проект требует их включения как DLL, в обратном случае можно статически включать.
Я конечно не специалист.
Но вроде для С++ тоже надо, если это конечно не консольная апп.
GTK+ QT?
Но вроде для С++ тоже надо, если это конечно не консольная апп.
GTK+ QT?
как пример приложения, написанного на python - bittorrent
Если останавливаться на С++, я бы подумал о Qt - очень неплохая кроссплатформеняя библиотека. Так же интересна привязка Adobe AIR i Web Services (Java или ASP.NET, могут быть другие). При этом получаем RIA с возможностью оффлайн работы. Замечу, что флаш иже опенсорс, так что поддержка этой группы людей со временем будет крепчать, что не скажешь о SilverLight (мое личное мнение, возможно все пойдет совсем не так %) ).
Возможна интеграция Adobe AIR и Java, на основе AMF протокола, по сравнению с SOUP он намного эффективней. Для такого типа интеграции можно использовать уже бесплатный и опенсоурс пакет - Adobe Data Service (сейчас этот пакет называется BlazeDS: язык Java, также нужен Аpplication server, например JBoss. Больше инфы http://opensource.adobe.com).
Хорошая тема и очень актуальная. Сам участвую в проекте Adobe Flex и ASP.NET Web Services и проблема переносимости проектов волнует уже давно (речь идет о проектах уровня предприятий). Было бы интересно услышать мнение/опыт других исполнителей подобных проектов.
Надеюсь, был хоть сколько полезен :)
Возможна интеграция Adobe AIR и Java, на основе AMF протокола, по сравнению с SOUP он намного эффективней. Для такого типа интеграции можно использовать уже бесплатный и опенсоурс пакет - Adobe Data Service (сейчас этот пакет называется BlazeDS: язык Java, также нужен Аpplication server, например JBoss. Больше инфы http://opensource.adobe.com).
Хорошая тема и очень актуальная. Сам участвую в проекте Adobe Flex и ASP.NET Web Services и проблема переносимости проектов волнует уже давно (речь идет о проектах уровня предприятий). Было бы интересно услышать мнение/опыт других исполнителей подобных проектов.
Надеюсь, был хоть сколько полезен :)
ashoot, спасибо за информацию по теме - поизучаю эти платформы. Тема, действительно, актуальная, при этом однозначного решения пока не видно.
Вот сам собирался написать по поводу AIR платформы. Кроссплатформенное решение (ждем в ближайшем будущем выпуска под linux, alpha уже тестируеться во всю), очень малый размер фрэймворка (ну раз уж так его в этой теме называют, хотя это скорее виртуальная машина или плеер или интерпретатор...). Да и в принципе оч много плюшек, включая коммьюнити правда русское не слишком большое но англоязычное оч даже...
Да, для небольших приложений мне больше всего привлекательнее то направление, которое выбрал Adobe в AIR.
*более привлекательно
Ну положим масштабы приложения это уже решение разработчика, так было уже масса примеров когда изначально не приспособленный инструмент (язык) в умелых руках делал чудеса. В данном случае чтобы абстрагироваться от масштабов можно использовать AIR как кроссплатформенную свободную и интуитивно понятную оболочку.
ЗЫ как последний пример Alternative3d по сути не целевое использование флэша но судя по всему оно того стит :)
ЗЫ как последний пример Alternative3d по сути не целевое использование флэша но судя по всему оно того стит :)
Обратите внимание на использование ресурсов =). Это все таки не оправдывает использование флеша. В свое время Директор делал чудеса покруче этих (в те то годы!)
Согласен и об этом написал что "не целевое использование". Положим директор для меня остается загадкой, вроде сложившийся продукт но не нашедший своего места на массовом рынке, последний коммерческий проект на нем, в котором я принимал участие был убран в стол изза не разрешимых проблем, видимо в большинстве своем связанных с отсутсвием достаточной Информационной базы.
Меня в AIR смущает пока качество Linux реализации (например, большие проблемы с кодировками) и языки программирования. Я правильно понимаю, что там ECMAScript (JS или ActionScript) и есть ли возможность критические места написать на низкоуровневом языке (уровня Java).
с каких пор java,mono,dotnet стали фреймворком?
Java SDK, MONO и .NET - Сollections framework, а не Software framework как Struts.
Java SDK - это собственно компиллятор, виртуальная машина, библиотеки, вспомогательные утилиты для разработки.
Collection Framework - это просто часть библиотеке ядра
Collection Framework - это просто часть библиотеке ядра
Вот! Вот слышат же люди звон! :) Вопрос: о каких именно collections речь? ;)
1. .NET Framework
2. Если верить википедии, термин Framework означает "простую концептуальную структуру, используемую для решения сложной, проблемной задачи". Собственно, вся нескончаемая библиотека классов Java, .NET Framework для этого и предназначена =)
2. Если верить википедии, термин Framework означает "простую концептуальную структуру, используемую для решения сложной, проблемной задачи". Собственно, вся нескончаемая библиотека классов Java, .NET Framework для этого и предназначена =)
Вообщето есть и XUL просто, удобно и весело
ага. учитывая, что в моей утилите почти нет GUI - очень весело :)
только некоторые ограничения XUL могут отринуть его как возможный вариант :)
Вы меня опередили, как раз хотел это написать. Плюсы разработки XUL-based приложений — это, во-первых, простота работы с веб (полезно для разного рода RIA mashups), во-вторых, никакого стомегабайтного фреймворка, и наконец в-третьих, очень короткая и радостная (по меньшей мере для веб-программиста/верстальщика) learning curve, т.к. используются до боли знакомые клиентские технологии: XUL (читай: практически XHTML), JavaScript, CSS. Ну и native bindings через XPCOM — задача вполне разрешимая, если без них совсем уж не обойтись.
для desktop приложений не всё так радостно... UDP серверных сокетов нет. Окна нельзя прятать. Z уровнем управлять нельзя, отсутcтвие некого подобия volatile (a.setAttribute("src", y); a.setAttribute("src", y); gecko проигнорирует второй вызов), тормознутость что ппц, слабенькая документация (по сравнению с Qt) и многое другое...
Странные минусы у Java...
Необходимость установки фреймворка - в трех из четырех приведенных Вами случаев - это норма. А JRE весит в два раза меньше .Net фреймворка.
Кривость GUI - приложения на Java могут выглядеть точь-в-точь как родные приложения для win32 (Пример - упомянутый Вами же Эклипс)
Низкая производительность - если интересно, найду ссылочку, где сравниваются Java, C#, C++ на одном и том-же алгоритме. В кратце - Java ни чем не хуже (а в некоторых случаях и лучше) С# и С++.
А для конкретного, описанного Вами приложения, я не вижу смысла делать его кросс-платформенным.
Необходимость установки фреймворка - в трех из четырех приведенных Вами случаев - это норма. А JRE весит в два раза меньше .Net фреймворка.
Кривость GUI - приложения на Java могут выглядеть точь-в-точь как родные приложения для win32 (Пример - упомянутый Вами же Эклипс)
Низкая производительность - если интересно, найду ссылочку, где сравниваются Java, C#, C++ на одном и том-же алгоритме. В кратце - Java ни чем не хуже (а в некоторых случаях и лучше) С# и С++.
А для конкретного, описанного Вами приложения, я не вижу смысла делать его кросс-платформенным.
Норма для разработчика не означает радости у пользователя.
Поясните свою мысль про "не вижу смысла делать его кросс-платформенным"? Для каждой платформы писать свою версию приложения?
Поясните свою мысль про "не вижу смысла делать его кросс-платформенным"? Для каждой платформы писать свою версию приложения?
>> Поясните свою мысль про "не вижу смысла делать его кросс-платформенным"? Для каждой платформы писать свою версию приложения?
Какова целевая аудитория продукта? Из Вашего описания, я сделал вывод (вполне вероятно, что неверный), что целевая аудитория, будет на 90% win-users.
Да и разве предварительно выбранный Вами С++ позволит !нормально! писать и поддерживать кросс-платформенное приложение?
Какова целевая аудитория продукта? Из Вашего описания, я сделал вывод (вполне вероятно, что неверный), что целевая аудитория, будет на 90% win-users.
Да и разве предварительно выбранный Вами С++ позволит !нормально! писать и поддерживать кросс-платформенное приложение?
Вы правы, целевая аудитория будет 90% win users. При этом стратегия развития подразумевает старт проекта на mac users, как бы парадоксально это не звучало.
Про C++ сказать Вам не могу - я не программист. Я написал эту статью, чтобы послушать мнения экспертов - в том числе и Ваше :) В чем проблема с С++?
Про C++ сказать Вам не могу - я не программист. Я написал эту статью, чтобы послушать мнения экспертов - в том числе и Ваше :) В чем проблема с С++?
Как программист, использующий в качестве своего основного языка C++, могу сказать - нет никакой проблемы. Qt - один из лучших инструментов для разработки кросс-платформенных приложений, особенно если дело касается GUI. Стоит недёшево, но на уровне зарплат разработчиков его стоимость быстро теряется. Ну, или пишите ПО под GPL, от этого всем будет только лучше :)
В качестве наглядных примеров использования Qt - Opera и Skype.
В качестве наглядных примеров использования Qt - Opera и Skype.
Проблема с C++ очень простая: деньги. Человек не слишком высокой квалификации может легко привести C++ до состояния, когда его придётся переписывать полностью. Python, Java - тут такое сделать сложнее. Соответственно разработка на C++ всегда обходится дороже: либо вы нанимаете более крутых (а стало быть и дорогих) специалистов сразу, либо вам приходится тратить деньги на переработку каких-либо частей.
В случае нацеливания на мак, я бы лучше для него свою версию написал. Иначе ваше приложение будет выглядеть чужеродно в среде Mac OS X.
java под мак весьма неплохо выглядит, да и QT тоже
Скорее всего, имелся в виду не столько внешний вид GUI, сколько native feel приложения. На Mac OS X многие вещи понимаются иначе, нежели под виндовс, например, отображение статуса программы через иконку в доке, которая является одновременно (в терминах Windows) и tray icon, и кнопкой приложения на taskbar-е.
Еще пример, правда, на сей раз про Linux: у многих пользователей system tray на экране отсутствует в принципе, поэтому стандартная для Windows-приложений практика — молча стартовать и висеть в трее — здесь не подходит, т.к. пользователь, запустив программу, не пронаблюдает никакой ответной реакции, расстроится и в конечном итоге уйдет к конкурентам.
Еще пример, правда, на сей раз про Linux: у многих пользователей system tray на экране отсутствует в принципе, поэтому стандартная для Windows-приложений практика — молча стартовать и висеть в трее — здесь не подходит, т.к. пользователь, запустив программу, не пронаблюдает никакой ответной реакции, расстроится и в конечном итоге уйдет к конкурентам.
Да естественно позволит и именно кроссплатформенное. Как уже говорили выше есть замечательная библиотека QT. Кроме всех своих достоинств она ещё обладает самой хорошой документацией. Разобраться может даже новичок. Как раз недавно написал именно программу для закачки сайтов, использовал Qt и libcurl. Все получилось просто замечательно.
Не сомневаюсь.
Но имея опыт поддержки кросс-платформенного внутрикорпоративного продукта на С++ и Qt, и последующее его переделывание на java, я выбираю второе :)
Но имея опыт поддержки кросс-платформенного внутрикорпоративного продукта на С++ и Qt, и последующее его переделывание на java, я выбираю второе :)
У нас ведется разработка кросплатформенного софта на Qt, WxWidgets, Python. Если вы имеете отрицательный опыт поддержки кроссплатформенного продукта на С++, не стоит высказыватся в таком ключе. Отвечаю, С++ позволяет. Более того скажу, язык - это инструмент, гораздо большее влияние оказывает выбор фреймворка, ну и естественно правильное и разумное проектирование приложения и многое другое.
о, как я вас понимаю ;)
c++/QT приложения получаются почти совместимы и почти переносимы. Даже pyqt программы под win имеели свои маленькие, но очень раздражающие приколы. А под linux приколы были немного другие
c++/QT приложения получаются почти совместимы и почти переносимы. Даже pyqt программы под win имеели свои маленькие, но очень раздражающие приколы. А под linux приколы были немного другие
хорошая статья про сравнение алгоритмов управления памятью - http://www.ibm.com/developerworks/ru/lib…
В языках-платформах проблемы нет никакой. Есть проблема в головах людей, которые занимаются разработкой ПО. Я не хочу работать с джава-проектами не из-за языка, а из-за того, что джавой занимается слишком много самоуверенных болванов. С ними работать — зря тратить время. Я сам использую Руби, но не могу сказать, что руби-сообщество на голову умнее и интереснее джава-сообщества. Там тоже полно маразма. Но сам язык для меня гораздо удобнее и легко интегрируется с разными сиплюсами и джавами. Проблема остается лишь в людях, 95% которых — невежды.
главное иметь самомнение=)
Джава программистов не очень много(ну например по сравнению с пхп:))
А руби программистов вообще практически нет, так что шанс нарваться на болвана стремится к 0?
Как же хорошо дело обстоит с PL/1 каким- нибудь!:)
А руби программистов вообще практически нет, так что шанс нарваться на болвана стремится к 0?
Как же хорошо дело обстоит с PL/1 каким- нибудь!:)
Начнем с того, что большинство пхп-программистов — не программисты (не инженеры). Во-вторых, меня совершенно не интересует сколько в мире джава-, си-, пси- и прочих программистов. Я знаю очень небольшую часть и тех, и тех и в каждой среде вижу небольшую долю грамотных людей и огромную — безграмотных.
Если кому-то требуется совет в духе "какой фреймворк выбрать", то я скажу просто: найдите инженеров, которые заинтересованы в решении задачи и знают, как её решать. А какой фреймворк они выберут — это уже дело их профессионализма и взглядов на жизнь.
Если кому-то требуется совет в духе "какой фреймворк выбрать", то я скажу просто: найдите инженеров, которые заинтересованы в решении задачи и знают, как её решать. А какой фреймворк они выберут — это уже дело их профессионализма и взглядов на жизнь.
Это шутка была:)
А насчет постановки вопроса - полностью согласен.
Это также как новичкам советуют выбирать дистрибутив линукса - такой же как у ближайшего гика:)
Лучше положится на разработчиков, и делать на том что они лучше знают или считат целесообразным использовать в конкретном случае.
А такие вопросы имхо нужно задавать например при перепрофиллировании всей организации, например хотим уйти с С++ но не знаем в какую сторону:)
Хотя при таком подходе нужно както удостовериться что команда не из тех самых 95 процентов...
А насчет постановки вопроса - полностью согласен.
Это также как новичкам советуют выбирать дистрибутив линукса - такой же как у ближайшего гика:)
Лучше положится на разработчиков, и делать на том что они лучше знают или считат целесообразным использовать в конкретном случае.
А такие вопросы имхо нужно задавать например при перепрофиллировании всей организации, например хотим уйти с С++ но не знаем в какую сторону:)
Хотя при таком подходе нужно както удостовериться что команда не из тех самых 95 процентов...
Возможно, вам имеет смысл посмотреть в сторону Haskell... Community, конечно, не сказать чтобы поражает воображение, зато непрограммистов практически нет. Не выдерживают, уходят :)
На яве, или на C++ под QT4 компилить под разные платформы...
Java определенно. Во первых JRE весит мегабайт 13 - 16 в зависимости от платформы и версии, а не 80!! Во вторых уж кого кого, а джава программистов всегда хватало. А кроссплатформенность С++ тоже под вопросом. Я разрабатывал кроссплатформенные GUI на С++ 2 года. И понял, что пусть немного подтормаживает Java, чем разбираться в миллионах тонкостей программирования и сборки С++ приложений. Ну, конечно если у вас есть супер команда сиплюсплюсников, которая никуда не денется, то С++ рулит. А если сегодня один, а завтра другой, то Java лучше всего подходит. Согласен с постом выше, про то что дело в головах.
>> Во вторых уж кого кого, а джава программистов всегда хватало.
А хороших ява-программистов - мало. Постоянно нахожусь в поиске именно хороших. Среди потока кандидатов, на должности ява-программистов разного уровня, хороших очень и очень мало :( Конечно среди них есть много таких, которых взять да подучить, и получить хорошего программиста, но такой возможности у меня нет :(
А хороших ява-программистов - мало. Постоянно нахожусь в поиске именно хороших. Среди потока кандидатов, на должности ява-программистов разного уровня, хороших очень и очень мало :( Конечно среди них есть много таких, которых взять да подучить, и получить хорошего программиста, но такой возможности у меня нет :(
Ой как это знакомо, джава программисты, ИМХО, вообще особый подвид программистов они особые люди в принципе (почему так и не выяснил).
Но здесь как почти не где хороший=дорого, очень хороший=очень дорого, мыслящий очень хороший программист=редкий и почти бесценный :) ИМХО
Но здесь как почти не где хороший=дорого, очень хороший=очень дорого, мыслящий очень хороший программист=редкий и почти бесценный :) ИМХО
А где много хороших программистов? На C/C++ ?
Смеялсо. А что, в ваших краях много _хороших_ С++ программистов? Способных писать кроссплатформенные приложения? А вы их запросы по зарплате уже видели? :) :)
Просто объективно С++ гораздо сложнее явы и как язык и как средство разработки (писать на нём сложнее), и, особенно, как кроссплатформенное средство (в яве это происходит само по себе). По-моему, найти хорошего С++ программиста чуть не на порядки сложнее, чем сопоставимого явского. И размер их зарплатных требований тот ещё :)
Просто объективно С++ гораздо сложнее явы и как язык и как средство разработки (писать на нём сложнее), и, особенно, как кроссплатформенное средство (в яве это происходит само по себе). По-моему, найти хорошего С++ программиста чуть не на порядки сложнее, чем сопоставимого явского. И размер их зарплатных требований тот ещё :)
uTorrent не кроссплатформенный
да, явно не лучший пример, однако, на оф сайте заявлена поддержка wine..
Wine - это запускач Windows-программ. Из небольших утилиток работают почти все. Это с монстрами типа Photoshop или MS Office проблемы...
спасибо что разъяснил, я думаю уже люди далекие от никсов знают что wine это реализация winapi... с прослойками для совместимости с никсами(файловая система, вывод через х сервер, работа с сетью, и.т.д), есть так же libwine позволяющий собрать "нативное" приложение, как например гугл поступил с picaso.
P.S. Photoshop до версии CS2 включительно уже давно работает как часы..
P.S. Photoshop до версии CS2 включительно уже давно работает как часы..
>Photoshop до версии CS2 включительно уже давно работает как часы.
Возможно, я просто не умею его готовить, но цс2 мне так и не удалось запинать для работы под вайном. Сначала жутко тормозит, потом молча падает или виснет. Работой я это назвать ни как не могу. У меня гента, поэтому вайн почти самый свежий.
Возможно, я просто не умею его готовить, но цс2 мне так и не удалось запинать для работы под вайном. Сначала жутко тормозит, потом молча падает или виснет. Работой я это назвать ни как не могу. У меня гента, поэтому вайн почти самый свежий.
А как дела с флеш редактором ? Пока единственное что останавливает переход на линукс...
Добавьте ещё EVE Online:
http://wiki.python.org/moin/StacklessPyt…
"Although in alpha state, Stackless is being heavily used by commercial applications. One outstanding example is the Massive MultiPlayer Online Game EVE http://www.eve-online.com/ which is completely based upon Stackless technology."
http://wiki.python.org/moin/StacklessPyt…
"Although in alpha state, Stackless is being heavily used by commercial applications. One outstanding example is the Massive MultiPlayer Online Game EVE http://www.eve-online.com/ which is completely based upon Stackless technology."
С точки зрения деплоймента (особенно для софтин, интенсивно общающихся по сети), у джавы есть серьёзное достоинство по имени Java Web Start, не имеющее (насколько я знаю) аналогов на остальных рассматриваемых платформах. Грубо говоря, надо один раз в жизни поставить JRE, а дальше проблемы с инсталляцией и апдейтами решаются автомагически.
Могу еще добавить, что есть еще JavaFX, который окончательно выйдет в конце этого года. Красивость интерфейса - на уровне флеша/флекса
[Не холивар] А зачем "в конце этого года" когда есть сейчас flex, air? Кроме момента с кадрами(готовых java программеров действительно много, по крайней мере есть из чего выбрать даже в россии в отличии От..)
Потому что из JavaFX доступны все наработки на яве, которых намного больше чем на флексе.
Хотя это если они важны :). Если же десктоп-клиент - по сути тонкий клиент, а вся логика сосредоточена на сервере, то конечно флекса с эйром хватит...
Хотя это если они важны :). Если же десктоп-клиент - по сути тонкий клиент, а вся логика сосредоточена на сервере, то конечно флекса с эйром хватит...
Тобиш сходимся в том что проблема не в "языке", а в базе готовых решений (доки, примеры, коммьюнити, специалисты). Согласен.
Не совсем. Я хочу сказать, что в классе десктоп-приложений с небольшим количеством клиентской логики Flex и Java по большей части равноценны (последняя, возможно в данном случае имеет некоторый оверхед). Но при некотором уровне сложности Flex/Air становится непригодным принципиально - отсутствие дженериков, жесткой типизации и тд, а также чего то вроде JMX/(кому что) делают свое грязное дело. По личному опыту могу сказать, что в больших проектах с большим количеством разработчиком возникает множество проблем именно из-за особенностей архитектуры флекса. Я не могу быть увереным (а часто вообще не знаю) что мне вернет метод такой то, что будет в событии, и какие объекты будут лежать в коллекции.
В санкт петербурге найти java программиста, который сможет знать технологию java хотябы на 60 % от SJCP очень сложно...
у .net уже есть какое-то жалкое её подобие, кстати.
Как человек с некоторым опытом коммерческой разработки на C++ (4 года), советую — забейте на C++. Берите питон + кроссплатформенную библиотеку для GUI, например wxWindows. Питон это однозначно меньшие риски чем C++ в вашем случае. Если в каких-то конкретных местах вам будет не хватать производительности именно из-за питона — перепишете этот кусочек в виде C++ библиотеки.
Насчет "большого количества кадров" на C++ — это совершенно не так. Я не знаю как с питоном, но качественных нетрудоустроенных программистов на C++ практически нет (по крайней мере в Москве).
Насчет "большого количества кадров" на C++ — это совершенно не так. Я не знаю как с питоном, но качественных нетрудоустроенных программистов на C++ практически нет (по крайней мере в Москве).
Вот я стою перед выбором: Python или С++.
Python мне нравиться больше, но смогу ли я найти работу с таким языком? Я знаю, что хороший программист всегда найдет работу, но "хорошому программисту" нужно устроить в первый раз на работу и набраться опыта.
Стоит ли идти на риск?
Python мне нравиться больше, но смогу ли я найти работу с таким языком? Я знаю, что хороший программист всегда найдет работу, но "хорошому программисту" нужно устроить в первый раз на работу и набраться опыта.
Стоит ли идти на риск?
Ну, проблемы будут если только вы живете в небольшом городе где только 1-2 конторы, и они пишут на C++ а не питоне, и вы категорически не рассматриваете фриланс как вариант. Но тут все и так очевидно :)
А если глобально подходить — есть серьезный дефицит как программистов на питоне, так и на C++, но последний теряет и дальше будет терять долю рынка (это не значит что программисту на плюсах нечего будет кушать — вон, посмотрите на буржуйских сайтах, сколько до сих пор требуется разработчиков на коболе, но это, конечно, не новые проекты).
А если глобально подходить — есть серьезный дефицит как программистов на питоне, так и на C++, но последний теряет и дальше будет терять долю рынка (это не значит что программисту на плюсах нечего будет кушать — вон, посмотрите на буржуйских сайтах, сколько до сих пор требуется разработчиков на коболе, но это, конечно, не новые проекты).
Правду глаголите, поставил бы +, да не могу пока :(
Связка Python + C++, + биндинги к С/С++ библиотекам, позволяют отлично варьировать сложность проекта в плане скорость/сложность разработки.
Связка Python + C++, + биндинги к С/С++ библиотекам, позволяют отлично варьировать сложность проекта в плане скорость/сложность разработки.
что интересно, Python можно свободно заменить на Perl. Не в качестве холивара, но все же.
спасибо за совет. а Вы сами писали на питоне кроссплатформенные приложения?
приложение не требовательно к ресурсам, поэтому пойдет любая среда - как питон, так и с++.
приложение не требовательно к ресурсам, поэтому пойдет любая среда - как питон, так и с++.
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
и в эклипс и в зде можно включить OS Look and Feel и получаем родной вин интерфейс, с настолько мелкими отличиями, что обычный пользователь их и не заметит.
НЛО прилетело и опубликовало эту надпись здесь
gcj мне не очень понравился, но есть ещё excelsior jet
excelsior jet конечно мощная вещь, но мне кажется немного бесполезной:)
Т.к. в результате компиляции размер файла не уменьшается(все теже 15+ мегабайт). А прирост скорости ощутим только при ресурсоемких вычислений, тоесть для GUI бессмысленно.
Т.к. в результате компиляции размер файла не уменьшается(все теже 15+ мегабайт). А прирост скорости ощутим только при ресурсоемких вычислений, тоесть для GUI бессмысленно.
а как же дополнительная защита интеллектуальной собственности? =)
А что мешает пользоваться обфускаторами?:)
ну обфускатор-обфускатором, а нативная компиляция имхо сильней защитит.
Последний аргумент:)
excelsior jet - платный, а обсфуркаторов очень много и бесплатных, например yguard.
К томуже уровень нечитабельности компиллированного кода и кода прошедшего обсфуркацию практически одинаковый.
Большинство "кулхацкеров" отсеит. А кому ну очень сильно надо, тот и в скомпилированном разбереться:)
excelsior jet - платный, а обсфуркаторов очень много и бесплатных, например yguard.
К томуже уровень нечитабельности компиллированного кода и кода прошедшего обсфуркацию практически одинаковый.
Большинство "кулхацкеров" отсеит. А кому ну очень сильно надо, тот и в скомпилированном разбереться:)
жалко тока под линукс :) вся кроссплатформенность теряется. к тому же неизвестно что проще. поставить и скачать JRE или эту самую libgcj, то бишь JRE в нативном виде.
qt в списке явно не хватает. это качественно сделанная библиотека с ясным и могучим api, изучать который легко благодаря отличной документации и открытому коду. изначально плюсовая, но есть обвязки для питона и явы. работает почти везде. в кроссплатформенные методы завёрнуто очень многое — от gui до сети и тредов. производительность приличная.
от периода работы с ней у меня остались только положительные воспоминания.
от периода работы с ней у меня остались только положительные воспоминания.
ну тут уже говорили, но повторюсь.
AIR + Flex
Flex — это круто, AS3 — это круто.
С точки зрения мультиплатформенности — идеальный вариант. Интерфейс везде выглядит шикарно (если его сделать по человечески конечно).
Есть две проблемы. Если Flash стоит почти у всех в мире, то AIR еще далеко нет. Но тут жизнь облегчает Adobe. Автоматом сгенерируется ссылка (небольшая флешка точнее) на приложение, при нажатии на которую, если у пользователя нет AIR, то сначала скачается он, а потом само приложение. Выглядит весь процесс весьма симпатично.
Ну а еще в России хрен найдешь флекс-девелоперов, да.
AIR + Flex
Flex — это круто, AS3 — это круто.
С точки зрения мультиплатформенности — идеальный вариант. Интерфейс везде выглядит шикарно (если его сделать по человечески конечно).
Есть две проблемы. Если Flash стоит почти у всех в мире, то AIR еще далеко нет. Но тут жизнь облегчает Adobe. Автоматом сгенерируется ссылка (небольшая флешка точнее) на приложение, при нажатии на которую, если у пользователя нет AIR, то сначала скачается он, а потом само приложение. Выглядит весь процесс весьма симпатично.
Ну а еще в России хрен найдешь флекс-девелоперов, да.
НЛО прилетело и опубликовало эту надпись здесь
Вы наверняка пользовались этими приложениями лет эдак 10 назад. Когда ещё не было Джавы 6 (кстати уже ждём-недождёмся Джаву 7) А сейчас возможно пользуетесь джава приложениями и даже не подозреваете об этом.
Изначально кросплатформенность дотнета стоит под большим вопросом. .NET 3.0 не работает под Windows 2000 и ниже. У вас много пользователей под 2000? Моно не майкрософтовский продукт, я бы не стала ему беззаветно доверяться (я не имею ввиду что майкрософту можно доверять;)
Можете смело добавлять к минусам дотнета - низкую производительность, раз уж вы это добавили к Джаве. А примеры приложений вы на дотнете вообще не видели?
Межязыковая борьба ещё в библии описана. Технологии необходимо выбирать в зависимости от ваших планов на приложение и тенденции развития этих технологий, как мне кажется.
А Веб приложение вас никак не устроит?
Изначально кросплатформенность дотнета стоит под большим вопросом. .NET 3.0 не работает под Windows 2000 и ниже. У вас много пользователей под 2000? Моно не майкрософтовский продукт, я бы не стала ему беззаветно доверяться (я не имею ввиду что майкрософту можно доверять;)
Можете смело добавлять к минусам дотнета - низкую производительность, раз уж вы это добавили к Джаве. А примеры приложений вы на дотнете вообще не видели?
Межязыковая борьба ещё в библии описана. Технологии необходимо выбирать в зависимости от ваших планов на приложение и тенденции развития этих технологий, как мне кажется.
А Веб приложение вас никак не устроит?
Dash,
у нас в основном веб-приложение, которое должно скачивать файлы из интернета. Этот закачиватель должен быть desktop-приложением по определенным причинам.
Что касается Mono - я open source доверяю больше, чем Microsoft. Но больше всего я доверяю результатам эксперимента - попробовать и все вопросы снимутся.
На дотнете я видел много серверных приложений + монстры вроде MS Office. Небольшие приложения давно встречались, но удалялись по причине необходимости установки фреймворка.
у нас в основном веб-приложение, которое должно скачивать файлы из интернета. Этот закачиватель должен быть desktop-приложением по определенным причинам.
Что касается Mono - я open source доверяю больше, чем Microsoft. Но больше всего я доверяю результатам эксперимента - попробовать и все вопросы снимутся.
На дотнете я видел много серверных приложений + монстры вроде MS Office. Небольшие приложения давно встречались, но удалялись по причине необходимости установки фреймворка.
Насчет утилиты для веб-приложения по-моему Java - лучший вариант (ну или один из лучших).
Новая версия Java 6 beta 10
http://java.sun.com/developer/technicalArticles/javase/java6u10/index.html
снижает базовые размеры файла для скачивания (ядра JRE) до приблизительно 4-5 МБ.
Тем более вероятно что к окончанию разработки проекта будет выпущена Java 7 которая еще более оптимизирует эту возможность.
При этом Java предоставляет систему Java Web Start, которая предназначена специально для небольших приложений такого рода, предоставляя возможность запускать утилиту прямо из броузера и прозрачно обрабатывать обновления утилиты и т.п.
Новая версия Java 6 beta 10
http://java.sun.com/developer/technicalArticles/javase/java6u10/index.html
снижает базовые размеры файла для скачивания (ядра JRE) до приблизительно 4-5 МБ.
Тем более вероятно что к окончанию разработки проекта будет выпущена Java 7 которая еще более оптимизирует эту возможность.
При этом Java предоставляет систему Java Web Start, которая предназначена специально для небольших приложений такого рода, предоставляя возможность запускать утилиту прямо из броузера и прозрачно обрабатывать обновления утилиты и т.п.
Java - нормальный выбор, GUI там нативный, просто некоторые программы используют стандартный джавовский вид интерфейса. Виртуальную машину вполне можно включить в инсталятор, размер мегабайт на 10 - 15 увеличится. Например, если не ошибаюсь в ThinkingRock так сделали - кроссплатформенный софт для GTD.
Кстати виртуальная машина джавы все же не фреймворк:) И конечному пользователю нужен JRE, а JDK, который весит 80 мегабайт - это для разработчиков(кстати он в себя включает JRE).
C# я думаю пока рано заморачиваться, т.к. Mono все еще в разработке, и полностью аока толька первая версия используется, а в виндовсвроде уже на вторую перешли.
Еше забыли Ruby :) Был опыт, для окошек порт wxWidgets - wxRuby потом это все зажимается утилитой rubyscript2exe в екзешник в виндовс и ей же в .app файл в OS X, размер исполняемого файла GUI приложения в пределах 2х мегабайт.
Кстати wxRuby в разработке очень удобен, как мне показалось намного понятнее чем стандартный для скриптовых языков tk, да к томуже у tk GUI не нативно смотрится.
С питоном думаю также как и с руби.
Кстати, может быть не гнаться за кросплатформенностью, а платформозафисимые компоненты релизовать отдельно? Или же просто разные версии?
Если решили начать с OS X то смотрите Object-C + стандартный маковский фреймворк Cocoa. Но это только под мак.
Еще есть официальные эппловские порты JavaCocoa и RubyCocoa.
Кстати виртуальная машина джавы все же не фреймворк:) И конечному пользователю нужен JRE, а JDK, который весит 80 мегабайт - это для разработчиков(кстати он в себя включает JRE).
C# я думаю пока рано заморачиваться, т.к. Mono все еще в разработке, и полностью аока толька первая версия используется, а в виндовсвроде уже на вторую перешли.
Еше забыли Ruby :) Был опыт, для окошек порт wxWidgets - wxRuby потом это все зажимается утилитой rubyscript2exe в екзешник в виндовс и ей же в .app файл в OS X, размер исполняемого файла GUI приложения в пределах 2х мегабайт.
Кстати wxRuby в разработке очень удобен, как мне показалось намного понятнее чем стандартный для скриптовых языков tk, да к томуже у tk GUI не нативно смотрится.
С питоном думаю также как и с руби.
Кстати, может быть не гнаться за кросплатформенностью, а платформозафисимые компоненты релизовать отдельно? Или же просто разные версии?
Если решили начать с OS X то смотрите Object-C + стандартный маковский фреймворк Cocoa. Но это только под мак.
Еще есть официальные эппловские порты JavaCocoa и RubyCocoa.
ruby ?
C# примеры приложений: Microsoft Exchange Server 2007 :-)
В случае C++ могут сильно облегчить жизнь кроссплатформенные фреймворки, такие как wxWidgets. Кроме того, GTK и Qt в данный момент также собираются под все популярные платформы (правда, насколько мне известно, с GTK под Windows дела обстоят несколько лучше, нежели с Qt).
В случае с wxWidgets тулкитов ставить не нужно. В случае с GTK/Qt тулкит все же нужен, но его можно интегрировать в инсталлятор.
В случае с wxWidgets тулкитов ставить не нужно. В случае с GTK/Qt тулкит все же нужен, но его можно интегрировать в инсталлятор.
Кстати, есть еще winelib. Если задача сводится к компиляции в *nix уже имеющейся win32 codebase, возможно, это решение как раз для вашего случая.
о, я как раз хотел сказать про GTK
вроде бы Gimp и Gajim под виндой на нем работают
вроде бы Gimp и Gajim под виндой на нем работают
>GTK
лучше застрелиться
лучше застрелиться
И чем-же лучше, у гтк дела под вендой?
wxWidgets для Linux (связка с Gtk) качать нужно. При этом бибилиотека не самая маленькая :(
Вообще-то не мешало бы отметить, что кросплатформенность бывает разная. Воспроизвожу по памяти.
Кроссплатформенные прораммы бывают:
1.Совместимые по исходнику. Т.е. требующие перекомпиляции на целевой системе.
2.Совместимые по коду. Т.е. готовые к запуску на целевой системе.
2.1. Программы в псевдокоде. Требуют runtime engine (не представляю как это по-русски), а не framework
2.2. Скриптовые программы. Требуют наличия интерпретатора.
Это то, чего не хватало в начале обзора.
Кроссплатформенные прораммы бывают:
1.Совместимые по исходнику. Т.е. требующие перекомпиляции на целевой системе.
2.Совместимые по коду. Т.е. готовые к запуску на целевой системе.
2.1. Программы в псевдокоде. Требуют runtime engine (не представляю как это по-русски), а не framework
2.2. Скриптовые программы. Требуют наличия интерпретатора.
Это то, чего не хватало в начале обзора.
Меня большего смущает отсутствие нормального кроссплатформенного GUI API. FoxWidget убогие, в wxWidget мало функций (нельзя установить иконку на кнопку), GTK+ и Qt много весят. Мне нравиться Swing из Ruby (с включённым LookAndFeel, чтобы выглядело как родная ОС), но тянуть с собой Java — это сложно.
Swing из Ruby - вы наверно имели в виду Java?:)
Там все хорошо, но в итоге получается очень громоздкий код. Swing не очень выразительный.
50 строк кода чтобы форму с кнопкой создать:)
В отношении создания GUI самое лучшее что я видел, это новый сановский проект JavaFX.
Но у них там все еще сыро. Пока еще в разработке, ни документации ни примеров нет...
Там все хорошо, но в итоге получается очень громоздкий код. Swing не очень выразительный.
50 строк кода чтобы форму с кнопкой создать:)
В отношении создания GUI самое лучшее что я видел, это новый сановский проект JavaFX.
Но у них там все еще сыро. Пока еще в разработке, ни документации ни примеров нет...
Именно Swing + Ruby. JRuby позволяет обращаться к Java классам.
А я Swing приложения люблю в графическом редакторе задавать — мне очень нравиться, как у них сделано (раньше, я всё руками прописывал). Генерируемый исходник не сильно отличается от рукописного, так как задаётся взаимосвязь объектов.
Да и есть «обёртки» на Ruby для Swing для более красивого описания.
А JavaFX — это всего лишь язык программирования :) просто на нём удобнее описывать Swing интерфейс.
А я Swing приложения люблю в графическом редакторе задавать — мне очень нравиться, как у них сделано (раньше, я всё руками прописывал). Генерируемый исходник не сильно отличается от рукописного, так как задаётся взаимосвязь объектов.
Да и есть «обёртки» на Ruby для Swing для более красивого описания.
А JavaFX — это всего лишь язык программирования :) просто на нём удобнее описывать Swing интерфейс.
Теперь понятно. Всетаки между JRuby и Ruby большая разница.
Если напрямую джавовские классы использовать это не сильно интересно, все тоже огромное количество кода...
А вот про обертки - можно ссылочку?
Речь про обертки для JRuby? Потому что еще есть проект для Ruby который бридж с джавой устанавливает и доступ к swing дает(нипомню как называется, в gem'ах есть).
А насчет JavaFX - помойму интерфейсы это его чуть ли не единственное назначение:) Покрайней мере мне кажется что сану сложно с ним будет в мир RIA пробиться.
Но все же интерфейсы там делать - одно наслаждение:). Например удобно использовать как плагин в джава приложении для отрисовки GUI.
Если напрямую джавовские классы использовать это не сильно интересно, все тоже огромное количество кода...
А вот про обертки - можно ссылочку?
Речь про обертки для JRuby? Потому что еще есть проект для Ruby который бридж с джавой устанавливает и доступ к swing дает(нипомню как называется, в gem'ах есть).
А насчет JavaFX - помойму интерфейсы это его чуть ли не единственное назначение:) Покрайней мере мне кажется что сану сложно с ним будет в мир RIA пробиться.
Но все же интерфейсы там делать - одно наслаждение:). Например удобно использовать как плагин в джава приложении для отрисовки GUI.
вместо swing в данном случае можно отлично использовать groovy
qt,python+qt,ruby+qt,java(не swing!),ну или gtk
wxWidgets,Boost,C++ И более почти не чего не надо
А еще фултик есть...
очень поверхностный и плоский обзор, в которых не заторонуты куча плюсов и минусов разных систем
1) Java:
Исталятор и JRE можно собраться сразу же, для этого есть специальные утилиты и тулзы, причем open source. Поэтому пользователю не обезательно будет устанавливать JRE. К примеру у моего GUI проекта инсталятор с JRE 18 mb, а без 3Mb. Про GUI тоже абсолютно не правы - у вас есть полностью возможность творить то что вы хотите, к примеру есть библиотеки типа look and feel которые делают Vista, XP, Mac интерфейсы в одном билде (т.е. не надо под каждую систему выпускать свой билд), единственный минус в них бывают свои баги, с которыми придется бороться. Зато встроеный Swing или AWT будет всегда работать стабильно и везде... Так же не понятно как вы хотите чтоб ваше приложение поддерживало WIN32 функции при условии что оно должно быть платформенно независим. По поводу скорости java - это вообще старое заблуждение, java уже давно считается очень быстрым языком, если конечно не надо иметь доступ к видео и т.д. на прямую. Можете поискать в интернете сравнение java и c++ по основным математическим задачкам и алгоритмам, и java с ключем -server чуть больше половины тестов выигрывает ! Так же при java вы будете иметь один код, одно приложение, которое почти не будет зависить от платформы.
2) .NET - хм, а где тут вообще платформенно независимость ? где .net framework под mac или lunix ? Сам не занимаюсь почти .net но друзья разработчики - говорили что есть какие-то не офицальные фраймфорки под линухи, но в них какие-то проблемы и т.д. под маки вообще не слышал, хотя может и есть, но все равно это все не офицальные. Скорость работы сопоставима с java
3) с++ если найти крутого программиста то он конечно напишет вам приложение без утечек памяти, плюс платформеннозависимый код, но все равно время потраченное на 3 приложения под 3 операционные системы ни когда не будет сопостовимо с платформеннонезависимимы языками программирования. Плюс большая проблема c++ это сложная работа с многопоточностью, и утечки памяти.
4) про Python ни чего к сожалению не знаю, и врят ли что-то посоветывать могу
1) Java:
Исталятор и JRE можно собраться сразу же, для этого есть специальные утилиты и тулзы, причем open source. Поэтому пользователю не обезательно будет устанавливать JRE. К примеру у моего GUI проекта инсталятор с JRE 18 mb, а без 3Mb. Про GUI тоже абсолютно не правы - у вас есть полностью возможность творить то что вы хотите, к примеру есть библиотеки типа look and feel которые делают Vista, XP, Mac интерфейсы в одном билде (т.е. не надо под каждую систему выпускать свой билд), единственный минус в них бывают свои баги, с которыми придется бороться. Зато встроеный Swing или AWT будет всегда работать стабильно и везде... Так же не понятно как вы хотите чтоб ваше приложение поддерживало WIN32 функции при условии что оно должно быть платформенно независим. По поводу скорости java - это вообще старое заблуждение, java уже давно считается очень быстрым языком, если конечно не надо иметь доступ к видео и т.д. на прямую. Можете поискать в интернете сравнение java и c++ по основным математическим задачкам и алгоритмам, и java с ключем -server чуть больше половины тестов выигрывает ! Так же при java вы будете иметь один код, одно приложение, которое почти не будет зависить от платформы.
2) .NET - хм, а где тут вообще платформенно независимость ? где .net framework под mac или lunix ? Сам не занимаюсь почти .net но друзья разработчики - говорили что есть какие-то не офицальные фраймфорки под линухи, но в них какие-то проблемы и т.д. под маки вообще не слышал, хотя может и есть, но все равно это все не офицальные. Скорость работы сопоставима с java
3) с++ если найти крутого программиста то он конечно напишет вам приложение без утечек памяти, плюс платформеннозависимый код, но все равно время потраченное на 3 приложения под 3 операционные системы ни когда не будет сопостовимо с платформеннонезависимимы языками программирования. Плюс большая проблема c++ это сложная работа с многопоточностью, и утечки памяти.
4) про Python ни чего к сожалению не знаю, и врят ли что-то посоветывать могу
Писать на QT. Возьмите оперу - и гибко и летает. Значит инструментарий правильный.
Никогда не видел ни одного доказательства того, что Opera под Windows использует Qt. У вас есть?
Здесь оперы нет: http://trolltech.com/company/customers/c…
Но я думаю вы найдете инфу о QT в Opera → Help → About Opera
В Linux точно есть (Qt library 3.3.8b), в Windows по идее тоже должно быть.
Но я думаю вы найдете инфу о QT в Opera → Help → About Opera
В Linux точно есть (Qt library 3.3.8b), в Windows по идее тоже должно быть.
Если бы сейчас передо мной поставили задачу написать "небольшую кросс-платформенную утилиту для пользователя-"чайника", которая качает файлы из интернета", я бы, наверное, выбрал python + pygtk, либо C++ + boost + gtkmm.
Зря Вы, C++ вовсе не устарел, во многих областях ему просто нет замены. А с выходом нового стандарта он должен стать еще лучше.
Зря Вы, C++ вовсе не устарел, во многих областях ему просто нет замены. А с выходом нового стандарта он должен стать еще лучше.
А вообще-то ... тут есть еще один момент. Мне кажется, что невозможно написать приложение, чтобы оно выглядело абсолютно нативно во всех графических средах — хотя бы по той причине, что user interface design guidelines запросто могут отличаться (и отличаются!!). Например, для Windows-пользователя нажимать Alt+, для того, чтобы открыть окно настроек, будет несколько неудобно - в то время как Мак-юзер сильно расстроится, если по нажатию этих кнопок ничего не произойдет.
Так что, какое бы решение ни было принято, оно будет неизбежным компромиссом - между «нативностью» внешнего вида приложения и сложностью его разработки. В идеале. естественно, следует вообще разделять систему на кросс-платформенное ядро, и платформо-зависимый модуль отображения; но на то он и идеал, что вряд ли кто-то его достигнет — очень уж велики накладные расходы. Именно этим (точнее — не в последнюю очередь этим), как мне кажется, и обусловлена такая высокая популярность веб-приложений: ядро кросс-платформенно и крутится... ну, допустим, на Линуксе крутится, а веб-интерфейс пользователи используют в Firefox или Safari, и все счастливы. Но иногда это просто невозможно, как вы сами, разумеется, понимаете.
Автору статьи, к сожалению, «не зачет» - он очень поверхностно пробежал по технологиям (да еще и не по всем, да и выбор довольно странный), никакого анализа не дал, и оставил все висеть в воздухе.
Так что, какое бы решение ни было принято, оно будет неизбежным компромиссом - между «нативностью» внешнего вида приложения и сложностью его разработки. В идеале. естественно, следует вообще разделять систему на кросс-платформенное ядро, и платформо-зависимый модуль отображения; но на то он и идеал, что вряд ли кто-то его достигнет — очень уж велики накладные расходы. Именно этим (точнее — не в последнюю очередь этим), как мне кажется, и обусловлена такая высокая популярность веб-приложений: ядро кросс-платформенно и крутится... ну, допустим, на Линуксе крутится, а веб-интерфейс пользователи используют в Firefox или Safari, и все счастливы. Но иногда это просто невозможно, как вы сами, разумеется, понимаете.
Автору статьи, к сожалению, «не зачет» - он очень поверхностно пробежал по технологиям (да еще и не по всем, да и выбор довольно странный), никакого анализа не дал, и оставил все висеть в воздухе.
1) как я понял, Вы хотите минимизировать риски и стоимость разработки своего решения. Если так, то именно с этой точки зрения и нужно выбирать технологическую платформу.
- Вы оценили во сколько встанет разработка мультиплатформенного решения на C++? разные машины, разные версии ОС (каждая версия со своими особенностями), нужные специалисты с опытом работы на mac/nix/windows
- Вы оценили стоимость сопровождения мультиплатформенного решения в связи с появлением новых версий ОС (всех возможных версий и вариантов)? Люди будут меняться, будут нужны постоянно сильные специалисты и целый зоопарк железа и софта со штатом сопровожденцев всего этого.
- Вы оценили знание командой (а как оценить знание людей со стороны?) всех тех инструментов и технологий, с которыми хотите работать? Если хотите быстро занять нишу или потеснить конкурентов, то должны очень быстро делать качественный продукт. Вашей команде под силу с этим справиться на C++ или Java?
- Вы оценили, что же больше всего нужно покупателям: ГУИ-конфетка? фукнциональность? портируемость? простота установки? Важно понимать, что между всем этим в любом случае будут компромиссы и сделать идеальное решение встанет очень дорого.
2) на мой взгляд в исходной постановке сделано несколько ошибок:
- крайне сложно и дорого сделать программу, которая будет работать ВЕЗДЕ, не используя при этом широкораспространенной абстракции (например, JVM). Необходимо сократить количество поддерживаемых платформ/версий ОС и для начала поиметь успех на этой нише. Если это случится, то у Вас будет достаточно средств для портирования или переписывания кода под нужную платформу.
- технологическая платформа должна выбираться исходя из опыта и умения тех людей, с кем Вы планируете работать. Не поддавайтесь желанию программистов познать новый инструмент за Ваш счет. То что идеально может использовать команда и нужно использовать.
- необходимо четко определиться в том, что Вы хотите продать рынку: красивую ничего неделалку или делалку с некоторыми ограничениями? Множества софта, который сделал кучу денег разработчику не особенно привлекателен и не соблюдает все современные тенденции в юзабилити - все же главное, это его функции.
3) исходя из всего этого мне видится, что
- если Вам действительно нужна возможность запустить приложение везде где только можно, то необходимо использовать Java и забить на красивости доступные в нативных библиотеках. Дешево и сердито.
- если Вам нужно очень качественное снаружи решение, простое в установке, минимально занимающее место, выполняющее все необходимые функции, длительное в разработке и сопровождении и при этом команда состоит в основном из C++еров, то лучше отказаться от многоплатформенности, портируемости (на время) и использовать C++
- если Вам нужно очень качественное снаружи решение, выполняющее все необходимые функции и сделать это быстро, но пожертвовать размером дистрибутива и простой его установки, и при этом команда состоит в основном из C++еров или C#еров, то лучше также отказаться от многоплатформенности, портируемости (на время) и использовать C#
- все остальные изыски (до этого был mainstream) можете использовать только если у Вас есть подходящая сработавшаяся команда, которая все это знает и знает чего от всего этого ожидать.
- Вы оценили во сколько встанет разработка мультиплатформенного решения на C++? разные машины, разные версии ОС (каждая версия со своими особенностями), нужные специалисты с опытом работы на mac/nix/windows
- Вы оценили стоимость сопровождения мультиплатформенного решения в связи с появлением новых версий ОС (всех возможных версий и вариантов)? Люди будут меняться, будут нужны постоянно сильные специалисты и целый зоопарк железа и софта со штатом сопровожденцев всего этого.
- Вы оценили знание командой (а как оценить знание людей со стороны?) всех тех инструментов и технологий, с которыми хотите работать? Если хотите быстро занять нишу или потеснить конкурентов, то должны очень быстро делать качественный продукт. Вашей команде под силу с этим справиться на C++ или Java?
- Вы оценили, что же больше всего нужно покупателям: ГУИ-конфетка? фукнциональность? портируемость? простота установки? Важно понимать, что между всем этим в любом случае будут компромиссы и сделать идеальное решение встанет очень дорого.
2) на мой взгляд в исходной постановке сделано несколько ошибок:
- крайне сложно и дорого сделать программу, которая будет работать ВЕЗДЕ, не используя при этом широкораспространенной абстракции (например, JVM). Необходимо сократить количество поддерживаемых платформ/версий ОС и для начала поиметь успех на этой нише. Если это случится, то у Вас будет достаточно средств для портирования или переписывания кода под нужную платформу.
- технологическая платформа должна выбираться исходя из опыта и умения тех людей, с кем Вы планируете работать. Не поддавайтесь желанию программистов познать новый инструмент за Ваш счет. То что идеально может использовать команда и нужно использовать.
- необходимо четко определиться в том, что Вы хотите продать рынку: красивую ничего неделалку или делалку с некоторыми ограничениями? Множества софта, который сделал кучу денег разработчику не особенно привлекателен и не соблюдает все современные тенденции в юзабилити - все же главное, это его функции.
3) исходя из всего этого мне видится, что
- если Вам действительно нужна возможность запустить приложение везде где только можно, то необходимо использовать Java и забить на красивости доступные в нативных библиотеках. Дешево и сердито.
- если Вам нужно очень качественное снаружи решение, простое в установке, минимально занимающее место, выполняющее все необходимые функции, длительное в разработке и сопровождении и при этом команда состоит в основном из C++еров, то лучше отказаться от многоплатформенности, портируемости (на время) и использовать C++
- если Вам нужно очень качественное снаружи решение, выполняющее все необходимые функции и сделать это быстро, но пожертвовать размером дистрибутива и простой его установки, и при этом команда состоит в основном из C++еров или C#еров, то лучше также отказаться от многоплатформенности, портируемости (на время) и использовать C#
- все остальные изыски (до этого был mainstream) можете использовать только если у Вас есть подходящая сработавшаяся команда, которая все это знает и знает чего от всего этого ожидать.
Под ваше описание задачи хорошо подходит язык TCL - пример: tkjabber. Работает под всеми основными OS.
GUI у него к сожалению не нативный.
Это является проблемой? Если можно обоснуйте.
Постер например подчеркивал что в джаве ему не нравиться своеобразный интерфейс. Он вроде хотел системный.
А у tk с системный интерфейсом плохо:) Он просто везде одинаковый:) (я смотрел под виндовс и под маком)
Да и согласитесь, интерфейс не очень смотрится.
А у tk с системный интерфейсом плохо:) Он просто везде одинаковый:) (я смотрел под виндовс и под маком)
Да и согласитесь, интерфейс не очень смотрится.
Tile это может исправить.
Оговорюсь, что на Tcl/Tk ничего не писал, и топикстартеру рекомендовать или не рекомендовать не могу.
Оговорюсь, что на Tcl/Tk ничего не писал, и топикстартеру рекомендовать или не рекомендовать не могу.
Сразу видно, что сравнение _менеджера_. Вы менеджер - вот и занимайтесь своим делом, разработчки сами выберут фреймворк исходя из задачи.
Хотите очень серьезное кросс-платформенное приложение - Java, хотите простенькую утилитку, то C++ с использованием Qt4. Самый лучший способ - разделение на движок и графическую часть, чтобы движек был один на все, а GUI использовался нативный для каждой платформы(win32/.net для винды, Qt/GTK для линукса и Cocoa под мак).
Хотите очень серьезное кросс-платформенное приложение - Java, хотите простенькую утилитку, то C++ с использованием Qt4. Самый лучший способ - разделение на движок и графическую часть, чтобы движек был один на все, а GUI использовался нативный для каждой платформы(win32/.net для винды, Qt/GTK для линукса и Cocoa под мак).
Java станет серьезной проблемой. Для новичков — придется скачивать и устанавливать виртуальную машину. Для тех, кто начнет пользоваться — тормоза, порой, жутчайшие.
Для себя я сделал вывод, как пользователь: если написано в требованиях "нужна Java", то программа будет очень тормозить.
Для себя я сделал вывод, как пользователь: если написано в требованиях "нужна Java", то программа будет очень тормозить.
у меня, как пользователя, такое же мнение по поводу производительности Java - несмотря на множество программистов, которые разбивают здесь лоб, доказывая обратное :)
Это в какойто мере заблуждение:)
Просто виртуальная машина джавы ест достаточно много памяти. Запуск совсем небольшой програмки - порядка 32 а то и больше мегабайт. Ну а тот же эклипс за 100 и больше. И если у пользователя мало оперативки и запущено много приложений, то каждое сворачивание джава приложения(т.к. оно весит много) ведет за собой сброс его из оперативки в файл подкачки, а при разворачивании соответственно считывание обратно в оперативку. А так как эта операция достаточно медленная - тут то и появляются тормоза.
А вот сами приложения на джаве практически не уступают по производительности аналогам на других языках.
Так что это не джава медленная, просто оперативки мало:)
Просто виртуальная машина джавы ест достаточно много памяти. Запуск совсем небольшой програмки - порядка 32 а то и больше мегабайт. Ну а тот же эклипс за 100 и больше. И если у пользователя мало оперативки и запущено много приложений, то каждое сворачивание джава приложения(т.к. оно весит много) ведет за собой сброс его из оперативки в файл подкачки, а при разворачивании соответственно считывание обратно в оперативку. А так как эта операция достаточно медленная - тут то и появляются тормоза.
А вот сами приложения на джаве практически не уступают по производительности аналогам на других языках.
Так что это не джава медленная, просто оперативки мало:)
Моих полугигабайт памяти на неновом уже субноутбуке хватает даже для одновременной работы "Фотошопа", "Ворда", трех браузеров, "Квипа", "Тотал коммандера".
И вот только джава-приложения тормозят даже тогда, когда больше ничего не запущено. Наверное, это "винда сакс" и "кривые руки ламера"? :-)
И вот только джава-приложения тормозят даже тогда, когда больше ничего не запущено. Наверное, это "винда сакс" и "кривые руки ламера"? :-)
Пол гигабайта - однозначно мало:)
Мегабайт 100 - 150 виндовс, еще мегабайт 150 браузер итого на джава приложение всего метров 200 - мало!:)
А само это джава приложение наверно совсем не маленьких размеров. И тормозит скорей всего только при запуске и разворачивании.
Мегабайт 100 - 150 виндовс, еще мегабайт 150 браузер итого на джава приложение всего метров 200 - мало!:)
А само это джава приложение наверно совсем не маленьких размеров. И тормозит скорей всего только при запуске и разворачивании.
вполне вероятно, что это не совсем "тормоза".. дело может быть в том, что у swing (фреймворк для gui в яве) работает в одном потоке.. и если в нем еще происходят какие-либо вычисления, или он лочится по каким-либо другим причинам, то выглядит как будто приложение зависло.. как понимаете, причина это не столько ява, сколько плохие программисты
именно так. посмотрите недавнее сравнение производительности языков на хабре.
Давно пробовали програмки. И к сожалению у многих наших программистов и пользователей такой мнение создалось. Мне ещё в инстуте говорили - "Джава это слишком тяжело и медленно и вообще это для интернета". Я сейчас пишу на дотнете, и я вам скажу что производительность у дот нета совсем не "одни плюсы". Одни минусы и на каждом шагу ещё и подводные камни, которые чтобы обойти надо ещё больше денег заплатить Майкрософту.
Кстати, вы сказали что доверяете Опен Соурсу :) А Джава то опен соурсная http://www.sun.com/software/opensource/j… ;) И я полагаю вы знаете что это значит.
Да, когда Джава только появилась она была жутко громозкая и всё то что вы сказали. Но сейчас уже прошло 10 лет с того времени.
Кстати, вы сказали что доверяете Опен Соурсу :) А Джава то опен соурсная http://www.sun.com/software/opensource/j… ;) И я полагаю вы знаете что это значит.
Да, когда Джава только появилась она была жутко громозкая и всё то что вы сказали. Но сейчас уже прошло 10 лет с того времени.
>> такое же мнение по поводу производительности Java
Не соглашусь. Мнжество больших enterprise-систем сейчас разрабатываются на java. В том числе, и в финансовой сфере. Неужели крупные корпорации ошибаются в своем выборе? :)
Ну и еще, в качестве довода: http://dz.livejournal.com/453659.html
Не соглашусь. Мнжество больших enterprise-систем сейчас разрабатываются на java. В том числе, и в финансовой сфере. Неужели крупные корпорации ошибаются в своем выборе? :)
Ну и еще, в качестве довода: http://dz.livejournal.com/453659.html
Увы, но вы о-очень серъёзно заблуждаетесь. :-)
Если написано java надо просто поискать дополнительную память. В большинстве случаев упор идет именно в память, а не в проц.
Ассемблер. Те же преимущества, что перечислены автором для C++, только помноженные на два. Из недостатков — отсутствие внятного ООП (впрочем, кто-то сочтёт это достоинством) и наработанных фреймворков. Довольно неплохая переносимость. Главное — не использовать platform-specific команды и библиотеки.
Delphi. Отлично зарекомендовавший себя инструмент. Довольно легко переносится на Linux (см. Kylix). Для настоящих ценителей красивого кода. В последнее время подсдал позиции, но всё ещё очень даже.
PHP. Есть два слово из трёх букв, которые известны всем, и это одно из них. Пресловутый низкий порог вхождения. Неплохая реализация ООП. Гибкость и быстродействие. Малый вес фреймворка, легко автоматизируемая установка для пользователя в составе десктопного приложения. Отличная кроссплатформенность.
PHP с HTML-интерфейсом. Всё то же самое плюс лёгкость и доступность в конструировании интерфейсов. Использовани AJAX позволяет довести интерфейс до совершенство. Мощь самого PHP обеспечивает хорошую функциональность проекта.
Delphi. Отлично зарекомендовавший себя инструмент. Довольно легко переносится на Linux (см. Kylix). Для настоящих ценителей красивого кода. В последнее время подсдал позиции, но всё ещё очень даже.
PHP. Есть два слово из трёх букв, которые известны всем, и это одно из них. Пресловутый низкий порог вхождения. Неплохая реализация ООП. Гибкость и быстродействие. Малый вес фреймворка, легко автоматизируемая установка для пользователя в составе десктопного приложения. Отличная кроссплатформенность.
PHP с HTML-интерфейсом. Всё то же самое плюс лёгкость и доступность в конструировании интерфейсов. Использовани AJAX позволяет довести интерфейс до совершенство. Мощь самого PHP обеспечивает хорошую функциональность проекта.
ирония - это замечательно :) но вопрос остался без ответа.
Какой именно вопрос? Какую платформу бы я выбрал? Если из перечисленных вами — то Java. Может быть, C#. Но ни в коем случае не С++.
Если добавить также мои варианты, то мой выбор — PHP с HTML-интерфейсом.
Хотя это ещё может сильно зависеть от решаемой задачи.
Если добавить также мои варианты, то мой выбор — PHP с HTML-интерфейсом.
Хотя это ещё может сильно зависеть от решаемой задачи.
PHP(+фреймворки) являются всё же интерпретивными средами на стороне сервера. Кроме PHP нужно продумывать организацию серверного хозяйства из ОТДЕЛЬНОГО Web-сервера и протоколов взаимодействия (HTTP/HTTPS, SOAP и т.д.), что очень накладно.
Java как платформа может предоставить всё это сразу даже БЕЗ нативных Web-серверов и с системой управления контентом. Пример 1: ставим JDK и Tomcat, запускаем — у нас работающий Web-сервер с JSP, странички можно писать в Блокноте, копировать в каталог Tomcat'а, они при первом обращении клиента компилируются в сервлеты, затем JIT'ятся в нативный код и кладутся в пул памяти — тормоза только при первом обращении. PHP в таком режиме использования тормозит ВСЕГДА.
Пример 2: добавляем jar-библиотеки к Tomcat для WebServices и JSF — получаем почти Enterprise-сервер приложений — очень лёгкий, чтобы не заморачиваться с полным JEE.
Пример 3: вместо Tomcat развёртываем бесплатный сервер приложений JEE GlassFish — получаем возможность использовать весь спектр JEE-приложений. Заметьте, что всё это в одном флаконе, работает одинаково на Windows, Linux, FreeBSD, нативный Web-сервер (например, Apache) не так уж необходим — разве что для редиректа активных страниц. Среды разработки: Eclipse или NetBeans — обе бесплатны и заточены на всё-про-всё через плагины.
Java как платформа может предоставить всё это сразу даже БЕЗ нативных Web-серверов и с системой управления контентом. Пример 1: ставим JDK и Tomcat, запускаем — у нас работающий Web-сервер с JSP, странички можно писать в Блокноте, копировать в каталог Tomcat'а, они при первом обращении клиента компилируются в сервлеты, затем JIT'ятся в нативный код и кладутся в пул памяти — тормоза только при первом обращении. PHP в таком режиме использования тормозит ВСЕГДА.
Пример 2: добавляем jar-библиотеки к Tomcat для WebServices и JSF — получаем почти Enterprise-сервер приложений — очень лёгкий, чтобы не заморачиваться с полным JEE.
Пример 3: вместо Tomcat развёртываем бесплатный сервер приложений JEE GlassFish — получаем возможность использовать весь спектр JEE-приложений. Заметьте, что всё это в одном флаконе, работает одинаково на Windows, Linux, FreeBSD, нативный Web-сервер (например, Apache) не так уж необходим — разве что для редиректа активных страниц. Среды разработки: Eclipse или NetBeans — обе бесплатны и заточены на всё-про-всё через плагины.
Если учитывать что есть PHP-GTK (http://www.gtk.php.net/), то я думаю это совсем не ирония, а поскольку из комментов выше ясно что приложения является веб-ориентированным, то, ИМХО, достаточно хороший вариант. Разве-что проблемы с мемори-ликами :(
НЛО прилетело и опубликовало эту надпись здесь
Если говорить об индустриальном мультиплатформенном desktop-приложение, то на сегодняшний день выбор практически однозначен. Это джава и только джава. Все остальные языки имеют свои минусы и плюсы, но для их использования нужны некие особенные обоснования. Выбор между C++ и Питоном крайне неудачен. Не потому, что они плохи, а потому что их специфика крайне затруднит разработку приложения. Хотя, разумеется понятно, что писать можно хоть в двоичных кодах. :-)
Для Windows, C# возможно был бы возможным выбором, хотя опять же, если говорить о платформе в целом, то платформа Джава имеет на голову больше наработок и стандартным образом накрывает заметно большее количество технологий.
Для Windows, C# возможно был бы возможным выбором, хотя опять же, если говорить о платформе в целом, то платформа Джава имеет на голову больше наработок и стандартным образом накрывает заметно большее количество технологий.
Конечно же может и не совсем серьезная вещь, но позиционируется очень интересно: http://www.realbasic.com/download/
Это Вижуал Бейсик с компиляцией под любые платформы. Опробовать не успел, но видео у них - забавное.
сам давно ищу - больше нравится решение Python, но визуального создания форм нигде не нашел. И вообще не представля как на Python например Сделать типа LookupComboBox (или DBGrid) и привязать его к БД в локалке под MSSQL или MySQL. Ну просто очень интересно. Если кто даст ссылочку как такое провернуть, было бы очень поучительно. Я уж не говорю о таких возможностях какие реализованы в Ehlib для Дельфей и С++ Builder(например выпадающие списки в таблице, на практике это очень частая для меня задача).
Это Вижуал Бейсик с компиляцией под любые платформы. Опробовать не успел, но видео у них - забавное.
сам давно ищу - больше нравится решение Python, но визуального создания форм нигде не нашел. И вообще не представля как на Python например Сделать типа LookupComboBox (или DBGrid) и привязать его к БД в локалке под MSSQL или MySQL. Ну просто очень интересно. Если кто даст ссылочку как такое провернуть, было бы очень поучительно. Я уж не говорю о таких возможностях какие реализованы в Ehlib для Дельфей и С++ Builder(например выпадающие списки в таблице, на практике это очень частая для меня задача).
Если говорить об индустриальном мультиплатформенном desktop-приложение, то на сегодняшний день выбор практически однозначен. Это джава и только джава. Все остальные языки имеют свои минусы и плюсы, но для их использования нужны некие особенные обоснования. Выбор между C++ и Питоном крайне неудачен. Не потому, что они плохи, а потому что их специфика крайне затруднит разработку приложения. Хотя, разумеется понятно, что писать можно хоть в двоичных кодах. :-)
Для Windows, C# возможно был бы возможным выбором, хотя опять же, если говорить о платформе в целом, то платформа Джава имеет на голову больше наработок и стандартным образом накрывает заметно большее количество технологий.
Для Windows, C# возможно был бы возможным выбором, хотя опять же, если говорить о платформе в целом, то платформа Джава имеет на голову больше наработок и стандартным образом накрывает заметно большее количество технологий.
что то странный этот индекс TIOBE - на третьем месте по его мнению Visual Basic...
Судя по уровню Ваших знаний Вам даже хорошие ответы здесь вряд ли помогут...
Сравнивать C++ и, скажем, Java напрямую - некорректно, поскольку Java включает в себя универсальную библиотеку (в том числе - графическую), а C++ без библиотек позволит только в терминал выводить символы.
Eclipse, если не ошибаюсь, привязан к Windows. Как раз поэтому его не любит Sun.
Рассуждать как лучше писать некую "общую" программу: совершенно бесплодно! В частности, закачать файл можно с помощью той же Оперы, но даже если Вы наймете хороших программистов, то сделать подобный хороший файловый менеджер быстро не сможете - это нетривиально.
Самое лучшее: взять в качестве клиента браузер и нанять интернет-программистов.
А также бросить заниматься вещами, в которых не смыслите...
Сравнивать C++ и, скажем, Java напрямую - некорректно, поскольку Java включает в себя универсальную библиотеку (в том числе - графическую), а C++ без библиотек позволит только в терминал выводить символы.
Eclipse, если не ошибаюсь, привязан к Windows. Как раз поэтому его не любит Sun.
Рассуждать как лучше писать некую "общую" программу: совершенно бесплодно! В частности, закачать файл можно с помощью той же Оперы, но даже если Вы наймете хороших программистов, то сделать подобный хороший файловый менеджер быстро не сможете - это нетривиально.
Самое лучшее: взять в качестве клиента браузер и нанять интернет-программистов.
А также бросить заниматься вещами, в которых не смыслите...
>Eclipse, если не ошибаюсь, привязан к Windows
ошибаетесь
ошибаетесь
Не совсем я ошибаюсь. Не ради холиваров и бессмысленных дикуссий процитирую с википедии:
"GUI в Eclipse написан с использованием инструментария SWT. Последний, в отличие от Swing (который лишь эмулирует отдельные графические элементы используемой платформы), действительно использует графические компоненты данной системы. Пользовательский интерфейс Eclipse также зависит от промежуточного слоя GUI, называемого JFace, который упрощает построение пользовательского интерфейса, базирующегося на SWT."
"SWT — альтернатива AWT и Swing (Sun Microsystems) для разработчиков, желающих получить привычный внешний вид программы в данной OS и избежать части проблем, связанных с переучиванием пользователей. Использование SWT делает Джава-программу более эффективной, но лишает независимости от OS и оборудования, требует ручного освобождения ресурсов, в некоторой степени разрушает Sun-концепцию Джава."
Я прошу только обратить внимание на слова "ИСПОЛЬЗОВАНИЕ SWT ... ЛИШАЕТ НЕЗАВИСИМОСТИ ОТ OS".
Короче говоря, все конечно достижимо, но через определенные грабли все равно.
"GUI в Eclipse написан с использованием инструментария SWT. Последний, в отличие от Swing (который лишь эмулирует отдельные графические элементы используемой платформы), действительно использует графические компоненты данной системы. Пользовательский интерфейс Eclipse также зависит от промежуточного слоя GUI, называемого JFace, который упрощает построение пользовательского интерфейса, базирующегося на SWT."
"SWT — альтернатива AWT и Swing (Sun Microsystems) для разработчиков, желающих получить привычный внешний вид программы в данной OS и избежать части проблем, связанных с переучиванием пользователей. Использование SWT делает Джава-программу более эффективной, но лишает независимости от OS и оборудования, требует ручного освобождения ресурсов, в некоторой степени разрушает Sun-концепцию Джава."
Я прошу только обратить внимание на слова "ИСПОЛЬЗОВАНИЕ SWT ... ЛИШАЕТ НЕЗАВИСИМОСТИ ОТ OS".
Короче говоря, все конечно достижимо, но через определенные грабли все равно.
мультиплатформенное - ги ги ги, смешно :)
кроссплатформенное - может лучше так?
а почему нет C? все С++ да С++, но ведь C != C++, как и unix != linux.
кроссплатформенное - может лучше так?
а почему нет C? все С++ да С++, но ведь C != C++, как и unix != linux.
НЛО прилетело и опубликовало эту надпись здесь
> Тем не менее у разработчиков есть масса претензий к С++. По моему мнению, язык является "устаревшим" и его популярность в дальнейшем будет снижаться, что подтверждается индексом TIOBE.
ну ты и индюк :)
ты бы еще сказал, что asm - устарел и вовсе не нужен :)
p.s. Си прожил долгую жизнь и стал стабильным, проверенным временем. Или вы предпочитаете тупо быдлокодить в php т.к. сложней basic'а ниасилить?
нет ничего лучше C & GTK
ну ты и индюк :)
ты бы еще сказал, что asm - устарел и вовсе не нужен :)
p.s. Си прожил долгую жизнь и стал стабильным, проверенным временем. Или вы предпочитаете тупо быдлокодить в php т.к. сложней basic'а ниасилить?
нет ничего лучше C & GTK
Мой выбор:
- Либо уже упоминавшееся тут сочетание C++ со скриптовым языком (скажем, CPython)
- Чистый Python - по поводу UI можно посмотреть в сторону wxPython
- Либо Java (можно тоже со скриптовым языком - Jython, JRuby, Groovy). Java под виндой и под линкусом можно скомпилировать в .exe (например, используя Excelsior Jet). JRE оно упаковавает метров до шести, если мне не изменяет память. Собирает инсталлятор. Для UI - не Swing, а SWT.
Для принятия окончательного решения недостаточно известно о требованиях.
- Либо уже упоминавшееся тут сочетание C++ со скриптовым языком (скажем, CPython)
- Чистый Python - по поводу UI можно посмотреть в сторону wxPython
- Либо Java (можно тоже со скриптовым языком - Jython, JRuby, Groovy). Java под виндой и под линкусом можно скомпилировать в .exe (например, используя Excelsior Jet). JRE оно упаковавает метров до шести, если мне не изменяет память. Собирает инсталлятор. Для UI - не Swing, а SWT.
Для принятия окончательного решения недостаточно известно о требованиях.
НЛО прилетело и опубликовало эту надпись здесь
Речь шла о .Net Framework для .Net и аналогично JRE для Java. Вполне понимаю сомнения автора, включать ли 14-метровый JRE вместе с 1-метровым приложением. (Когда удаётся это урезать до шести метров - это несколько меняет дело).
к моменту готовности приложения уже будет java6 update N, которая умеет урезаться :)
Это серьёзно? А можно подробнее? Чему равно N? ;-)
Насколько я знаю, по лицензии Сана до текущего момента можно было поставлять только всю JRE целиком. В Excelsior Jet была возможность включать только те классы из JRE, которые непосредственно нужны для приложения - но из-за лицензионных ограничений её убрали.
Насколько я знаю, по лицензии Сана до текущего момента можно было поставлять только всю JRE целиком. В Excelsior Jet была возможность включать только те классы из JRE, которые непосредственно нужны для приложения - но из-за лицензионных ограничений её убрали.
"Java Kernel divides JRE libraries into small bundles. The idea of Java Kernel is to provide the smallest possible Kernel JRE bundle that runs a simple HelloWorld program. And, once the Kernel JRE is installed, it will download the rest of the JRE bundles in the background managed by Download Manager. The reason is to reduce the size of the Kernel JRE and thus a shorter download time user will experience."
Да, круто! Спасибо за инфу.
Да, круто! Спасибо за инфу.
ирли адоптеры качают альфа-версии — загляните в блог Firefox :)
АВАP забыли. моим приложением написанным на AВАР могут пользоваться на линуксах, маке, винде бухгалтера, программисты, консультанты, контролёры и даже складские грузчики на сканерах штрих-кодов :)
НЛО прилетело и опубликовало эту надпись здесь
А мне кажется, что кроссплатформено надо писать только логику приложения. Даже если будем использовать родные виджеты, то всё равно у разных платформ разные принципы в построении GUI. В KDE у программмы должна быть куча настроек, в Gnome она должна быть «юзабильной по Gnome HIG». На маках в идеале нужно всё делать одной кнопкой мыши. Ну и т. д.
вы первый, кто предложил внятную инициативу (: за что вас спасибо
автору топика:
вот, человек дело говорит. практика и мнения людей показывают, что гораздо продуктивнее писать, разделяя логику и представление.
даже если писать проект целиком на Java, гораздо проще будет учесть нюансы необходимых ОС в процессе дописывания представления, а не городить огороды, обходя HIG`и и рекомендации.
отделяя логику и представление, значительно расширится круг выбора инструментов реализации. пишите логику на плюсах, пока один человек пишет представления для всех ОС, употребляя заглушки на логику.
автору топика:
вот, человек дело говорит. практика и мнения людей показывают, что гораздо продуктивнее писать, разделяя логику и представление.
даже если писать проект целиком на Java, гораздо проще будет учесть нюансы необходимых ОС в процессе дописывания представления, а не городить огороды, обходя HIG`и и рекомендации.
отделяя логику и представление, значительно расширится круг выбора инструментов реализации. пишите логику на плюсах, пока один человек пишет представления для всех ОС, употребляя заглушки на логику.
Писали софтину на питоне, после релиза наблюдались проблемы с запуском примерно у 30% клиентов (ошибки с wx и еще некоторыми библиотеками, причем не зависимо от операционки, ее версии и т.п.). В итоге все переписали на Cpp + Qt4. Сейчас все работает без проблем у всех.
просто my 2 cents:
DMD + DWT
программистов на D практически нет, но адекватный девелопер перелезает на D с Java или Cpp за месяц.
официальная gui-библиотека DWT - это вообще порт SWT. отдельного runtime у DMD нет, есть сборка мусора, совместимость с Си, скорость работы.
DMD + DWT
программистов на D практически нет, но адекватный девелопер перелезает на D с Java или Cpp за месяц.
официальная gui-библиотека DWT - это вообще порт SWT. отдельного runtime у DMD нет, есть сборка мусора, совместимость с Си, скорость работы.
http://localhost - достаточно кросплатформенно?
А зачем вам кросс-платформенность? нет, серьезно..
Вы думаете, что программа, написанная для винды (пусть будет та же ява), будет _нормально_ работать на маках? под нормальностью я имею в виду то, что она будет удобна мак-пользователя, не будет резать им глаз?
Когда у меня был linux, мне очень нравился Azureus. Когда перешел на мак, заменил его на transmission (который вроде как обладает меньшей функциональностью).
Это я к тому, что каждая из 3-х ОС обладает своими особенностями, и, на мой взгляд, кросс-платформенностью нельзя назвать возможность запуска программы в разных средах.
Мне кажется, что вашему стартапу будет полезнее выбрать целевую ОС, и писать для нее _качественно_. Для винды можно делать делать очень красиво на .NET, для линукс - qt, для OSX сам Джобс велел cocoa... Выбрав, например, виндовс, вы получите макс. допустимый охват аудитории, выбрав linux - технически подкованных пользователей. Для OSX у вас появляется шанс создать что-то очень классное (TextMate, OmniOutliner/OmniGraffle/.. - гениальнейшие творения из всех, что я встречал; водятся только в OSX).
Я все это к тому, что создание кросс-платформенных (типа выбрали java, фигачим в винде, работает везде, круто, у нас 100% аудитории) - это глупый старый подход к созданию продуктов. И реально это не работает. И даже больше - от этого часто только хуже - приложение нормально (привычно, адекватно) не работает ни в одной среде.. Не верите - запустите на маке _любое_ кросс-платформенное приложение. В качестве эталона java-программы предлагаю взять IntelliJ IDEA или тот же Azureus, и сравните работу с нативными программами.
В качестве примера можно рассмотреть обычный текстовый редактор. В linux (ну по крайней мере для меня, хотя думаю, что для многих) это vim (примечание для менеджеров - приложение, работающее в консоли, причем что бы редактировать в нем, нужно изучить его, что не так просто). В OSX и Windows это GUI приложения, скажем, TextMate и Edit+. Тут разницу описать сложнее, но можно сказать, утрируя,что если в винде сколько вкладок в taskbar'e, столько и запущенных редакторов, в маке же при запускается редактор один, и может быть без окон (сложно описать точно разницу, но нормально поработав в этих средах понимаешь, что тут абсолютно разные идеологии построения GUI приложений)...
В качестве ответа предлагаю на ваш вопрос: выберите целевую ОС, для нее подходящий язык. Язык в свою очередь выбирать максимально простой (из вашего списка предпочтителен python, далее java/c#, не С++), при этом учитывая сложность создания нативного интерфейса. Плюс можете лелеять себя надеждой, что когда "стартап взорвет целевой рынок", вы сможете выделить ядро приложения, и написать соответствующий порт для других ОС.
Вы думаете, что программа, написанная для винды (пусть будет та же ява), будет _нормально_ работать на маках? под нормальностью я имею в виду то, что она будет удобна мак-пользователя, не будет резать им глаз?
Когда у меня был linux, мне очень нравился Azureus. Когда перешел на мак, заменил его на transmission (который вроде как обладает меньшей функциональностью).
Это я к тому, что каждая из 3-х ОС обладает своими особенностями, и, на мой взгляд, кросс-платформенностью нельзя назвать возможность запуска программы в разных средах.
Мне кажется, что вашему стартапу будет полезнее выбрать целевую ОС, и писать для нее _качественно_. Для винды можно делать делать очень красиво на .NET, для линукс - qt, для OSX сам Джобс велел cocoa... Выбрав, например, виндовс, вы получите макс. допустимый охват аудитории, выбрав linux - технически подкованных пользователей. Для OSX у вас появляется шанс создать что-то очень классное (TextMate, OmniOutliner/OmniGraffle/.. - гениальнейшие творения из всех, что я встречал; водятся только в OSX).
Я все это к тому, что создание кросс-платформенных (типа выбрали java, фигачим в винде, работает везде, круто, у нас 100% аудитории) - это глупый старый подход к созданию продуктов. И реально это не работает. И даже больше - от этого часто только хуже - приложение нормально (привычно, адекватно) не работает ни в одной среде.. Не верите - запустите на маке _любое_ кросс-платформенное приложение. В качестве эталона java-программы предлагаю взять IntelliJ IDEA или тот же Azureus, и сравните работу с нативными программами.
В качестве примера можно рассмотреть обычный текстовый редактор. В linux (ну по крайней мере для меня, хотя думаю, что для многих) это vim (примечание для менеджеров - приложение, работающее в консоли, причем что бы редактировать в нем, нужно изучить его, что не так просто). В OSX и Windows это GUI приложения, скажем, TextMate и Edit+. Тут разницу описать сложнее, но можно сказать, утрируя,что если в винде сколько вкладок в taskbar'e, столько и запущенных редакторов, в маке же при запускается редактор один, и может быть без окон (сложно описать точно разницу, но нормально поработав в этих средах понимаешь, что тут абсолютно разные идеологии построения GUI приложений)...
В качестве ответа предлагаю на ваш вопрос: выберите целевую ОС, для нее подходящий язык. Язык в свою очередь выбирать максимально простой (из вашего списка предпочтителен python, далее java/c#, не С++), при этом учитывая сложность создания нативного интерфейса. Плюс можете лелеять себя надеждой, что когда "стартап взорвет целевой рынок", вы сможете выделить ядро приложения, и написать соответствующий порт для других ОС.
ExtJS + AIR. Автору бы сделать голосование для всех способов.
Хотел бы попросить помощи. У меня подобная проблема. Разрабатываю программу для 3хмерного моделирования. На данный момент использую C++ и Qt для ГУИ. Есть ряд вопросов:
1) Давно уже интересуюсь питоном, но ничего не пишу на нем. В этой программе приходится обрабатывать достаточно большие объемы данных и отображаются в трехмерном виде. Использую естественно низкоуровневые массивы(я имею в виду указатели, например double*). Сомневаюсь что что-нибудь кроме С++ мне подойдет в данном случае, хотя к питону лежит душа. В принципе я и с С++ больших проблем не испытываю. Ошибки конечно сложно искать, но в принципе главное за памятью следить, если это делать используя ООП подход, то в принципе жить можно.
2) Вопрос по поводу Qt - инструмент идеальный. Никаких заморочек. Пишу на линуксе, компилирую под Винду. Не устраивает только GPL. Так как частей моей программы в дальнейшем может сотрудничать с проприетарным кодом. В Qt я погряз достаточно плотно, использую ихние контейнеры. Но программа пока еще на такой стадии, что переписать ее на другой фреймворк можно. Благо Это всего лишь ГУИ-шная часть. Вот здесь и возникают вопросы об альтернативах. Смотрю на GTK, сам он конечно ужасный, но GTKmm выглядит вполне человечески. Какие могут возникнуть проблемы с кросс-платформенностью? В Qt все просто .pro файл, универсальный, здесь я не знаю. К WxWidgets как-то с подозрением отношусь..
1) Давно уже интересуюсь питоном, но ничего не пишу на нем. В этой программе приходится обрабатывать достаточно большие объемы данных и отображаются в трехмерном виде. Использую естественно низкоуровневые массивы(я имею в виду указатели, например double*). Сомневаюсь что что-нибудь кроме С++ мне подойдет в данном случае, хотя к питону лежит душа. В принципе я и с С++ больших проблем не испытываю. Ошибки конечно сложно искать, но в принципе главное за памятью следить, если это делать используя ООП подход, то в принципе жить можно.
2) Вопрос по поводу Qt - инструмент идеальный. Никаких заморочек. Пишу на линуксе, компилирую под Винду. Не устраивает только GPL. Так как частей моей программы в дальнейшем может сотрудничать с проприетарным кодом. В Qt я погряз достаточно плотно, использую ихние контейнеры. Но программа пока еще на такой стадии, что переписать ее на другой фреймворк можно. Благо Это всего лишь ГУИ-шная часть. Вот здесь и возникают вопросы об альтернативах. Смотрю на GTK, сам он конечно ужасный, но GTKmm выглядит вполне человечески. Какие могут возникнуть проблемы с кросс-платформенностью? В Qt все просто .pro файл, универсальный, здесь я не знаю. К WxWidgets как-то с подозрением отношусь..
Lazarus - хороший кросплатформенный аналог Delphi, основан на freepascal. Сам юзаю Wine (WineHQ) + Delphi2007, так как в Lazarus нет SkinEngine и Web-Браузера, ну и Lazarus естественно.
Относительно Java написано следующее:
Минусы: необходимость установки фреймворка, кривость GUI, низкая производительность.
1. Устанавливать фреймворк необязательно. Более того, если пишите обычное приложение - не нужно. Нужно фреймворк в инсталлятор для этого приложения включить. Причем будет использоваться только в этом приложении. См. IDEA
2. Кривость GUI. Вранье либо незнание дел (скорее последнее). Есть два основных гуевых фреймворка - swing и swt. Если говорить очень коротко и для юзеров, то первый не похож на конкретную платформу, но везде выглядит одинаково (см. IDEA). Второй - везде выглядит как родное приложение (см. Eclipse).
3. Низкая производительность. По сравнению с чем? На чем основывается этот миф? На статьях 2002-го года? Неактуально давным давно.
Про остальное - не самый большой специалист, поэтому писать не буду. Автора в школу. Учиться, учиться и еще раз учиться.
Минусы: необходимость установки фреймворка, кривость GUI, низкая производительность.
1. Устанавливать фреймворк необязательно. Более того, если пишите обычное приложение - не нужно. Нужно фреймворк в инсталлятор для этого приложения включить. Причем будет использоваться только в этом приложении. См. IDEA
2. Кривость GUI. Вранье либо незнание дел (скорее последнее). Есть два основных гуевых фреймворка - swing и swt. Если говорить очень коротко и для юзеров, то первый не похож на конкретную платформу, но везде выглядит одинаково (см. IDEA). Второй - везде выглядит как родное приложение (см. Eclipse).
3. Низкая производительность. По сравнению с чем? На чем основывается этот миф? На статьях 2002-го года? Неактуально давным давно.
Про остальное - не самый большой специалист, поэтому писать не буду. Автора в школу. Учиться, учиться и еще раз учиться.
Изначально неправильный подход к выбору.
1. Выбирать должен специалист (да, я знаю что об этом говорили, но я повторюсь)
2. Специалист должен выбрать то, с чем будет удобнее работать ему, то что он знает досконально. Если он не знает досконально ни один кроссплатформенный вариант - наймите другого специалиста. В идеале оценку должен делать человек знакомый с 2-3 разными подходами к кроссплатформенности.
Все остальное вторично. Если проект маленький, то никто не будет тратить деньги на его юзабилити, производительность и т.д. больше чем это требуется. Вы не сделаете красивый кроссплатформенный проект визардом. Все равно что-то вылезет.
Если проект большой, то можно на любой платформе сделать конфетку. К примеру в моем проекте изобретено немеряно велосипедов просто потому, что нам не подходили стандартные по скорости/памяти или функциональности. Именно поэтому у нас своя замена SWT, свой джаббер сервер и т.д.
1. Выбирать должен специалист (да, я знаю что об этом говорили, но я повторюсь)
2. Специалист должен выбрать то, с чем будет удобнее работать ему, то что он знает досконально. Если он не знает досконально ни один кроссплатформенный вариант - наймите другого специалиста. В идеале оценку должен делать человек знакомый с 2-3 разными подходами к кроссплатформенности.
Все остальное вторично. Если проект маленький, то никто не будет тратить деньги на его юзабилити, производительность и т.д. больше чем это требуется. Вы не сделаете красивый кроссплатформенный проект визардом. Все равно что-то вылезет.
Если проект большой, то можно на любой платформе сделать конфетку. К примеру в моем проекте изобретено немеряно велосипедов просто потому, что нам не подходили стандартные по скорости/памяти или функциональности. Именно поэтому у нас своя замена SWT, свой джаббер сервер и т.д.
Лучше вложите свои деньги в мой стартап ;)
Автор, некрасиво писать о том о чем вы не знаете, и употреблять термины которых скорее всего вы не понимаете(т.к. смысл у них другой). Почему бы просто не написать по человечески, понятным вам языком или так как вы поняли? Это все касаемо кроссплатформенности Java приложений, в вашей интерпретации.
Кстати, с
>>Минусы: ... низкая производительность.
Не соглашусь. Данное утверждение справедливо для первых версий виртуальной машины Java, однако в последнее время оно практически потеряло актуальность. Этому способствовал ряд усовершенствований: применение технологии JIT (Just-In-Time compilation), позволяющей переводить байт-код в машинный код во время исполнения программы с возможностью сохранения версий класса в машинном коде, широкое использование native-кода в стандартных библиотеках, а также аппаратные средства, обеспечивающие ускоренную обработку байт-кода (например, технология Jazelle, поддерживаемая некоторыми процессорами фирмы ARM).
>>Минусы: ... низкая производительность.
Не соглашусь. Данное утверждение справедливо для первых версий виртуальной машины Java, однако в последнее время оно практически потеряло актуальность. Этому способствовал ряд усовершенствований: применение технологии JIT (Just-In-Time compilation), позволяющей переводить байт-код в машинный код во время исполнения программы с возможностью сохранения версий класса в машинном коде, широкое использование native-кода в стандартных библиотеках, а также аппаратные средства, обеспечивающие ускоренную обработку байт-кода (например, технология Jazelle, поддерживаемая некоторыми процессорами фирмы ARM).
Если делать десктопную прогу на Java, то саму JRE можно включить в инсталлер (windows) или пакет (Linux).
jre-1_5_0_12-windows-i586-p.exe - 16 Mb.
Если такой размер не отпугнет пользователя, то почему бы и нет?
В проекте где я тружусь, виндовый инсталлер в своём составе имеет JRE, Tomcat, MySQL, JDBC MySQL driver и ставит любую из этих частей без лишних вопросов и только если она не стояла.
jre-1_5_0_12-windows-i586-p.exe - 16 Mb.
Если такой размер не отпугнет пользователя, то почему бы и нет?
В проекте где я тружусь, виндовый инсталлер в своём составе имеет JRE, Tomcat, MySQL, JDBC MySQL driver и ставит любую из этих частей без лишних вопросов и только если она не стояла.
немного запоздало, но полезно для топикстартера http://qt.osdn.org.ua/qt-vs-java.html
Используйте числа при указании производительности. Например в процентах. Если у C++ скорость выполнения по сравнению с Python на 20% выше, а скорость разработки по сравнению с Python на 200% медленнее, то выбор становится уже более очевидным, чем изначально.
Я считаю что скорость разработки тоже немаловажна, хотя если клиент готов платить за 20ти процентное увеличение скорости 200% от стоимости разработки на Python, то опять же выбор очевиден.
Я считаю что скорость разработки тоже немаловажна, хотя если клиент готов платить за 20ти процентное увеличение скорости 200% от стоимости разработки на Python, то опять же выбор очевиден.
НЛО прилетело и опубликовало эту надпись здесь
На чем писать мультиплатформенное desktop-приложение? Взгляд менеджера