Вы сами понимаете не логичность собственных комментариев?
Создатель термина лично пишет, почему он его использовал. Из-за получения “вибраций” при новом подходе к программированию. Когда не нужно самому писать код, а за тебя это делает LLM, а ты просто принимаешь его не забираясь в деталях и ловишь от этого кайф. Да, это работает не всегда, и иногда приходится разбираться в неработающем коде, но это мелочи, по сравнению с ощущениями от подобного подхода.
А вы пишите, что не обращайте внимания на ощущения, вайбкодинг - это тяп-ляп код. Если вы ставите в перед угла его качество, пожалуйста. Я же акцентирую внимание именно на эмоциях от использования LLM, а от хренового кода стараюсь избавляться, тоже не без помощи моделей и с одновременным получением вайба :-)
Где вы забываете про код и полностью отдаетесь вибрациям… Код выходит за рамки моего обычного понимания, мне приходится действительно читать его некоторое время. …
Я не спорю, что это слово превратилось в негативное как раз из-за подобного подхода к результату. Но это не отменяет факт самих “вибраций” от применения LLM
При вайб-кодинге может использоваться практика принятие кода без его проверки. Так вынужденно поступают те, что не разбирается в программировании, но это не означает, что все именно так и поступают.
Поэтому если вы ловите кайф от тяп-ляп кода, это ваше законное право. Но не приписывайте собственные предпочтения все остальным без разбора.
Вы сами подмениваете понятия. Вайб, это про эмоции, а не про качество. Если вы получаете удовольствие от плохого качества кода, значит для вас вайб-кодинг именно такой. Я же получаю удовольствие от хорошего результат работы и не считаю зазорным что-то переделать или улучшить.
У вас используется несколько допущений (теорем) из-за изменения которых можно сделать прямо противоположные выводы.
Если говорить про машину ТЬюринга, то тут все просто, её не существует. Это исключительно математическая абстракция, которая нужна для, … наверно, для формализованного определения такого термина, как “алгоритм” и вся вычислительная техника :-).
Сейчас в законе о национальном ИИ все к этому и идет. Не уверен, что будут именно рассылать письма, ведь задачу кто-то должен сформулировать, работу принять и проверить. А вот что ценник на “правильные модели” взлети до небес, в этом я не практически сомневаюсь. Новый вариант импортозамещения :-)
I’m working on a different approach to solving the problem of safety software development and performance - ensuring trusted at the level of programming language syntax and then translating the code into C++. https://github.com/afteri-ru/trust-lang
А потом уже директору придется писать письма с просьбой передать то, что было наворочено, чтобы исправлять то, что получилось в конечном итоге.
LLM не напишет за вас код, если вы в нем не разбираетесь. Кто-то все равно должен понимать, что и почему должно быть сделано и нести за это ответственность, в том числе и за результат роботы LLM.
Fil-C author says that his front-end is compatible with C++20 and most software can be compiled with Fil-C just find.
That’s right. It’s call-compatible with C++, and I’m talking about the “don’t pay for what you don’t use” ideology. After all, it adds not just additional data, but additional address checking at runtime, a sort of garbage collector/analyzer.
Yes, that’s Clang the author is talking about. The idea is brilliant. I also did something similar to protect against application crashes due to stack overflows https://github.com/afteri-ru/stack-check
I’m familiar with this language and have explored its capabilities. Unfortunately, it implements the concept of runtime pointer management, which is incompatible with C++.
Позвольте усомнится серьезности ваших решений,тем более вы сами написали, что реальных аргументов у и вовсе нет. А есть только желания потешаться над другими. Да и ведет себя вы отнюдь ни как профессионал.
Вы не учитываете геополитику и человеческий менталитет.
Эсперанто очень даже используется при общении и создании литературы. Но все это делается только силами энтузиастов без поддержки корпораций и государственной помощи. Корпорациям это ненужно, а государствам нужно защищать свои интересы, которые тесно связаны с национальными языками.
Однако у эсперанто для машин нет национальности и он не пересекается с какими либо государственными интересами, ведь он нужен не для людей. А если корпорации увидят реальную экономию за счет упрощения обучения моделей (например, за счет уменьшения количества ошибок), то сразу появится и финансовая поддержка и его продвижение.
Это дает теоретическое обоснование необходимости разработки универсальной грамматики, которая позволит исключить сложность парсинга синтаксиса у современных языков программирования с различными историческими наслоениями при их развитии.
Подобный синтаксис может стать своего рода “Esperanto for machines”, универсальную грамматикой для выражения синтаксических конструкций, который напрямую описывают вычислительные алгоритмы без учета особенностей человеческой психики :-)
прямо во время компиляции раскрывается по месту в AST …
В С/С++ макропроцессор работает до, а не вовремя компиляции и поэтому ничего не знает про AST и делается индивидуально для каждой единицы трансляции. Препроцессор ищет в коде лексему, совпадающие с именем макроса и заменяет её.
В моем случае макропроцессор может заменять не одну лексему, а сразу целую последовательность лексем, т.е. фактически это специализированный regexp, поэтому он может заменять не по одной лексеме за раз, а по заданному шаблону.
За счет этого и реализуется возможность создания универсального DSL. В синтаксисе не используются ключевые слова (нет шанса с ними пересечся), а за счет шаблонов замены получается обычных синтаксис func name(): type { return …}; и т.д.
Причем макропроцессору доступны для анализа и соседние лексемы, за счет чего он может валидировать использование самих макросов (например проверить, что следующим символом должна быть открывающая скобка).
Можно одновременно определить @foo и %foo в одной области видимости? — Если нет, то пардон, вы символами заменяется функции LSP. А если да — это ад, на мой вкус.
Если макрос @foo определен раньше, то при создание %foo будет предупреждение, но это не ошибка, так как это объекты разных уровней и их можно использовать одновременно. Макросы хоть и являются частью AST, но они уже полностью раскрыта на момент его анализа и наличие двух определений в одной области видимости влияет только на порядок разрешения имен без сигилов.
А использование сигилов для классификации идентификаторов на самом деле очень удобно. Можно с первого взгляда определить к какому виду относится этот объект (глобальный, локальный, макрос и т.д. ), а если они напрягают, то можно и не использовать, так как идентификатор будет найдено после разрешения имен.
Зато есть возможность однозначной идентификации объектов при совместном использовании всех вариантов квалификаторов, которые визуально различимы и не пересекаются (макрос, модуль, пространство имен, тип, класс, функция, метод класса или его поле или локальная переменная). И опять же, это если требуется, но не обязательно.
Вы сами понимаете не логичность собственных комментариев?
Создатель термина лично пишет, почему он его использовал. Из-за получения “вибраций” при новом подходе к программированию. Когда не нужно самому писать код, а за тебя это делает LLM, а ты просто принимаешь его не забираясь в деталях и ловишь от этого кайф. Да, это работает не всегда, и иногда приходится разбираться в неработающем коде, но это мелочи, по сравнению с ощущениями от подобного подхода.
А вы пишите, что не обращайте внимания на ощущения, вайбкодинг - это тяп-ляп код. Если вы ставите в перед угла его качество, пожалуйста. Я же акцентирую внимание именно на эмоциях от использования LLM, а от хренового кода стараюсь избавляться, тоже не без помощи моделей и с одновременным получением вайба :-)
https://habr.com/ru/news/878868/
Я не спорю, что это слово превратилось в негативное как раз из-за подобного подхода к результату. Но это не отменяет факт самих “вибраций” от применения LLM
При вайб-кодинге может использоваться практика принятие кода без его проверки. Так вынужденно поступают те, что не разбирается в программировании, но это не означает, что все именно так и поступают.
Поэтому если вы ловите кайф от тяп-ляп кода, это ваше законное право. Но не приписывайте собственные предпочтения все остальным без разбора.
Вы сами подмениваете понятия. Вайб, это про эмоции, а не про качество. Если вы получаете удовольствие от плохого качества кода, значит для вас вайб-кодинг именно такой. Я же получаю удовольствие от хорошего результат работы и не считаю зазорным что-то переделать или улучшить.
вайбкодинг, это от слова vibe, не от тяп-ляп :-)
Как это знакомо :-) https://habr.com/ru/articles/1027706/
У вас используется несколько допущений (теорем) из-за изменения которых можно сделать прямо противоположные выводы.
Если говорить про машину ТЬюринга, то тут все просто, её не существует. Это исключительно математическая абстракция, которая нужна для, … наверно, для формализованного определения такого термина, как “алгоритм” и вся вычислительная техника :-).
Сейчас в законе о национальном ИИ все к этому и идет. Не уверен, что будут именно рассылать письма, ведь задачу кто-то должен сформулировать, работу принять и проверить. А вот что ценник на “правильные модели” взлети до небес, в этом я не практически сомневаюсь. Новый вариант импортозамещения :-)
This (economics) is the main reason and headache of C++, and this is what this article is written about :-)
I’m working on a different approach to solving the problem of safety software development and performance - ensuring trusted at the level of programming language syntax and then translating the code into C++. https://github.com/afteri-ru/trust-lang
А потом уже директору придется писать письма с просьбой передать то, что было наворочено, чтобы исправлять то, что получилось в конечном итоге.
LLM не напишет за вас код, если вы в нем не разбираетесь. Кто-то все равно должен понимать, что и почему должно быть сделано и нести за это ответственность, в том числе и за результат роботы LLM.
That’s right. It’s call-compatible with C++, and I’m talking about the “don’t pay for what you don’t use” ideology. After all, it adds not just additional data, but additional address checking at runtime, a sort of garbage collector/analyzer.
Yes, that’s Clang the author is talking about. The idea is brilliant. I also did something similar to protect against application crashes due to stack overflows https://github.com/afteri-ru/stack-check
I’m familiar with this language and have explored its capabilities. Unfortunately, it implements the concept of runtime pointer management, which is incompatible with C++.
Позвольте усомнится серьезности ваших решений,тем более вы сами написали, что реальных аргументов у и вовсе нет. А есть только желания потешаться над другими. Да и ведет себя вы отнюдь ни как профессионал.
А раз у вас нет аргументов, кроме как потешаться, то может быть стоит над этим подумать и попробовать разобраться в этом вопросе? :-)
с чем вы спорите или пытаетесь доказать?
Вы не учитываете геополитику и человеческий менталитет.
Эсперанто очень даже используется при общении и создании литературы. Но все это делается только силами энтузиастов без поддержки корпораций и государственной помощи. Корпорациям это ненужно, а государствам нужно защищать свои интересы, которые тесно связаны с национальными языками.
Однако у эсперанто для машин нет национальности и он не пересекается с какими либо государственными интересами, ведь он нужен не для людей. А если корпорации увидят реальную экономию за счет упрощения обучения моделей (например, за счет уменьшения количества ошибок), то сразу появится и финансовая поддержка и его продвижение.
Спасибо за статью и ссылки на исследования.
Это дает теоретическое обоснование необходимости разработки универсальной грамматики, которая позволит исключить сложность парсинга синтаксиса у современных языков программирования с различными историческими наслоениями при их развитии.
Подобный синтаксис может стать своего рода “Esperanto for machines”, универсальную грамматикой для выражения синтаксических конструкций, который напрямую описывают вычислительные алгоритмы без учета особенностей человеческой психики :-)
В С/С++ макропроцессор работает до, а не вовремя компиляции и поэтому ничего не знает про AST и делается индивидуально для каждой единицы трансляции. Препроцессор ищет в коде лексему, совпадающие с именем макроса и заменяет её.
В моем случае макропроцессор может заменять не одну лексему, а сразу целую последовательность лексем, т.е. фактически это специализированный regexp, поэтому он может заменять не по одной лексеме за раз, а по заданному шаблону.
За счет этого и реализуется возможность создания универсального DSL. В синтаксисе не используются ключевые слова (нет шанса с ними пересечся), а за счет шаблонов замены получается обычных синтаксис func name(): type { return …}; и т.д.
Причем макропроцессору доступны для анализа и соседние лексемы, за счет чего он может валидировать использование самих макросов (например проверить, что следующим символом должна быть открывающая скобка).
Если макрос @foo определен раньше, то при создание %foo будет предупреждение, но это не ошибка, так как это объекты разных уровней и их можно использовать одновременно. Макросы хоть и являются частью AST, но они уже полностью раскрыта на момент его анализа и наличие двух определений в одной области видимости влияет только на порядок разрешения имен без сигилов.
Почему? Кажется в Julia именно так и сделано.
А использование сигилов для классификации идентификаторов на самом деле очень удобно. Можно с первого взгляда определить к какому виду относится этот объект (глобальный, локальный, макрос и т.д. ), а если они напрягают, то можно и не использовать, так как идентификатор будет найдено после разрешения имен.
Зато есть возможность однозначной идентификации объектов при совместном использовании всех вариантов квалификаторов, которые визуально различимы и не пересекаются (макрос, модуль, пространство имен, тип, класс, функция, метод класса или его поле или локальная переменная). И опять же, это если требуется, но не обязательно.