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)
Ответ на: комментарий от MOPKOBKA

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

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

Работа в образе никогда не отмечается и является побочным эффектом организации Forth-системы.

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

В учебниках по Common Lisp тоже работа в образе явно не отмечается, но является фактическим стандартом. И Forth и Common Lisp это операционные системы в миниатюре.

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

Вот смотрю первую попавшуюся: https://www.taygeta.com/fsl/library/runge4.seq - всё в коде. В https://github.com/irdvo/ffl/ есть html, но сгенерированный из кода и примера (в результате вместо нормального описания справочник + код примера программы). Для сравнения Racket: https://docs.racket-lang.org/functional-data-structures/Red-Black_Trees.html — потребности смотреть исходники не возникает.

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

Способы отладки являются следствием, а не причиной.

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

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

Это означало перезапуск ОС, почему такого совета нету, думаю понятно.

Вот смотрю первую попавшуюся

Все по разному пишут, я излагаю то что читал у Чарльза Мура, и наиболее приближенных.

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

Это означало перезапуск ОС, почему такого совета нету, думаю понятно.

Программы на Forth пишут только для голого железа?

Все по разному пишут, я излагаю то что читал у Чарльза Мура, и наиболее приближенных.

Когда определяют стиль программирования на Си++, читают Макконнела, а не Страуструпа. Образ работы в Common Lisp тоже заметно отличается от первых лиспов. Надо смотреть не на желания автора, а на то, как используется.

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

Программы на Forth пишут только для голого железа?

Во времена популярности форта (и книжек) это основное направление было. Все значимые проекты именно такие.

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

Сложно это, проектов мало, форты у всех разные.

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

Работа в образе никогда не отмечается и является побочным эффектом организации Forth-системы.

Вот отмечается:

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

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

По этим причинам Форт-программисты тратят меньше времени на планирование, чем их коллеги классического толка - праведники планирования. Для них отсутствие такового кажется безрассудным и безответственным. Традиционные окружения вынуждают программистов планировать, поскольку традиционные языки не готовы к восприятию перемен. К сожалению, человеческое предвидение ограничено даже при наилучших условиях. Слишком сильное планирование становится непродуктивным. Конечно, Форт не исключает планирования. Он позволяет создавать прототипы.
(Броуди «Способ мышления - Форт»)

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

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

и сразу просится

Я художник! Я так вижу!

... Шура, а вы рисовать хоть умеете?
alysnix ★★★
()
Ответ на: комментарий от monk

Для меня образ, это когда код сохраняется не в файле с исходным кодом как в С, а в каком то специальном файле, и часто исходный код хоть и можно увидеть, файла на диске с привычным расширением для него нету (sb-ext:save-lisp-and-die). Когда есть сохранение состояний переменных.

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

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

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

Иногда потеря информации не является чем то важным, как функция write_diff, которая вообще не знает с чем работает, и пишет/читает только байты. В Java/Racket такое написать можно, с помощью рефлексии и switch-case по разным группам, но выглядеть это будет сложнее чем в С.

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

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

Можно блок информации хранить в виде байтов.

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

Для меня образ, это когда код сохраняется не в файле с исходным кодом как в С, а в каком то специальном файле, и часто исходный код хоть и можно увидеть, файла на диске с привычным расширением для него нету (sb-ext:save-lisp-and-die). Когда есть сохранение состояний переменных.

Обрати внимание на префикс sb-ext. Сохранение образа в файл в ANSI CL не обязательно. А вот работа в образе, когда можно перекомпилировать любую функцию или даже определение структуры, определить макрос и тут же использовать, это обязательно.

А в реализациях Форта сохранение образа тоже есть: https://spf.sourceforge.net/docs/intro.en.html#save

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

Именно так. Из того же Броуди:

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

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

Причиной такого подхода было огромное давление в сторону демонстрации чего- нибудь начальству. Мы крутились, как заведенные, никогда не описывая того, что делали. Через три года нам понадобилось вернуться назад и пытаться модифицировать этот код, без какой-либо документации.
Форт стал недостатком, поскольку позволил нам начать слишком рано. Было забавно зажигать огоньки и заставлять жужжать дисководы. Но мы не проходили через горнило проектной работы. Как я сказал, наши «свободные духи» вернулись к нам в виде призраков.

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

Можно блок информации хранить в виде байтов.

Но нельзя взять структуру (struct game-state (...)) и просто вызвать эту функцию, и отправить клиенту diff, как это сделано в С. В высокоуровневых/ограниченных языках это обычно решается написанием дополнительного слоя serialization/deserialization, потому что невозможно выбрать единое представление для всех типов.

Сохранение образа в файл в ANSI CL не обязательно.

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

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

А как это происходит в CL? Вот например Forth не предоставляет никаких инструментов для повторного defstruct с расширением поля. А CL? Я попробовал, он выдал ошибку, я думал что не выдаст а магически все сам преобразует, и это будет моим аргументом что работа в обрезе Forth ограничивается запуском определенных команд, удобно иметь командную строку для кручения всяких телескопов.

* (defstruct point x y)
POINT
* (defstruct point x y z)
... ERROR ...

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

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

Ну да. У тебя два байтовых массива. Из оригинальной структуры и из изменённой. Можешь отправлять разность.

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

Для многих можно. https://docs.racket-lang.org/reference/serialization.html

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

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

Работа в образе не про сохранение образа, а про работу в нём. Например, в Racket можно только создавать новые переменные в контексте текущего модуля. Даже переопределять нельзя:

define-values: assignment disallowed;
 cannot re-define a constant
  constant: a
  in module:'anonymous-module

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

После defstruct надо все значения пересоздать. Это всё-таки достаточно примитивная конструкция. Для классов CLOS есть update-instance-for-redefined-class. Для каждого класса можно написать уникальный алгоритм обновления на ходу.

monk ★★★★★
()
Ответ на: комментарий от MOPKOBKA
* (defstruct point x y z)
... ERROR ...

Там же уточнение

restarts (invokable by number or by possibly-abbreviated name):
  0: [CONTINUE           ] Use the new definition of POINT, invalidating
                           already-loaded code and instances.
  1: [RECKLESSLY-CONTINUE] Use the new definition of POINT as if it were
                           compatible, allowing old accessors to use new
                           instances and allowing new accessors to use old
                           instances.

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

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

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

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

forth так и работает

Это и есть работа в образе.

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

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

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

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

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

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

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

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

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

это для каких-то гаражных проектов.

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

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

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

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

Иногда строят прототип на выброс вполне осознанно.

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

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

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

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

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

Это потому что ты даже не понял, насколько выразительные средства можно создать на форте. :)

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

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

А потом почти вся эта работа шла коту под хвост.

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

выбранные языки и окружение неадекватно задаче

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

Как TeX переписали с Паскаля на Си.

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

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

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

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

Как TeX переписали с Паскаля на Си.

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

Я говорю о проектах, где сотни людей заняты. Они задают технологические тренды, а не гаражники.

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

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

это какой - «достаточно мощный»? форт что-ли?

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

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

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

MacOS переписывают с Objective C на Swift. Банковский код с Кобола на Яву.

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

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

это какой - «достаточно мощный»? форт что-ли?

Да. Если в Яве f.connect(s, p1, p2) вдруг надо заменить на s.connect(f, p1, p2, p3), то надо переписывать две структуры классов. В форте мы переписываем одно слово CONNECT. Аналогично по структурам данных.

код чудовищно контекстно-зависим, то есть не поддается статическому анализу без эмуляции исполнения

Перл даже не разбирается на лексические единицы без эмуляции исполнения. И что?

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

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

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

но слабый по наглядности и абстракций и реализации

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

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

Перл даже не разбирается на лексические единицы без эмуляции исполнения. И что?

а кто-то говорил за перл? давайте еще брейнфак обсуждать.

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

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

Там можно определять «прилагательные». То есть слова, которые влияют на следующие слова-существительные. Или «наречия». То есть слова, которые влияют на следующие слова-глаголы.

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

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

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

Так этот специфицированный образ от внутреннего состояния зависит.

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

а в точной семантике и желательно ее проверяемости. и читаемости этого «влияния»

Так и я про то же. ВЕРХНИЙ ЛЕВЫЙ РЫЧАГ 20 ГРАДУСОВ МЕДЛЕННО ПОВЕРНУТЬ воспринимается проще, а что-то пропустить сложнее, чем в

Рычаг = new Рычаг();
Рычаг.горизонтальный_выбор = левый;
Рычаг.вертикальный_выбор = верхний;
Угол = new Градусы(20);
Устройство.скорость_поворота = медленно;
Устройство.повернуть(Рычаг, Угол);
monk ★★★★★
()
Ответ на: комментарий от alysnix

форт - это стековая машина со словарем

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

код чудовищно контекстно-зависим, то есть не поддается статическому анализу без эмуляции исполнения

Весь ANS Forth нет, но если добавить правил, то поддается, более того, при построении на стеке это идеальная машина для линейных типов. И разворот в SSA простейший. Да и даже ANS Forth компиляторы слова переводят в регистровое представление, если они подходят под некоторые правила.

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

Я писал без комментариев и карандаша.

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

Я писал без комментариев и карандаша.

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

alysnix ★★★
()
Ответ на: комментарий от monk
Рычаг = new Рычаг();
Рычаг.горизонтальный_выбор = левый;
Рычаг.вертикальный_выбор = верхний;

Это разве ООП? Переделал эти 3 строки на production-ready код:

// TODO протекающая абстракция, добавить AbstractBridgeProxyManager
AbstractLeverBuilderFactory levelBuilderFactory = applicationFacade.getLevelBuildFactory();

AbstractLevelBuilder levelBuilder = levelBuilderFactory.createBuilder(levelBuilderOptions, true);

AbstractLevelVerticalStatePool levelVerticalStatePool = levelBuilder.getVerticalStatePool();

// Ничего не трогать, в прошлый раз сервис висел 3 часа!!! 
try {
  AbstractLevelVerticalState leftState = levelVerticalStatePool.createLeftIfNotExists();
  levelBuilder.setVertical(new LevelStateAdapter(leftState, levelBuilder));
} catch (BuilderDomainException e) {
  AbstractLogger logger = applicationFacade.getLogger();

  AbstractMessageBuilder messageBuilder = logger.getMessageBuilder();
  messageBuilder.setMessage("Ошибка при создании состояния рычага !!!");
  logger.write(messageBuilder.build());

  throw LevelDomainException(e);
}

try {
  AbstractLevelVerticalState upperState = levelVerticalStatePool.createUpperIfNotExists();
  levelBuilder.setHorizontal(new LevelStateAdapter(upperState, levelBuilder));
  AbstractLevel level = levelBuilder.creaate();
} catch (BuilderDomainException e) {
  // Я ненавижу свою жизнь
  AbstractLogger logger = applicationFacade.getLogger();

  AbstractMessageBuilder messageBuilder = logger.getMessageBuilder();
  messageBuilder.setMessage("Ошибка при создании состояния рычага !!!");
  logger.write(messageBuilder.build());

  throw LevelDomainException(e);
}

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

проблема не ограниченых глобальностях (а в массе своей объекты и есть перситенции но не всюду доступные ( own из алгола передавали превет)

хохма в том что объекты без конкурентности это профанация

и ничё - в индустрии успели за поколение религию замутить

ща раскуриваюсь btree и прочий хаш ибо rdbM$ и забавно как не докрученность obj-rel модели данных ( ибо слонам достаточно реализации int float string для бизнеслеммингов) породило массы ORM

такая вот загагузия такая вот вечная молодость

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

большенство прелестей форта в пипоне декараторами :)

qulinxao3 ★☆
()
Ответ на: комментарий от monk
Рычаг = new Рычаг();
Рычаг.горизонтальный_выбор = левый;
Рычаг.вертикальный_выбор = верхний;
Угол = new Градусы(20);
Устройство.скорость_поворота = медленно;
Устройство.повернуть(Рычаг, Угол);

можно так

Рычаг.Левый().Верхний().Повернуть(20,Медленно)

Рычаг(Левый,Верхний).Повернуть(20,Медленно)

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

ВЕРХНИЙ ЛЕВЫЙ РЫЧАГ 20 ГРАДУСОВ МЕДЛЕННО ПОВЕРНУТЬ

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

То есть я художник, я так вижу. Англичанин(или китаец) может и не понять.

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

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

Код чужой я тоже без бумажек читаю, хотя без прототипов слов все же не так привычно, я их использую, но даже без можно хоть драйвера читать, этот например (там полный код драйвера для чтения/записи IDE диска): https://colorforth.github.io/ide.html

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

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

Ну это лол, с математикой тоже самое, сколько людей за прошлый век пыталось придумать нормальную однозначную математическую нотацию?

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

правильное ооп не задаёт ваще модель исполнения в сколько потоков

правильное ооп это каждый объект сам поток исполнения

да с наложением ограничения на объект его ролями - но всякое сообщение именно объект(точнее субъект но то устоявшаяся терминология ) процессирует с возможной делегацией в предков

однако в индустрии в целом ооп отдельно распределённость отдельно конкурентность/параллельность крч 7 ортогональностей а восьмая прямая в форме котёнка

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

Как лисперу не приходится считать скобки

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

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

так не надо.

надо чтобы выглядело так -

Рычаг(Левый,Верхний).Повернуть(20,Медленно)

тут и полная проверка типов, и компактно.

а стоит в фортовской фразе

ВЕРХНИЙ ЛЕВЫЙ РЫЧАГ 20 ГРАДУСОВ МЕДЛЕННО ПОВЕРНУТЬ

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

ВЕРХНИЙ ЛЕВЫЙ РЫЧАГ 20 ГРАДУСОВ ПОВЕРНУТЬ МЕДЛЕННО
alysnix ★★★
()
Ответ на: комментарий от MOPKOBKA

а нет счёта - есть навык видеть парности :)

это буквально как наигранные шахматисты быстро воспринимают(могут воспроизвести растановку) возможные по игре позиции и нубят к «невозможным в игре» позициям

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

Рычаг(Левый,Верхний).Повернуть(20,Медленно)

Вот хороший пример, где фортовское представление гибче.

Не трогая описания слова ПОВЕРНУТЬ и только добавив пару слов будет работать

3 РЯД ЛЕВОЕ КОЛЕСО 5 РАДИАНОВ МЕДЛЕННО ПОВЕРНУТЬ
ЦЕНТРАЛЬНЫЙ РЫЧАГ 2 РАДИАНА БЫСТРО ПОВЕРНУТЬ

А в ООП придётся копипастить класс Рычаг в класс Колесо, писать в документации, что центральный рычаг задаётся координатами Центральный, Центральный, добавлять метод ПовернутьРадианы.

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

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

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

alysnix ★★★
()