Библиотека для форматирования текста в Си

На стадии препроцессора в языке C невозможно узнать размер типа, потому что:

📌 Препроцессор C — это этап до компиляции, который работает только с текстом. Он не знает ничего о типах, размерах переменных, структурах памяти и т.п.

Еще вопросы есть?

На стадии препроцессора в языке C невозможно узнать размер типа, потому что:

Еще вопросы есть?

Да. Как сделать разное описание структур в зависимости от размера указателя на целевой платформе без использования препроцессора и внешних программ? Или Си для этого не подходит? На Rust это делается без особых проблем, к слову.

подсказка из зала: юнион, юнион!

подсказка из зала: юнион, юнион!

Что «юнион, юнион»? Можно мне пример рабочего кода, пожалуйста? Потому что 100% такого кода, который я видел в живых работающих проектах, использовал препроцессор и внешние вызовы для генерации макросов.

Смари, даже в ядре такой код пишут: https://github.com/torvalds/linux/blob/master/tools/lib/bpf/hashmap.h#L21

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

примеры я тебе писать не обязана. у меня свои задачи и твоё образование в них не входит. считай это домашним заданием. типа, как в книжках пишут: а теперь попробуйте сами написать код, который... вот это.

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

Ну ты додик..

#include <stdio.h>
#include <stdint.h>

typedef struct {
    union {
        struct {
            uint32_t a;
        } ptr32;

        struct {
            uint64_t a;
        } ptr64;
    };
} MyStruct;

void main() {
    MyStruct s;
    if (sizeof(void*) == 8) {
        s.ptr64.a = 0x1122334455667788;
    } else {
        s.ptr32.a = 0x11223344;
    }
}

А руст все равно ненужный кусок недоразумения. Мне все еще не объяснили чем он лучше ada/spark. Тем что позволяет сжвшникам гадить в ядро это не ответ.

Господь Бог, анон! Это же чудовищный говнокод! Зачем ты такое написал?

А чем это лучше препроцессора? Кода-то больше вышло. Еще и ветвление появилось.

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

Ты удаляешь куски ядра, чтобы его собрать? Зачем? Ты %*?нутая?

примеры я тебе писать не обязана. у меня свои задачи и твоё образование в них не входит. считай это домашним заданием. типа, как в книжках пишут: а теперь попробуйте сами написать код, который… вот это.

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

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

Даже если что-то такое есть, то оно будет без тайп чекинга, а значит не особо нужно. Тайп чекинг есть либо в компиляторах в виде warning для printf, либо в C++ шаблонной магии как в fmt.

От работы со строками требуется вот какая штука на самом деле - умение быстро и точно считать количество букв/иероглифов (не байт, не бит, не кодепоинтов богомерзких), быстрая конкатенация строк, быстрая и удобная выборка подстрок и нормальный инструмент для регулярок который умеет со строками работать и не требует написания больших талмудов по работе с каждой строчкой. Ещё требуется поддержка юникодных символов (что конечно конфликтует с буквами, т.к. юникод это сраные кодепоинты автору которых надо по рукам ссаными тряпками). Дополнительным плюсом идут фичи вроде uppercase/lowercase трансформаций. И требуется это не потому что те кто работает со строками глупые и не знают что строка это последовательность 1 и 0, они даже знают что строку (как и любые другие данные) можно даже как функцию (в математическом смысле) рассматривать, если очень хочется. Требуется это потому, что тупые люди и наша вселенная генерируют для обработки данные не в удобном для машины виде и удобная обработка этих данных часто требует неудобный для машины вид их представления. Вот когда ИИ полностью выкинет сишников, то сишка заживёт может быть, т.к. у ИИ памяти поболе чем у человека и некоторые штуки которые человек в голове удержать не может, оно сможет нагенерировать, таким образом, переведя часть задач неудобных к решению со стороны человека к удобным к решению со стороны ИИ. Но это ещё не скоро будет, лет 5-10 надо подождать (до прототипов, в проду ещё жди).

что касается, опять же, сишки, то на ней пишут парсеры и лексеры. и специально переводят эти вещи именно в Си

Да пишут, от горя (потому как писать на сишке - горе и её берут когда можно не брать ассемблер, но надо выжать железку почти как на ассемблере). Но прежде чем написать, внезапно, надо провести некоторую научно-исследовательскую работу (без неё бесполезный код будет написан, т.к. все сишники почему-то вопят и требуют чёткого ТЗ, а R&D, который жрёт нынче ресурсов поболе конечных продуктов, на сишке всё равно не делают, засыпают отрасль деньгами, но сишку не берут и делают это не потому что учёные глупые и в сишку не могут, а сишники тупые и не могут в научно-исследовательскую деятельность, а потому что если делать R&D на сишке, то конкуренты обгонят на десятки лет за год, потому берут всякие питоны, R, SQL, иногда даже ужас вроде матлаба/GNU Octave и как-то с ними возятся).

В ядре много говнокода. Анон конечно написал сишное уродство, но вот это

return (h * 11400714819323198485llu) >> (__SIZEOF_LONG_LONG__ * 8 - bits);

ЗЫ

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

но вот это

return (h * 11400714819323198485llu) >> (__SIZEOF_LONG_LONG__ * 8 - bits);

ничуть не лучше

Это подсчёт хеша. Этот код так будет выглядеть на любом языке.

11400714819323198485llu

Вроде как это к числам фибоначчи относится, и их много, так что думается, что 11400714819323198485llu стоит вынести в константу как минимум. Уверен, что оно не в одном месте используется. Почему у сишников нет файла с математическими константами - ну видимо сишникам каша нравится.

А зачем ты сказал мне прыгать на лыжах в гамаке в противогазе? Что заказывали, то и получите. Распишитесь.

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

какой бред…

R&D на сишке

Еще один лютейший бред. R и matlab берут потому что там уже реализованы многие нужные вещи, причем на той же сишке. Тратить время на переимплементацию всего с нуля, конечно обгонят, только это от ЯП вообще не зависит.

Еще для общего развития - во многих компаниях, таких как Nokia или ARM R&D таки делают на сишке. В наши дни уже больше на плюсах, но и си там не гнушаются вообще.

Что заказывали, то и получите.

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

Зачем ты опять врешь? Вопрос на этой же странице, даже листать не надо:

Как сделать разное описание структур в зависимости от размера указателя на целевой платформе без использования препроцессора и внешних программ?

Я тебе скопипастил выдачу chatgpt. Говнокод-неговнокод, а оно тебе показало как. Еще вопросы? Можешь сам в LLM вбить. Я вам тут не посредник.

Я тебе скопипастил выдачу chatgpt.

lol

lmao even

Можешь сам в LLM вбить. Я вам тут не посредник.

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

Б-же.. кто тебе сказал, что я сишник? Я читал K&R в школе, но работаю программистом не на си.

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

Почему же они там реализованы, а в сишке с 1972 года не могут? Хотя нет, ты анон дезинформацию вводишь, т.к. питон работает вокруг сишных батареек почти полностью. Так что в сишке всё есть, но не используют. Как так?

таких как Nokia

Во-во. Хороший пример умершей компании (что-то там с вышками сотовой связи ещё у них теплится, но в целом оно уже умерло и из айтишки вышло, не удивлюсь если они теперь сами вышки строят из металлоконструкций, даже не антены с начинкой, которые у китайцев покупают). Как раз умерли когда питон пришел в прототипирование и Java на смартфонах стала работать т.к. смартфоны стали мощные и копейки на jvm перестали что-то значить, а они за сишку цеплялись.

ARM

Ну эти железячники и конкурентов у них совсем нет (не Дубна же конкурент ARM-у и не Байкал). Хотя и АРМ куртка скушала.

а буквы, по-твоему, это не байты? :) а что же это за сущность такая магическая?

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

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

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

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

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

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

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

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

Кстати, если ты хейтишь си, форсь хотябы Cyclone, а не руст. Так хотябы от лучей испражнений увернешься.

даже не знала про такой язык, хотя тоже древний, судя по всему. для меня Cyclone - это FPGA от Altera, с которыми мы много работали одно время на работе.

Как хорошо что я сишку осилил, но она для меня не священная корова, а всего лишь инструмент, один из многих.

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

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

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

ты опять попутал сущности. комп - это машина, он работает с байтами. а пользователь на компе - человек, он читает текст. именно для человека придумали printf и иже с ними. а внутри софта везде идёт работа с байтами.

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

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

Она написала стыдный говнокод. Если ты пишешь такой же стыдный говнокод, тебе стоит уволиться.

Посмотри на досуге, если не лень. Мне интересно мнение. Можно даже попробовать попедалить по друзьям-знакомым или на этом форуме. Язык вроде не плохой. Особенно мне нравится, что сохранили синтаксис, а не как в zig. Если будет что сказать, создай новую тему в development.

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

Он тонко намекает на то что любимая сишниками индексация по массиву со строками работает не очень. А как только появляются структуры данных, сишка начинает сосать за обе щеки, да ещё и причмокивать.

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

и зачем он нужен? чисто ради любопытства я его поковыряла. даже какую-то книжку прочитала. но на практике это не встречается.

просто прочитай более другую книжку, более практичную. например, «Practical Common Lisp» или ещё что-то более практичное.

Common Lisp, впрочем тоже монстр – спецификация на 1500+ страниц, эдакий С++ монстр из мира лиспа. с другой стороны, ISO ISLISP (например, реализация eisl от sasagawa888 — у него ещё есть пролог opl и пара книжек на японском про программирование микроконтроллеров на лиспе и прологе – я читал, мне понравились ) – спецификация где-то на 120..87 страниц, гораздо формально более строгая).

с третьей стороны, есть схема Scheme с ещё более компактной спецификацией, страниц 60 если R5RS и около сотни в R7RS (но это уже более перебор, имхо).

строки можно обрабатывать и на лиспе. например, вот таком как TXR

прелесть лиспа в том, что это структурированные выражения. например, разметка Skribe реализованная например в Racket, или Skribilo на Guile схеме. в общем-то видны преимущества лиспа для обработки документов – элементарно пишется reader или writer для конкретного поверхностного синтаксиса в абстрактный глубинный AST, который затем и обрабатывается.

например, макросами. если макросы на c препроцессоры это просто текст в текст, ну или можно сконструировать токен из частей текста – то это и всё что можно полезного сделать на таком препроцессоре.

макросы лиспа же – CTFE, вызов функций во время компиляции (например, в CL; есть и рантайм макросы но они не совсем так интересны).

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

сравни, например, реализацию ассемблера на c препроцессоре из Inferno: файл /usr/inferno/asm в старых версиях inferno, в новых в другом месте (надо искать 8a/6a/и тп. из kencc c plan9 toolchain) в новом репозитории Inferno-OS/Inferno-OS в районе tools tools или utils utils, например, вот ассемблер x86_64, вот ARM

и например, реализацию ассемблера на схеме (16-битного, для простоты): aasm 2 3 или наоборот или на ocaml OrHayat/scheme_compiler )

ещё например есть в LLVM : akeep/scheme-to-llvm или scheme2llvm. впрочем, если ты посмотришь внимательно на исходники gcc, например, а конкретно – на GCC MELT – то ты увидишь, что этот IR тоже лисп (в который можно макросами раскрываться). хотя из SSA тулчейнов более компактен QBE

вообще, в качестве компактного лиспа можно смотреть схемы: например, то что выдаёт Ian Piumatra: rabbit, COLA и т.п.

ещё в качестве применения. например, вот пакетный менеджер hermes : интро репо andrewchambers/hermes реализованный на лиспе janet-lang awesome-janet швабр

janet, на мой взгляд – наиболее понятная реализация идеи scsh (+lush, +common lisp однострочники от fare и т.п.) – шелла на лиспе.

вот репозиторий с пакетами для hermes: andrewchambers/hpkg и andrewchambers/hpkgs-seeds. (гы, забавно: у этого же автора есть вот такой ассемблер на PEG-парсере: andrewchambers/minias )

я как-то собирал его для void-а. вполне работает из коробки.

посмотри, например, как пишутся «ебилды» (ну по аналогии с xbps-src, например).

вот например, bash.janet :

там макросы всю дорогу – все эти defsrc, и отсюда base.janet – def gcc, defbase и т.п.

опять же, вот например macros writing macros: base.janet#L264 и prelude.janet#L27

вот такие макросы на сишном препроцессоре «текст в текст» тупо изобразить сходу не получится.

ещё в этом смысле можно смотреть дистрибутив Guix – там тоже на лиспе, сам пакетник из Nix-OS только не на своём хаскелеподобном языке, а те же монады реализованы на лиспе, Guile схеме.

вот например, 2-3 полезных применений лиспа, которые достаточно очевидны.

в качестве пакетного менеджера для сборки; в качестве шелла; для обработки текстов; для небольшой CMS.

ну и ещё емакс можно на нём написать, хотя мне классический гнутый емакс (то есть, емакс гослинга) – тоже не нравится. именно тем что там всю дорогу свой диалект: elisp который mocklisp а не настоящий ansi cl или eisl iso islisp или схема, например.

более модульный лисп.

кстати, если про islisp. то есть такой проприетарный как openlisp (пользоваться можно, но без исходников, они чёто там зело дорогие). от того же автора – есть более лучший емакс – EmAct который расширяется опенлиспом. опенлисп как и islisp в целом более интересен чем cl и чем elisp хотя бы тем, что 1) большинство конструкций реализовано макросами а не спецформами 2)он объектно-ориентированый (ILOS, в стиле CLOS и метаобъектного протокола) 3)более эффективно компилируемый и 4) в целом, более модульный и компактный.

то есть, EmAct в этом смысле более похож на подгрузку компилируемых DLL. а сам опенлисп подгружается там примерно как lua (смотри исходники emact, кстати очень компактные и аккуратные).

но это проприетарщина. из непроприетарщины есть iso islisp EISL от sasagawa, вместе с книжкой и блогом (на японском, разумеется). там тоже есть какой-то емакс, на самом eisl ISLISP-е и реализованный. например, tk без tcl подключается в полпинка и ещё есть что-то полезное.

ещё есть такой емакс как fe от moria.de.

он, во-первых, с фолдингом. во-вторых, реализован как библиотека на сишке – то есть, элементарно дёргается через FFI.

то есть, дёргать их можно через eisl либо через janet либо ещё какую-то встраиваемую схему, тот же rabbit от Ian Piumatra, например.

в этом смысле, вот примерно так должен выглядеть «более лучший емакс»:

1. компактное ядро как у emact, fe, qemacs

2. функции редактора реализованы в си библиотеке

3. которая дёргается из любого встраиваемого языка (например, «более лучшего лиспа», да)

во-первых, можно побороть костыли с асинхронностью моклиспового емакса гослинга. хотя там в гну емакс вроде уже и конпелируемые елисп модули добавили, кажется. и для асинхронности какую-то примочку прилепили (ввобще, есть ещё один емакс, на этот раз на ерланге или LFE – lisp flavoured erlang)

во-вторых, делать более компактные и понятные макросы. как в том же islisp или в janet или в схеме.

в-третьих, конечно беда-беда – все эти модули из ELPA нужно будет на этом «более правильном лиспе» под «более правильный емакс» – невозбранно переписать.

начиная с орг-моде, например – сделать нечто более skribe-подобное в смысле разметки.

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

впрочем, вот например в gnu skribilo на guile reader-ов можно несколько разных прикрутить. с любым синтаксическим сахаром, который захочется.

сравни, например, реализацию ассемблера на c препроцессоре из Inferno: файл /usr/inferno/asm в старых версиях inferno, в новых в другом месте (надо искать 8a/6a/и тп. из kencc c plan9 toolchain) в новом репозитории Inferno-OS/Inferno-OS в районе tools tools или utils utils, например, вот ассемблер x86_64, вот ARM

про ассемблер в инферно.

в старом это был каталог /usr/inferno/asm где были исходники ассемблера. в новом это например:

например, вот ассемблер x86_64 6a, x86_32 8a , вот ARM 5a, кажется, ещё вот 0a/l.s 0a/l.s похоже то ли на армовский, то ли на DIS толи ещё какой «кроссплатформный переносимый ассемблер»), по-моему это армовский или RISC-V)

зацени, как реализовано – lex/yacc и сишный препроцессор.

в старом инферно емним 20060303 это в /usr/inferno/asm лежало.

в общем, сишного препроцессора в целом достаточно чтобы на нём реализовать ассемблер.

но что-то более сложное уже не очень. в этом смысле macros writing macros на схеме – гораздо интереснее.

вообще, исходники Inferno и Plan9 на мой взгляд, следует посмотреть всем кто хочет узнать как сделать уникод простым способом, а без вот этого там libicu на 50 мегабайт.

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

где-то был текст про rationale почему так сделано. авторы plan9 изначального не реализовывали всю эту локаль и прочую ненужно локализацию – в духе GNU helloworld на 200 килобайт с 20 опциями (cat -v considered harmful, же ну)

а взяли тупо посмотрели вместо того чтобы сделать 8-bit free исходники ядра и утилит – просто написали utf8 строки utf2rune и rune2utf. то есть, все строки в utf8 внутри конвертируются в utf-16.

таких мест оказалось не много, и в результате тот же troff, например – спокойно получился utf-8 уникодным.

в общем, всем кто хочет программировать на сишке модульно, аккуратно – срочно читать #ifdef considered harfmul и смотреть на то как через mkfile собирается что инферно что сам девятый план.

очень компактные и аккуратные там исходники. не то что этот ваш линакс.

еще было бы интересно как-нибудь взять тот же troff или там neatroff под inferno на limbo портировать. чтобы например под винду запускать или под андроид.

инферно под андроид, кстати, тоже есть: bhgv/Inferno-OS_Android и собирается довольно просто, правда надо хотя бы NDK ставить если не всю толстую андроид студию.

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

и смартьфон внезапно становится чуть более полезен – можно например писать скрипты на rc или программировать на Limbo в acme (под андрюшку с экраннной клавиатурой, лол)

впрочем, деды вообще ассемблер на awk писали. там тоже не очень сложно. искать там же где и #ifdef considered harfmul, там правда под PIC-контроллеры какой-то ассемблер целевой, а вообще в книжке linkers and loaders он там всю дорогу свой линкер на перле пишет, невозбранно достигнув желаемого.

форматированный ввод в plan9 кстати, уникодный и там ещё что-то добавили, пару каких-то форматов.

но от «сраных процентов» никуда не делись.

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

мой выбор - это оптимизируемые высокопроизводительные компилируемые языки: Си, ассемблер. с некоторой натяжкой (и с определёнными ограничениями при написании кода) сюда можно вписать и плюсы. говорят, что неплохи Форт и Фортран, но я их не тыкала палочкой, из-за их малого распространения. но всякие интерпретируемые вещи меня не интересуют. и функциональщина тоже, потому что с моей точки зрения эти дикий изврат. это моя точка зрения. кто-то может иметь другую.

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

где-то это будет проще, где-то это будет какая-то лукап-таблица, но это всё одно и то же.

вот в той статье от авторов Plan9 там где-то они сокрушались что с лукап-таблицами в хрюникоде не всё так просто.

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

вообще, философия unix way: «делай что-то и делай его хорошо» – на мой взгляд, произошла из тулчейна troff для подготовки документации.

вот есть например обычный tty эмулятор терминала. который берет и в силу своей замороченности начинает интерпретировать байты.

и программа на сишке становится уже не интерпретатором printf-форматов, в рантайме вместо компайлтайма.

а например, интерпретатором/транслятором ANSI ESC-последовательностей, VT100 с наворотами вроде DEC Tetronix sixel и прочих картинок (хотя например в iTerm вроде проще свои Esc-коды для картинок добавили), и далее в большую глубину степени упоротости вплоть до 3270, 5100 блочных терминалов с формами.

далее вот например есть troff. который появился из runoff на ассемблере, awk и на сишке.

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

по сути, troff – это язык программирования документации. где есть переменные – числовые регистры, счётчики; строки; макросы типа строк или типа макросов пишуших макросы (всё в рантайме троффа как языка программирования).

и далее конвейер в духе юниксвейности: troff -mms -mpicture foobar.ms | tbl | pic | grap | bibindex | …. > foo.ps |page

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

а так – явная демонстрация юниксвейности, всего этого: «делай что-то одно, и делай его хорошо»

то есть: есть драйвер троффа, например, devutf в plan9 и neatroff.

и есть шрифты которые не зависят от драйвера. отдельно метрики, отдельно шрифты, сам troff ничего о них не знает, делает в универсальном виде (см. например mkneatrofffn как там новые шрифты и их метрики подключаются).

а между пайпами передаются команды интерпретатору трофф-языка в наиболее абстрактном виде. простые текстовые.

например, tbl или pic окружение. у него есть команда – начать, есть команда закончить. а далее сам tbl или pic тупо всё игнорирует что не между этими командами, опять же как препроцессор.

вообще, эта схема невозбранно расширяется.

например, можно посмотреть как сделаны мануалы в Plan9port: fqa1.ms fqa1.html fqa1.pdf

.\" troff -ms -mpictures fqa1.ms | page
.\" htmlroff -u -ms -mhtml fqa1.ms >fqa1.html

первое собирает постскрипт или pdf (в plan9 page это такой mupdf, картинки показывает или PS/PDF/djvu/….)

второе генерирует .html из манов.

в самих исходниках стоят, например, для картинок

.de FG  \" .FG <basename>
.ie h .html - <img src="\\$1.\\$2" />
.el .BP \\$1.ps
.br
..

то есть: либо окружение .BP для постскрипт картинок в целевой Ps/PDF

либо в HTML.

в общем-то можно подобное и лиспом генерировать, например.

там ещё проще получится – лисп это «программирумый язык программирования».

структурных выражений S-exprs -> well-formed forms.

то есть, простой и тупой конпелятор можно написать вообче на макросах лиспа.

ты кого-то другого процитировал. я про эти ваши инферны и планы9 вообще ничего не знаю и не интересовалась. это глюки ЛОРа, с ошибками авторства цитат.

вот в той статье от авторов Plan9 там где-то они сокрушались что с лукап-таблицами в хрюникоде не всё так просто.

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

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

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

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

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

я много раз пытался въехать в рефал, потыкал icon/unicon, лисп, снобол. а вот в рефал с марковскими процессами и его самобытным паттерн матчингом как-то сразу не въехал.

помогло когда в каком-то журнале «монитор» за 1992 год увидел более понятное описание.

ну вот типа есть поле зрения и есть поле памяти. далее то что видим паттерн матчим. в рефальские Р-выражения – обычные н-арные деревья а не двоичные бинарные car-cdr S-выражений лиспа. с термами, возможно пустыми и атомами разных типов (символ-символ, символ-литера, символ-макроцифра, символ-метка и проч.)

затем если матчим – функцию соответствующую выполняем (синтаксис рефала чем-то CSS напоминает, кстати)

если совпало – удаляем из поля зрения и оставляем то что функция вернула. если не совпало – перебираем следующее правило.

это как-то напоминает сколхозенные на коленке парсер-комбинаторы хаскеля и вот ту статью про последовательность успехов или неуспехов. а может, и генераторы ковыражений из icon/unicon и его лямбды с генераторами (например, в тулчейне не троффа, а noweb на icon ковыражения довольно понятно написаны)

но на своей самобытной императивно-функциональной рефал-машине.

вообще, обработку строк в этом смысле проще писать на icon/unicon или даже на сноболе.

на сноболе вообще получается тупо конечный автомат, в котором всё явно прописывается. при этом у него есть нормальные ADT, типы, метаинформация, и батарейки. и FFI для сишки.

ассемблер на сноболе кажется тоже был в какой-то книжке типа «icon для гуманитариев» (там еще был парсер атрибутивных грамматик ANN для естественного языка, тоже как конечный автомат для своей грамматики)

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

это точка зрения однозадачного мозга, а мозг иногда работает и асинхронно.

я собираю софт из сорцов.

я тоже собираю из сорцов, и тоже под void. под hermes и janet.

вполне себе интересно так собирается, musl. еще кроссборку под Mingw написал, например. так что там более наглядно и понятно.

guix опять же, хотя они там с иммутабельностью конфигов имхо намудрили в nixos вообще и немного в guix тоже. в hermes/janet в hpkgs в этом смысле более понятно и предсказуемо всё собирается.

хотя и там и там – вызываем тот же баш из лисповых ебилдов и в целом делаем что угодно.

лисп есть, а софта нет.

ну можно например взять отладчик/эмулятор blinkenlight и лампочками помигать. и лисп из бутсектора в отладчике поковырять: justine.lol/sectorlisp2/

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

но если например взять более лучший лисп типа той же схемы. то можно написать на ней ассемблер, сишку (на лиспе, в духе ZetaC из лисп-машин Genera) и всё остальное.

опять же, GCC MELT например это по сути тоже лисп. то есть, можно довольно просто наколхозить простой конпелятор макросами в SSA представление.

говорят, что неплохи Форт и Фортран,

форт

тут можно смотреть sectorforth, jonesfort.S и читать Лео Броуди «Thinking Forth» до полного просветления. он там зачем-то структурное программирование и SADT процесс на форте объясняет.

и Фортран,

..настоящие программисты не используют паскаль! всё пишут руками на фортране (неструктурированном, с вычисляемым GOTO и отрицательными индексами в массивах, лол) – не то что эти новомодные хипстерские quiche eaters

:))

и программа на сишке становится уже не интерпретатором printf-форматов, в рантайме вместо компайлтайма.

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

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

в качестве пакетного менеджера для сборки; в качестве шелла; для обработки текстов; для небольшой CMS.

вот нет! я с пакетным менеджером много работаю. я его правлю под свои требования. мне там не нужны всякие экзотические и малораспространённые ЯП.

а для работы с текстом и так туева хуча утилит. правда, я практически не работаю с текстом и особо не вникала в это многообразие. мне хватает perl -pe, grep и awk, иногда sed. эти утилиты покрывают весь спектр моих потребностей при работе с текстовыми файлами. крайне редко нужно поменять кодировку в каком-нибудь файле (у меня везде UTF-8). и для этого тоже есть утилька, даже не помню навскидку её название, потому что крайне редко нужна. и всё, больше с текстом я ничего не делаю.