присвоение внутри if

А что за задача?

«Нам» это я образно про участников дискуссии.

В продолжение темы советую почитать: http://www.rsdn.ru/forum/decl/3504052.flat.1.aspx

It вычисляется всегда. Prg предается в функцию без интерпретации в виде списка. Если It не NIL, то интерпетируется первое выражение в Prg, иначе все остальные.

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

Из туторила: http://www.software-lab.de/doc/tut.html#fun

Preventing arguments evaluation and variable number of arguments

Normally, PicoLisp evaluates the arguments before it passes them to a function:

: (hello (+ 1 2 3))
Hello 6

: (setq A 1  B 2)       # Set 'A' to 1 and 'B' to 2
-> 2
: (de foo (X Y)         # 'foo' returns the list of its arguments
   (list X Y) )
-> foo
: (foo A B)             # Now call 'foo' with 'A' and 'B'
-> (1 2)                # -> We get a list of 1 and 2, the values of 'A' and 'B'

In some cases you don't want that. For some functions (setq for example) it is better if the function gets all arguments unevaluated, and can decide for itself what to do with them.

For such cases you do not define the function with a list of parameters, but give it a single atomic parameter instead. PicoLisp will then bind all (unevaluated) arguments as a list to that parameter.

: (de foo X
   (list (car X) (cadr X)) )        # 'foo' lists the first two arguments

: (foo A B)                         # Now call it again
-> (A B)                            # -> We don't get '(1 2)', but '(A B)'

: (de foo X
   (list (car X) (eval (cadr X))) ) # Now evaluate only the second argument

: (foo A B)
-> (A 2)                            # -> We get '(A 2)'

Mixing evaluated arguments and variable number of unevaluated arguments

As a logical consequence, you can combine these principles. To define a function with 2 evaluated and an arbitrary number of unevaluated arguments:

: (de foo (X Y . Z)     # Evaluate only the first two args
   (list X Y Z) )

: (foo A B C D E)
-> (1 2 (C D E))        # -> Get the value of 'A' and 'B' and the remaining list

О, как удобно писать функции с переменным числом аргументов, в каждом случае вызывать eval ручками?

Здесь это уже в языке из коробки

Разумеется. Вопрос в том, как будет выглядеть (de or ...). В CL нельзя написать (defun or ...), но можно (defmacro or ...), так как defun определяет функции с энергичной стратегией вычисления. Если de вводит функции не с энергичной стратегией (или если нет контроля над стратегией), то это просто смешно (почему - потому что эффективно компилировать функции с не строгой стратегией вычисления это нетривиальная задача). Нет, ну для интерпретатора «на поиграться» может и ок.

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

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

исходный код + байткод + бинарник на каждую платформу! По-моему, к простоте это не имеет отношения.

А что, где-то иначе? (Реализация языка (рантайм + компилятор + библиотеки) + исходный код для компиляции и загрузки (с помощью компилятор, в рантайм, с использование библиотек) | скомпилированный пакет (аналогия - динамическая линковка)) | толстый образ (аналогия - статическая линковка). CL легко ругать за deployment & delivery (особенно, за второе), но только за desktop приложения, с серверами приложений никаких проблем.

А что за задача?

«Нам» это я образно про участников дискуссии.

В продолжение темы советую почитать: http://www.rsdn.ru/forum/decl/3504052.flat.1.aspx

Спасибо за ссылку.

Может участникам дискуссии будет интересно познакомится, как решаются более менее стандартные задачи на http://rosettacode.org/wiki/Category:PicoLisp и сравнить с другими языками, чтобы составить свое мнение о предмете?

Так вроде и циклы и map никто не отменял.

Кстати, aif не нужен, и написан по желанию собеседников.

потому что эффективно компилировать..

Так и я об этом. Компилятор снижает гибкость!

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

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

антогонистичное «древним лиспам»

Не совместимое не значит «антогонистичное»

А что, где-то иначе?

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

серверами приложений никаких проблем

Давно хочу sbcl для андроида на мой телефон. Не подкинете ли ссылку?

Из туторила

Какие откровения.

CL-USER> (setq a 1 b 2)
2
CL-USER> a
1
CL-USER> b
2
CL-USER> (defun foo (x y) (list x y))
FOO
CL-USER> (foo a b)
(1 2)
CL-USER> (defun foo (x) (list (car x) (cadr x)))
FOO
CL-USER> (foo '(a b))
(A B)
CL-USER> (defun foo (x) (list (car x) (eval (cadr x))))
FOO
CL-USER> (foo '(a b))
(A 2)

суть в том, что это всё справедливо и по отношению к LISP 1.5 и вообще к тому лиспу который изначально определил МакКарти - достаточно cons-примитивов, quote и eval (ну и define). Т.е. неправильно говорить что это что-то PicoLisp-специфичное. Макросы и expand за тем и появились, чтобы не квотировать и не evalить всё вручную - то что тут делается это работа с кодом как с данными вручную, обработка частных случаев, макросы обобщают и упрощают такую работу.

Т.е. неправильно говорить что это что-то PicoLisp-специфичное.

Полностью с этим согласен. Вот только жаль, что никто и не настаивает на противоположном.

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

Давно хочу sbcl для андроида на мой телефон. Не подкинете ли ссылку?

В природе нет sbcl для андроеда. Да и жирноват он. А вот clozure CL мог бы взлететь на arm и рантайм у него полегче.

А «напаиграца» вполне clisp'а бы хватило.

Компилятор снижает гибкость!

У интерпретируемых языков соотношение скорость/память сильно отклонено в сторону память (медленно, но мало памяти). Есть достаточно высокоуровневые компилируемые языки у которых это соотношение более-менее ровное (OCaml, например). Вообще, компилятор может быть и незаметен (JIT, V8, например), всегда доступный и переписываемый (как в CL) компилятор не то чтобы снижает гибкость, просто программы тяготеют к образами в которые включён этот компилятор.

работа без макросов возможна и давно реализована

Да, начиная с 1958 года :)

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

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

Давно хочу sbcl для андроида на мой телефон. Не подкинете ли ссылку?

У SBCL нет готового (тем более официального) порта на ARM. Под Android/iPhone есть CCL и ECL (у последнего есть сборки с поддержкой ndk на GitHub).

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

Давно хочу sbcl для андроида на мой телефон.

Так лучше Clojure.

Так и я про это. Его уже наверное лет 5 на arm портируют и еще столько же будут. А ccl для arm только недавно появился и лишь для линуха И это все прелести компилятора.

Проблема в том, что интерпретация на уровне исходного кода по скорости это примерно как bash

Редкий язык работает медленне чем bash. Интерпретатор лиспа намного проще, чем любой другой. Автор picolisp утверждает, что на некоторых задачах picolisp сравним по скорости выполнения с с-кодом, на других отстает, но разница 2-3 раза.

сервера приложений это же другое

Кто сказал, что какую-нибудь базу или веб не надо запускать на телефоне или планшетке?

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

Макросы позволяют писать произвольный host eDSL в виде s-выражений, который потом компилируется (не интерпретируется!) в target, а именно в сам CL. В самом CL множество макросов, так что процесс компиляции, частично, это просто процесс раскрытия макросов.

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

Понимание кода всегда требует понимания используемых им форм - специальных форм, функций и макросов, если в языке нет макросов но есть функции с настраиваемой стратегией вычисление, то понимание кода требует знать о том, какая у них стратегия. Кроме того, можно следовать стилистическим соглашениям в названии макросов (define-*, with-* и т.п.) - будет понятно где что (emacs такие макросы из коробки выделяет особым образом). Ну и гомоиконность именно на том и основана, что язык расширяем макросами не отличными от функций и специальных форм. Например, (+ 1 2 3), можно полагать, что #'+ - функция, (or t (print 1)), тут or (вызываемый именно так) это либо специальная форма, либо макрос. С макросами всегда можно определитель or и любую другую форму транслируемую в расширяемое подмножество языка.

gensym * (26.04.2012 20:40:31)

Мы тут aif делаем, уходи, ты нам не нужен.

Автор picolisp утверждает, что на некоторых задачах picolisp сравним по скорости выполнения с с-кодом, на других отстает, но разница 2-3 раза.

Чудеса и магея. Интерпретатор не может так работать. Например, те самые тысячи раз (он (fibo 35) несколько секунд считает).

Кто сказал, что какую-нибудь базу или веб не надо запускать на телефоне или планшетке?

Сервер? Разве что что-нибудь лёгкое вроде SQLite.

Надеюсь, у вас есть конструкции интереснее, чем те, что можно симулировать «dosome '[ _ print ] '[ «err» print ] if*»?

Автор picolisp утверждает, что на некоторых задачах picolisp сравним по скорости выполнения с с-кодом, на других отстает, но разница 2-3 раза.

Чудеса и магея. Интерпретатор не может так работать. Например, те самые тысячи раз (он (fibo 35) несколько секунд считает).

: (de fibo (N)
   (if (> 2 N)
      1
      (+ (fibo (dec N)) (fibo (- N 2))) ) )
-> fibo
: (bench (fibo 35))
6.413 sec
-> 14930352

Да. Считает. Поскольку алгоритм ОЧЕНЬ не оптимален. Но для сравнения пойдет. Есть желаюшие набростать тоже самое на с?

Надеюсь, у вас есть конструкции интереснее, чем те, что можно симулировать «dosome '[ _ print ] '[ «err» print ] if*»?

Вот такая пойдет?

: (de fibonacci (N)
     (cache '(NIL) (pack (char (hash N)) N)
	(if (> 2 N)
	   1
	   (+
	      (fibonacci (dec N))
	      (fibonacci (- N 2))))))
-> fibonacci
: (bench (fibonacci 35))
0.000 sec
-> 14930352
: (bench (fibonacci 3500))
0.032 sec
-> 207130242203026275341619953729934146420769196734460097332608824722385384129249316079769734334045194449765931169332916009997704931531881944873913582286951513424682248770868964253684228104382689660431435922397519756497357499967505758679688646649075302803539077528386858224498222588856280163988716395494385174391839960163039177209350627464390126710780519800906469209323422419340370206160685029942665147699080894547312128772252056873619870227805192104251242507890220628181380481902079219434109323696121231264625722768733484440412902313033879037929246974105582008193813127877888969955929338924710176760096431782662127393614942208069808665358891583772406001030408459587892001012185206668209362160782987676392635512259975382189797347146626

Кстати, а что показывает здесь с-версия?

Здесь лежит старая байка, как написанный за пару минут веб сервер на piсolisp http://john.freml.in/*latest*?.=&AGE=3452325060&TAGS= уделал tpd2 на sbcl !!!

Автору tpd2 понадобилось 2 месяца чтобы отыгратся.

(cache ...

Это меморизация?

Тогда http://factor-language.blogspot.com/2007/01/memoization-in-factor.html

С тем примером, выполнение [ 3400 fib ] time даёт:
[code]
Running time: 0.003441205 seconds
...
--- Data stack:
261504693497714980661821775715951048827990096021932773199728004894253310070672336416807041378906494036434163074149768098349190160536881090094035095774204172522643493572010453580764771290349867284746087731524426973404696247089357915292358877022005258012372243222500220047110135291474853283021300531872204180932277501083168158112411087550446717015842441609072453117649795538510206288918553297725828250148158048160561529888420635626505500685830041083446288032743053618182388061635408672537850260162479203314626140401144128214715478620129906731675292919426962778148562339893838782707969542333200121019442096599984670784676045124717279361693579909460489062341979078646746498586969298256346200586216882482936095721901
[/code]

Это меморизация?

Да, она самая. Только у меня было 3500 а не 3400

(bench (fibonacci 3400))
0.000 sec
-> 261504693497714980661821775715951048827990096021932773199728004894253310070672336416807041378906494036434163074149768098349190160536881090094035095774204172522643493572010453580764771290349867284746087731524426973404696247089357915292358877022005258012372243222500220047110135291474853283021300531872204180932277501083168158112411087550446717015842441609072453117649795538510206288918553297725828250148158048160561529888420635626505500685830041083446288032743053618182388061635408672537850260162479203314626140401144128214715478620129906731675292919426962778148562339893838782707969542333200121019442096599984670784676045124717279361693579909460489062341979078646746498586969298256346200586216882482936095721901

А что показывает тест для 35 без меморизации?

мое железо:

cat /proc/cpuinfo 
processor	: 0
vendor_id	: GenuineIntel
cpu family	: 6
model		: 15
model name	: Intel(R) Core(TM)2 Duo CPU     T7300  @ 2.00GHz
stepping	: 10
microcode	: 0x92
cpu MHz		: 800.000
cache size	: 4096 KB

Так вроде и циклы и map никто не отменял.

Э-э-э... Как это относится к моему вопросу?

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

В вашем пиколиспе нужно понимать, какая функция какие аргументы вычисляет, а какие _возможно_ нет. Не вижу в чем это проще макросов CL.

О, как удобно писать функции с переменным числом аргументов, в каждом случае вызывать eval ручками?

Так вроде и циклы и map никто не отменял.

Э-э-э... Как это относится к моему вопросу?

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

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

В вашем пиколиспе нужно понимать, какая функция какие аргументы вычисляет, а какие _возможно_ нет. Не вижу в чем это проще макросов CL.

Если разработчик функции придает разный смысл каждому аргументу, то, естественно, позже он должен об этом помнить. Упрощение же состоит, в том числе, и в том, что даже не заглядывая в документацию, можно, не задумываясь, отправлеть каждую функцию в mapcar и со. Если есть макросы, то их поведение при передаче в другую функцию будет трудно предсказуемым. Поэтому вызов типа (mapcar foo (1 2 3)) в pl всегда корректен, а cl нужно сначала посмотреть не макрос ли foo

Кроме того писать и отлаживать макросы надо не так как функции. А это, как ни крути, и есть усложнение языка. Причем, как показывает, тот же picolisp не слишком нужное.1

А что показывает тест для 35 без меморизации?

Running time: 0.46716173 seconds

Железо:

processor	: 0
vendor_id	: AuthenticAMD
cpu family	: 15
model	 : 67
model name	: AMD Athlon(tm) 64 X2 Dual Core Processor 5000+
stepping	: 2
microcode	: 0x62
cpu MHz	 : 2599.990
cache size	: 512 KB

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

Да хер с ним, с разрабом - это должно быть описано в доке и об этом должен помнить _каждый_ пользователь либы - чем это лучше документирования и запоминания «функция/макро»? Так что «ни катит» за киллерфичу.

А на счёт трудности переноса компилятора - что-ж нормального пиколиспа до сих пор даже под грёбанный офтопик нет? Или мы имеем «маргинала из маргиналов»?

Я не спорю - малюсенький и довольно быстрый интерпретатор лиспа - это хорошо. Только надо (ладно, не всем - мне) несколько фич: куча поддерживаемых платформ, родное, простое и быстрое ffi с калбэками, поддержка системных тредов (без GIL-а!) и, как следствие, «тредо-безопасность». Вот только мне кажется, что под эти условия даже мулисп подойдёт больше, чем пиколисп.

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

Running time: 0.46716173 seconds

Какой язык?

Вот железка получше, чем была но похуже твоей (bench (fibo 35))

1.575 sec

Железо:

processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 26
model name      : Intel(R) Xeon(R) CPU           X5560  @ 2.80GHz
stepping        : 5
cpu MHz         : 1596.000
cache size      : 8192 KB

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

Ага и дивиться полученым сайд-эффектам.

что-ж нормального пиколиспа до сих пор даже под грёбанный офтопик нет?

Целевой платформой были posix- подобные. Под win собирается с cygwin. Есть java реализация.

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

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

куча поддерживаемых платформ

it should compile and run on current 32-bit GNU/Linux, FreeBSD, Mac OS X (Darwin) and Cygwin/Win32 distributions, and on 64-bit GNU/Linux systems.

+ Java

Я пробовал на Android и MeeGo. Все заработало. Для Android пришлось немного повозится

родное, простое и быстрое ffi ...

Есть:

To call C functions, the new 'native' function should be used, which can interface to native C functions directly, without the need of glue code to convert arguments and return values.

с калбэками,

С этим похуже: http://rosettacode.org/wiki/Use_another_language_to_call_a_function#PicoLisp

тредо-безопасность

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

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

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

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

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

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

Ага и дивиться полученым сайд-эффектам.

Это ошибка программиста а не свойство языка.

Надеюсь, у вас есть конструкции интереснее

Можно enum сделать:

(defenum color red green blue)

(color red)  ;; => 0
(color green)  ;; => 1
(color blue) ;; => 2

Где этот enum скомпилится в:

(defmacro color [value]
  (case value
    red 0 
    green 1 
    blue 2))

А вызов color скомпилится в код цвета.

На Clojure:

(defmacro defenum [name & colors]
  `(defmacro ~name [param#]
     (case param#
       ~@(reduce concat
                 (map (fn [color index]
                        `(~color ~index))
                      colors
                      (range (count colors)))))))

На Java/C#/C++/PHP:

Вася, возьми Раджеша и закодируйте мне класс Color по этой UML-диаграмме. Даю неделю.

...

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

...

Помните Color? Надо такое же, только со зверюшками: бегемот, жираф и белка. Отпуск придется перенести.

Под win собирается с cygwin.

если я не ошибаюсь, это «вырубает» много возможностей хост-системы

Для Android пришлось немного повозится

гы-гы, у меня Android на MIPS - где мой набор шаманских бубнов?

треды отправились в мусорное ведро вслед за компилятором с диагнозом «не нужно»

и туда-же отправилось взаимодействие со всем, что использует треды

Там таких заготовок пруд пруди.

В Питоне всё равно батареек больше.

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

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

То есть человек утверждающий, что работать на языке более высокого уровня, удобнее чем на языке низкого - полный даун?

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

гы-гы, у меня Android на MIPS - где мой набор шаманских бубнов?

Приблемка не в cpu а в том что google слегка кастрировал linux окружение и переделал систему сборки

Там таких заготовок пруд пруди.

В Питоне всё равно батареек больше.

Сколько волка не корми, а у ишака все равно толще

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

Даже не могу себе представить, как много времени надо на отладку этого шедевра:

(de cache ("Var" "Str" . Prg)
   (nond
      ((setq "Var" (car (idx "Var" "Str" T)))
         (set "Str" "Str" "Str" (run Prg 1)) )
      ((n== "Var" (val "Var"))
         (set "Var" (run Prg 1)) )
      (NIL (val "Var")) ) )

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

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

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

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

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

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

Шкала ценностей «дерьмо - драгоценности» в мире «чистого искусства» очень сильно отличается от аналогичной в среде «производства мат. ценностей». Утверждающим, что программирование - это искусство, спешу сообщить, что им надо поторапливаться - их Титаник вот-вот отправится. Всем остальным остаётся (прошу прощения за тавтологию) только грубая пахота, чтобы достигнутыми результатами доказать превосходство своих идей. А то получается как с торсионными полями...

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

программирование - это искусство

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

остаётся только грубая пахота..

Это очень печально. Мне больше нравится принцип IBM о том, что работать должна машина. Человек должен думать!

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

С какого хера ты сюда приплёл «поборников копирайтов и патентов» - оставим на твоей совести или по (недо|пере)мыслию. А программа «нематериальна» практически так-же, как и чертёж. Вот только «производство» последних стандартизировано настолько, что многим кодерам и в кошмарном сне не приснится.

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

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

Мне больше нравится принцип IBM о том, что работать должна машина. Человек должен думать!

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

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

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

К чему бы это?

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

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

Это то, о чем я второй день здесь толкую.

Кстати, реализацию defenum на PicoLisp в студию.

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

разделением логики.

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

Я думал, мы закрыли тему.

Где кривизна-то? Это инструмент для создания КОМПИЛЯТОРОВ. А ты всё про интерпретаторы свои. Обсуждать нечего.

Но самое смешное, что даже этот de из PicoLisp можно на макросах сделать.

Какой язык?

Factor же.
И да, вот как реализуется меморизация: https://github.com/slavapestov/factor/blob/master/basis/memoize/memoize.factor

Мемоизация же.

Кстати, реализацию defenum на PicoLisp в студию.

Да нет проблем

(de color(Color)
     (cdr (assoc Color '((red . 0)(green . 1)(blue . 2)))))