Rust vs C++

Кто-то писал на Rust? Стоит ли начинать учить? Насколько Rust хуже/лучше С++?

0

Сообщение от Fulcrum_013 Вы настолько безграмотны что не в сосотянии отличить языки программирования от форматов данных?

Код, генерирующий HTML отдаваемый браузера - это формат данных?

0

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

Ну то есть чем хуже данный конкретный язык, тем предпочтительнее он для использования по мнению Fulcrum_013. Ок, понятно.

Сообщение от Fulcrum_013 То есть С++ активно применяется при разработке ОСей, драйверов, веб-страниц, баз данных, запросов к ним, автоматизации запуска программ, встраивания в другие программы в качестве модулей и т.д. - я правильно понял? Правильно.

То есть Fulcrum_013 никогда не слышал о программирвоании. Не то чтобы это было непонятно из предыдущих 14 страниц...

Сообщение от Fulcrum_013 Вы настолько безграмотны

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

Сообщение от COKPOWEHEU Откуда у вас объем кода XP? Каков в нее объем скомпилированного ядра?

0

Сообщение от COKPOWEHEU То есть Fulcrum_013 никогда не слышал о программирвоании.

То есть вы никогда не слышали о разработке софта от слова совсем.

Добавлено через 4 минуты

Сообщение от COKPOWEHEU Ну то есть чем хуже данный конкретный язык

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

Добавлено через 4 минуты
COKPOWEHEU,
https://ru.wikipedia.org/wiki/... строк_кода
При этом показательны темпы роста. У винды рост объемов кода примерно линейный у линухи экспонента.

Добавлено через 3 минуты

Сообщение от Usaga Код, генерирующий HTML отдаваемый браузера - это формат данных?

Ну там вообще то html и т.д. были поставлены в один ряд с языками программирования, а не о генерации речь шла.
Ну а касательно того что касается генерации HTML то тут возможности плюсов превосходят горе-скрипты как минимум на пару порядков. При этом не забывайте что html - это всего лишь формат сериализации объектов используемых браузером. Чтобы что то сериализировать нужно сначала это вычилить - т.е. принять санитизировать и обработать запрос. К этим вопросам плюсы преспособлены на порядки лучше скриптов, а особенно в свете перехода к клиентскому рендеру и дуплексным протоколам.

Добавлено через 11 минут

Сообщение от COKPOWEHEU Ну то есть чем хуже данный конкретный язык

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

0

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

Ну то есть они имеют существенные недостатки, ограниченную нишу, неэффективны - и поэтому используются именно они, а не божественные плюсики?

Сообщение от Fulcrum_013 https://ru.wikipedia.org/wiki/... строк_кода

Вы сами привели эту ссылку, ей же и буду вас в нос тыкать:

Размеры исходных кодов операционных систем семейства Microsoft Windows NT точно не известны

Год Версия Строк кода, млн. 1993 Windows NT 3.1 4-5 ... 2001 Windows XP 45

Год Версия Строк кода 1991 Ядро Linux 0.1 10 239 1994 Ядро Linux 1.0.0 176 250 ... 2001 Ядро Linux 2.4.0 3 377 902 ... 2017 Ядро Linux 4.11.7 18 373 471

А теперь сравниваем:
1994 год: windows 3.1 занимает 4 млн. строк, Linux 1.0.0 - 0.18 млн. строк
2001 год: WindowsXP занимает 45 млн. строк, Linux 2.4 - 3.4 млн. строк
И даже в 2017 году ядро занимает всего 18.4 млн. строк - на треть меньше, чем Win2000.
Предвижу переобувание в прыжке: "большой объем кода windows - признак хорошего кода, там много комментариев, длинные имена переменных, форматирование и все такое". Так вот, нет. Само по себе количество строк кода не говорит строго говоря ни о чем. Ну кроме случая, когда программисту платят именно за строки (на всякий случай, это был не намек, а пример особого случая).
И еще раз обращаю внимание - я пользовался исключительно вашей ссылкой.

Сообщение от Fulcrum_013 Ну там вообще то html и т.д. были поставлены в один ряд с языками программирования.

Ну так не делайте этого больше: HTML - язык разметки, а не программирования. Он не управляет поведением чего бы то ни было.

0

Сообщение от COKPOWEHEU Ну так не делайте этого больше:

Ну дак вы же их поставили ы один ряд а не я.

Сообщение от COKPOWEHEU HTML - язык разметки, а не программирования

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

Добавлено через 4 минуты

Сообщение от COKPOWEHEU Ну то есть они имеют существенные недостатки, ограниченную нишу, неэффективны

Где они вообще используются то? 99% обработки данных выполняется таки универсальными языками. И то что строк кода на скриптах на порядки больше чем на универсальных языках а к решению 1% задачнужно превлекать в 10 раз больше людей чем для решения 99% задач - это в первую очередь недостатки скриптов. Т.е. причина их "популярности" именно в их убогости в условии тотального дефицита квалифицированных спецов, вынуждающего привлекать ко второстепенным задачам толпы неквалифицированных разработчиков.

Добавлено через 6 минут

Сообщение от COKPOWEHEU А теперь сравниваем:

Ну вот и продолжте кривую
7 января 2019: первый релиз-кандидат Linux 5.0 (более 26 млн строк кода). Продолжте кривую.
Размер растет по экспоненте.

Сообщение от COKPOWEHEU Само по себе количество строк кода не говорит строго говоря ни о чем.

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

Сообщение от COKPOWEHEU Предвижу переобувание в прыжке:

Вы так и не поняли суть? Вы сравниваете объем кода только ядра (т.е. только менеджер памяти, планировщик задач, загрузчик программ, система виртуализации устройств) и всей оси. Учитывая сколько апи и прочих искоробочных дел в винде, ядро у нее ну никак не больше 10% от общего объема кода, а скорее всего гораздо меньше.

0

Сообщение от Fulcrum_013 Первейшие недостатки скриптов - динамическая типизация, наличие архаичного GC, полное отсутствие всякого присутсвия средств создания высокоуровневых асбтракций

Мне динамическая типизация тоже не нравится, но поскольку найти достаточно распространенный скриптовый язык без нее мне не удалось, наверное зачем-то она нужна. Конечно, она добавляет накладные расходы, но и добавляет возможность модификации объектов, что в случае скриптов довольно полезная фича. Конечно, лишает возможности проведения одной проверки в компил-тайме... стоп, что? Вообще-то скрипты не предназначены для компиляции, значит проверку так и так придется проводить в рантайме.
То есть допотопный Си абстракции любого уровня обеспечивает без проблем, а скриптовые языки - нет? А какие именно абстракции вам нужны, которых невозможно добиться, скажем, в Lua?
Ах да, куда ж без пустословной нападки на GC. Наверное, это какая-то травма детства или разноцветные мечты о будущем. Кроме вас про этот механизм никто не кричит. Ну есть он в распространенных языках, ну страхует от некоторых ошибок почти не снижая производительность (а в скриптовых языках она не главное) - ну и что?

Сообщение от Fulcrum_013 Попытки применения их к чему то еще приводяи к экспоненциальному увеличению сложности разработки и/или катастрофическим последствиям.

Откуда берется квадратичная сложность при вашем подходе я понять могу (связи каждый-с-каждым). Откуда берется линейная или что-то вроде n*ln(m) при человеческой - тоже (древовидная структура или цепочки). Но откуда вы выкопали экспоненциальную? Здесь правда любопытно узнать какая математика за этим может стоять.
Ну а на счет ваших домыслов про экспоненциальную сложность - так это просто домыслы, основанные только на фанатизме.

Сообщение от Fulcrum_013 [HTML] Он вообще язык только с точки зрения теории формальных грамматик.

Русский или английский - тоже языки. И регулярные выражения - языки.

Сообщение от Fulcrum_013 к решению 1% задачнужно превлекать в 10 раз больше людей чем для решения 99% задач

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

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

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

Сообщение от Fulcrum_013 Ну вот и продолжте кривую

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

Сообщение от Fulcrum_013 Вы так и не поняли суть? Вы сравниваете объем кода только ядра

Это вы предложили такое сравнение, кто ж вам виноват что не подобрали какой-нибудь другой параметр?

Сообщение от Fulcrum_013 Учитывая сколько апи и прочих искоробочных дел в винде, ядро у нее ну никак не больше 10% от общего объема кода, а скорее всего гораздо меньше.

Ну если вы настаиваете, могу и в эту лужу вас потыкать: каков там, говорите, объем установленной актуальной винды, какие у нее системные требования и какой софт доступен из коробки? Я вот на почти чистой виртуалке обнаружил, что более 20 ГБ занято системой. Не менее чистая линуксовая виртуалка - 3,5 ГБ. Рабочая машина, с кучей софта и уже порядком загаженная - 30 ГБ. Про системные требования и функционал даже говорить не буду, а то виндузятникам совсем печально будет.

Миниатюры

 

1

Сообщение от COKPOWEHEU вот на почти чистой виртуалке обнаружил, что более 20 ГБ занято системой. Не менее чистая линуксовая виртуалка - 3,5 ГБ. Рабочая машина, с кучей софта и уже порядком загаженная - 30 ГБ.

Процетирую местного эксперта:

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

Это у винды такая "оптимизация" по жёсткому диску.



По поводу размера ядра линукса:
https://unix.stackexchange.com... es-of-code

According to cloc run against 3.13, Linux is about 12 million lines of code. 7 million LOC in drivers/ 2 million LOC in arch/ only 139 thousand LOC in kernel/ lsmod | wc on my Debian laptop shows 158 modules loaded at runtime, so dynamically loading modules is a well-used way of supporting hardware.

0

Сообщение от COKPOWEHEU Здесь правда любопытно узнать какая математика за этим может стоять.

Банальная возможность построения и повторного использования высокоуровневых абстракций. У всех скриптов она осталась на уровне языков 70-х точно так же как и у манаджед. При этом сложности с управлением ресурсами, в следствие роста сложности управления взаимосвязями, у языков не имеющих средств автоматики растут тоже экспоненциально. При этом GC без решения задачи управления взаимосвязями уборку произвести не способен. Ручное же решение оной задачи абсолютно аналогично ручному решению задачи управления жизненным циклом, решение которой попутно решает и задачу управления памятью гораздо более оптимальным способом чем GC.
При этом средства диагностики доступные при динамической типизации, опять же практически полностью исключают возможность использования высокоуровневых абстракций. Невозможность определить несоответсвие типов в компайлтайме требует покрывать абсолютно весь код бренч-тестами для отлова ошибок, которые в отличии от юнитов зависимы от реализации, что опять же ведет к резкому усложнению разработки.

Добавлено через 4 минуты

Сообщение от COKPOWEHEU и какой софт доступен из коробки

Такой который линуксу искоропки не снился в принципе. К примеру десктоп, SQL сервер, Web-сервер, антивирус, брендмауер, и самое главное - огромная гора апи как десктопного так и более другого (к примеру MS Сrypt, DirectX и даже тот же не к ночи помянут будет NetFramework ). Это и еще много чего что входит в состав винды из коробки и это все учтено в объеме кода указанном для винды.
В линухе же это количество кода только ядра - т.е. только то что работает непосредственно в нулевом кольце, не считая драйверов. Как видим только вот эта мизерная часть давно превысила то во что можно вложить ось с кучей апи и искоробочного софта.

Добавлено через 3 минуты

Сообщение от COKPOWEHEU Русский или английский - тоже языки. И регулярные выражения - языки.

Еще раз - с точки зрения формальных грамматик. С их точки зрения вообще все язык.
С точки же зрения всего остального - это формат данных сериализации объектов браузера.

0

Сообщение от Fulcrum_013 В линухе же это количество кода только ядра - т.е. только то что работает непосредственно в нулевом кольце, не считая драйверов.

Вы бредите? У вас шизофрения?
https://unix.stackexchange.com... es-of-code

0

Сообщение от Fulcrum_013 у языков не имеющих средств автоматики растут тоже экспоненциально

Я просил не повторить голословное высказывание, а обосновать его. Почему именно экспоненциально, а не квадратично, логарифмически или факториально?

0

Сообщение от COKPOWEHEU Это вы предложили такое сравнение, кто ж вам виноват что не подобрали какой-нибудь другой параметр?

Ну как бы по размерам конкретных частей оси данные от тех кто юзает не С а что то более подходящее все равно не доступны.
Но касательно винды начиная с хрюшки рост общего объема вызван в первую очередь ростом Net Framework - т.е. расширением прикладного АПИ.

Добавлено через 7 минут

Сообщение от COKPOWEHEU Почему именно экспоненциально, а не квадратично, логарифмически или факториально?

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

0

Сообщение от Fulcrum_013 Такой который линуксу искоропки не снился в принципе. К примеру десктоп, SQL сервер, Web-сервер, антивирус, брендмауер

Да уж, антивирус линуксу точно не снился даже в кошмарах.
А на счет остального - графическое окружение в линуксе из коробки (сделаю вам поблажку, не буду пугать такими страшными словами как репозиторий, обойдемся чем-то вроде установочного диска Убунты) однозначно лучше виндового.
Про SQL и веб-сервер ничего не могу сказать - не интересовался (хотя то, что напрактике обычно используются именно линуксовые версии намекает).
БрЕндмауер - оговорочка по-виндузятному . Но iptables это разве не оно?

Сообщение от Fulcrum_013 самое главное - огромная гора апи как десктопного так и более другого

Или вы про то, что в линуксе код, не относящийся к ядру, вроде графики или криптографии, в ядро и не пихают? Да, действительно, какое нарушение всех законов, куда катится мир!
Но вы от темы-то не уходите. Тут кое-кто размахивал ссылкой на количество кода в ядре и скорость его роста. Этому кому-то даже предоставили графики, в том числе темпов роста. Он продолжает утверждать что виндовый код растет линейно, а линуксовый - экспоненциально? Или у этого кого-то в его реальности прямая и экспонента именно так и выглядят?

0

Подтверждаю квалификаю Fulcrum_013

Ядро линукса с оф репозитория:

Сообщение от Fulcrum_013 В линухе же это количество кода только ядра - т.е. только то что работает непосредственно в нулевом кольце, не считая драйверов.

Где только таких экспертов выращивали...

0

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

Добавлено через 1 минуту

Сообщение от IamLost Ядро линукса с оф репозитория:

Это не ядро. Ядро это kernel. от и посчитайте сколько там кода.

0

Сообщение от Fulcrum_013 Это не ядро. Ядро это kernel. от и посчитайте сколько там кода.

Дурачком прикидываться будете?

Сообщение от Fulcrum_013 В линухе же это количество кода только ядра - т.е. только то что работает непосредственно в нулевом кольце, не считая драйверов.

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

"Эксперт", прекратите нести бред на форуме.

0

Сообщение от Fulcrum_013 Но касательно винды начиная с хрюшки рост общего объема вызван в первую очередь ростом Net Framework - т.е. расширением прикладного АПИ.

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

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

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

Добавлено через 4 минуты

Сообщение от Fulcrum_013 Это не ядро. Ядро это kernel. от и посчитайте сколько там кода.

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

Добавлено через 2 минуты

1

Сообщение от COKPOWEHEU Еще раз: даже если использовать ваш подход, каждый-с-каждым, это всего лишь квадратичный рост.

Вы не поняли в чем хохма. Имеем список А элементы которого имеют свой набор взаимосвязей уже с реализованным слеженинием за жизненным циклом и т.д. Добавляется список Б который зависим от А и который надо поддерживать актуальным при изменениях А. В результате усложняется как алгоритм слежения за жизненным циклом списка A. При увеличении количества списков рост сложности алгоритма будет расти гораздо быстрее квадрата.

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

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

Добавлено через 2 минуты

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

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

Добавлено через 4 минуты

Сообщение от COKPOWEHEU Хотя бы ссылку на то, что вы называете kernel

То что и называется kernel-ом - ядро ос. Т.е. та часть которая работает в нулевом кольце - а именно диспетчер памяти, планировщик задач, система виртуализауии устройств, загрузчик прикладных программ и драйверов.
Хотя опять же на основе отрывочных данных из википедии оценить это можно тлько очень приблизительно.
Касательно продуктивности плюсов и С лучший способ оценки - транспилировать код с плюсов в С и сравнить количество строк. А это делалось в свое время постоянно - примерно до середины 90-х прототип компилятора, используемый для развития языка, работал именно как транспилятор в C. Между С и "С с классами" разница в количестве строк в десятки раз. Для современных плюсов разница с "С с классами" будет не меньше, при этом будет резко возрастать при росте объема и сложности софтины.

0

Сообщение от Fulcrum_013 Имеем список А <...> Добавляется список Б который зависим от А

Эти списки на одном слое абстракции или на разных?

Сообщение от Fulcrum_013 Нормальные обработчики решают задачу в общем.

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

Сообщение от Fulcrum_013 Потому что абстракции эти сложности берут на себя.

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

Сообщение от Fulcrum_013 То что и называется kernel-ом - ядро ос. Т.е. та часть которая работает в нулевом кольце - а именно диспетчер памяти, планировщик задач, система виртуализауии устройств, загрузчик прикладных программ и драйверов.

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

Сообщение от Fulcrum_013 Хотя опять же на основе отрывочных данных из википедии оценить это можно тлько очень приблизительно.

Я вам уже неоднократно предлагал проверить конечный итог - объем дистрибутива, функциональность, требования. Вы почему-то* уходите от ответа.
*) нет, я-то понимаю почему: не хочется опозориться еще сильнее.

Сообщение от Fulcrum_013 Касательно продуктивности плюсов и С лучший способ оценки - транспилировать код с плюсов в С и сравнить количество строк.

Как бы вам намекнуть что это некорректное сравнение. Как минимум, потому что одну и ту же задачу на С++ скорее всего будут решать в ООП стиле, а на Си - в процедурном, то есть сам подход будет разным. Если уж хотите сравнивать - сравнивайте ассемблерный код или, что то же самое, объем бинарника.
Ну а если имеется в виду, что чем более высокоуровневый язык используется, тем меньше объем кода - так это не новость, более того, можно даже ввести какой-то коэффициент пропорциональности (линейной зависимости), чтобы этот объем прикинуть. Где-то слышал, что объем кода на С++ больше кода на Питоне примерно в 10 раз, но за достоверность не ручаюсь.

0

COKPOWEHEU, При этом к примеру манаджед, в следствие фундаментальных недостатков присущих GC, никогда не сможет подняться в средствах создания высокоуровневых абстракций выше чем Симула-67 - т.е. даже достичь уровня "С с классами". Учитывая же фундаментальные недостатки динамической типизации, cкрипты по продуктивности и опять же средствам создания абстракций всегда будут уступать манаджед.
Касательно же остальных универсальных языков - то преодолеть уровень "С c классами" и стать хотя бы на несколько ступенек выше смогла только Ада, в следствие того что проектировалась в тоже самое время что и плюсы. Для остальных же универсальных языков с момента появления плюсов и добавления средств ООП в Аду дальнейшее развитие стало просто неперспективно - существующие библиотеки на них можно точно так же использовать и в плюсах, а впихивание средств аналогичных плюсовым в их синтаксис приведет к полному перекраиванию языка - т.е. по факту проектированию нового, который априори не будет лучше уже существующего С++ - развитие плюсов упирается в первую очередь в потолок известных концепций построения абстракций, а не в невозможность их описания средствами синтаксиса.

Добавлено через 5 минут

Сообщение от COKPOWEHEU Как минимум, потому что одну и ту же задачу на С++ скорее всего будут решать в ООП стиле, а на Си - в процедурном, то есть сам подход будет разным

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

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

Добавлено через 11 минут

Сообщение от COKPOWEHEU не занимаясь оверинжинирингом

Оверинжиниринг - это плодить мульен вариантов решений для частных случаев, вместо одного универсального решения.

Добавлено через 1 минуту

Сообщение от COKPOWEHEU объем дистрибутива

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

Добавлено через 2 минуты

Сообщение от COKPOWEHEU язык скрывает реализацию строк, файлов, потоков и процессов от программиста, не то что мешая, а прямо запрещая вмешиваться в низкий уровень

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

0

Сообщение от Fulcrum_013 <Очередной поток бреда про фундаментальные недостатки всех языков кроме С++>

Общие соображения это, конечно, хорошо. А вот если бы они еще и практикой подтверждались...

Сообщение от Fulcrum_013 ООП - это методология проектирования а не стиль написания кода. При этом в плане реализации это абсолютно естественное развитие процедурного стиля.

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

Сообщение от Fulcrum_013 Оверинжиниринг - это плодить мульен решений для частных случаев, вместо одного универсального решения.

А равно и пытаться с нуля написать абсолютно универсальную софтину.
Еще раз: сначала задачу решают "хоть как-нибудь", потом рефакторят, выносят общий функционал в библиотеки для последующего переиспользования. С наскоку мало-мальски сложную программу написать невозможно.
--
Так что там со скоростями роста ядер разных ОС?
Что со ссылкой на "правильное" по вашему мнению ядро?
Что с объемом дистрибутивов, функционалом и требованиями?
Что с требованиями к языкам, включающим различную квалификацию программистов (а то и не-программистов)?

Добавлено через 5 минут

Сообщение от Fulcrum_013 Каким боком объем дистрибутива соотносится с объемом кода и продуктивности языка? А тем более при настолько гигантском разрыве в плане того что именно включено в дистрибутив.

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

Сообщение от Fulcrum_013 Это задача библиотек а не языка. При этом даже в баше всем этим занимаются внешние библиотеки написанные на универсальном языке.

Не угадали, в bash вообще нет библиотек, ни внешних, ни внутренних. Функциональность там меняется по-другому.

0