вопрос по sicp

Что еще можно почитать по типу sicp но желательно без привязки к конкретному яп?

Многие «thinking forth» ставят в один ряд с SICP, но я лично не читал.

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

http://lambda-the-ultimate.org/node/4850

очень интересная тема, я время от времени порываюсь осилить:)

Не читай, борщехлебушком станешь.

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

блин FORTH это конечно... хотя там объем книги в 3 раза меньше sicp можно и осилить.

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

Ну это только первая глава.

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

Что тогда читать?

Код читать. А лучше писать.

Код читать. А лучше писать.

Мне кажется это противоположная крайность.

«Теория без практики — мертва, практика без теории — слепа» (c) Суворов

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

Языки вообще бывают двух видов: описательные и алгоритмические. Логика - язык описания мира, изначально она не создавалась как язык приказов. Вообще говоря полезно в алгоритмическом языке иметь описательные возможности, а в описательном языке иметь возможность задавать процессы (алгоритмы). Т.е. скорее всего произойдет конвергенция этих двух видов языков. Однако логическое программирование (Prolog и ко) рассматривает логику как непосредственно алгоритмический язык, что концептуально неверно. Как конкретно будет соединена логика и ЯП сказать трудно. Как раз SQL - это движение в этом направлении.

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

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

без привязки к конкретному яп?

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

Лично я рекомендую остановиться на двух языках - Lisp и Smalltalk. Они несут в себе глубокие идеи.

По Лиспу можно еще почитать John Allen «Anatomy of Lisp». Blue Book оп Smalltalk.

Еще есть такая вот книга, она конечно устарела, но там такие классные замечания разбросаны по тексту. Полистать хотя бы стоит: Хигман Б. «Сравнительное изучение языков программирования.» М.,1974.

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

Christopher Strachey. «Fundamental Concepts in Programming Languages.»

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

Мало ли что там написано. Авторы SICP, например, говорили что замыкания и ООП - это одно и то же. А это, очевидно, не так. Знакомства с CLOS достаточно, чтобы понять, что такое ООП и почему предыдущие попытки (до CLOS) открыть это приводили к misconception. Логическое программирование - это такое же misconception, но в отличии от ООП мы не знаем как это делать правильно. Нужно подождать в этом вопросе.

Лично я рекомендую остановиться на двух языках - Lisp и Smalltalk. Они несут в себе глубокие идеи.

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

Авторы SICP, например, говорили что замыкания и ООП - это одно и то же

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

А это, очевидно, не так

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

попытки (до CLOS) открыть это приводили к misconception

И не пи*ди за клоз. клоз оправдывает свое название — клозет. Правильое ООП в смолтоке и селфе, а также в языках, перенявших данную модель, в той или иной степени — Javascript, IO, Ruby и прочие.

Учить яп которые сейчас не используют на практике у меня большого желания нету.

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

Smalltalk интересен не как язык, а как окружение. Как язык он ни чем не лучше Руби. Если ты хочешь понять какими были когда-то Лисп машины и каким должен быть вообще компьютер, то посмотри Smalltlak (например Squeak). Лисп же интересен именно как язык. Но Кложур - не тру Лисп.

Посмотрев на Squeak ты поймешь как много туфты выдумало человечество надстраивая Unix вместо того чтобы перепроектировать компьютер вообще.

Авторы SICP вообще это стремное слово не используют в книге ни разу

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

Да, но это отношения к вопросу не имеет. Это замыкание в математическом смысле.

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

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

Но Кложур - не тру Лисп.

Какой тру?

Тру лиспы — это лиспы с динамическим связыванием и фэкспрами. Из современных остались только newlisp и picolisp. С теоретической точки зрения, самые интересные лиспы, ИМХО — это LISP-3 и Planner

Окружения — не значит, обязательно, лексические замыкания

Согласен. Но это не отменяет того факта, что окружения как основа для диспетчеризации по одному аргументу приводят к misconception.

самые интересные лиспы, ИМХО — это LISP-3 и Planner

Ты про 3-Lisp авторства Brian Cantwell Smith? Только вот в его диссертации как раз написано, что dynamic scope не может быть основой рефлективного Лиспа.

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

и фэкспрами

А Kernel?

Можно расшифровать «фекспы» и «Kernel» ?

Какой тру?

Тру Лиспа нет. Есть приближения. CL, например.

диспетчеризации по одному аргументу

о какой диспетчирезации по одному аргументу ты говоришь? Вот тебе диспетчеризация по 2-м аргументам:

(define (object arg1 arg2 arg3)
   (let ((foo arg1)(bar arg2)(baz arg3))
     (let ((dispatcher (lambda(arg1 arg2)
        (cond ((and (eq? arg1 'foo) (eq? arg2 'bar)) baz)
              ((and (eq? arg1 'bar) (eq? arg2 'baz)) foo)
               (#t 'undefined)))))
        dispatcher)))

(define object1 (object 'fooo 'baar 'baaz))
(write (object1 'foo 'bar))
(newline)
(write (object1 'bar 'baz))
;  baaz
;  fooo

И тут в тред врывается эксперт, забывший разлогиниться!

А Kernel существует только на бумаге, пока. Полноценной реализации нет, насколько мне известно.

Можно расшифровать «фекспы» и «Kernel»?

http://en.wikipedia.org/wiki/Fexpr http://web.cs.wpi.edu/~jshutt/kernel.html http://www.nhplace.com/kent/Papers/Special-Forms.html

Когда-то в старых Лиспах была такая специальная форма nlambda. Она создавала функцию, которая принимает невычисленные аргументы. Это и есть фэкспр. В тех старых Лиспах она работала за счет того, что они были основаны на dynamic scope. Когда было осознанно, что dynamic scope - ошибка, фекспры были выброшены. Pitman написал статью где раскритиковал фэкспры. В CL их уже нет. Далее совсем недавно было осознанно, что макросы приводят к некоторым теоретическим проблемам, а фекспры вполне могут работать с некоторыми модификациями в lexical scope. John Shutt предложил очевидное решение - передавать внешнее окружение в фекспр и написал язык Kernel для доказательства концепции.

Фекспры - еще не все. Есть еще так называемые реификаторы Brian Cantwell Smith. Они мощнее.

емнип sql это декларативное, а логическое входит в декларативное, но sql не входит в логическое.

возможно в сабже переводчики накосячили

переводчики конкретно про sql ничего не говорили просто примеры очень похожи.

спс

John Shutt предложил очевидное решение - передавать внешнее окружение в фекспр и написал язык Kernel для доказательства концепции.

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

Я тебе щас попроще объясню, на примерах, а то ведь этот «специалист» о них только в книжках читал, кудахчет, мля, академик, сопли только не высохли.

(define-macro (test x) (let((a 1)(b 2)) (eval x)))
(println (test a)) ; 1
(println (test b)) ; 2
; получили своего рода объект

; вот пример "полезного" применения:
(define-macro (aif it x y) (if it (eval x) (eval y)))

(aif 1 (println it)) ; 1

Пардон, во втором примере eval пропустил. Вот так правильно

(define-macro (aif it x y) (if (eval it) (eval x) (eval y)))

Треш какой-то.

Concepts, Techniques, and Models of Computer Programming — по отзывам, так же является маст хэв для программистов, которые хотят познать больше, кидать дальше. В примерах используется язык Hope.

В примерах используется язык Hope.

Вообще-то Oz.

переводчики конкретно про sql ничего не говорили просто примеры очень похожи.

Ты про эти примеры? При чем тут SQL? Это же типа Prolog.

пролога я не знаю они у меня ассоциируются с sql, но я сам сомневался по этому в общем то и создал этот тред.

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

Когда-то в старых Лиспах была такая специальная форма nlambda. Она создавала функцию, которая принимает невычисленные аргументы. Это и есть фэкспр.

Интересно с этой стороны услышать мнение про ребол.

Concepts, Techniques, and Models of Computer Programming

Плюсую. Книга как раз по запросу топик стартера.

но желательно без привязки к конкретному яп?

Учебник по общей алгебре и/или дискретной математике?

Smalltalk вроде похож на руби

[...]

Интересно с этой стороны услышать мнение про ребол.

С REBOL я не знаком, только пробежался глазами по описанию. Как я понял, там главные идеи - блоки и parse. Если я правильно понял, каждый блок может иметь свой собственный синтаксис. Это так?

Есть такая идея, что один язык программирования может иметь множество синтаксических форм. Например, в Perl 6 функция load принимает на вход грамматику. Это, конечно, хорошо, но только если вы думаете, что синтаксис важен. Я в след за Christopher Strachey (который первым высказал идею о нерелевантности синтаксиса), полагаю, что синтаксис должен быть унифицированным и простым. Таким образом подход REBOL интересен и имеет место быть, но я лично двигаюсь в другом направлении.

с такими мозгами обычно жабу нахваливают.
Правильое ООП в смолтоке и селфе

Можешь пояснить что не так в жабном ООП? Ато я всегда считал его эталонным.

parse и блоки да, это для быстрого создания dsl, я имел ввиду про фекспры, в реболе функция может сама решать какие аргументы вычислять, для каких получить значение (напр функции), а какие зацитировать:

>> g: func ['a b] [             
[    print a 
[    print b
[    ]
>> g (5 + 5) (5 + 5)
5 + 5
10

Слушай, а ты в ребол пробовал?