5-й номер журнала «Практика функционального программирования»

А тут речи о принципале не было. ;) Хоть о джуниоре тожe...

Всё равно для Токио это немного.

>я правильно понимаю, что CL по этим параметрам эпич^W слил императивщине?


По этим параметрам от параметров жюри зависит. Один тип как-то взялся переписывать код вида a = f(x,f(y,f(z))) в эпический набор ifов потому что там ему «понятно как работает» а тут «нипанятна», ибо «читабельность». Когда я попросил пояснить конкретнее что он имеет ввиду он начал изложение вида «ну с ifами это ясно - если-то значит присвоить, то а иначе если то значит присвоить это».

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

> В нашей Вселенной, наоборот, интерес к Лиспу растёт.

не знаю, че у вас там во вселенной, но у нас на земле количество запросов по слову «lisp» в гугле падает, и уже слово «haskell» его обгоняет

http://www.google.com/trends?q=lisp%2C+haskell&ctab=0&geo=all&date=all&sort=0

Вот пример простенького рисовальщика.

(require «clim»)
(in-package :clim-user)

;; call it with
;; (clim-user::show-painter)

(defclass lines-pane (basic-pane)
((x :initform 0) (y :initform 0) (mouse-pressed :initform nil)))

(defmethod initialize-instance :after ((pane lines-pane) &key &allow-other-keys)
(setf (sheet-enabled-p pane) t))

(defmethod compose-space ((pane lines-pane) &key width height)
(declare (ignore width height))
(make-space-requirement :max-width 100000
:max-height 100000))

(defmethod handle-event ((pane lines-pane)
(event pointer-button-press-event))
(with-slots (x y mouse-pressed) pane
(setf x (pointer-event-x event))
(setf y (pointer-event-y event))
(setf mouse-pressed t)))

(defmethod handle-event ((pane lines-pane)
(event pointer-motion-event))
(with-slots (x y mouse-pressed) pane
(when mouse-pressed
(let ((x2 (pointer-event-x event))
(y2 (pointer-event-y event)))
(draw-line* pane x y x2 y2)
(setf x x2)
(setf y y2)))))

(defmethod handle-event ((pane lines-pane)
(event pointer-button-release-event))
(setf (slot-value pane 'mouse-pressed) nil))

(define-application-frame painter-frame ()
()
(:pane
(clim:make-pane 'lines-pane))
(:geometry :width 400 :height 400))

(defun show-painter ()
(let ((frame (make-application-frame 'painter-frame)))
(run-frame-top-level frame)))

Вот картинка

http://www.frank-buss.de/lisp/beach.png

А теперь, пожалуйста, тоже самое на cl-gtk и пускай люди скажут, где тут Ъ лиспи-стайл.

>один говорит что фукнционала у CL раз в 5-10 больше на строку кода чем у VB

Скажем так - общепринятоте решение вычисления значения из списка (свертывание списка) выражено в абстракции fold(l,r). Подобные же вычисления на VB обычно выражаются в ручных обходах списка. Добавим сюда фильтрацию и трансформацию - и получим три функции foldl/map/filter которые имеют огромное количество аппликаций и с помощью них можно выразить то что на типичном vb-коде выражается этими самыми десятками строк и сотнями.

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

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

я хочу выяснить, сочтешь ли ты язык, на котором решается эта задача, языком с зависимыми типами

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

и да, если лень меня не поборет, предложу ее решение на с++

Успокойся, не предложишь.

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

http://www.google.com/insights/search/#cat=31&q=lisp%2C%20haskell&cmpt=q

>Может быть, может быть. Но зато я сытое и довольное жизнью унылое говно, со своим неправославным bison-ом и еще мнее православным antlr. А функциональщики со своими матанистыми комбанаторами на жизнь озлобленные и голодные.

Борис ты неправ.

>> и да, если лень меня не поборет, предложу ее решение на с++

Успокойся, не предложишь.

гы. ты только добавляешь мне вдохновения :-)

>и да, если лень меня не поборет, предложу ее решение на с++ с вопросом к хаскелистам «а у вас так можно»?

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

>интерес к Лиспу растёт.

Да все изучено еще 10 лет назад никакого развития нет. Хотя да, появились Qi и newLisp.

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

тогда задачу надо как-то подправить; например, допустим, что длина массива — положительное вещественное число

Поздравляю всех с выпуском нового номера.

> Это будет интересно, потому что я пока не вижу способа это сделать.

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

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

>тогда задачу надо как-то подправить; например, допустим, что длина массива — положительное вещественное число

Вещественное? real^Wfloat? Длина массива?

>я вроде как вижу; но хотя это увлекательно, тем не менее сильно напоминает бег в мешках

Гораздо полезнее было бы научить компиляторы делать это для существующего кода :)

> Да все изучено еще 10 лет назад никакого развития нет.

Тогда даже SLIME не было, SBCL был только в проекте, а Clozure CL и не пахло. Т.е. 10 лет назад вообще не было вменяемых инструментов для работы с CL, доступных широким массам разработчиков. Конечно, никакого развития.

Хотя да, появились Qi и newLisp.

Кажется они умерли чуть раньше своих родов, такое случается в природе.

> По этим параметрам от параметров жюри зависит.

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

А теперь, пожалуйста, тоже самое на cl-gtk

Не тоже самое, но простой пример из состава cl-gtk где тоже есть кое-какое рисование:

(defun test ()
  "A simple test of 'on-expose' event"
  (within-main-loop
    (let ((window (make-instance 'gtk-window :type :toplevel :app-paintable t))
          x y)
      (g-signal-connect window "destroy" (lambda (widget)
                                           (declare (ignore widget))
                                           (leave-gtk-main)))
      (g-signal-connect window "motion-notify-event" (lambda (widget event)
                                                       (declare (ignore widget))
                                                       (setf x (event-motion-x event)
                                                             y (event-motion-y event))
                                                       (widget-queue-draw window)))
      (g-signal-connect window "expose-event"
                        (lambda (widget event)
                          (declare (ignore widget event))
                          (let* ((gdk-window (widget-window window))
                                 (gc (graphics-context-new gdk-window))
                                 (layout (widget-create-pango-layout window (format nil "X: ~F~%Y: ~F" x y))))
                            (draw-layout gdk-window gc 0 0 layout)
                            (setf (graphics-context-rgb-fg-color gc) (make-color :red 65535 :green 0 :blue 0))
                            (multiple-value-bind (x y) (drawable-get-size gdk-window)
                              (draw-line gdk-window gc 0 0 x y)))))
      (g-signal-connect window "configure-event"
                        (lambda (widget event)
                          (declare (ignore widget event))
                          (widget-queue-draw window)))
      (widget-show window)
      (push :pointer-motion-mask (gdk-window-events (widget-window window))))))

и пускай люди скажут, где тут Ъ лиспи-стайл.

Твой пример больше всего напомнил мне примеры использовании Canvas в дельфи. А никакого «Ъ лиспи-стайл» в природе не существует, угу.

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

Да нет, вполне можно. Но, конечно, надо исключить жульничество. Скажем, моё решение на Хаскеле (Джаве, Шарпе) - это НЕ зависимые типы, поскольку все массивы вводятся совместно и за совпадением длин мы следим постоянно. Впрочем, в C++ даже так не получится.

> общепринятоте решение вычисления значения из списка (свертывание списка) выражено в абстракции fold(l,r). Подобные же вычисления на VB обычно выражаются в ручных обходах списка.

я не совсем понимаю как это коррелирует с ~900 строками на CL.

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

практика показывает, что холивар CL vs VB в строках кода выглядит иначе ;). как же так?

зы. в треде меня особенно умиляет то, что оппонент именно CL-ю именно VB, о котором отзываются как правило как о языке для деби^W начинающих :). видимо на просторах инета скоро и статьи по этому поводу появятся ))

> Тогда как на C++ десятки тысяч вакансий от $200k p.a.

Т.е. надо понимать, что у Вас 200К в год?

Панрсер на сигнальном протоколе - это ХЗ, лучше бы программы математических расчётов писали.

> Вещественное? real^Wfloat? Длина массива?

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

>Скажем, моё решение на Хаскеле

URL?

The first supported operating system that CMUCL ran on was SunOS. After this port was done by volunteer effort, people outside CMU started to use CMUCL. This was around 1992.

> Скажем, моё решение на Хаскеле (Джаве, Шарпе) - это НЕ зависимые типы, поскольку все массивы вводятся совместно и за совпадением длин мы следим постоянно.

что значит «постоянно»? (я как раз что-то похожее хотел исключить, да формулировка вышла такой непонятной, что я ее писать не стал)

> The first supported operating system that CMUCL ran on was SunOS. After this port was done by volunteer effort, people outside CMU started to use CMUCL. This was around 1992.

Этим ты что пытаешься опровергнуть, а то такое ощущение, что ты вообще не понимаешь, о чем говоришь.

> URL?

пока что мы обсуждаем задачу, а не решения

мигель имел в виду «предполагаемое решение»

* вероятно имел в виду

> The first supported operating system that CMUCL ran on was SunOS.

Надеюсь ты не будешь утверждать, что CMUCL это вменяемый инструмент? который был доступен широким массам?

>да, как-нить (почти отбалды) определить такую длину, лишь бы там там целые числа не стояли и при конкатенации длины складывались

Вот тебе идея вокруг (hlist) в реализации на скале
http://jnordenberg.blogspot.com/2008/08/hlist-in-scala.html

Там правда про гетерогенный тайпсейф список, но все же по теме.

Но это как бы все-таки читинг:)

and SunOS + hardware were freely available to everyone? in 1992?

«Ъ лиспи-стайл»

Если ты не заметил это CLOS в чистом виде, если я не все еще забыл.

Определяется метод handle-event. А специализация идет по типу event. который интересен.

А тут вроде обязательно надо обрабатывать события типа expose, сonfigure. Вроде как это уже уровень Хlib, вся абстракция слилась.

> Определяется метод handle-event. А специализация идет по

типу event. который интересен.

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

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

> А тут вроде обязательно надо обрабатывать события типа expose, сonfigure. Вроде как это уже уровень Хlib, вся абстракция слилась.

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

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

университетский

не любой человек с улицы

вот поэтому и имеем то, что имеем

а когда пистон появился/стал популярным, тогда железо было доступно _всем_. Просто ЛИСП опередил свое время. И до сих пор впереди планеты всей.

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

да, кстати в США, высшее образование в университетах некоторым до сих пор не доступно.

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

Ну вообще-то я говорил, что «популярность Лиспа растёт», а не твоё «Хаскель становится популярней Лиспа». Разница ведь есть, не правда ли?

А в клос обернуть всегда можно и просто.

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

Да все изучено еще 10 лет назад никакого развития нет. Хотя да, появились Qi и newLisp.

Популярность - это частота применения. К CS популярность имеет отношение перпендикулярное.

> История проекта mcCLIM показывает, что это не просто, даже при

наличие готовой спецификации и работающих коммерческих реализациях.

Эта история показывает следующее:
* Тяжело притащить за уши спецификацию, корни которой уходят в те
времена, когда компьютеры были большими, на современные средства
разработки GUI
* Тяжело писать отталкиваясь только от Xlib
* CLIM не нужен, ибо просто архаичен.
* Не смотря ни на что, он таки работает, просто уродлив и страшен

> Ну вообще-то я говорил, что «популярность Лиспа растёт», а не твоё «Хаскель становится популярней Лиспа». Разница ведь есть, не правда ли?

а ты на картинку хоть глянул? там период полупотери интереса к лиспу (а-ля период полураспада) около 2.5 лет

гы. ты только добавляешь мне вдохновения :-)

Извини, мозгов не получается.

хотя наверно ближе к 3 годам

длина массива — положительное вещественное число

?????

да, кстати в США, высшее образование в университетах некоторым до сих пор не доступно.

Да при чем тут вообще это? Я хотел сказать, что еще 18 лет назад уже была свободная законченная реализация лиспа, на основе кода которой и начался проект sbcl, а не 10 лет назад как пытался представить г-н archimag.