![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Herb Sutter asks all the right questions:
“Why can’t I share C++ libraries even between my own internal teams without using the identical compiler and switch settings?” “Why are operating system APIs written in unsafe C, instead of C++?” “Why can’t I use std::string in a public shared library interface; it’s the C++ string, isn’t it?!”
http://herbsutter.com/2014/05/21/cppcon-my-proposed-talks-part-2/
Я вот чего не понимаю, эти ребята со Страуструпом во главе реально не понимают, что им просто нужен новый язык? Синтаксис плюсов был волосат еще до C++11, а теперь, после того как они туда напихали лямбд, райт вэлью референсов и прочего прочего, любой новичок 10 раз подумает зачем ему изучать весь этот зоопарк, а старички скажут что-то вроде "20 лет без этого жили и дальше проживем". Нереально запихнуть в язык все модные фишки и оставить синтаксис вменяемым. Люди не должны думать "о, замечательно, тут будет лямбда, только я посмотрю сколько закорючек и амперсандов мне нужно чтобы написать ее". Нельзя делать синтаксис сложнее чем у ближайших конкурентов. Я не спорю, что в C++11 много полезных и нужных новшеств, а в C++14 их еще лучше причешут, но как-то оно все не туда идет.
Логичнее было бы сделать новый язык, взять синтаксис тех же лямбд из жаваскрипта или си-шарпа, на уровне интерфейсов/компилятора сделать его легко стыкуемым с С++ и жить себе припеваючи! Хочешь гэрбэдж коллектор, лямбды, 'everything is an object' - юзай новый язык. Хочешь избавиться от оверхеда удобства быстрой разработки - пиши код на С++ и включай его из нового языка, компилятор позаботится об эффективности вставок. Это было бы офигенно удобное комбо.
А так - синтаксис расширяется, кода становится больше, а не меньше (что неправильно). Microsoft Compiler например научился нормально C++11 поддерживать только с 12-й версии, которая в октябре 2013 года вышла. Разработчики рвутся использовать новые фичи, но каждый компилятор реализует свой подсет новых фич, бустовые заимствования в STL делают бардак из состыковки старого кода и старого.
Я уже открыто коллегам говорю - не пытайтесь связать свое будущее только с С++. Несмотря на быстроту, портабельность и кучу легаси кода, язык упорно загоняют в какую-то жопу. Новичкам проще изучить жабу или си-шарп и уже через пару лет считаться неплохими спецами. В С++ человек лет только через пять перестает писать говнокод и может считаться вменяемым. В ситуации, когда работодатели уже не могут найти нормальных С++ программистов, а значит новые проекты будут начинать на чем-то еще, язык постепенно загнется (лет так через 10). И достаточно глупо надеяться что при этом специалисты по С++ сильно поднимутся в цене. Некоторый спрос будет, да, но случится как с перлом - старички забьют все вакантные позиции, а новых мест создаваться просто не будет.
Если на уровне "Cи с классами" язык был прост в изучении и сравнительно удобнее чистого Си, то на уровне "Си++ с блекджеком и прочим" - not so much. Учитывая вытеснение языка на embedded девайсы и критичные к математической производительности движки - плюсы плюсов становятся все менее очевидными.
“Why can’t I share C++ libraries even between my own internal teams without using the identical compiler and switch settings?” “Why are operating system APIs written in unsafe C, instead of C++?” “Why can’t I use std::string in a public shared library interface; it’s the C++ string, isn’t it?!”
http://herbsutter.com/2014/05/21/cppcon-my-proposed-talks-part-2/
Я вот чего не понимаю, эти ребята со Страуструпом во главе реально не понимают, что им просто нужен новый язык? Синтаксис плюсов был волосат еще до C++11, а теперь, после того как они туда напихали лямбд, райт вэлью референсов и прочего прочего, любой новичок 10 раз подумает зачем ему изучать весь этот зоопарк, а старички скажут что-то вроде "20 лет без этого жили и дальше проживем". Нереально запихнуть в язык все модные фишки и оставить синтаксис вменяемым. Люди не должны думать "о, замечательно, тут будет лямбда, только я посмотрю сколько закорючек и амперсандов мне нужно чтобы написать ее". Нельзя делать синтаксис сложнее чем у ближайших конкурентов. Я не спорю, что в C++11 много полезных и нужных новшеств, а в C++14 их еще лучше причешут, но как-то оно все не туда идет.
Логичнее было бы сделать новый язык, взять синтаксис тех же лямбд из жаваскрипта или си-шарпа, на уровне интерфейсов/компилятора сделать его легко стыкуемым с С++ и жить себе припеваючи! Хочешь гэрбэдж коллектор, лямбды, 'everything is an object' - юзай новый язык. Хочешь избавиться от оверхеда удобства быстрой разработки - пиши код на С++ и включай его из нового языка, компилятор позаботится об эффективности вставок. Это было бы офигенно удобное комбо.
А так - синтаксис расширяется, кода становится больше, а не меньше (что неправильно). Microsoft Compiler например научился нормально C++11 поддерживать только с 12-й версии, которая в октябре 2013 года вышла. Разработчики рвутся использовать новые фичи, но каждый компилятор реализует свой подсет новых фич, бустовые заимствования в STL делают бардак из состыковки старого кода и старого.
Я уже открыто коллегам говорю - не пытайтесь связать свое будущее только с С++. Несмотря на быстроту, портабельность и кучу легаси кода, язык упорно загоняют в какую-то жопу. Новичкам проще изучить жабу или си-шарп и уже через пару лет считаться неплохими спецами. В С++ человек лет только через пять перестает писать говнокод и может считаться вменяемым. В ситуации, когда работодатели уже не могут найти нормальных С++ программистов, а значит новые проекты будут начинать на чем-то еще, язык постепенно загнется (лет так через 10). И достаточно глупо надеяться что при этом специалисты по С++ сильно поднимутся в цене. Некоторый спрос будет, да, но случится как с перлом - старички забьют все вакантные позиции, а новых мест создаваться просто не будет.
Если на уровне "Cи с классами" язык был прост в изучении и сравнительно удобнее чистого Си, то на уровне "Си++ с блекджеком и прочим" - not so much. Учитывая вытеснение языка на embedded девайсы и критичные к математической производительности движки - плюсы плюсов становятся все менее очевидными.
