[philosophy] В чем заключается революционность перехода от функциональщины к ООП?

Плеваться можешь сколько угодно, но нигде я лисповый макрос with-open-file не называл функцией.

Если чё я могу - «Ау, with-open-file енто такая функция» :_:

??? Это с чего вдруг?

Ну, поскольку, в хаскеле нормальных макросов нет, покажу на примере CL.

(defun with-file (thunk &rest open-args)
  (let ((stream))
    (unwind-protect
        (funcall thunk stream)
      (when stream (close stream)))))

;;--------------------------------------------------------
(with-open-file (out "FILENAME" :direction :output)
  (write-line "Hello, world!" out))

(with-file (lambda (out) (write-line "Hello, world!" out))
           "FILENAME" :direction :output)

Ну так скажи, какие?

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

паттерны, в которых есть какие-то определения(типов, структур)

можно примеров таких паттернов?

Тот же with-open-file, скажем, становится обычной фукнцией.

Плеваться можешь сколько угодно, но нигде я лисповый макрос with-open-file не называл функцией.

(with-open-file (in "data.txt")
          (read-and-process-data in))

(macroexpand '(with-open-file (in "data.txt")
          (read-and-process-data in)))
(LET ((IN (OPEN "data.txt")) (#:G973 T))
  (UNWIND-PROTECT
      (MULTIPLE-VALUE-PROG1 (PROGN (READ-AND-PROCESS-DATA IN))
        (SETQ #:G973 NIL))
    (WHEN IN (CLOSE IN :ABORT #:G973))))

становится обычной фукнцией

ГДЕ?

в ней не видны лексические биндинги внешнего окружения

как мне написать что-то вроде state machine

Ну, то, что ты показал - это вообще не State Machine. Это Writer:

myStack =
  execWriter $ do
    tell [1]
    tell [2]
    tell [3]

В переменной myStack будем точно так же иметь [1, 2, 3].

ГДЕ?

Ну, в общем, Лавсан выше показал, как сделать этот паттерн функцией.

(funcall (macro-function 'with-open-file)
        '(nil (in "data.txt") (read in)) nil)
;=>
(WITH-OPEN-STREAM (IN (OPEN "data.txt")) (READ IN))

Т.е. макрос это функция от кода (от AST), возвращающая код (другой AST).

в ней не видны лексические биндинги внешнего окружения

а зачем они там?

При решении более-менее нетривиальных задач «мышление шаблонами» IMHO только повредит

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

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

Ну, красота - это штука относительная, сам посмотри:

withFile "FILENAME" WriteMode $\out -> hPutStrLn out "Hello, world!"

Лишняя сущность... ой, вряд ли. Лямбды только выглядят «сущностями», реально «$\» воспринимается просто как синтаксическая конструкция.

А расходы вряд ли вообще будут, GHC инлайнит со страшной силой (и иммутабельность ему очень помогает).

Но, в общем, твою мысль я понял.

Т.е. макрос это функция от кода (от AST), возвращающая код (другой AST).

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

Макрос - конечно, функция AST -> AST, но не говорить же вместо короткого «функция» длинное «функция-выполняющаяся-только-в-рантайме».

Лямбды только выглядят «сущностями»

В смысле, выглядят, если выделять их длинным словом «lambda».

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

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

а каким оно должно быть?

Ну, разные бывают понимания.

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

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

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

Любопытно, что в издании Большой Галактической Энциклопеции, которому благодаря искажению пространства-времени посчастливилось вернуться из далекого будущего в наши дни, отдел маркетинга сириусианской кибернетической корпорации определяется как “сборище полных кретинов, которых первыми поставили к стенке, когда случилась революция”.

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

Вырисовываются, только далеко не сразу. Сначала идёт период велосипедостроения и костылепроизводства. Вот чтобы не тратить на это время и силы нужно заранее иметь представления об основных приёмах, накопленных предшествующими поколениями. Это вообще то для любой инженерной дисциплины так. Никто не изобретает самолёт с нуля. Все конструкторы пользуются наработанными практиками. Другое дело, что правильное применение, комбинация, модификация паттернов уже сильно зависит от квалификации и опыта инженера. И причём тут математическое образование совершенно непонятно. Можно подумать математики инженерный опыт из астрала черпают. Вообще, нигилистическое отрицание паттернов совсем не красит программиста. Как минимум это свидетельство завышенного ЧСВ и нежелания изучать чужой опыт.

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

да ну синглтон тот же:

(defgeneric instance (class)
  (:method (x)
    (error 'type-error :datum x
           :expected-type '(or class symbol)))
  (:method ((class class))
    (error "~s is not a singleton class" (class-name class)))
  (:method ((class symbol))
    (instance (find-class class))))

(defmacro define-singleton-class
    (name (&rest superclasses) (&rest slots) &rest options)
  (let ((instance-var (gensym)))
    `(progn
       (defvar ,instance-var nil)
       (defclass ,name ,superclasses
         ,slots
         ,@options)
       (setf ,instance-var (make-instance ',name))
       (defmethod instance ((class (eql (find-class ',name))))
         ,instance-var)
       (defmethod make-instance ((class (eql (find-class ',name))) &key)
         ,instance-var)
       (defmethod allocate-instance
           ((class (eql (find-class ',name))) &rest initargs)
         (declare (ignore initargs))
         ,instance-var)
       ',name)))

> да ну синглтон тот же:

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

Там, кстати, не совсем правильно было.

 
(defun with-file (thunk &rest open-args) 
  (let ((stream (apply #'open open-args))) 
    (unwind-protect 
        (funcall thunk stream) 
      (when stream (close stream))))) 

Хотя это чистая инженерия. Отсюда превознесение математики

Гм. А можно заниматься инженерией без математики? Или там доля математики мизерная?

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

(define-singleton-class my-class ()
  ((slot1 :initform "Hello!" :accessor my-class-slot1)))

> А можно заниматься инженерией без математики?

Да почти везде.

Или там доля математики мизерная?

Именно так.

вот у нас есть паттерн синглтон

Начинать надо с этого. Синглтоновый объект - это такой модуль для бедных, если настоящих модулей нет. Или я не прав?

Да почти везде.

Ну, ладно, по мостам больше не хожу, их без математики делали.

И в метро не езжу.

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

> Ну, ладно, по мостам больше не хожу, их без математики делали.

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

Факт в том, что такой вот паттерн(и любой другой подобный, где идет манипуляция определениями)

Какой-нибудь реально полезный паттерн такого рода есть? Который не есть костыль, припёртый к языку из-за отсутствия в нём некоторых фич (это я, кстати, не про Лисп, в нём же, вроде, пакаджи есть?)

> А можно заниматься инженерией без математики? Или там доля математики мизерная?

Представь себе, да. Подробности можешь у архимага узнать, он кажется работал в КБ. Я не говорю, что математика совсем не нужна, но её роль сильно преувеличена. А вот роль паттернов ключевая в любой сфере человеческой деятельности.

Представь себе, да.

Трактор мне, трактор!

>Вообще, нигилистическое отрицание паттернов совсем не красит >программиста.

Нигилистическое отрицание чего-либо вообще никого не красит. Но и критическое осмысление тоже не повредит.

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

применение, комбинация, модификация паттернов уже сильно зависит от >квалификации

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

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

> Подробности можешь у архимага узнать, он кажется работал в КБ.

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

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

Правильно. Только многие почему то до сих пор не могут понять, что индустрия ПО сейчас - это именно что конвейрное производство. Программирование как наука и как искуство давно в прошлом.

> Трактор мне, трактор!

Случился разрыв шаблона?

>Программирование как наука и как искуство давно в прошлом

Очень смелое утверждение

>один занимался проектированием магистральных нефте- и газопроводов

Поинтересуйтесь, что сейчас происходит в мексиканском заливе

проектированием и изготовлением энергетических установок космических >кораблей.

Как интересно! Там не было математики!?

И причём тут математическое образование совершенно непонятно.

Я же написал «постановка задачи» и последующий «анализ». В этом очень много от математики. Или для тебя математика заключается только в интегралах и дифференциалах? Знаем таких ;) Спорить с ними нет никакого резона. Даже интереса нет.

Доля науки в программировании конечно есть, но она мизерная (примерно соответствует доли практикующих хаскелистов в общем количестве программистов)

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

>> Трактор мне, трактор!

Случился разрыв шаблона?

скорей всего паттерн в мозг ударил и как следствие — разрыв шаблона

> Поинтересуйтесь, что сейчас происходит в мексиканском заливе

Вы серьёзно считаете, что игнорирование имевшихся проблем и нарушение технологических процессов связано с плохим знанием математики???

Как интересно! Там не было математики!?

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

> Спорно. Без серьезной математики не было бы современных баз данных.

Не было бы. Но это именно тот мизерный сектор, где она имеет большое значение. Сравните число разработчиков РСУБД и число пользователей. А какая доля пользователей имеет более-менее ясное представление о реляционной теории? Боюсь не очень большая. И такая ситуация является вполне нормальной для индустрии. Есть маленькая площадка фундаментальных исследований, на которой базизуются разработчики инструментария, а подавляющее большинство лишь собирают кирпичики. Причём среди них выделяется группа инженеров-проектировщиков, которым как раз паттерны больше всех нужны. Всё ровно как в любой другой отрасли промышленности. Только вот у рабочих-программистов зачастую слишком высокое мнение о своей роли и способностях. В силу специфики отрасли (обилие бесплатного инструментария) каждый может писать по ночам хелловорлды на хаскеле и ощущать себя крутым учёным. Но как правило средний индус-похапешник уже довольно адекватно воспринимает своё место в мире.

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

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

>Вы серьёзно считаете, что игнорирование имевшихся проблем и нарушение >технологических процессов связано с плохим знанием математики???

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

Этим занимался отдельный небольшой сектор (в котором я и работал), >который носил вспомогательную функцию по обслуживанию конструкторов
(которые реально принимали решения)
Сами конструкторы ни в какой физике/математики, естественно, особо не > разбираются

Очень жаль, что те, кто не разбирается, принимают решения.

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

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

> Напрямую конечно же нет

Не понял, а не напрямую как? Зачем вы это вообще сюда привели?

Очень жаль, что те, кто не разбирается, принимают решения.

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

> Я же написал «постановка задачи» и последующий «анализ». В этом очень много от математики.

Что например? Выделение закономерностей и связей в предметной области? Тут больше знание предметной области пригодится, чем математика. Хотя конечно, базовые познания в мат.логике и дискретке в целом никто не отменял. Для этого, кстати, совершенно не обязательно иметь мат. образование. Вот если предметная область сильно математична, тогда другой разговор. Но опять же, это будет исключительно требование предметной области, а не имманентное свойство программирования.

> А специалист, решающий задачу в некой предметной области

и не знающий математики

Хм, не понял о какой математики идёт речь? Об абстрактной в абстрактной предметной области?

Вообще, вот отличная статья от известного специалиста (в том числе, в математике): http://www.williamspublishing.com/21-days.html - там нет ни слова о важности математики для программистов, Питер не прав?

> Без сомнения. А специалист, решающий задачу в некой предметной области и не знающий математики, так уж ли очевидно осознает, что здесь это нужно?

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

Или просто применит известные ему паттерны? С непредсказуемым результатом?

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

>Не понял, а не напрямую как? Зачем вы это вообще сюда привели?

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

Вы вероятно совершенно не представляете в чём заключается работа >конструктора/проектировщика. Ему нужно принимать множество >различных ?>решений, но лишь небольшая их часть имеет отношение к >физике/математике

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

и вот тогда, он (конструктор) обращается в расчётный и спрашивает «А >что будет, если сделать так? О, отлично, меня это устраивает.

Ни черта не поняв о сути побочных эффектах. И конечно же заявив: „подробности меня не интересуют“. Или что-то похожее

В крайнем случае, он может посоветоваться с расчётным что исправить,
если расчёты дают неудовлетворительный результат

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