Я это и имел ввиду 

SergeCpp, 
читай

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

Сейчас я пишу для Win CE. Просто нет другого компилятора + использую внутренние библиотеки. Т.е. просто нет выхода  



Не надо мешать все в кучу.  Речь шла о том, что повышение уровня абстракции есть шаг вперед. 
Специализация языков это уже другой вопрос. Критикуйте первое утверждение!

Добавлено @ 11:45 


Четко же было сказанно! Как вам удалось сюда приписать универсальность?

[offtop]
Извиняюсь, что не в тему (Delphi>>C++), такие языки, как например Python, Ruby -- имеют гораздо больший уровень абстракции, нежели Delphi, и следуя логике товарищей просто необходим дальнейший переход...

И хотелось бы уточнить, что товарищи понимают под более высоким уровнем абстракции? если абстрагирование от машинной реализации -- то почему вы тогда еще не перешли с Object Pascal на какой-либо язык декларативного программирования?
(вопрос не к skyboy  )
[/offtop]

 Ага если понадобится интенсивно программировать БД, и дадут время для переучится, то конечно!


 Насколько я понимаю для работы таких языков еще нет серьезной базы, так что это пока дело будущего. А программировать надо сейчас на том что имеется. Вот когда доведут это дело до ума (если доведут), то тогда и поговорим.

ну, как тебе сказать... Под платформу .NET существует немало "самописных" трансляторов(в основном - на C#) для разных языков: и Пролог, и Лисп(кста, в комплекте с VisualStudio в папке с примерами лежит небольшой транслятор-компилятор ЛИСПа, а в разделе research у Microsoft есть загрузка компилятора функционального языка F#), и несколько других разных... Так что, это скорее дело настоящего... Вот "самостоятельных" разработок действительно не так уж и много - как-то проще транслятор написать в ЯВУ, нежели в ассемблер, но и такое встречается(например, VisualProlog, не имеющий никакого отношения к Microsoft, и EZYProlog позволяют писать GUI-приложения под Windows).

Это сообщение отредактировал(а) skyboy - 6.12.2006, 15:32

предложи!

область применения питона и руби имхо не всегда применима везде, чисто мое имхо,
а вообще в этой теме это точно оффтоп!!!!

Разнообразные декларативные языки замечательно существовали задолго до .NET и JVM, так что тут проблем особых нет. Лучшие компиляторы ML и Haskell как раз управляемые среды не используют (хотя тот же Simon P. J. сам работает в MS research). Проблема в основном в мозгах разработчиков (не все хотят и могут преодолеть ломку при добавлении к процедурном или ОО-стилю функциональщины, метапрограммирования и т.п.) и, частично как следствие предыдущего факта, отсутствие такого разнообразия библиотек, как для «традиционных» языков. А с теоретической базой у декларативных языков всё замечательно.

я знаю о них. чесно-чесно. просто когда есть возможность сочетать в одной программе код, написанный на императивном и декларативном языке и при этом не возникает проблем, как раз можно решить ситуацию, когда имеется в наличии 
. Как где-то на форуме слышал: "пишу перебор на Прологе в dll, а потом клепаю GUI на C#"  Отдельные же компиляторы(по крайней мере, многие - может я не с теми сталкивался?) не компилят dll или ещё какой вид библиотек - сразу ЕХЕ. а GUI на том же lisp'e писать проблематично - все же событийная модель в той же Windows не предполагает, что "вся программа - одна большая функция". Впрочем, может я не со всеми аспектами функционального программирования знаком?

Добавлено @ 17:56 
вот подумалось: а тот же Пролог отлично приспособлен к сообщениям системы:

Не стоит думать, что Питон, например, только с БД замечательно справляется.

имеется многое.

А теперь, к чему я вообще задавал вопрос. Разговор зашел об уровнях абстракции. Сии уровни располагаются, как я понимаю, на линии между ориентацией на машину с одного конца, и ориентацией на контекст конкретной предметной области, для которой решается задача, с другого конца. Шаг к более высокому уровню абстракции -- это конечно же шаг вперед, НО (!) только когда нет зависимости от машинных ресурсов. В реальных же условиях получается, чем выше абстракция, тем более ресурсоемко решение задачи в терминах данной абстракции. Но на программирование этого решения затрачивается меньше человеческого ресурса (сравним размер моей подписи с размером реализации алгоритма быстрой сортировки в любом классическом императивном языке).

Таким образом, говоря о некоторой прогрессивной по отношению к чему-либо абстракции (если таковая, конечно, имеется), нужно сразу же делать ряд оговорок: человеческая ресурсоемкость построения программы; машинная ресурсоемкость выполнения программы. И исходя уже из конкретной решаемой задачи и указанных оговорок решать, шаг ли это вперед или назад.

 Это все проблемы несовершенства сред разработки и компиляторов. Если достигнут отставания по скорости от ассемблера порядка 10% и будет достаточно функциональная библиотека, то уже ни кто не посмотрит в сторону классических языков. Я же говорю, что это пока что дело будущего. Пока, не преодолеют все эти трудности толку будет мало! Но за этим будущее.

То есть вся линейка последовательных абстракций от ассемблера до того же Пролога например будет размещаться на интервале от 100% до 90%?


Это сообщение отредактировал(а) Artemios - 7.12.2006, 03:31

Да, всеохватывающая тема, сейчас по всему пробежимся   

в этом отношении как раз и хорош С++: абстракций хоть отбавляй при довольно приличной (даже хорошей) кодогенерации (чего стоит один boost разрулить)

С++ - безусловно, великий язык. Он велик своей универсальностью, на нем можно решать диаметрально противоположные задачи, пусть зачастую и не так комфортно, как на более специализированном языке, но достаточно эффективно. Предоставляя, с одной стороны, предельно низкоуровневые возможности, которые  идеально подходят для решения задач системного программирования, он допускает и более высокоуровневый подход, годящийся для широкого круга прикладных задач, в т ч таких специфичных, как программирование ИИ. Но, увы, в этой универсальности кроется сильная зависимость от соотношения между уровнем абстракции и вычислительными ресурсами, которые необходимы для реализации данного уровня абстракции. Одним словом, сегодня, когда "космические корабли бороздят просторы Вселенной", то бишь стандартом для рабочей станции является зверь-машина с двухъядерным процом и гигабайтом оперативы на борту, эффективность использования языка С++ для решения болшинства прикладных задач уже находится под вопросом. Это - реальность, и не признавать это сегодня нельзя.
Что произойдет с этим языком в дальнейшем? Будет ли его уделом исключительно системное программрование, откуда его точно никто вытеснить не сможет, пока жива архитектура фон-Неймана? Трудно сказать. Многое зависит и от следующих редакций стандарта. Страуструп и Ко, безусловно, просто так не сдадут этот язык. Уже обсуждалась возможность введения в стандарт сборщика мусора (если и не реализации, то по крайней мере ее спецификации). Большие надежды на комитет boost.



Lisp - в той же мере императивный язык, насколько и функциональный. ООП в современных реализациях Lisp'a поддерживается лучше, чем в С++ и приближается к Smalltalk. Например, там есть мультиметоды, для реализации которых в C++ (и не только) придумали целый паттерн. И никаких dynamic_cast и instance of не нужно . GUI писать на лиспе тяжелее не из-за того, что язык не предоставляет какой-либо возможности, это следствие высокоуровневости языка. 
Кстати, GUI на лиспе делается с помощью биндингов GTK, WxWidgets, Swing и пр. без особых проблем.


Это сообщение отредактировал(а) Амортизатор2 - 7.12.2006, 22:23