Последняя безнадежная попытка достучаться до некоторых

[rexy_craxy]

Почему "все языки делятся на две группы: Лисп и все прочие" ((ц) не помню кто)? А вот почему:

Определим пару функций:

(define (two-op a b c )
(* (+ a b) c))

(define (swap-ops , new-head)
(setq new-head (nth '(1 1 0) two-op))
(setf (nth '(1 1 0) two-op) (nth '(1 0) two-op))
(setf (nth '(1 0) two-op) new-head))
Пощупаем:

> two-op
(lambda (a

Comments

[sharpc]

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

[rexy_craxy]

Не особенно большая. Строки не считал. Управляла когда-то "умными" контроллерами по сбору информации с приборов учета и общалась с головным серваком.

И in advance: только не надо заводить тут любимую песню про "большие проекты", про "паттерны" и "шаблоны", про "скорость разработки" и т.п. -- на эти темы Вам есть где душу отвести ;)

[sharpc]

Ну хотя бы объем исходного кода

[rexy_craxy]

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

[sharpc]

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

[udpn]

Переводя sharpc.

[rexy_craxy]

Фи.

[rexy_craxy]

> Мне стало интересно, связано ли это с когнитивным стилем или с типичным объемом кода.

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

[sharpc]

Обычно байты, обладающие этой внутренней красотой, называют данными (в отличие от кода, который должен изменяться как можно меньше, скажем только посредством vtable). А чтобы уменьшить сложность создаваемой системы, эти изменяемые данные всячески типизируют, стандартизуют и прочими способами ограничивают. Одним из самых радикальных направлений является как раз pure functional языки и концепция stateless. Потому тем более интересно применение этого инструмента совершенно другим образом: внесения состояния даже в код.

[rexy_craxy]

Вот именно. Это ведь просто догма, которую можно (а ТРИЗ и история техники говорят: нужно!) перевернуть: пусть все течет и меняется, причем не просто как "состояния" в узком смысле (типа, как КА по своему графу прыгает), а в ходе постоянной целенаправленной самомодификации. Ведь очевидно же, что если пресловутый ИИ (уровня ранних хотелок) когда-нибудь и будет создан, то он будет именно таким -- непрерывно меняющим и перестраивающим сам себя, потому что таково мышление человека.

Почему же нынешних прогеров не учат думать так, как, по-видимому, думал Ленат, когда Eurisko писал? -- А кому учить?..

[sharpc]

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

[rexy_craxy]

Не хочу спорить (это нас слишком далеко заведет), лишь напомню, что "код" или "данные" -- это вопрос "отношения" к некоторому "тексту" в определенный момент времени. Что для ядра ОС код, то для компилятора или дебаггера данные, что код для ЦПУ, то данные для памяти, и т.д. Понятно, что сегодня преобладает подход "машина должна ездить", но когда-то человеку придется ведь (почти) выйти из "контура" чисто технологического процесса программирования! А зачем машине (или системе машин) для себя самой переводить с одного (теперь уже "чисто машинного") языка на другой?

[sharpc]

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