Никакой не латентный, я кое-что делал на дельфи, по необходимости, по этому знаю, что это не то что мне нужно  

Такое ощущение, что С/С++ действительно уходит на задний план. Для чего то маленького и быстрого, либо серьезного и большого. Гуй писать на С++ дело уже не гламурное. К примеру у нас вообще стали обходится веб-интерфейсами - вполне кошерно. 

  
Что касается Дельфи - вообще не понятно его существование, когда есть С#. Особенно улыбает тот факт, что есть плагин под студию где можно разрабатывать код на Delphi под .NET. 

  Так это дело рук кодегировцев. Delphi Prism поддерживает все возможности .NET 3.5. Так что возможности есть. Сейчас в проекте x64 и Linux. Так что все со временем будет. Delphi for Win32 уже на уровне .NET 2.0, но при этом дает нативный код. 
  
  Но, вообще, на сегодняшний день самым разумным является 2х ступенчатый подход, когда пишут для некой платформы не привязанной к железу и есть универсальная адаптация этой платформы под железо. Т.е. тебе не нужно делать глубокие тесты на всех платформах и ловить все особенности. У тебя есть гарантированный набор возможностей на который ты можешь рассчитывать вне зависимости от железа. 
  С++ не соответствует этой концепции. Поэтому его доля будет снижаться.

есть подозрения - что скорее Дельфи вольется в студию, чем Embarcadero наконец то сделает поддержку x64.

Это про Mono?


почему не соответствует? них фирштейн.

  В перспективе нативная поддержка.


  Потому что С++ сам по себе в рамках стандарта не дает достаточно возможностей для нормального программирования. Нативно у него поддержка текстовый режим и стандартный ввод/вывод. Остальное зависит от чужих библиотек, которые платформо-зависимы в той или иной степени. Как только ты ушел стандартной библиотеки у тебя сразу же начинаются танцы с бубном. Дальше уже финты с версиями платформами. Короче для С++ нет понятия родной платформы. Зачастую даже не все функции стандартной библиотеки реализуются.

Я конечно не эксперт в языках, но считаю что мнение о С++ неверно. Как известно все известные фреймворки такеи как Ява , дотнет.... предоставляют программисту удобство и избавляют его от рутинной и опасной работы c памятью. И это очень хорошо. Но ведь большинство функций этих каркасов реализовано на с++. И для машины полюбом нужен такой язык который может работаь напрямую с памятью. Я думаю С++ нужен как академическая и научная платформа для всех программистов. Я думаю корррекней было бы сказать не "C++ не нужен", a  "Мне в моем проекте для реализации конкретной задачи я могу обойтись без C++". Говорить что С++ не нужен - то же самое что говорить: "Блин, нафиг я 5 лет в универе штаны протирал, вот лучше бы купил самоучитель :Выучи С# за 24 дня - 10 минут на урок, и уже бы давно в визарде формы ваял".

  Нужен. Один раз написать явамашину и ее поддерживать, а в 1000 раз больше программистов будут просто использовать то что один раз оптимально и эффективно написано. Ява-машина это узкий перешеек между железом и многообразием ява-приложений. Он действительно является узким также в смысле производительности, что должен быть вылизан до предела, но только лишь он. Ведь не скажешь даже, что каждый 10й или каждый 100й программист пишет явамашины или аналогичные вещи.
  Речь идет о вытеснении С++ как высокоуровневого языка. Т.е. долой с массового рынка. Да с байтиками и битиками удобно играться, удобно залезть в абсолютный адрес.
  А теперь подумай, если в С++ нативные средства управления или создания потоков? Синхронизация? Межпроцессорная синхронизация или обмен. Средства для многомодульного программирования или распределенного? 
  Чаще всего это решается для текущей платформы непереносимыми возможностями, после чего наступает длительный этап проверки на всевозможных машинах и появления многих сюрпризов. Такие решения нельзя назвать удачными. 
  Delphi по крайней мере декларирует работу под Windows разных версий и набор родных, стандартных классов для работы с ней. Любой программист Delphi посмотрит код и поймет чего в нем происходит, потому что используются стандартные классы. Безусловно в этом вопросе C# далеко переплюнул Delphi for Win32, но его тоже нужно хорошо изучать и понимать какие языковые средства являются быстрыми, какие удобными но медленными, где можно ожидать нагрузку на сборщик мусора или менеджер памяти. 
  Кроме того алгоритмы они не зависят от языка, архитектуры данных, схемы взаимодействий объектов, архитектура приложения. Чтобы грамотно владеть C# понадобиться не одна неделя, и даже не один год наверное.

в tr1 уже есть синхронизация и потоки, есть OpenMP, TBB итд
interporcess - не просто стандартизировать, взять к примеру те-же средства delphi win32 и его классы для межмодульного взаимодействия, можно-ли их реализовать на posix api?  
в бусте есть библиотека interprocess, кроссплатформенная, она работает одинаково на разных платформах, но к примеру под windows, shared memory эмулируется с помощью отображаемых в память файлов, так как семантика shared memory POSIX не реализуется иными средствами в win32

что такое "средства для многомодульного программирования" я не знаю, возможно продукт больной фантазии дельфистов, а возможно ты имеешь ввиду interoperability, если так, то тут рулят всевозможные ВМ.

Добавлено через 58 секунд
also, delphi sucks and 

Добавлено через 11 минут и 10 секунд

COBOL, это то-же классика, между прочим до 80% используемого сейчас кода написано на нем - The statistics that surround COBOL attest to its huge influence upon the business world. [B]There are over 220 billion lines of COBOL in existence, a figure which equates to around 80% of the world's actively used code.[/B] There are estimated to be over a million COBOL programmers in the world today. Most impressive perhaps, is that 200 times as many COBOL transactions take place each day than Google searches - a figure which puts the influence of Web 2.0 into stark perspective.
но будущего у него нет

  Во первых новый стандарт еще не принят и не реализован. 

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

  boost это не стандарт, его и подключить можно далеко не ко всем компиляторам. 


  Линковка в рантайме. 
Вот например у меня есть платформа BlackFin и компилятор С++. нативными средствами С++ я не могу
1) Сделать таймер.
2) Вывести строку в cout
3) Вызвать assert()
4) Вывести что либо на экран
5) Вывести запустить второй поток
6) Синхронизировать 2 потока.
7) Синхронизировать поток и прерывание
8) Не могу сделать модуль так чтобы две программы использовали один и тот же кусок кода (например zlib)
9) Не могу создать/удалить/вывести в файл.
10) Эффективно работать с юникодом.

Теперь возьмем ява-программу для телефона. Разница очевидна. Имеется ява платформа, которая гарантирует мне определенный набор возможностей вне зависимости от типа процессора. Создатель телефона трудиться для того чтобы реализовать, то затребовала ява платформа, иначе телефон никто не купит.
Создатель компилятора С++ имеет минимум забот, зато теперь каждый программист С++ имеет кучу гемороя по изобретению велосипеда и каждый новый программист будет делать свой велосипед.
  
  Массовый программист должен иметь перед собой уже не полуфабрикат, готовую шоколадку, где некий стандарт гарантирует перечень ресурсов, ну или можно запросить у машины стандартным образом, умеешь ли ты делать такое? Или разрешено ли тебе такое.

  В концепции двухуровневой платформы С++ может занимать только первый "узкий" уровень, но никак не 2й "широкий". Тут даже говорить нечего, удивляюсь о чем тут спорить?

С++ годиться только для одноуровневой схемы, которая устаревает постепенно. 

11) Открывать пиво
12) Заказывать пиццу
напиши свои велосипеды - с преферансом и блудницами  
а вообще, компилятор с++ и стандартные библиотеки, это не платформа, все это должно расширяться сторонними библиотеками, в этом вся прелесть данного подхода, никто не заставляет использовать boost, или zlib


тут я бы то-же поспорил, для .NET есть P/Invoke, для Java - JNI, и С++ вполне годен для реализации каких-либо требовательных к ресурсам частей системы

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

Это сообщение отредактировал(а) Lazin - 26.8.2009, 14:42

Епт! Собственно вот на это я и хотел указать.
  C#, Java, Python, Perl, PHP это все платформа, языки предназначенные для 2го уровня двухуровневой системы. 
С++ не нужен как язык второго уровня. 
  

  

 off topic а Delphi?

  Delphi использует как платформу Win32 и его возможности это возможности Windows, например некоторые объекты даже не хранят свое состояние, они каждый раз вызывают API функции для определения своего состояния. Проблем, конечно больше из-за разных версий windows, но в целом это больше похоже на язык 2го уровня нежели С++, поскольку многие функции ОС отражены в классах VCL и являются нативными. Т.е. можно очень много написать не выходя за рамки VCL или используя VCL основанные компоненты. VCL имеет некоторые возможности адаптации к разным ОС, например некоторые системные библиотеки загружаются при помощи LoadLibrary, предварительно проверяется присутствуют ли они или нет, если да, то дополнительные опции включаются. Все это происходит без ведома пользователя. Во многих вещах VCL стр###т программиста, адаптируясь самостоятельно (без его ведома). Модульность это языковой механизм, многопоточность и синхронизация это встроенные классы, аналогично файлы и графический вывод. Многие вещи просто гарантируются платформой Win32. У тебя эти возможности всегда есть ввиду непереносимости кода по определению. Это простое решение  .

это совсем не похоже на язык 2-го уровня, если под словосочетанием "язык 2го уровня" имеется ввиду java или .NET, мало того, что тут дело далеко не в одном языке, да к тому-же, C++ обеспечивает более высокий уровень абстракции от ОС, в случае использования соответствующих библиотек, я уже молчу про все остальное  


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

еще раз хочу напомнить, что delphi тут - огромный offtopic, я вообще думал, что будет холивар на тему ФП vs традиционные языки, но Alexis все опошлил свей любовью к проприетарным, умирающим технологиям 10-летней давности 

Добавлено через 31 секунду

и хватит ругаться матом!

Одного упоминания названий языков недостаточно, чтобы развязать такой холивар. Приведи конкретный пример, как удалось реализовать преимущества ФП на конкретной задаче, адресно пни императивщиков, и получи толпу, доказывающую, что это их задачи это не решает, и вовсе это не преимущества на самом деле, и вообще что за китайская грамота.
И скажи спасибо, что ещё не набежали хардкорщики, у которых не плюсы плохи, а программисты недостаточно хороши для плюсов.