Задумывались ли вы о том, насколько архаичен дизайн операционных систем, которыми мы пользуемся в настоящее время?

Например, почему в Windows (включая 11-тую версию) основной диск с операционной системой называется C?

Начну с определений.

Симкод — это последовательность симкоманд.

Симкоманда — это символьная машинная макрокоманда с Си-подобным синтаксисом.

Например, ассемблерной команде add rax, rbx соответствует симкоманда rax += rbx.

Симкод позволяет выразить любой ассемблерный код [и как следствие машинный], только в более человекочитаемом виде. Однако, симкод не пытается назначить символьное обозначение для абсолютно каждой ассемблерной команды — те команды ассемблера, которые не имеют символьной записи, оставляются как есть. Таким образом, симкод является надмножеством ассемблера.

В процессе разработки мини-библиотеки файлового ввода я изучал код реализации функций/методов работы с файлами в стандартных библиотеках различных языков программирования, в том числе и Rust.

Глаз зацепился за реализацию итератора чтения файла по строкам. Для реализации итератора в Rust достаточно определения всего одной функции next()!
Это маленькое открытие сподвигло меня к изучению того, как реализованы итераторы в других языках программирования.

В данной статье я поделюсь результатами этого небольшого исследования, а также представлю новую модель итераторов, которую я планирую сделать основной для языка 11l, и которую можно уже сейчас использовать в C++ проектах посредством простого адаптера (вот пример использования).

Поводом к написанию данной статьи и к разработке соответствующей мини-библиотеки ffh стало одно из практических заданий по дисциплине ‘Языки программирования’, которую я веду. В этом задании необходимо прочитать все строки из текстового файла для последующей обработки. Так вот, у студентов, выбравших для выполнения этого задания язык C++ [язык программирования выбирается студентом для каждого задания, но чаще всего выбирают C++ или Python], почему-то иногда читалась из файла лишняя пустая строка. В прошлые годы я не придавал этому большого значения, но в последний раз решил таки разобраться в чём проблема.

Данная статья посвящена находящемуся на стадии проектирования компилятору 11lc. В ней перечисляются наиболее яркие особенности этого компилятора.

Отсутствие скрытой неэффективности

Это свойство скорее языка программирования 11l, нежели компилятора. Однако оно настолько важно и настолько отличает язык 11l от C++, D или даже Nim, что я решил разобрать его подробно в данной статье.

Уолтер Брайт, создатель языка D, писал:

Templates in C++ have evolved from little more than token substitution into a programming language in itself. Many useful aspects of C++ templates have been discovered rather than designed.

Так вот, как я считаю, нечто похожее произошло и с семантикой перемещения (move semantics). И в C++ и в D она появилась достаточно поздно, и если бы эти языки проектировались с опорой на семантику перемещения изначально, то в них было бы гораздо меньше скрытой неэффективности (hidden inefficiency). О чём идёт речь? Рассмотрю это на примере C++.

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

Размышляя о роли человека, я решил пойти от противоположного, и исключить то, что определённо ролью человека не является.

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

В данной статье приводятся наиболее полезные примеры перегрузки на основе имён аргументов, которые встретились в моей практике, и которые я воплотил в 11l. Просто про именованные аргументы функций/методов здесь я говорить не буду: их польза или вред являются предметом споров, а поддержка в языках программирования варьируется от практически полного игнорирования (привет, C++) до явного злоупотребления\overuse этой возможностью (привет, Swift).

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

Однажды на проводимом мной практическом занятии [по ЯП] я, скучая, разглядывал список студентов группы. Глаз зацепился за знак ударения в фамилии Лемзекóв, который я поставил [для себя] после того, как произнёс фамилию этого студента неправильно. Я мысленно прочёл эту фамилию по слогам, и тут у меня возник вопрос: «а по какому алгоритму мозг разбивает слова по слогам?» Почему-то интуитивно получается "Лем-зе-ков", а не "Ле-мзе-ков" или "Лем-зек-ов". Я выписал ещё несколько примеров, и разглядывая их размышлял о том, как перевести это в алгоритм.

Около 10 лет назад у меня начались серьёзные проблемы в ментальной сфере, в том числе с памятью {впрочем, в этом есть и свои плюсы: например негативные эмоции [злость на кого-то, раздражение, обида] забываются так быстро, что практически полностью перестали меня беспокоить}. Я просто физически перестал понимать всякие сложные штуки вроде графических API или каких-то объёмных библиотек, а при выполнении рабочих задач столкнулся с такой проблемой что к концу прочтения текста какой-нибудь не самой короткой задачи я забывал начало этой задачи (так что мне приходилось перечитывать условие задачи много раз чтобы хоть как-то запомнить его).

Несмотря на то, что к этому моменту я уже закончил разработку графического движка для одного [впрочем не слишком коммерчески успешного] игрового проекта, на меня накатывала апатия и депрессия, и не удивительно — что толку быть разработчиком движка, код которого ты просто перестал понимать (а о возможности его [графического движка] совершенствования и говорить нечего).

Рассмотрим такой пример кода:

void f(int i)
{
    auto g = [i](auto j)
    {
        return i + j;
    };
    g = [i](auto j)
    {
        return i - j;
    };
    g(1);
}

При компиляции возникнет ошибка в строке g = [i](auto j).

Почему так происходит?

Судя по результатам голосований (на compiler.su и даже здесь на Хабре) идею программирования на русском поддерживает не так уж и мало людей.

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

This article discusses the lexical analyzer, which is an integral part of any compiler.

The task of the lexical analyzer is to split the source code of the program into tokens.

So for example the code

print(1 + 2)

will be tokenized as
print, (, 1, +, 2 and )

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

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

Так, например, код

print(1 + 2)

будет разбит на лексемы
print, (, 1, +, 2 и )

Several years have passed since the appearance of the first text markup language that supports “dendrowriting”, but no worthwhile piece of text demonstrating the advantages of the new writing method/technology has yet appeared.

The largest “dendrotext” was a couple of paragraphs in the pqmarkup documentation, consisting of only ~1300 characters and available only in Russian.

In English there was no “dendrotext” at all, as such [apart from small insertions in the documentation for the 11l programming language (e.g., ‘Boolean type’ in Built-in types)].

But last year...

Со времени появления первого языка разметки текста, который поддерживает «древопись», прошло вот уже несколько лет, однако достойного текста, демонстрирующего преимущества новой технологии письменности, так и не появилось.

И самым большим «древотекстом» была пара абзацев из документации к пк-разметке {‘Дополнительные возможности форматирования’ → ‘Спойлеры (разворачиваемый блок информации)’ → ‘Для чего нужна последняя форма’ → см. скрытый текст после слова ‘древовидно’}, которые составляют всего ~1300 знаков.

А на английском языке «древотекста» как такового не было вообще [не считая маленькие вставки в документации к языку программирования 11l (например ‘Boolean type’ в Built-in types)].

Но в прошлом году...

В данной статье рассматриваются наиболее интересные преобразования, которые выполняет цепочка из двух транспайлеров (первый переводит код на языке Python в код на новом языке программирования 11l, а второй — код на 11l в C++), а также производится сравнение производительности с другими средствами ускорения/исполнения кода на Python (PyPy, Cython, Nuitka).

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

КДПВ:

geektimes.ru/post/100171:

I'm always delighted by the light touch and stillness of early programming languages. Not much text; a lot gets done. Old programs read like quiet conversations between a well-spoken researcher and a well-studied mechanical colleague, not as a debate with a compiler. Who'd have guessed sophistication bought such noise? – Dick Gabriel ... The standard languages (Java, C++) are statically typed. Most outsider languages (Ruby, Python, JavaScript) are interpreted and dynamically typed. Perhaps as a result, non-expert programmers have confused "ease of use" with interpretation and dynamic typing. The world has split into a false dichotomy: nice, interpreted, dynamic versus ugly, compiled, static. Time to put things right.

Меня всегда восхищала лёгкость и спокойствие ранних языков программирования. Немного текста; но делается многое. Старые программы читаются как тихие разговоры между хорошо говорящим исследователем и хорошо обученным механическим коллегой, а не как дебаты с компилятором. Кто бы мог подумать что изощрённость принесёт так много шума? — Дик Габриел ... Стандартные языки (Java, C++) — статически типизированные. Большинство языков-аутсайдеров (Ruby, Python, JavaScript) — интерпретируемые и динамически типизированные. Возможно в результате этого программисты неспециалисты путают "простоту использования" с интерпретируемостью и динамической типизацией. Мир разделился ложной дихотомией: приятные, интерпретируемые, динамические против уродливых, компилируемых, статических. Пришло время чтобы исправить эту ситуацию.

На этой пафосной ноте перейду к примерам на новом языке программирования.

Понимаю, что данная статья наверняка вызовет вопросы у модераторов (о целесообразности её пребывания на Хабре), но где как не здесь [на крупнейшем в Европе ресурсе для IT-специалистов] поднимать вопрос ответа на главный вопрос с точки зрения IT?

Для начала вкратце объясню, почему этот вопрос вообще актуален.

░░░░░░░░░░░░░░░░░░░░░░░░░░
░░▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒░░
░░▒▒▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▒▒░░
░░▒▒▓▓██▓▓██▓▓██████▓▓▒▒░░
░░▒▒▓▓██▓▓██▓▓▓▓▓▓██▓▓▒▒░░
░░▒▒▓▓██████▓▓██████▓▓▒▒░░
░░▒▒▓▓▓▓▓▓██▓▓██▓▓▓▓▓▓▒▒░░
░░▒▒▓▓▓▓▓▓██▓▓██████▓▓▒▒░░
░░▒▒▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▒▒░░
░░▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒░░
░░░░░░░░░░░░░░░░░░░░░░░░░░