Самый перспективный язык программирования???

[knight]

Как мне кажется сейчас на рынке складывается следующая ситуация:
происходит деление программистов на тех кто будет использовать
C# и другие языки framework , и тех кто - будет писать на C++,Win32Api,MFC etc.
Первые будут решать круг задач связанных с конкретными пользователями
то есть фактически обычные приложения рабочего стола. Вторая группа программистов будет заниматься системными задачами такими как драйвера,сервисы,утилиты и т.д..
Для программирования под Web будут использовать 2 технологии
PHP и ASP.NET.
Ну и безусловно с помощью ассамблера будут заниматься хакингом.

[knight]

Я написал свой взгляд об общем направлении. Если говорить о мобильных
ведь под них можно писать в зависимости от платформы либо на C++,Си,С#,J2ME (как мне кажется C# и Java достаточно близки по идеологии и нормальный программист может вполне адекватно перейти с одного на другое).Кроме того безусловно всегда существуют задачи, требуюшие нестандартных решений. Если чем - то обидел извините я высказал лишь мой взгляд на поднятую проблему

[BC Scout]

Сообщение от knight

...
происходит деление программистов на тех кто будет использовать
C# и другие языки framework , и тех кто - будет писать на C++,Win32Api,MFC etc.
Первые будут решать круг задач связанных с конкретными пользователями
то есть фактически обычные приложения рабочего стола.

How come? Или распределенные системы построенные на использьвании web services (и это только маааленький примерчик ) теперь называются "обычными приложениями рабочего стола"?

[knight]

Не совсем понял ответа. Если же мы говорим о возможностях framework'a то конечно они достаточно большие например Microsoft .Net Remoting или те же web - services.Как мне кажется технология framework ' a постепенно захватит многие части рынка, но давайте не будем забывать что внутри framework'a лежит обычный win32api и технологии com/com+/dcom и зачастую многих вещей на framework'e не сделаешь приходится импортировать обычный api и кроме того далеко не каждая задача может позволить себе проинсталлировать ~30 мб дополнительно. И ещё ведь пока программы написанные, например на C# достаточно тяжеловесны и проигрывают в скорости обычным программам написанным в неуправляемом коде.

[BC Scout]

Сообщение от knight

Не совсем понял ответа. Если же мы говорим о возможностях framework'a то конечно они достаточно большие например Microsoft .Net Remoting или те же web - services.Как мне кажется технология framework ' a постепенно захватит многие части рынка, но давайте не будем забывать что внутри framework'a лежит обычный win32api и технологии com/com+/dcom и зачастую многих вещей на framework'e не сделаешь приходится импортировать обычный api и кроме того далеко не каждая задача может позволить себе проинсталлировать ~30 мб дополнительно. И ещё ведь пока программы написанные, например на C# достаточно тяжеловесны и проигрывают в скорости обычным программам написанным в неуправляемом коде.

Я тоже не совсем понял почему программисты "кто будет использовать
C# и другие языки framework " "будут решать круг задач связанных с конкретными пользователями то есть фактически обычные приложения рабочего стола"? Неужели это следует из того, что возможности framework (надо полагать .NET framework) "достаточно большие"? Мне показалось что импликация просто не верна , отсюда и вопрос "how come" . Дальнейшие рассуждения о том что, мол, далеко не все можно сделать с управляемым кодом, моего вопроса не сняли.

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

[knight]

Давайте не переходите на выпады типа:

на что возможности framework (надо полагать .NET framework)

Я не пытаюсь доказать что - либо. Я высказал лишь своё мнение. Кроме того удалённое взаимодействие зачастую реализуется и используется на основании DCOM, а технология .NET ещё достаточно сырая и больше похожа на конструктор на основании которого сложно строить серьёзные системы.
Из вашего ответа

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

Не совсем понял, а что на С++ этого невозможно реализовать ?

[ЕЖ]

Вот это да! Borland решила продать все свои IDE разработки (Delphi, C++Builder, C#Builder, Kylix, JBuilder и Interbase) и сконцентрироваться только на ALM-линейке своих продуктов.

Что-то Borland стала частенько вносить смуту в стройные ряды поклонников своих сред разработки, интересно что из этого выйдет....

Прессрелиз: http://www.borland.com/us/company/ne..._software.html

[basturd]

Ну так из всех этих продуктов реально живы только Delphi и JBuilder. А следующая версия JBuilder должна была/будет основана на Eclipse, что говорит о том, какая была плачевная ситуация с JBuilder 2005/2006.

[vladislav75]

2Матроскин
Перспективность Java очень сильно увеличивается из-за сильной поддержки ее Oracl'ом.
Так что Ява может и не нравиться, а приходится учить и работать.
ИМХО, о перспективах языков невозможно говорить отдельно от перспектив крупных платформ. Все пилит от заказчика и того, на чем он собирается работать

[yan_kos]

Где какой язык приминят зависит от задачи например для прикладних и системных нужд рулят С\С++,асм Для веб PHP для кармаников, камерофонов и т.п. Java.

[yan_kos]

А насчот С# и framework то ето не ровня С\С++ потому что:
С# - полностю ООП и к томуже высокого уровня такчто на нем писать только апликейшины тогда как С\С++ можна писать всьо от дров до класного фейса проги. Плюс к тому С# - ето байт-код А С\С++ полноцений бинарник. На С# моджно быстро склипать небольшую прогу, но полно функцыональною, с полним контролем и безопасностю на С# быстро уж никак не напишеш и скорость такой проги ... (без коментов) так что для компов на сегоднешний день лутше чем С\С++ нету. Правда для писания на нем нужнен опыт и голова на плечах, особбено в еирархиях, темплейтах. В будущем я считаю что С# будет языком для начинающих.

то denver: я рус. некогда неучил. В то время когда все нормальные люди учили родной язык я читал Страуструпа... под партой...

[joker99]

yan_kos
Интересно каким образом то что C# полностью ООП делает его плохим языком?
Ктому же C# ето не байт код. Он компилируется в бинарник как и С\С++.

Я уже 3 года пишу на C# програмы которые "полно функцыональные, с полним контролем и безопасностю".

Я из C# могу использовать любой API который можно использовать из С\С++.

Если я захочу, я могу писать используя поинтеры.

при всём етом я получаю громадный прирост в продуктивности за счёт использования framework и платформы .NET

Единственный минус ето небольшая потеря в скорости, которая в 99.9% не будет замечена никем. Да и ето измениться когда выйдет Vista, в которую .NET встроен на самомом низком уровне.

Так что я считаю что действительно С# и framework ето не ровня С\С++

[Silent_Sky]

Borland вроде же прекратил все работы над Delphi и выставил ее на лот?

сам ваяю на C# и асп.нет, вроде ничего так у мелкомягких вышло...

[yan_kos]

=joker99

Интересно каким образом то что C# полностью ООП делает его плохим языком?

- То что приходитса много памяти тратить на один объект. Как последствие снижение общей производительности.

Я уже 3 года пишу на C# програмы которые "полно функцыональные, с полним контролем и безопасностю".

- ага а сколько ресурсов она жрет ?

Я из C# могу использовать любой API который можно использовать из С\С++.

- с етим я неспорю.

Если я захочу, я могу писать используя поинтеры.

ничего подобного! там все типа как поинтеры.

при всём етом я получаю громадный прирост в продуктивности за счёт использования framework и платформы .NET

- я бы сказал...

Так что я считаю что действительно С# и framework ето не ровня С\С++

- Конечно С\С++ намного лутше!

[yan_kos]

joker99

Ктому же C# ето не байт код. Он компилируется в бинарник как и С\С++.

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

[alexey_ma]

joker99:
Я из C# могу использовать любой API который можно использовать из С\С++.

В этом случае значительное снижение производительности.

[windheaven]

С/С++, PHP.

[joker99]

yan_kos:
ты на половину прав. изначально прога компилитса в байт-код только потом сам фрейворк компилит ее полностю в кеш лткуда ее потом и запускает! что сразу понижает ее скорость роботы дополнительной прослойкой!

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

yan_kos:
- ага а сколько ресурсов она жрет ?

Нормально жрёт. Никто не жалуется

yan_kos:
ничего подобного! там все типа как поинтеры.

Действительно c# ето референс-язык, но при етом в нём есть возможность напрямую работать с памаятью без GC. посмотри в интернете информацию про директиву C# unsafe.

yan_kos:
- я бы сказал...

Я слушаю...

Сообщение от alexey_ma

В этом случае значительное снижение производительности.

По тому что .....???

[Assasino]

Мне C++ нравицца довольно несложен в восприятии

[alexey_ma]

joker99:

По тому что .....???

Маршаллинг.
http://rsdn.ru/article/dotnet/coopdll.xml
и http://rsdn.ru/article/dotnet/complusnet.xml
Про тоже самое есть и в MSDN.
При успользовании неуправляемого кода из фреймворка вы получите в результате недостатки обоих.

joker99:
Нормально жрёт. Никто не жалуется

Жалуются, и еще как. Есть клиенты работающие на Citrix. Там каждый лишний мегабайт пямяти или процент CPU это катастрофа
Скажу по секрету что у нас есть один клиент который категорически отказывайтся покупать версию нашей программы в которой часть компонент написана на C# - он требует только нативный код, никаких фреймворков.

Во, нашел. Из MSDN :

COM Interop and Platform Invoke
COM Interop and Platform Invoke expose native APIs to 
managed code in an almost transparent way; calling most 
native APIs typically requires no special code, though it 
may require a few mouse clicks. As you might expect, 
there is a cost associated with calling native code from 
managed code and vice versa. There are two components 
to this cost: a fixed cost associated with doing the 
transitions between native and managed code, and a 
variable cost associated with any marshalling of arguments
 and return values that might be required. The fixed
 contribution to the cost for both COM Interop and 
P/Invoke is small: typically less than 50 instructions. The 
cost of marshalling to and from managed types will depend
 on how different the representations are on either side of
 the boundary. Types that require a significant amount of 
transformation will be more expensive. For example, all 
strings in the CLR are Unicode strings. If you are calling a 
Win32 API via P/Invoke that expects an ANSI character 
array, every character in the string has to be narrowed. 
However if a managed integer array is being passed where 
a native integer array is expected, no marshalling is 
required.

Because there is a performance cost associated with calling
 native code, you should make sure that the cost is
 justified. If you are going to make a native call, make sure

 that the work that the native call does justifies the 
performance cost associated with making the call—keep 
methods "chunky" rather than "chatty." A good way to 
measure the cost of a native call is to measure the 
performance of a native method that takes no arguments
 and has no return value, and then measure the 
performance of the native method you wish to call. The 
difference will give you an indication of the marshalling 
cost.


HINT   Make "Chunky" COM Interop and P/Invoke calls as
 opposed to "Chatty" calls, and make sure that the cost of 
making the call is justified by the amount of work that the
 call does.
Note that there are no threading models associated with 
managed threads. When you are going to make a COM 
Interop call, you need to make sure that the thread that 
the call is going to be made on is initialized to the correct 
COM threading model. This is typically done using the 
MTAThreadAttribute and STAThreadAttribute (though it can
 also be done programmatically).