Здравствуйте, LaptevVV, Вы писали:
LVV>Но для "среднего" потребителя клепают "средние" скрипки в массовом порядке.
Когда скрипки — еще куда ни шло. Тут, скорее, вместо скрипки так и норовят сделать шарманку, но очень большую, набитую готовыми звуками и мелодиями. Если не бить их по рукам — непременно ведь сделают.
Re[2]: Позиция C++ среди популярных ЯП и его изучение
Здравствуйте, reversecode, Вы писали:
R>для тех кто не следит за действием комитета R>сообщаю R>что комитет создал рабочую группу если не ошибаюсь, как минимум несколько лет назад R>которая следит за тем что бы язык развивался в нужном направлении R>что бы С++ не уходил в абсурд и не становился слишком сложным для изучающих его
Комитет создал подкомитет для борьбы с комитетами. Исчерпывающее объяснение, почему всё так, как оно есть.
2ТС. Нет ничего плохого в желании иметь в стандартной (а не хрен знает откуда взятой) библиотеке всё, что нужно каждый день, от коллекций до регэксов. Другое дело, что STL это самая нечеловеческая куча кода, которая явилась степанову под грибами, как метко написал один автор на лурке.
ЕМ>>При этом, если писать на C, то с ростом сложности и объема трудоемкость растет экспоненциально, а C++ позволяет достаточно долго удерживать ее почти линейной.
Pzz>Вот с этим не соглашусь. Экспоненциально она растет, когда сложность переполняет голову автора, и он теряет контроль над собственной программой. Но это не свойство языка, а свойство головы автора, его способность держать под контролем возрастающую сложность системы.
C++ как раз предоставляет средства для управления сложности, как поделить экспоненциальную сложность на меньшие сложности. Думать о том как они (обьекты) взаимодействуют друг с другом, есть разные способы соединить и вширь и вглубь. А меньшими сложностями не забивать голову когда не надо, можно отдать реализовывать другим людям и т.п. Надо тебе две сложности с разными параметрами создал два обьекта, надо что-то поменять создал производный класс. Надо связать разнообразные сложности вместе и потом по ним походить — пожалуйста, создал общий класс для всех и контейнер из него, все сложности туда — ходишь по ним и делаешь чего надо. Надо создал сложность динамически, надо статически... На С такого не особо поделаешь. В смысле на С можно все сделать но как только начинаешь делать чтото большое, расширяемое, красивое так и выходит что изобретаешь фичи C++, правда в которых порой только ты разумеешь. Зачем изобретать то когда уже есть?
Re[5]: Позиция C++ среди популярных ЯП и его изучение
Здравствуйте, qqqqq, Вы писали:
Q>C++ как раз предоставляет средства для управления сложности, как поделить экспоненциальную сложность на меньшие сложности. Думать о том как они (обьекты) взаимодействуют друг с другом, есть разные способы соединить и вширь и вглубь. А меньшими сложностями не забивать голову когда не надо, можно отдать реализовывать другим людям и т.п. Надо тебе две сложности с разными параметрами создал два обьекта, надо что-то поменять создал производный класс. Надо связать разнообразные сложности вместе и потом по ним походить — пожалуйста, создал общий класс для всех и контейнер из него, все сложности туда — ходишь по ним и делаешь чего надо. Надо создал сложность динамически, надо статически... На С такого не особо поделаешь. В смысле на С можно все сделать но как только начинаешь делать чтото большое, расширяемое, красивое так и выходит что изобретаешь фичи C++, правда в которых порой только ты разумеешь. Зачем изобретать то когда уже есть?
C++ пытается превратить смысловую сложность в синтаксическую сложность, но я не уверен, что смысловая сложность от этого куда-то девается.
История знает примеры успешного построения невероятно сложных проектов на чистом Си. То же ядро Linux, например.
Но в конечном итоге, рискну предположить, что контроль над проектом теряется в тот момент, когда остается критически малое количество людей, способных его понимать на должном уровне. И синтаксическая сложность в этом деле не помощник.
Re[5]: Позиция C++ среди популярных ЯП и его изучение
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Под них можно писать не на "плюсах", а на определенном подмножестве языка.
Ну так и технических возможностей у них тоже, как бы это сказать, весьма ограниченное подмножество.
ЕМ>Когда-то граница этого подмножества была достаточно хорошо видна, но со временем она очень сильно размылась. Работоспособную прошивку под мелкий МК на C++ в состоянии написать тот, кто изучал язык "снизу", в то время, как его преподавание уже давно и привычно идет "сверху". В результате сама идея использования языка в отрыве от STL и шаблонной магии
На тех же атмегах шаблонную магию вообще можно использовать без проблем. Некоторое подможество STL — тоже.
Pzz>История знает примеры успешного построения невероятно сложных проектов на чистом Си. То же ядро Linux, например.
Похоже Linux изначально сделан на основе unixa, который сделал Ричи — изобретатель C, в то время когда C++ не было и проекте. Кроме того, то что сам пингвин не любит C++ — общеизвестный факт и конечно же он никогда бы не позволил переписывать свой Linux на C++ или чтото там еще. А если бы ядро Linuxа было сделано на C++ то возможно в его разработке могли бы принимать активное участие не обязательно суперпрограммисты типа самого его и красноглазиков а обычные люди. Не факт что это нужно конечно, но было бы неплохо если бы можно было быстренько просечь как там сделан тот или иной кусок просто посмотрев на диаграммы классов их связи а не курить бамбмук годами. Естественно считается что ОС должна быть написана кровью на С или ассемблере потому что типа надо очень быстро а C++ это очень медленно. Это в общем случае заблуждение, я принимал участие в разработке вполне успешной и широко известной (в узких кругах) коммерческой ОС, в которой внезапно внутри некие части ядра на C++, и все там было и быстро и расширяемо, и легко для понимания. Если же не рассматривать ОСи ввиду их особенной специфики, то C++ по крайней мере не менее распространен в сложных проектах чем C. А там где C остался то часто как в Линуксе — потому что он там изначально был, не переписывать же.
Pzz>Но в конечном итоге, рискну предположить, что контроль над проектом теряется в тот момент, когда остается критически малое количество людей, способных его понимать на должном уровне. И синтаксическая сложность в этом деле не помощник.
В общем разница не столько в синтаксе языка а в несколько другом подходе к разработке и образе мысли, который невозможен на С. Конечно просто переход на C++ не сделает сразу проект лучше.
Re[5]: Позиция C++ среди популярных ЯП и его изучение
Здравствуйте, m2user, Вы писали:
S>>Какая польза от спича в заглавном сообщении этой темы именно на форуме я не понимаю. S>>Такой спич где-то в личном блоге, в каком-нибудь LinkedIn или на каком-нибудь Habr-е или Medium -- более чем OK.
M>Если я правильно понимаю, то даже если бы статья была размещена в блогах (blogs.rsdn.org), то обсуждение (комменты) всё равно было бы в тематическом форуме.
Это техническая тонкость конкретной платформы. Принципиально наличие самой исходной статьи, т.к. статья означает, что главная цель -- это некоторое высказывание автора. Не важно чем продиктованное -- графоманией, невозможностью удержать что-то в себе или желанием поделиться чем-то с публикой. Автор высказался, цель достигнута, реакция от читателей может быть, а может и не быть, т.к. эта самая реакция вторична по сравнению с желанием высказать свое мнение по какому-то вопросу.
Тогда как топик на форуме (без предшествующей статьи) означает, что автору нужно мнение форумчан.
И вот здесь я не понимаю какой именно фидбэк Музыченко ждет от нас, от участников обсуждений. Отсюда и мой вопрос. Ну вот реально ХЗ что ТС ждет от тех, кто осилил очередной поток оторванного от реальности бреда. А если ТС не ждет ответов, то зачем все это было?
Даже если 150 человек ему напишут "Да, чувак, ты прав на 146%! Мы с тобой!" то что это изменит и на что повлияет? Музыченко напишет свой учебник по программированию? Разработает свою замену C++? Начнет вести курсы по программированию, где будет учить людей самому главному, а не вот этому всему?
Понимаю, что вопросы риторические и ответы от ТСа мы вряд ли получим, но они таки имеют место быть.
Re[6]: Позиция C++ среди популярных ЯП и его изучение
Здравствуйте, so5team, Вы писали:
S>И вот здесь я не понимаю какой именно фидбэк Музыченко ждет от нас, от участников обсуждений. Отсюда и мой вопрос. Ну вот реально ХЗ что ТС ждет от тех, кто осилил очередной поток оторванного от реальности бреда. А если ТС не ждет ответов, то зачем все это было?
Этот пост (он не такой и большой, точно не статья) о С++ в теме про С++, что уже неплохо. Возможно, что в СВ или Философии было бы удачнее. С другой стороны, зачем придираться? Тот же velkin иногда такое напишет, что с телефона в принципе не прочитать. Так что нельзя сказать, что пост Евгения как-то выбивается в худшую стоорну на фоне остальных сообщений.
Re[7]: Позиция C++ среди популярных ЯП и его изучение
Здравствуйте, Nuzhny, Вы писали:
N>Этот пост (он не такой и большой, точно не статья) о С++ в теме про С++
Вообще-то нет. Это очередное подтверждение того, что Евгений живет в какой-то своей реальности, в каком-то крошечном и уютном маня-мирке из которого он уже лет 30 наружу даже не выглядывал. Но при этом пытается рассуждать о вещах, которых в его маня-мирке нет вообще.
Соответственно, я не понимаю, чего он ждет. Чтобы ему подтвердили, что он прав? Чтобы ему указали в чем он не прав?
Так что для меня его спич выглядит как декларация вида "Я вижу мир вот таким!"
Да, серьезно? Ну OK, бывает.
Здравствуйте, Евгений Музыченко, Вы писали: ЕМ>Получилось сумбурно. По-хорошему, такие вопросы надо рассматривать, как минимум, в большой статье, но нет ни времени, ни желания ее сочинять — все равно мало кто поймет.
на С/С++ практически ничего не писал, но в последнее время начал изучать, до этого .NET/Java/Typescript, на заре был ассемблер и Си для контроллеров
С/С++ языки, которые заставляют думать об исполняющем механизме, иногда до деталей (регистры, память, ссылки, указатели) и прочее
Вообще Си, именно Си очень хорошо приводит в порядок мозг, там всегда надо думать, нельзя просто так взять и написать код.
Серьезные вещи можно написать и на Java/NET но придется так или иначе столкнуться с ручным управлением памятью и семантика будет уже С/С++
Сейчас на языках с автоматической памятью подавляющее большинство пишет банальное крудошлепство, или формошлепство 2.0: тут выставили рест контроллер, перемазали спрингом, вот пара ДТОшек, тут мы их перекладываем, тут базенка.
Надо сделать еще фичи, нанимаем еще разрабов и те генерят еще больше кода. Редко кто пишет какие-то многопоточные фреймворки или библиотеки, думает об абстракциях и вылизывает модель — это никому не нужно.
работа сводится к том, что накинули микросервис, его в контейнер — работает, правда когда этого становится много, с этим становится работать сложнее и дороже.
То же самое касается тайп скрипта — прекрасный язык, с его оберткой над динамической типизацией можно строить потрясающие модели, но сложные веб проекты тоже есть далеко не везде и далеко не всем нужны, за чем какой-то быстро работающий внутренний портал? наговнякали и так сойдет.
несовершенство программной модели часто можно скомпенсировать наймом бОльшего количества разрабов.
так вот С++ и С не позволяют крудошлепить, это языки не того уровня и соответственно, массово люди в них не пойдут, это нишевые языки.
Re[2]: Позиция C++ среди популярных ЯП и его изучение
Здравствуйте, qqqqq, Вы писали:
Q>Похоже Linux изначально сделан на основе unixa, который сделал Ричи — изобретатель C, в то время когда C++ не было и проекте. Кроме того, то что сам пингвин не любит C++ — общеизвестный факт и конечно же он никогда бы не позволил переписывать свой Linux на C++ или чтото там еще. А если бы ядро Linuxа было сделано на C++ то возможно в его разработке могли бы принимать активное участие не обязательно суперпрограммисты типа самого его и красноглазиков а обычные люди. Не факт что это нужно конечно, но было бы неплохо если бы можно было быстренько просечь как там сделан тот или иной кусок просто посмотрев на диаграммы классов их связи а не курить бамбмук годами.
Не знаю, я обычный человек и не испытываю сложностей с писанием в ядро линуха. Можно разобраться за день, берешь какой-нибудь незамысловатый модуль из числа приходящих вместе с ядром, и смотришь. Там очень просто всё, и можно найти пример модуля, который делает что-нибудь полезное, и в нем будет всего несколько сот строк.
Может это и хорошо, что люди, не способные самостоятельно разобраться с примером из нескольких сот строк, не пишут в ядро?
Q>Естественно считается что ОС должна быть написана кровью на С или ассемблере потому что типа надо очень быстро а C++ это очень медленно.
Неа. Когда у тебя ОС, и что-то идет не так, тебе надо очень хорошо понимать, что у тебя на самом деле происходит. Не на уровне сложных абстракций, которые может и работают, как обещано, а скорее всего — нет, а вот по-настоящему. Вот здесь мы ловим такое-то событие и пишем такое-то слово в такой-то регистр, а здесь — вот так вот.
Все эти высокоуровневые абстракции C++ и автоматизмы только мешают.
Pzz>>Но в конечном итоге, рискну предположить, что контроль над проектом теряется в тот момент, когда остается критически малое количество людей, способных его понимать на должном уровне. И синтаксическая сложность в этом деле не помощник. Q>В общем разница не столько в синтаксе языка а в несколько другом подходе к разработке и образе мысли, который невозможен на С. Конечно просто переход на C++ не сделает сразу проект лучше.
Непонятно, с чего бы.
Re[4]: Позиция C++ среди популярных ЯП и его изучение
Здравствуйте, Pzz, Вы писали:
Pzz>C++ пытается превратить смысловую сложность в синтаксическую сложность, но я не уверен, что смысловая сложность от этого куда-то девается.
Позволю не согласиться. Прикладной код можно писать вполне красиво без всех этих закорючек, а вот возможности метапрограммирования хорошо снижают семантическую сложность
Pzz>История знает примеры успешного построения невероятно сложных проектов на чистом Си. То же ядро Linux, например.
Там главпингвин просто упоротый по сишечке. Писали бы на плюсах — и багов меньше было бы, и сложности меньше.
Некоторые (в частности, в GTK) в итоге начинают изобретать плюсы на сишечке — всякие ГОбджекты, метапрограммирование на макросах, и тд и тп. И в самом ядре линукса используют хотя бы те же таблицы виртуальных методов. Только по сишечному — максимально уродливо и небезопасно
Re[5]: Позиция C++ среди популярных ЯП и его изучение
Здравствуйте, пффф, Вы писали:
Pzz>>C++ пытается превратить смысловую сложность в синтаксическую сложность, но я не уверен, что смысловая сложность от этого куда-то девается.
П>Позволю не согласиться. Прикладной код можно писать вполне красиво без всех этих закорючек, а вот возможности метапрограммирования хорошо снижают семантическую сложность
Увеличивает, причем кратно.
Возможность метапрограммирования позволяет построить свой язык над существующим. Причем в каждой конторе, в каждом проекте он свой.
Этого не замечаешь, когда долго варишься в одном проекте. Но когда происходит переключение, или когда в проект вливается другой большой проект, это очень даже заметно.
Pzz>>История знает примеры успешного построения невероятно сложных проектов на чистом Си. То же ядро Linux, например.
П>Там главпингвин просто упоротый по сишечке. Писали бы на плюсах — и багов меньше было бы, и сложности меньше.
Ядро очень хорошо структурировано по самой природе вещей. Драйвера-файловые системы-стеки сетевых протоколов и т.д. Разбивка на "классы" естественная, давно и хорошо продуманная и обкатанная, еще и до линуха всякого, и интерфейсы "классов" тоже всем известны и понятны.
Ничего бы сюда C++ не добавил.
П>Некоторые (в частности, в GTK) в итоге начинают изобретать плюсы на сишечке — всякие ГОбджекты, метапрограммирование на макросах, и тд и тп. И в самом ядре линукса используют хотя бы те же таблицы виртуальных методов. Только по сишечному — максимально уродливо и небезопасно
GTK — это жудь. Никто не любит GTK, кроме авторов GTK.
Re[5]: Позиция C++ среди популярных ЯП и его изучение
Здравствуйте, qqqqq, Вы писали:
Pzz>>История знает примеры успешного построения невероятно сложных проектов на чистом Си. То же ядро Linux, например. Q>Похоже Linux изначально сделан на основе unixa, который сделал Ричи — изобретатель C, в то время когда C++ не было и проекте.
Линус начал лабать свой Линукс в 91ом году.
В 1991 году вышла версия Borland C++ 3.0 с поддержкой сборки Windows-приложений. Спустя год вышло обновление 3.1, в котором был реализован оконный IDE и шаблоны приложений OWL 1.0 и Turbo Vision 1.0.
Q>Кроме того, то что сам пингвин не любит C++ — общеизвестный факт
Просто не осилил
Q>В общем разница не столько в синтаксе языка а в несколько другом подходе к разработке и образе мысли, который невозможен на С. Конечно просто переход на C++ не сделает сразу проект лучше.
На самом деле сразу сделает. Потому что сишечный код — это на 90% ковыряние с сырой памятью и ручное управление ресурсами, что в плюсах один раз заворачивается в классы, и дальше на плюсах ты просто пишешь высокоуровневую логику. Тут сразу уходят все проджобы с памятью, из-за которых и появляется 90% багов
Re[6]: Позиция C++ среди популярных ЯП и его изучение
Здравствуйте, пффф, Вы писали:
П>На самом деле сразу сделает. Потому что сишечный код — это на 90% ковыряние с сырой памятью и ручное управление ресурсами, что в плюсах один раз заворачивается в классы, и дальше на плюсах ты просто пишешь высокоуровневую логику. Тут сразу уходят все проджобы с памятью, из-за которых и появляется 90% багов
Это ерунда. После того, как в Си понапишешь немного удобной инфраструктуры для управления памятью, очень быстро вообще перестаешь замечать наличие проблемы и сосредотачиваешься на высокоуровневой логике.
Re[6]: Позиция C++ среди популярных ЯП и его изучение
П>>Позволю не согласиться. Прикладной код можно писать вполне красиво без всех этих закорючек, а вот возможности метапрограммирования хорошо снижают семантическую сложность
Pzz>Увеличивает, причем кратно.
Pzz>Возможность метапрограммирования позволяет построить свой язык над существующим. Причем в каждой конторе, в каждом проекте он свой.
Этим мало кто занимается. И подобные сущности появляются в проектах, уровня которых на сишечке просто не достигнуть в разумные сроки
Pzz>Этого не замечаешь, когда долго варишься в одном проекте. Но когда происходит переключение, или когда в проект вливается другой большой проект, это очень даже заметно.
Я сменил не один плюсовый проект, никаких проблем не замечал
Pzz>>>История знает примеры успешного построения невероятно сложных проектов на чистом Си. То же ядро Linux, например.
П>>Там главпингвин просто упоротый по сишечке. Писали бы на плюсах — и багов меньше было бы, и сложности меньше.
Pzz>Ядро очень хорошо структурировано по самой природе вещей. Драйвера-файловые системы-стеки сетевых протоколов и т.д. Разбивка на "классы" естественная, давно и хорошо продуманная и обкатанная, еще и до линуха всякого, и интерфейсы "классов" тоже всем известны и понятны.
Pzz>Ничего бы сюда C++ не добавил.
Добавил бы. Убрал бы всё ручное управление памятью и ресурсами. А это очень много.
П>>Некоторые (в частности, в GTK) в итоге начинают изобретать плюсы на сишечке — всякие ГОбджекты, метапрограммирование на макросах, и тд и тп. И в самом ядре линукса используют хотя бы те же таблицы виртуальных методов. Только по сишечному — максимально уродливо и небезопасно
Pzz>GTK — это жудь. Никто не любит GTK, кроме авторов GTK.
Просто пример сишечного проекта. Все сишечные проекты скатываются в подобное
Re[7]: Позиция C++ среди популярных ЯП и его изучение
Здравствуйте, Pzz, Вы писали:
П>>На самом деле сразу сделает. Потому что сишечный код — это на 90% ковыряние с сырой памятью и ручное управление ресурсами, что в плюсах один раз заворачивается в классы, и дальше на плюсах ты просто пишешь высокоуровневую логику. Тут сразу уходят все проджобы с памятью, из-за которых и появляется 90% багов
Pzz>Это ерунда. После того, как в Си понапишешь немного удобной инфраструктуры для управления памятью, очень быстро вообще перестаешь замечать наличие проблемы и сосредотачиваешься на высокоуровневой логике.
На сишечке ты эту инфраструктуру пишешь постоянно. Я когда-то писал веб сервер на сишечке. Месяца полтора потратил. Как раз на эту удобную инфраструктуру. На плюсах бы написал бы в лучшем виде за неделю
Исчерпывающее объяснение, почему всё так, как оно есть.
