A>> Да и корпоративным решениям (кои скорее сервисы а не продукты) оно только навредить может — вгрохивать кучу бабла и ресурсов в то, что никому не потребуется никто не будет. Пример — RSDN

AB>КЫВТ использует кросс-платформенное ПО — пример не канает.

Ну, не так уж и много он использует А от MSSQL'я и ASP.NET'а далеко с винды не уйдешь.

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

C>Для разработки ты тоже существенно недооцениваешь полезность такой фичи.

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

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

M> AB>КЫВТ использует кросс-платформенное ПО — пример не канает.
M> Ну, не так уж и много он использует А от MSSQL'я и ASP.NET'а далеко с винды не уйдешь.

Опровергался тезис "потому что нафиг оно не надо и даже вредно". Как видим, надо и полезно. Даже заявителю оного тезиса.

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

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

T>>Потому что .net сосет там где java рулит:
T>>http://blogs.computerworld.com/london_stock_exchange_suffers_net_crash

IT>Особенно прикольно там комментарии почитать.

И Net и Java не подходят, а зачем тогда Вынь? — конечно же RHEL, если все же есть деньги и хочется потратить. LSE точно начинали переходить на Linux после фейла описанного в линке. Год назад проводили коннективити тесты, которые и были связаны с переходом.

Еще был очень показательный, хотя и не такой нашумевший epic fail очень крупной биржи: они почти 2 года упорно переходили на java и фактически давили на своих клиентов предлагая java api и обещая прикрыть все остальное. Потом расширились неслабо, прикупив пару других эксченджей, да и объем данных вырос в 4 раза. Закончилось тем, что они же сами стали давить опять на всех уходить с Java API (стали давать FIX и каналы с спецификацией). На их стороне переход произошел частично — просто отовсюду идут лучи JNI теперь.

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

LP>И тут ты прав Пользователи линукс имеют активный секс с системой, пользователи Windows — пассивный секс с Microsoft. По-моему, лучше быть "похотливым" чем..

IMHO, секс лучше иметь с женой, а на работе иметь проф. рост, а не секс

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

I>Потому что дотнет сильнее теснит С++ нежели джаву благодаря своим возможностям интеграции с системой.
А как эти вопросы связаны? От чего то, что С# теснит "плюсы" как-то улучшается судьба явы?

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

C>Собственно, то что любой 3-rd party алгоритм и реализация неприемлима. Бред это.
Почему бред?

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

C>Как бэ, нет. HTMLayout примерно по технологичности наравне с WPF. Разве что под WPF больше наработок.

Вкусность WPF в его архитектуре и качестве изоляции Display, Command и Data моделей от рукописного кода. Реализация лейаутов и прочей графической фигни в нем чуть лучше полного отстоя. Да и XAML та еще гадость.

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

E__>Исключительно для знаний, можно списочек?

Нельзя

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

НС>> Наверняка есть и еще варианты. Принятие решения о кроссплатформенности — непростой и многофакторный процесс.
S>И тем не менее кросплатформенность — большой плюс.

Ты мое сообщение не читал, что ли?

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

S>Теже 80% продуктов, написанных при помощи qt не требуют никаких дополнительных затрат на поддержку кроссплатформенности.

Даже Java, изолирующая от платформы на пару порядков лучше, чем Qt, для более менее реальных приложений не обеспечивает кроссплатформенность забесплатно. Это я тебе как человек, который несколько кроссплатформенных приложений написал, говорю.

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

AB>КЫВТ использует кросс-платформенное ПО — пример не канает.

Пример канает, потому что явно имелся в виду не весь софт на сервере, а конкретно тот софт, который для RSDN уникален. Там, АФАИК, ничего кроссплатформенного нет вообще.

Здравствуйте, Ночной Смотрящий, Вы писали:

C>>Как бэ, нет. HTMLayout примерно по технологичности наравне с WPF. Разве что под WPF больше наработок.
НС>Вкусность WPF в его архитектуре и качестве изоляции Display, Command и Data моделей от рукописного кода. Реализация лейаутов и прочей графической фигни в нем чуть лучше полного отстоя. Да и XAML та еще гадость.
Подход в HTMLayout отличается от WPF. С одной стороны, нет системы байндинга — в этом она хуже WPF, но как раз тут можно поправить дела с помощью продуманной внешней библиотеки. Cистема байндинга в WPF, кстати, откровенно халтурная — можно и лучше было сделать (типа как здесь: http://pypi.python.org/pypi/Trellis ).

С другой стороны в HTMLayout есть превосходное отделение данных и их отображения, с чётким выделением стилизации — CSS+CSSS в HTMLayout убивают жалкую поддержку стилей в WPF.

Ещё по мелочам — accessibility в HTMLayout делается существенно проще.

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

C>>Собственно, то что любой 3-rd party алгоритм и реализация неприемлима. Бред это.
E>Почему бред?
Потому. Не бредом может быть требование прохождения тестов и/или сертефикации кода.

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

C>С другой стороны в HTMLayout есть превосходное отделение данных и их отображения, с чётким выделением стилизации — CSS+CSSS в HTMLayout убивают жалкую поддержку стилей в WPF.
А что там жалкого в этих самых стилях WPF, м?

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

C>>С другой стороны в HTMLayout есть превосходное отделение данных и их отображения, с чётким выделением стилизации — CSS+CSSS в HTMLayout убивают жалкую поддержку стилей в WPF.
MK>А что там жалкого в этих самых стилях WPF, м?
Тем, что они не CSS

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

C>Подход в HTMLayout отличается от WPF.

Я в курсе. Имено поэтому вышеприведенное написал. Перефразируя — почти все то, что у WPF и HtmlLayout общее, в WPF находится на уровне чуть выше полного отстоя. А все то, что в WPF действительно хорошо, в HtmlLayout отсутствует почти полностью.

C>С другой стороны в HTMLayout есть превосходное отделение данных и их отображения, с чётким выделением стилизации — CSS+CSSS в HTMLayout убивают жалкую поддержку стилей в WPF.

Это говорит о том, что WPF ты совсем не знаешь.

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

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

C>>>С другой стороны в HTMLayout есть превосходное отделение данных и их отображения, с чётким выделением стилизации — CSS+CSSS в HTMLayout убивают жалкую поддержку стилей в WPF.
MK>>А что там жалкого в этих самых стилях WPF, м?
C>Тем, что они не CSS
Это не ответ.

Здравствуйте, Ночной Смотрящий, Вы писали:

C>>Подход в HTMLayout отличается от WPF.
НС>Я в курсе. Имено поэтому вышеприведенное написал. Перефразируя — почти все то, что у WPF и HtmlLayout общее, в WPF находится на уровне чуть выше полного отстоя. А все то, что в WPF действительно хорошо, в HtmlLayout отсутствует почти полностью.
А что в WPF действительно хорошо? По-моему, там основная вещь — это отход от использования системных окон для всего и введение scene graph'а. Оба есть в HTMLayout.

Возможность дизайна UI отдельным дизайнером тоже ещё на основную фичу тянет, но тут HTMLayout вообще побеждает — для него HTML вполне реально могут дизайнить отдельные спецы по UI.

Ну и байндинг в WPF ещё тянет на четвёрочку. Идея с XPath-подобным языком классная, но могли бы и лучше сделать. Этого реально не хватает в HTMLayout.

C>>С другой стороны в HTMLayout есть превосходное отделение данных и их отображения, с чётким выделением стилизации — CSS+CSSS в HTMLayout убивают жалкую поддержку стилей в WPF.
НС>Это говорит о том, что WPF ты совсем не знаешь.
Знаю. В WPF нет каскадных стилей. Т.е. я не могу сказать "наложить стиль на все элементы с таким-то предком, за которым следует элемент с таким-то классом". Мощность CSS позволяет практически полностью отделить контент от отображения.

Из-за этого делаются велосипеды для WPF типа такого: http://www.scottlogic.co.uk/blog/colin/2009/03/using-css-selectors-for-styling-in-wpf/

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

MK>>>А что там жалкого в этих самых стилях WPF, м?
C>>Тем, что они не CSS
MK>Это не ответ.
Ответил Ночному Смотрящему.