Conexus – универсальная библиотека ввода/вывода для ЯП C++

>и где там VB>?

Если имелся в виду visualbasic, то ровно посрединке.

> Сейчас есть Python, C# и F#... Посмотрим кто выйдет в финал... :-)

Прикол в том, что у нас несколько первых мест. :) И на одном из них прочно сидит Цэшарп, который уже точно никто не сдвинет лет 10.

> Прикол в том, что у нас несколько первых мест. :) И на одном из них прочно сидит Цэшарп, который уже точно никто не сдвинет лет 10.

Пруф? Ссылки на microsoft.com не предлагать.

А пока:

Исследование на основе анализа продуктов с открытым кодом http://www.blackducksoftware.com/oss/projects#language

Исследование на основе поисковой информации http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html

Везде православный C

>> Разве в ибм никогда не слышали, про STREAMS?

а при чем тут ibm ?

>Я имею в виду не простейшие случаи ввода/вывода

Мне кажется или бот от IBM впервые сказал о себе в первом лице?

>Мне кажется или бот от IBM впервые сказал о себе в первом лице?

Он тут и в камментах когда-то разговаривал.

С тем, что C++ в новых приложениях не нужен, согласятся многие (внимание! не все, и даже не обязательно большинство). Но по поводу остальной части вброса возникают сомнения. По пунктам: 1. Есть куча красивых и удобных объектно-ориентированных и мультипарадигменных языков, яркие примеры которых python ruby. Или perl, если речь не идет об ООП. Из нединамических стоит упомянуть Vala, D, C# (относительная «незрелость» первых двух объясняется, наверное тем, что контрибьюторов мало, что кагбэ намекает, что все прочно сидят попой на C++). Но, в отличии от явы, все эти платформы имеют нормальные биндинги к большинству существующих либ и возможности непосредственного взаимодействия с нативным кодом 2. Как вообще кореллируют C++ и ФЯ? ФЯ нужны там, где они нужны, как то ни странно. А именно: для легкой записи математических алгоритмов, для параллелизации вычислений (за счет чистоты функций и, как следствие, реентрабельности). А что на практике получится? Большинство линейных, однопроходных и до мозга костей императивных алгоритмов потребуют громоздкой и нетривиальной записи, что увеличит сроки и стоимость разработки. Немутабельность типов - очень спорный момент, поскольку на практике это означает, что присваивание превращается в инстанциирование нового объекта. Опять-таки, теряем в производительности В общем-то, надо просто мозг иногда включать, и выбирать средства исходя из целей. Для скриптов - shell + perl, для гуя - декларативное описание, для RAD - объектно-ориентированные обертки на любом современном языке (естественно, что библиотеки этих языков должны быть скомпилированы в нативный код, и, скорее всего, написаны на C или C++), для математики - специфические языки (не обязательно ФП, все зависит от задачи). И не надо мешать все в одну кучу. Ну нет в C++ функционала для работы с БД, XML и веб-сервисами в стандартной поставке - ну и не надо. Это же не «плафторма», а всего лишь прослойка между либами и программистом.

> С тем, что C++ в новых приложениях не нужен, согласятся многие... Ну нет в C++ функционала для работы с БД, XML и веб-сервисами в стандартной поставке - ну и не надо. Это же не «плафторма», а всего лишь прослойка между либами и программистом.

«забудьте всё, что я сказал, ибо я не сказал ничего».

Не смотря на то, что я редко в последнее время пишу _новые_ приложения на С++, очевидно, что всё зависит от задачи. Весь KDE написан на С++, и новые приложения пишутся, а всё потому, что удобно там.

> Все системные вещи надо писать исключительно на С, для всего остального - ява и функцианальные языки. с++ ненужен уже никому, особенно когда речь идет о новой разработке.

Да, системная часть KDE должна быть написана на Си, а приложения на Javascript. Вот только не слушают, почему-то, такого видного специалиста по всему, как Sun-ch. Не удаётся этому вундеркинду достучаться до нужных голов.