Rust и двусвязный список

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

лавров.jpg

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

Не совсем понятно, почему для этого нужно воображать лисп-машину.

Я чот не догнал иронии, слишком ленив.
Вообще мне малость любопытно, каких битовых операций не хватает aist1. В смысле, а чего еще такого еще можно делать с битами, чего мы до сих пор не сделали?

Нельзя воображать, это у меня вырвалось… Ты видел, какая там картинка страшная ?

Раст сковывает силы древнего зла и парализует их. Даёшь Раст!

Ну вот, например, https://graphics.stanford.edu/~seander/bithacks.html

Кроме того, нужны такие же операции как rank и select, но не только для битов, а для символьных последовательностей со словарем 1-8 бит. И не для 64-битных слов, я для 256-512-битных блоков. Нужна прямая поддержка сжатых символьных последовательностей.

Вот пример того, как обобщенное дерево можно упаковать в массив: LOUDS с помощью битовых карт с поддержкой rank/select.

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

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

Вот выкинешь ты несколько очевидных кривостей - поломаешь, допустим, 1% кода.

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

UB в целых исправляется просто ключами компилятора. Это вообще не проблема языка, как такового.

Есть и существенно другие варианты (кроме ключей).

Мой пойнт в несогласии с тезисом «невозможно исправить с++», и я его начал обосновывать максимально просто.

Это вообще не проблема языка, как такового.

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

Не совсем понятно, почему для этого нужно воображать лисп-машину.

Чтобы заплакать. Ваш К.О.

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

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

Это несущественно, можно и на лиспе такое сделать.

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

Но ты не отвел на мой вопрос: вот у нас есть образ лисп-машины Васи. Петя хочет убрать из него то, что ему не нравится (например reader macro — и может еще что-то, я не на столько знаю лисп, чтобы спросить все что я хочу) и продолжить с ним Васину работу. Это реально?

Развитие С++ сильно сдерживается императивом совместимости с существующей кодовой базой.

собственно основная идея resyntaxing в сохранении совместимости с существующей кодовой базой С++, но не сохранении совместимости с текущим синтаксисом С++

и предлагаю язык-компаньон, в котором можно было бы полечить болячки С++,

да

чтобы не конкурировать с С++ за ниши.

нет уж, за лоулевел вполне можно поконкурировать и с успехом

Я уже наплакался до полного истощения сил

Я не будут рассказывать тут все причины почему ты зря плачешь. Но вот тебе одна: не всем по жизни положено думать — кому-то надо и таски в джире закрывать, а не изучать там лиспы всякие. Впрочем, через 10-20 лет может и они начнут немного думать... хотя бы на тему, что им не хватает.

нет уж, за лоулевел вполне можно поконкурировать и с успехом

Можно, но пока не нужно. Нужно посмотреть, как появление языка-компаньона скажется на развитии самого С++. Может быть, они «выдохнут» и сфокусируются на реальных проблемах, не отвлекаясь на давлеющую над ними «высокоуровщину».

Образ может быть живой, тогда Вася и Петя могут к нему подключиться через две сессии swank и плевать друг другу в суп. Если же образ в виде файла (результат какого-нибудь save-lisp-and-die), то Петя может его восстановить у себя, убрать reader macro и продолжить работу. Правда, при этом, результат чтения, достигнутый с этим reader macro, никуда не денется. Т.е. система может перестать быть постижимой умом, да и вообще сломать её можно. Примерно так же, как можно в линуксе удалить bash. Поэтому желательно иметь скрипт, который накатывает образ с нуля. Примерно то же самое происходит в sql со скриптом начального развёртывания и с последующими миграциями.

Трудно сказать. Высокоуровщина-то в плюсах по-моему неплохая зачастую. Хотя с другой стороны многое надо совсем по-другому делать.

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

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

Неплохая, если говорить про zero-cost abstractions, сам знаю. Но можно и сильно лучше. Я тебе говорил уже, что clang в целом движется в направлении превращения в полноценную дата-платформу для С++, и clangd — это просто маленькая вершинка большого айсберга возможностей, которые при этом открываются и для языка, и для самой платформы. Широкая автоматизация изменит саму парадигму применения языка, а применение (прагматика) потянет за собой и понимание того, каким должен быть язык, чтобы в эту парадигму органично вписываться. Пока что С++ пытается усидеть на двух стульях сразу: и догнать современные (в значительной степени уже высокоуровневые) языки, и сохранить свою базовую парадигму close-to-metal zero cost abstractions. Противоречивые цели, мягко скажем.

Противоречивые цели, мягко скажем.

Цели вполне совместимые по моему мнению, хотя у с++ это получается действительно не очень.

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

Ну да, конечно. «Дурацкое название» - и всё, недостаток найден. Закапываем, язык плохой.

Вот, к примеру, go — название такое, что не гуглится. Закапывать рано, но оценку снижаем на 20%.

Отсутствуют дженерики — оценку снижаем в 3...4 раза.

Дженериков для программистов нет, но для себя, любимого, есть (щас не вспомню — то ли каналы дженеричные, то ли map дженеричный поддерживается компилятором) — значит неуважение к квалифицированным программистам, оценку языка снижаем еще в 2...3 раза.

одинаково плохо поддерживает все свои парадигмы

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

В близкой парадигме, кстати, находится Julia — язык-надстройка над динамическим AOT-компилятором (LLVM JIT).

Я эстет, если что. Правда ради реальной реализации иногда и готов поступиться принципами... но на время, не навсегда.

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

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

И исходя из этого хотелось бы еще и эстетичный язык для машинного кода. Правда llvm выглядит вполне прилично, но может и в нем чего-то не хватает для чтения ЧЕЛОВЕКОМ?

но может и в нем чего-то не хватает для чтения ЧЕЛОВЕКОМ?

MLIR ихний пробовал? Вполне годная вещь для постепенного понижения уровня абстракции.

ващще первый раз слышу, побегу смотреть (я тут спал 5-7 лет глубоким сном, если че)

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

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

дженерики уже добавили, гуглить можно golang.

гуглить можно golang

поэтому минус 20%, а не минус 99%

дженерики уже добавили

ага, после того, как пользователи наколбасили как минимум одну (внешнюю по отношению к го) систему генерации исходников под замену дженерикам

ну и отношение автора к программистам (а значит и мое отношение к автору) это не меняет

На самом деле смысл в отсутствии дженериков есть. Когда я делал Яр, я хотел сделать кастовое общество. На верхнем уровне более-менее убогий Яр, на нижнем - всемогущий лисп. Когда появился го, я подумал, что и с ним эта фишка прокатывает. Только не совсем так. На верхнем уровне будет лисп, а под ним, вместо машинного кода - Го. Соответственно, революция в кастовом обществе. Т.е. общество будет трёхэтажным. Сначала идёт этаж го, над ним - лисп, а уже над ним - Яр (DSL-и).

В Яве это уже проделано в виде каких-нибудь clojure и scala, только нижний этаж непомерно раздут и вообще уродливый. Го гораздо лучше подходит.

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

я не усматриваю в этом глупости — внутри транзакции таблица будет видна старая, снаружи — новая

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

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

В итоге кончилось тем, что зло от компьютеров мешает мне творить. Я потихоньку творю Оберон на место го (Оберон лучше, естественно), а вот этаж для всемогущих, видимо, надо вообще нахер послать. Люди тут по этике ещё на сержанта не тянут, куда им крылья? Будут летать и на голову гадить. Ну и вообще, языки программирования должны быть отвратительны, ИТ-шники должны страдать.

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

а вот грабли да, могут быть, если таблица меняется уж очень нелокально

Для сведения, в том же CLOS легко докопаться до неприятности: добавляем поле в класс, и даём ему значение по умолчанию. Удаляем поле. Добавляем его снова, но с другим значением по умолчанию. Аминь.

с таким отношением мир не захватить, знаешь ли

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

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

хорошая грабля, запомню

Не надо думать, что весь мир исчерывается ИТ-шниками. Нас не набирается и жалких 20 миллионов (плюс-минус). На фоне страданий людей, у которых машины постепенно отбирают всё, что у них есть, мы не страдаем вовсе.

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

На фоне страданий людей

у кого-то суп жидкий, у кого-то жемчуг мелкий, а у кого-то интерфейс неконсистентный и дженериков нет совсем — что крайне раздражает

вот так и живем

Можно также фантазировать на тему удаления/добавления одноимённой таблице в твоём мифическом версионнике без синхронных метаданных.

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

Страдания людей в развитых странах проходят по трем основным статьям: «плохое здоровье», «нечего делать» и «завышенные/нереалистичные ожидания». В США еще добавляются массовые шутинги, самострел и бодания с health insurance.

Ну вот не надо про развитые страны, это танцпол уже.

Я к тому, что страдания айтишников проходят по графе «завышенные ожидания» и «самострел».

Вовсе не так плоско; вот может быть например как у Печорина («Герой нашего времени» Лермонтова): Печорин сил чувствует дохрена, а куда их девать — ему не ясно, так как в компилятор не завезли метафункций, метаклассов, аспектов, или еще чего-нибудь в том же духе.

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

Это все смешарики, но к ЯП имеет прямое отношение. Излишний идеализм в ожиданиях от языка приводит только к хронической неудовлетворенности. Если ЯП рассматривать как инструмент добывания пропитания (решения задач), то проблемантика его дизайна меняется кардинально.

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

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

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

Апдейт: и тут даже не важно, что код компилятора открыт. И даже в принципе можно сделать closed source компилятор, который в этом аспекте будет лучше open source компилятора. Это конечно не означает, что так надо делать и так реально получится сделать — речь только о принципиальной возможности такой странной ситуации.