Коллеги!

Это просто прикол какой-то. Может, я и обижу кого в лучших чувствах, но вот понаблюдаешь за дискуссиями... (не только на RSDN)

Короче, почему никто ясно, логически не может доказать преимущества C#/Java как языка и как языковой концепции перед C++ как языком? Здесь же простейшие критерии: вот так-то можно сократить объём кода, а вот так-то гарантировать цельность. Бесконечные ссылки на библиотеки, на особенности runtime, "на всех", "на MS", на ещё черт-те кого и что. Заколебался! :maniac:

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

ИМХО, подобные передёргивания появляются от постоянного оболванивания маркетинговыми службами. Ну да фиг с ними — с маркетёрами. Это у них работа такая. Но, ребята, нельзя же о себе любимых забывать! Мы же своими руками косвенно снижаем эффективность и, следовательно, оплату своего труда!

Вот смотрите. И следите за логикой.

Ну, сделай систему, гипертрофированно используя что-то типа if(typeof(x) == TypeY) и сделай в ней новый дополнительный тип. Сколько дополнительной работы по тестированию появится? Много. Или, к примеру, добавить метод в интерфейс (тихо! это не interface, это class X{ void some(void) = 0; }), пусть даже реализуемый на базе уже существующих? Сколько классов придётся перепахать? Вот то-то же. :crash: А следовательно, понадобятся новые проектировщики, документаторы, архитекторы, менеджеры и... да, коллеги, ещё больше программистов. Только вот одна беда: клиент будут платить примерно те же деньги, только вот распределять их придётся среди большо-о-о-ой толпы. А ключ, имхо, один — бузудержный rtti и неспособность базового языка реализации к гибкому манипулированию абстракциями, безотносительно количества их готовых реализаций в данном окружении.

Вот, блин...

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

ГВ>Короче, почему никто ясно, логически не может доказать преимущества C#/Java как языка и как языковой концепции перед C++ как языком? Здесь же простейшие критерии: вот так-то можно сократить объём кода, а вот так-то гарантировать цельность. Бесконечные ссылки на библиотеки, на особенности runtime, "на всех", "на MS", на ещё черт-те кого и что. Заколебался!

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

Например, в C# компилятор строит метаданные для каждого объявления, но доступ к ним идёт через библиотечные функции. По твоей логике, такой возможности в C# нет, т.к. она реализована не на уровне языка. Но на самом то деле такая возможность есть, но я никак не могу привести её в качестве аргумента. Что тогда остаётся? Рассуждать о языковых конструкциях? Но ведь это несколько жалких процентов от того, что необходимо программисту в повседневной работе. Остальное — это знание технологий и библиотек.

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

IT>Здравствуйте Геннадий Васильев, Вы писали:

ГВ>>Короче, почему никто ясно, логически не может доказать преимущества C#/Java как языка и как языковой концепции перед C++ как языком? Здесь же простейшие критерии: вот так-то можно сократить объём кода, а вот так-то гарантировать цельность. Бесконечные ссылки на библиотеки, на особенности runtime, "на всех", "на MS", на ещё черт-те кого и что. Заколебался!

IT>Самое интересное, что в данном случае нет смысла что-то объяснять именно из-за постановки вопроса. Тебе говорят, что язык и его окружение это одно целое,

Именно структура и комбинаторные возможности языка всегда определяют пределы сложности выразимых на нём абстракций, а отнюдь не набор базовых поговорок (библиотек). А как следствие — он определяет образ мышления в смысле тех стереотипов, которыми оперирует разработчик при выборе способа решения задачи (а для нас решение задачи — не что иное, как точная и максимально компактная внутренне согласованная формулировка тех или иных способов преобразования информации). И у C++ этих самых возможностей компактного изложения формулировок на порядок больше, чем у C# + VB вместе взятых. Притом, обрати внимание, что C++ не навязывает готовых парадигм типа событий, GC или boxing.

Собственно говоря, против CLR я ничего не имею. Если C++ на нём появится, то тоже, вероятно, буду его использовать.

IT> ты утверждаешь обратное, следовательно, дальнейшие разговоры бесполезны.

Увы и ах, поскольку у тех кто говорит, что "язык и его окружение..." принципиально неверна исходная посылка. C# до C++ ещё расти и расти.

IT>Например, в C# компилятор строит метаданные для каждого объявления, но доступ к ним идёт через библиотечные функции. По твоей логике, такой возможности в C# нет, т.к. она реализована не на уровне языка.

Истинно так. Это — возможность использования промежуточного описания типа. Но мне этот тип для начала надо построить. О стротиельстве типов — см. выше.

IT>Но на самом то деле такая возможность есть, но я никак не могу привести её в качестве аргумента.

Не можешь. Только — как иллюстрацию.

IT>Что тогда остаётся? Рассуждать о языковых конструкциях?

Да.

IT> Но ведь это несколько жалких процентов от того, что необходимо программисту в повседневной работе.

Да, но эти проценты определяют очень много. ИМХО, это — структурный базис...

IT> Остальное — это знание технологий и библиотек.

Которые можно (и нужно) "завернуть" в структурированное представление о них, и заниматься собственно программой, т.е., вернуться к тем самым "жалким процентам".

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

IT>>Самое интересное, что в данном случае нет смысла что-то объяснять именно из-за постановки вопроса. Тебе говорят, что язык и его окружение это одно целое,

ГВ>Именно структура и комбинаторные возможности языка всегда определяют пределы сложности выразимых на нём абстракций, а отнюдь не набор базовых поговорок (библиотек). А как следствие — он определяет образ мышления в смысле тех стереотипов, которыми оперирует разработчик при выборе способа решения задачи (а для нас решение задачи — не что иное, как точная и максимально компактная внутренне согласованная формулировка тех или иных способов преобразования информации). И у C++ этих самых возможностей компактного изложения формулировок на порядок больше, чем у C# + VB вместе взятых.

Да ну? А как тебе вот такое компактное изложение? Это немного утрированный, но вполне реальный пример из программы использующей одновременно STL, ATL, MFC и #import.

CString fun(std::string s)
{
    return (LPCTSTR)CComBSTR((BSTR)_bstr_t(s.c_str()));
}

Уж накастился я с C++'совыми строками по самое нихачу. При этом подобной проблемы нет ни в C#, ни в VB.

ГВ>Притом, обрати внимание, что C++ не навязывает готовых парадигм типа событий, GC или boxing.

Это как? Ну нет в нём GC, есть хип. Или хип можно навязывать, а GC нет? Нет в C++ событий, нет свойств, да много чего нет. Мне уже надоело распинаться на эту тему и говорить, что эти возможности должны присутствовать в любом современном языке, в противном случае его можно относить к категории устаревших. Был в своё время такой язык PL/1. По богатству возможностей и наворотов ему не было равных. Был он сложен и мощен (так кажется) невероятно, на каждый чих в нём была языковая конструкция, на каждую надобность ключевое слово. Но он вымер, как динозавр, потому что устарел, а развивать его никто не собирался.

ГВ>Собственно говоря, против CLR я ничего не имею. Если C++ на нём появится, то тоже, вероятно, буду его использовать.

Он там давно есть, можешь почитать про это здесь

Автор(ы): Игорь Ткачёв
Дата: 05.02.2002
До сих пор трудно ответить на вопрос, что такое .Net. Эта статья, являясь введением в Managed Extensions for C++ (MC++), содержит описание ряда смелых экспериментов советских ученых, наконец-то позволяющих понять, что же такое .Net вообще, и место MC++ в нем, в частности.

.

IT>> ты утверждаешь обратное, следовательно, дальнейшие разговоры бесполезны.

ГВ>Увы и ах, поскольку у тех кто говорит, что "язык и его окружение..." принципиально неверна исходная посылка. C# до C++ ещё расти и расти.

Ты рассуждаешь как закоренелый теоретик и как человек врядли когда писавший больших программ. Ставлю двадцать против одного, что начинающий студент даст тебе фору в 100 очков, если вы с ним будете писать одну и туже GUI задачу, только он на Дельфи со всеми её возможностями, а ты на pure C++ без каких бы то ни было библиотек (даже CRTL), используя только windows.h. Хотя можно и это отменить. Чистый C++, так читый C++, а чё нам

IT>>Например, в C# компилятор строит метаданные для каждого объявления, но доступ к ним идёт через библиотечные функции. По твоей логике, такой возможности в C# нет, т.к. она реализована не на уровне языка.

ГВ>Истинно так. Это — возможность использования промежуточного описания типа. Но мне этот тип для начала надо построить. О стротиельстве типов — см. выше.

А зачем нужны типы? Просто ради типов? Что ты с ними собираешься делать, печать на принтере и вешать на стенки? Твоя программа должна делать что-то полезное, правильно? На чистом C++ без библиотек ты не сможешь даже вывести "Hello, world!", printf ведь не часть языка, а всего лишь жалкая библиотечная функция.

IT>>Но на самом то деле такая возможность есть, но я никак не могу привести её в качестве аргумента.

ГВ>Не можешь. Только — как иллюстрацию.

Я это уже понял.

IT>>Что тогда остаётся? Рассуждать о языковых конструкциях?

ГВ>Да.

Ok, хотя я и не вижу в этом большого смысла.
В C++ нет свойств. В C# их есть.
В C++ нет событий и делегатов. В C# есть.
В C++ нельзя задать видимость и доступ объекта внутри модуля, в C# можно.
В C++ отсутствует автоматическая сборка мусора, в C# присутствует.
В С++ отсутствуют атрибуты и вообще какие либо зачатки аспектного программирования.
В C++ отсутствует контроль выхода за пределы массивов и вообще контроль доступа к памяти.

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

IT>> Но ведь это несколько жалких процентов от того, что необходимо программисту в повседневной работе.

ГВ>Да, но эти проценты определяют очень много. ИМХО, это — структурный базис...

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

IT>> Остальное — это знание технологий и библиотек.

ГВ>Которые можно (и нужно) "завернуть" в структурированное представление о них, и заниматься собственно программой, т.е., вернуться к тем самым "жалким процентам".

Рапер шо ли написать? А потом это "структурированное представление о них" завернуть ещё в одно структурированное представление и т.п. Так и будем всё заворачивать и разворачивать, а делом кто заниматься будет?

Доброго времени суток,

Тут вот товарищи долго и упорно спорят про то, что лучше С++, Java, .NET или может даже VB. Причём все почему-то упорно забывают про самый главный инструмент программиста... Угадали? Да, это мозг.
И если человек хочет научиться программировать, он должен научиться думать.

Лирическое отступление:
Недавно отсобеседовали кучу студентов в качестве кандидатов на должность разработчика. Все утверждают, что знают С++, опыт разработки, проекты, все дела. НИ ОДИН не смог внятно рассказать про ассоциативные контейнеры, деревья поиска, сортировки и т.п. Я уже молчу про то, как они С++ знали... А ты говоришь кататься (с) не помню

Таким образом, я считаю, что вопрос заключается меньше всего в языке, а больше в тех технологических знаниях которыми программист обязан обладать, если хочет считаться программистом. Я не думаю, что уважаемые оппоненты, спорившие про C++ & Java & C# вообще станут разговаривать с человеком, который не понимает слова "хэш-функция" (к примеру). Никто также не отменял понятия синглетона, контейнера, потока (stream), нитей (thread), синхронизаций и прочее и прочее. Вот откуда нужно копать, по скромному моему мнению. А не спорить, круче GC или убиение объектов вручную.

Слабо составить список "Обязательных Знаний Программиста"?

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

O>Слабо составить список "Обязательных Знаний Программиста"?

"Формальные требования к пишущему программисту"
http://alexm.here.ru/mo.job.talk/novik-formal-req.txt

Это не совсем то что ты хотел, но достаточно близко

Пристите, что без стука.

IT>Да ну? А как тебе вот такое компактное изложение? Это немного утрированный, но вполне реальный пример из программы использующей одновременно STL, ATL, MFC и #import.

IT>

IT>CString fun(std::string s)
IT>{
IT>    return (LPCTSTR)CComBSTR((BSTR)_bstr_t(s.c_str()));
IT>}
IT>

Мда. дерьмо еще то.
А что, было тяжко сделать функцию с сигнатурой:

// ANSI --> BSTR 
BSTR StringToOleStr(const char* source,size_t source_len=-1,
                    bool create_empty=false);

IT>Уж накастился я с C++'совыми строками по самое нихачу. При этом подобной проблемы нет ни в C#, ни в VB.

Сочувствую

[skeep]

IT>Ты рассуждаешь как закоренелый теоретик и как человек врядли когда писавший больших программ. Ставлю двадцать против одного, что начинающий студент даст тебе фору в 100 очков, если вы с ним будете писать одну и туже GUI задачу, только он на Дельфи со всеми её возможностями, а ты на pure C++ без каких бы то ни было библиотек (даже CRTL), используя только windows.h. Хотя можно и это отменить. Чистый C++, так читый C++, а чё нам

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

IT>А зачем нужны типы? Просто ради типов? Что ты с ними собираешься делать, печать на принтере и вешать на стенки? Твоя программа должна делать что-то полезное, правильно? На чистом C++ без библиотек ты не сможешь даже вывести "Hello, world!", printf ведь не часть языка, а всего лишь жалкая библиотечная функция.

согласен.

IT>Ok, хотя я и не вижу в этом большого смысла.
IT>В C++ нет свойств. В C# их есть.
IT>В C++ нет событий и делегатов. В C# есть.
Builder C++

IT>В C++ нельзя задать видимость и доступ объекта внутри модуля, в C# можно.


IT>В C++ отсутствует автоматическая сборка мусора, в C# присутствует.
На вкус и цвет.

IT>В С++ отсутствуют атрибуты и вообще какие либо зачатки аспектного программирования.
Я еще не дорос до этого

IT>В C++ отсутствует контроль выхода за пределы массивов и вообще контроль доступа к памяти.
На вкус и цвет.

IT>Как видишь, любое достоинство C++ можно легко сделать недостатком, смотря с какой стороны на это посмотреть. Я не понимаю зачем вообще нужны эти сравнения, т.к. в реальных задачах всё это может как помогать так и мешать. Всё зависит от задач.
Точно.

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

Одно радует, когда задолбут, C# устаканиться до восприятия моим сознанием

IT>Да ничего они не определяют. Через пол года работы на любом языке (и его окружении) вырабатываются определённые шаблоны и стиль его использования (паттерны, панимаишь), далее эти паттерны применяются не задумываясь для достижения конкретной поставленной цели. На C++ эти паттерны одни, на C# немножко другие, но зачем на них зацикливаться?
Ну, вообщем, да. Паттерны можно выссосать из ритуала посещения сортира.

IT>>> Остальное — это знание технологий и библиотек.

ГВ>>Которые можно (и нужно) "завернуть" в структурированное представление о них, и заниматься собственно программой, т.е., вернуться к тем самым "жалким процентам".

IT>Рапер шо ли написать? А потом это "структурированное представление о них" завернуть ещё в одно структурированное представление и т.п. Так и будем всё заворачивать и разворачивать, а делом кто заниматься будет?
Мда. Гои, конечно

IT>>

IT>>CString fun(std::string s)
IT>>{
IT>>    return (LPCTSTR)CComBSTR((BSTR)_bstr_t(s.c_str()));
IT>>}
IT>>

О, нет
Это из категории, "можно я отрублю ему голову?"

А что запрещало сразу присвоить CString содержимое std::string
К тому же,кажется, в этом изврате могут теряться внутренние нулевые символы s.

Я все правильно напутал ?

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


IT>Это как? Ну нет в нём GC, есть хип. Или хип можно навязывать, а GC нет?

Да пожалуйста, напиши свой распределитель памяти на уровне класса, если не нравиться хип. Создай свои хипы... В чем проблема, у тебя есть возможности управлять размещением объекта.

IT>Нет в C++ событий, нет свойств, да много чего нет.

Только не говори, что сложно эмулировать события... (не поверю). А свойства вообще нафиг не нужны (если очень хочется можешь сделать Set... Put..., да и понятней будет ).

IT>Мне уже надоело распинаться на эту тему и говорить, что эти возможности должны присутствовать в любом современном языке, в противном случае его можно относить к категории устаревших. Был в своё время такой язык PL/1. По богатству возможностей и наворотов ему не было равных. Был он сложен и мощен (так кажется) невероятно, на каждый чих в нём была языковая конструкция, на каждую надобность ключевое слово.

Вот-вот, а ты говоришь свойства, GC, ...

IT>Ты рассуждаешь как закоренелый теоретик и как человек врядли когда писавший больших программ. Ставлю двадцать против одного, что начинающий студент даст тебе фору в 100 очков, если вы с ним будете писать одну и туже GUI задачу, только он на Дельфи со всеми её возможностями, а ты на pure C++ без каких бы то ни было библиотек (даже CRTL), используя только windows.h. Хотя можно и это отменить. Чистый C++, так читый C++, а чё нам...

Остынь...
А по поводу чем пользоваться, забивать гвозди нужно молотком, а пилить пилой. Нет языка на все случаи жизни.

IT>А зачем нужны типы? Просто ради типов? Что ты с ними собираешься делать, печать на принтере и вешать на стенки? Твоя программа должна делать что-то полезное, правильно? На чистом C++ без библиотек ты не сможешь даже вывести "Hello, world!", printf ведь не часть языка, а всего лишь жалкая библиотечная функция.

Если не нравятся типы, пиши на Perl, там с этим проще.

IT>Ok, хотя я и не вижу в этом большого смысла.
IT>В C++ нет свойств. В C# их есть.
IT>В C++ нет событий и делегатов. В C# есть.
IT>В C++ нельзя задать видимость и доступ объекта внутри модуля, в C# можно.
IT>В C++ отсутствует автоматическая сборка мусора, в C# присутствует.
IT>В С++ отсутствуют атрибуты и вообще какие либо зачатки аспектного программирования.
IT>В C++ отсутствует контроль выхода за пределы массивов и вообще контроль доступа к памяти.

Глупо сравнивать языки да еще в таком стиле (у нас есть дома венико-совок, а у нас нет — правда есть веник и совок). Часть вышеприведенного не очень полезно; часть полезно, но легко делается ручками; часть тяжело делается ручками, но иногда и вредно (так GC нужен не всегда); а то что и нужно, и тяжело сделать ручками — такого не много, а если очень надо, возможно есть библиотеки, а возможно лучше сменить язык (не нужно копать микроскопом).

IT>Как видишь, любое достоинство C++ можно легко сделать недостатком, смотря с какой стороны на это посмотреть. Я не понимаю зачем вообще нужны эти сравнения, т.к. в реальных задачах всё это может как помогать так и мешать. Всё зависит от задач.

Согласен...

IT> ... а делом кто заниматься будет? :))

Во-во, чето я отвлекся...

Здравствуйте Аноним, Вы писали:

IT>>Это как? Ну нет в нём GC, есть хип. Или хип можно навязывать, а GC нет?

А>Да пожалуйста, напиши свой распределитель памяти на уровне класса, если не нравиться хип. Создай свои хипы... В чем проблема, у тебя есть возможности управлять размещением объекта.

Зачем, меня и так всё устраивает.

IT>>Нет в C++ событий, нет свойств, да много чего нет.

А>Только не говори, что сложно эмулировать события... (не поверю). А свойства вообще нафиг не нужны (если очень хочется можешь сделать Set... Put..., да и понятней будет ).

Конечно, эмулировать можно всё. Так же можно эмулировать (точнее обходиться) без шаблонов и множественного наследования о котором ГВ не устаёт упоминать. Но он хотел различий в языках, вот вам различия. Насчёт свойства нафиг — это такой же аргумент как и множественное наследование нафиг, т.е. никакой.

IT>>Ты рассуждаешь как закоренелый теоретик и как человек врядли когда писавший больших программ. Ставлю двадцать против одного, что начинающий студент даст тебе фору в 100 очков, если вы с ним будете писать одну и туже GUI задачу, только он на Дельфи со всеми её возможностями, а ты на pure C++ без каких бы то ни было библиотек (даже CRTL), используя только windows.h. Хотя можно и это отменить. Чистый C++, так читый C++, а чё нам...

А>Остынь...
А>А по поводу чем пользоваться, забивать гвозди нужно молотком, а пилить пилой. Нет языка на все случаи жизни.

Странный поворот, разве я говорил обратное?

А>Глупо сравнивать языки да еще в таком стиле (у нас есть дома венико-совок, а у нас нет — правда есть веник и совок). Часть вышеприведенного не очень полезно; часть полезно, но легко делается ручками; часть тяжело делается ручками, но иногда и вредно (так GC нужен не всегда); а то что и нужно, и тяжело сделать ручками — такого не много, а если очень надо, возможно есть библиотеки, а возможно лучше сменить язык (не нужно копать микроскопом).

Понятно. Видимо исходное сообщение прошло мимо и читать мы начали с середины. Тогда я отвечу в твоём же стиле, можно? Ты ошибаешься, если думаешь, что на одном языке нельзя сделать того же, что и на другом. Вопрос лишь в эффективности. К тому же утверждения, что одно вредно, а другое полезно вообще не имеет смысла, т.к. и то и другое может быть как вредно, так и полезно в разных ситуациях.

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

IT>Здравствуйте Геннадий Васильев, Вы писали:

IT>>>Самое интересное, что в данном случае нет смысла что-то объяснять именно из-за постановки вопроса. Тебе говорят, что язык и его окружение это одно целое,

ГВ>>Именно структура и комбинаторные возможности языка всегда определяют пределы сложности выразимых на нём абстракций, а отнюдь не набор базовых поговорок (библиотек). А как следствие — он определяет образ мышления в смысле тех стереотипов, которыми оперирует разработчик при выборе способа решения задачи (а для нас решение задачи — не что иное, как точная и максимально компактная внутренне согласованная формулировка тех или иных способов преобразования информации). И у C++ этих самых возможностей компактного изложения формулировок на порядок больше, чем у C# + VB вместе взятых.

IT>Да ну? А как тебе вот такое компактное изложение? Это немного утрированный, но вполне реальный пример из программы использующей одновременно STL, ATL, MFC и #import.

IT>

IT>CString fun(std::string s)
IT>{
IT>    return (LPCTSTR)CComBSTR((BSTR)_bstr_t(s.c_str()));
IT>}
IT>

Ну, наутрировано по самое некуда. :) А инлайновые функции-конвертеры уже отменены? ИМХО, это — пример дурного стиля программирования, который неправомерно обобщается как обязательный для C++.

IT>Уж накастился я с C++'совыми строками по самое нихачу. При этом подобной проблемы нет ни в C#, ни в VB.

А откуда ей там взяться при единых-то типах?

ГВ>>Притом, обрати внимание, что C++ не навязывает готовых парадигм типа событий, GC или boxing.

IT>Это как? Ну нет в нём GC, есть хип. Или хип можно навязывать, а GC нет?

От хипа можно отказаться или переписать — это раз. Можно сделать частные альтернативы — два. Никакой проблемы. Сам так делал неоднократно.

IT>Нет в C++ событий, нет свойств, да много чего нет. Мне уже надоело распинаться на эту тему и говорить, что эти возможности должны присутствовать в любом современном языке, в противном случае его можно относить к категории устаревших.

А ещё в C++ нет встроенной обработки списков, поддержки реляционной логики, прямой трансляции из UML... :maniac:
Действительно, список можно продолжить, однако ниже ты сам приводишь аргументы против подобной эклектики.

IT> Был в своё время такой язык PL/1. По богатству возможностей и наворотов ему не было равных. Был он сложен и мощен (так кажется) невероятно, на каждый чих в нём была языковая конструкция, на каждую надобность ключевое слово. Но он вымер, как динозавр, потому что устарел, а развивать его никто не собирался.

Так вот C++ может потому и не умирает, что не следует за веяниями моды? А вот каким путём C# последует?

ГВ>>Собственно говоря, против CLR я ничего не имею. Если C++ на нём появится, то тоже, вероятно, буду его использовать.

IT>Он там давно есть, можешь почитать про это здесь

Автор(ы): Игорь Ткачёв
Дата: 05.02.2002
До сих пор трудно ответить на вопрос, что такое .Net. Эта статья, являясь введением в Managed Extensions for C++ (MC++), содержит описание ряда смелых экспериментов советских ученых, наконец-то позволяющих понять, что же такое .Net вообще, и место MC++ в нем, в частности.

.

Это я читал. Очередное корёженье C++. Ну неймётся ни MS ни Borland, кстати. :maniac:

IT>>> ты утверждаешь обратное, следовательно, дальнейшие разговоры бесполезны.

Кстати, знаешь, я понял. Я утверждаю не "обратное", а "перпендикулярное". Спор и на самом деле превращается в софистику. Ниже мои рассуждения есть.

ГВ>>Увы и ах, поскольку у тех кто говорит, что "язык и его окружение..." принципиально неверна исходная посылка. C# до C++ ещё расти и расти.

Ниже я попытался разобрать твоё высказывание.

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

Оппонент явно пытается перейти "на личности", т.е., в данном случае — унизить меня. Видимо, корректные аргументы исчерпаны? Я хотел поспорить с нижесказанным, но просто проанализирую высказывания на предмет их логической корректности.

Вероятно, термин "закоренелый теоретик" является унизительным, и должен заставить меня стушеваться, а характеристика: "вряд-ли когда писавший больших программ" должна выглядеть логическим выводом. Уместно было бы потребовать описаний "закоренелого теоретика" и того, кто "вряд-ли".

IT>Ставлю двадцать против одного, что начинающий студент даст тебе фору в 100 очков, если вы с ним будете писать одну и туже GUI задачу,

Вот в этом: "одну и туже GUI задачу" — ключ к пониманию понятия "направомерное обобщение". Сразу возникает вопрос: какую GUI-задачу? Каковы её цели/задачи/перспективы/сроки/бюджет/окружение/...? Каковы требования к качеству? Всё бы ничего, но таким простым и нечестным, кстати, приёмом можно запутать почти любого собеседника.

IT>только он на Дельфи со всеми её возможностями, а ты на pure C++ без каких бы то ни было библиотек (даже CRTL), используя только windows.h. Хотя можно и это отменить. Чистый C++, так читый C++, а чё нам :super:

Странно, :) было бы логично при такой постановке вопроса предложить и от компилятора отказаться. Ну, собственно, в контексте предыдущего неправомерного обобщения эта фраза выглядит уже чистой воды риторикой или лозунгом. А риторику как и лозунги опровергать не следует...

IT>>>Например, в C# компилятор строит метаданные для каждого объявления, но доступ к ним идёт через библиотечные функции. По твоей логике, такой возможности в C# нет, т.к. она реализована не на уровне языка.

ГВ>>Истинно так. Это — возможность использования промежуточного описания типа. Но мне этот тип для начала надо построить. О стротиельстве типов — см. выше.

IT>А зачем нужны типы? Просто ради типов? Что ты с ними собираешься делать, печать на принтере и вешать на стенки? Твоя программа должна делать что-то полезное, правильно? На чистом C++ без библиотек ты не сможешь даже вывести "Hello, world!", printf ведь не часть языка, а всего лишь жалкая библиотечная функция.

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

Но я, кажется, наконец-то понял суть наших противоречий. Это как спор между Эрудицией (набором деталей) и Интеллектом (способностью эти детали выделять и структурировать). Спорить можно бесконечно. Поясню: структура языка (в данном случае — программирования) — это интеллектуальный базис, на основе которого синтезируются производные структуры, а синоним эрудиции в данном случае — набор библиотек, т.е., готовых решений. Что из них "нужнее" — ответ на этот вопрос целиком зависит от контекста, в том числе и психологического. ИМХО, упование только на эрудицию уводит в одну сторону — бесконечного поиска конкретной детали, а упование только на интеллект — в другую, в поиск только теоретического решения. Друг без друга эти две области, на самом-то деле человеческой деятельности — бессмысленны.


Но тем не менее, я, например, полагаю, что поиск способа оптимального воплощения решения задачи — интеллектуальная задача, а определение конкретных способов её воплощения — тут уже полностью привлекается эрудиция. И вот что интересно — усечение структурной основы языка (в данном случае я имею ввиду C# по сравнению с C++) — автоматически "загружает" интеллектуальную составляющую, например, требованием решения задачи без привлечения механизма множественнного использования реализаций. Я имею ввиду множественное наследование и опять-таки шаблоны, будь они неладны :) Отсюда следует, что при решении задачи подобного класса сразу возникает необходимость учитывать дополнительные накладные расходы либо искать замену возможному решению. Вот, кстати, почему я не люблю искорёженные реализации C++. Получается, что вместо того, чтобы выпустить развитый инструмент интеллектуального решения задач производители компиляторов загружают разработчиков огромным числом деталей — в частности, конкретными "глюками" своих компиляторов. Стандарт-то на самом деле — логичен, но бесконечные отклонения в конкретных случаях приводят к тому, что разработчики начинают винить не производителей, а сам язык. Т.е. — неправомерно обобщать.

[...]

IT>>>Что тогда остаётся? Рассуждать о языковых конструкциях?

ГВ>>Да.

IT>Ok, хотя я и не вижу в этом большого смысла.

IT>В C++ нет свойств. В C# их есть.

Если надо, то можно сделать. Вопрос — зачем? То что это есть "везде" — не аргумент (вернее — неправомерный аргумент). Решение каких задач упрощается введением свойств на уровне базового языка?

IT>В C++ нет событий и делегатов. В C# есть.

Можно сделать, если понадобится. Это несложно.

IT>В C++ нельзя задать видимость и доступ объекта внутри модуля, в C# можно.

O'K. Покажи примеры использования? Хотя на C++ подобные штуки элементарно делаются манипулированием директивой "include".

IT>В C++ отсутствует автоматическая сборка мусора, в C# присутствует.

Да, но можно сделать оптимально подходящую под задачу схему упраления памятью — раз, и избежать проблем производительности, связанных с мотанием managed — объектов по памяти — два.

IT>В С++ отсутствуют атрибуты и вообще какие либо зачатки аспектного программирования.

O'K. Поясни, для чего оно нужно?

IT>В C++ отсутствует контроль выхода за пределы массивов и вообще контроль доступа к памяти.

Библиотеки, идиомы...

IT>Как видишь, любое достоинство C++ можно легко сделать недостатком, смотря с какой стороны на это посмотреть. Я не понимаю зачем вообще нужны эти сравнения, т.к. в реальных задачах всё это может как помогать так и мешать. Всё зависит от задач.

См. мой комментарий выше. Но, ИМХО, — золотые слова.

IT>>> Но ведь это несколько жалких процентов от того, что необходимо программисту в повседневной работе.

ГВ>>Да, но эти проценты определяют очень много. ИМХО, это — структурный базис...

IT>Да ничего они не определяют. Через пол года работы на любом языке (и его окружении) вырабатываются определённые шаблоны и стиль его использования (паттерны, панимаишь), далее эти паттерны применяются не задумываясь для достижения конкретной поставленной цели. На C++ эти паттерны одни, на C# немножко другие, но зачем на них зацикливаться?

Вот-вот, а тем более — делать эти паттерны существенно важной и необходимой деталью языка и языкового окружения... :maniac:

IT>>> Остальное — это знание технологий и библиотек.

ГВ>>Которые можно (и нужно) "завернуть" в структурированное представление о них, и заниматься собственно программой, т.е., вернуться к тем самым "жалким процентам".

IT>Рапер шо ли написать? А потом это "структурированное представление о них" завернуть ещё в одно структурированное представление и т.п. Так и будем всё заворачивать и разворачивать, а делом кто заниматься будет? :))

НЕТ, не Wrapper! :crash: Я имел ввиду структурированное понимание (или структурную интерпретацию), — т.е., сугубо человеческий аспект, от которого и пляшешь хоть в сторону Wrapper-а, хоть куда угодно. :super:

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

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

O>>Слабо составить список "Обязательных Знаний Программиста"? :)

A>"Формальные требования к пишущему программисту"
A>http://alexm.here.ru/mo.job.talk/novik-formal-req.txt

Особенно мне понравилось про умение писать по-русски :)

A>Это не совсем то что ты хотел, но достаточно близко

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

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

ГВ>Оппонент явно пытается перейти "на личности", т.е., в данном случае — унизить меня. Видимо, корректные аргументы исчерпаны?

Они не исчерпаны, они просто не восринимаются никак.

ГВ>Но я, кажется, наконец-то понял суть наших противоречий. Это как спор между Эрудицией (набором деталей) и Интеллектом (способностью эти детали выделять и структурировать). Спорить можно бесконечно. Поясню: структура языка (в данном случае — программирования) — это интеллектуальный базис, на основе которого синтезируются производные структуры, а синоним эрудиции в данном случае — набор библиотек, т.е., готовых решений. Что из них "нужнее" — ответ на этот вопрос целиком зависит от контекста, в том числе и психологического. ИМХО, упование только на эрудицию уводит в одну сторону — бесконечного поиска конкретной детали, а упование только на интеллект — в другую, в поиск только теоретического решения. Друг без друга эти две области, на самом-то деле человеческой деятельности — бессмысленны.

Суть наших противоречий в том, что ты считаешь, что язык основа всех основ и вполне самодостаточная вешь. Я же считаю, что язык всего лишь часть той системы, которую программист использует для решения своих задач. И, например, C++ и C# бесполезно сравнивать в твоём контексте, т.к. многие вещи в последнем тесно интегрированы с Framework.

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

По-этому, возвращаясь к твоему исходному постингу, а именно

Короче, почему никто ясно, логически не может доказать преимущества C#/Java как языка и как языковой концепции перед C++ как языком?

я ещё раз могу повторить, что это не имеет смысла.

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

ГВ>Коллеги!

ГВ>Это просто прикол какой-то. Может, я и обижу кого в лучших чувствах, но вот понаблюдаешь за дискуссиями... (не только на RSDN)

ГВ>Короче, почему никто ясно, логически не может доказать преимущества C#/Java как языка и как языковой концепции перед C++ как языком? Здесь же простейшие критерии: вот так-то можно сократить объём кода, а вот так-то гарантировать цельность. Бесконечные ссылки на библиотеки, на особенности runtime, "на всех", "на MS", на ещё черт-те кого и что. Заколебался! :maniac:
А шо непонятно ? Разницу между вином и виноградным соком надо объяснять приводя химические, спектральные, и прочие анализы в качестве аргументов ? Попей вина, и ты прозреешь... ;)

ГВ>То есть, всё время получается спор о цельных системах программирования с их библиотеками, рантаймами, комами, ещё вагоном интегрированных возможностей. Но притягивать к C++ понятие "система программирования" — это же просто бред! C++ — это язык общего назначения. Налицо постоянные передёргивания и подмены понятий. Нет, я не против того, чтобы поспорить о системах программирования, которые сами по себе сразу предназначены для решения определённых задач и несут определённые предположения о характере этих задач. Но это нельзя сопоставлять с языком как таковым.
Я тоже не против, вот только бы за это еще деньги платили...

ГВ>ИМХО, подобные передёргивания появляются от постоянного оболванивания маркетинговыми службами. Ну да фиг с ними — с маркетёрами. Это у них работа такая. Но, ребята, нельзя же о себе любимых забывать! Мы же своими руками косвенно снижаем эффективность и, следовательно, оплату своего труда!
Объясни пожалуйста, как и в чем снижается эффективность ? Или ты хочешь сказать, что теперь за тоже время ты сделаешь больше, получив денег как обычно ? ;)

ГВ>Вот смотрите. И следите за логикой.
Посмотрим что будет лет через 5ть, может ты и прав, пиши на C++, и когда все поймут что С# это не то, у тебя будут библиотеки, классы и прочее... Сорвешь кучу гринов... ;)

ГВ>Ну, сделай систему, гипертрофированно используя что-то типа if(typeof(x) == TypeY) и сделай в ней новый дополнительный тип. Сколько дополнительной работы по тестированию появится? Много. Или, к примеру, добавить метод в интерфейс (тихо! это не interface, это class X{ void some(void) = 0; }), пусть даже реализуемый на базе уже существующих? Сколько классов придётся перепахать?
А сколько кода было написано на чистом C, и ничего, перешли на C++.

ГВ>Вот то-то же. :crash: А следовательно, понадобятся новые проектировщики, документаторы, архитекторы, менеджеры и... да, коллеги, ещё больше программистов. Только вот одна беда: клиент будут платить примерно те же деньги, только вот распределять их придётся среди большо-о-о-ой толпы.
Клиент покупает продукт, и платит он не толпе, а тому у кого купил. Почему купил, это уже к маркетологам... :)

ГВ>А ключ, имхо, один — бузудержный rtti и неспособность базового языка реализации к гибкому манипулированию абстракциями, безотносительно количества их готовых реализаций в данном окружении.
Круто, только как то непонятно... :shuffle:

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

A>>"Формальные требования к пишущему программисту"
A>>http://alexm.here.ru/mo.job.talk/novik-formal-req.txt

ГВ>Особенно мне понравилось про умение писать по-русски

Да да, иногда в конфах такие сообщения встречаются...

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

O>Доброго времени суток,

O>Тут вот товарищи долго и упорно спорят про то, что лучше С++, Java, .NET или может даже VB. Причём все почему-то упорно забывают про самый главный инструмент программиста... Угадали? Да, это мозг.
O>И если человек хочет научиться программировать, он должен научиться думать.

O>Лирическое отступление:
O>Недавно отсобеседовали кучу студентов в качестве кандидатов на должность разработчика. Все утверждают, что знают С++, опыт разработки, проекты, все дела. НИ ОДИН не смог внятно рассказать про ассоциативные контейнеры, деревья поиска, сортировки и т.п. Я уже молчу про то, как они С++ знали... А ты говоришь кататься (с) не помню

К сожалению, ты не прав. Работодателю всегда важен результат, т.е. конечный продукт, приложение. Ты можешь долго объяснять ему в чем достоинства того или иного алгоритма сортировки, но если ты не знаешь как писать приложение, как
лабать код — он тебя не возмет. Студентам, выпускникам тоже есть хочеться и начать зарабатывать они могут лишь тогда когда выучат С++,С# или VB на худой конец.

Это крутым дядям, с устоявшимся авторитетом и жизненной позицией необходимо знать такие вещи, но не молодым специалистам!

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

O>>И если человек хочет научиться программировать, он должен научиться думать.
Таки здесь не спорим, так?

O>>Лирическое отступление:
O>>Недавно отсобеседовали кучу студентов в качестве кандидатов на должность разработчика. Все утверждают, что знают С++, опыт разработки, проекты, все дела. НИ ОДИН не смог внятно рассказать про ассоциативные контейнеры, деревья поиска, сортировки и т.п. Я уже молчу про то, как они С++ знали... А ты говоришь кататься (с) не помню

А>К сожалению, ты не прав. Работодателю всегда важен результат, т.е. конечный продукт, приложение. Ты можешь долго объяснять ему в чем достоинства того или иного алгоритма сортировки, но если ты не знаешь как писать приложение, как
А>лабать код — он тебя не возмет. Студентам, выпускникам тоже есть хочеться и начать зарабатывать они могут лишь тогда когда выучат С++,С# или VB на худой конец.

А ты доверишь свои зубы дантисту, который отличить коренной зуб от молочного не может? Который научился держать сверло (ну или как там оно называется, брр) с нужного конца, а вот как им ворочать толком еще не знает?
Закажешь ли ты дизайн интерьера своей квартиры человеку, который начитался модных журналов, а об эргономике пространства не слыхал?

Почему-то многие склонны относиться к программированию (и процессу производства ПО тоже) как к чему-то, где можно халявить, "так сойдёт", потом исправим, главное сдать и т.п. Не понимаю. Хочешь быть хорошим программистом — учись. Долго, нудно, упорно. На кошечках тренируйся. Пиши бесплатный open-source, подскажут, помогут, поправят. А если просто "кушать хочется" — вагоны грузить или прокладками торговать. Ибо нечего ламерство разводить.

А>Это крутым дядям, с устоявшимся авторитетом и жизненной позицией необходимо знать такие вещи, но не молодым специалистам!

Всем надо знать, всем. Ибо если кто-нибудь из моей команды в production code при частых вставках в начало и отсутсвию необходимости прямого доступа попользует массив вместо списка — он будет уволен. Или отправлен читать книжки, писать тесты, разбираться в основах. А иначе так и будем встраивать в компиляторы защиту от переполнения буфера (vc7), вместо того чтобы учиться писать хорошо.

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

IT>Короче, почему никто ясно, логически не может доказать преимущества C#/Java как языка и как языковой концепции перед C++ как языком?

IT>я ещё раз могу повторить, что это не имеет смысла.

Надо открыть конференцию "Битвы языков" :)) А что касается языков и библиотек — рекомендую еще раз прочитать п.2.8 и 3.1 "Язык программирования С++", третье издание, автор известен. Там, IMHO, исчерпывающее обобщение.

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

O>Доброго времени суток,

O>Лирическое отступление:
O>Недавно отсобеседовали кучу студентов в качестве кандидатов на должность разработчика. Все утверждают, что знают С++, опыт разработки, проекты, все дела. НИ ОДИН не смог внятно рассказать про ассоциативные контейнеры, деревья поиска, сортировки и т.п. Я уже молчу про то, как они С++ знали... А ты говоришь кататься (с) не помню

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

Могу сказать на ваше замечание на счет головы. ДА ГОЛОВА очень очень важна...
И оппоненты очень уважаемые...

ТОлько не забывайте о реальности. А реальность, в том, что деньги на корм и подключение к интернету надо зарабатывать.

///синглетона, контейнера, потока (stream), нитей (thread), синхронизаций и прочее и прочее

человек ! Которыей знает, что это !!!! Дае тебе господь клиентов, которые знают, ЧТО ОНИ ХОТЯТ!

Не сталкивадись с тем как в течение одного проекта ТЗ меняется 3 (три) раза.
Хотелось бы посмотреть на то, что вы скажете если у вас в первом варианте есть логическая связка данные-интерфейс
и серьезная логика обработки любого ввода пользователя через штук эдак 50 диалоговых окон и малюсеньких окошек.

Там вам и списки и потоки... и синхронизация...

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

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

O>Слабо составить список "Обязательных Знаний Программиста"?

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

O>Всем надо знать, всем. Ибо если кто-нибудь из моей команды в production code при частых вставках в начало и отсутсвию необходимости прямого доступа попользует массив вместо списка — он будет уволен.

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