Здравствуйте, vsb, Вы писали:
vsb>Здравствуйте, Wawan, Вы писали:
W>>новая перекличка тех кто С++ не осилил 
vsb>Ну мне надо код писать и поддерживать, а не С++ осиливать. С кодом на С я знаю, что я его могу дать любому программисту, который С когда-то учил в университете и он этот код поймёт и сможет поддерживать и что-то по мелочи дописывать.
НЕЕЕЕТ! НЕТ. Ровно те же концепции, что есть в Java, C#, F#, C++, Common Lisp... их все реально реализовать на голом C.
Выглядеть будет страшновато. И программа уже будет не совсем на C. Воспринимать её как программу на C можно ровно так
же, как результат компиляции C++ в ассемблер можно воспринимать на ассемблере. Любой студент разберётся? Скорей наломает дров,
причём куда хуже, чем если бы ему дали сразу C++.
Легко доказывается, что идея "простого языка" она не состоятельна. Можно взять, например, воображаемую ленту Тьюринга.
Или Brainfuck. Или язык ассемблера контроллеров фирмы Microchip PIC, где как любит упомянутая фирма писать, всего 35
(плюс-минус) инструкций, которые легко выучить. И на всех этих языках можно писать _сложные_ программы, а для последнего
есть попросту C-компилятор (не простой, с "компилируемым стеком"). Очевидно что программирование всего перечисленного
прямо скажем -- сильно не тривиально. Хотя казалось бы "несколько простых инструкций". Только любые более-менее сложные
концепции в этих инструкциях начинают выражаться очень непростым способом.
На самом деле мы имеем такую ситуацию, что с одной стороны стоят языки с "очень простыми инструкциями", а с другой
языки с очень большим количеством очень сложных концепций. И то и другое -- две крайности. Человеку проще освоить
всё же несколько большее количество инструкций и готовых концепций (библиотечных функций, конструкций языка), чем
реализовывать эти концепции на "очень простом языке" самостоятельно. Но до определённого предела. Слишком сложные
концепции не лучше, чем "очень простые инструкции". Последнее, на мой взгляд, демонстрирует C#. Где слишком много
встроенных именно концепций языка.
Что же касается C++, то многие вещи в нём на самом деле -- библиотечные функции,
а база на которой они построены пожалуй куда проще. Там проблема в другом, что те кто не понимают C++, на самом деле
не понимают, что это по меньшей мере три разных языка: язык макропроцессора C, императивный "улучшенный язык C с объектами",
и наконец _декларативный_ язык шаблонов, который лишь позволяет задавать правила по которому генерируются конструкции
"языка C с объектами". И повторюсь, многие вещи -- библиотечные функции или классы, а не свойства языка. Проблема в том,
что учат всему в целом, в куче, не разделяя на слои и у обучаемых не складывается правильая картина, они попросту
не понимают, например, что cout << "text" -- это ни разу не свойство языка (как Write() в паскале), а лишь перегруженный
оператор и библиотечный класс.
Отдельная проблема, что некоторые люди практически не владеют абстрактным мышлением ("не отдам ему яблоко, хоть он дерись").
По-видимости это какой-то дефект развития заложенный в очень раннем возрасте (родители не обучали ребенка).
Понимают всё только на конкретных примерах. И им просто объективно сложно понять концепции метапрограммирования.
И таких людей -- много. Увы.
vsb> С кодом на С++ — однозначно нужен отдельный человек, который будет незаменимым. Если в компании всё на С++,
vsb> то нормально. Если всё на Java, к примеру, а какие-то небольшие части нужно на С/С++ написать по какой-то причине,
vsb> лично я альтернативы C вообще не вижу.
В переводе на русский -- C++ требует обученных сотрудников, а с языком C -- может кто-то работать "по-совместительству".
Да, но по мере усложнения C-подпроекта он рискует по-сложности обогнать C++. И там действительно будут незаменимые люди.
Потому, что одно дело программа написанная в рамках стандартных средств языка, а другое дело, когда эти стандартные
(и всем понятные) средства заменяются на самодельные аналоги (к чему приходит сложная C-программа). Потому, что ряд
условно сложных концепций он в любой программе существует, не зависимо от языка. Это определяется задачей, а не языком.
И хорошо, если эти сложноть концепций ограничивается в языке или в стандартной библиотеке, а не в коде который нужно
поддерживать. Почему C#/Java и энтерпрайзе и лидируют. Готовая библиотека и язык имеют ответы на многие вопросы.
