История изменений
Исправление SZT, (текущая версия) :
Усложнение C++ (нововведения в последних стандартах) не делает ненужным умение читать C++ cтарых стандартов. В итоге получается, что программисту на плюсах надо удерживать в голове больше информации. Переписывание C++ предыдущего стандарта на новый стандарт может быть попросту экономически неоправданным т.к. во первых не все программисты могут знать все новые фичи языка, во-вторых может так оказаться, что надо компилировать код каким-то нестандартным старым компилятором, который не умеет полностью в новые стандарты, и переписывание пойдет только во вред. И в третьих, я считаю что плюсы, обрастая этими новыми возможностями, неуклонно движутся мягко говоря в пропасть, и потому правильнее будет выбрать более полноценный язык высокого уровня.
Вернемся к примеру с GCC. Если изначально сишный код пытаться адаптировать (а не переписать с нуля) на плюсы, получается в итоге каша из двух языков, а для нормального modern C++ надо все это естественно переписывать. Но трудозатраты в таком случае будут сопоставимы с написанием компилятора вообще с нуля. Да и вообще, я не разделяю энтузиазма по поводу новых плюсовых стандартов. Пытаться сделать высокоуровневый язык на основе кроссплатформенного ассемблера, сохраняя при этом обратную совместимость с ним - не очень хорошая идея. С моей колокольни эти плюсы (сама идея сделать высокоуровневый язык на основе Си) выглядят примерно как попытка прикрутить к танку крылья и авиационный двигатель, чтоб он еще и летал. Да и нормальным высокоуровневым языком плюсы никогда не станут.
В коде на плюсах встречаются уязвимости, характерные для Си (выход за границу массива, всякие там use-after-free) чего нет например в Java или питоне. В плюсах нет (и скорее всего не будет) GC. В плюсах точно не будет никогда метапрограммирования(генерации нового кода) через манипуляции с AST на этапе компиляции и в рантайме(JIT). Плюсы на мой взгляд это вообще какая-то тупиковая ветвь, и чем скорее оно вымрет, тем лучше. Но как показывает практика, живучесть языка определяется еще и количеством написанного на нем кода (например программисты на Коболе до сих пор есть) и плюсы еще долго будут держаться благодаря легаси.
Ну возьмем достаточно простую задачу: допустим что надо мне считать в бигинтах, и хочу я читать формулы из stdin от пользовалетя вида x=a*c+b*c и чтоб был eval() который бы генерировал машинный код по этой формуле (без всяких стековых калькуляторов, мне надо чтоб быстро) и чтобы оптимзировало на уровне арифметических преобразований, например выражение x=a*c+b*c превращало в x=c*(a+b), выражение sqrt(a^2) становилось abs(a) и так далее, и компилировал бы чтобы в машинный код, чтобы я мог через эту формулу применить к множеству чисел. Пользователь дает таблицу
a=123, b=342, c=456;
a=777, b=333, c=666;
....
и программа должна посчитать x для каждой строки, притом сделать это быстро. Таблица может быть задана в каком-нибудь двоично-сериализованном виде, не обязательно в виде строк. Надо чтоб работало в виндовсе, линуксе, масосх, андроиде и на айпэдах всяких(на ARM). Как это сделать? Какими плюсовыми средствами предлагаете решать эту задачу? Нет таких средств, надо самому костылить какой-то JIT (тащить LLVM и куски компилятора с его кучей абстрактных представлений ради калькулятора попросту неоправданно). А какой-нибудь жаваскрипт или лисп эту проблему решает запросто, там есть eval(). Может это будет не так эффективно, как если кто-то будет городить кастомный JIT и писать опкоды в исполняемый сегмент памяти, потом оттуда что-то вызывать, зато это будет БЫСТРО и ИЗ КОРОБКИ. Разве высокоуровневый язык должен требовать таких выкрутасов? Высокоуровневость плюсов это миф. Но и низкоуровневым его назвать у меня язык не поворачивается. Язык Си еще можно с натяжкой назвать языком среднего(но ни в коем случае не низкого) уровня, а плюсы, плюсы вообще вне этих категорий. Это язык фиг-знает-какого-уровня, это сишка, которую подперли кривыми ООП-костылями, шаблонами(почти-препроцессором, который однако встроен в компилятор), constespr-ами и пр.
Исправление SZT, :
Усложнение C++ (нововведения в последних стандартах) не делает ненужным умение читать C++ cтарых стандартов. В итоге получается, что программисту на плюсах надо удерживать в голове больше информации. Переписывание C++ предыдущего стандарта на новый стандарт может быть попросту экономически неоправданным т.к. во первых не все программисты могут знать все новые фичи языка, во-вторых может так оказаться, что надо компилировать код каким-то нестандартным старым компилятором, который не умеет полностью в новые стандарты, и переписывание пойдет только во вред. И в третьих, я считаю что плюсы, обрастая этими новыми возможностями, неуклонно движутся мягко говоря в пропасть.
Вернемся к примеру с GCC. Если изначально сишный код пытаться адаптировать (а не переписать с нуля) на плюсы, получается в итоге каша из двух языков, а для нормального modern C++ надо все это естественно переписывать. Но трудозатраты в таком случае будут сопоставимы с написанием компилятора вообще с нуля. Да и вообще, я не разделяю энтузиазма по поводу новых плюсовых стандартов. Пытаться сделать высокоуровневый язык на основе кроссплатформенного ассемблера, сохраняя при этом обратную совместимость с ним - не очень хорошая идея. С моей колокольни эти плюсы (сама идея сделать высокоуровневый язык на основе Си) выглядят примерно как попытка прикрутить к танку крылья и авиационный двигатель, чтоб он еще и летал. Да и нормальным высокоуровневым языком плюсы никогда не станут.
В коде на плюсах встречаются уязвимости, характерные для Си (выход за границу массива, всякие там use-after-free) чего нет например в Java или питоне. В плюсах нет (и скорее всего не будет) GC. В плюсах точно не будет никогда метапрограммирования(генерации нового кода) через манипуляции с AST на этапе компиляции и в рантайме(JIT). Плюсы на мой взгляд это вообще какая-то тупиковая ветвь, и чем скорее оно вымрет, тем лучше. Но как показывает практика, живучесть языка определяется еще и количеством написанного на нем кода (например программисты на Коболе до сих пор есть) и плюсы еще долго будут держаться благодаря легаси.
Ну возьмем достаточно простую задачу: допустим что надо мне считать в бигинтах, и хочу я читать формулы из stdin от пользовалетя вида x=a*c+b*c и чтоб был eval() который бы генерировал машинный код по этой формуле (без всяких стековых калькуляторов, мне надо чтоб быстро) и чтобы оптимзировало на уровне арифметических преобразований, например выражение x=a*c+b*c превращало в x=c*(a+b), выражение sqrt(a^2) становилось abs(a) и так далее, и компилировал бы чтобы в машинный код, чтобы я мог через эту формулу применить к множеству чисел. Пользователь дает таблицу
a=123, b=342, c=456;
a=777, b=333, c=666;
....
и программа должна посчитать x для каждой строки, притом сделать это быстро. Таблица может быть задана в каком-нибудь двоично-сериализованном виде, не обязательно в виде строк. Надо чтоб работало в виндовсе, линуксе, масосх, андроиде и на айпэдах всяких(на ARM). Как это сделать? Какими плюсовыми средствами предлагаете решать эту задачу? Нет таких средств, надо самому костылить какой-то JIT (тащить LLVM и куски компилятора с его кучей абстрактных представлений ради калькулятора попросту неоправданно). А какой-нибудь жаваскрипт или лисп эту проблему решает запросто, там есть eval(). Может это будет не так эффективно, как если кто-то будет городить кастомный JIT и писать опкоды в исполняемый сегмент памяти, потом оттуда что-то вызывать, зато это будет БЫСТРО и ИЗ КОРОБКИ. Разве высокоуровневый язык должен требовать таких выкрутасов? Высокоуровневость плюсов это миф. Но и низкоуровневым его назвать у меня язык не поворачивается. Язык Си еще можно с натяжкой назвать языком среднего(но ни в коем случае не низкого) уровня, а плюсы, плюсы вообще вне этих категорий. Это язык фиг-знает-какого-уровня, это сишка, которую подперли кривыми ООП-костылями, шаблонами(почти-препроцессором, который однако встроен в компилятор), constespr-ами и пр.
Исходная версия SZT, :
Усложнение C++ (нововведения в последних стандартах) не делает ненужным умение читать C++ cтарых стандартов. В итоге получается, что программисту на плюсах надо удерживать в голове больше информации. Переписывание C++ предыдущего стандарта на новый стандарт может быть попросту экономически неоправданным т.к. во первых не все программисты могут знать все новые фичи языка, во-вторых может так оказаться, что надо компилировать код каким-то нестандартным старым компилятором, который не умеет полностью в новые стандарты, и переписывание пойдет только во вред. И в третьих, я считаю что плюсы, обрастая этими новыми возможностями, неуклонно движутся мягко говоря в пропасть.
Вернемся к примеру с GCC. Если изначально сишный код пытаться адаптировать (а не переписать с нуля) на плюсы, получается в итоге каша из двух языков, а для нормального modern C++ надо все это естественно переписывать. Но трудозатраты в таком случае будут сопоставимы с написанием компилятора вообще с нуля. Да и вообще, я не разделяю энтузиазма по поводу новых плюсовых стандартов. Пытаться сделать высокоуровневый язык на основе кроссплатформенного ассемблера, сохраняя при этом обратную совместимость с ним - не очень хорошая идея. С моей колокольни эти плюсы (сама идея сделать высокоуровневый язык на основе Си) выглядят примерно как попытка прикрутить к танку крылья и авиационный двигатель, чтоб он еще и летал. Да и нормальным высокоуровневым языком плюсы никогда не станут.
В коде на плюсах встречаются уязвимости, характерные для Си (выход за границу массива, всякие там use-after-free) чего нет например в Java или питоне. В плюсах нет (и скорее всего не будет) GC. В плюсах точно не будет никогда метапрограммирования(генерации нового кода) через манипуляции с AST на этапе компиляции и в рантайме(JIT). Плюсы на мой взгляд это вообще какая-то тупиковая ветвь, и чем скорее оно вымрет, тем лучше. Но как показывает практика, живучесть языка определяется еще и количеством написанного на нем кода (например программисты на Коболе до сих пор есть) и плюсы еще долго будут держаться благодаря легаси.
Ну возьмем достаточно простую задачу: допустим что надо мне считать в бигинтах, и хочу я читать формулы из stdin от пользовалетя вида x=a*c+b*c и чтоб был eval() который бы генерировал машинный код по этой формуле (без всяких стековых калькуляторов, мне надо чтоб быстро) и чтобы оптимзировало на уровне арифметических преобразований, например выражение x=a*c+b*c превращало в x=c*(a+b), выражение sqrt(a^2) становилось abs(a) и так далее, и компилировал бы чтобы в машинный код, чтобы я мог через эту формулу применить к множеству чисел. Пользователь дает таблицу a=123, b=342, c=456; a=777, b=333, c=666 .... и программа должна посчитать x для каждой строки, притом сделать это быстро. Таблица может быть задана в каком-нибудь двоично-сериализованном виде, не обязательно в виде строк. Надо чтоб работало в виндовсе, масосх, андроиде и на айпэдах всяких(на ARM). Как это сделать? Какими плюсовыми средствами предлагаете решать эту задачу? Нет таких средств, надо самому костылить какой-то JIT (тащить LLVM и куски компилятора с его кучей абстрактных представлений ради калькулятора попросту неоправданно). А какой-нибудь жаваскрипт или лисп эту проблему решает запросто, там есть eval(). Может это будет не так эффективно, как если кто-то будет городить кастомный JIT и писать опкоды в исполняемый сегмент памяти, потом оттуда что-то вызывать, зато это будет БЫСТРО и ИЗ КОРОБКИ. Разве высокоуровневый язык должен требовать таких выкрутасов? Высокоуровневость плюсюв это миф. Но и низкоуровневым его назвать у меня язык не поворачивается. Язык Си еще можно с натяжкой назвать языком среднего(но ни в коем случае не низкого) уровня, а плюсы, плюсы вообще вне этих категорий. Это язык фиг-знает-какого-уровня, это сишка, которую подперли кривыми ООП-костылями, шаблонами(почти-препроцессором, который однако встроен в компилятор,).