drupal и plone

[serge]

 

 

https://wordstat.yandex.ru/

 

Что искали со словом «drupal» — 58 622 показа в месяц

Что искали со словом «plone» — 392 показа в месяц

Что искали со словом «wordpress» — 1 436 575 показов в месяц

 

 

Как-то так…

 

____________________________________

Serge73

 

 

 

[Юрий Поляков]

Разработчики Plone сами планомерно, версия за версией, отрезали от себя массовую аудиторию. Происходило это за счет усложнения компонентов и увеличения кол-ва телодвижений, необходимых для простых кастомизаций.

Для долгих проектов это оправдано. Для мелких - уже нет.

Вполне возможно, что это делается сознательно.

Ну и wordstat показывает кол-во показов _объявлений_ директа, а не статистику поиска;

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

-- 
-- 
Russian Plone Group http://ploner.ru/
Для отправки сообщений plon...@googlegroups.com
Новые участники контролируются
Архив и настройки подписки http://groups.google.com/group/plone-ru

--- 
Вы получили это сообщение, поскольку подписаны на группу "Russian Plone Group".
Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес plone-ru+u...@googlegroups.com.
Чтобы настроить другие параметры, перейдите по ссылке https://groups.google.com/d/optout.

[Roman Suzi]

А Plone и не рассчитан на ту же нишу, что wordpress. Что касается "отрезания", так это наверное из-за тяжелого многоуровневого наследия (надежды на работу TTW, чем был силен Plone, не оправдалить, разработчики все равно хотят код и управление версиями, а уж управление конфигурацией у Plone - просто кошмар (http://stackoverflow.com/questions/10570416/plone-4-smarter-generic-setup-updates-needed  ) . Самое разумное, что можно сделать, это просто сравнивать дампы, дабы понять, что было чем заменено. Впрочем, "кошмар" порождается не самим Plone, а сложностью системы и экосистемы вокруг, управление конфигурацией и пакетами - непростая тема сама по себе). Еще я заметил, что прежде, чем устанавливать компонент, нужно посмотреть его код на вшивость. Дабы потом не пришлось какие-нибудь локальные утилиты подчищать при расставании. Но в целом dexterity - шаг в нужном направлении.

Короче, Plone рулез, если умеешь рулить ;-)

[Сергей Грегер]

С управлением версиями проблем как везде. git + buildout рулят. Если версии в setup.py  обновление проходит проще, чем через  GS.

> Впрочем, "кошмар" порождается не самим Plone, а сложностью системы и экосистемы вокруг, управление конфигурацией и пакетами - непростая тема сама по себе

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

28.01.2016 14:28, Roman Suzi пишет:

[Roman Suzi]

Версии ещё куда ни шло (хотя проверок и тестов хватает, что не каждый minor upgrade стоит делать). Я имею в виду все те настройки, которые разбросаны по реестрам и другим инструментам, и с коими GS не всегда знает, что делать. Эта проблема та же, как, скажем, что делать с измененным файлом конфигурации при обновлении сервера (например, Apache), то есть merge - ручная работа.

Такое, похоже, действительно через семантические технологии можно преодолеть (если при этом "предположение об открытости мира" действует ;)

и с поправкой на возможные ошибки и неточности в исходной информации.

[Сергей Грегер]

И преодолеваются достаточно успешно. До управления конфигурацией мы пока не добрались, только потому, что руки не доходят. А без Dexterity  и создания видов  уже обходимся.   Правда это становится уже другой Plone. Если интересно, то предлагаю посмотреть наши  публикации http://ontoprojects.ru/Plone/publikacii

28.01.2016 16:49, Roman Suzi пишет:

[Michael Krishtopa]

Зашёл, увидел дизайн, всплакнул от ностальгии :)

[Сергей Грегер]

форма ничто - содержание все
рабочая лошадь не обязательно красива

28.01.2016 21:12, Michael Krishtopa пишет:

[Roman Suzi]

Кстати, один мой вопрос на похожую http://programmers.stackexchange.com/questions/283837/semantic-web-and-web-ui-impedance-matching "ожил" сегодня. Правда, меня не устраивает то, что содержание впихивается в неважно какую форму. Интересует как раз обратное. Как на основе той общности и изменчивости семантического веба всё-таки выдавать красивый интерфейс (ну, скажем, меня более интересовал интуитивность CRUD на тот момент, но можно обобщить).

[Сергей Грегер]

"Красивый" интерфейс контекстно-зависим, т.е. , на мой взгляд, функция деятельности пользователя и его предпочтений ( собственно, стиль страницы).  Я с недоверием отношусь к понятию семантического веба, как к глобальной семантике. Сейчас я строю GRUD приложения как интерпретацию семантического графа предметной области в контексте конкретной задачи (выраженной графом). Интерпретация - набор правил, формируемых пользователем, определяющих способ представления  входных данных, процесса обработки и результата.  Есть несколько базовых интерпретирующих  агентов.  Наверно, сумбурно.  Я сейчас не рассматриваю сайт как конечный продукт. Это виртуальная машина, генерирующая представление базы знаний и способная с самоизменению при изменении модели этой машины. В общем, змея кусает свой хвост.  

30.01.2016 19:22, Roman Suzi пишет:

[Roman Suzi]

Позволю не согласиться. Под красотой в данном случае понимаю сознательный дизайн, который вводит в продукт единство. Другими словами, красота не в пользовательских настройках, а в замысле дизайнера, который охватывает очень многие аспекты, не только внешний вид или стиль страницы, но и интерактивность, соответствие целям и ожиданиям (явным и эмоциональным) пользователя, и много чего (даже мода в некотором смысле влияет на восприятие продукта). Разумеется, хороший интерфейс контекстно-зависим. Более того, даже пользователи с разными ролями могут на одну и ту же онтологию иметь свой взгляд. Но и эти "метазнания" тоже могут быть представлены (в конце концов, в любом софте это как-то решается, разве что вместо триплетов и правил пишется код на полном по тьюрингу ЯП. В Plone это просто дошло до безобразия, что было накручено столько уровней (надеюсь, начиная с Plone 5 жир несколько обрезан, без ущерба знаниям о предметной области - как получать правильно работающие сайты).

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

[Сергей Грегер]

Я различаю два подхода. Первый я уже описал -классу предметной области  сопоставляется  форма (или другой UI элемент).
Второй  - UI элемент моделируется как класс или композиция предметной области "Пользовательский интерфейс", определяющей интерактивность, стили и все замыслы дизайнера. У Грибовой про это много написано

31.01.2016 0:03, Roman Suzi пишет:

[Сергей Грегер]

"логические системы обычно новой информации не содержат - кто-то должен

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

31.01.2016 0:03, Roman Suzi пишет:

[Сергей Грегер]

31.01.2016 0:03, Roman Suzi пишет:

> В Plone это просто дошло до безобразия, что было накручено столько
> уровней
"В Plone это просто дошло до безобразия, что было накручено столько

уровней ". Думаю, уровней нормальное количествот с точки зрения
проектирования ИС. Проблема в отсутствии инструментов для программиста,
скрывающих частично эти уровни. В частности, зависимости, о которых уже
говорили. Или browser layer. Зачем мне прописывать руками зависимости в
setup.py и в GS? С workflow появился инструментарий, Dexterity, Diazo .
Я вижу необходимость в введение уровня абстракций над этими технологиями
с соответствующими редакторами. Решение чисто программными способами,
т.е. разработка под каждую задачу отдельного пакета - то тупик. Следуя
Фаулеру разработка в Plone, да и во многих других CMS, проводится в
соответствии с паттерном Transaction Scripts. А DDD, MDA только в мечтах

[Roman Suzi]

Наверное, я хотел сказать не только об уровнях, но и о сущностях, коих в компонентной модели слишком много (я имею в виду все эти виды адаптеров и т.п.). А критерий прост: производительность Plone страдает от количества уровней. Не соглашусь, их лишка. Они (как, кстати, многое в мире java) появились чисто органически и нужно только потому, что требовалось абстрагировать нижележащее, а не потому, что именно такой набор наиболее соответствует решаемым задачам. А в совокупности с не очень гибкой структурой легче просто параллельно проложить что-то свое и быстрое. Например, я пробовал использовать registry для хранения конфигурации для страниц (page models) с оверрайдами для конкретных (есть даже продукт для этого). В итоге понял, что теоретически реестр для этого и нужен, но на практике на страницу реестра теперь очень сложно зайти, так как там тысячи отдельных свойств. И других более простых абстракций не хватает. Напрмиер, contentlisting - давно бы так, но хотелось бы и фиды в той же манере и т. д. То есть, сущностей наплодили совершенно неуправляемо. И самое главное из-за отсутствия четких параллелей между действиями thru-the-web, теми же действиями в виде кода и ими же в GS нужно держать в голове много мусора, вспоминая, чему соответствует registry.xml и т.п. Да и доверия к инструментам (тем, что есть, мало) - иногда GS-дамп просто не выходит, нужно сломанную часть убирать (кажется, с portlets такое часто бывает).

Касательно Transaction Scripts - это точно (хотя структура объектов в базе все-таки для DDD хороша). Скрипты слишком выразительны и от этого порождают непредсказуемую систему, кормящую саму себя.

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

Что касается введения уровня абстракции над технологиями Plone - это хорошо, но предварительно нужно все сильно упростить внизу. Сейчас хоть и формально есть plone. и plone.app., оторвать одно от другого проблематично, чтобы хотя бы не бороться с умолчаниями, которые некоторому проекту вредны. Например, в нашей системе вообще не используется этот ужас с folder+default page. Вместо этого просто page, универсальная. Для пользователя так гораздо понятнее. Лишняя сущность удалена.

Но эта критика разумеется пустая, так как такую махину сдвинуть никому не под силу. Ее нужно до основания (хотя бы до ZODB) разобрать и перестроить, используя диктуемые задачами, а не историей развития, абстракции, но сохраняя "опыт, сын ошибок трудных". А если после этого добавить "транслятор" для превращения скинов вордпресс в скины plone - так и вообще. webCMS стали commodity, как файлы офисных пакетов, но пока не на уровне обмена данными.

Кстати, иерархическая структура Plone зачастую плохо вписывается в ментальную модель пользователя, который редко его использует. От этого всё просто кидают в корень...

Про тупиковость разработки пакетов под каждую задачу. Ну да, в каком-то смысле это просто говорит о плохо продуманной архитектуре. В этом плане, например, показателен Odoo (OpenERP). В нем фреймворк предлагает больше, а поэтому пакеты меньше и сфокусированы на своих задачах. (не хочу конечно сказать, что там все идеально). В Plone же каждый пакет на уровне Python, ZCML и GS нужно отдельно подключать (как вы и заметили), а ZCML еще и отдельно meta, overrides, так как они разные проходы, в разное время... Полагаю, что проблему решил бы подход вроде OSGI. Заодно можно было бы легче масштабировать.

Новички в Plone не идут, вот и имеем показы в месяц, что в начале этого обсуждения...

--
--
Russian Plone Group http://ploner.ru/
Для отправки сообщений plon...@googlegroups.com
Новые участники контролируются
Архив и настройки подписки http://groups.google.com/group/plone-ru

--- Вы получили это сообщение, поскольку подписаны на группу Russian Plone Group.

Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес plone-ru+u...@googlegroups.com.

Настройки подписки и доставки писем: https://groups.google.com/d/optout.

[Сергей Грегер]

>>Что касается введения уровня абстракции над технологиями Plone - это хорошо, но предварительно нужно все сильно упростить внизу.

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

>>И других более простых абстракций не хватает.

Именно об этом выше. Правда в семантике наблюдается такой же грех. Введешь абстракцию и начинаешь ее специализировать. Практически в семантический ассемблер сваливаешься. Работу с OWL и RDF  я так и трактую. Семантический ассемблер  необходим. Я его в Plone и сделал и в виде продукта оформил. А дальше можно использовать любую визуалную систему, связывая ее с С.ассемблером  через SOA.  Те. сейчас меня в Plone  привлекает только Zodb и интерфейс манипуляции объектами  для пользователя. Вопрос в другом - кому сегодня такие системы реально нужны. Я уже устал крутится в рамках унифицированной системы создания и управления  базой знаний. Продукты поэтому не выкладываю. На запад много писать сопроводиловок  на англицком придется, у нас в сообществах интереса особого не вижу. Студентам несу вечное семантическое и с радостью наблюдаю когда они эти принципы в других cms  применяют.

31.01.2016 11:26, Roman Suzi пишет:

[Roman Suzi]

Это Вы правильно заметили. Семантический подход - не панацея. И сейчас крупные игроки используют его, так как могут позволить себе нанять кадры, в этом разбирающиеся. Составить хорошую онтологию - дорого и сложно. Часто проще alignment сделать. Есть области, для которых уже есть хорошие онтологии. Например, единицы измерения (QUDT), для сенсорных данных, даже для кое-какой торговли (я не говорю здесь о cyc и других  базах для common sense и высокоуровневых онтологиях). Более того, биохимия/фармакология без онтологий уже просто не может жить. Поэтому, как это ни странно, направление развивается (на рыночных условиях). Еврокомиссия тоже много проектов спонсировала на семантические темы. Так что не бойтесь английского.

Ваше упоминание про метапрограммирование напомнило мне, как я один раз несколько лет назад пытался понять, что у наших клиентов используется. Я просто взял да залил из Plone данные в SWI Prolog (gnu prolog не выдержал), а потом от души делал запросы. Наверное, в конце концов дошёл бы и до генеративного подхода.

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

http://cs.stackexchange.com/questions/35490/mathematical-model-for-a-webpage-layout

Хотя теперь даже W3C новые стандарты по CSS3 в более формальном ключе представляет.

Что касается греха "сваливания в ассемблер", то от этого никуда не уйти. Всегда найдётся надсистема, в которой данная система - элемент. Более того, она всегда нужна для нетривиальных приложений. (не берусь формально доказывать, но это положение вещей скорее всего того же поля ягода, что и теорема Геделя о неполноте).

Если Вы еще не пробовали http://callimachusproject.org/ , может быть, он позволит более эффективно продвигать исследования. Во всяком случае, визуальность там решена, но зато инструменты linked data встроены и если не ошибаюсь поддерживают недавно вышедший стандарт платформы linked data, так что можно избавиться от несущественных деталей и заняться задачами и агентами.

[Сергей Грегер]

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

Но почему нет Вот подборки:
https://yadi.sk/d/1MdPaftRo45Vh
https://yadi.sk/d/RVZgX2d1o45bH
Реализации не полностью открыты, но теории вполне строги.

>>Составить хорошую онтологию - дорого и сложно.

Я предпочитаю легковесные онтологии. А alignment только для интеграции. ISO15926 имеет хорошую онтологию верхнего уровня и группа Левенчука редактор для нее сделали. Но для программиста и тем более пользлвателя это слищком сложно. Т.е. опять нужны уровни абстракции самописные. Сейчас  оптимально: есть проект - я длаю семантический слой, map на систему реализации и все. Наука ради науки уже не прельщает. Да и студент не тот уже. В этом году мне группу не удалось набрать для  этого направления. По хорошему нужен старьап с целью, подобной http://callimachusproject.org/. Но уже куража того нет, Старею..

31.01.2016 17:20, Roman Suzi пишет:

[Roman Suzi]

По всей видимости, узок круг тех, кто видит за этими исследованиями большой потенциал. Куда проще - набрал веб-кодеров, вот тебе и UI, выразил идею или требования, ещё группа кодеров тебе результат. Ну, в крайнем случае перепишут с языка X на язык Y. Поэтому и получается "я делаю семантический слой". Это в промышленности не масштабируется. Ну, примет такого гуру Goldman Suchs, Google, Apple, (впишите своё). На этом всё и заканчивается. В революции никто не заинтересован, кроме подрывных стартапов. В общем, спасибо, буду изучать на досуге.

[Сергей Грегер]

Ну, как говорил В.И.Ленин "Узок круг революционеров". Но наше дело правое. Правда это говорил уже другой персонаж.

31.01.2016 20:42, Roman Suzi пишет:

[Юрий Поляков]

Ленин-то в итоге сделал массовый продукт )

[Сергей Грегер]

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

04.02.2016 15:59, Юрий Поляков пишет:

[Roman Suzi]

Тем не менее, массовый продукт часто не самого лучшего качества: http://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/

[Сергей Грегер]

С точки зрения теории любой  язык отражает онтологию предметной области, которая в голове у разработчика языка. И если  удобно мыслить в этих понятиях - язык удобен. Это, кстати, относится и к парадигмам программирования. Объектно-ориентированный подход - попытка выразить все через концепты предметной области, функциональный - через концепты онтологии задач предметной области, процедурный -  набор базовых связок ПО и задач ПО. Что касается PHP, то он отображает  понимание задач того времени когда он был создан. И его распространение   вызвано скорее влиянием старых редисок, типа меня, которые учат студентов только тому, что знают и к чему привыкли. Если размышлять в типажах статьи, на которую дана ссылка, то пила - удобный инструмент, которому тысячи лет и  миллионы построенных зданий. Однако современные плотники пользуются электрическим инструментом.

18.02.2016 9:20, Roman Suzi пишет:

[Roman Suzi]

Проблема не в том, что вместо пилы используется электроинструмент. Даже "старинная" пила имеет выверенный дизайн. Другими словами, в PHP проблема именно с некачественным дизайном языка, который предъявляет повышенные требования к памяти программиста, ну и все остальные недостатки. Скажем, Python при переходе от 2 к 3 как раз в основном избавился от того небольшого количества "сюрпризов", которое там оказалось. Это понятно - создатели Python с самого начала стремились к этой цели. Что касается "старых редисок", то вовсе с этим не согласен. Думающие люди все время работают над онтологиями в своих головах и проводят рефакторинг. То есть, к старости у них в голове должна быть полнейшая ясность.

[Павел Петлинский]

Боже мой, ну что вы такое говорите, мужчина.

Что за коцепты онтологии?

Что вы называете “функциональный подход”?

В 95 году вышли: Java, Delphi, Ada, Ruby, JavaScript, PHP. Простите, но это _абсолютно_ разные языки. И как же тогда быть с вашей мыслью об отображении PHP задач того времени? Остальные их не отображают? Или это разные задачи? А привязаны ли эти задачи ко времени?

Причина популярности PHP лежит в несколько другой плоскости. И основная - очень низкий порог вхождения(чтобы напилить хелоу ворлд не надо думать)+возможность быстро из всякого собрать веб страничку. А когда хостеры стали его везде ставить - то предложение сформировало спрос (типа “на чем пишем?” - “на пхп, он везде стоит").

С уважением, Петлинский Павел.

[Сергей Грегер]

>>Что за концепты  онтологий?
В работе "В.Э. Вольфенгаген. Аппликативный компьютинг. Попытки установить природу вычислений" автор  вводит понятие аппликативное вычисление:
"Аппликативное вычисление непохоже на обычное. Оно выполняется на переплетении цепочек возможных путей вычислений, которые представляют собой связи конвертируемости, отражающие трансформации объектов. При этом одни объекты могут редуцироваться к другим либо подвергаться экспансии до других объектов."
Далее, рассматривая природу вычислений:
"Аппликативный компьютинг предполагает комбинационное построение вычисления как относительно самостоятельного «блока» с использованием уже имеющихся «блоков» вычислений. Традиционно в состав аппликативных вычислительных систем, или сокращенно АВС, включают системы исчислений объектов, основанные на комбинаторной логике и ламбда-исчислении. Единственное, что существенно разрабатывается в этих системах, — это представление об объекте. В комбинаторной логике единственный мета-оператор — аппликация, или, по иной терминологии, приложение одного объекта к другому. В ламбда-исчислении два мета-оператора — аппликация и функциональная абстракция, позволяющая связывать одну переменную в одном объекте.
Возникающие в этих системах объекты ведут себя как функциональные сущности, имеющие следующие особенности:
— число аргументных мест, или арность объекта, заранее не фиксируется, но проявляет себя постепенно, во взаимодействиях с другими объектами;
— при конструировании составного объекта один из исходных объектов (функция) применяется к другому объекту (аргументу), причем в других контекстах они могут поменяться ролями, то есть функции и аргументы рассматриваются как объекты на равных правах;
— разрешается самоприменимость функций, то есть объект может применяться сам к себе."

Говоря об онтологии задач и о концепте задача  я имел в виду  функциональный объект, обозначаемый часто как задача, и онтологии, классифицирующие задачи конкретной  предметной области.
Способы реализации этого концепта в различных системах программирования свой, в том числе и в PHP.
Про язык.  Одна из причин возникновения синтаксиса PHP состояла в том, что программисты хотели воткнуть куски кода на С++ в НТМL. И это им удалось. Отсюда низкий порог вхождения для  определенной группы людей.  И эти люди стали заказчиками систем с предустановленным PHP. С тех пор многое изменилось. И существуют другие способы проведения вычислений и системы вычислений.  Я писал об этом.
 

18.02.2016 22:23, Павел Петлинский пишет:

[Павел Петлинский]

Мужчина, ну что Вы… Я вам про Фому, вы мне про Ерему.

"Автор вводит”, читаем мы, и поражаемся глубине познаний автора. Простите, но термин “аппликативный” - это унылая попытка перевести английский термин apply на русский. Переводя на русский, это “применить функцию к аргументу”.

Термин “компьютинг” - это вообще за гранью. Прям хоть словарь новоизобретенных терминов прикладывай.

Не стоит пытаться морочить окружающим головы.

Работу просмотрел. Много думал. Например, всю работу пронизывает мысль - “ну, вот можно регистры там всякие использовать и все такое, а были мужики, которые пытались построить LISP машину, построили, а потом их(LISP машины) убил x86, ну тупыыууе”. Видите, кратко, просто, и без зауми.

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

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

Теперь перейдем к вашему письму:

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

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

Простите, но функция - это не задача, а классификатор - ну, тут совсем потерялся.

Рискну предположить, что вся ваша мысль такая - “Шаблоны проектирования в ООП языках и в языках функциональных отличаются”. Простите, но в таком случае - это банальность.

По поводу вставок кусков С++ в HTML - посмешили, что уж там. Пруфф линк, откуда такие мысли про историю PHP? Вот линк  на официальную историю - http://php.net/manual/ru/history.php.php , там такого нет.

Простите, а какие новые способы и системы вычислений появились с 1995 года, не расскажете? А также объясните, что такое “система вычислений”? Поделитесь истиной.

С уважением, Петлинский Павел.

[Сергей Грегер]

Обращение "мужчина" меня настораживает. Так и видится жеманная красотка, пытающаяся привлечь внимание. 
Теперь вопрос - что Вы, Павел,  хотите достичь своей критикой. Показать мою несостоятельность? Я согласен, я не состоятелен. И почти за тридцать лет программирования и преподавания ни на что не годен. Вас это удовлетворило?
Наверно мы с Романом Сузи поступили не правильно, не продолжив общение в личке.  Не видя историю обсуждения нельзя понять всего разговора.  Поэтому,  если есть желание понять точку зрения оппонента - добро пожаловать. Если нет _ ну я уже выше написал. Просто для интереса поищите автора цитируемого текста, познакомьтесь, прежде чем ставить навешивать ярлыки.

19.02.2016 17:07, Павел Петлинский пишет:

[Павел Петлинский]

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

1) Что такое "функциональный объект", дайте пожалуйста определение,

2) Что такое “концепты онтологий”, также, дайте пожалуйста определение,

3) Что такое “концепт задачи”, дайте определение?

4) Откуда вы взяли историю про встраивание С++ в HTML?

5) Что такое “система вычислений”, какого определение этого термина?

6) Какие новые способы проведения вычислений были изобретены с 1995 года?

7) Какие были до 1995 года и были изобретены новые “системы вычислений”?

8) Языки Java, Delphi, Ada, Ruby, JavaScript отображают или нет задачи 1995 года?

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

С уважением, Петлинский Павел.

[Roman Suzi]

Часть понятий есть в Википедии, русской и английской. Системы вычислений из Вольфенгагена. C++ (или скорее C) - видно из синтаксиса и см. PHP#Early history.

Собственно, если задело подпадание PHP под закон Старджона (см. Википедию) - напоминаю, что тема у нас Drupal и Plone - так давайте по существу.

[Сергей Грегер]

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

Окружающих много и они принадлежат разным группам, имеющим свои системы понятий (онтологии). Прежде чем приводить системы понятий друг к другу  следует ответить на вопрос  "зачем"?
С какой целью Вы накладываете на меня "бремя доказательств"?  Мое замечание имело точного адресата. Я уже признал свою вину в том, что отправил ответ не в личку. Вы ворвались в разговор двоих и, судя по перечисленным вопросам, требуете ввести Вас  в курс дела.  Зачем? Чтобы подобно "пикейным жилетам" Ильфа и Петрова вывести заключение "Бриан -голова" и разойтись? Либо убедить меня, что я ни черта не понимаю о том что говорю? Или чтобы закрутить совместный проект?
Давать развернутые ответы я не вижу причины, пока не прояснилась цель разговора. А проводить индивидуальные занятия  бесплатно не намерен. Я не думаю, что именно занятия Вам нужны, хотя вопросы и наводят на такую мысль. Я не склонен следовать девизу Портоса "Дерусь, потому что дерусь", или "Спорю, потому что спорю" в нашем случае. С детства помню фразу из учебника: "Северный олень добывает пищу, разбивая копытом слой льда".
С уважением, Грегер Сергей Эдуардович (и да, мужчина).

19.02.2016 19:02, Павел Петлинский пишет: