Комментарии 20
англицизма vibe («вибрация») и под ним принято понимать сильные эмоции
вайб это наоборот про спокойствие и комфорт. когда два человека вайбят - им взаимно комфортно при взаимодействии друг с другом. Поэтому и вайб-кодинг это история про то как "чиловый парень" промтит приложение без приближения к выгоранию. Конечно, на выходе обычно фигня получается. Ну и как говорится - лучшее ТЗ на программу - сама программа. Поэтому ИИ и не отберёт работу у программистов - кому-то всё равно придётся наиболее детальное ТЗ писать.
И не знаю как у вас так получилось, но оно все же харденинг - как у вас в транслитерации ошибка случилась - загадка. Переводится как закалка/укрепление. Закаляйте ваши приложения.
Так "спокойствие и комфорт", это и есть про эмоции. Так же как и Андрей Карпаты пишет именно про эмоции и ощущения, которые он испытывает при программировании с помощью LLM
Поэтому ИИ и не отберёт работу у программистов - кому-то всё равно придётся наиболее детальное ТЗ писать.
Про вайб-кодинг в реальным проекте на С++ как раз сейчас дописываю статью, которую доделаю и опубликую ближе к концу недели.
Про модули в С++ говорят уже очень давно и я с нетерпением жду окончательного принятия нового стандарта, поэтому стараюсь быть в курсе нововведений.
Про «стандарт» говорить не берусь, но свое представления о модулях в С++ я описал в статье: «Модульное программирование в C++. Статические и динамические плагины» ( https://habr.com/ru/articles/566864/ ).
Спасибо за ссылку, хотя это больше про плагины с WinAPI, а не про модули в С++.
это больше про плагины с WinAPI, а не про модули в С++.
Это и в дискуссии под статьей видно, что у каждого свое представление о понятии «модуль». Чаще всего, под модулем в С++ понимают тоже самое что под модулем в Питоне. Но, я так не думаю. Я, лично, под модулем понимаю изолированный код проекта, который, стандартным образом (например, с помощью внешних скриптов), как подключается к общему проекту, так и отключается от него (при этом работоспособность проекта должна сохраняться). Это можно делать двояко: на уровне исходников (у меня это статические плагины) и на бинарном уровне (динамические плагины). Можно еще вспомнить бинарные компоненты от M$, но, это уже будет чужой (бинарный) код.
При работе в команде, я бы предпочел разделение труда в рамках статических плагинов, а для их тестирования – аналогичных, динамических. Однако в команде мне работать не пришлось (все свои программы писал в одиночку), поэтому, мне трудно судить о реальной эффективности этого метода.
А так, похоже на обычную реакцию: «Это не то, что я хочу, но, что я хочу – я не знаю!».
Немного не понял о чем это вы, так как доклад на конференции был про модули С++ в одном конкретное представлении - модульная организация на уровне исходного кода. Это С++ модули только времени компиляции и нужны они только для компилятора при сборке бинарных файлов библиотек или приложений.
Ни к статическим, ни к динамическим библиотекам (как в вашем случае) данные С++ модули отношения не имеют.
хорошим аналогом для меня был бы package из java, тоесть чтобы на самой платформе языка сделать модуль стандартной библиотеки 1 раз и переносить его
для меня неудобно и не тривиально создать такой пакет
вин апи или проектный код понятно что запакуется, тут интересно разбить стандарт по модулям по категориям чтобы удобнее было дальнейшее управление, тоесть это первичная задача если речь о модулях
модули С++ в одном конкретное представлении - модульная организация на уровне исходного кода. Это С++ модули только времени компиляции и нужны они только для компилятора при сборке бинарных файлов библиотек или приложений
Ну, и чём прикол? В этом смысле, любой проект на VS C++ уже разбит на модули: *.h / *.cpp файлов компонент и сопровождающие их файлы. Что нового-то?
При этом, исходный текст модуля, на С++, можно взять из опенсорса и прилепить к своему проекту. Все его файлы положить в отдельный каталог и получить к ним доступ из основной части проекта. Так делалось всегда. Как их там компилирует компилятор – не суть важно, главное на выходе получить искомый ехе-шник. Это что не модульность, в вашем (именно!) понимании? О чем тогда речь?
Для примера. Мне понадобилось сделать программу для ручного извлечения текста из медиа-файлов (для подготовки обучающих данных к своей программе). Для этого взял опенсорсный файл FFPlay.c с зависимыми файлами, для работы с видео и прочим медиа, преобразовал их в классы с++ и подключил к своему (неопубликованному) проекту «MediaText», см. скриншот: http://scholium.webservis.ru/Pics/MediaText.png .
Разве это не есть модульность в вашем понимании? Чего тогда еще хотеть от модульности в С++, когда она уже в любом виде присутствует там и так?
Ну, и чём прикол? В этом смысле, любой проект на VS C++ уже разбит на модули: *.h / *.cpp файлов компонент и сопровождающие их файлы. Что нового-то?
Прикол в том, что *.h / *.cpp файлы, это не модули. В С++ модули наоборот противопоставляются заголовочным файлам и являются их прямой заменой.
Разве это не есть модульность в вашем понимании? Чего тогда еще хотеть от модульности в С++, когда она уже в любом виде присутствует там и так?
Это не есть модульность в понимании комитета по стандартизации С++.
Модульность в С++ нужна для библиотек и для крупных проектов, так как упрощает написание взаимозависимого кода (нет необходимости писать отдельные файлы для интерфейса (.h) и реализации (.cpp)), ускоряется компиляция больших проектов и использование программных компонентов (на уровне исходного кода для компилятора) и модули не имеют проблем с порядком их импорта в исходных файлах.
Модульность в С++ нужна для библиотек и для крупных проектов, так как упрощает написание взаимозависимого кода (нет необходимости писать отдельные файлы для интерфейса (.h) и реализации (.cpp)), ускоряется компиляция больших проектов и использование программных компонентов (на уровне исходного кода для компилятора) и модули не имеют проблем с порядком их импорта в исходных файлах.
«Нужна для» это не из определения. В определении должны присутствовать слова: «это (есть)».
Что именно «упрощает написание взаимозависимого кода» – непонятно. Отсутствие h / cpp файлов? А что взамен? А дальше идут только хотелки.
Скажите, вы сами пишите на С++? Вот, я, лично, пишу и для меня понятие модульности не абстрактное, а конкретное. Чтобы упростить сильные связи, да еще взаимно-перекрестные, нужна именно изоляция кода на относительно независимые части. Причем, не на уровне dll-ек (это и так есть), а .на уровне текстовых блоков, которые я и называю модулями.
Эти блоки кода (модули) должны быть легко подключаемыми / отключаемыми. Для этого нужна спецификация их взаимодействия. Об этом где-нибудь говорится? Можно было сказать, на конференции, которую вы описываете, но там, как я понял, предпочитают говорить о стандартах развития языка, типа, С++ 26, протоколах и прочих формальностях.
А зачем это надо практическому программисту на С++? Меня, вот, вполне устраивает, VS C++ 2013. Дешево и сердито. Все, что мне нужно, там есть. Лёгкий, шустрый, удобный. Есть бесплатный VS C++ 2017, но он мне нравится меньше. А более новые версии, еще менее интересны.
Как это ни странно, но я не вижу никакой потребности в развитии этого языка. Главное, научится толком работать с тем, что уже есть. Скажем, с WTL. Этой библиотеке всего полтора мегабайта в исходниках, но мне она кажется неисчерпаемой.
Поэтому, думаю, нужно больше писать не о принципах программирования, типа SOLID и прочем, а о технологии программирования. А на эту тему статей, на Хабре, практически нет. Ибо все предпочитают говорить «вообще», а не «конкретно».
Как это ни странно, но я не вижу никакой потребности в развитии этого языка.
Ну и зря. У С++ самые лучшие перспективы с точки зрения возможностей и потенциала развития (еще очень много нужно сделать :-) )
А на эту тему статей, на Хабре, практически нет. Ибо все предпочитают говорить «вообще», а не «конкретно».
Вообще то я предпочитаю писать именно «конкретно». Не абстрактные теории, а конкретные предложения, ссылки на которые уже приводил в статье. Однако, что касается С++ модулей, то мне они нужны все же не для текущей работы (меня сейчас и так все устраивает), а именно для проработки теории модульности исходного кода в собственном языке программирования.
Ну и зря. У С++ самые лучшие перспективы с точки зрения возможностей и потенциала развития (еще очень много нужно сделать :-) )
Кто же против, пусть делает! Ибо останавливаться в развитии – чревато. Речь о другом, мне возможностей C++ / WTL хватит на всю оставшуюся жизнь. Зачем мне отвлекаться на непонятки? Как кто-то написал, в Интернете: «В Мире есть много вещей, которые мне… не нужны!». Но, ведь я не главный в этом Мире, правда? Если другим надо – пусть дерзают!
Вообще то я предпочитаю писать именно «конкретно». Не абстрактные теории, а конкретные предложения, ссылки на которые уже приводил в статье.
Я бы предпочел скриншоты программ, как, скажем, в своей статье: «Роль данных при изучении иностранного языка» ( https://habr.com/ru/articles/930868/ ). Посмотрел на картинки и сразу видно, стоит читать статью или ну ее нах?
У вас только фото с мероприятия. Что они дают нетерпеливому читателю? Пройтись по ссылкам? Прошелся, за несколько секунд – ничего не понял либо не интересно, а какой мне смысл вникать? И так поступают многие.
Однако, что касается С++ модулей, то мне они нужны все же не для текущей работы (меня сейчас и так все устраивает),
Меня эта тема зацепила, ибо актуальна в моем творчестве, поэтому именно на нее я только и реагирую.
а именно для проработки теории модульности исходного кода в собственном языке программирования.
Ну, это, надолго, может быть интересно только вам. Лично мне Питона и С++ хватает за глаза. Куда еще один язык программирования?
Куда еще один язык программирования?
Оооо... это как все просто. Как вам текущий синтаксис С++? А как вам синтаксис С++, который планируется в C++26 стандарте, а в будущих?
Смысл нового языка в том, чтобы уметь описать любой возможный алгоритм и транслировать его в выбранный язык (например в код на С++) с использованием только безопасных средств и методов разработки кода. По сути, это DSL для безопасной работой с памятью и автоматическим управлением синхронизацией при многопоточном или асинхронном программировании и бесшовной интеграцией с кодом на языкуе реализации (т.е. С++).
Как вам текущий синтаксис С++? А как вам синтаксис С++, который планируется в C++26 стандарте, а в будущих?
Я в синтаксисе С++ вообще никаких проблем не вижу. Меня все устраивает. А современный синтаксис только усложняет жизнь, поскольку иногда надо конвертировать проекты из VS C++ 2019 либо выше в 2013-й. Не всегда это возможно, с пол-гинка.
Что дают новые возможности? Безопасность? Так я ограничиваюсь только собственными пет-проектами. Для работы писал драйвера, кстати, они до сих пор работают, без модернизации (более десяти лет). Там хватало 1С, правда, для развлечения, писал внешние компоненты для них.
Смысл нового языка в том, чтобы уметь описать любой возможный алгоритм и транслировать его в выбранный язык (например в код на С++) с использованием только безопасных средств и методов разработки кода.
Это красиво звучит, но верится слабо. Не проще ли разрабатывать сами безопасные алгоритмы, все же, как-то надежней выглядит.
Если вы работаете на Космос или на Оборону и вас хорошо спонсируют, то это может иметь некоторый смысл. Помните, как разбилась наша «Луна-25» при прилунении? Торопились опередить индийцев с аналогичной миссией. В итоге, была ошибка в алгоритме торможения аппарата при спуске на Спутник Земли. Уверен, что код там был «безопасный». Только программисты плохо знали физику Луны, в которой много специфики и особенностей. Ну, и помог бы там ваш новый безопасный универсальный язык? Наверняка, используемый алгоритм преобразовался бы корректно и безопасно. Только откуда ваш язык программирования узнает обо всех особенностях физики Луны и исправит сам алгоритм? Так что, результат был бы тем же, космический аппарат ухайдокали бы, а индийцам бы дали повод позлорадствовать.
По сути, это DSL для безопасной работой с памятью и автоматическим управлением синхронизацией при многопоточном или асинхронном программировании и бесшовной интеграцией с кодом на языкуе реализации (т.е. С++).
Вот, если бы кто-то изобрел новый язык программирования, по оптимизированной работе с графикой (GUI), то я бы, наверняка, заинтересовался. Китайцы, вместо нового языка, предлагают свою библиотеку «DuiLib». Получается красиво (интерфейс программ вынесен во внешние xml-файлы, для редактирования которых они даже создали специальный редактор «DuiEditor»), только очень громоздко – пользоваться, особого желания – нет.
Как кто-то написал, в Интернете: «В Мире есть много вещей, которые мне… не нужны!»
Это был Сократ. И было это сильно до Интернета.
Возникает несколько проблем с хэдерами - скорость компиляции, зависимость от порядка их включения и проблемы транзитивности зависимостей, а также проблемы с инкапсуляцией интерфейса. Собственно, модули призваны попытаться всё это дело исправить.
Скорость компиляции - вроде понятно как и почему и как это решается для обычных hpp/cpp - предкомилирование заголовочников, кэширование промежуточных файлов, unity сборка и прочее в том же духе - долго, неудобно, а иногда и дорого: есть кампании, которые занимаются предоставлением услуг по ускорению сборки. Модули же в этой ситуации становятся отдельным юнитом трансляции, независимым от каких-то внешних вещей из-за чего скорость компиляции растёт в разы. Ранние эксперементы показывали рост скорости компиляции почти в 20 раз - собрать за минуту-другую вместо получаса заметное приятнее и полезнее.
Порядок включения заголовочников и возможность поломать внутренние флаги модуля - вроде тоже достаточно понятная проблема.
// ---------------------- foo.h
#pragma once
class Foo {
#if defined(FOO)
... // поведение A
#else // !FOO
... // поведение B
#endif // FOO
#ifdef (ASD)
... // поведение X
#endif
};// class Foo
// ---------------------- bar.h
#pragma once
class Bar {
#if defined(FOO)
... // поведение С
#else // !FOO
... // поведение D
#endif // FOO
};// class Bar
#define ASD
// ---------------------- main.cpp
// мы хотим поведение A но не X для класса Foo
// и поведение D для класса Bar
// получаем
#include "bar.h" // ломает желаемое поведение для Foo
#define FOO // влияет на все хэдеры ниже
#include "foo.h"Получается некоторая грязь с обмазыванием флагами вокруг инклюдов и прочий беспредел. Если где-то случайно ещё и имя флага совпало, то невзначай такие дефайны могут случайно поломать сборку или поведение не оставив при этом явного следа, потому что его взвели где-нибудь на третьем уровне инклюдов или затянули из какой-нибудь соседней библиотеки. Модули в этом смысле становятся более изолированными и по плану такой дефайн не будет влиять на состояние модуля
// ---------------------- main.cpp
#define FOO // влияет только на этот cpp не влияя на поведения импортов
// необходимые флаги взводятся при компиляции самого модуля
// поэтому поведение после импорта уже будет фиксированным
import Foo // собран без FOO и ASD
import Bar // собран с FOOПолучаем неплохую инкапсуляцию. Что ко всему позволит использовать это для оптимизации бинарей по размеру, избавляясь от неиспользуемых компонент.
import в модуль перестаёт влиять на скорость сборки кода, импортирующего этот модуля.
// ---------------------- header.hpp
// один раз добавишь в заголовочник и теперь все эти инклюды будут
// всегда добавляться во всех пользователей header.hpp
// каждый из заголовочников будет пересобирать эти шаблоны и таскать
// с собой кучу мёртвого кода
#include <numeric>
#include <vector>
#include <unordered_map>
#include <map>
#include <ranges>
#include "asd.hpp" // некоторый хэдер который тут оказался случайно
// ---------------------- modules.ixx
import std
// также использует импортирует всё что было упомянуто выше,
// но остаётся в пределах этого модуля/юнита компиляции.
// Пока код не вызван, он не будет висеть мёртвым кодомВсё это пока конечно есть только в идеальной картине мира, в реальности только часть из всего этого существует, работает и поддерживается внешними инструментами.
Люди конечно хотели бы как в rust, чтобы можно было иметь один файл, где ты явно обозначешь модуль, видимость компонент и прозрачные юниты трансляции, но как обычно встаёт проблема поддержки совместимости и нельзя просто взять и добавить, не переписав при этом половину компилятора.
#define FOO // влияет только на этот cpp не влияя на поведения импортов ...
Если я правильно понял Антона, комитет так пока окончательно и не определился с поведение директивы #define в модулях и это один из вопрос, который до сих пор не решен.
По итогам конференции загорелся вайб-кодингом и решил повторить это дома. Результаты описал в статье Вайб-кодинг и реальное программирование на С++ с по итогам реального применения генеративных LLM моделей, но уже в "боевых условиях".
Харденинг, модули в С++ и первый опыт вайб-кодинга у программиста со стажем5