В моей семье главным мемом из игр стало "Эцио, сюда, я здесь!",- явно мало кто вспомнит. Из реплик "рабов" я регулярно вспоминаю не war3, а Majesty - вот где была божественная русская озвучка. Ну и как не вспомнить не из игры, но напрямую основанное на мемах из игр "Отличный денёк для рыбалки, хэ-хэй!"
А просто самому ручками вбить в дипсик за бесплатно?
Я вот не могу перейти эту грань, чтобы у меня llm сидела в ide. Пробовал локальную, был мрак лютый. Мне нравится, когда ты сам выдаешь ей контекст, который считаешь нужным. Да, много копипаста, да, периодически приходится делать "пресеты" описательные. Зато полный контроль. Плюс дисциплинирует, потому что не лезешь в llm за каждым чихом, что очень опасно. Мозг же стремится вообще не думать. А если вообще не думать с llm, там такой снежный ком оверинжениринга и технического долга тут же начинает расти, что в какой-то момент, когда волшебная кнопка "ляляльмика, почини пожалуйста" перестанет работать, сам уже вообще ничего не разгребешь.
Спасибо за подробный разбор. Возвращаться в angular после года с vue мы, конечно, не будем. )
Для меня переход с первого на второй был сравним с переходом с многолетнего написания кода на плюсах на typescript, где вместо выбирания часами подходящих для задачи языковых конструкций, у вас есть function, interface, async/await, и все. До сих пор воздеваю руки к небу с благодарными криками "А что, так можно было?!" И вот с ангуляром также - день уходит на то, чтобы понять, как собрать пару вызовов на бэк с помощью rxjs в что-то удобоваримое, а уже через неделю смотришь на этот магический код и не понимаешь в нем ни хрена. А сколько времени ушло на отладку потери реактивности в виджетах. Или реактивные формы, которые имеют настолько тупорылый интерфейс, что я их по факту никогда не использовал, хотя это типа база ангуляра. )
Signals - интересная идея, но поздно. После элегантности и простоты Vue3 возвращаться к Angular, даже если больше никогда не придется использовать ни одного оператора Rxjs, все равно не хочется )
Для меня это всегда был один из самых простых и понятных принципов, и никаких схем классов для него не нужно. Просто в реальной разработке, допустим, какого-то железа, происходит следующая ситуация, если разработка ведётся итеративно без плана. Разработчик драйвера устройства пишет код и интерфейс драйвера, как он его видит, со всеми ограничениями физическими и т.п. И этот интерфейс переусложнен. Там нужно вызвать метод "дрыгнуть ножкой АЦП", потом прождать 50 мс и т.п. Эта информация вообще не нужна разработчику управляющей программы, для него конечное устройство должно просто иметь пару методов вроде задал - получил и все. Исходя из этого он делает архитектуру. И принцип инверсии зависимостей - это то, что разработчик всей системы должен прийти к разработчику драйвера и дать ему интерфейс, которому тот должен соответствовать, а если тому кажется, что это невозможно, написать его за него, а не наоборот. В классах это и получается то, что Вы написали.
С одной стороны да, с другой нет. Я начинал со вторых Дисайплов в детстве, и они мне не очень нравились (на фоне тех же 3-х героев). А вот первых Дисайплов я увидел впервые в 20 лет, когда это вроде была уже очень устаревшая игра. Но как же мне она зашла, насколько же графика и стиль там были круче чем во второй, эти анимации заклинаний на карте.. Да, разрешение текстур небольшое, но зато какое оно все классное. Что касается героев, четвертые в детстве тоже совсем не заходили - их и комп нормально не тянул, валились, и что там происходит, было совсем непонятно. А вот во взрослом возрасте они тоже весьма зашли. Да, это совсем другая игра. Которую портят только дико некрасивые замки и слишком мелкая сетка в битве, но при этом она все равно играбельная и реиграбельная. Что не скажешь о пятой. Где красивые замки, классные юниты, интересная прокачка, но блин карты приключений по сути нет - она визуально хуже, чем во вторых (полностью устарела за несколько лет), по контенту тоже меньше, и при этом ее ещё и вертеть постоянно надо! Была бы карта пятых устроена по принципу четвёртых (3д сохранённое в изометрию), может быть, была бы лучшая игра в серии.
Очень долго писал на Ангуляре, к rxjs так и не привык, каждый раз смотришь на какую-то магию в коде и не можешь вспомнить, как она работает. Это главное из-за чего не хочется больше Ангуляром пользоваться. Вью в первый раз увидел когда был переход с angular.js на Angular2, последний казался крайне перспективным, а Вью, хоть и хорошеньким, но не впечатлил. В прошлом году взялся за Вью снова - делал свой проект месяца полтора, а там Composition API просто сказка после ангулярных сервисов. Кроме тормозного Nuxt (в итоге его бросил и делал все на Vite) у меня нет никаких претензий к экосистеме, документации и т.п., все просто отлично, следующий коммерческий проект спокойно бы делал на нем. Что касается реакта, мне всегда был отвратителен его линукс вэй подход (собирай тысячу пакетов как знаешь) и его организация кода из-за jsx, и мне очень жаль, что он "победил"
Вот вроде все хочется в Rust, но смотришь как на нем выглядит реальный код (вот эта смесь такого подхода к именованию и синтаксиса языка) и думаешь, ну нормально же все на typescript пишу. Непреходящее ощущение от Rust, что это как C++ std 2.0
У меня первое прозрение произошло, когда я после стандартной библиотеки стал Qt использовать. Вот это вот "а что, можно было просто str.split("/") написать?" Второе - когда перешёл на web и стал писать на javascript/typescript. Помню, какое снисходительное, даже пренебрежительное отношение в плюсовой среде было к javascript. А я как перешёл, просто выпал с того, что мне для того, чтобы писать вообще весь код достаточно одной языковой конструкции function. Что задачи, для которых я бы городил вспомогательные виртуальные классы, какие-то перегрузки, шаблонную магию, они решаются как бы автоматически, просто написал две строчки, следишь за тем, что написал, и все.
Не знаю, что я делаю не так, но за 8 лет работы full-stack я ни разу не влетал ни на один из приведенных багов. Единственное, что могу вспомнить, на чем попадался пару раз, это проверка, что поле имеет значение, а там 0 лежит и проверка выдает ложный результат. Зато вот сколько костылей и выстрелов в ногу у меня было за годы использования плюсов до этого, не сосчитать. Самое главное - сотни бессмысленных конструкций, тысячи строк нагромождений наследств, шаблонов и все ради того, чтобы где-то в одном месте кода можно было бы не заморачиваться над тем, а какой у меня сейчас там тип или объект передается. Просто годы, уходящие на то, чтобы понять, что код в стиле стандартной библиотеки - это не круто, это не показатель классного программиста, а просто абстрактные ментальные упражнения, откровенный эквилибристичемский мусор, который нужно забыть и никогда так не делать в реальной разработке. А после этого приходишь в javascript/typescript, у тебя есть function, которая и объект, и класс, и функция, и замыкание, у тебя есть async/await, и все, по факту это все, что нужно, чтобы решать все свои задачи.
Или javascript-way — это собрать некое подмножество хорошо удавшихся вещей, а про остальные сделать вид, будто их не существует?
Именно. javascript очень повезло тем, что в него не стесняются вводить хорошее и новое, по сути отказываясь от старого. И javascript поразителен тем, что для того чтобы на нем писать адекватный код, достаточно знать всего три вещи: как объявить функцию/замыкание/класс/объект (используя всего одну языковую конструкцию), что такое async/await, и что такое Typescript.
Я много лет потратил на изучение С++. Каждый год чувствовал, что вот теперь я что-то понимаю. И каждый раз решая простейшую задачу, которая обычно сводится к банальному «вызови мне то, пока я сам не знаю что» городил многоэтажные конструкции из наследования, шаблонов, а порой и директив препроцессора… Радовался, как у меня тут все безопасно вызывается. Ухмылялся, читая статьи про javascript вроде «посмотрите на это уродство — не укажите radix в parseInt и все, не оберетесь»,- и почему-то забывая, насколько уродливо та же операция делается в С++.
Вот Вам приходилось на С++ строку разбить на подстроки, если разделитель не пробел? Как Вы думаете, там это выглядит, str.split(x)? Как бы не так. Нужно написать десяток строк магии перенаправления одних потоков ввода-вывода в другие, посмотрев на которые человек, даже знающий С++, не сразу скажет, что они делают. И там вся стандартная библиотека такая. И поколения программистов еще умудряются этим гордиться. Что они поняли и выучили эту хрень. А самое грустное, следовать подобному стилю. Что написать str.split(x) — это по какой-то причине жутко не эффективно, потоконебезопасно, и вообще придумано для домохозяек, которые нормальный язык освоить не могут.
А я теперь стал «домохозяйкой» и последние три года пишу на javascript. Он меня радует каждый день. Меня в нем ничего не бесит. Потому что все, что могло бы бесить, можно просто не использовать ("===" почему-то не бесит, честно). И эта возможность поразительна.
И поэтому я уверен, что если бы мне сейчас предложили научить человека с улицы не писать говнокод, я бы учил его javascript. Потому что грамматику языка, которую он будет использовать 95% времени, можно объяснить за два часа, а все оставшееся время посвятить тому, что такое говнокод и как его не писать. В то время как с С++ новичок бы просто утонул в виртуальных деструкторах и итераторах, и там вообще первые пару лет было бы не до обсуждения, что такое говнокод, а что нет.
Можно возразить, что дескать, сравнил теплое с зеленым, но ведь статья как раз об этом, с посылом — «Ох, как круто, сейчас запилим наш любимый [подставить название языка] в браузер и заживем!».
Я ничего не имею против того, чтобы у студентов развивать абстрактное мышление, это хорошо.
Но давайте представим, как Вашу замечательную универсальную шаблонную функцию использовать на практике.
Немного утрируя, но допустим, пришел к Вам заказчик и говорит:
— А чем это, батенька, ты занимался неделю?
— (Гордо) Создал универсальную функцию разбивания всего на все с минимум оверхэда
— ?
— Ну в стандартной библиотеке нет такой функции. Кстати, вызывать ее достаточно легко: split(str.begin(), str.end(), sep, [&]([не прошло цензуру]) { [не прошло цензуру] })
— ***, мне нужно было разделить «Вася Пупкин» на имя и фамилию, чем ты занимался?!
C++ — это как большая качественная головоломка. Людям с аналитическим складом с ней очень интересно. Но чтобы решить конкретную задачу, нужен эргономичный инструмент, а не головоломка. Если мне нужно строку разбить на подстроки, используя символ или строку как разделитель (что ну очень попсовая задача), я хочу написать str.split(delimiter), это абсолютно естественно. Но почему-то в С++ это не так. Достаточно вбить в гугл how to split a string in C++, чтобы осознать насколько далеко это не так. И мне совершенно непонятно, почему это не так. И на мой взгляд, этому нет никаких оправданий.
раньше вы считали, что на C++ нужно писать все, теперь вы считаете, что на нем не нужно писать ничего
Где я такое писал?
Я написал, что лично я постараюсь к С++ больше никогда не возвращаться. Как и к embedded. Хотя это мои личные пристрастия, я все равно подробно написал, почему для меня это так. Я совершенно четко понимаю, что в мире миллионы С++ разработчиков, триллионы legacy кода на С++, и ни сегодня ни завтра это никуда не денется. Так же как кучи процессоров и RTOS систем, для которых есть только С библиотеки, кучи графических и игровых движков и т.п. Но я считаю, что это потому, что так исторически сложилось, а не потому, что С++ лучше альтернатив. Если бы сейчас я выбирал язык под тот же круг задач, что я выполнял раньше (разработка управляющих программ для научных лазеров, например), я бы всеми силами постарался избежать использования С++, если это от меня зависит, и учил бы Rust. например.
Что в своем оригинальном сообщении я считаю реальностью, общей для всех — это полная ущербность стандартной библиотеки, которая сильно испортила общее направление развития языка. Я просто в принципе не вижу задач, для которых ее можно использовать (ну, разумеется, кроме поддержки legacy, где она уже используется). Если у вас есть нет сильного ограничения по ресурсам, и важно время разработки — Qt и подобное гораздо лучше. Если есть ограничения по ресурсам (например, embedded), то ее опять нельзя использовать, потому что исключения — это непозволительная роскошь. В итоге тысячи проектов, где люди пишут с нуля свои собственные контейнеры, функциональщину и прочее.
Да очень просто цена считается. Вот есть компания, ей нужно обеспечить бизнес процесс для сотрудников. Ее интерес — чтобы сотрудники имели заданный интерфейс взаимодействия друг с другом, чтобы работать эффективно, не тратить кучу времени на пересылку емейлов туда-сюда и иметь безопасный доступ к данным, ведь большая часть из них — еще и фрилансеры (переводчики, корректоры и т.п.). А еще хорошо бы знать, чем они там занимаются.
Для компании делается веб приложение. AWS бэкенд для него, при порядка 100 сотрудников в системе, обходится в 200$ в месяц, из них большинство уходит на базу данных. Ключевой для Вас момент — вычисления в Lambda на javascript — забирают 15$. Фронт энд запускается на любом обычном компьютере в браузере — это все что волнует компанию об его эффективности.
Разумеется, в такой ситуации самое дорогое для компании — это зарплата разработчика и скорость разработки. Поэтому на С++ такое никто не делает (хотя вроде ничего не мешало сделать в Lambda поддержку С++, это же чистые вычисления! Но нет же — с удивлением обнаруживаем там только Java, Go, PowerShell, Node.js, C#, Python и Ruby).
Ну еще бы, ведь к многопоточности это не имеет абсолютно никакого отношения. Расскажите мне, пожалуйста, как с помощью async/await распараллелить вычислительную задачу.
Вроде специально многопоточность в кавычки взял, нет, не помогло. Да, физически это к многопоточности не имеет ни малейшего отношения. А как часто Вам нужна именно физическая многопоточность? Чаще всего нужна многопоточность логическая — вот сейчас мне нужно делать А и Б одновременно, и чтобы ни одно из них не зависило от другого. async/await — это оно и есть. А вот как раз вычислительная задача с точки зрения конечного пользователя — это что-то неделимое, логически ему нужен просто конечный результат.
Начать что?
Благодаря тому, что я выучил что-то совсем другое и избавился от ощущения, что С++ это центр вселенной, я работаю на заказчиков по всему миру, и я очень доволен. Уровень заработков у меня возрос в несколько раз. Где упущенные возможности-то? :)
Когда-то разрабатывал только на С++ и был большим фанатом языка, писал для Embedded и библиотеки. Радовался уникальным пятиэтажным сочетаниям разноплановых языковых конструкций, а порой и макросов, которые позволяли мне получить гибкое решение для очевидных логических задач в стиле «вызови мне то, пока еще не знаю что». Каждый год чувствовал, что ну вот теперь-то я прокачался в языке — то OOP то templates, то Design Patterns, то S.O.L.I.D., то еще чего… Другие языки периодически посматривал, но как-то они не цепляли — ни Java, ни C# ни Python. А потом решил перейти на удаленную разработку, оказалось, что на С++ это сложно, начал учить web, и естественно javascript. А в javascript вдруг оказалось, что 90% всех моих логических задач решает то, что функция — это одновременно класс, объект, замыкание и экземпляр. То есть всего одна гибкая языковая конструкция решает все задачи. Добавьте к этому async/await для «многопоточности», для понимания которой кроме этих двух слов ничего не нужно. Добавьте typescript только, чтобы объявлять интерфейсы, которые так и так где-то все равно пришлось бы объявлять для документации, и которые при этом позволяют отлавливать ошибки рано, чем так гордится С++. И по сути, это все, что нужно держать в голове, чтобы писать на языке, решая конкретные бизнес задачи как full-stack разработчик, а не воображаемые проблемы в стиле «ой, у меня тут инкапсуляция нарушена, кто-то потом, используя мой код, сможет выстрелить себе в ногу».
Но что меня больше всего всегда выводило в С++, даже когда я только на нем и писал, это, разумеется стандартная библиотека. Написанная не для того, чтобы ее использовали. А как будто, чтобы показать всем: «Смотри, как я могу!»,- как ребенок в песочнице. Которая задала целый тренд мышлению С++ программистов совершенно не в том направлении, породив еще более форменное уродство под названием boost. И когда появился Qt — с человеческими интерфейсами (я, разумеется, не имею в виду UI, я имею в виду интерфейсы библиотеки), написанный для людей, он уже на этот тренд никак особо не повлиял.
Поэтому развивается С++ семимильными шагами или не развивается, мне как-то совершенно наплевать. Если придется возвращаться к программированию, где нужно думать не только об алгоритмической, но и других видах оптимизаций, я определенно начну учить Rust. Или тот же C#, если его допилили за эти годы. Но никак не в плюсы.
Очень какие-то радостные цифры пробега получились.
Колесо KS-14D, вес 70кг. Пробег до заряда 30-40% (что, на самом деле 10-15% оставшегося пробега и на маленькой скорости) около 15км.
Как и многие здесь, долго маялся с выбором в октябре, в итоге взял 750Ti…
Серьезно.
При условно неограниченном бюджете на апдейт.
Если бы производителем не была обрублена возможность ставить их в SLI, обновил бы материнку, и поставил две.
Вот так выглядит мое мнение о новинках NVIDIA и их соотношении цена/производительность/энергопотребление.
В моей семье главным мемом из игр стало "Эцио, сюда, я здесь!",- явно мало кто вспомнит. Из реплик "рабов" я регулярно вспоминаю не war3, а Majesty - вот где была божественная русская озвучка. Ну и как не вспомнить не из игры, но напрямую основанное на мемах из игр "Отличный денёк для рыбалки, хэ-хэй!"
А просто самому ручками вбить в дипсик за бесплатно?
Я вот не могу перейти эту грань, чтобы у меня llm сидела в ide. Пробовал локальную, был мрак лютый. Мне нравится, когда ты сам выдаешь ей контекст, который считаешь нужным. Да, много копипаста, да, периодически приходится делать "пресеты" описательные. Зато полный контроль. Плюс дисциплинирует, потому что не лезешь в llm за каждым чихом, что очень опасно. Мозг же стремится вообще не думать. А если вообще не думать с llm, там такой снежный ком оверинжениринга и технического долга тут же начинает расти, что в какой-то момент, когда волшебная кнопка "ляляльмика, почини пожалуйста" перестанет работать, сам уже вообще ничего не разгребешь.
Прекрасная работа) Ещё бы хорошо локально такое запускать на ноутбуке по своей базе знаний ;)
Спасибо за подробный разбор. Возвращаться в angular после года с vue мы, конечно, не будем. )
Для меня переход с первого на второй был сравним с переходом с многолетнего написания кода на плюсах на typescript, где вместо выбирания часами подходящих для задачи языковых конструкций, у вас есть function, interface, async/await, и все. До сих пор воздеваю руки к небу с благодарными криками "А что, так можно было?!" И вот с ангуляром также - день уходит на то, чтобы понять, как собрать пару вызовов на бэк с помощью rxjs в что-то удобоваримое, а уже через неделю смотришь на этот магический код и не понимаешь в нем ни хрена. А сколько времени ушло на отладку потери реактивности в виджетах. Или реактивные формы, которые имеют настолько тупорылый интерфейс, что я их по факту никогда не использовал, хотя это типа база ангуляра. )
Signals - интересная идея, но поздно. После элегантности и простоты Vue3 возвращаться к Angular, даже если больше никогда не придется использовать ни одного оператора Rxjs, все равно не хочется )
Для меня это всегда был один из самых простых и понятных принципов, и никаких схем классов для него не нужно. Просто в реальной разработке, допустим, какого-то железа, происходит следующая ситуация, если разработка ведётся итеративно без плана. Разработчик драйвера устройства пишет код и интерфейс драйвера, как он его видит, со всеми ограничениями физическими и т.п. И этот интерфейс переусложнен. Там нужно вызвать метод "дрыгнуть ножкой АЦП", потом прождать 50 мс и т.п. Эта информация вообще не нужна разработчику управляющей программы, для него конечное устройство должно просто иметь пару методов вроде задал - получил и все. Исходя из этого он делает архитектуру. И принцип инверсии зависимостей - это то, что разработчик всей системы должен прийти к разработчику драйвера и дать ему интерфейс, которому тот должен соответствовать, а если тому кажется, что это невозможно, написать его за него, а не наоборот. В классах это и получается то, что Вы написали.
С одной стороны да, с другой нет. Я начинал со вторых Дисайплов в детстве, и они мне не очень нравились (на фоне тех же 3-х героев). А вот первых Дисайплов я увидел впервые в 20 лет, когда это вроде была уже очень устаревшая игра. Но как же мне она зашла, насколько же графика и стиль там были круче чем во второй, эти анимации заклинаний на карте.. Да, разрешение текстур небольшое, но зато какое оно все классное. Что касается героев, четвертые в детстве тоже совсем не заходили - их и комп нормально не тянул, валились, и что там происходит, было совсем непонятно. А вот во взрослом возрасте они тоже весьма зашли. Да, это совсем другая игра. Которую портят только дико некрасивые замки и слишком мелкая сетка в битве, но при этом она все равно играбельная и реиграбельная. Что не скажешь о пятой. Где красивые замки, классные юниты, интересная прокачка, но блин карты приключений по сути нет - она визуально хуже, чем во вторых (полностью устарела за несколько лет), по контенту тоже меньше, и при этом ее ещё и вертеть постоянно надо! Была бы карта пятых устроена по принципу четвёртых (3д сохранённое в изометрию), может быть, была бы лучшая игра в серии.
Очень долго писал на Ангуляре, к rxjs так и не привык, каждый раз смотришь на какую-то магию в коде и не можешь вспомнить, как она работает. Это главное из-за чего не хочется больше Ангуляром пользоваться. Вью в первый раз увидел когда был переход с angular.js на Angular2, последний казался крайне перспективным, а Вью, хоть и хорошеньким, но не впечатлил. В прошлом году взялся за Вью снова - делал свой проект месяца полтора, а там Composition API просто сказка после ангулярных сервисов. Кроме тормозного Nuxt (в итоге его бросил и делал все на Vite) у меня нет никаких претензий к экосистеме, документации и т.п., все просто отлично, следующий коммерческий проект спокойно бы делал на нем. Что касается реакта, мне всегда был отвратителен его линукс вэй подход (собирай тысячу пакетов как знаешь) и его организация кода из-за jsx, и мне очень жаль, что он "победил"
Вот вроде все хочется в Rust, но смотришь как на нем выглядит реальный код (вот эта смесь такого подхода к именованию и синтаксиса языка) и думаешь, ну нормально же все на typescript пишу. Непреходящее ощущение от Rust, что это как C++ std 2.0
У меня первое прозрение произошло, когда я после стандартной библиотеки стал Qt использовать. Вот это вот "а что, можно было просто str.split("/") написать?" Второе - когда перешёл на web и стал писать на javascript/typescript. Помню, какое снисходительное, даже пренебрежительное отношение в плюсовой среде было к javascript. А я как перешёл, просто выпал с того, что мне для того, чтобы писать вообще весь код достаточно одной языковой конструкции function. Что задачи, для которых я бы городил вспомогательные виртуальные классы, какие-то перегрузки, шаблонную магию, они решаются как бы автоматически, просто написал две строчки, следишь за тем, что написал, и все.
Не знаю, что я делаю не так, но за 8 лет работы full-stack я ни разу не влетал ни на один из приведенных багов. Единственное, что могу вспомнить, на чем попадался пару раз, это проверка, что поле имеет значение, а там 0 лежит и проверка выдает ложный результат. Зато вот сколько костылей и выстрелов в ногу у меня было за годы использования плюсов до этого, не сосчитать. Самое главное - сотни бессмысленных конструкций, тысячи строк нагромождений наследств, шаблонов и все ради того, чтобы где-то в одном месте кода можно было бы не заморачиваться над тем, а какой у меня сейчас там тип или объект передается. Просто годы, уходящие на то, чтобы понять, что код в стиле стандартной библиотеки - это не круто, это не показатель классного программиста, а просто абстрактные ментальные упражнения, откровенный эквилибристичемский мусор, который нужно забыть и никогда так не делать в реальной разработке. А после этого приходишь в javascript/typescript, у тебя есть function, которая и объект, и класс, и функция, и замыкание, у тебя есть async/await, и все, по факту это все, что нужно, чтобы решать все свои задачи.
Именно. javascript очень повезло тем, что в него не стесняются вводить хорошее и новое, по сути отказываясь от старого. И javascript поразителен тем, что для того чтобы на нем писать адекватный код, достаточно знать всего три вещи: как объявить функцию/замыкание/класс/объект (используя всего одну языковую конструкцию), что такое async/await, и что такое Typescript.
Я много лет потратил на изучение С++. Каждый год чувствовал, что вот теперь я что-то понимаю. И каждый раз решая простейшую задачу, которая обычно сводится к банальному «вызови мне то, пока я сам не знаю что» городил многоэтажные конструкции из наследования, шаблонов, а порой и директив препроцессора… Радовался, как у меня тут все безопасно вызывается. Ухмылялся, читая статьи про javascript вроде «посмотрите на это уродство — не укажите radix в parseInt и все, не оберетесь»,- и почему-то забывая, насколько уродливо та же операция делается в С++.
Вот Вам приходилось на С++ строку разбить на подстроки, если разделитель не пробел? Как Вы думаете, там это выглядит, str.split(x)? Как бы не так. Нужно написать десяток строк магии перенаправления одних потоков ввода-вывода в другие, посмотрев на которые человек, даже знающий С++, не сразу скажет, что они делают. И там вся стандартная библиотека такая. И поколения программистов еще умудряются этим гордиться. Что они поняли и выучили эту хрень. А самое грустное, следовать подобному стилю. Что написать str.split(x) — это по какой-то причине жутко не эффективно, потоконебезопасно, и вообще придумано для домохозяек, которые нормальный язык освоить не могут.
А я теперь стал «домохозяйкой» и последние три года пишу на javascript. Он меня радует каждый день. Меня в нем ничего не бесит. Потому что все, что могло бы бесить, можно просто не использовать ("===" почему-то не бесит, честно). И эта возможность поразительна.
И поэтому я уверен, что если бы мне сейчас предложили научить человека с улицы не писать говнокод, я бы учил его javascript. Потому что грамматику языка, которую он будет использовать 95% времени, можно объяснить за два часа, а все оставшееся время посвятить тому, что такое говнокод и как его не писать. В то время как с С++ новичок бы просто утонул в виртуальных деструкторах и итераторах, и там вообще первые пару лет было бы не до обсуждения, что такое говнокод, а что нет.
Можно возразить, что дескать, сравнил теплое с зеленым, но ведь статья как раз об этом, с посылом — «Ох, как круто, сейчас запилим наш любимый [подставить название языка] в браузер и заживем!».
Но давайте представим, как Вашу замечательную универсальную шаблонную функцию использовать на практике.
Немного утрируя, но допустим, пришел к Вам заказчик и говорит:
— А чем это, батенька, ты занимался неделю?
— (Гордо) Создал универсальную функцию разбивания всего на все с минимум оверхэда
— ?
— Ну в стандартной библиотеке нет такой функции. Кстати, вызывать ее достаточно легко: split(str.begin(), str.end(), sep, [&]([не прошло цензуру]) { [не прошло цензуру] })
— ***, мне нужно было разделить «Вася Пупкин» на имя и фамилию, чем ты занимался?!
Где я такое писал?
Я написал, что лично я постараюсь к С++ больше никогда не возвращаться. Как и к embedded. Хотя это мои личные пристрастия, я все равно подробно написал, почему для меня это так. Я совершенно четко понимаю, что в мире миллионы С++ разработчиков, триллионы legacy кода на С++, и ни сегодня ни завтра это никуда не денется. Так же как кучи процессоров и RTOS систем, для которых есть только С библиотеки, кучи графических и игровых движков и т.п. Но я считаю, что это потому, что так исторически сложилось, а не потому, что С++ лучше альтернатив. Если бы сейчас я выбирал язык под тот же круг задач, что я выполнял раньше (разработка управляющих программ для научных лазеров, например), я бы всеми силами постарался избежать использования С++, если это от меня зависит, и учил бы Rust. например.
Что в своем оригинальном сообщении я считаю реальностью, общей для всех — это полная ущербность стандартной библиотеки, которая сильно испортила общее направление развития языка. Я просто в принципе не вижу задач, для которых ее можно использовать (ну, разумеется, кроме поддержки legacy, где она уже используется). Если у вас есть нет сильного ограничения по ресурсам, и важно время разработки — Qt и подобное гораздо лучше. Если есть ограничения по ресурсам (например, embedded), то ее опять нельзя использовать, потому что исключения — это непозволительная роскошь. В итоге тысячи проектов, где люди пишут с нуля свои собственные контейнеры, функциональщину и прочее.
Да очень просто цена считается. Вот есть компания, ей нужно обеспечить бизнес процесс для сотрудников. Ее интерес — чтобы сотрудники имели заданный интерфейс взаимодействия друг с другом, чтобы работать эффективно, не тратить кучу времени на пересылку емейлов туда-сюда и иметь безопасный доступ к данным, ведь большая часть из них — еще и фрилансеры (переводчики, корректоры и т.п.). А еще хорошо бы знать, чем они там занимаются.
Для компании делается веб приложение. AWS бэкенд для него, при порядка 100 сотрудников в системе, обходится в 200$ в месяц, из них большинство уходит на базу данных. Ключевой для Вас момент — вычисления в Lambda на javascript — забирают 15$. Фронт энд запускается на любом обычном компьютере в браузере — это все что волнует компанию об его эффективности.
Разумеется, в такой ситуации самое дорогое для компании — это зарплата разработчика и скорость разработки. Поэтому на С++ такое никто не делает (хотя вроде ничего не мешало сделать в Lambda поддержку С++, это же чистые вычисления! Но нет же — с удивлением обнаруживаем там только Java, Go, PowerShell, Node.js, C#, Python и Ruby).
Вроде специально многопоточность в кавычки взял, нет, не помогло. Да, физически это к многопоточности не имеет ни малейшего отношения. А как часто Вам нужна именно физическая многопоточность? Чаще всего нужна многопоточность логическая — вот сейчас мне нужно делать А и Б одновременно, и чтобы ни одно из них не зависило от другого. async/await — это оно и есть. А вот как раз вычислительная задача с точки зрения конечного пользователя — это что-то неделимое, логически ему нужен просто конечный результат.
Благодаря тому, что я выучил что-то совсем другое и избавился от ощущения, что С++ это центр вселенной, я работаю на заказчиков по всему миру, и я очень доволен. Уровень заработков у меня возрос в несколько раз. Где упущенные возможности-то? :)
Но что меня больше всего всегда выводило в С++, даже когда я только на нем и писал, это, разумеется стандартная библиотека. Написанная не для того, чтобы ее использовали. А как будто, чтобы показать всем: «Смотри, как я могу!»,- как ребенок в песочнице. Которая задала целый тренд мышлению С++ программистов совершенно не в том направлении, породив еще более форменное уродство под названием boost. И когда появился Qt — с человеческими интерфейсами (я, разумеется, не имею в виду UI, я имею в виду интерфейсы библиотеки), написанный для людей, он уже на этот тренд никак особо не повлиял.
Поэтому развивается С++ семимильными шагами или не развивается, мне как-то совершенно наплевать. Если придется возвращаться к программированию, где нужно думать не только об алгоритмической, но и других видах оптимизаций, я определенно начну учить Rust. Или тот же C#, если его допилили за эти годы. Но никак не в плюсы.
Колесо KS-14D, вес 70кг. Пробег до заряда 30-40% (что, на самом деле 10-15% оставшегося пробега и на маленькой скорости) около 15км.
Серьезно.
При условно неограниченном бюджете на апдейт.
Если бы производителем не была обрублена возможность ставить их в SLI, обновил бы материнку, и поставил две.
Вот так выглядит мое мнение о новинках NVIDIA и их соотношении цена/производительность/энергопотребление.