BZ>>представьте себе ассемблер с ООП расширениями, шаблонами, клозурами, монадами, примитивами синхронизации и т.д. смешно? было бы смешно, если б не было близко к правде. С появился как язык системного программирования, высокоуровневый ассемблер, и именно благодаря своей эффективности, близости к железу он завоевал симпатии в мире ранних мини-компьютеров и персоналок, с их скромными ресурсами

A>Теперь не применительно только к этой фразе а вывод в общем. Каждый инструмент создается as main concept для определенных задач. Кто то ниже говорил "разделять сервер и морду". Я совершенно с этим согласен и как видишь даже в бессмысленный спор не вступаю. Вопрос лишь в том кто будет морду реализовать.
A>Я прекрасно представляю ассемблер с шаблонами и примитивами синхронизации, но и вы представте C# в виде монстра, который решает не только задачи прикладного програмирования, а еще и будет перекручен конструкциями с определенными unmanaged оговорками для свободного манипулирования ресурсами под уровень ядра, либо все таки МС придется извратится чтобы все возможные варианты изобразить MSIL компилером. Все равно это будут не логичные для его контекста описания. Вообщем заметьте Г. получается как с одной, так и с другой стороны. Не нужно все это.
A>Пускай C++ занимается задачами в своем стиле и не нужно ему всего что касается managed расширений. Человек, который не хочет следить за ресурсами сам, либо не умеет оперировать типами, пускай не лезет в ++ (это не характеризует недостатки языка). При правильном архитектурном подходе, я поверь мне уже практически избавился от страшных снов связанных с этим, абсолютно. Каждый инструмент требует определенных навыков, опыта и мозгов. Кесарю, кесарево. Железная истина. Для прикладников языки другие.

что C# с unmanaged code, что C++ с его managed расширениями типа smart pointers — это фактичсеки два разных языка за цену одного

можно считать, что я пошёл ещё дальше и весь прикладной код пишу на хаскеле, а низкоуровневый — на C++ и не требую ни от того, ни от другого языка неестественных для него трюков. что касается арзитектурного подхода, то я тоже когда-то отладивал C с помощью printf'ов. можно чему угодно обезьяну научить но всё же лучше потратить силы на то, чтобы научиться писать более сложные программы с современными языками, нежели учиться делать несложные вещи, которые становятся сложными из-за устаревшего инструментария


BZ>>в 80-х ...

A>Хватит о них. Мне 33 и я помню о них прекрасно. По моему до сих пор в обсуждении остались только люди, которые хоть как то ориентируются во всем этом флейме, не воспримите за оскорбление.

вы в 80-е программировали? да ещё и отслеживали все события в мире компилтяоров?? я-то просто недавно надыбал dr dobbs за эти годы и с удовольствием отследил борьбу и языков, и компиляторов. кол-во компиляторов C, паскаля и модулы было тогда практически одинаковым — 5 модул, шутк 6-7 Си. ну и ещё интерсено вспомнить, что С++ пошёл только потому, что разработчики были уверены, что на нём можно будет писать программы не медленней, чем на C


BZ>>однако когда речь доходит ло прикладного программирования и эффективность оказывается не главным, тут С++ напоминает Винни-Пуха, который прикидывался тучкой в языке нет GC и type-safe generic references, синхронизации, клозур и т.п. ну и фиг с ним! мы всё это сэмулируем! в результате чего есть язык С++, содержащий массу конструкций, которые прикладному программисту просто не следует использовать, и многочисленные бибилиотеки, которые худо-бедно эмулируют возможности, напрямую встроенные в другие, более современные языки

A>Вот и пускай будут они туда встроены. !!!! О БОЖЕ, мы наконец приходим к тому, к чему с самого начала стремились.
A>1. Я счастлив, что простому прикладнику наконец сделали инструменты, которые позволяют меньше думать и больше работать, но это отнюдь не означает что С++ плох. Ему просто все эти расширения не нужны.
A>2. Если человек владеет С++ — это должно четко обозначать что он в состоянии за время не меньшее, чем прикладник с помощью своего инструмента, может эмулировать все те вещи о которых мы говорим.
A>Для меня это кристальная истина. Все остальные лишь используют язык, в каких то узких целях, который им возможно и не нужен.

давайте это по-другому выразим. спец C++ , по-вашему — это человек, который в несколько раз дольше учился, в несколько раз больше работает, и в конечном счёте получает ровно то же, что и спец в более современно языке? "товарищ сержант, ну можно я веником подмету?"

знаете, что меня к хаскелу привело? я вроде тоже неплохой спец по C++ был, мой арзиватор arjz широко известен в узких кругах. и прикинув, на что больше всего времени тратится при разработке архиватора, я решил, что с (тогдашним) С++ мне не по пути. нужны гибкие структуры данных с мощными возможностями по их обработке, нужны клозуры, весьма желателен gc. C++ — по своей сути просто препроцессор, генерящий чисто императивный код, какая-нибудь фиговина типа map+sort без промежуточных переменных уже способна повергнуть его в ступор.

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

затем на руби, в нём замечательная объектная модель, клозуры, но язык всё же динамический со всеми вытьекающими отсюда ненадёжностью, медленностью и т.д.

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

я собственно не так давно поработал ведущим программистом в асу тп конторе, мы писали как раз на BC 3.1 под контроллеры. мне неинтересно на этом C++ писать — слишком примитивный язык, многие проблемы приходится решать путём тупого копирования кода. поэтому я только раздавал руководящие указания а на хаскеле мне писать интересно, поскольку уровень языка соответствует уровню моего мышления — то, что мне легко вообразить, легко записать и на хаскеле. я не зря те три примера хаскеловского кода приводил — они напрямую описывают то, как я вижу решение задачи. ну вот возьмите хоть это:

-- |this function finds last space in String within 80-char boundary
len_f = last . filter (<80) . findIndices (==' ')

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

то есть хаскелл соответствует тому, как я думаю. я на нём не вгоняю себя в рамки искусственной дисциплины, не "эмулирую все те вещи", не "избавляюсь от стращных снов". я просто творю, естественно и прямолинейно. человек должен работать, машина думать — так, кажется, говорят в ibm?


A>В языке достаточно минимально необходимых примитивов для эмуляции чего угодно. Все что нельзя сделать, неправильно концептуально спроектировано

это вы про машину Тьюринга?


A>То что язык развивается в сторону метапрограммирования на базе шаблонов — это совершенно логичесное и естественное развитие языка данного уровня.

высокоуровневого ассеблера? да. но для написания эффективных программ шаблоны особо и не нужны, а для написания прикоадных программ лучше испольщзовать более высокоуровневые средства. у макросов, даже в таком виде, свои недостатки — сообщения об ошибках, отсутствие run-time поддержки, время компиляции


BZ>>вот поэтому вы и need a complex language — чтобы созранить совместимость с кодом 30-летней давности, сгенерить как можно более эффективную программу, а затем попытаться как-то сэмулировать современные языки.

A>Что вы так пристали к этой совместимости. Она остается до сих пор только потому, что нет смысла язык наворачивать не свойственными ему вещами изначально.
A>Если для вас совместимость главный критерий, то для меня абсолютно. Я уже ранее говорил, что в определеной степени владения языком нет проблем в эмуляции того о чем мы говорим. Просто кто то — это сделает быстрее, а кто то не сделает вообще и то что язык требует более высокого уровня skills — это не недостаток его, а лишь характеристика.

совместимость с BCPL — это ограничитель развития самого C++. ну ни к чему в один язык тащить все aborb? которые когда-либо были изобретены. а когда тащат и начинают всё вместек совмещать, "эмулировать" — тогда и выходит коктейль из switch'a с лямбдой


BZ>>я тут выше приводил пару примеров кода в хаскел, напиши их аналоги в С++ и сравни сам. если вместо изучения всех этих legacy features и методов эмуляции modern features изучать напрямую современный язык, то ты здорово сэконишь во времени изучения и затем во времени написания/отладки кода.

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

ну с таким подходом мы вообще должны сами проектировать кмпьютер для решения каждой новой задачи — гибче некуда. ИНДУСТРИЯ программирования развивается в сторону того, чтобы выделить паттерны, обобщить их и внести в методолгию/язык/whatever. это повышает призводительность труда, а производительность труда, по Марксу — это мерило степени развития общества помню, как мне один амер в 90-х говорил "не занимайся ассемблерной оптимизацией, брось бяку!", а я ему не верил сейчас я вам говорю то же самое, сыны мои

РАЗВИТИЕ ПРОГРАММИСТА ОПРЕДЕЛЯЕТСЯ УРОВНЕМ ЗНАНИЯ СОВРЕМЕННЫХ ТЕХНОЛОГИЙ, А НЕ СПОСОБНОСТЬЮ СЭМУЛИРОВАТЬ ИХ ЧЕРЕЗ СТАРЫЕ. по очень простой причине — деньги. быстрее делаешь программу — длиннее деньги. а для интереса я и сам с удовольствием C++ со всеми его наворотами прочту (но зазубривать не стану, и не просите )


BZ>>именно об этом я и говрю — что в С++ thread-safe программирование требует специального изучения и в job offers, например, указывается как отдельное требование чтобы понять, насколько это смешно, представьте себе скажем требование "умение вызывать функции рекурсивно". это тоже может специальным умением в языке типа Фортрана, где это не поддерживалось

A>Сравнивать "рекурсивный вызов" и "thread-safe" — это все равно что в правах на вождение автомобиля указывать уровень владения самокатом. Давайте не опускаться до такого уровня. Человек ничего не знающий о потоках и разделяемых ресурсах и в C# репу перегреет такими понятиями как ThreadMutex и т.д.

ха! вот тут-то я вас и подловлю. прежде всего — вы представляете, какого уровня знаний требует рекурсвиное порграммирование на фортране IV? для рекурсивного вызова нужно завести по массиву на каждую локальную переменную, и хранить номер текущего используемого индекса в этом массиве. затем нужно обеспечить переход к нужной части порцедуры при вовзрате. но это ещё фигня — предствьте себе взаиморекурсивные вызовы нескольких порцедур!!! нынешние пограммисты и не подозревают, как много им сил сэкономили компиляторы

а теперь посмотрите как записывается многопоточная программа на хаскеле:

-- Thread, который в цикле читает команды из потока и исполняет их
graphThread c = do cmd <- getChan c
                   cmd
                   graphThread c

-- Создаёт graphThread и посылает ему команды на исполнение
main = do с <- newChan
          forkOS $ graphThread c
          putChan c (print "Hi")
          tid <- forkOS $ putChan c (print "Hi from other thread")
          putChan c (print "Bye")
          waitThread tid

а теперь скажите, что легче — написать рекурсивную программу на фортране, или многопоточную, с автоматичсекой синхронизацией и разделением ресурсов — на хаскеле? и стоит ли хаскелловскому порграммисту указывать умение писать такие порграммы как отдельный скилл?


это кстати пример из реальной жизни. одному моему знакомому понадобилось такое написать, когда выяснилось, что граф. библиотека умеет принимать команды только из одного потока, а ему потребовалось посылать их из нескольких. в данном случае различные треды посылают потоку graphThread колманды print, а он их по очереди выполняет. и как этот человек мне писал — он был просто поражён тем, как элементарно оказалось в этом разобраться и запрограммировать

у меня было аналогично. когда я решил присобачить к своему арзиватору read-ahead, опережающее чтение файлов в отдельном от упаковки треде, я потратил неделю. на то, чтобы во всём этом разобраться, и чтобы осознать, КАК это просто будет сделать. у меня просто мозги этого не совпринимали, как и ваши наверно сейчас разобравшись, я сделал за день, там строк 40 кода всего понадобилось. а вот ни в одлном из других арзиваторов этого до сих пор нет. почему? наверно, потому, что они все на C++ написаны

то же самое относится и ко многим другим архиваторным фичам. у меня более интеллектуальная сортировка, разбиение на солид-блоки, выбор алгоритма сжатия и т.д. может, Рошаль и Павлов в вашей классификации и не специалисты по C++, но по крайней мере я их по многим фичам обхожу


BZ>>т.е. опять речь о complex language, порождённом тем, что современные концепции программирования в нём — нечто дополнительно прикрученное сбоку с теми самыми километрами художеств

A>Где явное определение того, что так называемый complex language охватывает весь спектр современных концепций и что есть весь спектр современных концепций?
A>Я надеюсь понятно без лишних объяснений почему вам не удастся быть объекивных в этой части вопроса.

а мне кажется — можно multi-threading, GC, лямбды и прочие вещи, которые в других языках есть изначально, и умение пользоваться эмуляцией которых в C++ рассматривается как необходимое условие для устройства на работу