Вот почитал я тут громадные нитки обсуждений на темы "Чем так развлекателен Си++" и "Проектируем старый язык программирования" и задумался над тем, чего хотелось бы мне от языка программирования и от среды в целом.

Пишу я нониче на работе на Си++, компилятор MSVC++ 6, ATL, WTL, COM, COM+, раньше писал на Фортране, Бейсике, Фокс-Про, Дельфах, Паскале, Билдере, и вообще на чем попало. Маненечко интересуюся Дотнетом, хотя возможности заняться оным вплотную нету.

Всякий раз меня что-то доставало, что-то мне не нравилось, более или менее сильно... Дотнет выглядит весьма многообещающим, но опять-таки: кое-чего не хватает!

Вот я и подумал, а что если попытаться свесть воедино мои мыслишки на эту тему? Коротенько так, минут эдак на сорок, больше, думаю, не надо... (c) тов. Огурцов.

Во-первых, сразу определюсь, что имею в виду только языки императивно-декларативного программирования общего назначения. Специализированные языки (типа Перла, скриптов, оболочечных языков) я не трогаю: у них свои задачи и своя ниша.

Во-вторых, языки других типов — функциональные (Лисп), логические (Пролог), реляционные (Дейталог, SQL) и проч. — также рассматривать не буду, т. к. с точки зрения практической для разработки приложений они негодны, хотя и годятся для разработки подсистем и модулей, для решения специальных задач.

В-третьих, языки чисто императивные (типа Фортрана-77 и старого Бейсика), не предоставляющие мало-мальских средств декларативного программирования (ну есть в Фортране-77 структуры, но этого же недостаточно!), также не катят, ибо упрощение и повышение качества программирования заключается в переходе от чисто императивного стиля в сторону все более и более декларативного, и с этой точки зрения эти языки уже безнадежны (Фортран-90 ничего существенного нового в процесс разработки на Фортране не внес, а ВБ — это, простите, уже не Бейсик).

Значицца, так.

Вот тут спорят по поводу Си++. Кто-то утверждает, что Си++ — чудо. Кто-то — что Си++ — отстой. Думаю, и те, и те неправы. Недаром Си++ стал на долгое время самым популярным средством разработки; опять же недаром с него сейчас многие уходят.

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

Некоторые заявляют, что Си++-де не развивается, чтобы отвечать современным требованиям. Проблема в том, что, как мне скромно кажется, расти ему некуда — за исключением разве что некоторых синтаксических улучшений вроде бурно обсуждавшихся здеся делегатов, в самой примитивной их форме. Самые фундаментальные основы существования этого языка, его оправдание — строгая статическая типизация, доступ к непосредственному управлению доступной программе памятью и много-много еще чего — ориентированы на создание более или менее монолитных приложений, преемственных к тому же программным модулям 60-70-х годов. Они [основы] были существенно необходимы для разработки приложений тогдашнего уровня сложности. А при нынешних требованиях к сложности приложений создавать их монолитными... — нет, ну я соглашусь, что теоретически возможно все, — но практически-то нереально!

Создание компонентного ПО на Си++ возможно, но это же просто невозможно! Я знаю, что говорю, сам сейчас мучаюсь с ATL/COM... Не говоря уже о том, что поддержка статической типизации в межкомпонентных интерфейсах, возможность использования классов Си++ — это таки отдельная песня! Нет, мне, конечно, скажут: это не вопрос языка, это вопрос среды, библиотек... Отлично: но почему же нету нормальных средств удобной разработки приложений на Си++? Почему нет стандартной среды, функционально подобной, скажем COM, делающей процесс создания качественного ПО на Си++, скажем так, не сложным сверх всякой меры? Почему постоянно приходится путаться между полудюжиной всевозможных средств работы со строками?

А как вам нравится полное отсутствие встроенной в язык целочисленной арифметики с контролем переполнения? Нет, конечно, для многих задач это несущественно, для многих — наоборот, подход Си/Си++ как раз и нужен. Но ведь есть и такие приложения, где нужно иметь разумную защиту от того, что деля на сумму двух положительных чисел, программа может вылететь с криком "Division by zero".

"Мне же нужно программировать прикладную логику! Мне нужно это делать сегодня! Я не желаю все силы отдавать системным вещам в ущерб основной логике! А мне приходится это делать — раз за разом! Дайте же мне что-нибудь не столь чистое и идеальное, чтобы я мог достигать результата проще!" — вот что заявит нормальный разработчик...

Получается так, что, чтобы "расти", Си++ должен преодолеть то, что является его самой основой. Тогда это становится уже другим языком, например Си-шарп.

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

Тем не менее, в Си++ есть много чего хорошего, что хотелось бы сохранить...

Статическая типизация по-прежнему является очень важным средством построения программных модулей (недаром ведь ни один новый язык не отказался от прототипов функций). Но нужна стандартная среда, которая брала бы на себя все вопросы обмена объектами между программными компонентами. Нужна стандартная среда, которая бы динамически отслеживала все, что связано с исполнением статически (жестко) типизированных контрактов между компонентами...

Очень неприятно было читать в описаниях CLR и языка Си-шарп ("До-диез" ) обороты вроде "это мы отбросили, потому как в этом многие путаются, мы предлагаем взамен другие концепции программирования". Например, взять то же множественное наследование реализаций. При надлежащем объяснении оно оказывается вполне понятным программистам; при надлежащем использовании оно становится весьма удобным средством. Если кто-то не чувствует в себе достаточной уверенности в том, что сможет использовать его, — его можно и не использовать. Если мудрецы из Микрософта решили, что эта возможность не может быть реализована в CLR или что она откладывается на будущее (это можно было бы понять, т. к. объемы работ огромны), — так и следовало честно сказать.

Шаблоны — ну о них вообще многие рыдают... Тут все, на мой взгляд, ясно. Наличие STL — это, можно сказать, третий плюс к Си++. Возникает только одно но: как это реализовать в рамках CLR или аналогичной среды? Вопросец еще тот...

Оптимизация — по всей видимости CLR, MSIL, JIT в совокупности открывают потенциально путь к огромным возможностям оптимизации (как, скажем, полностью безопасное межкомпонентное встраивание вызовов функций) — короче, по этому вопросу — нужно ждать! Если же при этом еще и оставить богатые выразительные возможности Си++ по составлению выражений...

Еще, как я понял, в Дотнете нету автоматических (в смысле Си/Си++) объектов. Вот это непонятно — почему?

Теперь собственно о среде...

Когда я почитал впервые насчет того, что предоставляет Дотнет... Реакция моя была такой: ну почему все это только сейчас?!!

На этом, собственно, обсуждение и закончилось...

Теперь — о том, чего еще желает моя душа...

Ну почему, ну почему языки и среды так мало внимания уделяют собственно разработке?

В среде разработки Дотнета VS.Net наконец-то появился более-менее удобный редактор для Си-шарпа, позволяющий сворачивать-разворачивать определения классов и функций... Как давно мечталось о чем-то подобном для Си++! Но, увы, для Си++ с его раздельным объявлением и определением методов это недостижимо. Так легко получить рассогласование, скажем, между комментариями к одному и тому же методу в точке объявления и определения.

Ни в одном популярном языке нет ни понятий антецедента и консеквента, ни поддержки состояний, проверяемых при компиляции. Слава богу, хоть появились языки, в которых возможно нормальное (не как в Си++) описание того, какие исключения могут быть выброшены из функций, и это даже проверяется компилятором.

Могу еще продолжить, но хотелось бы послушать, что вы все на этот счет думаете...

Здравствуйте Znow, Вы писали:

Z>Очень неприятно было читать в описаниях CLR и языка Си-шарп ("До-диез" ) обороты вроде "это мы отбросили, потому как в этом многие путаются, мы предлагаем взамен другие концепции программирования". Например, взять то же множественное наследование реализаций. При надлежащем объяснении оно оказывается вполне понятным программистам; при надлежащем использовании оно становится весьма удобным средством. Если кто-то не чувствует в себе достаточной уверенности в том, что сможет использовать его, — его можно и не использовать. Если мудрецы из Микрософта решили, что эта возможность не может быть реализована в CLR или что она откладывается на будущее (это можно было бы понять, т. к. объемы работ огромны), — так и следовало честно сказать.

Понимаешь, видимо то что ты читал это какая то маркетинговая листовка, на которую не стоит особо обращать внимание. Вон Sun тоже заявляет что write once run anywhere, но на практике все немножко не так.
А так смешно было бы — заявлять в пресс-релизах что мол у нас сил и соображалки не хватило реализовать то и то.

Z>Шаблоны — ну о них вообще многие рыдают... Тут все, на мой взгляд, ясно. Наличие STL — это, можно сказать, третий плюс к Си++. Возникает только одно но: как это реализовать в рамках CLR или аналогичной среды? Вопросец еще тот...

Ну тестовые реализации есть и для джавы и для дотнета. Можешь поглядеть как.

Z>Еще, как я понял, в Дотнете нету автоматических (в смысле Си/Си++) объектов. Вот это непонятно — почему?

GC потому что. Хотя конечно автоматические деструкторы для структур можно было постараться добавить. А лучше ввести в рантайм специальные автоматические дестроеры, что то вроде рантайм варианта using. Но в общем то using как правило вполен заменяет, с ним жить можно.

Z>Ни в одном популярном языке нет ни понятий антецедента и консеквента, ни поддержки состояний, проверяемых при компиляции. Слава богу, хоть появились языки, в которых возможно нормальное (не как в Си++) описание того, какие исключения могут быть выброшены из функций, и это даже проверяется компилятором.

Это ты про джаву? На самом деле это тот еще гемморой, хорошо что в шарпе это выбросили.

Здравствуйте AndrewVK, Вы писали:

Z>>Ни в одном популярном языке нет ни понятий антецедента и консеквента, ни поддержки состояний, проверяемых при компиляции. Слава богу, хоть появились языки, в которых возможно нормальное (не как в Си++) описание того, какие исключения могут быть выброшены из функций, и это даже проверяется компилятором.

AVK>Это ты про джаву? На самом деле это тот еще гемморой, хорошо что в шарпе это выбросили.


Какой такой гемморой? А помоему очень удобно.
Или обработай исключение или скажи честно, что не обработал.
Всегда ясно, что можно ожидать от ...

Правда наблюдал пару раз — глючит — выбрасывается исключение,
которого не положено по спецификации.
Но это из чужого класса... исходников не было.


Слушай, Aznow, расскажи pls, что это за слова такие "антецедент и консеквент". Интересно ведь...

Здравствуйте Рек, Вы писали:

Рек>Здравствуйте AndrewVK, Вы писали:

Z>>>Ни в одном популярном языке нет ни понятий антецедента и консеквента, ни поддержки состояний, проверяемых при компиляции. Слава богу, хоть появились языки, в которых возможно нормальное (не как в Си++) описание того, какие исключения могут быть выброшены из функций, и это даже проверяется компилятором.

AVK>>Это ты про джаву? На самом деле это тот еще гемморой, хорошо что в шарпе это выбросили.

Рек>
Рек>Какой такой гемморой? А помоему очень удобно.
Рек>Или обработай исключение или скажи честно, что не обработал.
Рек>Всегда ясно, что можно ожидать от ...

Абсолютно согласен! Дай пять! Когда пишешь COM-сервер, методы которого вызывают другой код, который выбрасывает исключения, мой долг — поймать все исключения, преобразовать их в код ошибки и не пропускать исключения наружу! А что ловить-то?

Рек>Слушай, Aznow, расскажи pls, что это за слова такие "антецедент и консеквент". Интересно ведь...

Антецедент и консеквент — это условия, которые должны выполняться соответственно перед входом и по выходе из некоторого участка кода.

Их формальная запись помогает контролировать верность кода (в частности, что ничего из требований не забыто)

Здравствуйте Рек, Вы писали:


Рек>Какой такой гемморой? А помоему очень удобно.
Рек>Или обработай исключение или скажи честно, что не обработал.
Рек>Всегда ясно, что можно ожидать от ...

Поясняю. Лично я привык разрабатывать программы примерно так: сначала пишется голый костяк, в котором половина не реализована, а половина тормозит жутко. На этом костяке я довожу интерфейсы и логику взаимодействия, не стесняясь корежить довольно большие куски, поскольку коду немного. А уже когда скелет устаканился я начинаю прорабатывать частности. Так вот — необходимость сразу, в первой же строке кода обрабатывать исключения мягко говоря не очень удобна. Главное ощущение от перехода с джавы на шарп — жуткое облегчение от отсутствия необходимости заботиться обо всех исключениях.

Здравствуйте AndrewVK, Вы писали:

AVK>Поясняю. Лично я привык разрабатывать программы примерно так: сначала пишется голый костяк, в котором половина не реализована, а половина тормозит жутко. На этом костяке я довожу интерфейсы и логику взаимодействия, не стесняясь корежить довольно большие куски, поскольку коду немного. А уже когда скелет устаканился я начинаю прорабатывать частности. Так вот — необходимость сразу, в первой же строке кода обрабатывать исключения мягко говоря не очень удобна. Главное ощущение от перехода с джавы на шарп — жуткое облегчение от отсутствия необходимости заботиться обо всех исключениях.

Я полностью согласен с тем, что начинать с этого сразу сложно. Я и сам так пишу. Но ведь можно сделать (как именно — сложно сказать, это нужно продумывать долго-долго!) так, чтобы среда разработки поддерживала некий список требований к коду, и на начальной стадии большинству требований выставлять признак "пренебречь". Потом, когда нужно доводить код, ищем: чем мы там до сих пор пренебрегали?

Здравствуйте Znow, Вы писали:

Z>Вот я и подумал, а что если попытаться свесть воедино мои мыслишки на эту тему? Коротенько так, минут эдак на сорок, больше, думаю, не надо... (c) тов. Огурцов.

Не знаю. Спорить о преимуществах языков достаточно бесполезно, но вот о среде помоему стоит. Я вот что подумал на эту тему. Наверное все кто программит на VC знает о такой приблуде Visual Assist. Я когда в первый раз ее увидел подумал "Ну все, техника дошла, скоро к тому моменту как ты наберешь программу она уже будет скомпилирована".

К сожалению Visual Assist все же достаточно далек от идеала. Потому как ему всетаки сложно парсить C++ в runtime. C++ слишком сложный язык.

Я вот до сих пор думаю почему нельзя создать язык не только с точки зрения удобства человека, но и с точки зрения удобства парсинга/компиляции кода. С точки зрения удобства его Reverse Engeneering-а всякими тулзами типа Rational Rose и тп. Если это изначально предусмотреть то можно создать язык программирования вместе с IDE, притом IDE будет такого качества что будет буквально делать 2/3 работы за программиста.

Т.е. основная идея делать не IDE для языка, а язык для IDE. Интересно кто-то об этом уже думал или мне стоит это запатентовать

Здравствуйте Anatolix, Вы писали:

A>Я вот до сих пор думаю почему нельзя создать язык не только с точки зрения удобства человека, но и с точки зрения удобства парсинга/компиляции кода. С точки зрения удобства его Reverse Engeneering-а всякими тулзами типа Rational Rose и тп. Если это изначально предусмотреть то можно создать язык программирования вместе с IDE, притом IDE будет такого качества что будет буквально делать 2/3 работы за программиста.

A>Т.е. основная идея делать не IDE для языка, а язык для IDE. Интересно кто-то об этом уже думал или мне стоит это запатентовать

Правильно мыслишь. Одной из особенностей шарпа является легкость компиляции и reverse engoneering. Так что думают.
Еще был такой проект — xml-вариант java.

Здравствуйте AndrewVK, Вы писали:

A>>Т.е. основная идея делать не IDE для языка, а язык для IDE. Интересно кто-то об этом уже думал или мне стоит это запатентовать

AVK>Правильно мыслишь. Одной из особенностей шарпа является легкость компиляции и reverse engoneering. Так что думают.

Он всетаки сильно на C++ похож, чтобы это было так. Хотя синтаксических гадостей всеравно поубавилось. Ты меня не лечи за шарп ты мне скажи для него есть что0нибудь сильно лучше чем Visual Assist

AVK>Еще был такой проект — xml-вариант java.
Это уже для человека тяжко.

Кстати pascal достаточно близок к языку который легко парсить.(надо глянуть Delphi7/Architect). Правда надежды призрачны, для того чтобы было все клево нужно отказаться от всяких багосовместимостей что Borland не сделает.

Здравствуйте Anatolix, Вы писали:

A>Он всетаки сильно на C++ похож, чтобы это было так.
Да не похож он на C++. Вся его похожесть ограничивается только использованием сходных ключевых слов, фигурных скобок для выделения блока ну и еще пожалуй for. На самом же деле совершенно иной язык. Вот на джаву он действительно похож.
Впрочем похож/не похож неважно. Студия довольно быстро реализует intellisense и сериализацию/десериализацию свойств компонентов в код.

Здравствуйте AndrewVK, Вы писали:

AVK>Здравствуйте Anatolix, Вы писали:

A>>Он всетаки сильно на C++ похож, чтобы это было так.
AVK>Да не похож он на C++. Вся его похожесть ограничивается только использованием сходных ключевых слов, фигурных скобок для выделения блока ну и еще пожалуй for. На самом же деле совершенно иной язык. Вот на джаву он действительно похож.
AVK>Впрочем похож/не похож неважно. Студия довольно быстро реализует intellisense и сериализацию/десериализацию свойств компонентов в код.

Ладно я спорить не буду потому как не знаю, лучше потом сам посмотрю, когда время будет.

Здравствуйте Anatolix, Вы писали:

A>Не знаю. Спорить о преимуществах языков достаточно бесполезно, но вот о среде помоему стоит. Я вот что подумал на эту тему. Наверное все кто программит на VC знает о такой приблуде Visual Assist. Я когда в первый раз ее увидел подумал "Ну все, техника дошла, скоро к тому моменту как ты наберешь программу она уже будет скомпилирована".

Visual Assist — это типа когда набираешь ".", а он тебе список членов? Я его завсегда отключаю, он у меня непрестанно приводит к тому, что студия закрывается без всякой ругани и предупреждений. Была студия, нажали ".", нет студии (и плодов часового труда).

A>К сожалению Visual Assist все же достаточно далек от идеала. Потому как ему всетаки сложно парсить C++ в runtime. C++ слишком сложный язык.

Дело в том, что благодаря своей немодульной структуре, макросам и т. п. Си++ вообще в принципе разбирать "на лету" невозможно. Т. е. возможно, но только если делать какие-то сложные предположения... Вот например, нажимаем Ctrl+Пробел. Начинаем набирать "CreateWindowEx". В списке видим CreateWindowEx, но не видим ни CreateWindowExA, ни CreateWindowExW. Очевидно, это неким образом специально обрабатывается. Т. е. это довольно-таки эклетичная штучка.

A>Я вот до сих пор думаю почему нельзя создать язык не только с точки зрения удобства человека, но и с точки зрения удобства парсинга/компиляции кода. С точки зрения удобства его Reverse Engeneering-а всякими тулзами типа Rational Rose и тп. Если это изначально предусмотреть то можно создать язык программирования вместе с IDE, притом IDE будет такого качества что будет буквально делать 2/3 работы за программиста.

Нет, язык нужно создавать именно с точки зрения удобства человека. Язык, удобный для человека, действительно будет проще в разборе, и Си-шарп, насколько я с ним знаком, тому пример. А вот с шаблонами — ей-богу — надо что-то придумывать... В Си++ они пишутся несложно, покуда они сами не сложны, а вот потом начинается песня... Такой синтаксис сохранять нельзя, это мое исключительно скромное мнение. В частности, что бы там ни говорили, нужны средства для описания моделей, которым должны удовлетворять параметры шаблона.

A>Т.е. основная идея делать не IDE для языка, а язык для IDE. Интересно кто-то об этом уже думал или мне стоит это запатентовать

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

Z>Потом, когда нужно доводить код, ищем: чем мы там до сих пор пренебрегали?

Иными словами, это своего рода "to-do list", но поддержанный всей мощью компилятора, который не позволит забыть что бы то ни было.

Если бы губы Никанора Ивановича да приставить к носу Ивана Кузьмича, да взять сколько-нибудь развязности, какая у Балтазара Балтазарыча, да, пожалуй, прибавить к этому еще дородности Ивана Павловича – я бы тогда тотчас же решилась.
(Гоголь, Женитьба).

Здравствуйте esr001, Вы писали:

E>Если бы губы Никанора Ивановича да приставить к носу Ивана Кузьмича, да взять сколько-нибудь развязности, какая у Балтазара Балтазарыча, да, пожалуй, прибавить к этому еще дородности Ивана Павловича – я бы тогда тотчас же решилась.
E>(Гоголь, Женитьба).

Так-то оно так, но из Никанора Ивановича, Ивана Кузьмича, Балтазара Балтазарыча и Ивана Павловича нового человека не слепишь... Если только сам изволит родиться...

А вот новые языки программирования людьми придумываются!

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

Z>Я это затеял просто к тому, что существующее положение вещей вызывает у меня недовольство. И я думаю о том, чего бы можно придумать или ожидать в плане того, чтобы это недовольство уменьшить...

Блестяще! Все больше недовольства в постах.
Люди собрались неглупые, и есть еще одна вещь, которая всех объединяет: многим пришлось работать над крупными проектами очень малыми силами. Не двести, а пять/десять человек на проект (а то и вовсе один). Именно в таких ситуациях и проявляются слабые места существующих систем.

Что-то явно назревает. И вообще, IO задавал неглупые и далеко не наивные вопросы. Зря заглохла ветка.
Может теперь Znow поддержат больше. Ведь для обдумывания концепций не нужно писать код и ездить в метро. А кое-что, выведенное для гипотетической идеальной среды, может оказаться применимым уже к существующим языкам.

Здравствуйте Poudy, Вы писали:

P>Блестяще! Все больше недовольства в постах.
P>Люди собрались неглупые, и есть еще одна вещь, которая всех объединяет: многим пришлось работать над крупными проектами очень малыми силами. Не двести, а пять/десять человек на проект (а то и вовсе один). Именно в таких ситуациях и проявляются слабые места существующих систем.

Ну, я не очень согласен... Я думаю, чем более полна поддержка программисту, тем лучше — независимо от того, какова команда.

Вот пишу я сейчас (на этот раз в одиночку) модуль (COM) для довольно-таки большого проекту. На Си++.

Что мне не нравится?

Во-первых, строки. Получаем BSTR, проверяем на длину, чтобы не грохнуть стек, преобразуем посредством OLE2T, имеем LPTSTR. Затем, для разных целей: то используем LPTSTR, где-то, опять-таки необходимо применять порою T2A или T2W, то CString, то std::string и std::wstring (вот ведь как оборачивается: средство стандартное, практически — часть языка, но использовать его жутко невозможно). Или же применяю CComBSTR — ну, чуть полегче, но не дай Бог забыть Attach или Detach. В конце ответ запихиваю опять в BSTR. Задолбало! Это свойство, в первую очередь, сложившейся практики программирования на Си++ под COM. Можно много говорить о правильном проектировании и т. д. и т. п. Но практически применимого рецепта выхода из этого маразма я не вижу.

Во-вторых, исключения. Структурная обработка исключений — страшная сила. Но нельзя передать исключение "сквозь" COM-интерфейс. Приходится отлавливать довольно много типов исключений на верхнем уровне — т. е. непосредственно в каждом методе реализации интерфейса — и упаковывать их в некие структуры для возврата вызывающей стороне (что, кстати, уродует сам интерфейс). Или использовать HRESULT (хотя его зачастую недостаточно) и IErrorInfo (а кто вам сказал, что мне достаточно текстового описания ошибки?). Это свойство уже COM (хотя я и сам не уверен, что скрестить SEH и COM возможно).

В-третьих, поддержка системных вещей — таких, как журнализация, работа с транзакциями и т. п. Такие вещи замечательно делаются с помощью аспектов (чтение о них привело меня в восторг) при системной поддержке, каковую, как я понял, оказывает Дотнет. А вот в Си++ этого не сделать. Если кто и знает как, пусть поделится: вот у меня есть метод COM-сервера, открыта фигурная скобка. Как ему рассказать о журналах, о транзакциях?

Ну я еще могу привести в-четвертых, в-пятых и в-дватцать шестых.

Мне скажут: смени COM на что-то еще (например, на Кобру, гы-гы!). Не могу, т. к. встраиваюсь в уже имеющуюся систему.

Скажут: пиши, ну скажем, на VB — там хоть часть проблем снята. Опять не могу, т. к. мне, по характеру задачи, нужны потоки, семафоры, события. Дельфы здесь не в почете...

Скажут: ну чем же тебе язык тут поможет?

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

Так вот, чтобы ничего не забыть, я записаваю себе разные таблички в тетрадочку, а потом ставлю галочки, черкаю... Такая тетрадочка в клеточку, раньше 3 коп. стоили . Инструментарий программиста, так сказать . Ну собственно, это то, о чем тут рядышком писал Anatolix, — потепенное ужесточение и введение в действие различных требований к программному коду.

Понятно, к чему я веду? Мало того, что среда не избавляет от рутины, она даже и не дает средств к организованному ее преодолению.

Z>Так вот, чтобы ничего не забыть, я записаваю себе разные таблички в тетрадочку, а потом ставлю галочки, черкаю... Такая тетрадочка в клеточку, раньше 3 коп. стоили . Инструментарий программиста, так сказать .

Кстати, обычно уходит две-три тетрадочки на средний проект.

Здорово. Тетрадочки очень забавно... Действительно, есть над чем задуматься.

Говоря о большом числе программистов, я имел в виду, что десять мартышек печатают быстрее одной (да не обидится никто).

По правде сказать, от языка редко требуется больше, чем избавление от рутинной автоматной работы. Среда должна поддерживать метаданные и метаоперации. Такие вумныя слова. Это в том смысле, что необходима поддержка для возможности строить из простых понятий более сложные, комплексные, выходить на более высокий уровень абстракции.
То есть, на каком-то этапе все должно становиться значительно проще. Этакий предельный уровень агрегации, когда наплевать на работу составляющих элементов.

Тут есть одна потрясная мысль: текст программы — это линейная структура. Тривиально, но: это означает, что она хорошо подходит для обработки линейных структур.
Помните, как в далеком детстве тяжело въезжалось в циклы? Квадрат хотят поместить в линеечку. В чем, совственно, загвоздка. Кто-то сказал, что проектирование — это по сути топологическая задача.
Станные сортировки в одномерных массивах еще как-то понятны, а странных сортировок в двумерных, которые бы не приводились (выводились) явно из одномерного случая я не видел.

Это все выше бред полный, а зерно в том, что стоит только перейти от линии к плоскости (всякие там алгоритмы сглаживания), как ничинается форменное г0вн0. Еще хуже в 3D. Такое начинается, если захочется грани куба в тройном массиве обойти или отрисовать самому — целое дело. Муму идут ко дну без криков. Появляется мысль, что многие проектные задачи также имеют существенно многомерную структуру, и, хотя в целом с ними все понятно, кода приходится ваять вагонами.

Здравствуйте Znow,
cогласен с вами почти во всем.
Я сам предпочитаю писать программы модульно, определять для нужных функций некоторый четкий API, а потом “склеивать” все это на интерпретируемом языке, к которому тоже прописано некоторое API. Если потом надо – легко прописать wrap к API на C++, перековать скрипты на C++. Иначе мне трудно отладить программу.
Что касается средств разработки – я обычно использую минимум. Простой редактор типа SciTE (www.scintilla.org) и набор кодогенерящих скриптов.