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

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

O>Тут вот товарищи долго и упорно спорят про то, что лучше С++, Java, .NET ...
O>... Вот откуда нужно копать, по скромному моему мнению. А не спорить, круче GC или убиение объектов вручную.

Немного лирики.
Вы несколько упрощённо смотрите на вопрос какой должен программист.
Только ли технические знания его определяют, а как насчёт личных качеств.
И разве Вас, как ведущего программиста, менеджера проекта или руководителя проекта (или какую позицию Вы занимаете в своей компании) не должно интересовать мотивации человека? По какой причине человек собирается работать у Вас (или с Вами) программистом.

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

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

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

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

Вот ещё что.
O>И если человек хочет научиться программировать, он должен научиться думать.
Кто не согласен с этим, два шага вперёд!!!
Но вот побывав на многих собеседованиях в разные времена своей карьеры, я не помню, чтобы кто-то интересовался, умею ли я думать. ( Самому интересно узнать ) Обычно интересуются опытом и техническими знаниями, часто мотивациями. Да и судя по Вашему рассказу, Вы тоже интересовались наличием у соискателем определенных технических знаний, а про умение думать Вы умолчали в своём "лирическом отступлении". Что так?

Ещё раз.
O> И если человек хочет научиться программировать, он должен научиться думать.
...лирическое отступление...
O> Таким образом, я считаю, что вопрос заключается меньше всего в языке, а больше в тех технологических знаниях которыми программист обязан обладать, если хочет считаться программистом.

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

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

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

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

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

А>Я удивляюсь такой приверженности C++. Это ведь всего лишь язык программирования и сравнивать его с естественным языком просто смешно.

Как известно, "язык формирует стиль нашего решения и предопределяет, о чем мы можем думать". В этом плане сравнение вполне уместно.

A> Или, может быть, кто-то думает, что рукой Стауструппа двигал Бог и С++ единственное, что нам дано на века?

Никто не спорит, что С++ несовершенный язык. У Страуструпа, Александреску и Вельдхуйзена много замечаний на этот счет.

A> Подумайте, нужен ли кому то будет С++ через 50 лет, и если нет, то не начался ли процесс его отмирания уже сейчас. И где вы увидели уничтожение "комплексных средств языка"? Кто их уничтожает и каким образом? Если вы имеете ввиду, что Микрософт продвигает C# вместо С++, так это их право. Если С++ настолько крут, то происки MS окончатся ничем и у вас еще будет время попинать труп C#. И деградация здесь не при чем. С++ не решает проблем, все должен делать программист вплоть до мелочей. Возможно, кому то это нравится, как есть люди, которым нравится писать на ассемблере, но я предпочитаю декларативный стиль программирования, когда тебя не беспокоят мелочи, о которых заботится компилятор,

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

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

Пример: активная библиотека Blitz++.

Оборотная сторона: написание нетривиальных качественных библиотек на плюсах слишком сложная задача. Иногда это объясняют тем, что С++ не был изначально предназначен для производящего программирования.

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

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

Таким образом, С++ — замечательный, в некоторых отношениях уникальный язык.

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

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


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

Итак, ни кого не удивлю, если скажу что русский язык один из самых сложных в мире, и дожив почти до 30 лет я так и
не научился граммотно выражать свои мысли, строить всевозможные языковые конструкции, иногда путаюсь с падежами,
а главное за хорошее знание столь сложного языка не платят баксы, фунты, марки и евро.
Единственным выходом в создавшейся ситуации я вижу изменение непокорного языка ( упаси господи ),
упрощение языковых конструкций, сокращение словарного запаса до необходимого минимума, отмена механизма принятого
в нашем языке словообразования и т.д. Предлагаю высказаться всех участников спрора по данной теме: что же
эти изменения сулят нам, какие блага и несчастья получим мы взамен.
На мой взгляд — ничего хорошего, интеллектуальная единица общества будет обделена, уравнена с общей серой массой,
не будет необходимости совершенствоваться в умении выражать СВОЮ мысль, а не сетовать на отсутствие в
языке некоторых специальных конструкций и обозначений, упрощающих этот процесс.
Возможно что мы потеряем важнейшие черты русской нации, те, которыми мы обладаем благодаря нашему богатому
словарному запасу. Никто не задумывался, почему например в английском многие предложения строятся
на основе глагола "иметь" хотя не только на русском гораздо естесственнее выразится посредством глагола "быть"?
Что за странная подмена понятий, да еще и с таким важным для русской души понятием как "бытие". В иврите,
например слова богатство и счастье произносятся одинаково ( различия в написании ), точного перевода слова
"самопожертвование" вообще не существует
( для информации, израильский солдат попавы в плен имеет право выдавать все военные тайны государства,
это не наказывается ), ну и наконец попытайтесь обяснить иностранцу точный смысл слова "убогость" ( краеугольный камень
русской ментальности и сострадания, один из базисов всего Православия )...
Вот такое вот мнение по-этому спору, попрошу высказаться.

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

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

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

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

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

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

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>> Остальное — это знание технологий и библиотек.

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

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

Здравствуйте 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:

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


А>Можно и С++ обсудить. Если я правильно понял, целью твоих рассуждений по поводу русского языка было провести аналогию с С++. Но право, смешно сравнивать язык программирования, где каждая конструкция и каждое слово имеют совершенно конкретный смысл, и естественный язык, где зачастую, чтобы понять предложение надо почуствовать его в целом и может быть множество толкований одной и той же фразы. Но даже такая сомнительная аналогия не работает, поскольку люди, в основном, говорят на примитивном русском и ко всем возможностям языка прибегают редко, если не никогда. Есть, безусловно, таланты, которые прекрасно владеют языком, но нам, простым смертным, на них не равняться. Так же и с С++, пусть "интеллектуалы" топчут клаву, пытаясь выжать из C++ все, что можно. А в обычной жизни можно обойтись и C#.
Я ничего не сравниваю, а провожу аналогии, другими словами параллели между двумя ситуациями. Что касается отдельных конструкций и служебных слов — мне абсолютно наплевать нужен ли брейк в свитче или кто то решит это упростить, а вот речь идет о гораздо более серьёзных вещах — об уничтожении комплексные средства языка, которые в свою очередь позволяют реализовывать расширенные возможности и конструкции самого языка, предлагается кастрировать а в замен дать встроенные фенечки и примочки, которые со временем могут и сами устареть.

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

Коллеги!

Это просто прикол какой-то. Может, я и обижу кого в лучших чувствах, но вот понаблюдаешь за дискуссиями... (не только на 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>Да ну? А как тебе вот такое компактное изложение? Это немного утрированный, но вполне реальный пример из программы использующей одновременно STL, ATL, MFC и #import.

IT>

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

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


а это кто виноват что ты бибилиотек наворотил три разу? неужели с++ ? ))

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

Ну язык то тут не причем !!!! Все дело в технологии...

Имхо — для кросс платформенности есть java, для нормального прикладного программирования есть c++, и RAPID средства...Для системного — assembler

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

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

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


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

Здравствуйте 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> Остальное — это знание технологий и библиотек.

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

Здравствуйте 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 нужен не всегда); а то что и нужно, и тяжело сделать ручками — такого не много, а если очень надо, возможно есть библиотеки, а возможно лучше сменить язык (не нужно копать микроскопом).

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

Здравствуйте 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 при частых вставках в начало и отсутсвию необходимости прямого доступа попользует массив вместо списка — он будет уволен.

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

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

[...]

I>Не сталкивадись с тем как в течение одного проекта ТЗ меняется 3 (три) раза.

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

I>Хотелось бы посмотреть на то, что вы скажете если у вас в первом варианте есть логическая связка данные-интерфейс

Объясни, что означает в данном случае: "логическая связка данные-интерфейс"? Где данные, где интерфейс, есть ли между ними ещё что-то? Как размещна прикладная логика?

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

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

I>Переделывать одни элементы управления на другие (сразу чего он хочет он не мог сказать) и вся эта стройность рассыпается и превращается в кучу заплат.

Вот здесь можно поточнее?

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

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

Риторика...

I> а студенты это не самые потерянные люди, раз здали сопромат, значит и про список выучат...

Согласен ;) Главное — чтобы хотели.

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

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

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

Бесспорно. :super: Только я думаю, что используемый язык и его характеристики как средства выражения мыслей и способа компактного документирования программы — очень немаловажная вещь. :shuffle: А отсюда и топик появился.

[...]

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

:) Стану, если он не знает, но хочет знать. А вот если и не хочет знать, да ещё и считает это всё глупым теоретизированием... :crash: ИМХО, здесь очень большая проблема для всей нашей индустрии зарыта.

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

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

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

Вот не надо передёргивать :-\
Там стоит "И" (and, && ), а при частых вставках в начало массив сильно проигрывает в производительности списку. Спорить о структурах данных можно также долго, как и о языках :down: , можно обсудить проблемы фрагментации памяти при работе со списками и массивами, в отдельной ветке :)

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

IT>>>

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

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

Хм. В воскресенье утром моей первой мыслью было _UNICODE.
IT, черт тебя за ногу, это что — поддержка компиляции UNICODE и ANSI программ?

Или это был поток оторванного сознания?

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

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

ГВ>[...]

ГВ>Объясни, что означает в данном случае: "логическая связка данные-интерфейс"? Где данные, где интерфейс, есть ли между ними ещё что-то? Как размещна прикладная логика?

Ясно, что это недостаток в программе. Связка возникает , когда логика (или математика) очень простая но настроек по обработке и выводу данных очень много. Получается, что если хочешь зделать "как бы межплатформенный код" то такого кода будет ну — 20 — 30 % это максимум.
Остальное это взять из элементов управления их состояние записать в глобальные переменные или в члены классов и затем прогнать алгоритм отображения данных снова, что бы "настройки" вступили в силу.
50 % кода — оптимизация перерисовки.
20 % грамотный опрос элементов управления и т.д.
10 % сохраниение в базу данных или еще куда. (оно же чтение)
20-30 % сами мозги проги.

С фантазией у пользователей все впорядке, они в состоянии такого навыдумывать, что только успевай записывать. Вот и получается, что реально настройки программы — это состояние этих самых Box — ов и TextBoxov и т.д.

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


ГВ>Просто почти все, с кем мне приходилось сталкиваться, почти всегда делают одну и ту же концептуальную ошибку, избыточно "сращивая" логику интерфейса и логику приложения (вот я навоевался со своими коллегами MFC-шниками!). А потом вопиют по поводу того, что гад-заказчик потребовал поменять TextBox на ComboBox. Ну, это я не в твой адрес.

Это фигня... сечас у нас задача быстренько Excel переписать. Надоумили связаться с MFCGridCtrl...
Табличка ничего себе, но вот юзеры увидали что — то знакомое и сразу применили весь свой опыт после "Office для чайников"...

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

ГВ>Риторика...

Не, не риторика...
У заказчика ТЗ пишет такойже IT — шник как и я , ну только постарше и уже не может он писать проги. Надоело.
А вот принимает работу Big Shot/ Он компа то кроме как у секретарши на столе на видел ни где.
А согласований сколько А внедрение !!! У там начальства разной степени некомпетентности до 5 человек на одного исполнителя !!!! (САМ считал чуть не запил с горя.) И каждый хочет показать как он во всем разбирается и замечание делать умеет.
В общем ОТДЕЛИТЬ SALES от DEVELOPMENTA ////!!!!!!!!.

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

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

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

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

I>ТОлько не забывайте о реальности. А реальность, в том, что деньги на корм и подключение к интернету надо зарабатывать.
Мне это удаётся, если вопрос в этом. Но зарабатывать на булку с маслом можно и собирая бутылки на улицах...

I>///синглетона, контейнера, потока (stream), нитей (thread), синхронизаций и прочее и прочее
I>человек ! Которыей знает, что это !!!! Дае тебе господь клиентов, которые знают, ЧТО ОНИ ХОТЯТ!

С клиентами нужно работать, а не ожидать маны небесной. Некоторые делают это интуитивно, некоторые "воспитывают" клиентов. Есть в конце концов более или менее формальные подходы (RUP, XP, MSF, PSP/TSP, etc), в которых всегда так или иначе присутствует фаза (стадия, процесс) анализа. И спецификации (Т3) составляются совместно. Вероятность и частота изменения Т3 в основном (но не только) зависит от профессионализма аналитика и условий бизнеса клиента. Если меняются условия — тут уж деваться некуда, спасти может только продуманная и гибкая архитектура или напряжённый труд

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

Бывало и хуже.

I> а студенты это не самые потерянные люди, раз здали сопромат, значит и про список выучат...
Никто не говорит о потерянных, просто я почему-то на первом курсе ФФ НГУ уже знал всё это, потому что хотел знать. А многие не знают и не хотят учиться. Считают, что это вполне нормально. Я против тех студентов, которые хотят больших денег в "IT индустрии" но нифига учиться не хотят, а не против тех, кто еще не знает...

Я понятно выразился на этот раз?

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

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

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

O>Вот не надо передёргивать

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

O>Там стоит "И" (and, && ), а при частых вставках в начало массив сильно проигрывает в производительности списку. Спорить о структурах данных можно также долго, как и о языках , можно обсудить проблемы фрагментации памяти при работе со списками и массивами, в отдельной ветке

Правильно, не будем

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

КД>Хм. В воскресенье утром моей первой мыслью было _UNICODE.
КД>IT, черт тебя за ногу, это что — поддержка компиляции UNICODE и ANSI программ?

Да какой там юникод?

Вот, например, ты пишешь MFC GUI приложение, следовательно имеешь CString, с которым работают все MFC'шные классы.

Дальше ты решил сделать это приложение сервером автоматизации, да не кастрированным MFC'шным, а настоящим ATL'ым. Значит ты уже имеешь и CComBSTR.

Теперь ты хочешь работать например с БД через ADO и #import. Получите _bstr_t.

Ну до кучи добавить STL с std:string и вот вам нате весь этот зоопарк в полный рост.

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

IT>Здравствуйте Коваленко Дмитрий, Вы писали:

КД>>Хм. В воскресенье утром моей первой мыслью было _UNICODE.
КД>>IT, черт тебя за ногу, это что — поддержка компиляции UNICODE и ANSI программ?

IT>Да какой там юникод?

Аааа. Я просто по старой памяти — если IT что-то сказал, значит это серьезно. Ну и стал искать скрытый смысл

У меня в программах std::string std::wstring BSTR и AnsiString (из VCL) вполне мирно ужиываются. Главное выбрать из них главных .

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

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

[]
O>Никто не говорит о потерянных, просто я почему-то на первом курсе ФФ НГУ уже знал всё это, потому что хотел знать. А многие не знают и не хотят учиться. Считают, что это вполне нормально. Я против тех студентов, которые хотят больших денег в "IT индустрии" но нифига учиться не хотят, а не против тех, кто еще не знает...

O>Я понятно выразился на этот раз?

нет, а че ты против студентов имеешь? Ты препод что-ли? Я не пойму!
хотят учиться, не хотят.
Жизнь заставляет учить WinAPI, СОМ, SQL и проч. а не алгоритмы быстрой сортировки или поиска подстроки в строке. Да, это круто, когда человек это знает. Но если он не знает как открыть файл или создать окно, я разговаривать с ним даже не буду. И это правильная буржуйская позиция. Платят за то, что приносит конкретные результаты. Я не призываю к тому, что надо забить на алгоритмы. Сам сейчас читаю "Алгоритмы: построение и анализ" Т. Кормена и сотоварищей. Мне это очень интересно. Но до этого я получается программистом не был?

В общем, кроме необоснованного гона на молодежь, в твоих сообщениях ничего и нет.

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

А>Жизнь заставляет учить WinAPI, СОМ, SQL и проч. а не алгоритмы быстрой сортировки или поиска подстроки в строке. Да, это круто, когда человек это знает. Но если он не знает как открыть файл или создать окно, я разговаривать с ним даже не буду. И это правильная буржуйская позиция. Платят за то, что приносит конкретные результаты. Я не призываю к тому, что надо забить на алгоритмы. Сам сейчас читаю "Алгоритмы: построение и анализ" Т. Кормена и сотоварищей. Мне это очень интересно. Но до этого я получается программистом не был?

А>В общем, кроме необоснованного гона на молодежь, в твоих сообщениях ничего и нет.

Да ты не нервничай так. По большому секрету скажу что деньги системным архитекторам платят больше чем программерам. Так что и WinAPI, COM, SQL тоже не круто. Вон дотнент грядет — и где после этого будут ком и винапи?

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

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

хъ

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

ну вот они и пусть будут обязаны знать все это!

AVK>Так что и WinAPI, COM, SQL тоже не круто. Вон дотнент грядет — и где после этого будут ком и винапи?

Там же где и были.

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

AVK>>Да ты не нервничай так. По большому секрету скажу что деньги системным архитекторам платят больше чем программерам.
А>ну вот они и пусть будут обязаны знать все это!

Ты прям оппортунист какой то.

AVK>>Так что и WinAPI, COM, SQL тоже не круто. Вон дотнент грядет — и где после этого будут ком и винапи?

А>Там же где и были.

Да нет, сейчас они пока еще используются весьма активно

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

O>>Никто не говорит о потерянных, просто я почему-то на первом курсе ФФ НГУ уже знал всё это, потому что хотел знать. А многие не знают и не хотят учиться. Считают, что это вполне нормально. Я против тех студентов, которые хотят больших денег в "IT индустрии" но нифига учиться не хотят, а не против тех, кто еще не знает...

А>нет, а че ты против студентов имеешь? Ты препод что-ли? Я не пойму!

Не препод, но потенциальный потребитель кадров :)

Факт №1. Большинство ищущих работу летом — студенты.
Факт №2. Большинство студентов сами не понимают, чего они хотят делать на работе.
Факт №3. Большинство студентов хотят зарабатывать хорошие деньги, независимо от уровня их знаний.

Факты, конечно, очень спорные, но это то, что я наблюдаю сегодня на рынке.
Мне плевать на факт №1 — мне не важно студент он или нет. Я смотрю на основные две вещи — текущий уровень знаний и желание (вперемешку со способностью) оными знаниями овладевать.
Факт №2 настораживает, но не напрягает. Когда очередной кандидат совершенно теряется при вопросе "чем бы тебе хотелось заниматься" — я всерьез задумываюсь о его судьбе ;) Ответы типа "делать всё, чтобы приносить пользу компании" — слишком размыты. Ответы типа "писать крутые проги и стать кулхацкером" — ну сами понимаете :)
Факт №3 является, скорее всего, следствием мифа о легкости и крутости программирования (и производства ПО) совместно с общим понижающимся (увы) уровнем программистов и повышенным вследствие этого самомнением выпускников и студентов.

Надеюсь не сильно заумно сказал :)

А>хотят учиться, не хотят.

Ты лично хочешь?

А>Жизнь заставляет учить WinAPI, СОМ, SQL и проч. а не алгоритмы быстрой сортировки или поиска подстроки в строке. Да, это круто, когда человек это знает. Но если он не знает как открыть файл или создать окно, я разговаривать с ним даже не буду. И это правильная буржуйская позиция. Платят за то, что приносит конкретные результаты. Я не призываю к тому, что надо забить на алгоритмы. Сам сейчас читаю "Алгоритмы: построение и анализ" Т. Кормена и сотоварищей. Мне это очень интересно. Но до этого я получается программистом не был?

Жизнь заставляет...
Заставляет не жизнь, а вытекающая из желания кушать потребность в деньгах, причём немаловажную роль играет предрасположенность человека к той или иной деятельности. В конце концов существет много профессий, не одними программистами... WinAPI, COM, SQL и прочее — это лишь одна мелкая "гранька" всего многообразия информации в нашем деле. "Буржуйская" позиция тоже бывает разная, не зря же есть PARC, research центры в Microsoft, IBM, Intel и прочих гигантах. И уж там они занимаются отнюдь не winapi... Так что не стоит обобщать до мировых масштабов отдельные затруднения отдельных личностей. А книжка да, не плохая, удачи в познании.

А>В общем, кроме необоснованного гона на молодежь, в твоих сообщениях ничего и нет.

Может быть ты и прав. Но, во-первых, я и сам себя стариком не считаю :) Во-вторых "гон" вполне обоснованный. Раньше (когда и девки были моложе) на 100 человек называющих себя программистами находилось 60 грамотных, умных, опытных "бойцов". Сейчас и десятка не наберётся. Так может происходит девальвация самого термина "программист"?

Скажи, пожалуйста, вот например Вася Пупкин, написавший для своей странички на PHP (ASP, perl, по вкусу) обработку формы "напешите мне што вы думаити пра мой сайт" — программист?

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

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


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

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

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

А вот здесь возникает вопрос, внимательно ли ты ознакомился со стандартом C#. Считать его урезанным вариантом С++ неправильно. В C# есть очень много такого чего нет в C++. А вырезано из него не очень много. Я считаю что выкинули именно мусор.
Приведи примеры чего не очень хватает в C# и есть в C++.
Выкинули переопределения некоторых операторов наподобии ->. Но их нехватка как то не замечается.

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



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

Программы выглядят более стройно, меньше мусора в программе. И для визуальных инструментов облегчается жизнь, (хотя визуальные инструменты вещь второстепенная).

IT>>В C++ нет событий и делегатов. В C# есть.
ГВ>Можно сделать, если понадобится. Это несложно.

"Можно сделать" — такие аргументы не принимаются (Сделать можно и на ассамблере), главное что уже сделано.
Кстати очень сомневаюсь, что на C++ можно сделать события с такой-же функциональностью, как в C#.
К примеру, с наружи класса в котором определено событие, единственное что можно сделать с событием это добавить- убрать обработчик-делегат. Внутри класса можно вызвать обработчики событий. На С++ если такие события сделать то получется очень криво.


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

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

А если внутри одного класса надо объявить другой класс с атрибутом доступа private, чтобы он был невидим снаружи. И например, чтобы внутренний класс мог видеть private поля и функции внешнего класса? Как на C++ такое сделать?

К тому-же с include связано другое важное концептуальное отличие C++ в пользу C#.
Ошибочна идея что, некая сущность должна быть сначала объявлена, а использоваться может только ниже по тексту программы — Это удобно только для разработчиков компиляторов. Даже в C++ эту проблему частично решили — внутри класса порядок обявления методов не играет роли. А с объявлениями самих классов проблема не решена. И это сильно портит жизнь разработчиков.

IT>>В С++ отсутствуют атрибуты и вообще какие либо зачатки аспектного программирования.
ГВ>O'K. Поясни, для чего оно нужно?
Это долго объяснять. Да и в C# это пока, только на зачаточном уровне.

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


O>Не препод, но потенциальный потребитель кадров :)

O>Факт №3 является, скорее всего, следствием мифа о легкости и крутости программирования (и производства ПО) совместно с общим понижающимся (увы) уровнем программистов и повышенным вследствие этого самомнением выпускников и студентов.

Не могу сказать что я потребитель кадров но позволю себе откоментировать эти высказывания.

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

Знаете, что сечас золотое дно??? Это автоматизация бух учета. 4 подразделения по стране — франчайзинг 1С заработали намного больше чем бригада аналитиков, которые писали сервер для опроса телемеханики!
Те кто работает с 1С — ну это максимум БЭЙСИК. Програмерами их назвать трудно. Но они окупаются. И готовить просто и нанимать за дешево ...

А сейчас висит контракт — документо оборот по инженерной системе — слияние баз данных + телемех + немного экономики

Проект шлифуют уже 2 месяца человек 10. Напильниками дорабатывают. Там архитектуру словно Фидий проектировал. Афинский храм будет. :-) Заметте ни каких дельфей при реализации нет. :-)...

На 20 листов умных мыслей + столько же картинок с проектом интерфейса.

Так вот ВСЕ можно решить с помощью VC++.

НО так как маштабируемость и сроки исполнения весьма критичны, то решат использовать всякие хитрые технологии.

На случай будущей межплатформенности (вдруг линух все победит??) Писать интерфейсы будут либо на J++ либо на еще чем-то, о чем 6 мес. назад я даже не слышал.
Но логику софта на J++ не написаить. VC++ — одно решение.

Будет и COM и DCOM и черте что, так как у клиента телемех весь на них сидит.
Документы будут с помощью OLE в word сразу отправляться. (не забудте о макросах на VB)
До сих не ясно как с web сервера запускать API на компе клиента который лезет на сервер, Решений масса, но что выберут мне пока не сообщили.

В общем на проект ТРИВИАЛЬНЫЙ !!!! Уже неоднократно решенный. Применят 5 или 6 технологий. ВСЕ отностиельно новые — отностельно VC++.
Полно аналогов существующих в мире, но для русского клиента не адаптированных, поэтому и заказали.
Но как эта солянка сборная будет работать ????

ГДЕ бойцы??? Даже за деньги спецов нельзя нанять.

Программистов — уже давно нет. есть SOFTWARE engineers... То есть ремесленник COM технологий.
Слесарь по HTML. и т. д.

Кем вы хотите стать ???? Вы спрашиваете нового сотрудника.
Наверное правильный ответ скоро будет такой как у работника автомастерсткой.
"Вначале буду рихтовать кузва запоров, а потом меня повысят на BMW"...


O>Может быть ты и прав. Но, во-первых, я и сам себя стариком не считаю :) Во-вторых "гон" вполне обоснованный. Раньше (когда и девки были моложе) на 100 человек называющих себя программистами находилось 60 грамотных, умных, опытных "бойцов". Сейчас и десятка не наберётся. Так может происходит девальвация самого термина "программист"?

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

O>>Не препод, но потенциальный потребитель кадров

O>>Факт №3 является, скорее всего, следствием мифа о легкости и крутости программирования (и производства ПО) совместно с общим понижающимся (увы) уровнем программистов и повышенным вследствие этого самомнением выпускников и студентов.

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

Не скажи. Если ты можешь позволить себе "купить" хорошие кадры — ты их найдёшь. Предложи мне $5k в месяц, комфортные условия труда, возможность обучения и исследований и я всерьёз задумаюсь над этим предложением А если приму — вкалывать буду ого-го
Дальнейшее обсуждение этого вопроса выношу в отдельную ветку в форуме "Работа".

[ золотое дно поскипано ]

I>ГДЕ бойцы??? Даже за деньги спецов нельзя нанять.
Можно. Только нужны ли тебе бойцы?
У меня была одно время назад команда из 14 отличных "бойцов". Вот только трудности возникают там, где нужен не боец, а просто хороший трудяга. Не всегда нужна команда альфа, спецназ и т.п. Иногда нужно просто хорошо сделать дело. См. далее ту же ветку.

I>Программистов — уже давно нет. есть SOFTWARE engineers... То есть ремесленник COM технологий.
I>Слесарь по HTML. и т. д.

I>Кем вы хотите стать ???? Вы спрашиваете нового сотрудника.
I>Наверное правильный ответ скоро будет такой как у работника автомастерсткой.
I>"Вначале буду рихтовать кузва запоров, а потом меня повысят на BMW"...

Когда-то проводил SWOT-анализ вышеупомянутой команды. Сложилась картина альфа-команды В анализе в разделе "Opportunities" была строчка "Подъём завалов", которая тут же естественно рифмовалась со строчкой "Завал подъёмов"

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

SS>К тому-же с include связано другое важное концептуальное отличие C++ в пользу C#.
SS>Ошибочна идея что, некая сущность должна быть сначала объявлена, а использоваться может только ниже по тексту программы — Это удобно только для разработчиков компиляторов. Даже в C++ эту проблему частично решили — внутри класса порядок обявления методов не играет роли. А с объявлениями самих классов проблема не решена. И это сильно портит жизнь разработчиков.

А еще в шарпе проблема циркулярных ссылок решена кардинально, они допустимы.

... Янус v1.0alpha (только для тестовых целей)

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

Я бы перекинул тему, но что то неохота, нить диалога потеряю.

ЛЕГЕНДА О $5k.

Золотого дна НЕ БУДЕТ.

Дьявол в деталях.

$5k. — в Лондоне — не вопрос... Ты индус по национальности?
если да — то куда отправить резюме — мест 20 наверное есть.

Знаешь индусы пишут там — НУ в индии, за одно и в ЛОНДОНЕ ядро... То бишь основной софт.
За это из около $5k. и платят. Ну только побываешь в том месте где это все пишется, сразу поймешь почему 98% населения ЛОНДОНА это "британцы". Ты просто не сможешь пробится туда. Там все немного темнокожие и любят только своих. А на родине ЗИТЫ и ГИТЫ программисты за еду работают. Ты с ними не сможешь конкурировать, если только не станешь трудится за 500 уе. Для них перевод в ЛОНДОН — это мечта !!!! Они с семьями и тещями и зятями и т.д. едут и едут...

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

А как я уже сказал на разработке индусы... То есть теоретически я есть должен рис и по праздникам масло мазать на хлеб.

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

!!!!!____________________ есть только одна зона — это разработка операционок и интернет решений. Там индусы слабоваты.
А все что с математикой связано и со сложной логикой, модельным софтом. К сожалению данная область вне моей компенетции. Сам занимаюсь прикладным ПО.

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

<skipped>

I>На случай будущей межплатформенности (вдруг линух все победит??) Писать интерфейсы будут либо на J++ либо на еще чем-то, о чем 6 мес. назад я даже не слышал.
I>Но логику софта на J++ не написаить. VC++ — одно решение.

Что есть J++ Вы в курсе? О какой межплатформенности J++ может идти речь? Ж))
J++ -- это изобретение MS даже близко не стоит с реальной многоплатформенностью Sun Java 2 Platform (EJB знаете?). J++ только для Windows и поделок вроде апплетов.

Сервера приложений давно и успешно пишутся на Java2 Enterprise Edition, а о C/C++ даже речи не идёт -- слишком критично и дорого обходится слежение за утечками памяти(чтобы их не было). Конечно, для маленьких контор всё едино, т.к. проекты небольшие. Ну не оправдывает себя трудоёмкость написания кода на C/C++ для серверов приложений. Всё идёт к тому, чтобы переложить ответственность за управление памятью на среду исполнения, в частности, на Garbage collector -- трудоёмкость написания приложений уровня предприятия уменьшается на 30-40%.
В этом направлении двигаются и Java, и .Net :user:

I>Будет и COM и DCOM и черте что, так как у клиента телемех весь на них сидит.

Унаследованные системы, понимаешь... :)

I>Документы будут с помощью OLE в word сразу отправляться. (не забудте о макросах на VB)

??? :))
Я думаю, будет что-то независимое от платформы, типа XML!

I>До сих не ясно как с web сервера запускать API на компе клиента который лезет на сервер, Решений масса, но что выберут мне пока не сообщили.

API чего?
А надо ли(риторический вопрос)?

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

[...]

SS>Это мнение понятно. В таком "перпендикулярном" направлении тоже имеет смысл рассматривать языки. Нельзя не согласиться, что языковые возможности вещь важная. Например VB6 со своей навороченой компонентно-ориентированной средой некоторые задачи позволяет решить проще, эффективнее чем на C++ (программа с аналогичной функциональностью стоит дешевле). Но (пусть это слишком грубо сказано) VB6 это все-таки убогий язык, с точки зрения языковых возможностей.

OK, вот я и предлагал рассмотреть именно возможности C# как языка, в отвязке от его окружения. А получилось, что вопрос в принципе неправомерен, поскольку C# не может существовать без части абстракций, реализованных "за пределами". Но! Эти абстракции представляют собой языковые конструкции. Чуешь разницу? В принципе, да, C++ тоже не может существовать вне компилятора, но всю стандартную библиотеку можно из него убрать и заменить своей. Ну, пусть это и не самый распространённый вариант, но принципиальная возможность всегда остаётся. Для C# такой возможности нет в принципе. ИМХО, Java в этом смысле — более цельный язык.

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

SS>А вот здесь возникает вопрос, внимательно ли ты ознакомился со стандартом C#. Считать его урезанным вариантом С++ неправильно. В C# есть очень много такого чего нет в C++. А вырезано из него не очень много. Я считаю что выкинули именно мусор.

Вот тут я не согласен, поскольку впечатление мусора, ИМХО, складывается за счёт того, что компиляторы C++ вносят кучу своеобразных искажений в C++, как в концепцию ;), а отсюда — ругань, но уже в адрес C++, как языка.

Поимаешь... Всё, что пока приводилось в пользу C# как языка, пока говорит либо о развитых библиотеках, возможности которых интегрировны в язык, либо о сильном поощрении RTTI.

SS>Приведи примеры чего не очень хватает в C# и есть в C++.

Множественное наследование, шаблоны — набившие оскомину примеры.

SS>Выкинули переопределения некоторых операторов наподобии ->. Но их нехватка как то не замечается.

ИМХО, подобные улучшения как раз и уничтожают целостность. Смотри, те же делегаты, например, с точки зрения C# — классы, но sealed. ИМХО, связано это на самом деле с тем, что аналогичной конструкции нельзя сделать с помощью языковых средств C#, и часть реализации делегатов выполнена на чём-то ещё (MSIL или C++ — без разницы). И, кстати, это подтверждается тем, что C# не содержит оператора, аналогичного operator() [я не имею ввиду кастинг]. Ну, то есть, скобки-то есть, но перекрыть их, похоже, нельзя.

SS>А по поводу Templates и множественного наследования здесь не все так просто, хотя в с++ это были полезные вещи.
SS>Templates прикрутить к C# можно даже пытались, но их концепция плохо стыкуется с динамичностью языка (темплейты по большому счету это все таки препроцесная обработка текста программы перед компиляцией).

Ну да, и ориентированы они именно на статическую систему типов.

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

SS>Программы выглядят более стройно, меньше мусора в программе. И для визуальных инструментов облегчается жизнь, (хотя визуальные инструменты вещь второстепенная).

OK, понял. То есть, компактности кода ради... На C++ не всегда получается компактно выразить свойства... Хотя за многие "грехи" C++ имеет смысл винить только MSVC.

IT>>>В C++ нет событий и делегатов. В C# есть.
ГВ>>Можно сделать, если понадобится. Это несложно.

Скажем так, не очень сложно ;), если речь идёт о введении новой идиомы во framework разработки.
http://www.rsdn.ru/forum/message.asp?mid=91643&amp;only

Автор: Геннадий Васильев
Дата: 28.08.02

SS>"Можно сделать" — такие аргументы не принимаются (Сделать можно и на ассамблере), главное что уже сделано.
SS>Кстати очень сомневаюсь, что на C++ можно сделать события с такой-же функциональностью, как в C#.

Та функциональность, что я сделал — только иллюстрация принципа.

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

Да нет, и это тоже можно повторить, получится описание события вроде event<event_type, owner_type>. Но опять, всё упирается в компилятор...

[...]

SS>А если внутри одного класса надо объявить другой класс с атрибутом доступа private, чтобы он был невидим снаружи. И например, чтобы внутренний класс мог видеть private поля и функции внешнего класса? Как на C++ такое сделать?

А чем friend не годится?

SS>К тому-же с include связано другое важное концептуальное отличие C++ в пользу C#.
SS>Ошибочна идея что, некая сущность должна быть сначала объявлена, а использоваться может только ниже по тексту программы — Это удобно только для разработчиков компиляторов. Даже в C++ эту проблему частично решили — внутри класса порядок обявления методов не играет роли. А с объявлениями самих классов проблема не решена. И это сильно портит жизнь разработчиков.

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

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

IT>Здравствуйте Коваленко Дмитрий, Вы писали:

КД>>Хм. В воскресенье утром моей первой мыслью было _UNICODE.
КД>>IT, черт тебя за ногу, это что — поддержка компиляции UNICODE и ANSI программ?

IT>Да какой там юникод?

IT>Вот, например, ты пишешь MFC GUI приложение, следовательно имеешь CString, с которым работают все MFC'шные классы.

IT>Дальше ты решил сделать это приложение сервером автоматизации, да не кастрированным MFC'шным, а настоящим ATL'ым. Значит ты уже имеешь и CComBSTR.

IT>Теперь ты хочешь работать например с БД через ADO и #import. Получите _bstr_t.

IT>Ну до кучи добавить STL с std:string и вот вам нате весь этот зоопарк в полный рост.

A makrosami tipa A2W i prochimi iz etoy serii pochemu ne pol'zueshsya — dlya etogo ved' i predusmotrenno.
Ih kak i v MFC tak i v ATL primenyat' mojno.

Все это злостный офтопик, ну да ладно... тут еще и оверквотинг светит...

B>Единственным выходом в создавшейся ситуации я вижу изменение непокорного языка ( упаси господи ),
B>упрощение языковых конструкций, сокращение словарного запаса до необходимого минимума, отмена механизма принятого
B>в нашем языке словообразования и т.д. Предлагаю высказаться всех участников спрора по данной теме: что же
B>эти изменения сулят нам, какие блага и несчастья получим мы взамен.


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

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

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


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


B>словарному запасу. Никто не задумывался, почему например в английском многие предложения строятся
B>на основе глагола "иметь" хотя не только на русском гораздо естесственнее выразится посредством глагола "быть"?

"Иметь или быть" ? Это название уже зарезервировано другим автором

B> это не наказывается ), ну и наконец попытайтесь обяснить иностранцу точный смысл слова "убогость" (

По поводу сложностей перевода, понравилось у Довлатова — как перевести выражение
"Все люди — как люди, а ты — как хрен на блюде"

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

точный смысл слова "убогость" ( краеугольный камень
B>русской ментальности и сострадания, один из базисов всего Православия )...
B>Вот такое вот мнение по-этому спору, попрошу высказаться.

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

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

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

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

А>Вот насчет убогости, как краегульного камня нашей ментальности, правильно замечено. Спасибо за это православию.
Я не говорил об убогости, речь шла о точном филосовском СМЫСЛЕ этого слова, глубочайшем смысле, который близок по духу православию. Не помню чьи это слова, но кто то из великих сказал что православие это религия УБОГИХ.

А>Сравнивать русский и английский языки некорректно, слишком они разные. И я не думаю, что англичанин, употребляя have в сложных временах, все время вспоминает о том, что одним из значений этого слова является иметь. Кроме того, "быть" у них тоже задействовано.
Это не я сравниваю, это Эрих Фром( американский ученый философ ) проводит анализ общественного недуга под названием гедонизм, вчастности при помощи анализа языка данного общества. К теме аналитических и эмоциональных языков это отношение не имеет.

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

А>Я не говорил об убогости, речь шла о точном филосовском СМЫСЛЕ этого слова, глубочайшем смысле, который близок по духу православию. Не помню чьи это слова, но кто то из великих сказал что православие это религия УБОГИХ.

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

А>Это не я сравниваю, это Эрих Фром( американский ученый философ ) проводит анализ общественного недуга под названием гедонизм, вчастности при помощи анализа языка данного общества. К теме аналитических и эмоциональных языков это отношение не имеет.

Да, верно. Но есть работы других философов и исследователей (если нужно могу привести ссылки), где показывается показывается связь между языком и мышлением. Точнее сказать то, что язык определяет мышление.
Я читал Фромма на русском и помню, что приводимые там примеры (а были они на русском, разумеется) не выглядели исскуственными, а значит, если следовать Фромму, русский язык ничуть не меньше, чем английский или немецкий ориентирован на "Иметь". Да что говорить, если почитать форум работа сразу будет видно, что люди там постоянно говорят о том, что они стоят столько то или, что должны продавать себя дороже. Овеществление в полном разгаре.

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

[skip]


Мы немного отклонились от темы, хотелось бы все таки обсудить С++.

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

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

B>[skip]

B>
B>Мы немного отклонились от темы, хотелось бы все таки обсудить С++.

B>

Можно и С++ обсудить. Если я правильно понял, целью твоих рассуждений по поводу русского языка было провести аналогию с С++. Но право, смешно сравнивать язык программирования, где каждая конструкция и каждое слово имеют совершенно конкретный смысл, и естественный язык, где зачастую, чтобы понять предложение надо почуствовать его в целом и может быть множество толкований одной и той же фразы. Но даже такая сомнительная аналогия не работает, поскольку люди, в основном, говорят на примитивном русском и ко всем возможностям языка прибегают редко, если не никогда. Есть, безусловно, таланты, которые прекрасно владеют языком, но нам, простым смертным, на них не равняться. Так же и с С++, пусть "интеллектуалы" топчут клаву, пытаясь выжать из C++ все, что можно. А в обычной жизни можно обойтись и C#.

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

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

А>>Вот насчет убогости, как краегульного камня нашей ментальности, правильно замечено. Спасибо за это православию.
А>Я не говорил об убогости, речь шла о точном филосовском СМЫСЛЕ этого слова, глубочайшем смысле, который близок по духу православию. Не помню чьи это слова, но кто то из великих сказал что православие это религия УБОГИХ.

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

P.S. По моему понятия "точный" и "философский" несовместимы.

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

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

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

А>>>Вот насчет убогости, как краегульного камня нашей ментальности, правильно замечено. Спасибо за это православию.
А>>Я не говорил об убогости, речь шла о точном филосовском СМЫСЛЕ этого слова, глубочайшем смысле, который близок по духу православию. Не помню чьи это слова, но кто то из великих сказал что православие это религия УБОГИХ.

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

M>P.S. По моему понятия "точный" и "философский" несовместимы.

Это закономерно. Для православия святые — это ущербные люди, блаженные, они якобы ближе к богу.

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

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

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

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

А>>>>Вот насчет убогости, как краегульного камня нашей ментальности, правильно замечено. Спасибо за это православию.
А>>>Я не говорил об убогости, речь шла о точном филосовском СМЫСЛЕ этого слова, глубочайшем смысле, который близок по духу православию. Не помню чьи это слова, но кто то из великих сказал что православие это религия УБОГИХ.

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

M>>P.S. По моему понятия "точный" и "философский" несовместимы.

А>Это закономерно. Для православия святые — это ущербные люди, блаженные, они якобы ближе к богу.

Да неужели?
Назови ка мне хоть одного ущербного православного святого.

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

M>Назови ка мне хоть одного ущербного православного святого.

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

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

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

M>>Назови ка мне хоть одного ущербного православного святого.

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

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

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

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

B>Что же до людей, то в том то и дело что если не будут слышать нормальный язык, то и стремиться не будут к нормальному уровню, так и будут пользоваться своим скудным словарем из 30 словю Больше всего мне кажется нужно боятся деградации после таких изменений в языке ( каком либо языке вообще ).


Я удивляюсь такой приверженности C++. Это ведь всего лишь язык программирования и сравнивать его с естественным языком просто смешно. Или, может быть, кто-то думает, что рукой Стауструппа двигал Бог и С++ единственное, что нам дано на века? Подумайте, нужен ли кому то будет С++ через 50 лет, и если нет, то не начался ли процесс его отмирания уже сейчас. И где вы увидели уничтожение "комплексных средств языка"? Кто их уничтожает и каким образом? Если вы имеете ввиду, что Микрософт продвигает C# вместо С++, так это их право. Если С++ настолько крут, то происки MS окончатся ничем и у вас еще будет время попинать труп C#. И деградация здесь не при чем. С++ не решает проблем, все должен делать программист вплоть до мелочей. Возможно, кому то это нравится, как есть люди, которым нравится писать на ассемблере, но я предпочитаю декларативный стиль программирования, когда тебя не беспокоят мелочи, о которых заботится компилятор, и можно решать проблему, а не бороться с излишней свободой. И C# это шаг в этом направлении.

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

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

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

M>>>Назови ка мне хоть одного ущербного православного святого.

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

M>Понятие мирных целей у каждого свои. Как и понятие нормальности. И если ущербностью называть отличие от "среднего" человека, то есть от толпы, то все они, безусловно, ущербные.

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

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

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

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

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

M>>>>Назови ка мне хоть одного ущербного православного святого.

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

M>>Понятие мирных целей у каждого свои. Как и понятие нормальности. И если ущербностью называть отличие от "среднего" человека, то есть от толпы, то все они, безусловно, ущербные.

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

Ты логику изучал? Понимаешь разницу между следует и равносильно?
И лично на мой взгляд — "изучать богословие, пыталясь решить проблемы церкви" ни к Богу, ни к религиозности отношения не имеет.

А вообще то это уже оффтопик начался, форум то Философия программирования, а не философия вообще
Посему предлагаю закончить сию тему

Здравствуйте Anton V. Kolotaev, Вы писали:

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

AVK>Как известно, "язык формирует стиль нашего решения и предопределяет, о чем мы можем думать". В этом плане сравнение вполне уместно.

Вы решаете проблемы, думая на С++? Я полагаю, что нет. Хотя согласен, язык программирования подталкивает в определенном направлении. Но сравнивать естественный язык и язык программирования все равно нет смысла. Хотя бы потому, что я могу придумать новый язык программирования и решить проблему на нем. С естественным у вас такое вряд ли выйдет (например попробуйте овладеть языком теории категорий так же быстро, как Java or even C++, а ведь это условно говоря, всего лишь жаргон).

AVK>Вот в том то и прикол, что С++ с мощнейшим механизмом статической типизации можно заставить делать множество семантических проверок на этапе компиляции . Вряд ли есть еще язык, способный сравниться с плюсами в этом.

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

AVK>Оборотная сторона: написание нетривиальных качественных библиотек на плюсах слишком сложная задача. Иногда это объясняют тем, что С++ не был изначально предназначен для производящего программирования.

С этим я согласен.

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

AVK>Таким образом, С++ — замечательный, в некоторых отношениях уникальный язык.

Зато, когда тебе не нужно думать о мелочах, тебе хватит сил на штурм более высоких вершин.

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

Согласен.

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

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

dad>а это кто виноват что ты бибилиотек наворотил три разу? неужели с++ ? ))

Ну построй мне GUI приложение на MFC, которое использует MS Office как сервер автоматизации, в качестве доступа к БД — ADO, само является сервером автоматизации и использует кое-что написанное на всеми обажаемом stl Потом расскажешь как ты сопрягал CString полученный из MFC контролов со строками прочитанными из MS Word.

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

dad>Ну язык то тут не причем !!!! Все дело в технологии...

Кажется именно это я и пытаюсь доказать.

dad>Хотя конечно — уборка памяти наличие совместимых библиотек и прочее и прочее — сведенное в единую библиотеку — становится (напрашивается) на новый язык... и писать на нем удобно и комфортно ....Не зоботясь о типах и т.д.. но как то "страшновато" становится когда думаешь что под этим скрыто, кастинг , кастинг, кастинг )))

Ты абсолютно уверен в том, что это так?