LINUX.ORG.RU

Lisp: Где применимы cons?

 cons,


1

6

Для начала небольшой «бенчмарк», С без всех оптимизаций в 7406000 раз быстрее.

(defun main ()
  (declare (optimize (speed 3)))
  (let ((n 99999) (l '()) (sum 0))
    (loop for i from 0 to n
	  do (setq l (append l (list i))))
    (setq sum 0)
    (loop for i from 0 to n
	  do (setq sum (+ sum (nth i l))))
    (format t "~d~%" sum)))
#include <stdlib.h>
#include <stdio.h>

int main(int argc, char **argv)
{
	long n = 99999, *l = NULL, count = 0, sum = 0;
	for (long i = 0; i <= n; i++) {
		l = realloc(l, (count + 1) * sizeof(long)); 
		l[count++] = i;
	}
	for (long i = n; i >= 0; i--) sum += l[i];
	printf("%ld\n", sum);
}

Для чего же нужны cons? В качестве универсального строительного блока, я считаю это одна из самых худших структур. Все ее преимущества заканчиваются на быстром добавлении в начало. Добавление в конец уже нежелательно, разрез в произвольном месте тоже, так как нету даже быстрого доступа к случайному элементу. Она медленная и неудобная, можно придумать кучу более быстрых и удобных структур. Даже JS на световые годы опережает Lisp со своим JSON, и его частое использование лишь подтверждает его удобство.

Так почему же cons из языка-ассемблера IPL 1956 года считается важным? Да, это неплохая структура для AST, если ваша машина имеет 16 кб памяти, но она распространилась по языку слишком широко.

★★★★★

Последнее исправление: MOPKOBKA (всего исправлений: 3)
Ответ на: комментарий от qulinxao3

литературно-грамотный метапрог

  • подразумевал что в зиге есть нечто что выглядит как часть сырца в том же синтаксисе и обладает «imediate» свойством сделать некоторое преобразование предкомпилируемое - (привычное в виде препроцессинга сырца - но это(препроцессинг обычно как трасформация текста по некоторым постороним(к языку программирования) правилам позволяющим отделять препроцессорные директивы от основного потока токенов :)

вот в форте такое невозбранно делается через CREATE ... DOES> ... слова или вот например, нашел любопытный код через Recognizers:

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

https://theforth.net/package/recognizers/current-view/literacy.4th

https://theforth.net/package/recognizers/current-view/README.md

literacy.4th

Simple formatting of source code in the spirit von Don Knuth’ literate programming. You can combine the real source code and its documentation in one file that the standard forth interpreter can handle directly.

Actually testing this recognizer requires a Forth that supports recognizers already.

Author: Julian Fondren, 2014 License: probably public domain.

https://amforth.sourceforge.net/Recognizers.html

https://amforth.sourceforge.net/TG/Architecture.html

https://amforth.sourceforge.net/TG/Architecture.html#recognizer

https://amforth.sourceforge.net/TG/Compiler.html

про реализацию if,else,then,(0branch),(branch)

https://wiki.forth-ev.de/doku.php/projects:english_as_a_second_language_for_forth_programmers

https://sourceforge.net/p/amforth/code/HEAD/tree/trunk/examples/literacy.frt

anonymous
()
Ответ на: комментарий от anonymous

tl;dr: !ъ-mode:

AmForth – компактный форт для AVR/ARM/ит.п микроконтроллеров, который можно дергать через REPL через serial порт.

код про Recognizers пакет похоже оттуда (судя по последней ссылке из SVN amforth)

код написан как набор парсеров с тестами, где наподобие CommonLisp-овых READER macro делается аналогичное через immediate/CREATE…DOES>… подобные слова, чем-то напоминая этот пример, по структуре – только на форте а не на лиспе.

форт вроде бы идеоматичный, но для amforth полезно прочитать ссылку https://amforth.sourceforge.net/TG/Architecture.html#recognizer про то как там устроен интерпретатор с расширениями, и еще на wiki.forth-ev.de где-то был пример про модификацию интерпретатора для упрощения написания парсера; и еще код про FSM через CREATE … DOES> … слова.

там на wiki.forth-ev.de кстати, выпуски журнала 4th dimension про форт, еще какой-то забавный код с примерами есть, исходники к журналу. в основном, на немецком.

а тут пишут что форт это почти естественный язык уточняя как: https://wiki.forth-ev.de/doku.php/projects:english_as_a_second_language_for_forth_programmers

еще про метакомпиляторы форта тоже интересное.

вообще, про литературно-грамотное:

https://sourceforge.net/p/amforth/code/HEAD/tree/trunk/examples/literacy.frt

https://theforth.net/package/recognizers/current-view/literacy.4th

это такой юпитероутбуковый REPL на парсере форта :)

вообще, был какой-то еще форт, кажется Retro или ngaro с VM – в котором исходники были написаны в литературно-грамотном стиле.

по идее, с этого и надо было начинать:

  • написать не только простой org-mode C-c C-c «выполнитель» перекрытием парсера как в literacy.frt, но и

  • более похожий на org-mode babel M-x org-babel-tangle ну или классический weave/tangle утилиты Д. Кнута — только на форте

  • писать требования и реализацию и тесты в литературно-грамотном стиле

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

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

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

минимальное подмножество RTF довольно простое.

то есть: на форте писать генерацию RTF-объектов, PostScript-объектов, и т.п.

или тупо взять обычный RichEdit контрол для RTF и его наполнение генерировать фортом.

anonymous
()
Ответ на: комментарий от qulinxao3

там кстати ссылка про журналы и про исторические документы – про историю форта интервью с Чарльзом Муром с примерами ранних версий форта на алголе, коболе, PL/I и фортране.

по идее надо бы взять W-грамматики ван Вейнгаардена (на которых синтаксис Алгол 68 еще) с двухэтажным синтаксисом правил, гиперправил и метаправил. довольно мощный формализм – сам Вейнгаарден потом написал книжку про это, клеточные автоматы и что-то вроде игры Жизнь на одних только грамматиках :)

и на них описать парсер литературно-грамотного программирования.

с трансляцией сразу в реализацию на конечных автоматах (FSM) или сразу в форт.

чтобы эти Recognizers/parsing words как-то более универсально задавать.

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

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

Finally, a really neat way to write keyword-driven translators.

anonymous
()
Ответ на: комментарий от anonymous

FORTH is a polarizing concept. There are people who love it and people who hate it. It’s just like religion and politics. If you want to start an argument, say, „Boy, FORTH’s really a great language.“

This is partly because FORTH is an amplifier. A good programmer can do a fantastic job with FORTH; a bad programmer can do a disastrous job.

It is quite apparent, but difficult to explain, why or how a FORTH program is bad.

BASIC and FORTRAN are less sensitive to the quality of the programmer. I was a good FORTRAN programmer; I thought that I was doing the best job possible with FORTRAN, but it was not much better than what everybody else was doing. In this sense, FORTH is an elitist language.

вот, он всю суть – заранее уловил!! еще тогда! только сейчас BASIC ^W Python и FORTRAN ^W C++ – это модные и молодежные в которые сумел отмасштабировать бизнес, а в остальном – ничего не меняется.

On the other hand, I think that FORTH is a language that a grade school child can learn to use quite effectively, if it is presented in bite-size pieces with the proper motivation.

FORTH is the first language that has come up from the grass roots. It is the first language that has been honed against the rock of experience before being standardized. I hesitate to say it is perfect; I will say that if you take anything away from FORTH, it is not FORTH any longer—the basic components are all essential to the viability of the language.

anonymous
()
Ответ на: комментарий от anonymous

вот, он всю суть – заранее уловил!! еще тогда! только сейчас BASIC ^W Python и FORTRAN ^W C++ – это модные и молодежные в которые сумел отмасштабировать бизнес, а в остальном – ничего не меняется

Тогда если кто-то напишет компилятор форта уровня SBCL, то есть шанс и форт возродить.

monk ★★★★★
()
Ответ на: комментарий от monk

Тогда если кто-то напишет компилятор форта уровня SBCL, то есть шанс и форт возродить.

Написание SBCL никак не изменила ситуацию с лиспом. :)

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

BRE ★★
()
Последнее исправление: BRE (всего исправлений: 1)
Ответ на: комментарий от MOPKOBKA

Ну значит это зацикленные списки а не бесконечные, на них твоя функция вылетает

Проверки не делалось.

Тогда так

(defun my-length (list)
  (labels ((recurse (list result seen)
             (cond
               ((null list) result)
               ((gethash list seen) (error "It is not a proper list"))
               (t 
                 (setf (gethash list seen) t)
                 (recurse (cdr list) (1+ result) seen)))))
    (recurse list 0 (make-hash-table :test 'eq))))
monk ★★★★★
()
Последнее исправление: monk (всего исправлений: 1)
Ответ на: комментарий от BRE

Написание SBCL никак не изменила ситуацию с лиспом. :)

Очень изменило. Точнее не SBCL, а изначально CMUCL. Пока был только clisp, ничего открытого кроме скриптов на лиспе не писали. Потому что тормозило очень. Сейчас на quicklisp библиотеки есть почти для всего.

есть несколько ссылок на коммерческие форты уровня sbcl

Allegro CL тоже всегда был. Но так как дорогой и коммерческий, то и писали на нём дорогое и коммерческое.

Я думаю он навсегда останется нишевым языком и языком для фанатов, как и лисп.

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

monk ★★★★★
()
Ответ на: комментарий от monk

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

Можно писать, но пока эти программы пишут на C|C++?

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

BRE ★★
()
Ответ на: комментарий от BRE

Можно писать, но пока эти программы пишут на C|C++?

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

Сейчас эти программы пишут на Java и C#. Теперь ещё и Go, наверное. Потому что за этими языками стоят корпорации. И эти языки как раз обеспечивают достаточно высокий уровень производительности совместно с достаточно эффективной изоляцией модулей, чтобы криворукий молодой программист не обрушил всю программу.

поэтому продакшену проще найти среднего сишника или плюсовика.

Много знаете проектов на Си, начатых после 2010 года?

monk ★★★★★
()
Ответ на: комментарий от monk

Много знаете проектов на Си, начатых после 2010 года?

Современные коммерческие проекты могут состоять из многих программ, которые могут быть написаны на разных языках. Поэтому я бы так не считал.

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

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

BRE ★★
()
Ответ на: комментарий от anonymous

У CoSy Forth сам Forth код автор пишет в стиле дневника какого то, похоже на литературный стиль. Возможно его привычка восходит к блокнотам APL, если там такое было.

MOPKOBKA ★★★★★
() автор топика
Ответ на: комментарий от MOPKOBKA

в духе sectorlisp, минималистичный sectorforth и еще более минималистичный milliForth

в DuskOS которая на форте есть компилятор (почти)С – на форте.
еще есть CollapseOS в браузере

оберон там впрочем, тоже есть — впрочем, как и лиспъ

а вообще из минималистичного нужно что-то типа uxnuxn_guide (? или uxntal оттуда ? unxtal.macros? uxn_tutorial awesome-uxn ) или varvara или тут

вообще, нужен какой-то минималистичный форт:

Minimal Forth Architectures In The Road Towards A Minimal Forth Architecture, Mikael Patel builds toward a forth from only a handful of arithmetic and stack primitives. Here is an implementation of some of these primitives in Uxntal macros.

только на обычном форте.

простой и понятный лисп на алгол68genie: en.algol-68-genie.lisp-interpreter.a68
Algol68G – интерпретатор/конпелятор, Algol68C – конпелятор Algol68.

вообще, надо как-то пересобрать GCC 15.1+ с алголоподобными: Algol68, Modula2, Ada.
GNU Pascal похоже сдох уже лет 20 – последняя версия была под gcc 3.45/4.1

по воспоминаниям об «истории форта» Чарльза Мура – есть примеры исходников реализаций на алгол68/PL1/кобол/ит.п., правда только куски без подробностей.

я так думаю, что правильно было бы взять например реализацию TeX на gpc/fpc (есть патчи на CTAN), и собрать ей мини тех (ну или взять TinyTex но это неспортивно); потом брать этим минитехом собирать weave.web/tangle.web -> паскалевские реализации weave/tangle; потом взять для спортивного интереса их переписать на Algol68/Modula2/Ada в новом GCC.

после чего на этом миниалголе раскрутить простой мини лисп или мини форт, и переписать weave.web/tangle.web уже на это форте (или лиспе).

в milliforth вообще абсолютный минимум примитивов, даже ." делают руками через parse и [char] immediate-слова.
далее можно расширять reader macro парсер форта как в примере с recognizers – или в другой статье про измененный интерпретатор.
сделать например, utf-8 прозрачное чтобы weave.web/tangle.web переписать с паскаля на форт через recognizers/настраиваемый парсер.
потом взять какой-то текстовый редактор с раскраской (на форте, например: mcForth или duskos-ed.txt и сделать из него REPL-запускалку типа org-mode C-c C-c в Emacs.

anonymous
()
Ответ на: комментарий от anonymous

вообще, во-первых можно взять Dosbox и досовские форты (или uxn/varvara/DuskOS/CollapseOS).

во-вторых, собственно без нихто еще даже проще и интереснее: например, sectorforth/milliforth запускается через qemu-386, а образ делается очень просто в makefile.

в-третьих, нужно туда в такой минималистичный форт «на самом себе» запилить минималистичный weave/tangle utf-8 совместимый или для начала 8-bit free.

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

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

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

в-пятых, взять в духе досовского паскаля отрисовывать что-то: диагармы (ц), жгутики, проводочки…

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

методологию метапрог-моделирования. ДРАКОН-схемы для начала изобразить, что ли.

в-шестых, взять и написать уже метапрог на всем этом вот.

минималистично на самом себе.

anonymous
()
Ответ на: комментарий от anonymous

mcForth.EdWin

вот эта штука, например – поддерживает раскраску форта и markdown исходников.

осталось добавить туда две/три вещи:

  1. weave/tangle (на форте)

  2. markdown раскраску двигать в сторону *.web раскраски и ее возможностей

  3. сделать пару кнопок на видном месте для viewPDF/weave/tangle/run/compile/test.

anonymous
()
Ответ на: комментарий от anonymous

Какой то адовый план по построению форта на мертвых компиляторах.

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

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

в milliforth вообще абсолютный минимум примитивов, даже ." делают руками через parse и [char] immediate-слова.

Логично, наоборот должна быть причина что бы НЕ использовать уже определенные слова. Я правда не знаю зачем так усложнять слово (."), у меня это просто два вызова слов " (определение строки) и type (вывод строки).

Компилятор изначально был написан так, что бы побыстрее настроить стек и среду (~100 строк), а потом уже все подпрограммы пишутся сразу в словарь на ассемблере, и по сути все вызываемые функции это уже и так слова.

в-пятых, взять в духе досовского паскаля отрисовывать что-то: диагармы (ц), жгутики, проводочки…

Так как мой Forth не использует libc, что бы не ввязываться в C Runtime который будет ограничивать мои идеи, то я думал над графикой без X11, очень простой вариант под Linux, это fbdev. И никакие DOS с паскалями нинужны.

методологию метапрог-моделирования. ДРАКОН-схемы для начала изобразить, что ли.

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

  1   2   3
  |   |   |
  |   |  drop
  |   |
  |  dup
  |   |
  |   +---+
  |   |   |
  |   2   2
  |   |   |
  .   .   . 
Цвет провода обозначает тип стека, их как минимум 3 должно быть, возвраты, данные, матетматический.

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

markdown раскраску двигать в сторону *.web раскраски и ее возможностей

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

MOPKOBKA ★★★★★
() автор топика
Последнее исправление: MOPKOBKA (всего исправлений: 4)
Ответ на: комментарий от MOPKOBKA

Так как мой Forth не использует libc, что бы не ввязываться в C Runtime который будет ограничивать мои идеи, то я думал над графикой без X11, очень простой вариант под Linux, это fbdev. И никакие DOS с паскалями нинужны.

и никакие Linux тоже не нужны – это лишний оверхед.

makefile

=> просто делается qemu образ sector.bin, в котором и запускается sector.asm

–> обычный 16/32 битный ассемблер реального режима с int 16, int 10 – из BIOS.

далее аналогично пишем в 0xB8000 текстовый или в линейный фреймбуфер графический : [osdev.wiki/wiki/Drawing_In_a_Linear_Framebuffer] (https://osdev.wiki/wiki/Drawing_In_a_Linear_Framebuffer) установив VBE режим, и вперед.

ну или старые VGA режимы и пишем в буфер с 0xA0000.

сложности начнутся если в защищенный режим или в 64-битность и например UEFI играться, но тоже относительно небольшие.

anonymous
()
Ответ на: комментарий от anonymous

вот в UEFI рисовать немного сложнее чем в VESA, но именно что не намного.

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

там если играться в защищенный режим 32-битный или сразу 64-битный возможны заморочки, но тоже не очень большие.

anonymous
()
Ответ на: комментарий от anonymous

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

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

Но какой нибудь драйвер USB3 будет довольно сложным, сравнимым с самой Forth-средой. Раньше было проще, у Чарльза Мура есть код его драйвера диска, там пару строк буквально.

Вообще минимальный Linux это теперь новый BIOS я считаю, UEFI до ужаса стал большой, нету смысла пытаться остаться на нем. Либо не заниматься ерундой и использовать Linux API как BIOS, либо сразу делать свою UEFI прошивку, Чарльз Мур кстати так и делал, говорил что ему не понравилось как долго загружается BIOS что бы моментально вгрузить его ОС.

MOPKOBKA ★★★★★
() автор топика
Последнее исправление: MOPKOBKA (всего исправлений: 5)
Ответ на: комментарий от MOPKOBKA

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

алгоритм литературно-грамотный самый простой это например zyedidia/Literate сайт на D – где именно это с markdown разметкой и происходит.

но вообще-то это неполноценное: нету нормальных индексов в weave, макросов типа @d (define)в tangle изначальном, возможно что-то можно изобразить плагинами или pandoc, но это такое…

хотя там довольно простые наглядные исходники на D2, опять же, какие-то плагины можно накостылить по быстрому

и по идее, вообще-то нужен более полноценный с weave с индексами и tangle с топологической сортировкой.

или вообще что-то менее tex-подобное.

например, вот Slit2 под Lout.

тот генерирует нормальный PostScript из которого можно сделать PDF (хотя, с кириллическими буквами нужно разбираться с Type1 PostScript шрифтами или понаделать из уникодных Type42), шрифты нужно встраивать (embed)

итоговый weaved PDF получается довольно симпатичный – с правильными индексами, оглавлением, pretty printing-ом…

хотя проще всего наверное взять noweb и XeTeX с обычными true type – проще всего и менее замороченно, но это значит TeX, TinyTex минималистичный или Texlive еще более толстый

а в weave.web/tangle.web – изначальный на паскале.

там наиболее полноценная функциональность: индексы, идентификаторы как ссылки, pretty printing в tangle; макросы @d и т.п.; change-файлы; tangle с нормальной статистикой.

в общем, если делать нормальный литературно-грамотный weave/tangle – нужно брать изначальный кнутовский и переписывать его на aлгол68 или аду или модулу2 в новомодном gcc 15 – на форт, разумеется, но лучше не сразу именно руками, а например взять какой-то Libero и расписать как парсер на конечных автоматах, подо все, в том числе и форт в первую очередь.

чтобы сохранить всю функциональность полноценного weave/tangle, и даже добавить что-то (например, напрашивается условная компиляция и сборка вариантами, то есть далее расширять макроязык метаязыка литературного программирвания, @d макросы литпрога изначального в метарог более полноценный)

anonymous
()
Ответ на: комментарий от MOPKOBKA

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

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

но оно же по идее может быть и с именоваными кодоблоками, и в нескольких файлах.

так что там все-таки придется полноценный tangle наподобие org-mode M-x org-babel-tangle для конпеляции кодоблоков в нужные файлы и конпелируемые подфункции подсистемы с пакетами, делать а не только лишь C-c C-c для интертрепации и непосредственного выполнения анонимных кодоблоков.

anonymous
()
Ответ на: комментарий от monk

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

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

MOPKOBKA ★★★★★
() автор топика
Ответ на: комментарий от MOPKOBKA

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

Желания поискать или сделать отладчик в нëм уже очень давно не возникало.

monk ★★★★★
()
Ответ на: комментарий от monk

А как идеологически решается проблема со сторонним кодом? И еще вопрос, как живут лисперы в Emacs, если их программа вылетает, ну к примеру из за segfault или из за бесконечной рекурсии, у меня умирает процесс что у racket, что у sbcl, образ теряется, начинай заново, выглядит очень неудобно, его еще надо заново стартовать, это как если бы Visual Studio вылетала каждый раз когда в твоей программе обращении к NULL.

MOPKOBKA ★★★★★
() автор топика
Ответ на: комментарий от monk

А как заставить car работать для defstruct? Я ожидал что оно будет интерпретировано в порядке полей как список значений.

Вообще странно что оно по умолчанию так не выглядит, в том же JS объекты классов ведут себя как обычные объекты созданные через {}.

>>> class Point { constructor() {this.x = 100; this.y = 200;} }
>>> const p = new Point()
>>> Object.keys(p)
[ 'x', 'y' ]
>>> p['x']
100
MOPKOBKA ★★★★★
() автор топика
Последнее исправление: MOPKOBKA (всего исправлений: 1)
Ответ на: комментарий от MOPKOBKA

А как идеологически решается проблема со сторонним кодом?

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

И еще вопрос, как живут лисперы в Emacs, если их программа вылетает, ну к примеру из за segfault или из за бесконечной рекурсии, у меня умирает процесс что у racket, что у sbcl, образ теряется, начинай заново, выглядит очень неудобно

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

или из за бесконечной рекурсии

Так её же прервать можно. Ctrl-C.

к примеру из за segfault

Но как? Без FFI или safety 0 в SBCL это вроде невозможно.

это как если бы Visual Studio вылетала каждый раз когда в твоей программе обращении к NULL.

У тебя же не Emacs падает, а выполняемая программа. И в Visual Studio выполняемая программа при обращении к NULL также падает.

monk ★★★★★
()
Ответ на: комментарий от MOPKOBKA

А как заставить car работать для defstruct? Я ожидал что оно будет интерпретировано в порядке полей как список значений.

(defstruct (point (:type list)) x y)
(car (make-point :x 100 :y 200)) ; = 100

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

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

в том же JS объекты классов ведут себя как обычные объекты созданные через {}

Понятие классов в JS появилось недавно. И было бы странно, если бы разработчики решили, что обычные объекты и объекты классов должны быть несовместимы.

monk ★★★★★
()
Ответ на: комментарий от MOPKOBKA

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

Если уж заниматься бесполезной академической деятельностью

то это цитата оттуда, из статьи которую лучше читать целиком:

Программиста бьют по рукам, если он посмеет написать оператор цикла, не найдя перед этим его инварианта.

Предварительные соображения о лексиконе программирования

Академик А.П. Ершов, 1983 г.

тыц:

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

Все наши рассуждения мы ведем для того, чтобы обосновать какие-то перемены в статус-кво. Взяв год на раскачку, будем все относить к периоду с 1986 по 2005 г. Итак, общий тираж программного продукта должен к 2005 г. вырасти в сто раз. Один порядок роста можно отнести за счет увеличения тиражности. Отсюда получаем контрольную цифру минимального объема программного продукта к 2005 г. в 1 млрд.команд. Рассчитывать более чем на двукратное увеличение числа профессиональных программистов, учитывая демографическую ситуацию, не приходится; отсюда получаем задание на пятикратный рост производительности труда. Но этого мало. Стократное увеличение «контактной поверхности» программного продукта при существующем уровне надежности доводит стоимость издержек из-за ошибок в программах до 100 млрд. руб. Это значит, что надежность программного обеспечения должна быть по крайней мере на два порядка выше. Другими словами, число ошибок должно быть в десять раз меньше так же, как и число авостов, случающихся в программах. Наконец, соотношение стоимости разработки к стоимости сопровождения должно быть не порядка 2 : 1 на первый год эксплуатации, а ближе к 10 : 1.

Итак, мы получаем следующую задачу, стоящую перед программированием на ближайшие двадцать лет: при умеренном росте (в 2–3 раза) числа профессиональных программистов не менее чем в пять раз повысить их производительность; повысить надежность программного продукта не менее чем на два порядка и примерно на столько же сократить удельные затраты на сопровождение. Будет полезно сравнить нашу исходную точку отсчета с состоянием двадцатилетней давности (с 1965 г.). Понятие программного продукта еще только складывалось, но ретроспективная переформулировка нашей деятельности в то время может быть выражена следующим образом.

anonymous
()
Ответ на: комментарий от anonymous

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

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

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

Давайте вообразим, как выглядит программирование в лексиконе. Синтезирующее программирование проходит полностью в лексиконе вплоть до получения алгоритма нужной степени детализации. Если это заготовка (модуль или универсальный алгоритм), то она в таком виде и остается. Если программа должна быть передана машине, то она подвергается особой процедуре «лингвизации» (фортранизации, паскализации, алголизации и т.п.). Лингвизация – это перековка программы, которая, сохраняя правильность, придает ей стилистические особенности рабочего алгоритмического языка, после чего прямая транслитерация превращает программу в текст на этом языке, который исполняется или пополняет рабочую библиотеку. Лингвизация может быть творческим процессом, выполняемым специалистом по данному рабочему языку. Творчество, однако, состоит не в сохранении правильности программы (она гарантированно сохраняется), а в придании программе особого шика, наиболее идущего этому рабочему языку.

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

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

anonymous
()
Ответ на: комментарий от anonymous

Лексикону учат в ВУЗе раньше, чем какому бы то ни было рабочему языку (игрушечный практикум не в счет). Доказательное программирование является основой курса программирования, подкрепленного каторжным тренингом в духе лучших задачников по математическому анализу.

Программиста бьют по рукам, если он посмеет написать оператор цикла, не найдя перед этим его инварианта.

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

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

вместо этого на лексиконе было написано «TeX: the Program and the Book» того же Д. Кнута, на наглядных литературно-грамотных weave.web/tangle.web

вот например патчи на CTAN под gpc/fpc чтобы собиралось:

CTAN tex FPC and GPC Tex-FPC

если пройдешь по ссылке tex-gpc, то GPC надо брать отсюда: gnu-pascal.de/alpha

и стародревний gcc который уже лет 20 как не обновляется.

или на гитхабе отсюда: https://github.com/hebisch/gpc , там оно собирается с более свежим gcc 3.4.6,4.1.2,4.2.4,4.3.5

впрочем, более канонiчно взять ISO Pascal P5, P6 или подобные у него: https://github.com/samiam95124

там как раз рядышком ISO Pascal P2, P4, P5, P6 и Pascal-S и Pascaline.

кстати, есть метапроговая библиотека под Pascal/Pascaline/lib/C/C++ : samiam95124/petit-ami

кросплатформная под везде.

еще там рядом есть POPLOG: hebisch/poplog и hebisch/poplog_packages

– с метапроговой черепашкой – тоже интересно

опять же, см. «Thinking FORTH!» Лео Броуди про лексикон программирования форта и **Programming a problem-oriented language" Charles H. Moore POL.pdf

в общем, А. Ершов опять оказался прав. как и Лео Броуди и Дональд Кнут.

только в некоторых деталях они все ошибались – потому что метапрога тогда еще не было.

anonymous
()
Ответ на: комментарий от anonymous

точнее говоря: не было еще литературно-грамотного метапрога с нормальной литературно-грамотной IDE

нормальная : это например как в TDS или Origami из The Occam development system, со складками. чтобы блоки документации или блоки кода скрывать в фолдинги.

литературно-грамотное IDE должно быть фолдинговое

как пример, вот автор самого того Origami текстового редактора из moria.de пишет про свой емаксовый метапрог: FE

что такое редактор со складками ? это вот

это fe

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

да, у него нет лиспа. зато сам емакс написан как простая библиотека на понятной няшной сишечке.

отлично структурированной – потому что с фолдингом.

хелп кстати, зацени как там реализован:

fe.mm написан на troff который скриптом Mm2html на awk конпелируется в HTML

из него же можно сделать fe.ps и далее fe.pdf

сам Troff текст написан с фолдингом и макросами.

вот например, как нарисованы стрелочки на стр. 3 в 5 главе 5.Moving the cursor:

fe.mm line 200:

.H 1 "Moving the cursor" \"{{{
Moving the cursor is an important thing in an editor.
The most basic commands are:
.\"{{{ picture
.DS CB
.if t \{
.PS
line -> right 1 ; " forward character: C-f" ljust
line -> left 1 from last line.start ; "backward character: C-b " rjust
line -> down 0.5i from last line.start ; "next line: C-n" below
line -> up 0.5i from last line.start ; "previous line: C-p" above
.PE
\}
.if n \{
                    previous line: C-p
                            ^
                            |
                            |
backward character: C-b <---+---> forward character: C-f
                            |
                            |
                            v
                     next line: C-n
\}
.DE
.\"}}}
<....>
.\"}}}
.H 1 "Regions and the kill ring" \"{{{

здесь мы видим два фолдинга и открывающийся третий (приведено для синхронизации).

вот скажи мне теперь — а что мешает собственно, в таком же духе

рисовать постскриптом, или PIC-диалектом для troff/groff картинки

— описывая методологию метапрог моделирования ???

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

anonymous
()
Ответ на: комментарий от anonymous

TeX-FPC TeX-GPC

Compiling Knuth’s tex with GNU Pascal - gpc:

First, Knuth himself published in 2000 a port of tex to GNU Pascal. However, this version is limited to tex v3.14159 and requires a small additional heterogeneous piece of C code.

Second, Waldek Hebisch published a port gor GNU Pascal. It is nicely documented and published on CTAN. It supports the latest version of Knuth’s tex (v3.1415926), and has a clean directory scheme for the additional files (eg. fonts). Since it has very limited dependencies to the GPC library (only one call to execute and one to installsignalhandler that are easy to remove), it can be easily compiled in other runtime environments (and maybe with other compilers).

FreePascal

Preferred Wolfgang Helbig has also ported TeX to FreePascal, see https://ctan.org/pkg/tex-fpc, with the latest version from 2020-11-24

See also running tex on a java virtual machine

хотя можно взять например старый добрый ДОС (в Dosbox, разумеется) – и DJGPP + GPC + FPC + tex под dos (есть у того же DJGPP, например)

anonymous
()
Ответ на: комментарий от anonymous

хотя можно взять например старый добрый ДОС (в Dosbox, разумеется) – и DJGPP + GPC + FPC + tex под dos (есть у того же DJGPP, например)

более того, тогда можно взять rutangle.exe/ruweave.exe отсюда и писать свой метапрог на паскале по-русски

для чего надо сначала изучить примеры литературно-грамотного:

  • единый исходник web_exam.web

  • –> через rutangle конпелируется в паскалевские сорцы web_exam.pas

  • ==> через ruweave конпелируется в наглядную литературно-грамотную документацию web_exam.pdf

само описание метаязыка weave.web/tangle.web изначального есть здесь: webdescr.htm

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

с другой стороны, более-менее фичастый.

например, те же @d макросы – которыми сделан «перевод» русского паскаля на обычный волапуковский.

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

например, возможности макросов – в еще большем смысле.

например, как в Emacs org-mode есть переменные у блоков кода. а можно было бы придумать метапеременные и метаметапеременные и макросы которые пишут макросы и прочее метапрог который программирует сам себя – на лиспе или на форте и вот это все.

с другой стороны – упрощать разметку в каком-то смысле все же нужно.

например, сделать облегченную markdown-подобную.

наподобие набора макросов mom для groff (или, еще лучше – heirloom troff) – а не mm.

но чтобы не в ущерб функциональности.

anonymous
()
Ответ на: комментарий от anonymous

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

Если это заготовка (модуль или универсальный алгоритм), то она в таком виде и остается.

то есть: вот у нас тексто-графическое изображение ASCII-графикой метапроговых жгутиков и проводочков

.if ТЕКСТОВОЕ \{          \"{{{ тексто-графическое

                    previous line: C-p
                            ^
                            |
                            |
backward character: C-b <---+---> forward character: C-f
                            |
                            |
                            v
                     next line: C-n
\} \"}}} тексто-графическое

здесь для наглядности вложил в еще один фолдинг, в еще одну вкладку

Если программа должна быть передана машине, то она подвергается особой процедуре «лингвизации» (фортранизации, паскализации, алголизации и т.п.). Лингвизация – это перековка программы, которая, сохраняя правильность, придает ей стилистические особенности рабочего алгоритмического языка, после чего прямая транслитерация превращает программу в текст на этом языке, который исполняется или пополняет рабочую библиотеку. Лингвизация может быть творческим процессом, выполняемым специалистом по данному рабочему языку. Творчество, однако, состоит не в сохранении правильности программы (она гарантированно сохраняется), а в придании программе особого шика, наиболее идущего этому рабочему языку.

а это графическое изображение того же жгутика и проводочка подвергнутое перековке:

  • графичезации (тексто-графическое -> картинка где жгутики & проводочки )

  • метапроговизации ( конструирование копулирующих жгутиков & проводочков в новую диагарму неизвестным науке способом )

  • метаметапроговизации

( тексто-графическое -> картинка где жгутики & проводочки – это объектный язык метапроговый -> метаязык над этим объектным языком – например, PostScript примитивы над текстовым PostScript; или PIC-язык для картинок Брайана Кернигана для генерации шаблона с параметрами-метапеременными вида:

if ГРАФИЧЕСКОЕ \{             \"{{{  метаязык -- шаблон метапрога
.PS
line -> right $A ; " forward character: C-f" ljust
line -> left $B from last line.start ; "backward character: C-b " rjust
line -> down {$C}i from last line.start ; "next line: C-n" below
line -> up {$D}i from last line.start ; "previous line: C-p" above
.PE
\}   \"}}} метаязык -- шаблон метапрога

которое генерируется метакодом на похапе метаметапроге:

\"{{{ метаметаязык -- шаблон мета метапрога

PHP_emit($what="метаязык -- шаблон метапрога", $where={$metavars={$A,$B,$C,$D}});

\"}}} метаметаязык -- шаблон мета метапрога

с метапеременными $A,$B,$C,$D параметризующими этот шаблон.

метаметапрог является метакодом порождающим шаблон метапрога параметризованный метапеременными – параметрами «лексикона программирования» метапрогового

лингвизации в метапроговые метаязыки

(а также метамета языки и метаметамета языки и так далее ….)

anonymous
()
Ответ на: комментарий от anonymous

Итак, мы получаем следующую задачу, стоящую перед программированием на ближайшие двадцать лет: при умеренном росте (в 2–3 раза) числа профессиональных программистов не менее чем в пять раз повысить их производительность; повысить надежность программного продукта не менее чем на два порядка и примерно на столько же сократить удельные затраты на сопровождение.

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

то есть прогноз не оправдался.

alysnix ★★★
()
Ответ на: комментарий от alysnix

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

но случилось как и предсказывал Charles Moore:

Lisp Forth is an amplifier. Good programmer could write better code with it while bad programmer could write really ugly disastrous code.

то есть: на порядок усилили тех которые и так осилили. а неосиляторы – стали еще больше неосиливать :)))

в итоге победил жабаскрипт и питон :)) потому что на них неосиляторы хоть что-то смогут написать что не сломается от не в том месте поставленной запятой

в общем, осталось только найти таких программистов :)))

anonymous
()
Ответ на: комментарий от anonymous

он говорил что чтобы догнать и перегнать надо заниматься не экстенсификацией а интенсификацией

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

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

alysnix ★★★
()
Ответ на: комментарий от monk

(defstruct (point (:type list)) x y)

А в Racket так можно? Не могу найти в документации что то.

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

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

2. Императивное программирование в CL не такое удобное как в условном С, и не такое простое и наглядное как функциональное, а функциональное в Racket лучше продуманно, лучше подобраны аргументы, функции принимают несколько списков, пример foldl - reduce.

3. Вещи которые ожидаемы из коробки: генераторы, паттерн-матчинг (это есть даже в Python).

4. Lisp 2 ужасен, я хочу отличить #f от '(), я не хочу запоминать что есть несколько пространств имен.

Так что если кто то заинтересовавшийся лиспом это читает, я советую ему Racket.

MOPKOBKA ★★★★★
() автор топика
Последнее исправление: MOPKOBKA (всего исправлений: 1)
Ответ на: комментарий от MOPKOBKA

А в Racket так можно? Не могу найти в документации что то.

В Racket cons не базовый тип. Макросы на синтаксических объектах.

Есть struct->list.

А базовый тип как раз структура

> (struct->vector '(1 2))
'#(struct:pair ...)
> (struct->vector "ok")
'#(struct:string ...)

Так что если кто то заинтересовавшийся лиспом это читает, я советую ему Racket.

Для меня лично Racket тоже лучше, но есть люди, которым будет точно наоборот. Вот я делал когда-то анализ: Анализ пользователей Common Lisp и Racket

Common Lisp родня Forth’у: пишем программу в REPL, тестируем тут же, проектируем после того, как что-то выросло. Racket родня скорее Java: начинать писать приходится с декомпозиции на модули и описание типов/контрактов. Но, в отличие от Java, не приходится писать километровые портянки шаблонного кода, так как в языке есть нормальные макросы.

Кстати, у Racket есть и синтаксис совсем без скобочек: https://docs.racket-lang.org/rhombus/index.html

monk ★★★★★
()
Ответ на: комментарий от monk

Кстати, в Rhombus есть List и PairList.

Про List написано так:

Many operations on a list with N elements take O(log N) time, including getting an element of a list with […], appending lists with ++, adding to the front or end of a list with List.cons or List.add, inserting into the middle of a list with List.insert, deleting a list element with List.delete, or dropping or taking a list prefix or suffix with functions like List.drop. Internally, lists are implemented as relaxed radix balanced (RRB) trees.
monk ★★★★★
()
Ответ на: комментарий от anonymous

Впервые вижу анонимуса понимающего системное моделирование. Все что вы написали хорошо и правильно, но есть одна небольшая проблемка: лексикон метапрограммирования в метамета-* языках является данными, те моделью системы, а модель данных - мета моделью системы. В итоге мы на самом деле получаем 2 уровня: язык и метаязык, те мета высших порядков абстракции схлопывается и имеет смысл рассуждать о текущим + следующем уровне или о текущем + предыдущем уровне абстракции, а не раскапывать всю кроличью нору. Там ничего не поменяется, а сложности для понимания накинет очень сильно.

Obezyan
()
Ответ на: комментарий от monk

В Racket cons не базовый тип. Макросы на синтаксических объектах.

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

Это проблема многих высокоуровневых языков, например в Java я столкнулся с невозможностью адекватно написать коллекцию, потому что там невозможно написать общий код для Integer и int, и генерики принимают только объекты, а они занимают слишком много памяти по сравнению с примитивами. (А еще там индекс менее 32 бита, что не позволяет создавать массивы byte более 4гб, ну это отдельная тема)

В этом плане С намного более единообразен (а ассемблер на фон-неймановской архитектуре достигает вершины, там не только данные представлены в виде char[], но и код).

И этому есть много реальных применений, вот два интересных:

  • В некоторых мультиплеерных играх, сервер хранит предыдущее отправленное игрокам состояние, и текущее вычисленное, когда его нужно отправить, он запускает функцию:
    void write_diff(int socket, const void *old_state, const void *new_state);
    
    Которая отправляет клиенту данные вида [(offset, byte[]), ...], и клиент этими данными просто патчит свою память кодом вида:
    for (auto chunk : server.read()) 
      memcpy(&my_state[chunk.offset], chunk.data, chunk.data.size()); 
    
  • Консервативный сборщик мусора, такой как Boehm GC, сканирует память приложения, и ищет указатели, если указатель на память найден, то она считается используемой. Используется за пределами С, например в Guile.

Common Lisp родня Forth’у: пишем программу в REPL, тестируем тут же, проектируем после того, как что-то выросло. Racket родня скорее Java: начинать писать приходится с декомпозиции на модули и описание типов/контрактов.

При низкоуровневой работе, первым делом рекомендуется написать эмулятор устройства, что бы можно было тестировать свой код (мокинг). Работа в образе никогда не отмечается и является побочным эффектом организации Forth-системы. Заплаточное программирование считается вредным. Чарльз Мур против документации в коде, и вообще комментариев.

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

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

MOPKOBKA ★★★★★
() автор топика
Последнее исправление: MOPKOBKA (всего исправлений: 3)