• Стиль удава: компиляция на лету

    Для 2.3 работает, для 2.2 вроде нет. Сужу по доступным пакетам: http://pypi.python.org/pypi/By...Если действительно нужно для 2.2, то можно и своими силами сделать.

    И как понимать слова «... несложной умеренно сложной...»?

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

  • Catalyst — Perl веб-фреймворк в лучших традициях MVC

    Спасибо за статью. Есть несколько вопросов.

    А вот, к примеру, Catalyst: Controller: View делегирует запрос пользователя непосредственно в Представление. Таким образом, всю бизнес-логику можно реализовать в Представлении. Но, это уже, немного, извращение.

    Зачем делегировать запрос в V? Также было упомянуто что работой с БД занимается C. Зачем тогда вообще модель в такой системе? Если это считается извращением, то что оно вообще делает в библиотеке? Мне понятно желание схлопнуть разные компоненты, но непонятно зачем тогда изначально брать MVC? Есть ли у вас пример когда одна и та же модель использовалась с разными V и C? Еще интересна история фреймворка: кому, когда и по какой причине захотелось для веб-разработки на Перле использовать MVC? Кроме веба он способен на что-то еще? ORM лежит слоем ниже модели или используется как mixin? Упомянута работа с БД из контроллера. Как в таком случае читает данные модель? Или они читаются только при инициализации? Заранее спасибо за ответы.

  • Catalyst — Perl веб-фреймворк в лучших традициях MVC

    Максим, я надеялся что по вопросам ясно что я знаю что такое MVC, а вопросы относятся к реализации и рекомендуемых подходах в Catalyst. Спасибо за ответы, но зря трудились.Насчет:

    Нет, с БД (или другим источником информации) работает M.

    Так должно бы быть, но автор написал:

    Вот, например, Catalyst: Controller: CRUD реализует код для основных функций чтения/записи в БД.

  • Catalyst — Perl веб-фреймворк в лучших традициях MVC

    Может и базовые, подожду ответы.

  • Catalyst — Perl веб-фреймворк в лучших традициях MVC

    Понял, спасибо.

  • Уникальные технологии Common Lisp (с примерами использования)

    Про уникальность LISP заявление излишне смелое. Например PEAK-Rules является надмножеством CLOS.

  • Уникальные технологии Common Lisp (с примерами использования)

    @Всеволод Дёмкин

    поскольку с Python я знаком лишь теоретически, то хотелось бы, если можно получить более детальный комментарий...В описании PEAK-rules я пока вижу лишь полное повторение CLOS — может я чего-то не заметил?

    Я в свою очередь не пишу на LISP и CLOS не использовал, только читал о. Поэтому могут быть ошибки в сравнении. Насколько я понимаю у CLOS диспатчинг идет по отношениям instance-of и is-a, в PEAK-Rules на данный момент реализованы два движка диспатчинга, второй из них умеет проверять произвольные условия для аргументов, и не смотря на это для разных перегруженных функций определяются конфликты / полная перегрузка, оптимальный порядок проверок и т.д. Кроме того можно определять новые типы методов (помимо стандартных before / when / after / around) для которых можно реализовывать произвольные алгоритмы перегрузок или комбинаций (интересно услышать о том как работает поддержка подобного в LISP, я встречал упоминания что она есть). Также можно реализовать новые движки диспатчинга, инфраструктурой это предусмотрено.Расширение самой библиотеки PEAK-Rules и её движков также реализуется за счет расширения-переопределения её функций (например implies, overrides итд).Подробней можно прочитать в .txt файлах в репозитории.

    А что вы скажете о мета-объектном протоколе: можно ли в Python выбрать то или иное представление класса (чтобы реализовать, например, что-то подобное ContextL) и как это сделать?

    К сожалению сейчас нет времени вникать в ContextL в достаточной мере чтобы ответить наверняка, но судя по тому с чем успел ознакомиться — да, всё это можно реализовать и в какой-то мере реализовано. Вообще я как раз последнее время занимался темой «контекстно-ориентированного» программирования и некоторые решения повторяют описанное, но в целом я тяготею в сторону более явных подходов. На эту тему можно посмотреть например Contextual или мою вариацию на ту же тему (на данный момент несколько устаревшую).Опять таки, задачи, которые я встретил в описаниях, определенно решаются в Python достаточно элегантно.

  • Уникальные технологии Common Lisp (с примерами использования)

    Конечно PEAK-Rules был построен с учетом уроков CLOS и потому разумно повторил его везде где было уместно. Это нужно хотя бы для того чтобы программистам уже знакомым с CLOS не нужно было переучиваться. Я кстати так и знал что разговор придет к Тюринг-полноте, но ведь нельзя говорить что C уникален потому что он первым использовал «C-подобный синтаксис»? Точно также, не отрицая заслуг LISP, нельзя говорить что те или иные его возможности уникальны только потому что они были уникальны 30 лет назад.Насчет того что PEAK-Rules не является частью языка, то я считаю это победой Python. С одной стороны это демонстрирует что то, что в ином языке требует расширения языка, в Python реализуется библиотекой. С другой стороны в Python, как и в любом другом языке с поддержкой ОО есть диспатчинг по типу первого аргумента (а также по его is-a), для минимальных усложнений диспечеризации есть удобное соглашение (опять обратите внимание на легковесность решения) которого обычно хватает (см. radd итп). То что для перехода к CLOS-подобной диспечеризации требуется некоторый скачек это несомненный плюс. Во-первых это усложнение реально требуется не слишком часто, не будь тут никакого барьера код превратился бы в кашу просто потому что слишком многие хотят всё делать как можно мудрее, а не как можно надежнее и проще. Т.е. LISP тут дает дает пушку для стрельбы по воробьям (а стрелять чаще всего надо по ним), никакого менее мощного и опасного инструмента вообще не предлагается. Это вполне в стиле LISP, но это его минус.PEAK-Rules действительно никогда не станет мейнстримом, но это не должно мешать Python быть мейнстримом. В LISP же получается либо всё либо ничего.Изучу ваши ссылки более внимательно и отвечу про отличия / преимущества.

  • Уникальные технологии Common Lisp (с примерами использования)

    Про отличия.Насколько я вижу обычную функцию в LISP нельзя превратить в generic. В P-R можно.Не смог разобраться насколько полно переопределяема в CLOS логика переопределения и комбинации. Например можно ли было сделать call-next-method с нуля? Можно ли сделать аналог before, но с запитыванием его результата в дальнейшую цепочку исполнения тем или иным способом? Например умножить на него результат основного метода; аналогично для их цепочки? Требуется ли для этого содействие остальных типов методов (before / after /...)? В P-R все эти части достаточно высокоуровневые и не являются базисом системы.Публикацию «Predicate Dispatching in the Common Lisp Object System» пролистал. Действительно похоже на реализацию в P-R, но насколько я могу судить там реализовано достаточно малое подмножество того что умеет P-R, во всяком случае я так понял что используется конъюнкция предикатов, никаких деревьев с произвольными узлами. Также не заметил ничего приближающегося к pattern-matching и упорядочивания pattern’ов. Например то что (arg < 0) перегружает (arg < 100), а (0 < arg < 3) и (1 < arg < 4) для arg == 2 конфликтуют.В общем я надеюсь мы уже уяснили что говорить про уникальность технологий Лиспа можно только по незнанию.

  • Уникальные технологии Common Lisp (с примерами использования)

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

    Наверное опечатка и имелось в виду «не важно»? Так что за уникальность тогда? Словарь Ожегова: «Уникальный — Единственный в своем роде, неповторимый».Пример с синтаксисом считаю корректным т.к. речь не о преимуществах, а именно о уникальности.

    Как раз в случае с PEAK-Rules, я так понимаю, дело обстоит иначе — это как раз больше из категории расширений.

    Извините, но нет. Это из категории библиотек.

    А в чем, кстати, опасность CLOS-подобной множественной диспетчиризации?

    В спагетти коде и ненужной сложности понимания реализации и отладки. Подобное кстати можно сказать насчет ООП-фанатизма в Java. Иногда нужна просто функция. Иногда нужен просто метод. Кому-то покажется что того, что они — частный случай GF достаточно для того чтобы иметь в языке только GF, но это математический, а не инжинерный подход и потому в применении к программированию неверный.

    В LISP же получается либо всё либо ничего.

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

    Реализовать можно, но это как раз препятствие к упрощению, а не к усложнению, о чем я и говорил. Это знаете как в анекдоте когда математик предлагал вылить воду из чайника сводя задачу к предыдущей. И вывод вполне логичен, т.к. для использования ООП в Лиспе необходимо изучить CLOS, т.е. кривая обучения ступенчастая — всё или ничего.

    Таким образом, если не хотите стрелять по воробьям из пушки, ограничте себя сами — у вас есть такая возможность, но ни BDFL, ни Microsoft вас не будет ограничивать.

    Тут целый ряд возражений. Вопрос не в том чтобы иметь возможность себя ограничить. А в том чтобы сложность разработки была пропорциональна сложности задачи. Это решается путем предоставления инструментов разной сложности и мощности. Говоря о том что можно ограничить себя самого вы несколько лукавите, это как Микеланджело говорил что для того чтобы создать скульптуру достаточно отсечь от камня всё лишнее. Вроде и верно, но неправда.Далее, говорят о том что их «ограничивает BDFL» как правило самовлюбленные идиоты считающие что знают лучше всех. Не слушайте их. Им бы смотреть на решения более умных и опытных людей и пытаться понять почему так лучше. Им же конечно мешают чужие решения.Да и вообще вся эта идея «лучше сразу максимум, ограничивать потом» сродни тому чтобы раздавать патрульным милиционерам гранаты, и пусть сами решают в кого попадут осколки.

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

    Увы, тут вы попали пальцем в небо. Параметр self есть потому что он есть в любом случае. В любом ОО языке. Делая его неявным (зачем???) мы сразу делаем невозможным ряд манипуляций (например декораторы сразу идут лесом), ухудшаем читаемость кода итд итп. Причем это как раз пример не абстракции принесенной в жертву, а ровно наоборот. В этой проекции функция и метод — одно и то же. Есть огромная практическая польза от того чтобы этот факт был явно выражен в языке. В то же время от обобщения методов до GF больше вреда чем пользы, поэтому возможность «апгрейдить» их в отдельных случаях являет куда лучшим решением. Отдельно хотелось бы услышать о «вот тут и вылазит боком дизайн». Каким таким боком вылазит self, позвольте поинтересоваться?

    Ну и, напоследок, обратите внимание: я не говорил о том, что Lisp является уникальным языком.

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

  • Уникальные технологии Common Lisp (с примерами использования)

    А хорошо ли PEAK-Rules известны даже в Python среде?

    Малоизвестны. Вообще библиотека довольно свежая, но причина скорей в том что GF нужны не очень часто и еще реже являются центральным элементом программы. Разных реализаций GF для Python уйма, есть и новые и старые, тот же RuleDispatch, предшественник PEAK-Rules. Очень часто вместо применения GF используется локальное специализированное решение меньшей мощности, я догадываюсь что это кажется неверным, но это зря, т.к. точно также наверное кажется излишним специализированый синтаксис вместо горы скобочек. Эта неизвестность конечно имеет минусы, но такой баланс я всё равно считаю лучшим чем имеющийся в Лиспе.К слову, можно ли GF в Лиспе расширять замыканиями? Т.е. например синтезировать новые методы и предикаты из данных пользователя и добавлять их к GF во время исполнения?

  • Уникальные технологии Common Lisp (с примерами использования)

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

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

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

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

    Следует ли понимать название статьи как " [Исключительно мощные] технологии [произошедшие из] Common Lisp«? Если так, то не имею возражений.

    Иногда нужна просто функция. Иногда нужен просто метод.

    В Lisp’е все это есть, да и вы сами это, вроде как, должны знать (если писали о том, что нельзя превратить обычную функцию в generic).

    Путаница вышла. В данном случае я имел в виду «классический-ООП-метод».

    Но проблема дублирования информации при определении метода остается.

    Вы о доступе к атрибутам через self.*? Категорически не согласен что это проблема, по-моему никто даже не предлагает от этого избавиться. Если о self среди аргументов, то я не понял с чем вы тогда согласились.

    На счет Микелянджело, милиции и чайников — это уже чистая философия и спорить тут бесполезно.

    Я не спорю и не склоняю к своей точке зрения. С чем-то не согласен, по каким-то вопросам имею мнение и высказываюсь, не более того. Вот насчет того что про милиционеров — философия не согласен. Потому что я сам хоть и умею пользоваться например GF или еще какой мудреной штукой, но при разработке я принимаю решение использовать ли её или нет чтобы быть увереным в дальнейшем что какой-то код делает нечто определенное и не более того, с какими-то гарантиями. Это происходит из осознания своих собственных ограничений, в голове может умещаться не больше какого-то предела. Так что ограничение сложности нужно не только для недостаточно компетентных работников, но и для наиболее эффективной работы вообще. Если такое ограничение сложности требует значительных затрат времени или изучения новых понятий это плохо.

  • Уникальные технологии Common Lisp (с примерами использования)

    В общем, в Lisp’е все то же, что делается во время компиляции, можно делать и во время исполнения (механизм GF, во всяком случае, полностью динамичен). Однако, я не совсем понял, что Вы подразумеваете под «расширением GF замыканиями»

    Я имел в виду использование замыкания в качестве тела GF-метода. Если там всё динамично, значит можно конечно.

  • Уникальные технологии Common Lisp (с примерами использования)

    Декораторы супер-простая штуковина, синтаксический подсластитель. На самом деле можно сказать REAK-Rules был бы возможен в любом случае, но отдельные свойства конечно полагаются на какие-то возможности языка (или, иногда, именно CPython). Он достаточно быстр благодаря компиляции байт-кода на лету (возможность создавать code-objects). Сложные предикаты задаются достаточно просто благодаря синтаксическому разбору и тому что возможна интроспекция функций (для получения имен аргументов). Комбинация происходит благодаря простым соглашениям и отчасти тому, что P-R могут быть применены к собственным внутренностям. Апгрейдить обычные функции до GF можно благодаря тому что функции хранят свой код (code-object) в атрибуте который можно и читать и писать. Т.е. по сути, если язык достаточно динамичен, то всё необходимое для мощных GF в нем есть.

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

    Технологии в языке действительно нет. Что, я повторюсь, является его плюсом, и еще раз показывает что плохому танцору BDFL мешает. Конфликтов или несовместимостей PEAK-Rules с чем либо даже не могу представить. P-R обитает в своей парафии и никуда не вмешивается. Более того, очень весело можно расширять GF обьявляя ООП-метод в классе. Что называется и нашим и вашим.

    @abstractdef getfoo(bar):    passclass C(object):    @when(getfoo) # тут это означает @when(getfoo, (C,))    def getfoo_method(self):        ......

    Имена getfoo / getfoo_method разные только чтобы не путаться в примере.В общем в Python реализация GF не требует «интеграции в языковую среду», а отлично живет как библиотека.

  • Уникальные технологии Common Lisp (с примерами использования)

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

    Я говорил только о том, что плохо если требуется что-то изучать и вообще трудиться для ограничения сложности. Лучше когда это нужно только для её увеличения.

    Но Вы же сами говорите: в PEAK-Rules есть и предикатная диспетчиризация и любой сложности комбинация-методов. Так потому ее в CLOS и нет, чтобы не усложнять простую концепцию. Хотя инструмент для создания этих продвинутых вещей предусмотрен — MOP.

    Отлично! Вот дискуссия и привела к еще одной принципиальной особенности Python-way которую давно пытался найти как обьяснить. Завтра постараюсь написать.

  • Уникальные технологии Common Lisp (с примерами использования)


    На самом деле можно сказать REAK-Rules был бы возможен в любом случае

    Вспомним, хотя бы, Тюринга.:)

    Именно! Именно!

  • Уникальные технологии Common Lisp (с примерами использования)

    В языке Common Lisp есть как минимум 3 инфраструктурных технологии, во многом формирующие подходы к его применению, которые в других языках либо отсутствуют вовсе, либо реализованы в очень ограниченном варианте, либо еще мощнее чем в LISP, только не говорите лисперам, могут озвереть.

  • Уникальные технологии Common Lisp (с примерами использования)

    Виктор, да что вы, конечно если что-то есть в Лиспе, то этого нет больше нигде. Круче только вареные яйца Тюринга.

  • Торбен Майгаард, Ciklum: чтобы добиться успеха нужно работать

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

    Буш! Ты сраный ковбой!...

  • Что послушать ИТ-специалисту — интересные подкасты на русском языке

← Сtrl 1234567 Ctrl →