LINUX.ORG.RU

вопрос по sicp


3

5

Глава 4.4.1 Логическое программирование, дедуктивный поиск информации.

Я правильно понимаю что sql это пример яп для логического программирования?

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

★★★★★

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

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

terminator-101 ()

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

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

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

terminator-101 ()

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Pinkbyte ★★★★★ ()

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

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

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

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

TDrive ★★★★★ ()
Последнее исправление: TDrive (всего исправлений: 1)

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

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

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

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

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

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

Christopher Strachey. «Fundamental Concepts in Programming Languages.»

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Какой тру?

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

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

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

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

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

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

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

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

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

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

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

о какой диспетчирезации по одному аргументу ты говоришь? Вот тебе диспетчеризация по 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

Что, от этого быдляцкое ооп стало менее быдляцким говном?

terminator-101 ()
Ответ на: комментарий от terminator-101

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

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

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

terminator-101 ()
Ответ на: комментарий от TDrive

Можно расшифровать «фекспы» и «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. Они мощнее.

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

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

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

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

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

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

terminator-101 ()
Ответ на: комментарий от TDrive

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


(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

terminator-101 ()
Ответ на: комментарий от terminator-101

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

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

terminator-101 ()
Ответ на: комментарий от TDrive

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

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

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

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

TDrive ★★★★★ ()
Последнее исправление: TDrive (всего исправлений: 1)

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

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

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

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

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

Concepts, Techniques, and Models of Computer Programming

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

anonymous ()

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

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

no-such-file ★★★★★ ()
Последнее исправление: no-such-file (всего исправлений: 1)
Ответ на: комментарий от loz

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

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

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

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

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

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

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

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

>> g: func ['a b] [             
[    print a 
[    print b
[    ]
>> g (5 + 5) (5 + 5)
5 + 5
10
loz ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.