Здравствуйте, Visor2004, Вы писали:

V>Т.е. выводы никак не соотносятся с приведенными таблицами ( видно, что ява охватывает все, кроме iOS )... Это наталкивает на мысль об использовании автором взаимоисключающих параграфов. Или недостаточно детальной проработки вопроса.

Java не допустима на iOS и Windows Phone 7 и не желательна на Mac OS X.

V>После просмотра скриншота кэп намекнет нам, что эмоциональная составляющая авторского message высосана из пальца.

А начале заметки я писал о приложении для "конечного пользователя". Такого класса приложение не должно и не может смотреться на столько страшно, как то, что отображается на приведенном скриншоте

V> не нэтивный интерфейс != ужасный

В случае с Mac OS X, не нэтивный интерфейс == ужасный.

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

Будут. И примеров таких приложений, насколько я знаю, нет.

V>А вот это вообще писк, особенно выделенное.

Угу, поправлю. Тут скорее речь о том, что либо трудности с поддержкой одной платформы (в данном случае это Windows Phone 7), либо нескольких. Если идти по пути наименьшего сопротивления, то логичнее отказаться от поддержки одной платформы (которая еще не факт что выстрелит вообще). А при отказе от ее поддержки реализация действительно будет нигде не нужна.

V>в целом вы, я уверен людям интересующимся, америку не открыли.

Да я и не претендовал, вобщем-то

По ряду причин, мне понадобилось подобрать наиболее простой способ написать максимально переносимое приложение для "конечного пользователя". В процессе поиска и оценки решения накопился довольно большой объем информации, которая возможно будет кому-то полезной. Как ни крути у нас тут часто возникают вопросы про платформы, фрэймворки, на чем писать и т.д.
Собственно вот мысли на эту тему. Дополнения и комментарии с радостью рассматриваются

P.S. даю заметку в виде линке т.к. лень переформатировать заметку, да и таблицы форум не поддерживает.

Здравствуйте, kaa.python, Вы писали:

Возможность построения GUI

Платформа/SDK C++ Java Objective-C C#
Windows + + — +
Linux + + — +
Mac OS X +/- +/- + —
iOS — — + +/-
Android — + — —
Symbian + + — —
Windows Phone 7 — — — +

Возможность написания бизнес-логики

Платформа/SDK C++ Java Objective-C C#
Windows + + + +
Linux + + + +
Mac OS X + + + +
iOS + — + +
Android + + — —
Symbian + + — —
Windows Phone 7 — — — +

Глядя в эти таблички видно, что максимальное покрытие функционала предоставляет Java, а вы в своих выводах пишете:

Выводы получаются довольно неожиданные. Java не является лучшим решением ни для написания кроссплатформенной логики, ни для написания кроссплатформенного GUI

Т.е. выводы никак не соотносятся с приведенными таблицами ( видно, что ява охватывает все, кроме iOS )... Это наталкивает на мысль об использовании автором взаимоисключающих параграфов. Или недостаточно детальной проработки вопроса.

Поклонников C# обрадует тот факт, что Mono работает на Mac OS X, но вот то как Mono приложение будет выглядеть на Маке заставит вздрогнуть даже не притязательного пользователя. Дело в том, что Mono использует библиотеку GTK, которая работает на Mac OS X только через X-сервер и отличается на редкость уродливым внешним видом (лично я это могу простит только Wireshark).

После просмотра скриншота кэп намекнет нам, что эмоциональная составляющая авторского message высосана из пальца. не нэтивный интерфейс != ужасный, хотите нэтива берите cocoa, не надо мозг людям пудрить, лучше вместо этого поизучайте биндинги к cocoa для mono и все будет выглядеть очень даже по маковски, хотя и все равно думаю найдутся ньюансы.

А вот это вообще писк, особенно выделенное.

А вот поддержку для Windows Phone 7 я бы стал делать только в крайнем случае. Создание приложения для этой платформы потребует отдельной реализации как логики, так и GUI которая нигде больше не пригодится.

т.е. плюсики в графе c# означают не то, что подсказывает капитан, а что-то другое?

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

Здравствуйте, kaa.python, Вы писали:

KP>да и таблицы форум не поддерживает.

Форум	поддерживает	таблицы
по крайней мере	их базовый	функционал

Питон там же, где C++ и где другие скриптовые языки, который можно присобачить к C++.

Написать полностью на питоне приложение хоть с какими-то требованиями к производительности и потреблению памяти, вряд ли реально.

Хотя, в принципе, это тоже вариант.

В том-то вся и проблема, что, вроде, возможности какие-то есть, но нет ни одной, которая бы покрывала все 100% платформ, и все это в таком аморфном и неопределенном состоянии, что совершенно непонятно, за что хвататься.

Здравствуйте, Kerbadun, Вы писали:

K>Питон там же, где C++ и где другие скриптовые языки, который можно присобачить к C++.
K>Написать полностью на питоне приложение хоть с какими-то требованиями к производительности и потреблению памяти, вряд ли реально.

С выделенным — не позволяет согласиться тот факт, что я ежедневно использую достаточно много приложений, реализованных на питоне, в т.ч. для решения весьма емких задач, в которых производительность стоит не на последнем месте. Вот некоторые из них:

http://www.digital-forensic.org/ и http://www.volatilesystems.com/default/volatility/
http://secdev.org/projects/scapy/
http://w3af.sourceforge.net/
http://code.google.com/p/sulley/
http://mercurial.selenic.com/

+ несколько десктоп приложений, включая клиент к вышеупомянутому mercurial, мессенджер digsby и т.п.

Их производительность очень даже, затраты памяти не выше, чем у дотнет-приложений. При том, что к w3af и sulley требования достаточно жесткие, т.к. первый является в т.ч. сканером уязвимостей веб-приложений, а второй фреймворком для фаззинга (тестирования через последовательности случайных данных).

Я не спорю с тем, что питон (при прочих равных) неспособен порвать по производительности или затратам памяти оптимизированный под конкретную задачу нативный код, но десктоп-приложения, на мой взгляд — не тот класс ПО, в котором можно часто встретить недостижимые для питона требования. Особенно учитывая тот факт, что в крайнем случае, всегда можно переписать критические участки на нативном языке и спокойно использовать их из py-кода.

Здравствуйте, kaa.python, Вы писали:

KP>Java не допустима на iOS и Windows Phone 7 и не желательна на Mac OS X.

WP7 не рассматриваем, просто тупо не вижу смысла это делать, там денег нет и ближайшие пару-тройку лет не будет. В случае с маками есть просто две категории софта:
1) мегавостребованный/корпоративный софт, будут юзать и пох какой UI, как пойдут деньги от продаж можно будет отдельно вложиться для напиcания UI на мак.
2) обычный, тупой софт типа "CD Ejector", совершая эмоциональную покупку яблокофил, конечно, будет отдавать предпочтение тому, что ему нравиццо, а именно — родной дизайн Apple.

Таким образом, тут надо просто с целевой аудиторией определиться, после этого вопрос о выборе платформы отпадет сам собой. Вопрос выбора платформы — это всегда вопрос, а кто и как будет мою программу юзать.

KP>В случае с Mac OS X, не нэтивный интерфейс == ужасный.
Опять таки — это только для макофилов, ну и от класса софта зависит.

Пользователь LeonidV узрел в моем сообщении полемику. Какие вы все однообразные, долбануться можно. Утомили.

Здравствуйте, Kerbadun, Вы писали:
K>Ну а за что минус?

Минус означает несогласие с постом. В данном случае, я не согласен с утверждением про быстродействие.

Здравствуйте, kaa.python, Вы писали:

KP>Да не забыл я ее. Осознанно не включил. Возможно я имею не верное представление, но мне думается что Blackberry это некая бизнес ориентированная платформа, на которой присутствует довольно ограниченный спрос на не бизнес ориентированные приложения.

Бизнес-уклон есть, но есть также много простых пользователей, и свой аппстор.

А бизнес-пользователи — это тоже хорошо ($$).

А по продажам RIM опережает и Android, и Apple. Это в мире, а в штатах RIM уходит в отрыв.

Здравствуйте, Kerbadun, Вы писали:

K>Я был бы счастлив, если бы действительно можно было писать критичные к быстродействию и потреблению памяти части на питоне, и не бояться получить проблемы, но, рассуждая трезво, надо быть полным идиотом, чтобы на это решиться в коммерческом проекте.

Ни спора ради, никто ни пишет критичные к быстродействию части на питоне. Пишут гибридные приложения, в которых объем кода на Си/C++ редко превышает 20% от общего объема кода приложения. Как пример Mercurial который является достаточно критичным к быстродействию приложением, (основные конкуренты git и svn на Си/C++):

N:\dev\tmp\mercurial-1.7.3

c/cpp: files = 9  lines = 3474  size = 75 kb. (76933 bytes)
cmd: files = 9  lines = 484  size = 10 kb. (10555 bytes)
python: files = 196  lines = 62441  size = 2104 kb. (2155475 bytes)

global: files = 214  lines = 66399  size = 2190 kb. (2242963 bytes)

Если считать по строкам кода, то сишного всего около 5%.

Для сравнения git:

N:\dev\tmp\git-1.7.3.5

c/cpp: files = 402  lines = 151554  size = 3866 kb. (3959474 bytes)
cmd: files = 568  lines = 94387  size = 2233 kb. (2286813 bytes)
tcl: files = 39  lines = 11597  size = 284 kb. (291507 bytes)
perl: files = 23  lines = 25939  size = 726 kb. (744402 bytes)
python: files = 14  lines = 2291  size = 69 kb. (71040 bytes)

global: files = 1046  lines = 285768  size = 7180 kb. (7353236 bytes)

Который в общем тоже гибридный, но наоборот основной код на си.

По своему опыту разработки разного рода внутренних утилит для разработчиков игр код на C++ занимал не больше 20%. И все это нормально работало на Celeron 400 Mh и 256 метрах памяти.

Здравствуйте, kaa.python, Вы писали:

KV>>А почему, кстати, не рассматривались динамические языки?

KP>Потому-что интересовал способ затащить приложение на как можно большее количество платформ. Т.к. приложение для пользователя, а не системная утилита, то вариант с тем чтобы требовать дополнительно что-то доустановить (тем более что-то такое массивное как интерпретатор) я не рассматривал. Ну и не стоит забывать про внешний вид приложения и пожелание родного интерфейса.

Могу сказать по питону, ничего доустанавливать конечному пользователю не нужно, приложение распространяется
как обычное нативное интерпретатор туда включен (это + 1 — 2 сжатых метра к дистрибутиву), ну и для разработчика
используя например http://www.pyinstaller.org/ или http://www.py2exe.org/ никаких сложностей это не доставляет.

Примеры таких приложений:
http://www.taskcoach.org/
http://tortoisehg.bitbucket.org/
http://wikidpad.sourceforge.net/

KP>Да и скорость работы интерпретируемых приложений не впечатляет, если честно

Для десктопа вполне достаточно, питон все-таки язык клей, все тяжелое будет делать C/C++ код.

Здравствуйте, rsn81, Вы писали:

R>На SWT прорисовка выполняется стандартными средствами OS, это некрасиво?

Тем не менее, SWT приложение не выглядит "родным" (в качестве примера можно взять тот же Eclipse). В определенных случаях это равносильно "некрасиво".

Здравствуйте, kaa.python, Вы писали:

KP>По ряду причин, мне понадобилось подобрать наиболее простой способ написать максимально переносимое приложение для "конечного пользователя". В процессе поиска и оценки решения накопился довольно большой объем информации, которая возможно будет кому-то полезной. Как ни крути у нас тут часто возникают вопросы про платформы, фрэймворки, на чем писать и т.д.
KP>Собственно вот мысли на эту тему. Дополнения и комментарии с радостью рассматриваются

KP>P.S. даю заметку в виде линке т.к. лень переформатировать заметку, да и таблицы форум не поддерживает.

А почему, кстати, не рассматривались динамические языки? Тот же питон есть на всех перечисленных платформах кроме ios и wp7. Причем в джейлбрейкнутой ios он уже давно есть (http://www.saurik.com/id/5), а если очень хочется, то можно и в нетронутой (http://www.philhassey.com/blog/2009/12/23/elephants-is-free-on-the-app-store/). Что касается wp7, то основным препятствием для использования этого языка там является отсуствие поддержки SR.Emit со стороны CLR, AFAIK (если говорить о дотнете и IronPython), либо пробовать подход для ios (трансляция в плюсовый код и сборка под конкретную платформу).

Здравствуйте, kaa.python, Вы писали:

KP>По ряду причин, мне понадобилось подобрать наиболее простой способ написать максимально переносимое приложение для "конечного пользователя".
Максимально переносимое приложение будет веб. Да и то из-за разных размеров экрана и органов управления может понадобиться делать разные интерфейсы для мобильных устройств и всех остальных.

Как только вы начинаете писать десктоп приложение, то сразу же надо думать о UI Guidelines, а они ооочень сильно отличаются для разных платформ.

Твое сообщение просто жжет напалмом.

Во-первых, оно совершенно мимо кассы: при чем тут декстоп и дотнет?

Во-вторых, это уж, извините, совсем маразм — спорить с тем, что динамический интерпретируемый язык может оказаться неподходящим для реализации критичных к быстродействию и потреблению памяти алгоритмов.

Не ожидал, что кому-то вообще придет в голову с этим не соглашаться.

У меня нет каких-то "религиозных" предубеждений, и я далеко не фанат C++, точнее, я его ненавижу лютой ненавистью.

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

Здравствуйте, kaa.python, Вы писали:

1. В каких сценариях есть востребованность кроссплатформенности между ПК и мобильными устройствами? Если такие сценарии и есть, то приложение настолько просты, что переписывание его для каждой специфичной платформы наверно не покажется трудоемким.
   
2. По поводу "некрасивой" Java: про SWT (Eclipse) слышали?

Здравствуйте, rsn81, Вы писали:

R>Здравствуйте, kaa.python, Вы писали:

R>В каких сценариях есть востребованность кроссплатформенности между ПК и мобильными устройствами? Если такие сценарии и есть, то приложение настолько просты, что переписывание его для каждой специфичной платформы наверно не покажется трудоемким.

Довольно во многих. Пара примеров: OmniFocus, GoogleTalk (и любая другая болталка), Twitter клииент.

R>По поводу "некрасивой" Java: про SWT (Eclipse) слышали?

Слышал конечно. Но вроде как я написал про то, где и почему Java смотрится не красиво.

Здравствуйте, kaa.python, Вы писали:

R>>По поводу "некрасивой" Java: про SWT (Eclipse) слышали?
KP>Слышал конечно. Но вроде как я написал про то, где и почему Java смотрится не красиво.
На SWT прорисовка выполняется стандартными средствами OS, это некрасиво?

Здравствуйте, kaa.python, Вы писали:

KP>Тем не менее, SWT приложение не выглядит "родным" (в качестве примера можно взять тот же Eclipse). В определенных случаях это равносильно "некрасиво".
Конкретнее можно, что не выглядит "родным"?

Здравствуйте, rsn81, Вы писали:

R>Конкретнее можно, что не выглядит "родным"?

Тулбары, табы, диалоги настройки, строка состояния.

Здравствуйте, kaa.python, Вы писали:

R>>Конкретнее можно, что не выглядит "родным"?
KP>Тулбары, табы, диалоги настройки, строка состояния.
По ссылке данной выше все это выглядит настолько нативно, насколько позволяет OS. Вы же говорите про надстройки над SWT сделанные в Eclipse RCP, в частности, JFace. Но их никто не заставляет использовать.

Здравствуйте, kaa.python, Вы писали:

KP>Собственно вот мысли на эту тему. Дополнения и комментарии с радостью рассматриваются

Для С++ (питона, руби, эрланга) есть еще wxWidgets как GUI библиотека лучше чем QT тем что для windows и linux(гномьего) рисует
нативными контролами, с маком те же проблемы что и у QT.

Здравствуйте, kochetkov.vladimir, Вы писали:

О!

Здравствуйте, FR, Вы писали:

FR>Здравствуйте, kaa.python, Вы писали:

KP>>Собственно вот мысли на эту тему. Дополнения и комментарии с радостью рассматриваются

FR>Для С++ (питона, руби, эрланга) есть еще wxWidgets как GUI библиотека лучше чем QT тем что для windows и linux(гномьего) рисует
FR>нативными контролами, с маком те же проблемы что и у QT.

Да, я про него в курсе. Дело в том, что Qt приложение довольно легко затягивается на Symbian и, в перспективе, MeeGo. Поэтому и не стал его рассматривать вообще.

Здравствуйте, kochetkov.vladimir, Вы писали:

KV>А почему, кстати, не рассматривались динамические языки?

Потому-что интересовал способ затащить приложение на как можно большее количество платформ. Т.к. приложение для пользователя, а не системная утилита, то вариант с тем чтобы требовать дополнительно что-то доустановить (тем более что-то такое массивное как интерпретатор) я не рассматривал. Ну и не стоит забывать про внешний вид приложения и пожелание родного интерфейса.
Да и скорость работы интерпретируемых приложений не впечатляет, если честно

Здравствуйте, kaa.python, Вы писали:

KP>Здравствуйте, kochetkov.vladimir, Вы писали:

KV>>А почему, кстати, не рассматривались динамические языки?

KP>Потому-что интересовал способ затащить приложение на как можно большее количество платформ. Т.к. приложение для пользователя, а не системная утилита, то вариант с тем чтобы требовать дополнительно что-то доустановить (тем более что-то такое массивное как интерпретатор) я не рассматривал. Ну и не стоит забывать про внешний вид приложения и пожелание родного интерфейса.

Не холивара ради, но есть аж несколько путей поставки приложений на питоне без создания пользователю неудобств, связанных с необходимостью установки среды исполнения и библиотек. Есть масса упаковщиков py-приложений в автономно работающие пакеты, есть возможность компиляции в нативный код и т.п. По поводу же внешнего вида — у питона есть биндинги ко всем распространенным UI-фреймворкам, плюс к большинству GUI API непосредственно платформ (к той же ios, например).

KP>Да и скорость работы интерпретируемых приложений не впечатляет, если честно

Ну речь-то не о полностью интерпретируемом приложении. Канонический питон, по сути — клей на байт-коде, обеспечивающий работу вполне себе нативных и оптимизированных напрочь библиотек, написанных на нативных-же языках. Если этого не достаточно, то есть сразу несколько путей компиляции py-кода в нативный, что также дает прирост производительности (почти всегда не дотягивающей до труъ-натива, конечно, но тем не менее).

Я собственно не настаиваю, просто показалось, что тема динамики не прорабатывалась не столько из-за нежелания, сколько из-за отсутствия достаточной информации, чтобы говорить о такой проработке всерьез.

Если ставится цель сделать приложение, которое не будет выглядеть чужеродным, то даже между Windows и Linux, да что там, даже между GNOME и KDE нет возможности сделать это переносимо. Т.к. в каждой среде свои Guidelines о том, как должно выглядеть приложение. Кнопочки родные или похожие на них нарисовать несложно, но этого не достаточно.

Поэтому интерфейсная часть для серьёзного приложения должна писаться отдельно для каждой платформы.

Ну а ядро, конечно, будет общее.

Поэтому имеет смысл сравнивать разные языки и платформы в контексте поддержки соответствующих биндингов к WinAPI, Cocoa, GTK, Qt, и т.д., ну и, непосредственно, кроссплатформенности.

Здравствуйте, kaa.python, Вы писали:

KP>Да, я про него в курсе. Дело в том, что Qt приложение довольно легко затягивается на Symbian и, в перспективе, MeeGo. Поэтому и не стал его рассматривать вообще.

Ну wx тоже в перспективе переползет, вот основной разработчик обещает Android http://wxwidgets.blogspot.com/2010/12/do-androids-dream-of-wxwidgets.html

Здравствуйте, FR, Вы писали:

FR>Ну wx тоже в перспективе переползет, вот основной разработчик обещает Android http://wxwidgets.blogspot.com/2010/12/do-androids-dream-of-wxwidgets.html

Еще вроде как с 3-й версии GTK не будет привязан к X-серверу. Будет вообще прекрасно просто

Да нет такого.

Вавилонское столпотворение.

Вы еще забыли такую серьезнейшую платформу как Blackberry. Там только Java.

Я уже себе весь мозг продумал на тему lingua franca, и как быть с готовой программой на C++.

Пока что ни хрена не придумал.

Пока что остается C++, а Blackberry и Windows Phone выпадают.

Что я могу сказать про всех производителей мобильных платформ: мудаки!!!

Здравствуйте, Kerbadun, Вы писали:

K>Вы еще забыли такую серьезнейшую платформу как Blackberry. Там только Java.

Да не забыл я ее. Осознанно не включил. Возможно я имею не верное представление, но мне думается что Blackberry это некая бизнес ориентированная платформа, на которой присутствует довольно ограниченный спрос на не бизнес ориентированные приложения.

Здравствуйте, Kerbadun, Вы писали:

K>Здравствуйте, kaa.python, Вы писали:

KP>>Да не забыл я ее. Осознанно не включил. Возможно я имею не верное представление, но мне думается что Blackberry это некая бизнес ориентированная платформа, на которой присутствует довольно ограниченный спрос на не бизнес ориентированные приложения.

K>Бизнес-уклон есть, но есть также много простых пользователей, и свой аппстор.

K>А бизнес-пользователи — это тоже хорошо ($$).

K>А по продажам RIM опережает и Android, и Apple. Это в мире, а в штатах RIM уходит в отрыв.

Очень интересно. А каким-то образом создать логику для Blackberry приложений на плюсах, или на чистом Си не представляется возможным? А какой API предоставляет их новый айпадоподобный девайс, тоже только Java?

Здравствуйте, kaa.python, Вы писали:

Да, есть еще такие хрени как Appcelerator, RhoMobile, PhoneGap, и еще из этой серии какие-то вроде есть.

Общая идея — использовать промежуточный язык и API как мост ко всем платформам, транслируя все в нативный код платформы.

Но пока что это все имеет неясные перспективы и возможности, плюс, привязываясь к такой платформе, начинаешь от нее зависеть полностью.

Да и у Mono дела не так плохо обстоят — вот весьма успешный коммерческий движок Unity 3D использует же его, значит можно.

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

Здравствуйте, kaa.python, Вы писали:

KP>Очень интересно. А каким-то образом создать логику для Blackberry приложений на плюсах, или на чистом Си не представляется возможным? А какой API предоставляет их новый айпадоподобный девайс, тоже только Java?

У них вся инфа открытая — http://us.blackberry.com/developers

На C/C++ — нет, в том и вся проблема.

Здравствуйте, Kerbadun, Вы писали:

K>Но пока что только C++ дает какую-то гарантию, что ты в какой-то критический момент не упрешься в проблемы какой-нибудь "прокладки".

да мало-ли для с++ существует прокладок, либ и прочих радостей абстракции? Это общий риск для любой разработки, имхо.

Здравствуйте, kaa.python, Вы писали:

Полагаю, это вызвано тем, что основная масса пользователей не любит отличный от Cocoa интерфейс и как следствие все стараются выпустить приложения с "родным" внешним видом. Недавно (Mac OS X 10.6.3), руку к этому приложила и компания Apple объявив Java “устаревшей”. Написанные на Java приложения и раньше отличались некой внешней убогостью и неповоротливостью (Stanza, Code Collaborator), но поддержка со стороны Apple гарантировала стабильность платформы. Теперь этого нет и использование Java уже не кажется на столько привлекательным решением как раньше.

Apple будет участвовать в разработке OpenJDK (http://www.apple.com/pr/library/2010/11/12openjdk.html).
Для Swing есть тема (доступна только на MacOS), которая достаточно близка к Cacao http://www.mucommander.com/screenshots.php

Здравствуйте, Kerbadun, Вы писали:

K>Пользователь LeonidV узрел в моем сообщении полемику.
С чего это вы так решили?

Здравствуйте, LeonidV, Вы писали:

K>>Пользователь LeonidV узрел в моем сообщении полемику.
LV>С чего это вы так решили?

Ну а за что минус?

Здравствуйте, FR, Вы писали:

FR>Ни спора ради, никто ни пишет критичные к быстродействию части на питоне. Пишут гибридные приложения, в которых объем кода на Си/C++ редко превышает 20% от общего объема кода приложения. Как пример Mercurial который является достаточно критичным к быстродействию приложением, (основные конкуренты git и svn на Си/C++):

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

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

Здравствуйте, Kerbadun, Вы писали:


K>Я имел в виду именно специфический случай, когда приложение целиком написано на питоне, так как в этом случае приложение имеет шансы быть портированным на все платформы, кроме WP7, но, к сожалению, этому мешает вопрос быстродействия.
Прикрутят туда DLR и на питоне что надо взлетит.

Здравствуйте, LeonidV, Вы писали:

LV>Apple будет участвовать в разработке OpenJDK (http://www.apple.com/pr/library/2010/11/12openjdk.html).

Может быть. Пока что, в официальной документации, есть только упоминание о том что Java устарела.

LV>Для Swing есть тема (доступна только на MacOS), которая достаточно близка к Cacao http://www.mucommander.com/screenshots.php

Ого… Ну разве что в сравнении с GTK "это" достаточно близко

Здравствуйте, kaa.python, Вы писали:

LV>>Для Swing есть тема (доступна только на MacOS), которая достаточно близка к Cacao http://www.mucommander.com/screenshots.php

KP>Ого… Ну разве что в сравнении с GTK "это" достаточно близко
Ближе, чем темы от Adobe