Некоторое время назад я искал работу разработчика на C#.
Прошел множество интервью, в основном в фирмах, занимающихся
разработкой софта для промышленности. От Штутгарта до Вены,
пару раз меня заносило в Швейцарию Так вот, в абсолютном
большинстве контор был вопрос "Вы не против возвращения на С++ ?"
Я на СРР шесть лет оттрудился, и до сих пор его нежно люблю

Подумалось мне, а не является ли такой вопрос неким провозвестником
тенденции возврата "к корням"?, потому что, по крайней мере в промышленности
люди не уверены в будущем платформы .NET. Или это у меня что-то параноидальное?
Потому что буквально нескольло дней назад листал один местный программерский
журнал, где была предпринята довольно робкая попытка противопоставить "старую"
платформу .NET и новую WinRT.

Дорогой форум, что ты думаешь по этому поводу?

PS: Чтобы быть в курсе уже купил книжку по С++ 11.

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

S>большинстве контор был вопрос "Вы не против возвращения на С++ ?"
S>Я на СРР шесть лет оттрудился, и до сих пор его нежно люблю

может наоборот — люди хотят с плюсов переносить на шарп?

S>Подумалось мне, а не является ли такой вопрос неким провозвестником
S>тенденции возврата "к корням"?, потому что, по крайней мере в промышленности
S>люди не уверены в будущем платформы .NET. Или это у меня что-то параноидальное?

параноидальный ... я сейчас как раз ковыряюсь и пишу на шарпе и wpf —
стал понимать почему меня называли извращенцем изза того что
на голом винапи UI пишу

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


S>Дорогой форум, что ты думаешь по этому поводу?

C++ ренессанс и все дела.
Здесь http://channel9.msdn.com/posts/C-and-Beyond-2011-Herb-Sutter-Why-C
Саттер объясняет что и почему..

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

S>Некоторое время назад я искал работу разработчика на C#.
S>Прошел множество интервью, в основном в фирмах, занимающихся
S>разработкой софта для промышленности. От Штутгарта до Вены,
S>пару раз меня заносило в Швейцарию Так вот, в абсолютном
S>большинстве контор был вопрос "Вы не против возвращения на С++ ?"
S>Я на СРР шесть лет оттрудился, и до сих пор его нежно люблю
Меня недавно спросили о том же самом. Сказал "не против". Результат — no hire

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

S>>большинстве контор был вопрос "Вы не против возвращения на С++ ?"
S>>Я на СРР шесть лет оттрудился, и до сих пор его нежно люблю
MM>Меня недавно спросили о том же самом. Сказал "не против". Результат — no hire

Очевидно из-за этого ответа не взяли или могли быть иные причины?

Определённо, тенденция есть. Можно, например, вспомнить "битву за натив" для андроида, закончившуюся победой натива. На Win Phone C++ будет чуть ли не основным языком разработки. MS внезапно прикручивает доступ к WPF из С++.

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

S>Дорогой форум, что ты думаешь по этому поводу?

Это явная тенденция и она обсуждалась на этом форуме уже несколько раз в течение последнего года.

_>Это явная тенденция и она обсуждалась на этом форуме уже несколько раз в течение последнего года.

А причина? ДотНет не нужен?

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

_>>Это явная тенденция и она обсуждалась на этом форуме уже несколько раз в течение последнего года.

Y>А причина? ДотНет не нужен?

Ну сколько я помню, по итогам прошлых дебатов было выдвинуто две версии: либо дот нет — тормоз, либо Sinofsky — кАзел.

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

Y>А причина? ДотНет не нужен?

Плюситсам хочется чувствовать себя нужными и полезными.

Если серьезно, то тенденция ровно обратная: везде где только можно отказываются от C++ в пользу Pure C, или managed языков.

M>Если серьезно, то тенденция ровно обратная: везде где только можно отказываются от C++ в пользу Pure C, или managed языков.

Аха. Только "можно" оказывается практически нигде. Что касается Pure C, то нет абсолютно никаких аргементов в пользу такого перехода. Ничего не мешает писать на С++ в стиле Pure C, используя лишь небольшой набор фич, таких, как объявление переменных в середине блока, ссылки и пр.

Здравствуйте, Евгений Коробко, Вы писали:

ЕК>Аха. Только "можно" оказывается практически нигде.
Что-то нынче уровень вранья в КСВ зашкаливает. Даже неинтересно.

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

P>C++ ренессанс и все дела.
P>Здесь http://channel9.msdn.com/posts/C-and-Beyond-2011-Herb-Sutter-Why-C
P>Саттер объясняет что и почему..

С самого начала вводится постулат Perf/$ без каких либо доказательств. По мне так это не верно. То, что на плюсах можно добится быстродействия большего, чем на управляемых языках — с этим никто не спорит. Но то, что этого добится дешевле — это как раз очень большой вопрос.

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

IT>С самого начала вводится постулат Perf/$ без каких либо доказательств. По мне так это не верно. То, что на плюсах можно добится быстродействия большего, чем на управляемых языках — с этим никто не спорит. Но то, что этого добится дешевле — это как раз очень большой вопрос.
Это если вообще добиться бОльшего возможно не в теории, а на практике. Мы же всё таки лишь людишки, а супермозг ещё не изобрели.

http://blog.evernote.com/ru/2010/10/27/evernote-4-for-windows-is-here/

вброс старый, но качественный

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

S>PS: Чтобы быть в курсе уже купил книжку по С++ 11.
А какую?

Здравствуйте, Евгений Коробко, Вы писали:

ЕК>http://blog.evernote.com/ru/2010/10/27/evernote-4-for-windows-is-here/
ЕК>вброс старый, но качественный
Ой, ну это всё меняет. Спасибо, что открыл мне глаза.

Здравствуйте, Евгений Коробко, Вы писали:

А можно как для меня объяснить в чём состоит вброс?

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

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

S>>PS: Чтобы быть в курсе уже купил книжку по С++ 11.
ML>А какую?

Torsten T. Will "C++11 programmieren. 60 Techniken für guten C++11-Code" Galileo Press, Bonn 2012 30€

Не для начинающих. Вроде вменяемая. (да в любом случае, потом мне вернут за нее деньги
как за литературу по специальности )
Я люблю книжки немецкоязычных авторов, НЕ ПЕРЕВОДНЫЕ!, они освещают проблему со всех сторон,
белых пятен просто не остается, такое в английских далеко не всегда бывает.

Думаю что на английском и русском тоже можно найти подобное

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


M>Если серьезно, то тенденция ровно обратная: везде где только можно отказываются от C++ в пользу Pure C, или managed языков.

Не везде. Просто инструменты почетче расползлись по нишам. Стало лучше видно, где нужен нейтив, а где нет.

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

S>Думаю что на английском и русском тоже можно найти подобное

На русском не искал, на английском купил эту, но она по стандартной библиотеке, а не по самому языку. А вот книги, где описываются новые фичи именно языка найти не могу пока.

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

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

Кстати, симбиоз этих всех вещей — вероятно, и даёт лучший результат.

Лично мне думается, это просто отскок, что вполне закономерно. Когда-то, когда управляемые языки начали активно входить в жизнь, они казались чуть-ли не серебряной пулей: почти такая же производительность и значит новые приложения будут не медленнее старых, нет сложноужасного ручного управления памятью и значит никогда не будет падать. А ведь это так здорово, ведь теперь "индусы" справятся! Но, прошло время, оглянулись по сторонам. Тормозит? Тормозит, совсем не похоже на "почти такую же производительность". Падает? Падает, но по другому. Раньше был расстрел памяти с последующим падением, а теперь выжирание всей памяти с последующим падением.
Поэтому везде, где перешли на управляемые языки в порыве восторга от их эпической мощи, начали чесать репу и думать что же дальше делать
Ну а там где они реально нужны, там подобной тенденции само собой нет.

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

F>Кстати, симбиоз этих всех вещей — вероятно, и даёт лучший результат.

Вот только C++ в этом симбиозе часто уступает место pure C, потому что так проще и быстрее.

[quote]
Evernote 4 кардинально отличается от Evernote 3.5 по всем параметрам. Хотя версия 3.5 и добавила множество отличных новых возможностей, в ней мы столкнулись с рядом проблем, которые невозможно было легко исправить: размытый шрифт, долгое время загрузки, большое потребление памяти и плохая поддержка видеокарт. Все это было обусловлено спецификой технологий, лежащих в основе 3.5 (Windows .NET и WPF), на которые мы никак не могли повлиять. В конечном итоге мы скатились к борьбе с ошибками платформы вместо работы над новыми возможностями, о которых нас просили пользователи.

В итоге мы решили начать с нуля, используя только быстрый и надежный C++, в котором мы были уверены. Как вы сами увидите, результат получился просто удивительный. Эта новая версия положит основу для более быстрого развития Windows-клиента.
[/quote]

Классическая .NET fail story ) Причём само приложение не требует ни аццкой математики, ни низкоуровневого доступа к железу, ни 3D. По внешним признакам — это как раз такой тип приложений, которые надо писать на .NET.

Здравствуйте, Евгений Коробко, Вы писали:

ЕК>[quote]
ней мы столкнулись с рядом проблем, которые невозможно было легко исправить: размытый шрифт, долгое время загрузки, большое потребление памяти и плохая поддержка видеокарт. Все это было обусловлено спецификой технологий, лежащих в основе 3.5 (Windows .NET и WPF) , на которые мы никак не могли повлиять. [/quote]

ЕК>Классическая .NET fail story ) Причём само приложение не требует ни аццкой математики, ни низкоуровневого доступа к железу, ни 3D.

Мне даже сложно представить, что же она там требует, раз "плохая поддержка видеокарт WPF-ом" бедным разработчикам жизни не давала.

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

F>>Кстати, симбиоз этих всех вещей — вероятно, и даёт лучший результат.
M>Вот только C++ в этом симбиозе часто уступает место pure C, потому что так проще и быстрее.
Я встречался только с обратной ситуацией — C++ проще, быстре и понятнее, нежели любой пурэ припурэ C.

Здравствуйте, Евгений Коробко, Вы писали:

ЕК>[quote]
ЕК>Evernote 4 кардинально отличается от Evernote 3.5 по всем параметрам. Хотя версия 3.5 и добавила множество отличных новых возможностей, в ней мы столкнулись с рядом проблем, которые невозможно было легко исправить...
ЕК>[/quote]

А гуй они на C++ чем рисовали, MFC или Qt или что-то ещё?

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

Y>Мне даже сложно представить, что же она там требует, раз "плохая поддержка видеокарт WPF-ом" бедным разработчикам жизни не давала.

На 3.5 на Win XP на самом деле мазня со шрифтами (по сравнению с нитивными приложениями),
"плохая поддержка видеокарт", скорее всего означает тормознутость отрисовки окон на олдовых видюхах, что тоже имело место быть.
На 4 и 7 всё намного лучше и не удивлюсь, что для 8-ки таки пепепишут всё на наследника WPF.

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

S>Здравствуйте, Евгений Коробко, Вы писали:

ЕК>>[quote]
ЕК>>Evernote 4 кардинально отличается от Evernote 3.5 по всем параметрам. Хотя версия 3.5 и добавила множество отличных новых возможностей, в ней мы столкнулись с рядом проблем, которые невозможно было легко исправить...
ЕК>>[/quote]

S>А гуй они на C++ чем рисовали, MFC или Qt или что-то ещё?

Если пишут WPF, но на чём ещё

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

Y>Здравствуйте, Евгений Коробко, Вы писали:

ЕК>>[quote]
Y>ней мы столкнулись с рядом проблем, которые невозможно было легко исправить: размытый шрифт, долгое время загрузки, большое потребление памяти и плохая поддержка видеокарт. Все это было обусловлено спецификой технологий, лежащих в основе 3.5 (Windows .NET и WPF) , на которые мы никак не могли повлиять. [/quote]

ЕК>>Классическая .NET fail story ) Причём само приложение не требует ни аццкой математики, ни низкоуровневого доступа к железу, ни 3D.

Y>Мне даже сложно представить, что же она там требует, раз "плохая поддержка видеокарт WPF-ом" бедным разработчикам жизни не давала.

Управляемые языки, как и неуправляемые, требуют, чтобы их изучали.В частности, чтобы нормально писать на WPF, надо долго тренироваться . В целом, как я понимаю, ситуация была примерно следующей — писали себе мирно Evernote на с++, потом пришло какое-нибудь юное дарование, и сказало — "а давайте перепишем на .net". Опытных специалистов не было, поэтому получили то,что получили.Впрочем, чтобы понять, в чем проблема, надо код глядеть.

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

S>>А гуй они на C++ чем рисовали, MFC или Qt или что-то ещё?
M>Если пишут WPF, но на чём ещё

Ответ непонятен чуть более чем полностью. Судя по ответу евернотовцы ушли от C#/WPF и пришли к C++/WPF, что ни как не стыкуется.
Во первых давно ли можно рисовать гуй на C++ (не C++/CLI) через WPF?
Во вторых, в блоге евернота написано, что все их проблемы были из-за дотнета и WPF в частности, размытые шрифти как раз из-за способа сглаживания через opengl который используется в WPF. На маке можно наблюдать ровно тоже самое со шрифтами, так же из-за отрисовки шрифтов через opengl.

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

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

S>>>А гуй они на C++ чем рисовали, MFC или Qt или что-то ещё?
M>>Если пишут WPF, но на чём ещё

S>Ответ непонятен чуть более чем полностью. Судя по ответу евернотовцы ушли от C#/WPF и пришли к C++/WPF, что ни как не стыкуется.
S>Во первых давно ли можно рисовать гуй на C++ (не C++/CLI) через WPF?
S>Во вторых, в блоге евернота написано, что все их проблемы были из-за дотнета и WPF в частности, размытые шрифти как раз из-за способа сглаживания через opengl который используется в WPF. На маке можно наблюдать ровно тоже самое со шрифтами, так же из-за отрисовки шрифтов через opengl.

Т.е. вопрос про то, к чему пришли после того, как одумались?

Здравствуйте, mtnl, Вы писали:
...
M>Т.е. вопрос про то, к чему пришли после того, как одумались?
Уже обсуждали

Автор: alexey_ma
Дата: 02.12.10

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

KP>Лично мне думается, это просто отскок, что вполне закономерно. Когда-то, когда управляемые языки начали активно входить в жизнь, они казались чуть-ли не серебряной пулей: почти такая же производительность и значит новые приложения будут не медленнее старых, нет сложноужасного ручного управления памятью и значит никогда не будет падать. А ведь это так здорово, ведь теперь "индусы" справятся! Но, прошло время, оглянулись по сторонам. Тормозит? Тормозит, совсем не похоже на "почти такую же производительность". Падает? Падает, но по другому. Раньше был расстрел памяти с последующим падением, а теперь выжирание всей памяти с последующим падением.
KP>Поэтому везде, где перешли на управляемые языки в порыве восторга от их эпической мощи, начали чесать репу и думать что же дальше делать
KP>Ну а там где они реально нужны, там подобной тенденции само собой нет.

О, наконец то реалистичное мнение в холиварной темке. ) Полностью согласен.

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

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

M>На 3.5 на Win XP на самом деле мазня со шрифтами (по сравнению с нитивными приложениями),
M>"плохая поддержка видеокарт", скорее всего означает тормознутость отрисовки окон на олдовых видюхах, что тоже имело место быть.

"Типичный пользователь"(с) evernote на древней машинке с ХР... Вы серьёзно?

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

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

M>>На 3.5 на Win XP на самом деле мазня со шрифтами (по сравнению с нитивными приложениями),
M>>"плохая поддержка видеокарт", скорее всего означает тормознутость отрисовки окон на олдовых видюхах, что тоже имело место быть.

Y>"Типичный пользователь"(с) evernote на древней машинке с ХР... Вы серьёзно?

Посмотрите год, в котором эта новость родилась.

Здравствуйте, Евгений Коробко, Вы писали:

M>>Если серьезно, то тенденция ровно обратная: везде где только можно отказываются от C++ в пользу Pure C, или managed языков.

ЕК>Аха. Только "можно" оказывается практически нигде.

Против C++ уже были споры, новых аргументов с тех пор практически не появилось. Вот только пара примеров:

1) Тред на rsdn Metaprogramming et al

Автор: CrazyPit
Дата: 12.07.05

2) Linus Torvalds: С++ — ужасен, его выбор для проекта — плохое решение

Можно еще нашего мыщъх-а вспомнить

Автор: мыщъх
Дата: 27.06.12

— он там правда за питон против Си, а не C++ говорил.

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

Согласен с тем, что .NET — платформа уже без будущего. Микрософт уже не торт. Все было хорошо до поры до времени, Микрософт доминировал и творил, что хотел (навязывал .NET, WPF, Silverlight и прочее гуано), и пипл хавал, ибо что еще оставалось? Но потом они внезапно проспали планшеты и мобильники, и это стало началом их конца. Внезапно оказалось, что .NET не подходит для мобильных девайсов, т.к. жрет слишком много памяти и процессора, а значит и заряда батарей. Если еще принять во внимание идею-фикс Микрософт (фатальную для них) запускать одну и ту же Винду на десктопах и таблетах, перспектива .NET в следующих версиях Винды очень сомнительная.

Помню, пару лет назад, когда я еще был Виндофагом, я тоже считал .NET замечательной платформой, однако помню и то, как мне потребовалось заметное усилие, чтобы смириться и закрыть глаза на прожорливость и тормоза этого фреймворка, в пользу его современности и мейнстримовости. Помню даже как я спорил с приятелем, убеждая его, что скорость работы и прожорливость не главное в современной индустрии ПО, что это все покрывается быстрым развитием железа и экономии на разработке. Действительно, C# вроде неплохой язык и библиотеки хороши, но только с точки зрения разработчика. Для Микрософт характерно не очень-то беспокоиться о пользователе. А пользователь получает тормоза и завышенные требования к системе, непонятно ради чего.

Предвижу, что вскоре этот массовый самогипноз рассеется и все разработчики снова прозреют, что .NET — неоправданно тормозная и прожорливая система, что JIT не нужен, и т.п. Вспомните Флеш. Это был де-факто стандарт, от которого никуда было не деться, хоть он и был отстоем. Но столкнувшись с мобильными девайсами, он стал быстро хиреть и угас всего за пару лет, и уже сами его создатели отреклись от него.

Анонимус наверное спросит, а на чем тогда писать, на С++ и QT или на WinAPI? Отнюдь. С++ ужасен (хоть и в другом отношении нежели .NET), не говоря уже про WinAPI и прочие копролиты мамонта. Из таких зол не хотелось бы выбирать вообще. Я бы голосовал за новую связку язык + фреймворки. Удачным примером реализации считаю Obj-C и фреймворки Mac OS X / iOS. Надеюсь, Микрософт из последних сил успеет создать нечто такое, чтобы спасти Винду. Раньше им было пофигу, а теперь придется почесаться. А пока разработчики под Винду зависают в неопределенности и начинают потихоньку мигрировать на более перспективные (во всех смыслах) платформы.

Кстати, вот интересная идея, наверное уже где-то обсуждалась. Нельзя ли убрать из .NET JIT и оставить просто язык C# и реализовать библиотеки .NET в каком-нибудь нативном виде? Это по крайней мере не с нуля было бы все переписывать для них.

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

_>Замечу только, что процесс ещё заметно подтолкнуло появление мобильных устройств, для которых понятия энергоэффективности и отжираемости памяти весьма актуальны.

Именно, вопрос энергетической стоимости вычислений 10 лет назад даже не стоял. А теперь речь о том, чтобы мобильные и десктопные ОС/приложения имели один и тот же или близкий друг другу код.

M>То есть получается, что для задач, требующих предельной оптимизации C++ ничем не лучше чистого Си, а для задач, требующих развитой логики C++ в целом не быстрее того же питона или Java, но сложнее в разработке.

Предельной оптимизации требует 1% кода.

Здравствуйте, Яблофаг, Вы писали:

Я>Предвижу, что вскоре этот массовый самогипноз рассеется и все разработчики снова прозреют, что .NET — неоправданно тормозная и прожорливая система, что JIT не нужен, и т.п. Вспомните Флеш.

И Java. И животноводство.

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

C>Управляемые языки, как и неуправляемые, требуют, чтобы их изучали.В частности, чтобы нормально писать на WPF, надо долго тренироваться .

Зачем?
И разве это нормально?

C>В целом, как я понимаю, ситуация была примерно следующей — писали себе мирно Evernote на с++, потом пришло какое-нибудь юное дарование, и сказало — "а давайте перепишем на .net". Опытных специалистов не было, поэтому получили то,что получили.Впрочем, чтобы понять, в чем проблема, надо код глядеть.

GUI несложный. Но приложение тянет за собой суммарно порядка 30мег зависимых дотнетных DLL для WPF. Долго грузится в итоге. Много требует памяти и т.д.

Здравствуйте, Яблофаг, Вы писали:

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

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

Сила флеша — быстрое создание готового продукта малыми силами (для типовой инди-игры — один разработчик один месяц вечером после работы), делать дольше — для большинства проектов тупо нерентабельною

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

Я>Кстати, вот интересная идея, наверное уже где-то обсуждалась. Нельзя ли убрать из .NET JIT и оставить просто язык C# и реализовать библиотеки .NET в каком-нибудь нативном виде? Это по крайней мере не с нуля было бы все переписывать для них.

Mono делают LLVM backend.

Здравствуйте, Яблофаг, Вы писали:

Я>Удачным примером реализации считаю Obj-C и фреймворки Mac OS X / iOS.
Ну вот, начал за здравие, а кончил "как всегда" (тм).
У тебя всего то сменился фетиш: раньше тебя пёрло от .NET теперь тебя прёт от ObjC.

Здравствуйте, Яблофаг, Вы писали:

Я>Удачным примером реализации считаю Obj-C и фреймворки Mac OS X / iOS.


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

Если мы стремимся к быстрой разработек, то надо смотреть на языке типа Python и Ко. Там это пожалуй максимально (если не считать спец. RAD систем), но при этом они ещё заметно хуже .Net по потреблению ресурсов. Да и ещё куча минусов есть из-за виртуальной машины. Но если ситуация всё же позволяют, то оно того стоит — намного эффективнее и C++ и .Net языков по скорости разработки.

Если же говорить о нативных языка, то на мой взгляд сейчас лучшим является D, но у него неразвитая инфраструктура, поэтому приходиться обходиться C++.

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

_>Ну вот, такой логичный весь текст и вдруг такая дикая фраза. Obj-C же убог по всем параметрам.

Опять же, ты судишь с точки зрения разработчика, а не пользователя программ, которые ты разрабатываешь. Да, язык Obj-C может не так изящен, как хотелось бы, но сказать на нем можно все то же самое, что и на других языках. Как язык, он прост и однозначен (в отличие от С++), это плюс. По мере роста популярности язык быстро развивается, причем в правильном направлении. К слову, принцип auto release, а в последних версиях Obj-C auto reference counting имхо отличная идея, намного облегчающая управление памятью, но при этом избавленная от тормозов GC.

Но главное — к нему идут классные стандартные фреймворки, обеспечиваемые самой операционкой (тоже в отличие от С++). Код, написанный на Obj-C быстрый и не требовательный к системе, до такой степени, что он отлично работает даже на мобилках. UI собирается легко, причем отлично выглядит, снабжен крутыми анимационными эффектами, и не тормозит. Пользователь очень доволен. Его не волнует синтаксический сахар языка или принцип управления памятью или мифическая кроссплатформенность.

_>Если мы стремимся к быстрой разработек, то надо смотреть на языке типа Python и Ко. Там это пожалуй максимально (если не считать спец. RAD систем), но при этом они ещё заметно хуже .Net по потреблению ресурсов. Да и ещё куча минусов есть из-за виртуальной машины. Но если ситуация всё же позволяют, то оно того стоит — намного эффективнее и C++ и .Net языков по скорости разработки.

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

_>Если же говорить о нативных языка, то на мой взгляд сейчас лучшим является D, но у него неразвитая инфраструктура, поэтому приходиться обходиться C++.

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

Здравствуйте, Яблофаг, Вы писали:

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

А как ещё судить, если мы говорим о ЯЗЫКЕ? )

Я>Но главное — к нему идут классные стандартные фреймворки, обеспечиваемые самой операционкой (тоже в отличие от С++). Код, написанный на Obj-C быстрый и не требовательный к системе, до такой степени, что он отлично работает даже на мобилках. UI собирается легко, причем отлично выглядит, снабжен крутыми анимационными эффектами, и не тормозит. Пользователь очень доволен. Его не волнует синтаксический сахар языка или принцип управления памятью или мифическая кроссплатформенность.

1. К самому языку это технические отношения не имеет
2. Наличие у языка только одного фреймоврка — это большой минус. Привязка к одной платформе...

Вот у нас есть приложение на C++. Один код собирается и под винду и под мак и под линух. Про быстродействие думаю можно и не уточнять (уж точно не хуже и Obj-C и остальных) и при этом имеет на маке тот же сам нативный интерфейс со всеми анимациями и т.п. пользовательскими игрушками.

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

Нууу то что нейтив лучше я в принципе согласен... Но к сожалению пока нет нативного языка со скоростью разработки уровня Питона и т.п. )

Я>В этом-то все и дело — язык должен идти с инфраструктурой, привязанной к целевой платформе. Иначе это не серьезный язык, а игрушка. Obj-C удовлетворяет этому требованию, а С++ в Windows — нет.

Хы, у самого C++ действительно нет привязки к целевой платформе, т.к. он может хоть на микроконтролёрах работать. ))) Но при этом у него есть мощнейшие фреймворки под каждую существующую платформу — это я и называю развитой инфраструктурой. И как раз этого у языка D нет. А вот если бы было, то мы уже давно перешли бы на него...

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

_>1. К самому языку это технические отношения не имеет

Но с другой стороны имеет, в контексте обсуждаемой темы — причины заката .NET. Ведь не в языке же C# эти причины.

_>2. Наличие у языка только одного фреймоврка — это большой минус. Привязка к одной платформе...

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

_>Вот у нас есть приложение на C++. Один код собирается и под винду и под мак и под линух. Про быстродействие думаю можно и не уточнять (уж точно не хуже и Obj-C и остальных) и при этом имеет на маке тот же сам нативный интерфейс со всеми анимациями и т.п. пользовательскими игрушками.

Это очень плохая идея. На Маке совсем другие принципы построения UI и другие HIGs. И так на всех платформах. Даже если на Маке построить UI из нативных контролов Mac OS X, но использовать принципы Windows (например жирные тулбары, перегруженные функциями), программа не будет выглядеть нативно. Так или иначе ненативность вылезет. Пользователи это сразу почувствуют и справедливо назовут такую программу унылым говном, а автора — мудаком, который решил сэкономить на качественной нативной разработке, за счет пользователей. Если ты пользовался хоть одной т.н. "кроссплатформенной" программой, то знаешь, о чем я.

_>Хы, у самого C++ действительно нет привязки к целевой платформе, т.к. он может хоть на микроконтролёрах работать. ))) Но при этом у него есть мощнейшие фреймворки под каждую существующую платформу — это я и называю развитой инфраструктурой. И как раз этого у языка D нет. А вот если бы было, то мы уже давно перешли бы на него...

Сейчас для С++ под современной Windows нет нормальных фреймворков (если не считать managed C++ c .NET, что есть настоящий Адъ.) Это видно даже по этому форуму, одна из самых часто обсуждаемых тем — на чем писать под Винду.

Здравствуйте, Яблофаг, Вы писали:

Я>Ничто не мешает создавать разные фреймворки на разных платформах для одного и того же языка, даже такого стрёмного как С++. Однако возможность переноса кода без изменений с одной платформы на другую — иллюзия.

С правильными инструментами это совсем не иллюзия.

Я>Это очень плохая идея. На Маке совсем другие принципы построения UI и другие HIGs. И так на всех платформах. Даже если на Маке построить UI из нативных контролов Mac OS X, но использовать принципы Windows (например жирные тулбары, перегруженные функциями), программа не будет выглядеть нативно.

Правильные инструменты всё это учитывают и прячут внутри себя за абстракциями. Ну а кривой изначально интерфейс останется таким под любой платформой. )))

Я>Если ты пользовался хоть одной т.н. "кроссплатформенной" программой, то знаешь, о чем я.

Да, переодически натыкаюсь на такое. Обычно написаное на Java или чём-то подобном. Но бывают и кроссплатформенные продукты на 100% выглядящие нативныеми.

Я>Сейчас для С++ под современной Windows нет нормальных фреймворков (если не считать managed C++ c .NET, что есть настоящий Адъ.) Это видно даже по этому форуму, одна из самых часто обсуждаемых тем — на чем писать под Винду.

А Qt, wxWidgets и ещё куча разных — это что тогда? )))