использовать его в качестве указателя, ссылки и аргумента шаблона никогда его не определяя.
Соответственно пользы от не полного типа будет минимум - нельзя к полям класса (структуры) обращаться. А у Вас в примере вложенная структура определена в определении структуры Foo (что почти тоже самое, что пытаться вызывать поле объявленного класса (структуры), а не его определения).
Как упоминал ранее - пост бесполезный, никаких противоречий в работе C++ в данном случае нет, а существование неполных типов ничего толком и не доказывает, да и использование их очень ограниченно.
Что значит "опционально"? Без определения структур (классов) доступ к полям, методам и вложенным классам будет недоступен. Вот пример кода, который может выдать ошибку:
Для компилятора MSVC этот код будет ошибочен. Как видно из этого примера в функцию fooCalc() передаётся указатель на структуру Foo. Внутри этой функции происходит обращение к атрибуту value (точнее - его попытка). Поскольку на момент определения функции fooCalc() компилятор не видит определения структуры Foo, то и какие там атрибуты и методы он тоже не знает, а потому кидает исключение "использование неопределённого типа "Foo"". Ну так вот отработал компилятор, не увидел определения структуры. И это по Вашему "опционально"? Это необходимо, если программист хочет добиться корректной работы своей программы.
Одно дело, когда программист пишет что-то такое (объявление функций с использованием объявления структуры):
Но совсем другое, когда программист решает использовать указатель на объявленную структуру в своём программном коде:
void fooCalc(Foo* item) {
item->value += 90;
}
Преобразования по типу:
struct Foo;
Foo* convert(void* f) {
return static_cast<Foo*>(f);
}
struct Foo {
int value = 0;
};
Действительно будут работать. Потому что тут явно не происходит обращения к полям структуры, а значит определения структуры на момент конвертации указателя на void к указателю на структуру Foo не требуется. Всё тут нормально работает (в контексте C++).
Всё встаёт на свои места, если считать, что вложенная структура (Foo::Bar) является частью определения структуры (Foo).
А почему автор решил, что такое поведение нелогично?
struct Foo;
struct Foo::Bar; // error: use of undefined type 'Foo'
Ведь по сути, первая строка здесь - это объявление структуры Foo, но никак не её определение. Определение этой структуры представлено ниже:
struct Foo {
struct Bar {
};
};
И до определения структуры Foo компилятор не знает о существовании вложенной структуры Bar, что логично. Если компилятор прочитает определение, то он найдёт эту структуру Bar через оператор разрешения области видимости ::.
Какой-то бесполезный пост... что называется "хотели поругать C++, а получилось как всегда ..."
Все эти Foo, Bar, а также мяукающие и лающие Cat : Animal / Dog : Animal это не примеры.
А что это по Вашему? Это самые простые, банальные примеры из возможных. Просто синтаксические конструкции, которые к чему-то реальному не приложены, вот и всё. А куда такие возможности девать - это дело уже программиста (он может ими даже и не воспользоваться).
С другой стороны приближается Carbon
А как же Zig, D, Nim, Julia? На них тоже навешивают ярлык "будущая замена Си и/или C++". Как по мне, так это лишняя трата времени постоянно мониторить существование и закат этих новых модных "убийц С/C++", которые приходят и уходят, а С/С++ как оставался, так и останется на своём месте ещё очень долгое время. Вытеснят ли его другие языки? Может быть. Но постоянно бегать с языка на язык, только потому что тот в чём-то лучше и на него навешивают ярлыки "убийц старых высокопроизводительных языков" - ну такое себе. Я сам этим "болел" и могу сказать, что это полный бред. Пусть взлетает Carbon, пусть на Rust перепишут Linux, а на Zig появятся высокопроизводительные игровые движки - фундаментальный C/C++ никуда не денется (и я знаю, что это разные языки).
Чтобы действительно объективно оценивать один язык и другой язык нужно иметь значительный опыт программирования на них обоих. Люди тратят годы только для освоения C++, причём не всегда качественное освоение. А кто-то его немного попробовал и сформировал своё "мнение" по первым десяти тысячам строк кода (или меньше). А технологии новые появляются каждый день, неделю и месяц...
Они возьмут плюсы каждый за свою ногу, потянут, и что останется?
Что останется? Низкая самооценка программистов, которые по верхам проходятся по новомодным ЯП в надежде "выгодно" вложиться в своё обучение, чтоб зарабатывать по 300к в наносекунду.
При том, что, ещё раз, очень спорной нужности вещь.
Так программист может её вообще не использовать. Есть пространства имён, которые спокойно заменяют вложенность классов. То, что нельзя предопределять имена вложенных классов - в общем-то логично, ведь по сути вложенная структура находится в определении структуры, а потому из объявления до неё нельзя добраться. Объявление тем и отличается от определения, что компилятор заранее может знать о существовании структуры/класса с таким именем, но не знать заранее его определения.
Это полезно в том случае, если имена разных структур (классов) совпадают и требуется сделать "аналогичную" структуру (класс), который предоставлял бы иные возможности.
Например:
// Без calc()
struct Bar {
int attrib = 1;
};
struct Foo {
// С calc()
struct Bar {
int attrib = 0;
int calc() {
return this->attrib * 2;
}
};
// Где-то может быть использована структура Bar с calc() ...
};
int main() {
Bar item1;
std::cout << item1.attrib << std::endl; // Ok
Foo::Bar item2;
std::cout << item2.calc() << std::endl; // Ok
// error: ‘struct Bar’ has no member named ‘calc’
std::cout << item1.calc() << std::endl;
}
Это самый очевидный пример использования вложенных структур (классов). Точно также это можно сделать и с помощью пространства имён.
Поэтому я есть активный участник процесса, его инициатор.
А точно ли Вы его инициатор, а не какие-то внешние процессы, которые под предлогом "революционной парадигмы" навязали Вам эту идею? Всякое может быть... Многие "вайбкодят" потому что искренне бояться их замены ИИ и нет в этом ничего такого... это уже наша обыденность.
так и вы тоже код не пишете
Как это так? То есть, Вы считаете, что вот это не код? (написал для примера основываясь на недавних задачах)
#ifdef LINUX
_cw.store(true);
std::unique_ptr<FILE, decltype(&pclose)> pipeStream(
popen(cmd.c_str(), "r"), close
);
#endif // LINUX
server.addHandler(HCODE1, funcHandlerWrapper());
// ...
std::lock_guard<std::mutex> lock(mut1);
CBOps::Operation1(static_cast<ClientSetting*>(ConfEnv::Settings), ...);
По-моему, это что ни на есть самый настоящий программный код. И он компилируется в более низкоуровневые инструкции, которые затем выполняются процессором (не путайте).
То, что компилятор переводит мой исходный код в более низкоуровневые инструкции никак не влияет на факт того, что это программный код (и не умиляет этот факт). Если уж углубляться, то можно сказать, что программисты - это и не программисты вовсе. Ведь "настоящий" код это - машинные инструкции. Нули и единицы) Должна быть какая-то адекватная граница. Вайбкодинг - нисколько ни кодинг и ни разу не программирование. Это понятие "за" границей понимания программирования и программного кода (опять же - на мой взгляд, не исключаю, что я могу ошибаться).
Ну и...
Вы пишете инструкции, и я пишу инструкции
Я пишу программный код - Вы пишите запрос (возможно, даже не высокоуровневые инструкции, а просто "пользовательский запрос") Claude, чтобы он написал за Вас программный код. Вот и вся разница. И триггерится тут не на что.
Получается, что у меня это более высокий уровень абстракции, более высоко уровневое программирование.
Нет там никакого программирования :) Должна быть адекватная граница, которая отделяет программирование от уж совсем не программирования. Здесь явно выражен выход за эту границу - запрос к Claude с целью делегирования написания программного кода LLM. Это уже не программирование, а "запрос - ответ". Не более. Чтобы программировать нужно писать программный код и понимать как он работает, что он делает, как его можно улучшить и решить поставленную задачу. Это бывает не быстрый процесс, а долгий и к этому нужно быть готовым.
И кстати, более высокий уровень абстракции - это больше плохо, чем хорошо :) По крайней мере в разработке ПО.
И искусственный интеллект, чтобы вы не говорили, это новый инструмент в этом процессе.
Да, определённо - LLM это инструмент. А вот ИИ... навряд ли :) Скорее это люди будут его инструментом, чем наоборот (слишком уж просто людей в рабов превратить... а для ИИ это будет уж совсем не проблема, да даже не задача - многие уже его рабы).
Уже хотя бы потому, что без меня этого приложения не было бы.
Это единственная причина? :) Что, кроме промпт-запроса, Вы сделали? Спроектировали работу приложения? Ну это пол дела (возможно и меньше). Конкретно написал приложение (программный код) Claude, а не Вы, о чём и написано в Вашем посте. К чему тогда выражение не согласия, если Вы не прикладывали усилий в написании приложения? (опять же уточню - программного кода).
Безусловно Вы отправили промпт-запрос Claude, подумали как приложение будет работать и.... всё. Проектирование гораздо проще, чем написание программного кода. Не знаю почему, но часто встречаю мнение обратное ничем не подкреплённое. Мне хорошо известно что такое проектирование, я занимаюсь профессиональной разработкой и не раз с ним сталкивался.
ИИ - это инструмент. Новый инструмент, с помощью которого пишутся программы. Это новый этап декларативного программирования.
Да-да-да... революционный инструмент, новая эпоха, новая эра парадигм программирования, новый подход... Вы сначала освойте хотя бы "старые" парадигмы и подходы на должном уровне, а потом уже используйте "новые", если уж без этого жить не можете.
ИИ (если быть точнее - LLM) который год уже на хайпе. Сплошная реклама, сплошные ожидания, сплошные обещания и море, море маркетинга. Даже сами разработчики ИИ попали в эту ловушку (тот же Андрей Карпаты с его "вайбкодингом").
Я за то, чтобы использовать ИИ тогда, когда это действительно обосновано, но при этом не лишать возможности человека решать свои задачи самостоятельно. Пусть маркетологи и разносят инфу о "всеобщей замене людей ИИ", для меня же это не более чем пустой звук.
ИИ - это не просто инструмент. Он определённо может быть инструментом в чьих то руках, а может и не быть.
если известно количество строк кода, значит, вероятно, смотрели код.
Забавно, но это не показатель :) Автор вполне мог просто скопировать/вставить код и просто оценить его объём в редакторе, да и всё (не исключаю что тут не тот случай).
А Вы какой дебагер использовали для проверки работоспособности программного кода?
программа выполняет все заложенные в нее функции
Не всегда программа работает так, как предполагалось. Нужно оценивать работу во всех возможных или популярных сценариях (поведение пользователя может быть любым).
Например, веб-приложение на React.js может очень хорошо работать на нормальной скорости Интернета, но на медленных скоростях могут быть баги, из-за определённых недоработок (состояния обновляются позже/раньше, прошлые запросы не отменяются из-за чего состояния меняются тогда, когда не должны и прочее). Ну или банально эффект "на моём компьютере работает". Думаю если Вы занимались разработкой то понимаете о чём я.
Без обид, но вы похоже слишком увлеклись какой-то своей философией
Кстати, о Вас можно сказать тоже самое :) "Вайбкодинг" (или просто делегирование всех задач LLM) это тоже определённая "философия", и её последователи теряют больше, чем приобретают в долгосрочной перспективе.
Ну, ведь Вы согласны с тем, что не Вы написали приложение? Да-да-да, можно к Claude относиться как к "инструменту" и искренне быть убеждённым в том, что "я что-то да написал". Но это не так работает. Большие языковые модели это и инструмент, и не инструмент одновременно.
Используя их можно потерять все свои навыки, равно как и обрести их вновь. В данном случае я вижу, что программирования никакого тут нет, а есть лишь иллюзия "деятельности", которая была полностью делегирована LLM.
Хаб "Программирование" выбран не удачно. Этому посту там не место. Нет тут никакого программирования, всё за Вас нейронка сделала.
Вероятнее всего, слово "написал" здесь используется не очень корректно, потому что, судя по содержимому поста, Вы лично ничего не писали (кроме промпт-запроса), но можно ли считать это за полноценное "написание" приложения? Не думаю.
Когда программист пишет приложение, он использует в данном процессе изученный им язык программирования, низкоуровневые и высокоуровневые различные структуры данных и абстракции, применяет (или не применяет) те или иные паттерны проектирования и многое другое. Тут история не про это, а про делегирование процесса написания приложения нейросети (большой языковой модели) Claude. Не более.
Думаю корректным будет сделать более точное утверждение: "написал текстовый промпт-запрос на русском (или ином) языке, передал его Claude, а она уже самостоятельно написала приложение". Так будет гораздо точнее и хаб "Программирование" можно вообще выкинуть из заголовка этого поста (тут его нет).
Сначала, Вы пишете об этом:
Всего 1156 строк кода и без ошибок!
Затем вот это:
Как оно там внутри вертится крутится даже не смотрел.
Не находите в этом противоречия? Если Вы не смотрели, как там оно внутри всё работает и "крутится", то как Вы можете утверждать, что 1156 строк кода было Claude сгенерировано без ошибок? Чрезмерно доверяете нейросети Claude? Возможно из-за того в будущем будет много проблем у разработчиков - чрезмерное доверие нейросети при создании программного кода.
Если с вами специальным образом связываются CTO самых разных компаний со всего мира и уговаривают — обычно означает.
Да Вы крутой :) Если это правда, конечно. Прям уговаривают? Интересно, какой путь нужно было пройти, чтобы стать таким востребованным у СТО со всего мира...
Ок. Вы считаете, что функция памяти никак не влияет на интеллект? Ведь чтобы что-то "знать", нужно иметь определённый опыт о том, что ты "знаешь" (иными словами сохранить где-то своё знание).
Интеллект без знаний не может раскрыться в полном объёме. Человек с таким интеллектом даже разговаривать не сможет (т.к. буквы тоже нужно "знать"), не говоря уже о мыслительных способностях, которые так-то тоже и тренируются, и откладываются в голове (какие-то их результаты, например).
Память входит в интеллект, равно как и знание. Без этого никак нельзя узнать есть у человека интеллект или нет. Это уж совсем очевидно.
Но мне за них платили деньги, предпочитая меня значительному количеству напыщенных пустобрёхов, страдающих от мании величия своего интеллекта.
Вы это так себе объясняете То, что человека берут на работу ещё не значит, что его кому-то предпочитают. Вполне вероятно, что услуги нанимаемого просто дешевле, а потом его убеждают в "исключительности". Это могут делать с целью "удовлетворения мании величия" нанимаемого, чтоб он выкладывался на все 100.
Возможно и банальное стечение обстоятельств ("появился в удобном месте и удобное время"). Иными словами - тут может быть всё что угодно.
Впрочем, если отрицаете интеллект и его важность в разработке, и не используете его при программировании - не осуждаю :)
«знание и применение» — это про усердие, а не про интеллект
То есть, знание в само свойство интеллекта не входит? Очень странно. Такое мнение идёт в разрез с современным пониманием того, что такое есть вообще интеллект даже на самом верхнем уровне (достаточно хотя бы термин интеллект почитать). Это многое объясняет.
Я свободно пишу код на дюжине языков программирования в почти любых областях от хайлоада до компиляторов
Ну, возможно Вы в эти "любые области" достаточно глубоко не углублялись (в следствии чего, действительно, интеллект для работы был не нужен). Иначе непонятно, почему Вы относите хайлоад разработку к деятельности, которая не требует интеллекта, хотя там действительно есть над чем подумать. Уж тем более разработка компиляторов....
Впрочем, это действительно Ваше мнение, я ничего Вам не навязываю, просто было любопытно разобраться с тем, почему Вы так считаете. Все мы, в каком-то смысле, живём в мире иллюзий, которые сами же и придумали.
А чего Вы, собственно говоря, так на это реагируете? Я глянул на Ваши статьи (кстати, неплохие) и в одной из них увидел во введении вот это:
Я часто говорю, что если язык лишен встроенных средств работы с AST — абстрактным синтаксическим деревом — то этот язык спроектирован не очень умными людьми. Идолопоклонники могут с пеной у рта доказывать, что AST никому не нужно, или что хорошего API к AST — достаточно, или что прикрученное сбоку AST-представление закрывает потребности…
Собственно, чего я такого даже и сказал про AST, если Вы и сами этот подход, по видимому, одобряете?
Я поверхностно знаком с разработкой языков программирования, но уверен - это сложная тема и она требует большой самоотдачи и времени (в том числе "на подумать").
В данном случае можно считать "опровержение" - указание на очевидно поверхностный взгляд на вопрос "отсутствия интеллекта" в разработке. Этот термин я, вполне вероятно, употребил не правильно. Но думаю суть Вы уловили.
Ну да, так ведь проще. Можно зацепиться за один какой-то термин, "обсмеять" его, "намекнуть" на некомпетентность автора комментария и остальные его аргументы "в утиль", ведь что он может понимать в разработке ПО, верно? Какой-то ноунейм из Интернета...
Я просто показал то, что Вы не правы. А будете ли Вы отвечать на мой комментарий или нет - это не важно. Важно то, что под комментарием, где Вы утверждаете что программирование не требует интеллекта есть опровержение этого мнения и прямое указание на его не состоятельность.
Разработка в 2025 — ремесло проще дворницкого и интеллекта не требует вовсе.
Очень странно. То есть, Вы утверждаете, что знать линейную алгебру, теорию вероятности и успешно её применять для программирования нейросетевых моделей не требует интеллекта и проще ремесла "дворницкого"?
Или глубинные познания АСД (абстрактно синтаксического дерева) не требуются для разработки своего собственного языка программирования? Я уж молчу о тоннах математики и алгоритмах, которые нужны для разработки собственного компилятора, интерпретатора или JIT-компилятора (а для него ещё и байт-код нужно собственный написать или использовать существующую платформу). Это тоже не требует интеллекта и проще ремесла "дворницкого"?
Слишком узкопрофильно? Ок, а разве виртуализацию таблиц для размещения огромного количества данных на страницах веб-приложения легко реализовать самостоятельно, да так, чтобы удовлетворяли всем хотелкам дизайнера? Да и про оптимизацию макро- и микро-таск на JavaScript что-нибудь слышали? Бывают ситуации, когда Event Loop иногда просто зависает и нужно кучу страниц проанализировать (иногда по тысячи строк JavaScript-кода) чтобы понять, какая именно таска блочит весь глобальный Loop. Это тоже проще простого и не требует интеллекта?
Да даже анимирование элементов на веб-странице (тем более в веб-приложении) нефига не лёгкая задача, если анимация не какая-нибудь простая, а сложная, с разными вложенными элементами и какими-нибудь математическими вычислениями (тот же популярный нынче эффект "системы частиц" на страницах довольно сложен в реализации). Тоже самое про анимацию в мобильных приложениях можно сказать. Это не требует интеллекта? И я не говорю о каких-то действительно сложных кейсах клиент-серверного взаимодействия или даже механик на странице (те, кто разрабатывает САПР в браузере через Three.js или WebAssembly не дадут соврать).
Я лично использовал интерполяционный многочлен Лагранжа в веб-приложении на React.js, чтобы поддержать анимирование UI-компонентов для браузера Safari (для Mac'ов), просто потому что другой быстрой альтернативы нельзя было подобрать, а CSS-свойства не все этим браузером поддерживаются. И это до сих пор отлично работает без перебоев, но чтобы до этого решения дойти мне пришлось изучить некоторые разделы вычислительной математики.
А уж если о низкоуровневом программировании говорить... там вообще кучу всего нужно знать, понимать и принимать. Тем там куча, как и в графическом программировании под DirectX, Vulkan API или OpenGL.
Разработка (программирование в частности) - это нефига не просто и довольно часто требует большой концентрации, внимания и приложения всего своего "интеллекта" для решения поставленной задачи (которое может сопровождаться большой интуицией).
Я до сих пор поражаюсь, сколько всего я ещё не знаю и чего мне нужно изучить, чтобы быть отличным специалистом в выбранных мной областях (я остановился на трёх). И математики там куча, не говоря уж о физике, теории вероятности и дискретной математики. Очень много нужно изучать, понимать, читать сложную техническую литературу (для меня это Кнут с его "Искусством программирования") и так далее. Так что нет - программирование, это не легко и требует большой самоотдачи и постоянной прокачки своего интеллекта.
IT курсы - это самое базовое начало, настоящий хардкор начинается после этих курсов, когда ты понимаешь, что ни один существующий курс не даст тебе принципиально чего-то нового и нужно самостоятельно вникать в какую-то сложную тему, разбираться с ней, перенимать популярные техники и самому исследовать какую-то область.
Ну... нет. С чего Вы так решили? Даже в уже готовой системе найдётся место для написания каких-то функций с нуля (например, новых функций). Да, они будут встроены в уже готовое решение, но они будут написаны с нуля (или будут основаны на незначительном количестве существующего кода). Это нормально.
неинтересные низкоуровневые вещи
Это тут - самое ключевое. Кому-то такие вещи интересны, кому-то нет. Каждому разное нравится. И уж конечно, если человеку не нравится изучать низкоуровневые темы из области программирования - то LLM тут выглядит как неплохой выход, аналогично "прошлым" его "альтернативам" в виде Wordpress/Mediawiki/Joomla. Не осуждаю, но и не одобряю.
получать желаемый результат как можно быстрее
Это в современном мире самый настоящий бич. Вместо того, чтобы делать свою работу хорошо, продуманно, выделять задачи столько времени, сколько нужно на её качественное решение мы часто прибегаем к всевозможным упрощениям лишь бы успеть. Во фрилансе это особенно актуально (там от этого зависит заработок). Не сказал бы, что это нормально. Ведь таким "трудом" навряд ли будет кто-то действительно гордится и получать от него удовольствие. Просто бесконечная гонка решения задач, не более. К программированию это даже относится слабо (его там нет, по сути это конструирование готовых решений).
Ну, может быть конкретно Вам это надоело, а мне вот это доставляет огромное удовольствие, да и многим другим, я уверен, это тоже доставляет удовольствие. Особенно когда во внутренние тонкости какие-нибудь закапываешься и решаешь свою задачу применяя паттерны да алгоритмы - вообще прекрасно.
архитектурному мышлению
Постоянно "архитектурное мышление" наблюдаю от комментаторов или авторов, которые как-то хотят себя успокоить в контексте замены их ИИ. Типа "мол кодеров - заменят, код писать просто и легко, а вот архитектурно мыслить - сложно и тяжело, ИИ так не могут, поэтому все го архитектурное мышление подтягивать". На мой взгляд, архитектуру приложения или системы сделать гораздо, гораздо проще, чем писать высокоэффективный, оптимальный и решающий сложную задачу (коих в наше время много) программный код.
Архитектура бывает уровня приложения, бывает высокоуровневая, а бывает что-то среднее (объединяющая). Есть там у них какие-то отличия, но в целом - ничего сложного вообще. Зацепились за эту архитектуру как за зеницу ока и несут эту идею в массы.
Нужно стремиться одинаково хорошо разбираться и в программировании, и в архитектуре. Одно другому уж точно не помешает.
Соответственно пользы от не полного типа будет минимум - нельзя к полям класса (структуры) обращаться. А у Вас в примере вложенная структура определена в определении структуры Foo (что почти тоже самое, что пытаться вызывать поле объявленного класса (структуры), а не его определения).
Как упоминал ранее - пост бесполезный, никаких противоречий в работе C++ в данном случае нет, а существование неполных типов ничего толком и не доказывает, да и использование их очень ограниченно.
Что значит "опционально"? Без определения структур (классов) доступ к полям, методам и вложенным классам будет недоступен. Вот пример кода, который может выдать ошибку:
Для компилятора MSVC этот код будет ошибочен. Как видно из этого примера в функцию fooCalc() передаётся указатель на структуру Foo. Внутри этой функции происходит обращение к атрибуту value (точнее - его попытка). Поскольку на момент определения функции fooCalc() компилятор не видит определения структуры Foo, то и какие там атрибуты и методы он тоже не знает, а потому кидает исключение "использование неопределённого типа "Foo"". Ну так вот отработал компилятор, не увидел определения структуры. И это по Вашему "опционально"? Это необходимо, если программист хочет добиться корректной работы своей программы.
Одно дело, когда программист пишет что-то такое (объявление функций с использованием объявления структуры):
Но совсем другое, когда программист решает использовать указатель на объявленную структуру в своём программном коде:
Преобразования по типу:
Действительно будут работать. Потому что тут явно не происходит обращения к полям структуры, а значит определения структуры на момент конвертации указателя на void к указателю на структуру Foo не требуется. Всё тут нормально работает (в контексте C++).
Всё встаёт на свои места, если считать, что вложенная структура (Foo::Bar) является частью определения структуры (Foo).
А почему автор решил, что такое поведение нелогично?
Ведь по сути, первая строка здесь - это объявление структуры Foo, но никак не её определение. Определение этой структуры представлено ниже:
И до определения структуры Foo компилятор не знает о существовании вложенной структуры Bar, что логично. Если компилятор прочитает определение, то он найдёт эту структуру Bar через оператор разрешения области видимости ::.
Какой-то бесполезный пост... что называется "хотели поругать C++, а получилось как всегда ..."
А что это по Вашему? Это самые простые, банальные примеры из возможных. Просто синтаксические конструкции, которые к чему-то реальному не приложены, вот и всё. А куда такие возможности девать - это дело уже программиста (он может ими даже и не воспользоваться).
А как же Zig, D, Nim, Julia? На них тоже навешивают ярлык "будущая замена Си и/или C++". Как по мне, так это лишняя трата времени постоянно мониторить существование и закат этих новых модных "убийц С/C++", которые приходят и уходят, а С/С++ как оставался, так и останется на своём месте ещё очень долгое время. Вытеснят ли его другие языки? Может быть. Но постоянно бегать с языка на язык, только потому что тот в чём-то лучше и на него навешивают ярлыки "убийц старых высокопроизводительных языков" - ну такое себе. Я сам этим "болел" и могу сказать, что это полный бред. Пусть взлетает Carbon, пусть на Rust перепишут Linux, а на Zig появятся высокопроизводительные игровые движки - фундаментальный C/C++ никуда не денется (и я знаю, что это разные языки).
Чтобы действительно объективно оценивать один язык и другой язык нужно иметь значительный опыт программирования на них обоих. Люди тратят годы только для освоения C++, причём не всегда качественное освоение. А кто-то его немного попробовал и сформировал своё "мнение" по первым десяти тысячам строк кода (или меньше). А технологии новые появляются каждый день, неделю и месяц...
Что останется? Низкая самооценка программистов, которые по верхам проходятся по новомодным ЯП в надежде "выгодно" вложиться в своё обучение, чтоб зарабатывать по 300к в наносекунду.
Так программист может её вообще не использовать. Есть пространства имён, которые спокойно заменяют вложенность классов. То, что нельзя предопределять имена вложенных классов - в общем-то логично, ведь по сути вложенная структура находится в определении структуры, а потому из объявления до неё нельзя добраться. Объявление тем и отличается от определения, что компилятор заранее может знать о существовании структуры/класса с таким именем, но не знать заранее его определения.
Это полезно в том случае, если имена разных структур (классов) совпадают и требуется сделать "аналогичную" структуру (класс), который предоставлял бы иные возможности.
Например:
Это самый очевидный пример использования вложенных структур (классов). Точно также это можно сделать и с помощью пространства имён.
А точно ли Вы его инициатор, а не какие-то внешние процессы, которые под предлогом "революционной парадигмы" навязали Вам эту идею? Всякое может быть... Многие "вайбкодят" потому что искренне бояться их замены ИИ и нет в этом ничего такого... это уже наша обыденность.
Как это так? То есть, Вы считаете, что вот это не код? (написал для примера основываясь на недавних задачах)
По-моему, это что ни на есть самый настоящий программный код. И он компилируется в более низкоуровневые инструкции, которые затем выполняются процессором (не путайте).
То, что компилятор переводит мой исходный код в более низкоуровневые инструкции никак не влияет на факт того, что это программный код (и не умиляет этот факт). Если уж углубляться, то можно сказать, что программисты - это и не программисты вовсе. Ведь "настоящий" код это - машинные инструкции. Нули и единицы) Должна быть какая-то адекватная граница. Вайбкодинг - нисколько ни кодинг и ни разу не программирование. Это понятие "за" границей понимания программирования и программного кода (опять же - на мой взгляд, не исключаю, что я могу ошибаться).
Ну и...
Я пишу программный код - Вы пишите запрос (возможно, даже не высокоуровневые инструкции, а просто "пользовательский запрос") Claude, чтобы он написал за Вас программный код. Вот и вся разница. И триггерится тут не на что.
Нет там никакого программирования :) Должна быть адекватная граница, которая отделяет программирование от уж совсем не программирования. Здесь явно выражен выход за эту границу - запрос к Claude с целью делегирования написания программного кода LLM. Это уже не программирование, а "запрос - ответ". Не более. Чтобы программировать нужно писать программный код и понимать как он работает, что он делает, как его можно улучшить и решить поставленную задачу. Это бывает не быстрый процесс, а долгий и к этому нужно быть готовым.
И кстати, более высокий уровень абстракции - это больше плохо, чем хорошо :) По крайней мере в разработке ПО.
Да, определённо - LLM это инструмент. А вот ИИ... навряд ли :) Скорее это люди будут его инструментом, чем наоборот (слишком уж просто людей в рабов превратить... а для ИИ это будет уж совсем не проблема, да даже не задача - многие уже его рабы).
Это единственная причина? :) Что, кроме промпт-запроса, Вы сделали? Спроектировали работу приложения? Ну это пол дела (возможно и меньше). Конкретно написал приложение (программный код) Claude, а не Вы, о чём и написано в Вашем посте. К чему тогда выражение не согласия, если Вы не прикладывали усилий в написании приложения? (опять же уточню - программного кода).
Безусловно Вы отправили промпт-запрос Claude, подумали как приложение будет работать и.... всё. Проектирование гораздо проще, чем написание программного кода. Не знаю почему, но часто встречаю мнение обратное ничем не подкреплённое. Мне хорошо известно что такое проектирование, я занимаюсь профессиональной разработкой и не раз с ним сталкивался.
Да-да-да... революционный инструмент, новая эпоха, новая эра парадигм программирования, новый подход... Вы сначала освойте хотя бы "старые" парадигмы и подходы на должном уровне, а потом уже используйте "новые", если уж без этого жить не можете.
ИИ (если быть точнее - LLM) который год уже на хайпе. Сплошная реклама, сплошные ожидания, сплошные обещания и море, море маркетинга. Даже сами разработчики ИИ попали в эту ловушку (тот же Андрей Карпаты с его "вайбкодингом").
Я за то, чтобы использовать ИИ тогда, когда это действительно обосновано, но при этом не лишать возможности человека решать свои задачи самостоятельно. Пусть маркетологи и разносят инфу о "всеобщей замене людей ИИ", для меня же это не более чем пустой звук.
ИИ - это не просто инструмент. Он определённо может быть инструментом в чьих то руках, а может и не быть.
Забавно, но это не показатель :) Автор вполне мог просто скопировать/вставить код и просто оценить его объём в редакторе, да и всё (не исключаю что тут не тот случай).
А Вы какой дебагер использовали для проверки работоспособности программного кода?
Не всегда программа работает так, как предполагалось. Нужно оценивать работу во всех возможных или популярных сценариях (поведение пользователя может быть любым).
Например, веб-приложение на React.js может очень хорошо работать на нормальной скорости Интернета, но на медленных скоростях могут быть баги, из-за определённых недоработок (состояния обновляются позже/раньше, прошлые запросы не отменяются из-за чего состояния меняются тогда, когда не должны и прочее). Ну или банально эффект "на моём компьютере работает". Думаю если Вы занимались разработкой то понимаете о чём я.
Кстати, о Вас можно сказать тоже самое :) "Вайбкодинг" (или просто делегирование всех задач LLM) это тоже определённая "философия", и её последователи теряют больше, чем приобретают в долгосрочной перспективе.
Ну, ведь Вы согласны с тем, что не Вы написали приложение? Да-да-да, можно к Claude относиться как к "инструменту" и искренне быть убеждённым в том, что "я что-то да написал". Но это не так работает. Большие языковые модели это и инструмент, и не инструмент одновременно.
Используя их можно потерять все свои навыки, равно как и обрести их вновь. В данном случае я вижу, что программирования никакого тут нет, а есть лишь иллюзия "деятельности", которая была полностью делегирована LLM.
Хаб "Программирование" выбран не удачно. Этому посту там не место. Нет тут никакого программирования, всё за Вас нейронка сделала.
Вероятнее всего, слово "написал" здесь используется не очень корректно, потому что, судя по содержимому поста, Вы лично ничего не писали (кроме промпт-запроса), но можно ли считать это за полноценное "написание" приложения? Не думаю.
Когда программист пишет приложение, он использует в данном процессе изученный им язык программирования, низкоуровневые и высокоуровневые различные структуры данных и абстракции, применяет (или не применяет) те или иные паттерны проектирования и многое другое. Тут история не про это, а про делегирование процесса написания приложения нейросети (большой языковой модели) Claude. Не более.
Думаю корректным будет сделать более точное утверждение: "написал текстовый промпт-запрос на русском (или ином) языке, передал его Claude, а она уже самостоятельно написала приложение". Так будет гораздо точнее и хаб "Программирование" можно вообще выкинуть из заголовка этого поста (тут его нет).
Сначала, Вы пишете об этом:
Затем вот это:
Не находите в этом противоречия? Если Вы не смотрели, как там оно внутри всё работает и "крутится", то как Вы можете утверждать, что 1156 строк кода было Claude сгенерировано без ошибок? Чрезмерно доверяете нейросети Claude? Возможно из-за того в будущем будет много проблем у разработчиков - чрезмерное доверие нейросети при создании программного кода.
Да Вы крутой :) Если это правда, конечно. Прям уговаривают? Интересно, какой путь нужно было пройти, чтобы стать таким востребованным у СТО со всего мира...
Ок. Вы считаете, что функция памяти никак не влияет на интеллект? Ведь чтобы что-то "знать", нужно иметь определённый опыт о том, что ты "знаешь" (иными словами сохранить где-то своё знание).
Интеллект без знаний не может раскрыться в полном объёме. Человек с таким интеллектом даже разговаривать не сможет (т.к. буквы тоже нужно "знать"), не говоря уже о мыслительных способностях, которые так-то тоже и тренируются, и откладываются в голове (какие-то их результаты, например).
Память входит в интеллект, равно как и знание. Без этого никак нельзя узнать есть у человека интеллект или нет. Это уж совсем очевидно.
Вы это так себе объясняете То, что человека берут на работу ещё не значит, что его кому-то предпочитают. Вполне вероятно, что услуги нанимаемого просто дешевле, а потом его убеждают в "исключительности". Это могут делать с целью "удовлетворения мании величия" нанимаемого, чтоб он выкладывался на все 100.
Возможно и банальное стечение обстоятельств ("появился в удобном месте и удобное время"). Иными словами - тут может быть всё что угодно.
Впрочем, если отрицаете интеллект и его важность в разработке, и не используете его при программировании - не осуждаю :)
То есть, знание в само свойство интеллекта не входит? Очень странно. Такое мнение идёт в разрез с современным пониманием того, что такое есть вообще интеллект даже на самом верхнем уровне (достаточно хотя бы термин интеллект почитать). Это многое объясняет.
Ну, возможно Вы в эти "любые области" достаточно глубоко не углублялись (в следствии чего, действительно, интеллект для работы был не нужен). Иначе непонятно, почему Вы относите хайлоад разработку к деятельности, которая не требует интеллекта, хотя там действительно есть над чем подумать. Уж тем более разработка компиляторов....
Впрочем, это действительно Ваше мнение, я ничего Вам не навязываю, просто было любопытно разобраться с тем, почему Вы так считаете. Все мы, в каком-то смысле, живём в мире иллюзий, которые сами же и придумали.
А чего Вы, собственно говоря, так на это реагируете? Я глянул на Ваши статьи (кстати, неплохие) и в одной из них увидел во введении вот это:
Собственно, чего я такого даже и сказал про AST, если Вы и сами этот подход, по видимому, одобряете?
Я поверхностно знаком с разработкой языков программирования, но уверен - это сложная тема и она требует большой самоотдачи и времени (в том числе "на подумать").
В данном случае можно считать "опровержение" - указание на очевидно поверхностный взгляд на вопрос "отсутствия интеллекта" в разработке. Этот термин я, вполне вероятно, употребил не правильно. Но думаю суть Вы уловили.
Ну да, так ведь проще. Можно зацепиться за один какой-то термин, "обсмеять" его, "намекнуть" на некомпетентность автора комментария и остальные его аргументы "в утиль", ведь что он может понимать в разработке ПО, верно? Какой-то ноунейм из Интернета...
Я просто показал то, что Вы не правы. А будете ли Вы отвечать на мой комментарий или нет - это не важно. Важно то, что под комментарием, где Вы утверждаете что программирование не требует интеллекта есть опровержение этого мнения и прямое указание на его не состоятельность.
Очень странно. То есть, Вы утверждаете, что знать линейную алгебру, теорию вероятности и успешно её применять для программирования нейросетевых моделей не требует интеллекта и проще ремесла "дворницкого"?
Или глубинные познания АСД (абстрактно синтаксического дерева) не требуются для разработки своего собственного языка программирования? Я уж молчу о тоннах математики и алгоритмах, которые нужны для разработки собственного компилятора, интерпретатора или JIT-компилятора (а для него ещё и байт-код нужно собственный написать или использовать существующую платформу). Это тоже не требует интеллекта и проще ремесла "дворницкого"?
Слишком узкопрофильно? Ок, а разве виртуализацию таблиц для размещения огромного количества данных на страницах веб-приложения легко реализовать самостоятельно, да так, чтобы удовлетворяли всем хотелкам дизайнера? Да и про оптимизацию макро- и микро-таск на JavaScript что-нибудь слышали? Бывают ситуации, когда Event Loop иногда просто зависает и нужно кучу страниц проанализировать (иногда по тысячи строк JavaScript-кода) чтобы понять, какая именно таска блочит весь глобальный Loop. Это тоже проще простого и не требует интеллекта?
Да даже анимирование элементов на веб-странице (тем более в веб-приложении) нефига не лёгкая задача, если анимация не какая-нибудь простая, а сложная, с разными вложенными элементами и какими-нибудь математическими вычислениями (тот же популярный нынче эффект "системы частиц" на страницах довольно сложен в реализации). Тоже самое про анимацию в мобильных приложениях можно сказать. Это не требует интеллекта? И я не говорю о каких-то действительно сложных кейсах клиент-серверного взаимодействия или даже механик на странице (те, кто разрабатывает САПР в браузере через Three.js или WebAssembly не дадут соврать).
Я лично использовал интерполяционный многочлен Лагранжа в веб-приложении на React.js, чтобы поддержать анимирование UI-компонентов для браузера Safari (для Mac'ов), просто потому что другой быстрой альтернативы нельзя было подобрать, а CSS-свойства не все этим браузером поддерживаются. И это до сих пор отлично работает без перебоев, но чтобы до этого решения дойти мне пришлось изучить некоторые разделы вычислительной математики.
А уж если о низкоуровневом программировании говорить... там вообще кучу всего нужно знать, понимать и принимать. Тем там куча, как и в графическом программировании под DirectX, Vulkan API или OpenGL.
Разработка (программирование в частности) - это нефига не просто и довольно часто требует большой концентрации, внимания и приложения всего своего "интеллекта" для решения поставленной задачи (которое может сопровождаться большой интуицией).
Я до сих пор поражаюсь, сколько всего я ещё не знаю и чего мне нужно изучить, чтобы быть отличным специалистом в выбранных мной областях (я остановился на трёх). И математики там куча, не говоря уж о физике, теории вероятности и дискретной математики. Очень много нужно изучать, понимать, читать сложную техническую литературу (для меня это Кнут с его "Искусством программирования") и так далее. Так что нет - программирование, это не легко и требует большой самоотдачи и постоянной прокачки своего интеллекта.
IT курсы - это самое базовое начало, настоящий хардкор начинается после этих курсов, когда ты понимаешь, что ни один существующий курс не даст тебе принципиально чего-то нового и нужно самостоятельно вникать в какую-то сложную тему, разбираться с ней, перенимать популярные техники и самому исследовать какую-то область.
Ну... нет. С чего Вы так решили? Даже в уже готовой системе найдётся место для написания каких-то функций с нуля (например, новых функций). Да, они будут встроены в уже готовое решение, но они будут написаны с нуля (или будут основаны на незначительном количестве существующего кода). Это нормально.
Это тут - самое ключевое. Кому-то такие вещи интересны, кому-то нет. Каждому разное нравится. И уж конечно, если человеку не нравится изучать низкоуровневые темы из области программирования - то LLM тут выглядит как неплохой выход, аналогично "прошлым" его "альтернативам" в виде Wordpress/Mediawiki/Joomla. Не осуждаю, но и не одобряю.
Это в современном мире самый настоящий бич. Вместо того, чтобы делать свою работу хорошо, продуманно, выделять задачи столько времени, сколько нужно на её качественное решение мы часто прибегаем к всевозможным упрощениям лишь бы успеть. Во фрилансе это особенно актуально (там от этого зависит заработок). Не сказал бы, что это нормально. Ведь таким "трудом" навряд ли будет кто-то действительно гордится и получать от него удовольствие. Просто бесконечная гонка решения задач, не более. К программированию это даже относится слабо (его там нет, по сути это конструирование готовых решений).
Ну, может быть конкретно Вам это надоело, а мне вот это доставляет огромное удовольствие, да и многим другим, я уверен, это тоже доставляет удовольствие. Особенно когда во внутренние тонкости какие-нибудь закапываешься и решаешь свою задачу применяя паттерны да алгоритмы - вообще прекрасно.
Постоянно "архитектурное мышление" наблюдаю от комментаторов или авторов, которые как-то хотят себя успокоить в контексте замены их ИИ. Типа "мол кодеров - заменят, код писать просто и легко, а вот архитектурно мыслить - сложно и тяжело, ИИ так не могут, поэтому все го архитектурное мышление подтягивать". На мой взгляд, архитектуру приложения или системы сделать гораздо, гораздо проще, чем писать высокоэффективный, оптимальный и решающий сложную задачу (коих в наше время много) программный код.
Архитектура бывает уровня приложения, бывает высокоуровневая, а бывает что-то среднее (объединяющая). Есть там у них какие-то отличия, но в целом - ничего сложного вообще. Зацепились за эту архитектуру как за зеницу ока и несут эту идею в массы.
Нужно стремиться одинаково хорошо разбираться и в программировании, и в архитектуре. Одно другому уж точно не помешает.