Что, господа суровые С++ программисты, поспорим быстродействием с отстойной Джавой? ;)

anonymous_lor> на ум приходит только работа с огромными обемами данных ... типа перекодирования видео ...

Каков ум, таковы и результаты...

anonymous_lor> все это костыли, и нужны чтобы не умереть в энтерпрайзных абстрациях ...

Ну что тут можно сказать, видимо масштаб Ваших работ никогда не выходил за пределы "Hello, World!". И Вы даже не представляете какое ПО существует (и разрабатывается) в мире...

Сергей-4030> Что ж вам еще сказать. Есть имплементации систем, использующих треды, но не использующие util.concurrent. И не просто использующих, а повышающих эффективность и/или упрощающих дизайн многократно за счет использования тредов.

Это правда.

Сергей-4030> Для вас же если util.concurrent не используют, значит и multithreading им не нужен.

А это неправда. Речь о том, что как только нормальный разработчик начинает использовать потоки, он тут же узнает много нового и интересного, и быстро переходит ко всему спектру фич этого раздела.

Сергей-4030> И что? Я не понял, что с того? pragma есть указания компилятору, pragma ничем концептуально не отличается от задания ключей компилятора. Или вы и с этим несогласны?

С этим несогласен стандарт. Ещё раз повторяю: реакция на #pragma является implementation-defined. Компилятор волен делать что угодно. В случае OpenMP #pragma являются расширением языка. Можете считать их операторами.

Вот как выглядит Ваш код портированный (за 10 минут) на C++/OpenMP:

1.     static int solve(const int size, bool checkTransitions) {
2.         setLimits(size, false, checkTransitions);
3.         known_positions.clear();
4.         solution_pointer = 0;
5.  
6. #pragma omp parallel for num_threads(size)
7.         for (int i = 0; i < size; i++) {
8.             Solution s(i);
9.             s.arrange();
10.         }
11.  
12.         return solution_pointer;
13.     }

1. #pragma omp critical
2. {
3.             if ((!CHECK_TRANSITIONS) || (known_positions.end() == known_positions.find(desk))) {
4.                 addKnownPosition(desk);
5.                 solutions[solution_pointer++] = desk;
6.                 result = true;
7.             }
8. }

Теперь расскажите как такое сделать ключами компилятора

*А ведь ещё совсем недавно Вы издевались над Eretik'ом: "Я про С++ знаю более-менее все ... Вы же про Яву читаете из бульварных журналов" Как выяснилось, на самом деле обе стороны достойны друг друга

Сергей-4030> Вы знаете, пока что я не знаком ни с одним Вашим проектом и потому нет у меня никаких оснований полагать, что вы можете чего-то там указывать мне с высоты вашего опыта без доказательств. Уж извините.

Не извиняю. Мои проекты не имеют никакого отношения к вопросам знания языка/платформы.

*Чисто для справки. Свой крайний коммерческий проект на C++ я выполнил ещё до принятия стандарта Потом работал в основном с Java во всех её ипостасях. Ну а три года назад перешёл на .NET (направление и скорость развития Java перестали меня устраивать)

Сергей-4030> Но ее главная направленность - операционные системы и продукты для "десктопного" пользователя, что накладывает отпечаток. И такая направленность - отнюдь не самая распространенная, более того - вполне исключительная.

Чушь. Десктопных приложений навалом, это мэйнстрим, как на массовом бытовом рынке, так и в enterprise'е.

Сергей-4030> ЗЫ А в каком направлении вообще будет двигаться показ класса?

Ну-у-у, например, полагаю интересно будет показать как выглядят unit test'ы и соответствующие фрэймворки на топовой платформе.

Сергей-4030> UML нам напишете и design specifications? Ума не приложу, как это на чисто алгоритмической задачке вы будете это все показывать.

Как раз вычислительные задачи и требуют самых точных спецификаций. Только не в том смысле в каком Вы их себе представляете. Слышали такие термины: "корректность", "частичная корректность", "предусловие", "постусловие", "инвариант", "сходимость", "устойчивость" ???

Сергей-4030>> И что? Я не понял, что с того? pragma есть указания компилятору, pragma ничем концептуально не отличается от задания ключей компилятора. Или вы и с этим несогласны?
Nikita> С этим несогласен стандарт. Ещё раз повторяю: реакция на #pragma является implementation-defined. Компилятор волен делать что угодно. В случае OpenMP #pragma являются расширением языка. Можете считать их операторами.

Можно и макросы считать операторами, было бы желание.

Nikita> Вот как выглядит Ваш код портированный (за 10 минут) на C++/OpenMP:
Nikita> Теперь расскажите как такое сделать ключами компилятора

А вы полный текст приведите. И, собственно, что именно вы хотите продемонстрировать этим? То, что в Джава вы должны явно запустить нити, а OpenMP может это автоматизировать? Если вам это так важно - пользуйте annotation classes - и при сильно большом желании будете управлять фактически кодогенерацией. Но, опять же, это к чему?

Nikita> *А ведь ещё совсем недавно Вы издевались над Eretik'ом: "Я про С++ знаю более-менее все ... Вы же про Яву читаете из бульварных журналов" Как выяснилось, на самом деле обе стороны достойны друг друга

Я не занимаюсь последнее время C++, правда. Не работал с OpenMP. Но OpenMP не входит в стандарт C++ пока что еще, не правда ли?

Сергей-4030>> Вы знаете, пока что я не знаком ни с одним Вашим проектом и отому нет у меня никаких оснований полагать, что вы можете чего-то там казывать мне с высоты вашего опыта без доказательств. Уж извините.
Nikita> Не извиняю. Мои проекты не имеют никакого отношения к вопросам знания языка/платформы.

Языка!?

Сергей-4030>> Но ее главная направленность - операционные системы и продукты для "десктопного" пользователя, что накладывает отпечаток. И такая направленность - отнюдь не самая распространенная, более того - вполне исключительная.
Nikita> Чушь. Десктопных приложений навалом, это мэйнстрим, как на массовом бытовом рынке, так и в enterprise'е.

Мэйнстрим? Это где же? Скажем, Оракл десктопными приложениями занимается прежде всего? Онлайн-банкинг, биллинг всякий, страховые компании, сети продаж, безопасность etc?

Сергей-4030>> ЗЫ А в каком направлении вообще будет двигаться показ класса?
Nikita> Ну-у-у, например, полагаю интересно будет показать как выглядят unit test'ы и соответствующие фрэймворки на топовой платформе.

И какие же unit testы вы предлагаете?

Сергей-4030>> UML нам напишете и design specifications? Ума не приложу, как это на чисто алгоритмической задачке вы будете это все показывать.
Nikita> Как раз вычислительные задачи и требуют самых точных спецификаций. Только не в том смысле в каком Вы их себе представляете. Слышали такие термины: "корректность", "частичная корректность", "предусловие", "постусловие", "инвариант", "сходимость", "устойчивость" ???

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

Сергей-4030> Можно и макросы считать операторами, было бы желание.

Можно считать что угодно, но в стандарте всё описано вполне чётко и конкретно.

Сергей-4030> А вы полный текст приведите.

Не люблю некрасивый код выкладывать, даже если это всего лишь прямой порт Он всё равно практически ничем не отличается от Вашего оригинала. И эти две #pragma есть единственные моменты касающиеся многопоточности.

Сергей-4030> И, собственно, что именно вы хотите продемонстрировать этим?

То что #pragma это не "ключик компилятора"...

Сергей-4030> То, что в Джава вы должны явно запустить нити, а OpenMP может это автоматизировать?

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

Сергей-4030> Если вам это так важно - пользуйте annotation classes - и при сильно большом желании будете управлять фактически кодогенерацией.

Это криво. "Синтаксический сахар" должен быть бесшовно интегрирован.

Сергей-4030> Но OpenMP не входит в стандарт C++ пока что еще,

А речь не об OpenMP. Речь о препроцессоре и #pragma.

Сергей-4030> не правда ли?

Пока нет. Комитет как раз решает, с какой стороны подойти к поддержке многопоточности. Возможно OpenMP и будет базой.

Nikita>> Не извиняю. Мои проекты не имеют никакого отношения к вопросам знания языка/платформы.
Сергей-4030> Языка!?

Ага. Я же не соревнуюсь с Вами в C++ кодинге.

Nikita>> Чушь. Десктопных приложений навалом, это мэйнстрим, как на массовом бытовом рынке, так и в enterprise'е.
Сергей-4030> Мэйнстрим? Это где же?

Ну вот давайте посмотрим на мой taskbar: FAR, Opera, Acrobat Reader, Visual Studio 2008, Expression Blend, StrongDC++, uTorrent... Куча десктоп-приложений, и вот что странно, ни одного Java'овского С .NET, правда, тоже не всё так хорошо как хотелось бы, но всё-таки Blend спасает ситуацию (ну и VS2008 содержит managed-компоненты) А всё остальное - сплошное C++ практически...

А что у Вас в taskbar'е ?

Сергей-4030> Скажем, Оракл десктопными приложениями занимается прежде всего?

А причём здесь эта махонькая корпорация с жалким 5-ком миллиардов продаж ?

Сергей-4030> Онлайн-банкинг, биллинг всякий, страховые компании, сети продаж, безопасность etc?

Ничего не понял. Вы хотите сказать, что Oracle Database 11g типа на Java написан ?

Сергей-4030> И какие же unit testы вы предлагаете?

Обычные, какие же ещё ?

Nikita>> Как раз вычислительные задачи и требуют самых точных спецификаций.
Сергей-4030> Я буду очень рад послушать.

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

Nikita> Ну вот давайте посмотрим на мой taskbar: FAR, Opera, Acrobat Reader, Visual Studio 2008, Expression Blend, StrongDC++, uTorrent... Куча десктоп-приложений, и вот что странно, ни одного Java'овского С .NET, правда, тоже не всё так хорошо как хотелось бы, но всё-таки Blend спасает ситуацию (ну и VS2008 содержит managed-компоненты) А всё остальное - сплошное C++ практически...

А во сколько Вам все это обошлось? Я не в порядке наезда, чисто в порядке сравнения - сколько с вас поимели производители всего этого десктопного софта. Скажем, если у вас все лицензионное - сколько это стоит в сумме? И сколько стоит биллинг-система какая-нибудь банковская.

Nikita> А причём здесь эта махонькая корпорация с жалким 5-ком миллиардов продаж ?

При том, что десктопными приложениями она вовсе практически не занимается. Не мейнстрим?

Nikita> Ничего не понял. Вы хотите сказать, что Oracle Database 11g типа на Java написан ?

См. выше.

Сергей-4030>> И какие же unit testы вы предлагаете?
Nikita> Обычные, какие же ещё ?

В смысле - что именно в данном случае тестировать? Какой план regression testing вы бы порекомендовали в данном случае?

Сергей-4030>> Я буду очень рад послушать.
Nikita> На эту тему скорее всего нет. Надо много вспоминать, уж очень давно последний раз вычислительными вещами занимался...

Очень жаль. Но все-таки покажете хоть сколько-то класса на C#.

Сергей-4030> А во сколько Вам все это обошлось?

$0.00

Blend - preview'шный, VS2008 - места знать надо где раздают Ну а всё остальное есть freeware. Ну ладно, можете посчитать Windows Vista Ultimate, ажно $50 (хороший в Редмонде магазинчик для сотрудников Microsoft, MVP и т.д. )

Сергей-4030> И сколько стоит биллинг-система какая-нибудь банковская.

Не знаю. И совершенно не понимаю при чём тут бабло. Мэйнстрим - это то что прямым образом пользуют соответствующие массы.

Сергей-4030> При том, что десктопными приложениями она вовсе практически не занимается. Не мейнстрим?

Неа. Это мэйнстрим для разработчиков, а пользователи этого ничего не видят и на свои машины не ставят.

Сергей-4030> В смысле - что именно в данном случае тестировать?

То что должны тестировать unit test'ы.

Сергей-4030> Какой план regression testing вы бы порекомендовали в данном случае?

Ещё смешней. У нас даже первой версии нет. Какой тут ещё regression ?

*Вы всё-таки хотя бы Wikipedia почитайте на тему...

Balancer> Да ещё очень желательно не цепляться за массу традиционного уже кода, менять который просто расточительно.

Угу-угу... "Здесь играем, здесь не играем" (с) не мой

Код есть, он нужен, и его нужно развивать. И это факт от которого нельзя отвертеться. И факт настолько, что у того же Microsoft'а, несмотря на массу девелопмента на .NET, владение C++ является обязательным базовым требованием для всех SDE.

Сергей-4030>> При том, что десктопными приложениями она вовсе практически не занимается. Не мейнстрим?
Nikita> Неа. Это мэйнстрим для разработчиков, а пользователи этого ничего не видят и на свои машины не ставят.

А что у нас, кто использует языки программирования - разработчики, или пользователи?

Сергей-4030>> В смысле - что именно в данном случае тестировать?
Nikita> То что должны тестировать unit test'ы.

А конкретно, конкретно. Какие именно тесты поименно, что тестируют в данном случае.

Сергей-4030>> Какой план regression testing вы бы порекомендовали в данном случае?
Nikita> Ещё смешней. У нас даже первой версии нет. Какой тут ещё regression ?
Nikita> *Вы всё-таки хотя бы Wikipedia почитайте на тему...

Ага. Вы же говорили о том, что вы-то бы показали класс, наиспользовали бы то и се, не я.

ЗЫ Мне не надо Wikipedia использовать, я, слава богу, каждый день этим занимаюсь. Кстати говоря, у меня это третья редакция данной имплементации. Хотя, конечно regression testing было не про это, это был типа стеб по поводу ваших комментариев, как надо использовать то и это.

Nikita> Я рад, что Вы оценили эту важную фичу. У OpenMP много недостатков, но вот этот момент - правильный.

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

Сергей-4030> Не касаясь прочего флейма, мне не кажутся правильными подобные имплементации. На большинстве компьютеров у нас пока что всего несколько процессоров/ядер. Если бы были сотни ядер и я бы более-менее мог бы быть уверенным, что всегда найдется пара десятков незанятых - тогда будет время таких решений.

Только вот наоборот всё. Как раз потому что неизвестно количество ядер на которых будет исполняться код, языковая поддержка должна выражаться в терминах "вот это можно параллелить; на сколько и как - это твои проблемы, компилятор". И OpenMP как раз следует этому совершенно правильному подходу. Если убрать num_threads(size), то будет сгенерён код определяющий количество процессоров, порождающий необходимое количество потоков, и "пилящий" for на соответствующее число "кусочков". Более того, стратегий распила предлагается целая пачка, да ещё и настраеваемых.

*num_threads(size) я ввёл исключительно для полной аналогичности кода с Вашим оригиналом

Сергей-4030> но это во-первых - оверхед,

Копейки.

Сергей-4030> а во-вторых - не учитывает, что вполне могут быть какие-то другие треды в приложении, которые, скажем, более приоритетны.

Это-то как раз можно учесть. Не с C++, правда

Nikita> Только вот наоборот всё. Как раз потому что неизвестно количество ядер на которых будет исполняться код, языковая поддержка должна выражаться в терминах "вот это можно параллелить;

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

Сергей-4030> Это ваша точка зрения.

Это факты, а не "точка зрения". Если не согласны - приводите контраргументацию, а не ведите себя как подросток.

Сергей-4030> В будущем, когда ядер будет столько,

Это самое будущее давным-давно наступило. У меня вот под столом стоит Core 2 Quad. И что ? Мэйнстрим ПО может его эффективно загрузить на 100% ??? Угу, как же... Практически вся софтина такого толка с двумя-то ядрами с трудом справляется, а дальше полный капут. И всё это как раз потому, что писали вот такие товарищи как Вы, дальше машинного кода видеть положение неспособные...

Сергей-4030> А сейчас, когда ядро - очень дорогой ресурс,

Чушь полнейшая!!! Дешевле некуда они сейчас. Весь рост идёт в количество ядер+потоков исполнения. GPU вообще чуть-ли не по 100+ за поколение накидывают. Средний девайс, типа моего 8800GTX, выдаёт для FoldingHome ажно 100GFLOPS+ производительности!!! x86, Cell, POWER'ы, SPARC'и, даже микроконтроллеры пошли уже многоядерные. Вы в сауне, что ли, последние пять лет живёте ???

Всё это добро нагрузить не могут эффективно, вот где проблема тормозящая развитие...

Nikita> Это самое будущее давным-давно наступило. У меня вот под столом стоит Core 2 Quad. И что ? Мэйнстрим ПО может его эффективно загрузить на 100% ??? Угу, как же...

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

Сергей-4030>> Это ваша точка зрения.
Nikita> Это факты, а не "точка зрения". Если не согласны - приводите контраргументацию, а не ведите себя как подросток.

Ах, факты...

Сергей-4030>> В будущем, когда ядер будет столько,
Nikita> Это самое будущее давным-давно наступило. У меня вот под столом стоит Core 2 Quad. И что ? Мэйнстрим ПО может его эффективно загрузить на 100% ???

Мэйнстрим ПО? Какое именно ПО не способно эффективно нагрузить? Notepad? Вот у нас сервер на хорошей нагрузке загружает все ядра, какие только есть без проблем. И всякие игрушки у меня на компьютере оба ядра пользуют только так. Нет, безусловно, есть программы, которые не умеют пользовать все ядра. Но обычно с ними и проблем быстродействия нет - они и в одном ядре в лучшем виде выполняются без задержек. А вот тяжеловычислительные - те умеют. Мы на одной планете с вами живем?

Nikita> Угу, как же... Практически вся софтина такого толка с двумя-то ядрами с трудом справляется, а дальше полный капут. И всё это как раз потому, что писали вот такие товарищи как Вы, дальше машинного кода видеть положение неспособные...

Ну понятно, такие товарищи, как вы видят просто сквозь стены. Вы с какой стати пальцы-то гнете таким образом? Какие тому основания? У вас какие-то знаменитые проекты? Вас работодатель ценит так, что платит мильон? Вы приведите основания-то наконец.

Сергей-4030>> А сейчас, когда ядро - очень дорогой ресурс,
Nikita> Чушь полнейшая!!! Дешевле некуда они сейчас.

Ну да, ну да. У меня сейчас два ядра. И поэтому выделить двадцать ядер на параллельное вычисление какого-то цикла - легко! Я не понимаю, как выделить еще двадцать, если их всего два, но вы-то понимаете, конечно. И добавить еще сотню ядер - уж дешевле некуда, да. Пришлите мне пару таких процессоров, пожалуйста. А лучше сотен пять процессоров добавьте, коли "дешевле некуда". Да что сотню, дайте разбивку, сколько стоит добавить хотя бы пятьдесят.

Nikita> x86, Cell, POWER'ы, SPARC'и, даже микроконтроллеры пошли уже многоядерные.

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

Nikita> Вы в сауне, что ли, последние пять лет живёте ???

В курятнике.

Nikita> Я описал реальную задачу для реальной библиотеки.
не сомневаюсь, только в этой ветке обсуждается совсем другая задача ...
Nikita> Как только пошла поддержка J2ME - на рынке мгновенно начался бум, и вышла масса отличных приложений.
бум начался не поэтому ... бум начался потому что появилась возможность продать че-то новое ... язык разработки приложений под эти самые мобилы не имеет никакого значения ...
Nikita> Ага. Наверное от очень хорошей жизни, то бишь от обилия замечательных текстовых редакторов доступных на UNIX-платформах
ну так и где же все замечательные супер портабельные текстовые редакторы на супер портабельной Яве ...
Nikita> *Кстати, ещё один штрих отлично характеризующий Ваш уровень.
Nikita> то я бы порекомендовал Вам сменить профессию. Принесёте меньше вреда...
Nikita> Ничего подобного, это просто Ваша безграмотность, необразованность и непрофессионализм..
Nikita> Каков ум, таковы и результаты...
Nikita> видимо масштаб Ваших работ никогда не выходил за пределы "Hello, World!".
мда ... все как обычно вопщем, во всяких спорах через интернет ... вы за мой ум, уровень и образованность не волнуйтесь, я с этим сам как-нибудь разберусь ... лучше беспокойтесь как вам на земле остаться, того и гляди вознесетесь на небеса ...
Nikita> Совершенно не понимаю, что Вас так напугало
а напугало меня то, что для решения простой задачи скачивания с веб-сайта страницы и сохранения её в локальный файл, городят какие-то немыслимые и совершенно ненужные конструкции и сложности ... с очень неочевидной последовательностью выполнения программы ...

Nikita> Ну вот давайте посмотрим на мой taskbar: FAR, Opera, Acrobat Reader, Visual Studio 2008, Expression Blend, StrongDC++, uTorrent... Куча десктоп-приложений, и вот что странно, ни одного Java'овского
ну так а что же вы ... пользуетесь каким-то отстоем из прошлого века ... никаких супер портабельных программ на Яве, или на C#, которые отличаются от обычных программ что не просто работают, а работают "круто" ... сохраняют страницы с помощью AsyncEnumerator-ов, время узнают со спутника наверно, не меньше ...

Murkt> Порадовало то, как по ходу дела MS Word записали в текстовые редакторы без зазрения совести. Вот уж действительно сделали из утки слона.
с высоты птичьего полета плохо видно всякие notepad-ы знаете ли ...

Balancer> У меня на десктопе практически весь софт многоядерность эффективно использует.
и какой же это интересно ? ... веб браузер? почтовый клиент ? аська ? текстовый редактор ? файловый менеджер ? записывалка компакт-дисков ? ... что-то мне кажется что "практически весь" это две-три программы, типа компилятора, антивируса и ещё каких-нить смотрелок видео и слушалок аудио ... ну игры ещё ... все ... об эффективности речи не идет вообще, одноядерные-то процессоры простаивают без работы, а уж для многоядерных обычному пользователь задач вообще не сыскать ...

Сергей-4030> Впрочем, дискуссия сильно ушла в оффтопик. Я в одностороннем порядке объявляю мораторий на три дня.
надоже ... вы только заметили ? ...
вобщем-то типичная интернет-дискуссия, где каждый кулик хвалит свое болото ... "а вот я", "а вот у меня" ... и никто не хочет понять про что говорят другие ... зря байты на сервере только тратим ...

anonymous_lor> что-то мне кажется что "практически весь" это две-три программы, типа компилятора, антивируса и ещё каких-нить смотрелок видео и слушалок аудио

Весь вышеперечисленный софт прекрасно и на одном ядре живёт на свой процесс.

Кстати, браузер у меня - потока в три сидит. Так что до трёх ядер загрузить может.

Почтовик и аська - ну, тут понятно. Им и 1/10 ядра хватит.

А вот где многоядерность нужна - тут всё отлично. Ты сам назвал аудио- и видеопроигрыватели, например. Или те же архиваторы.

А в остальном - уже дело операционной системы - раскидать процессы по разным ядрам. С этим она отлично справляется.

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

anonymous_lor> ну так а что же вы ... пользуетесь каким-то отстоем из прошлого века ...

Ну так а что делать ? Кругом-то сплошь helloworlder'ы, да notepader'ы, вот и софт соответствующий...

anonymous_lor> никаких супер портабельных программ на Яве,

За этим, пожалуйста, к местным Java'истам. Бо как раз отсутствие развития Java в области desktop/client приложений, и стало одним из ведущих факторов заставивших меня сменить платформу.

anonymous_lor> или на C#, которые отличаются от обычных программ что не просто работают, а работают "круто"

Вы невнимательны. Expression Blend.

anonymous_lor> бум начался не поэтому ... бум начался потому что появилась возможность продать че-то новое ...

Чтобы продать, нужно сначала сделать. Чем меньше времени и квалификации требуется на это самое "сделать", тем больше будет предложение. А когда простейший клиент для web-приложения требует полгода работы, то ничего существенного на выходе не появится.

anonymous_lor> язык разработки приложений под эти самые мобилы не имеет никакого значения ...

Вы глубоко заблуждаетесь. В секторе где тусовался BREW, например, никакого бума не было.

anonymous_lor> а напугало меня то, что для решения простой задачи скачивания с веб-сайта страницы и сохранения её в локальный файл,

Для helloworlder'ов эта задача несомненно кажется простой. А для разработчиков proxy/cache сервисов а-ля squid, например, всё совсем по-другому. И для них слова scalability, density, throughput не являются "Ынтерпрайзной абстракцией"...

anonymous_lor> городят какие-то немыслимые и совершенно ненужные конструкции и сложности ...

Конструкции все те же самые. И именно в этом состоит преимущество. Мне не нужно парить мозг изобретая самопальные контексты и эмулируя поведение using/try/catch/finally. Я просто пишу практически такой же код как и в случае синхронного I/O.

anonymous_lor> с очень неочевидной последовательностью выполнения программы ...

Всё абсолютно очевидно. Как работала последовательно, так и будет. То что по-ходу дела может меняться поток в котором идёт исполнение ничего загадочного не представляет.

А вот если Вы посмотрите на реализацию асинхронного I/O в том же squid'е... Хотя лучше не надо, опасаюсь что Вы помрёте даже на первом уровне абстракции