Давно полюбил формат Markdown за простоту и легкость его использования при документировании исходного кода и за возможность его применения при оформлении статей для Хабра. Потом добавился Obsidian для ведения заметок. И формат Markdown стал по сути основным способом форматирования набираемого текста.

Единственной, но весьма большой ложкой дегтя, оставалась проблема ввода символа решетки «#» при использовании русской клавиатуры. А так как знак решётки (октото́рп, хеш, знак номера, дие́з, sharp), в русской раскладке клавиатуры отсутствует, то каждый раз переключаться на английскую раскладку, меня немного утомляло. И «немного утомляло» еще мягко сказано, так как символ решетки, кроме указания заголовков в Markdown и тегов в Obsidian, еще часто используется как начало комментария до конца строки (в Bash, Python, NewLang).

А так как предлагаемые на просторах интернета способы ввода символа решетки в русской раскладке клавиатуры меня совсем не вдохновляли (и если Alt+35 на Numpad под виндой еще сойдет, но этот способ не работает под Linux, а занимать буфер обмена ради вставки одного символа, вообще не вариант), то пришлось потратить некоторое время на эксперименты, результатами которых я и хочу поделиться.

Помните, несколько лет назад была проведена согласованная клеветническая компания против Ричарда Столлмана, в которой он был ложно обвинён в одобрении изнасилований, и по результатом которой его вынудили уволиться с поста президента Фонда Свободного Программного Обеспечения?

Уже тогда многие предполагали, что данная спланированная акция является подготовкой к атаке производителей проприетарных программ на экосистему свободного программного обеспечения. Многие в это не верили (типа, «не приписывайте обычную глупость злому умыслу»), а кто-то не верит и сейчас. Ведь гораздо проще и удобнее игнорировать якобы не существующую опасность, ведь в противном случае на нее нужно как-то реагировать (хотя бы морально).

И вот сейчас, в релизе ядра Linux 6.2, произошло очень важное изменение — разрешён приём кода в ядро Linux под лицензией Copyleft-Next, для которой заявлена совместимость с GPLv2, что подтверждено юристами компаний SUSE и Red Hat (кто бы сомневался?).

Данная лицензия также содержит пункт о предоставлении прав на запатентованные технологии, что делает Copyleft-Next совместимой и с Apache 2.0. А для обеспечения полной совместимости с GPLv2, в тексте Copyleft-Next явно указано, что производная работа может поставляться не только под исходной лицензией Copyleft-Next, но и под лицензией GPL.

Но как говорится, «есть нюанс».

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

NewLang находится в процессе активного развития. Это третий публичный релиз в который добавлены новые существенные возможности по сравнению с предыдущей версией.

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

С самим лотереями особо не заморачивался и покупал билеты, которые не требуется заполнять. Какие нибудь 100-Лото и тому подобные. И вчера, я как и обычно, попросил несколько билетов на сдачу и… покупка не состоялась, потому что у меня потребовали номер мобильного телефона!

На прошлой неделе, после нескольких месяцев разработки, вышла очередная версия языка программирования NewLang. Одной из технических особенностей данного релиза является переход на использования компилятора clang вместо gcc.

Данная статья описывает причины смены компилятора, некоторые особенности этого процесса, проблемы, которые приходилось решать и итоговые выводы.

Автор надеется, что эта информация может оказаться полезной и позволит сэкономить кучу времени, если заранее знать некоторые подводные камни, а так же положительные стороны от перехода на clang.

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

Основной особенностью языка является простой, логичный и не противоречивый синтаксис, который основан не на использовании зарезервированных ключевых слов, а на строгой системе грамматических правил с использованием знаков препинания (в список которых входят и операторы языка).

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

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

Основной особенностью языка является простой, логичный и не противоречивый синтаксис, который основан не на использовании зарезервированных ключевых слов, а на строгой системе грамматических правил с использованием знаков препинания (в список которых входят и операторы языка).

Новое по сравнению с прошлым выпуском:

• Реализованы все основные алгоритмические конструкции: проверка условий, различные варианты циклов, сравнение по образцу, прерывание последовательности команд и возврат данных, обработка ошибок и т.д.
• Переработан основной синтаксис для отдельных языковых конструкций.
• Реализованы большинство операций с переменными, включая операторы раскрытие списков и тензоров.
• Серьезно переработана система встроенных типов, реализованы функции для их преобразования и для определения данных (последнее можно назвать data comprehensions).
• Добавлены новые тесты и пр.

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

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

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

И если рассуждать здраво, то ведь действительно от западных решений придется отказываться. И такой переход будет стоить не малых денег для бизнеса (который и так в пролете), а тут еще нужно будет раскошеливаться на переделку ИТ инфраструктуры и переобучение пользователей. Особенно, если будет поддержано предложение профильных ассоциаций чуть ли о не принудительном переходе на отечественный софт. Софт, который в большинстве своем является перебрендированным клоном какого нибудь свободного проекта, но который можно продавать втридорога, ведь все равно альтернатив нет и не будет.

Или все таки можно придумать что нибудь компромиссное? Не только в интересах крупных и особо приближенных ИТ компаний, а приемлемое и для обычных разработчиков, простых и корпоративных пользователей, в том числе и с учетом интересов государства?

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

Данная статья предназначена в первую очередь для проверки основных концепций нового языка программирования, а также для получения обратной связи от читателей Хабра. Ведь согласно наблюдению «Хабр-ума палата», не замыленный взгляд со стороны очень сильно помогает в проработке новых идей.

Этот проект очень долго был без собственного названия и в публикациях назывался просто и абстрактно «новый язык». Но после нескольких статей, временное название «новый язык» постепенно превратилось в имя собственное NewLang, которое я и решил в конечном итоге оставить (что еще раз подтверждает поговорку, что нет ничего более постоянного, чем что-то временное).

При создании компилятора для собственного языка программирования я сделал его как транспайлер в исходный код на С++, вот только реализация сильно подкачала. Сначала приходится генерировать динамическую библиотеку с помощью вызова gcc, который и сам по себе не очень быстрый, так еще его может и не быть на целевой машине, особенно на другой платформе (например Windows). Конечно, для первых экспериментов и такой реализации было достаточно, но сейчас, когда я начал готовить код компилятора к публикации, стало понятно, что текущий вариант с фоновым запуском gcc никуда не годится.

Из-за этого, я решил не откладывать перевод компилятора на использование LLVM, который планировался когда нибудь в будущем, а решил сделать это уже сейчас. И для этого нужно было научиться запускать компиляцию C++ кода с помощью библиотек Clang, но тут вылезло сразу несколько проблем.

Оказывается, интерфейс Clang меняется от версии к версии и все найденные мной примеры были старыми и не запускались в актуальной версии (Сlang 12), а стабильный C-style интерфейс предназначен для парсинга и анализа исходников и с помощью которого сгенерировать исполняемые файлы не получится*.

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

А теперь публикую результат своих изысканий в виде рабочего примера динамической компиляции С++ кода с последующей его загрузкой и выполнением скомпилированных функций. Исходники адаптированны под актуальную версию Clang 12. Пояснения к коду я перевел и дополнил перед публикацией, а ссылки на исходные материалы приведены в конце статьи.

• *) Кажется в 14 версии планируется реализовать C интерфейс для генерации исполняемых файлов.
• **) На самом деле, Clang может (или теперь может) компилировать файлы из оперативной памяти, поэтому в исходники я добавил и эту возможность.

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

До недавнего времени я считал, что императивная и декларативная парадигмы написания программ являются антагонистами и взаимоисключающими понятиями. Ведь выбор стиля написания кода, изначально определяется автором языка еще на стадии его проектирования и оказывает влияние на все последующие аспекты.

Но сейчас я думаю, что это не верно. Императивный и декларативный стили программирования не являются взаимоисключающими, а писать программы только в одной из указанных парадигм подталкивают правила синтаксиса, реализованные в языке!

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

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

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

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

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

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

И тот факт, что при атаках начинают применяться приемы социальной инженерии с использованием сразу несколько независимых каналов одновременно, значительно повышает их достоверность и вероятность срабатывания!

Итератор (от англ. iterator ― перечислитель) — интерфейс, предоставляющий доступ к элементам коллекции (массива или контейнера) и навигацию по ним. В различных системах итераторы могут иметь разные общепринятые названия. В терминах систем управления базами данных итераторы называются курсорами.

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

Ну и судя по моим наблюдениям Хабр — ума палата, буду рад любым комментариям и предложениям, которые помогут протестировать или улучшить предлагаемое решение.

Хочу представить на обсуждение читателей немного необычный концепт языка программирования, в котором отсутствует проблема, присущая практически всем промышленным языкам — постоянное увеличение сложности синтаксиса языка из-за его естественного развития по мере выхода новых версий и добавления новых фич. Эта проблема описана в материале Простое сложное программирование и Какая «идеальная» цель развития у языков программирования?

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

Особенности языка:

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

Ну и в соответствии с собственным наблюдением Хабр — ума палата, буду рад любым комментариям и предложениям, которые помогут протестировать или улучшить предлагаемое решение.

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

И хотя сам материал содержит вроде бы обоснованные способы борьбы с контрафактом, но по факту, наше текущее законодательство дает возможность владельцам авторских прав использовать данные инструменты со значительными злоупотреблениями. И как в подтверждение этого, совсем недавняя статья Роскомнадзор заблокировал портал и форум 4PDA.

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

Наверное уже многим надоело, что все кому не лень, пишут про очередной кризис в производстве микросхем, повышение отпускных цен на радиодетали и микроэлектронику или невозможность их приобрести вследствие нарушившихся цепочек поставок из-за пандемии COVID-19, майнинговой лихорадки или продолжающейся торговой войны США и Китая.

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

И вот теперь эту напасть я увидел воочию и сполна прочувстовал на себе. И если сказать, что был удивлен и шокирован, то это не сказать вообще ничего. Я просто не поверил своим глазам, когда увидел стоимость копеечного микроконтроллера STM32F105 из новой поставки.

Ровно два года назад, в апреле 2019 года, произошло знаменательное событие для всех сторонников свободного и открытого ПО, которые следят за Российскими новостями. АО «МЦСТ» "опубликовало" ОС Эльбрус для свободного скачивания. И несмотря на некоторые сложности в самом начале из-за возникшего ажиотажа, этот дистрибутив остается в свободном доступе по сей день и даже продолжает периодически обновляться.

На текущий момент доступны для скачивания версии «Эльбрус Линукс» 6.0.0 на базе ядра Linux 5.4 и версии 5.0-rc3 и 4.0.4 на базе ядра Linux 4.9.



Я специально написал слово «опубликован» в кавычках, т.к. на тот момент исходные тексты дистрибутива Эльбрус Линукс в свободном доступе отсутствовали. Два года назад в разговоре с CNews директор по маркетингу МЦСТ Константин Трушкин сообщил, что

… исходные коды на продукты компании пока недоступны ни для самостоятельного скачивания, ни по запросу, но в скором времени компания намерена их открыть.

Разные пакеты ПО выпускались МЦСТ под различными открытыми лицензиями, и под ними же будет происходить распространение исходных кодов.

Раскрывая исходные коды, компания преследует маркетинговые цели, связанные с продвижением продуктов МЦСТ, а также стремится расширить комьюнити разработчиков ПО под ОС «Эльбрус».

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

После уточнения всех её хотелок и нескольких экспериментов были сформированы примерные требования к проекту «видеосъемка для интернета»:

1. Съемка видео должна выполняться с использованием штатива (в противном случае на видео заметны движения оператора)
2. Требуется поворотный стол для экспозиции небольших предметов (так как камера располагается на штативе, а необходимо показать изделия со всех сторон).
3. Съемка должна вестись на камеру мобильного телефона, т.к. одно из мест для публикации, это Instagram, в котором опубликовать видео можно только с мобильника

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

Внимание, дальше картинки и видео!

В очередной раз увидел на Хабре статью про сложное дело под названием «программирование». И то, что программирование действительно является делом не простым воспринимается как факт и обычно не требует какого либо подтверждения.

Но понятие «сложность» сродни термину «куча». Для кого-то и пять кокосов это не куча, а кого-то съел один и «больше не хочется» — значит для него и единственного кокоса будет много.

Так и со сложностью ПО. Вроде бы увеличение сложности является для всех очевидным и наблюдается во всех сферах применения IT технологий, да и сами языки программирования по мере своего развития становятся все сложнее, а вот оценивать «сложность» с помощью численных метрик — дело заведомо неблагодарное, но и «нельзя управлять тем, что невозможно измерить ...».

Обычно разговоры о «сложности» включают в себя только оценочные суждения без какой либо численной оценки. А так как лично меня интересует вопрос сложности языков программирования, то я решил посчитать сложность реализации компилятора gcc в каких нибудь условных попугаях. Вдруг можно будет увидеть какие нибудь закономерности?

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

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

Об этой проблеме меня заставила задуматься первоапрельская статья «Доказательное программирование»

Понятно, что дата публикации статьи говорит сама за себя. Тем не менее, новые стандарты С++, постоянно выходящие спецификации Java или новый синтаксис у PHP 8, невольно заставляют задуматься, а в нужную ли сторону идет развитие языков программирования? Ведь большинство нововведений добавляют сложность в основной рабочий инструмент и решая одни проблемы, неявно добавляя множество других.

А что должно быть в конце прогресса у развития такой дисциплины как программирование? Или хотя бы у одного конкретного языка? Ради достижения какой конечной «идеальной» цели разрабатываются новые стандарты языков программирования?