С/C++ (стр. 4 из 4)

В одном из интервью Страуструп приводит следующие потенциальные направления развития C++:

"Параллелизм: я сторонник библиотечной реализации потоков и параллельного выполнения операций без разделения памяти.

Отображение типов: неплохо было бы обеспечить библиотечную организацию интерфейса с информацией расширенных типов.

Типизация: хотелось бы, чтобы в библиотеку Standard Library были включены функции поддержки расширенных типов, однако конкретных предложений у меня нет.

Хеш - таблицы: конечно, необходимо интегрировать некоторые варианты популярной схемы hash_map.

Ограничения для аргументов - шаблонов: все это просто, универсально и элегантно реализуется в рамках существующего стандарта Си++.

Операторы контроля: многие из наиболее важных операторов контроля - верификация кода и обработка ошибок - можно было бы реализовать в виде шаблонов. Некоторые из них следует включить в библиотеку Standard Library.

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

Сборка мусора: в стандарте Си++ нужно явно определить технологию, позволяющую игнорировать "скрытые указатели", а также конкретизировать порядок обработки деструкторов.

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

Независимость от платформы: хотелось бы, чтобы Standard Library поддерживала более широкий набор интерфейсов с общими системными ресурсами, например, с каталогами и сокетами."

Еще одна проблема заслуживающая упоминания - это путь распространения C++. Очевидно, что тут повлияли распространенность Си, широта средств языка и областей его применения. Достаточно большой вопрос - насколько на распространение C++ повлияла рекламная поддержка ?

Вот что говорит сам Страуструп по этому поводу:

"Си++ приобрел массу приверженцев там, где это было нужнее всего: миллионы программистов используют его в качестве своего основного инструмента.

Удивительно, но этого удалось добиться, не имея <административного ресурса> и по существу без финансовых затрат. Однако, с другой стороны, сообщество сторонников Си++ оказалось разобщенным и крайне уязвимым для выпадов враждебной пропаганды. Мне кажется, все дело здесь в том, что хороший код часто остается незамеченным - даже его пользователями. Посмотрите на программы, написанные на Си++, например, на приложения Netscape или на Internet Explorer. Компании, разрабатывающие программы для решения реальных задач - в частности, для управления телекоммуникациями, контроля за различными механизмами и имитационного моделирования, - предпочитают не говорить, на каком языке написаны их приложения.

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

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

Язык Си++ никогда не поддерживался каким - то одним лидером отрасли. Каждый крупный производитель дополняет (и так было всегда) стандарт Си++ своими собственными элементами. Си++ никогда не являлся предметом маркетинговой стратегии. Если какие - то маркетинговые мероприятия и проводились, то только организациями, продающими что - то другое (например, среду для разработки программного обеспечения), включающее в себя Си++ в качестве составляющего компонента. Сообщество Си++ скорее страдало от чрезмерной популярности этого языка: он постоянно становился <объектом нападок>, ведь в современном мире, живущем по законам коммерции, честная борьба - большая редкость.

У сообщества Си++ никогда не было координирующего центра, финансовые возможности которого позволяли бы ему заниматься популяризацией языка. Кто и из каких соображений готов голосовать за Си++? И как довести эту информацию до программистов, преподавателей, менеджеров? Буквально на днях я слушал выступление профессора перед студентами, в котором он категорически отрицал существование стандарта Си++! Жаль, что даже спустя два года после ратификации этого стандарта сплошь и рядом возникают подобные недоразумения."

Приведу и другую точку зрения.

Многие приверженцы C++ считают его языком для профессионалов. Это так.

Но они переходят дальше и производят ошибочное следствие, что единственный язык для профессионалов - это C++.

Яблоко - это фрукт. Но это не значит, что любой фрукт есть яблоко.

Поклонники Си даже сочинили стишок

"У любого ты спроси

Будь хоть трижды ламер

программируешь на Си

Ты - крутой программер"

Я cчитаю что определять крутость программиста по языку - по крайней мере некорректно. Можно писать хорошие программы на Basic и ужасные на C++. Кроме того, аргумент против C++ в религиозных войнах о его рекламной распространенности тоже появился, вероятно не с неба.

В заключение отмечу что:

В тоже время нужно признать, что C++ является наиболее мощным, вероятно за исключением Ad'ы языком из широко используемых.

Он же является на момент написания обзора наиболее популярным языком. Хотя это не бесспорно. Почему см. страницу XXX. Хотя последние годы его потеснила Java.Сейчас теснит и C#.

Он же является наиболее критикуемым языком.

Он же содержит огромное наибольшее количество недостатков и подводных камней нередко делающих программы на нем менее надежными.

P.S.

Хотелось бы знать мнения читателей по поводу:

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

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

принципы, по которым в индустрии выбираются языки

сферы, где существует конкуренция языков - и области, где "все поделено"

тенденции и прогнозы (например - "через N лет мы все будем в сфере A - писать на B, в сфере C - на D, и т.п."

Очень приветствуются аргументированные ответы ссылки на научные исследования,книги и статьи.

Очень интересны результаты разработок(и практический опыт приобретенный при разработке оных) однотипного(а лучше одинакового ПО) на разных ЯП и его влиянии на их стоимость/время разработки/устойчивость и скорость работы приложений/...

При этом хорошо бы рассматривать ЯП не как вещь в себе, а в связи с другим ПО(от отладчика уровня ядра до Case средств).

Интересен сравнительный анализ ЯП и компиляторов и вообще всё что с этим связанно. В частности связь с психологией. Очень интересно отличие "у нас" и " за бугром".

Интересуют также координаты людей и организаций, в чьи профессиональные и научные интересы входят ЯП.