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

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

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

Здравствуйте, 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++ код.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Здравствуйте, 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++ — нет, в том и вся проблема.

Питон там же, где 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-кода.

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

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

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

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

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

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

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

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

Здравствуйте, 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Здравствуйте, 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 метрах памяти.

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

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

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

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