Последнее время только ленивый не пишет о великом прорыве человечества в области разработки искусственного интеллекта под общим названием "большая языковая модель" (LLM, large language model). И хотя у них остается еще много возможностей для совершенствования, но за последние несколько лет подобные приложения стали действительно востребованными. Большие языковые модели привлекают своей сверхъестественной способностью резюмировать текст, понимать естественный язык и создавать контент (и судя качеству некоторых статей, в том числе и тут на Хабре).

Правда подобные инструменты иногда сбоят и выдают некорректную информацию т.е. "галлюцинируют", которую выдают за правду. Генераторы изображений могут нарисовать лошадей с пятью ногами или кисть руки с семью пальцами. Однако подобные "фантазии" не всегда плохо. Например, когда творчество ценится выше точности, генерация не существующего контента, но похожего на правду, может оказаться полезной.

Томас Валадес (Thomas Valadez) воспользовался этим творческим потенциалом, чтобы создать интересное устройство под названием «Storybook». Его проект с открытым исходным кодом превращает Raspberry Pi в рассказчика на базе искусственного интеллекта, способного создавать иллюстрированные сказки. Это устройство использует LLM и генератор изображений для создания одной страницы книги из никогда не существовавшего сборника рассказов и выводит их на E-Ink дисплей.

I always pay attention to assessing the complexity of programming in a particular language. Programming is indeed not an easy task and this is perceived as a fact and usually does not require any confirmation.

But the concept of “complexity” is akin to the term “heap”. For some, five coconuts is not so much, but for someone who ate one and “didn’t want any more,” this means that even one coconut will be too much for him.

The same goes for the complexity of programs. It seems that the constant increase in the complexity of programs is obvious to everyone and is observed in all areas of application of IT technologies, and programming languages themselves become more and more complex as they develop, but assessing “complexity” using numerical metrics is a problem. obviously a thankless task, but also “You can’t manage what you can’t measure...”

Typically, talk of “complexity” only implies value judgments without any numerical evaluation. And since I am personally interested in the issue of the complexity of programming languages, I decided to calculate the complexity of implementing the gcc compiler on some conditional “parrots”. What if we could see some patterns of difficulty changing over time?

Brainfuck — это один из эзотерических языков программирования, который имеет всего восемь команд, каждая из которых записывается одним символом.

А Bodyfuck — это жестовый интерпретатор Brainfuck, который позволяет писать код программы, используя различные движения тела без использования клавиатуры.

Смотрите, не перепутайте! :-)

Every programmer is familiar with the concept of "reference." This term usually refers to a small object whose main task is to provide access to another object physically located elsewhere. Because of this, references are convenient to use, they are easily copied, and they make it very easy to access the object to which the reference points, allowing access to the same data from different parts of the program.

Unfortunately, manual memory management, or more precisely, manual memory control, is the most common cause of various errors and vulnerabilities in software. All attempts at automatic memory management through various managers are hampered by the need to control the creation and deletion of objects, as well as periodically run garbage collection, which negatively affects application performance.

However, references in one form or another are supported in all programming languages, although the term often implies not completely equivalent terms. For example, the word "reference" can be understood as a reference as an address in memory (as in C++) and a reference as a pointer to an object (as in Python or Java).

Although there are programming languages that try to solve these problems through the concept of "ownership" (Rust, Argentum, or NewLang). The possible solution to these and other existing problems with references will be discussed further.

Practically all programming languages are built either on the principle of similarity (to make like this one, only with its own blackjack) or to realize some new concept (modularity, purity of functional calculations, etc.). Or both at the same time.

But in any case, the creator of a new programming language doesn't take his ideas randomly out of thin air. They are still based on his previous experience, obsession with the new concept and other initial settings and constraints.

Is there a minimal set of lexemes, operators, or syntactic constructs that can be used to construct an arbitrary grammar for a modern general-purpose programming language?

Бесконечно можно смотреть на три вещи: как горит огонь, как течет вода и то как фронтендеры пишут очередную статью про this.

Но все же такое количество статей существует не просто так, тема действительно для многих запутанная и зачастую даже сами авторы статей неправильно понимают this и соответственно закладывают неправильное понимание этого у читателей. Есть и хорошие статьи, где все описано верно, но в основном чисто с практической точки зрения, без погружения в то “как это работает на самом деле”.

В этой статье я попытаюсь раскрыть эту тему как можно глубже с теоретической точки зрения, исходя из спецификации ECMAScript, а уже на основе этой теории вывести определение значения this на практике.

Rust сочетает в себе высокую производительность с безопасностью памяти. Одной из его особенностей является отсутствие сборщика мусора традиционного инструмента для автоматического управления памятью во многих ЯПах. Вместо этого, Rust использует уникальную систему владения и заимствования, которая позволяет эффективно управлять памятью, предотвращая при этом распространенные ошибки, такие как утечки памяти и доступ к уже освобожденной памяти.

Привет, Хабр!

Rust — язык программирования с акцентом на безопасность, скорость и параллелизм. Rust решает многие проблемы, с которыми сталкиваются на других ЯП, например, управление памятью без сборщика мусора.

Очевидно из-за многих преимуществ Rust выбирают все большей компаний. В этой статье рассмотрим пять часто задаваемых вопросов на собеседованиях, которые помогут подготовиться к собеседованию по части Rust.

Любому программисту знакомо понятие "ссылка". Под этим термином обычно понимают небольшой объект, главная задача которого обеспечить доступ к другому объекту, физически расположенному в другом месте. Из-за этого ссылки удобно использовать, они легко копируются, и с их помощью очень просто получить доступ к объекту, на который эта ссылка ссылается и можно получить доступ к одним и тем же данным из разных мест программы.

К сожалению ссылки, точнее ручное управление памятью, является наиболее частой причиной возникновения различных ошибок и уязвимостей в программном обеспечении. А все попытки автоматического управления памятью с помощью различных менеджеров упираются в необходимость контролировать создание и удаление объектов, а также периодически запускать сборщик мусора, что отнюдь не положительно сказывается на производительности приложений.

Тем не менее, ссылки в той или иной форме поддерживаются во всех языках программирования, хотя под этим термином часто подразумеваются не полностью эквивалентные термины. Например, под словом "ссылка" можно понимать ссылку как адрес в памяти (как в С++) и ссылку, как указатель на объект (как в Python или Java).

Хотя встречаются языки программирования, которые пытаются решать данные проблемы за счет концепции "владения" (Rust, Аргентум или NewLang). О возможном решении этих и других имеющихся проблем со ссылками далее и пойдет речь.

У меня уже более пяти лет пылится старый монитор ASUS VH323T. Это довольно старая модель с диагональю 23" и довольно неплохой матрицей (на КДПВ не он), но все дело портит очень плохая подсветка. Мало того, что у нее очень низкая яркость (всего 300 кд/м2), так еще лампы подсветки со временем очень сильно потускнели до противного желтого цвета, в результате чего монитор был заменен на более современный, чтобы не ломать глаза.

Тем не менее, монитор вполне рабочий, и противное земноводное не разрешает его просто взять и выбросить на помойку, тогда как продать монитор новому владельцу не позволяет уже совесть.

Когда-то встречал на просторах интернета пару статей, в которых описывалось, что можно заменить в мониторе старые лампы подсветки на новые. И после того, как в очередной раз запнулся за коробку со старым монитором, решил попробовать заменить его подсветку на светодиодную. Ведь после этого его можно будет либо честно продать, либо просто выкинуть. В любом случае, избавлюсь от старого хлама :-)

Кому интересны рабочие нюансы и рассказ о не совсем очевидных проблемах, прошу под кат с фотками котиков этапов работ, конечного результата и финальных выводов.

Полгода назад я писал, как решал проблему с ушедшими JLCPCB. И вот с марта возникла новая проблема ахахах (истерический смех) —  китайские банки начали блокировать оплату от российских компаний за компоненты для сборки электроники. Оплаты не проходят даже у тех компаний, которые заключили долгосрочные контракты с китайскими производственными площадками.

Из-за этого увеличились сроки, а также ряд компаний начал работать через посредников, что сильно увеличило цену на поставку электронных компонентов.

Я порезал свой первый обзор + добавил несколько новых компаний, которые сейчас напрямую поставляют компоненты и печатные платы из Китая. В конце - сводная таблица с итогами.

Когда-то давно я писал статью-наблюдение про использование Хабра в качестве площадки для архитектурных ревью технических решений практически любой сложности Хабр — ума палата, и продолжаю пользоваться этим способом на постоянной основе.

А теперь, похоже, я нашел еще один очень полезный Хаброхак, который заключается в использования Хабра как записной книжки, но не как в том анекдоте я думал, что это блокнот для заметок, а всем видно оказывается что я здесь написал, а в самом хорошем смысле — для хранения результатов различных экспериментов, подведения итогов поиска в решения проблем и публикации итоговых выводов.

Так, на днях искал материалы про JIT компиляцию C++ в рантайме с помощью clang/llvm и поиск мне выдал мою же собственную статью трехгодичной давности: Динамическая JIT компиляция С/С++ в LLVM с помощью Clang / Хабр. В результате появилась уже эта новая статья про JIT компиляцию C/С++.

Данный текст является ответом на опубликованную накануне «Оду бесполезности споров» с целью рассказать о проекте, который намерен принципиально решить проблему анализа достоверности информации в Интернете и оценки репутации ее авторов. Я считаю, что новые никогда ранее не существовавшие децентрализованные технологии дают нам возможность наконец найти ответ на извечный вопрос «Что есть истина?», которым уже почти две тысячи лет задается человечество.

Python-разработчики, как правило, хорошо знают, что такое и для чего нужен GIL, вопросы по нему встречаются на большинстве собеседований, я и сам люблю их задавать. Но в CPython его скоро не будет. Да, core-разработчики CPython взяли курс на его удаление.

Разберём основные концепции того, как это будет произведено, с обзором соответствующего PEP 703.

В этой статье мы сосредоточимся на ключевых элементах асинхронного программирования в Java Script: Event Loop, Event Bus, промисы и синтаксический сахар async/await. Разберемся, как эти концепции взаимодействуют между собой и как их использование помогает нам создавать более эффективные и отзывчивые веб-приложения.

Мы начнем с изучения роли Event Loop - механизма, ответственного за управление выполнением асинхронного кода. Затем мы перейдем к рассмотрению Event Bus, который обеспечивает коммуникацию между различными компонентами приложения. После этого мы ознакомимся с промисами и синтаксическим сахаром async/await, которые значительно упрощают работу с асинхронным кодом и делают его более читаемым и понятным.

Приветствую уважаемую публику Хабра от лица условно анонимного представителя компании «Актив», занимающейся производством небезызвестных средств аутентификации и электронной подписи.

В этой статье хотелось бы рассказать об одном из менее известных направлений деятельности подразделения Рутокен, связанного с обеспечением киберфизической безопасности. В рамках данного направления компания уже не первый год производит встраиваемые в управляющее и управляемое оборудование устройства линейки Рутокен Модуль. Не так давно в эти устройства (а заодно в токены и смарт-карты Рутокен ЭЦП 3.0) добавилась поддержка протокола CRISP, и это отличный повод рассказать и о самом протоколе, и о принципах интеграции устройств Рутокен Модуль, и об организации процессов разработки в компании.

Julia является одним из самых востребованных математических языков программирования. Однако некоторые особенности этого языка, которые обеспечивают гибкость и позволяют расширять её области применения, не столь часто используются программистами. В этой статье пойдёт речь о механизме макросов, который выгодно её отличает от прочих скриптовых языков программирования.

Механизм макросов используется в Julia довольно часто. Макрос при использовании начинается с символа @ и имеет вид @show, @benchmark… А также, в неявной форме, макросами являются регулярные выражения r"[a..z]" (это макрос с полным именем r_str), а также многочисленные другие способы применения, включая примеры Modia.jl / Unitful.jl с макросом u_str, где физическая величина «вшита» в число:

L = 0.8u"m",
m = 1.0u"kg",
d = 0.5u"Nms/rad",
g = 9.81u"m/s^2",


Здравствуйте!

Расскажу о серии задач, которая случайно возникла в процессе решения другой задачи. Мне на глаза попалось равенство:

81 * 27 = 2187

– Интересно, – подумал я. – А бывают ли ещё такие числа, чтобы цифры слева и справа повторялись?

Некоторые компании, защищая свои системы от несанкционированного доступа, используют изолированные компьютерные сети, или полностью обходятся без сетей. Работа в таких системах может быть сопряжена со сложностями, но нельзя сказать, что в них невозможно разрабатывать программные проекты. А особую важность в подобных ситуациях имеет подбор подходящего инструмента для контроля версий наподобие Git.

Система контроля версий Git вполне благополучно работает без удалённого репозитория. Такова её природа. При таком подходе можно создавать ветви репозитория, можно индексировать файлы и коммитить их в репозиторий. Всё выглядит так же, как и при обычной работе.