Небесный путь в PHP

Идею проекта SKY можно излагать по разному, но самое короткое и простое изложение следующее. В интернете существует много сайтов, сила которых в основном обусловлена текстовым и фото-видео контентом пользователей, но нет ни одного, сила которого бы была обусловлена кодом пользователей. Уточню: конечно, есть сайты сохраняющие код пользователей, например «packagist.org», но нет ни одного, которые бы могли достигнуть уровня популярности социальной сети в отношении кодового контента (назовем это цель X), в котором ведется активный скрупулезный анализ всех деталей кода многими участниками. Так сайт packagist сопоставим с проектом SKY, достигшем цели X, также, как можно сопоставить любую инсталляцию форума phpbb с сайтом Facebook. В данный момент проект SKY мало известен, но возможна ли указанная популярность? Моё мнение – конечно, и ключ к этому — простота, следование принципам KISS в дизайне кода. Имхо, и php достиг высокой популярности, в первую очередь, благодаря простоте.

Вообще, я считаю «верный путь в php» большой досадной ошибкой. Точнее некоторые его важные фундаментальные принципы. Писать код в глобальную область видимости и использовать eval() в коде нужно шире, как это делается в SKY framework. По крайней мере, дорогой читатель, я надеюсь, что вы допускаете разумность существования двух путей, а уж какой путь истинно верен, только время способно показать. Часто новое это хорошо забытое старое, прошу вас, не торопитесь думать, что «SKY way» это бесперспективное прошлое.

Простые вещи всегда имеют больший потенциал для развития, чем сложные. «SKY way» это наилучшая основа, дающая возможность реализовать идею проекта, в котором «сила сайта» была бы обусловлена кодом пользователей проекта, когда уровень развития сайта сопоставим с социальной сетью, но только где контент — код.

«SKY way» образует некоторые небольшие запросы к изменениям в php в текущий момент, например, хорошо бы было иметь функции: get_context($deep) и filter_context($array). Первая бы выдавала массив переменных соответствующих контексту уровня глубины, где $deep = 0 — свой контекст переменных, 1 — контекст уровня вызова функции, в которой находится код get_context(1). Возвращаемый массив — такой же, как и для callback функции для set_error_handler(). Вторая бы фильтровала массив, для вывода на экран программиста и анализа им переменных, при этом, например $GLOBALS, не должна быть показана в «чистом» виде, но лишь в сокращенном. «SKY way» не следует принципу изолирования, когда программист просто не использует глобальную область видимости для переменных, чтобы избежать нечаянного их переопределения в процессе разработки. Вместо этого, в «SKY way» имеются специальные средства, чтобы не допустить такие ошибки, в частности, например используя вышеуказанную функцию get_context(). Принцип изолирования и другие принципы, которые используются, например в Symfony и других популярных в данный момент Framework, приводят к слишком высокому уровню сложности архитектуры, в сравнении с «SKY way».

Второй пример. Чтобы избежать ошибок второго рода, классически, рекомендуется просто не использовать eval(). Но если аргументом для eval() есть код, находящийся в константе — нет абсолютно никакой опасности в использовании eval(). Однако, все равно, не рекомендуется использовать eval(), рекомендуется опасаться его «как огня». В «SKY way» такая логика считается ошибочной. Альтернативы для eval() нет. Наоборот, та альтернатива, которая используется в Symfony и Framework со сходной архитектурой, считается сомнительной, когда eval() не используются широко, так как, подобный путь слишком увеличивает сложность. Усложнять архитектуру кода для повторного использования (КПИ) на PHP, все равно, что, «пилить сук на котором сидишь». Но можно ли использовать eval() не опасаясь подвергнуть приложения риску? Можно. Можно, например, при использовании eval() выдавать ошибку PHP WARNING, когда достоверно неизвестно о безопасном использовании eval(), в остальных случаях не выдавать ошибку. Также можно, например, в Framework, сделать реестр использования eval(), чтобы привлечь внимание разработчиков к этим местам в коде или использовать комбинированный, гармоничный с самим PHP способ. Я подразумеваю, что реестр содержит текстовые описания гарантий безопасности. Кстати, можно представить ситуацию, когда начинающий программист не знает об опасности eval(), а наличие реестра, акцентирует его внимание и он благодаря этому избежит ошибок безопасности.

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

В проекте SKY уделяется огромное внимание потенциальной частоте использования КПИ на реальных веб-приложениях. Так ядро SKY Framework (потенциально наиболее часто употребимый код), составляют всего лишь три файла, размером около 50 Kbytes и именно этот код должен быть подвержен максимальной кристаллизации сообществом. Гибкость кода, в том числе ядра, выбирается более низкой, в сравнении, например с гибкостью компонентов Symfony.

Ввиду ультимативного преследования принципов KISS, в SKY многие решения не типичны или даже противоположны тем, которые приняты сообществом, поддерживающим «верный путь в PHP»:

1) нет необходимости использовать (по крайней мере, как базовые средства разработки) технологии в Framework:

а) роутинг страниц, как механизм излишен. Реально нужные задачи, которые им решаются, легко реализовать простыми манипуляциями в коде приложения.
б) ORM как механизм излишен. Нет необходимости «делать обертку» для и без того лаконичного языка SQL.
в) Компилируемые шаблоны излишни. PHP сам по себе предоставляет достаточно средств, чтобы использовать PHP шаблоны с самым высоким качеством.
г) Механизм NAMESPACE излишен. Он решает задачу этапа разработки, на этапе выполнения, в том числе на production инсталляциях, что само по себе даже неверно логически.
д) и т. д. нет необходимости сейчас все вспоминать и перечислять…

2) В SKY уделяется гораздо большее внимание этапу разработки. В SKY все старается быть гармоничным, как окружающий мир. SKY Framework поставляется вместе с веб-приложением DEV.SKY, ориентированным на решение задач этапа разработки в гораздо большей мере, чем например, консольная утилита Symfony. Я бы сказал, что в SKY, «сапожник имеет сапоги».

3) нет папки vendor. Требуется переработка классов на packagist в соответствии с идеологией SKY. В SKY допускается (но, конечно, стараемся избегать) редактирование КПИ, в том числе ядра, разработчиками приложений. Во-первых есть стандартные средства для изменений кода ядра (с помощью приложения DEV.SKY) — получения из «чистого облака» кода «облачной модификации», это позволяет заменить высокий уровень гибкости компонентов Symfony, SKY-решением. «Чистое облако» это термин проекта SKY, характеризующий условно идеальный КПИ, потенциально способный стать полноценной заменой для не менее чем 70% сайтов реально существующих в Интернете. Во-вторых, обновления кода ядра, просто часто не требуется, ввиду того что он мал, прозрачен и кристаллизирован. В-третьих, обновления кода ядра, остаются возможными путем слития (ручного разрешения коллизий) и не представляют трудностей из-за того, что код мал и прост. Также обновления редки, ввиду того, что код кристаллизирован (идеален). В четвертых, стараться «уходить» от обновлений это скорее хорошо, чем плохо. Нельзя быть уверенным в постоянной благонадежности доверительных источников, нехорошо тратить личное время на обновления заведомо не идеального кода.

4) Вместо packagist, код третьего крыла, как и ядро SKY, хранится в БД кода, на том же сайте, в том же проекте SKY. Нет смысла собирать более 100К классов на PHP как на packagist, вместо этого, имеет смысл иметь гораздо меньшее кол-во классов на coresky.net, но подвергать код кристаллизации, постоянному совершенствованию. Не нужно иметь альтернативные решения на packagist, лучше иметь единые идеальные решения. В проекте SKY будет цениться умная мысль даже анонимного пользователя, с помощью пирамидальной системы рейтингов и бонусов. Любой участник системы будет способен легко влиять на любой код КПИ в SKY, если имеет ценные мысли.

5) и т. д. нет необходимости сейчас все вспоминать и перечислять…

На этом сайте, habrahabr, я иногда встречаю статьи подобные этой: PHP: фрактал плохого дизайна. Эта статья — интересная работа, но минус автору за то, что он не сделал анализ «железобетонного факта», не ответил на вопрос — почему язык PHP является ведущим в области веб разработки. Без такого анализа статья видится как «плач вопиющего..». Даже если автор написал эту статью без специального заказа от создателей конкурирующих языков, она имеет 100% рекламный (анти-рекламный) характер. Кстати, мое мнение: язык PHP похож на простой C/C++ с возможностями языка высокого уровня, именно этот факт, первую очередь, а не верная маркетинговая стратегия или что-либо иное, принесло ему, имеющуюся популярность. Важна также возможность расширения языка с помощью модулей «extension», написанных на C и удачное время начала разработки. Автор хвалит Perl, но Perl был раньше и проиграл в популярности, это факт. Подобно этой статье, предлагающей напрочь отказаться от PHP, я рассматриваю «верный путь в PHP», как подобный, но еще более тонкий маркетинговый ход, предлагающий напрочь отказаться от других подходов с целью использовать только этот. Мне видится, существующая в данный момент, к сожалению, большая «армия» профессионалов, поддерживающая «правильный путь в PHP» и небольшое количество профессионалов, чувствующих что в «правильном пути» что-то не так, к вторым, я отношу и себя. Первых я прошу не быть категоричными в убеждениях, позволить существовать «небесному пути», вторых я приглашаю на проект для более детального изучения того, что имеется уже сейчас в проекте SKY.

Еще я встречаю статьи подобные этой: PHP: неправильный путь. Имхо, это все — робкие попытки «армии меньшинства» сказать «правильный путь в PHP», на самом деле, не верен. В этой статье приводится фраза:
Но даже KISS может стать угрозой для проекта, если довести его до абсурда.

Мысль верная, но мне не нравится угол рассмотрения. Я бы сказал так: при совершенно определенной постановке задачи нужно всегда придерживаться принципов KISS. Просто, дело в том, что сделать безошибочную, совершенно определенную постановку задачи в области программирования бывает также трудно как и выполнить саму задачу. Выполняя задачу, разработчики часто принимают решения, которые могли бы присутствовать в постановке задачи и это было бы хорошо, как для того кто ставит задачу, так и для того кто ее выполняет. Использовать сложное решение, в то время, когда можно применить простое, равносильно выбрасыванию денег на ветер. В масштабе человечества, сложные решения вносят чрезвычайно большие потери разных ресурсов.

В заключении хочу отметить, что эта статья и проект SKY не только о создании веб-приложений на PHP. При достижении цели X, последствия будут невообразимы, это:

а) создание свободного идеального КПИ как для веб-разработки, но также и для другого программирования. Создание формального подхода для получения идеального кода не только для веб.

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

в) возможно создание контролируемого искусственного интеллекта, в отличие от недавно прозвучавшего в новостях DEEPMIND, который, несмотря на принятый «комитет по этике ИИ», вероятно работает по принципу «черный ящик» и вероятно представляет угрозу. Нельзя создать ИИ типа «черный ящик», чтобы он был безопасен. Хакеры знают как можно «взломать все», но если ИИ будет умнее людей, он также, обязательно вырвется на свободу. Эта проблема сродни проблеме CO2 в атмосфере и глобальному потеплению: все всё понимают, но продолжают ездить на бензине, также же и с ИИ: хочется сделать первый раз неважно какой, но реально работающий.

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

Все ли Вам нравится в «верном пути PHP» и современных трендовых фреймворк?
Поделиться публикацией
Ой, у вас баннер убежал!

Ну. И что?
Реклама
Комментарии 269
  • +16
    Что то я совсем ничего не понял (кроме того что глобальные переменные и eval это хорошо, а фреймворки — плохо). Наверное, проект SKY просто опережает свое время…
    • +19
      > но нет ни одного, сила которого бы была обусловлена кодом пользователей

      https://github.com/
      • +5
        Это статья для конкурса NaNoGenMo? Тянет на призовое место.
        • +3
          Было очень тяжело читать. А автору стоит вспомнить о том, что PHP — это не только про сайты (сайты в том понимании, в котором они упоминаются в тексте статьи).
          • –3
            Что вы имеете ввиду? Консольные скрипты? Не понял вашу мысль, можно подробнее?
            • 0
              На PHP давно пишут полноценные программы не связанные с сайтами в обычном понятии.
              К примеру из моего опыта — банковская, кассовая и транзакционная CRM, система бронирования клиент-брокер-отель, алгоритмы прокладки маршрутов между пунктами назначения по дорогам и много чего другого.
              • 0
                М-да… А что такое CRM? Не веб ли приложение? Те приложения, которые ориентированны для работы в локальных сетях или на локалхосте даже, не имеюют ли часто demo в паблике? Я употребил слово «сайт» где-то, вместо «веб-приложения» и это вас ввело в конфуз? От чего же?
          • +20
            Статья напоминает дамп мозговой деятельности PHP програмиста в момент погружения в сон
            • +2
              Фух, а я думал, что я один ещё не проснулся, чтобы понять смысл вышеизложенного…
              • +1
                Самая точная рецензия к этой статье! Спасибо, давно так не смеялся
              • 0
                Мне кажется, что ваш проект SKY еще в начале пути, во всяком случае вы позиционируете его как php-ядро для создания сайтов, а сам ваш сайт по уровню, честно говоря, слабоват (на мой взгляд).
                Но сама идея у вас очень и очень интересная, поэтому спокойно относитесь к критике — у вашего проекта есть и достаточный потенциал, и хорошие перспективы.
              • 0
                > Имхо, и php достиг высокой популярности, в первую очередь, благодаря простоте.
                Этого не достаточно. Технология формируется не новичками, а теми, кто в ней закрепился.

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

                Сила PHP в его мощной экосмистеме и свободе выбора. PHP очень умело балансирует между ruby с python и java с C#, попадая в обе ниши. Здесь вам и возможность написать страничку в пару строк, и сильная статическая типизация (тайпхинтинг), важная для крупных проектов.
                • 0
                  Я согласен — PHP богат, но он и прост как никакой другой
                  • +2
                    Прост для обучения азам, но крайне сложен для понимания полностью. Я считаю себя довольно опытным, но до сих пор полностью не осознаю что конкретно делает метод `send()` у оператора `yield` и почему это заставляет конструкцию `$value = yield $key => $val;` пропускать один «тик» отдачи данных.

                    Может вы ответите, раз считаете себя переросшим большинство профессионалов, которые писали Right Way (оригинальный), пройдя все терни языка?
                    • –10
                      Я не PHP сюда пришел преподавать, ваш вопрос — оффтоп, но отвечу так и быть: yeild не имеет ничего общего с тиками. Их логика совершенно не взаимосвязана. И если «пропускается тик» то это просто кандидат в «todo list» разработчикам PHP, это просто их недоработка. И в этом ничего сложного нет, если вы программируете на симфони и не понимаете этого, то мне жаль ваших заказчиков. Несмотря на неоспоримые достоинства языка PHP — посмотрите за занавес и прочтите статью PHP: фрактал плохого дизайна
                • НЛО прилетело и опубликовало эту надпись здесь
                  • –2
                    Все термины нужны, а предостережение есть см. http://ru.coresky.net/roots?id33 Там написано:
                    Нужно стараться вносить как можно меньше новых терминов, чтобы читателю не приходилось искать их значения. Тем не менее…
                    • +4
                      А мне показалось, что все гармонично. И код, и статьи, ммммм, соответствуют нестандартному мышлению автора.
                    • +4
                      нет необходимости использовать (по крайней мере, как базовые средства разработки) технологии в Framework

                      роутинг страниц, как механизм излишен.

                      ORM как механизм излишен

                      Компилируемые шаблоны излишни

                      Механизм NAMESPACE излишен.


                      Интересно, а вот скажем классы — они тоже излишни? Может тогда просто сразу вернемся к четвертому PHP? Там ведь ничего лишнего — 100% соответствие идеологии SKY. Да ну его все… К чему эти излишние всякие там паблики, статики, трэйты и интерфейсы. Только вносят путанницу.Ну правильно? Писали ведь на четвертом PHP и все было предельно ясно и просто. Ну полный SKY в общем.
                      • –5
                        ООП — величайшее достижение в программировании. Практически весь код третьего крыла должен быть написан с использованием классов, так как логически неверно выполнять редко используемый код в процедурном стиле. В коде coresky (3 файла о которых я писал) также есть 4 класса. А вот запросы к БД лучше делать с помощью функции-обертки sql(), так как она чрезвычайно часто используется. А вот, когда фреймворк предлагает использовать метод класса для запросов к БД — это идеологическая прихоть, имеющая мало общего с объективной реальностью. Разработчики языка могли бы просто выделить имена, которые можно применять для функций фреймворк, с той целью, чтобы они никогда не пересеклись с новой версией языка. Это сделать им чрезвычайно просто. Просто задекларировать у себя на сайте.
                        • 0
                          появление ORM прямое следствие популярности ООП и РСУБД. Это мост между ними.
                          • 0
                            Это круто… А практическая необходимость в чем?
                            Вот вы работали раньше без ORM и было ужасно плохо… можете объяснить в чем были сложности?
                            • +1

                              Сложность в том, что надо писать весь этот избыточный SQL-код, помнить как названы объекты в БД, писать код, который преобразует обратно результат в тот, который нужен программе… И все это, конечно же, без поддержки компилятора.


                              Зачем, когда можно просто написать вот так:


                              var searchResult = _db.Books.Where(b => b.Author.BirthDate.Year < 1970).GroupBy(b => b.Author);
                              • 0

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


                                ИМХО
                                ламбды (безымянные функции, да и класы) не попадают под "сильную" типизацию. Если же их писать с типизацией — получается больше кода и теряется преимущество синтаксического сахара.


                                Либо надо создавать "супер сильную типизацию". Где компилятор (и ИДЕ) сможет по определению function Where(f(b: Book): Boolean) проверить ...Where(b => b.Year < 88) на валидность.

                                • 0
                                  а в вашем коде надо помнить, что поле авторов у обьекта книга, называется Author.

                                  Не надо. Автодополнение вполне работает.


                                  ламбды (безымянные функции, да и класы) не попадают под "сильную" типизацию.

                                  Почему не попадают-то? Код выше полностью типизированный.


                                  Где компилятор (и ИДЕ) сможет по определению function Where(f(b: Book): Boolean) проверить ...Where(b => b.Year < 88) на валидность.

                                  Что значит "проверить на валидность"?

                                  • 0
                                    Что значит «проверить на валидность»?

                                    Вопрос становится неактуальным, когда понимаешь, что лямбда типизированная
                                    • 0

                                      Ну… мало ли, человек хочет, чтобы конструкция Where(x => x > 99).Where(x => x < 99) не компилировалась или автоматически оптимизировалась в пустой итератор.

                                  • 0
                                    зануда мод: а в вашем коде надо помнить, что поле авторов у обьекта книга, называется Author.
                                    ламбды (безымянные функции, да и класы) не попадают под «сильную» типизацию. Если же их писать с типизацией — получается больше кода и теряется преимущество синтаксического сахара.


                                    Рекомендую вам пописать на C# в хорошей IDE, мурашки по коже пойдут) Лямбды вполне типизируются и типы выводятся автоматически (это ведь довольно просто) так, как очень часто в Generic'ах.

                                    Посмотрите на исходники Linq:
                                    public static IEnumerable<TSource> Where<TSource>( // 1
                                        this IEnumerable<TSource> source, // 2
                                        Func<TSource, bool> predicate) // 3
                                    


                                    Строка 3 означает, что лямбда обязана принимать на вход тип TSource (тот же, что в IEnumerable), а на выход давать bool. Так и типизируется.
                                • +2
                                  Изоляция объектной модели от способа хранения — это не необходимость, но это упрощает разработку, поддержку и развитие. Написать, что угодно можно в машинных кодах, но гораздо проще и дешевле писать с использованием более высокоуровневых средств.

                                  Без ORM я работал когда толком и ООП не использовал. Как только начал использовать, то идея что гораздо лучше будет маппить записи БД на объекты модели и наоборот, чем продолжать работать на уровне бизнес-логики и представления с массивами, возвращаемыми mysql_fetch_assoc и(или) генерировать SQL на этих уровнях, возникла практически сразу — это упрощает отслеживание и управление взаимосвязями сущностей приложения. Теперь мне не надо думать о способе хранения данных, когда я реализую бизнес-логику или представление, у меня просто есть граф объектов, с которым я работаю. А когда работаю на уровне логики хранения мне не надо думать о том, как изменения в ней могут повлиять на остальной код, логика хранения на вход команд принимает граф объектов и на выходе запросов отдаёт граф объектов.
                              • 0

                                … а какие парадигмы программирования, кроме ООП и процедурной, вы лично пробовали и знаете на уровне, достаточном, чтобы утверждать, что ООП — величайшее достижение?

                                • –9
                                  При работе в проекте SKY, я пользуюсь беспрецендентной логикой, и глубоким пониманием того, что делаю. Большинство же из вас не понимает глубоко что делают, а просто следуют указанием «умных учителей». Прошу вас, не пишите глупостей, ставя (может быть и с сарказмом) под сомнение то, что ООП величайшее достижение. ООП должно применяться — там где должно, и не где попало… По этому поводу хорошо написано в статье: PHP: неправильный путь.
                                  • +4

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


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

                                    • 0
                                      Величайшее достижение? А вы пробовали ФП?
                                      (я, пожалуй, заострю внимание — именно функциональное, а не процедурное)
                                      • –6
                                        вы меня простите, ваш вопрос оффтоп. Он далеко уходит за пределы темы статьи.
                                        • +2
                                          А в каком месте оффтоп-то? Вопрос относится не к статье, а к вашему смелому утверждению «ООП — величайшее достижение».

                                          Это еще при том, что я закрыл глаза на заявление «Большинство же из вас не понимает глубоко что делают, а просто следуют указанием «умных учителей». », ибо не ведаете что творите.
                                        • 0
                                          А вы пробовали ФП?

                                          А вы? Без ооп и для чего-то крупного, с длительной поддержкой и реальными пользователями.
                                          • 0
                                            Да, всю жизнь гонялся за ООП. А, в целом, и сейчас приходится. Но мне системы, написанные, ну например на том же OCaml или Haskell, кажутся гораздо более элегантными и лаконичными.

                                            Сфера деятельности мне позволяет, например, использовать в работе Elm и Purescript, которые всецело опираются на Haskell. И код действительно становится проще и предсказуемей.
                                            Хотя, к сожалению, резко повышается порог входа для поиска сотрудников.
                                            • 0
                                              Простите, я не понял ваш ответ. Спрошу еще раз. У вас есть продукт, который был написать исключительно на ФП, он достаточно крупный и не тривиальный, он развивался эволюционно (как большинство сложного софта сейчас), его использует или использовало множество пользователей (потому что писать для себя и для пользователей — разные вещи)? Если да, то дайте ссылочку, пожалуйста
                                              • 0

                                                В вашем комментарии сквозит намек на то что ФП менее удобен для больших проектов и масштабируемых систем. Непонятно откуда взялся этот стереотип, возможно из за JS к которому пока неуклюже пытаются придать функциональную парадигму некоторые фреймворки. Сами идеи ФП такие как неизменяемость состояний и чистые функции как раз и располагают к написанию более поддерживаемых больших и сложных систем. Как эти идеи представлены в конкретных языках, вопрос другой. Что касается вашего вопроса про массовый продукт реализованный исключительно с использованием ФП то как вам пример Riemann?

                                                • 0
                                                  В вашем комментарии сквозит намек на то что ФП менее удобен для больших проектов и масштабируемых систем.


                                                  По-моему, вы предвзяты. Скорее имелось в виду, что вы намекаете на необходимость попробовать ФП, сами не обладая опытом его применения в серьёзных проектах.

                                                  Как эти идеи представлены в конкретных языках, вопрос другой


                                                  Это первейший вопрос при выборе платформы для серёзной разработки.
                                                  • 0
                                                    Опять отвечаете на какой-то другой вопрос.
                                                    Я вот просто много пообщался с командами, которые использовали ФП. И вот задаешь вопрос и обычно слышить ответ:
                                                    — да, все просто шикарно, мы уже полгода фигачим, все иммутабельно, декларативно, чисто как слеза девственности, да, пользователи еще не видели, да и QA только мельком, но все точно очень клево.
                                                    — да, мы вот написали очень клевую тулзу за пару дней (даже две, если считать ту, на которой тренировались), так клево, что на ооп так не напишешь, хипстеры на последней афтерпати просто писали кипятком
                                                    — да, пользователей запустили, пришло куча чейнджреквестов и багрепортов, но пофиксить не получается ибо пользователи — идиоты и не понимают нашу стройную архитектуру, иммутабельность и чистоту (ну или если честные с собой люди, то где-то здесь осознают свою ошибку, но уже ничего не поделаешь)
                                                    — ну а люди, которые ничего толком не писали крупного обычно кидают какую-то тулзу для программистов в пример — веб-сервер, сервер чата, сервис мониторинга, етс. Где на любой чейнджреквест, который не вписывается в «стройную чистую иммутабельную архитектуру ©®» можно просто забить, а любой баг, который вызван этой архитектурой задокументировать как фичу.

                                                    Почему у кого б из сторонников ФП я не спросил — ни у одного нету личного удачного опыта.

                                                    И да, я лично не писал функционально ни на чем кроме JS.

                                                    Мы вот писали игру, пять лет, три из них с десятками тысяч живых пользователей. И я представляю, что такое поддержка живого продукта годами.
                                                    • 0
                                                      Хочу еще раз акцентировать:

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

                                                      Но я так и не встретил ни одного человека, который бы писал что-то на ФП, что может сойти за опыт успешного применения ФП в коммерческой разработке. Где истории успеха?

                                                      У меня вот друг близкий любит на Ерланге в свое удовольствие писать. Говорит, что любимый и самый изящный язык. Но крупные вещи предпочитает писать на более классических — php или java зависимо от задачи.
                                                      • 0
                                                        Но я так и не встретил ни одного человека, который бы писал что-то на ФП, что может сойти за опыт успешного применения ФП в коммерческой разработке. Где истории успеха?

                                                        WhatsApp написан на Erlang.

                                                        • +4
                                                          Он, наверное, хочет пообщаться лично с автором такого проекта, задать честные вопросы и услышать честные ответы. Так что проекты других людей не подходят, надо именно Ваш.
                                                          • +2
                                                            Это вы участвовали в его написании? Да, я знаю, что есть крупные компании, часть сервиса которых написано на ФП языках (клиент для Win вот написан на C# на сколько я могу судить, а в статье врут, что «WhatsApp fully written in Erlang»), но я хочу личного общения, а не сухих рекламных буклетов. Почему на хабре нету людей, которые тут и там говорят: «да, я писал, да, клево».

                                                            Я хочу не просто почитать: «да, вон та компания говорит, что крута, держит много» (та в любом стиле можно так написать)

                                                            Хочу спросить: «и как вам спустя несколько лет? насколько легко возвращаться в старый код? легко ли найти человека в команду? если найдете — как он входит? а как пишете гуи? легко ли реагировать на все хотелки пользователей/заказчиков? Я вот столкнулся с тем, что не всегда в команду приходится брать синиоров. И не всегда необходимы именно синиоры. Как мидлы от ФП справляются в вашей команде?».
                                                            • 0

                                                              Я отвечал на вопрос "где истории успеха".

                                                              • –1
                                                                Ну «там где-то, далеко» — это не тот ответ, о котором я говорил. Где личные истории успеха, а не маркетинговые ходы для привлечения заинтересованных программистов?
                                                          • 0
                                                            Backend игры World of Tanks написана на Erlang'e.
                                                            • +1
                                                              Кто вам такое сказал? Там С++ и Питон
                                                              Игровые объекты BigWorld написаны на языке Python, стандартном объектно-ориентированном языке, позволяющем программистам в три раза эффективнее выполнять поставленные задачи. В случае возникновения необходимости оптимизировать работу регулярно используемых функций, скрипты могут использовать язык C++
                                                              • 0
                                                                Я смотрел конференцию по функциональному программированию, там их тимлид рассказывал о обсчёте игровой карты и расчёте областей видимости танков. Эта задача у них выполнена на эрланге, к сожалению это видео найти не смог за 5 минут, но то что у них используется erlang это не секрет.

                                                                С вами всё же соглашусь в том что не весь бэкенд, но какая-то часть со сложными задачами — точно.
                                                                • +1
                                                                  Да, у нас в Варгейминге даже в Киеве были вакансии на Ерланг, я туда друга рекомендовал. Чтобы вы понимали — это неимоверно крупная контора, где есть огромное количество сервисов от самых маленьких до довольно крупных и самых разных языков. Более того, на некоторых направлениях эксперименты вполне поощряются, а для уменьшения усталости поощряются довольно экстремальные. Но это еще не значит ничего.

                                                                  У нас вот в проекте для билда Gulp использовался. И вполне мы могли б на конференции какой-нибудь рассказать. Только это отвратительная, неюзабельная штука, куда нельзя послать мидла без бутылки. Не удивительно, что он так быстро умер. И вот вы уже можете сказать, что «В Варгейминге используется Gulp на продакшене», вот только комментарии о нем у нас нелестные.
                                                            • 0

                                                              Я специально в своем комментарии в защиту ФП упомянул JS, это очень распространенный опыт, обжечься на нем и ругать ФП. Сам писал бэкенд на Node.js с лямбдами и думал что пишу ФП, это был очень неудачный опыт. Но этот опыт говорит только о том что в JS очень неудачная реализация для ФП и не более. Примеры больших ФП проектов вам привели, это намекает что парадигма жизнеспособна. Почему в целом и в Российском IT сегменте такие большие проекты сложно найти? Думаю ответ очевиден, для большого проекта нужно собрать в одну команду несколько специалистов со знанием ФП языка, что ввиду невысокой распространенности проблематично, так же немаловажный аспект — бизнес не будет вкладывать деньги в непроверенную годами технологию. Повод ли это хоронить ФП? Не думаю.

                                                              • 0
                                                                Так я сейчас и не спрашиваю про свой опыт, а про чужой.

                                                                Писать ФП на JS — мазохизм, тут без сомнений. Но вот на хабре много советуют ФП. Неужели никто из советчиков не может на своем опыте сказать, чем он хорош на практике?
                                                                • 0
                                                                  Я в ряды советчиков не напрашиваюсь, но пару мыслей из практики (F#) скажу. Дозированно смешиваю (но не взбалтываю) с С#. Хороший коктейль, когда в F# только алгоритмы. Они реально меньше, например генетический алгоритм у меня в три раза меньше (не меньше) вышел.

                                                                  Но ввиду своей лаконичности, F# достаточно труден и в отладке и в чтении, и в чем-то даже в написании. Но от «вау»-эффекта по первости сложно отделаться, как программировать заново научился :) Какой-нибудь энтерпрайз на функциональщине полностью точно писать не стану. Выигрыш от количества кода полагаю будет потерян, и по времени выигрыша тоже не думаю что будет много (если учитывать отладку).
                                                                  • 0
                                                                    Прочитав ветку, уловил суть вопроса
                                                                    А вы? Без ооп и для чего-то крупного, с длительной поддержкой и реальными пользователями.
                                                                    В таком случае ответ нет, но не потому что ФП не годится для промышленной разработки, а потому что компания не может себе позволить писать в ФП из-за высоких рисков не найти разработчиков. Т.е. это никак не относится к самой парадигме.

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

                                                                    Неужели никто из советчиков не может на своем опыте сказать, чем он хорош на практике
                                                                    Позволю себе описать некоторые плюсы опираясь на свой опыт с elm и ps:
                                                                    • Полное отсутствие рантайм-ошибок
                                                                    • Хорошая тестируемость и предсказуемость кода из-за отсутствия сайд-эффектов
                                                                    • Иммутабельность из коробки и как следствие time-travelling отладка, hot-reloading и прочие фишки. Ну и, опять же, предсказуемость кода


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

                                                                    Но есть и минусы:
                                                                    • Иногода может понадобиться сильно сломать голову, чтобы решить тривиальную задачу
                                                                    • Производительность в целом ниже (я про elm и ps, OCaml местами обгоняет C++, ну или обгонял раньше)
                                                                    • Необходимость крайне высокого уровня самодисциплины и, как следствие, риски при поиске разработчиков


                                                                    Подводя итоги: мой совет про ФП был не про реальную коммерческую разработку а в противовес идее, что «ООП — лучшее, что придумало человечество».
                                                                    • 0
                                                                      «ООП — лучшее, что придумало человечество».

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

                                                                      В таком случае ответ нет, но не потому что ФП не годится для промышленной разработки

                                                                      А вы считаете, что годится? Ну вот я менеджер в каком-то крупном городе, куда могу схантить разработчиков. Или даже, допустим, ФП стало популярным, как это стараются сейчас всюду всунуть. И теперь у нас рынок заполонили мидлы и джуны и даже можно задорого купить синиора. И что, как на счет ответов на остальные вопросы? Можно ли будет этот код поддерживать через 3 года активных change-request? Легко ли сможете вы вставить что-либо противоречащее архитектуре? Где состояние прописано прям в бизнес-логике. Как на счет написания гуи? А если гуи игры (допустим, казуалки, где производительность должно хватить). Или какой-либо интерактивный и анимируемый. Плавные изменения значений как результат анимаций, а не мгновенная перерисовка после приказа от сервера.

                                                                      Ну вот вы бы взялись написать аналог гимпа, казуальную игру, видеоредактор етс при помощи ФП? А если бы вы знали, что вам его 3 года поддерживать и вносить любые правки, то выбрали бы ФП или ООП?

                                                                      Полное отсутствие рантайм-ошибок

                                                                      Разве это не особенность всех статически-типизированных языков? Намного страшнее ошибки логики.
                                                                      • –1
                                                                        Я писал «ООП величайшее достижение в программировании» а не лучшее что придумало человечество. Как однако у вас восприятие «летает»… И ООП в извращенной форме применяется в современных трендовых фреймворк, значительно неоправданно увеличивая сложность. Нужно его применять там где нужно, а не где попало…
                                                                        • +2
                                                                          Я писал «ООП величайшее достижение в программировании» а не лучшее что придумало человечество. Как однако у вас восприятие «летает»…

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

                                                                          Нужно его применять там где нужно, а не где попало…

                                                                          Представьте пожалуйста объективные критерии оценки, где нужно применять ООП. Сразу напоминаю, что ваш «здравый смысл» не является объективным, не говоря уже о том, что мало кому здесь он кажется здравым.
                                                                          • –1
                                                                            Превосходно…
                                                                            >объясните… только это заведомо не здраво…
                                                                            зачем тогда просите писать? Это здравая последовательная логика?
                                                                            • +1
                                                                              Объясняю. Здравый смысл — это субъективный взгляд, ощущение правильности. Поэтому здравый смысл — это не объективные факты, а нам интересны именно факты, которые в итоге можно измерить человеко-часами, доходом и т.д.

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

                                                                              Если Вы посмотрите внимательно, то увидите, что я прошу Вас представить объективные критерии оценки, а не субъективное мнение.
                                                                              • +1
                                                                                Если же вы хотите выбирать, где нужно использовать ООП, руководствуясь здравым смыслом, то прислушайтесь к нему. То, что Вам все пишут — это и есть здравый смысл.
                                                                                https://ru.wikipedia.org/wiki/Здравый_смысл
                                                                            • 0
                                                                              Кстати, тут не так давно в какой-то статье обсуждали ООП vs ФП. Оказалось, создатель ООП вообще считает, то его неправильно поняли, что ООП никак не мешает ФП, а очень хорошо с ним сочетается, и что императивщики сильно извратили идею. В общем, ООП — это совсем не то, что хотел предложить автор данной концепции. От него осталось только название.
                                                                            • 0

                                                                              Все ваши вопросы, можно смело адресовать и к ООП. Их решения напрямую зависит от квалификации разработчика закладывающих архитектуру на старте проекта, ФП или ООП тут имеют мало значения как таковые. Особенно с учетом того что почти все языки гибридные, могу ошибаться но только Haskell можно назвать чистым ФП языком, остальные функциональные языки могут работать с мутабельными состояниями, что позволяет там где нужно писать императивно, а уже большую часть функционально. Помимо того, ошибки проектирования с использованием ФП нормальная практика для только набирающей популярность методологии, паттерны проектирования ООП тоже не за один год придумались. Для ФП есть и еще будут свои паттерны.
                                                                              Отвечая на тезис «ООП — лучшее, что придумало человечество», лично для меня определенно нет, по простой причине. ООП для меня это рутинный кактус который нужно есть, а ФП это тот код, при написании которого я могу отдохнуть.

                                                                              • 0
                                                                                ООП величайшее достижение в программировании
                                                                                Лучшее, что придумало человечество это пиво )
                                                                                • +1
                                                                                  для только набирающей популярность методологии

                                                                                  ФП зародилось практически одновременно с процедурным ИП: Лисп и Фортран — ровесники. Первый ООП язык (Smalltalk) появился гораздо-гораздо позже, в 1980-м релизнулся. А Лиспу скоро будет 60 лет, причём мёртвым языком он никогда не был, на нём писали и пишут постоянно. Напрашивается вывод, что что-то с ФП не так, раз оно 60 лет только набирает популярность и паттерны проектирования для него придумываются. Может для отдыха оно и годится, но бизнес и власть в его промышленной эксплуатации выгоды не видит, как правило, если и использует то в каких-то весьма ограниченных областях.
                                                                                  • +1
                                                                                    Я помню, еще в школе на математике далеко не все понимали, как строить график функции. Зато выполнять последовательность указаний и отдавать их другим — это элементарный навык, который все получают еще в детстве. Возможно, по этой причине императивное программирование проще декларативного, а декларативное вообще мало кому дается для понимания. За функциональным программированием стоит целый раздел дискретной математики. Сколько у Вас в классе было отличников по математике? Если функциональщиков — десять человек на всю страну, то мало кто рискнет затевать серьезный проект в функциональном стиле.
                                                                                    • +2
                                                                                      Зато выполнять последовательность указаний и отдавать их другим

                                                                                      Практика показывает, что даже программисты не всегда этим владеют в достаточной степени:
                                                                                      Жена посылает программиста в магазин:
                                                                                      — Дорогой, купи, пожалуйста, палку колбасы, и если будут яйца, то купи десяток.
                                                                                      Через полчаса программист возвращается с десятью палками колбасы.
                                                                                      Жена:
                                                                                      — Что это?! Зачем ты купил столько колбасы?
                                                                                      Программист:
                                                                                      — Ну так яйца-то были…

                                                                                      :)

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

                                                                                      С другой стороны, среди программистов не встречал особых трудностей с освоением азов ФП, когда какой-то кусок программы требуется написать в функциональном стиле, храня его (куска) состояние в стеке вызовов. Трудности возникают когда нужно написать всё приложение, активно взаимодействущее с внешним миром, в таком стиле. Так что я больше бы поставил на то, что ФП мало подходит для решения подавляющего большинства практических задач, чем на то, что требуется какое-то особое мышление, которое очень трудно приобрести. В конце-концов, доминирующие аппаратные архитектуры (Тьюринг-подобные машины) оперируют прежде всего набором инструкций, изменяющих состояние, а функциональные языки лишь предоставляют декларативную абстракцию над императивной машиной, что бесплатно не даётся, а в человеческом мышлении скорее первична декларативная составляющая, чем императивная. Задача обычно ставится декларативно (заметно при общении с бизнесом, далеким от ИТ или с детьми), а вот уже решение переводится в императивную форму, если нет уверенности, что исполнитель правильно поймёт декларативную. В какой-то мере работа современного программиста в принципе состоит из перевода декларативных слабоформализованных задач заказчика в императивные команды тьюринг-машины. И почему-то многие программисты избегают варианта полной формализации в декларативной форме с автоматическим переводом в императивную.
                                                                                      • 0
                                                                                        Почему-то… Но вот почему — непонятно. Пока только сложность восприятия кажется мне надежным аргументом.

                                                                                        Трудности возникают когда нужно написать всё приложение, активно взаимодействущее с внешним миром, в таком стиле.

                                                                                        Как на счет Phoenix? Люди уже целый фреймвёрк сотворили.
                                                                                        Какие именно трудности возникают? Это факт или предположение? Если факт, то можно ли описать подробнее прецеденты и суть возникших проблем?
                                                                                        • 0
                                                                                          Сложно сказать, по-моему, именно сложность предмета самого по себе или, скажем, необходимость ломать привычки. И определённо эмуляция декларативного исполнителя императивным не бесплатна. Остаётся только надеяться, что транслятор языка будет, например, разворачивать хвостовую рекурсию в циклы (в популярных движках JS, например ещё не реализовано, хотя и определено стандартом ES2015), будет мутировать состояние уже имеющихся экземпляров структур данных вместо почти полного глубокого копирования и удалением оригинала и прочие оптимизации применять. В идеале ещё и наличие в библиотеке функций с императивной реализацией (инкапсулированной, конечно) в тех случаях, когда она заметно эффективней функциональной.

                                                                                          Я бы назвал общепринятым мнением, что ФП усложняет работу с мутируемым состоянием, сайд-эффектами (включая ввод/вывод) и т. п., без которых сложно обойтись (или это будет очень накладно по вычресурсам) при решении подавляющего большинства практических задач. Мой личный опыт в виде попыток создавать простейшие CRUD веб-приложения с хранением данных в РСУБД на Лиспе и Хаскеле это подтверждает. И, кстати, сложилось впечатление, что мутации внедрены в эти языки именно таким образом, чтобы облегчить работу транслятору, а не разработчику. Я очень надеюсь, что обошлось без сознательного усложнения работы с мутациями с тем чтобы разработчики прибегали к ним только когда без этого реально не обойтись, а не мешали функциональный и императивный подход руководствуясь локальной простотой начальной реализации, как это часто встречается в мэйнстримовых языках (прежде всего Си-подобных), к которым некоторые функциональные возможности были прикручены позже и транслятор не следит за чистотой функций.
                                                                                          • 0
                                                                                            Тогда, возможно, Вам для полноты картины стоит посмотреть на Elixir. Там работа с состояниями обернута довольно изящно.
                                                                                            • 0
                                                                                              Тогда, возможно, Вам для полноты картины стоит посмотреть на Elixir.
                                                                                              Боюсь, что erlang/elixir это как раз больше про оригинальное ООП, нежели ФП. Объекты есть (процессы), общение через сообщения есть (позднее связывание), все как завещали, только приправленное некоторыми функциональными фишками.
                                                                                              • 0
                                                                                                Ну так ведь и ФП же там в чистом виде.
                                                                                                • 0
                                                                                                  От ФП там иммутабельность и паттерн-матчинг, когда ни типизации, ни алгебраических типов данных (хотя, это частично решается атомами в кортежах), ни, уж тем более, теории категорий, к сожалению нет. Так было бы совсем круто. Кстати, кажется, если мне память не изменяет, кто-то даже пробовал спортировать OTP на haskell.
                                                                                        • +1
                                                                                          Недавно мне поставили задачу в императивном стиле. В смысле текст задачи был как-бы псевдокодом на русском языке. В итоге я так и не смог понять что нужно сделать т.к. не смог понять, что должно получиться. А мои навыки как раз и заточены на генерацию решений «как сделать чтобы получилось как описано». Пришлось идти и устно расспрашивать, что и зачем должно быть на выходе. Да и в личной жизни слова девушки вида "(не/с)делай то-то и то-то" меня совсем не берут, нужно описать что должно получиться и зачем, только после этого можно давать подробности по «деталям реализации».
                                                                                  • 0
                                                                                    ФП — оно хорошо для определенных задач, но не так универсально, ведь решает именно определенные задачи. И игру, или графический редактор не будешь писать на ФП

                                                                                    Отсутствие доказательства того, что ФП лучше, не является доказательством того, что ФП хуже. То, что мало специалистов по ФП, тоже не говорит о том, что он хуже. Например, я считаю, что PHP хуже, чем Python или Ruby, по многим объективным критериям, но количество разработчиков на PHP как бы «доказывает», что PHP — лучший язык. Также, как количество курильщиков может доказывать, что курить — это хорошо. Здесь нет логики, выбор большинства не может быть объективным критерием оценки.
                                                                                    • 0
                                                                                      Ну ты прям меня обижаешь, я могу в базовую логику. Конечно, количество не обязательно означает качество.

                                                                                      «ФП — оно хорошо для определенных задач» — вывод сделанный не из-за количества последователей.

                                                                                      Тем не менее полное отсутствие свидетельствует уже о чем-то. Например…

                                                                                      Слышали про "Чайник Рассела"? Так вот. Сейчас ФПисты похожи на религиозных фанатиков. Да, никто не видел (лично) успешных проектов на ФП, только где-то в библии сказано, да, никто не может назвать игру или 3д-редактор на ФП, кто-то даже слышал голос бога и после химиотерапии его родственник чудесным образом исцелился. Никто не может точно наверняка сказать, что ФП работает, но все верят и стараются затянуть в эту веру окружающих.

                                                                                      И я не удивляюсь, что люди, которые писали маленькие или подходящие вещи действительно так считают, ибо… прототипы всегда писать намного веселее в абсолютно любом стиле. Я вот писал прототип видео-редактора на WebGL на жесткой смеси процедурщины, ооп, фп, быдлокода и какой-то матери. Писать мне было весело и легко, оно клево работало и фичи добавлялись быстро. Но это совершенно не значит, что я считаю такой подход приемлимым для реально разработки.
                                                                                      • 0
                                                                                        Есть свидетельства в виде сторонних проектов. Но на Хабре никто не делится ни положительным, ни отрицательным опытом. О чем это говорит? Мне — только о том, что никто из хаброюзеров не использовал ФП в своих больших проектах. Доказывает ли это, что ФП не годится? Нет, совершенно. Это доказывает лишь то, что ни у кого нет данного опыта.
                                                                                        • 0
                                                                                          Тем не менее, почему-то, многие стараются убедить, что это очень круто и надо в него обязательно верить. Почему?
                                                                                          • 0
                                                                                            Не знаю. Просто не следуйте их примеру и не пытайтесь безосновательно убедить, что это не круто. Пусть кто-то поверит и попробует, это же интересно! ;)

                                                                                            Я тут на коленке начал небольшой проект по сравнению парадигм. Надеюсь что-то прояснить для себя. Если получу какой-то стоящий результат — обязательно поделюсь этим на Хабре.
                                                                                            • 0
                                                                                              А потом нельзя работу будет найти, где не отказались бы от нормальных практик в пользу новой моды? ;) Люди ж читают всё это и думают — оно ведь реально так клево. А критически мыслить — сложно, что никто на практике это реально еще не использовал и методик пока не изобретено.
                                                                                              • 0
                                                                                                Так надо же проверить, чтобы критически мыслить. А пока в основном только теоретически рассуждения и анализ чужого опыта.
                                                                                          • +1
                                                                                            Мне — только о том, что никто из хаброюзеров не использовал ФП в своих больших проектах.

                                                                                            Или не хотят признаваться в ошибках.
                                                                                            • 0
                                                                                              Да ладно! Не обязательно признаваться в ошибках и вспоминать о том, что был евангелистом ФП. Зато обвинить парадигму в своих неудачах — это святое дело! Уверен, был бы повод — все тут рассказывали бы истории, как ФП подвело их на важном проекте.
                                                                                      • +1
                                                                                        Можно ли будет этот код поддерживать через 3 года активных change-request?
                                                                                        Да, поддержка через 3 года функционального кода настолько же сложна, насколько сложна поддержка ООП через те же 3 года. Вот только накосячить с ООП гораздо проще.
                                                                                        Легко ли сможете вы вставить что-либо противоречащее архитектуре?
                                                                                        Ну не сказал бы, что легко, но и не сложнее, чем с ООП. Более того, в случае ООП нужно отдавать отчет, что все вставленные костыли рано или поздно вернутся головной болью. ФП же сужает круг мест, где эти костыли можно расставить.
                                                                                        Как на счет написания гуи?
                                                                                        Вот как раз ФП тут больше подходит. Взять тот же реакт: ui — чистая функция от состояния.
                                                                                        А если гуи игры
                                                                                        Почему нет? Хотя опыта в этой области у меня нет. Ну, и перфоманс видимо просядет.
                                                                                        Плавные изменения значений как результат анимаций, а не мгновенная перерисовка после приказа от сервера.
                                                                                        На самом деле, все это возможно. ФП ничем не отличается в плане возможности наличия сложного состояния процесса (например, анимации). Просто обработка этого состояния по-другому происходит.
                                                                                        Ну вот вы бы взялись написать аналог гимпа, казуальную игру, видеоредактор етс при помощи ФП? А если бы вы знали, что вам его 3 года поддерживать и вносить любые правки, то выбрали бы ФП или ООП?
                                                                                        Ну, я не могу похвастаться таким опытом в ФП, чтобы сесть и написать гимп. Но, тем не менее, это опять таки не значит, что ФП не годится для этих вещей. На ФП прекрасно пишутся огромные сложные вещи, взять ту же MirageOS на OCaml.
                                                                                        Разве это не особенность всех статически-типизированных языков?
                                                                                        В том то и дело, что нет. Статическая типизация лишь обеспечивает проверку типов, но не обработку тех же исключений. Вот зареджектится ваш промис, а вы это не обработали — пожалуйста, рантайм ошибка. В случае же с тем же Elm (ну, раз уж за фронтенд), там просто не существует этих исключений. Все возможные сайд-эффекты обрабатываются как данные.
                                                          • +3
                                                            Поскольку большинство, включая текущих разработчиков php, eval не считают полезной вещью, а так же по ряду очевидных объективных причин eval имеет проблемы:
                                                            • Низкая скорость из-за парсинга и компиляции в момент вызова функции;
                                                            • Не используется кэш байткода;
                                                            • Ограничен доступ к локальным переменным и пространствам имён;
                                                            • Не поддерживается компиляторами, типа HipHop;
                                                            • Не понятно что там с обработкой ошибок, возникших внутри eval-кода.
                                                            • –2
                                                              Насчет пространств имен — я писал…

                                                              Глобальные переменные доступны через инструкцию global, вы говорите о недостатках SKY Framework или о другом? В SKY Framework (текущем) eval имеет доступ ко всему что нужно.

                                                              Ваши пункты 1,2,4 — это один пункт. Замечание впросак, не готов дать ответ. Плюс нужно сравнить быстродействие готовых эквивалентных приложений. За счет того что в Symfony не используется eval, а КПИ имеет известную тяжелую архитектуру, я не думаю, что будет выигрыш в производительности.

                                                              Ошибки нормально, как обычно обрабатываются. С этим нет проблем.
                                                              • +1
                                                                Понимаете, проблема не в том, какое применение вы нашли eval, а в том, что эту функцию фвно не любят текущие разработчики языка. И если учесть, что сейчас она в основном используется вредоносным кодом, то я не удивлюсь, если в следующей мажорной версии её просто выкинут.

                                                                Это здорово искать новые пути разработки, но опираться на функциональность, живущую на птичьих правах немного опасно.
                                                              • +1
                                                                А дебажить PHP код изобилующий eval — это ад кромешный!
                                                                • –2
                                                                  нет самоцели применять много eval, но он иногда сильно упрощает вид кода, вплоть до тривиально простого вида. Вы используете eval, если знакомы с проблемой?
                                                                  • +3
                                                                    Я рефакторил легаси код с кучей eval и знаком с проблемой не понаслышке!
                                                                    Даже если в коде будет всего один eval, использующийся для выполнения различных кусков кода из БД и прочих источников данных, недоступных для анализатора IDE — это уже «ад» для того, кто будет с этим кодом работать после автора.
                                                                    Все ваши проблемы можно решить с помощью уже давно реализованных в PHP замыканий! Но при этом разобраться с кодом стороннему разработчику в своей IDE будет в разы проще, и исчезнут проблемы с которых началась эта ветка.
                                                                    • –4
                                                                      вы не поняли, почему я использую eval. Анонимные функции я так же использую, это совсем другое. Если вы у меня в коде увидели create_funcion() и не поняли почему там не используется замыкание, то ответ прост — это непринципиально. Если вы программист PHP скачайте код из видео на главной, посмотрите немного внимательней код
                                                                      • +1
                                                                        ответ прост — это непринципиально
                                                                        Если для вас непринципиальны мои доводы и pda0,
                                                                        то дальше объяснять вам недостатки eval — бессмысленно!
                                                                        • –1
                                                                          Вы читаете мое сообщение, прежде чем написать комментарий? ) Я сравнивал функцию create_funcion() и Closure. А Closure не может заменить eval.
                                                                      • –2
                                                                        Как можно совсем не разобравшись в предмете участвовать в дискуссии?
                                                                • +3
                                                                  Господа, будьте добры, кто-нибудь в одном предложении скажите, о чем тут пытался сказать автор?
                                                                  > Идею проекта SKY можно излагать по разному, но самое короткое и простое изложение следующее:
                                                                  В итоге получилось на полэкрана некороткого и непростого изложения, не раскрывающего сути.
                                                                  > Так сайт packagist сопоставим с проектом SKY, достигшем цели X
                                                                  Увы, не сталкивался с проектом packagist.

                                                                  > нет ни одного, сила которого бы была обусловлена кодом пользователей
                                                                  github.com
                                                                  И всякие сайты-песочницы кода, вроде jsfiddle.net, нет? Сайт помогает эмулировать код, а без этого кода «силы» нет. Сюда-же можно добавить великий Stackoverflow — уберите из него все коды пользователей, и какая будет у этого сайта «сила»? Если засчитываем Stackoverflow, то считаем и миллионы форумов, где люди в топиках задают вопросы по программированию, и им отвечают предоставляя код (начиная от програмирования контроллеров и веб-страниц, заканчивая монстрами биг-даты).

                                                                  > В данный момент проект SKY мало известен
                                                                  Хоть 1 слово про проект то! ни слова о том, что же за проект, в конце то концов. Куча воды. После первого громадного абзаца так и не понятен проект. А второй абзац начинается вообще с мемуаров:
                                                                  > Вообще, я считаю «верный путь в php» большой досадной ошибкой…
                                                                  • 0
                                                                    >github.com
                                                                    нет. я писал о идеальном коде разрабатываемом коллективно.
                                                                    • 0
                                                                      А почему гитхаб то под это определение не подходит?
                                                                      • –1
                                                                        А где вы там видите коллективную разработку кода, в том смысле, который упоминается в статье? У вас есть идеальный framework, над мельчайшими деталями которого потрудилось множество людей? Жаль, что никто не понял материал статьи, я честно старался быть максимально лаконичным. Посмотрите результаты голосования в этой статье — довольно много людей хотят что-то исправить в framework с которыми работают. Если бы существовал сайт достигший цели X, таких людей бы не было. Они либо прояснили свое понимание вещей, либо их идея была использована для совершенствования framework.
                                                                        • +4
                                                                          Не может быть одного фреймворка, удовлетворяющего всех. Даже если пишешь сам всё с нуля в рамках одного проекта приходится идти на компромиссы.
                                                                          • –2
                                                                            Если фреймворк «закрутить» сложно, как есть, то да — бредовые мысли могут не совпасть, так как ход мыслей у людей разный. А если сделано просто, то может один удовлетворить всех.
                                                                            • +4
                                                                              Не может. Есть вечные компромиссы, на которые часто приходится идти разработчикам, например, читаемость против потребления ресурсов, надежность против потребления ресурсов и читаемости, Более того, даже под читаемостью каждый понимает своё. А в одних задачах в требование надежности входит атомарность изменений, или всё меняем, или не меняем ничего, если хоть что-то поменять не можем, а в других надежной считается система, которая изменяет всё, что может изменить, даже если что-то не может. Да и по ресурсам часто приходится искать компромисс между скоростью и потреблением памяти. Не сможет одно решение удовлетворять всех, всегда и при любых условиях.
                                                                              • –1
                                                                                Все веб-приложения (мы же говорим о них?) имеют конечное количество канонично-логических связей. Первая, например, что существует центральное тело страницы и LAYOUT и нужно «их» соединить. Я говорю о наиболее частом случае при построении веб-приложений, да, встречается редко и не так и аякс не так. Это я называю каноничной предрасположенностью. Таких вещей не очень то много и они продиктованы основой, которая «уходит» за пределы темы. Уходит в http протокол, принятый способ фундаментальной архитектуры браузеров и прочее. Так вот такой «каноники» не очень то много…

                                                                                Теперь вопрос… вы не верите в идеальный код? Задача то для всех одна: «сделайте так чтобы сайты можно было читать в интернете...». Вспомнилось видео: хочу мышкой открывать окна..
                                                                                Как может возникнуть разнобой в требовании программистов к фреймворк? Исходя из этой логики, существует единое лучшее решение. Есть одна лучшая постановка задачи и одно лучшее решение. Альтернативы, имхо, доказательство лишь того, что каноничность так и не «разрулена», хотя, я верю, что это возможно.
                                                                                • 0
                                                                                  Первая, например, что существует центральное тело страницы и LAYOUT и нужно «их» соединить.

                                                                                  … и даже у этой задачи есть больше одного равноправного решения.


                                                                                  Люди до сих пор не могут определиться, какой presentation pattern лучше подходит для веб-приложений (и, будем честными, с развитием технологий это банально меняется), а вы говорите "идеальный фреймворк". Да он устареет раньше, чем будет написан.


                                                                                  Задача то для всех одна: «сделайте так чтобы сайты можно было читать в интернете...».

                                                                                  Эту задачу решает http-протокол… и если вы обратите внимание, тоже единой версией не обошлось.


                                                                                  Но вообще я вам настоятельно не рекомендую смешивать веб-сайты и веб-приложения.

                                                                                  • +1
                                                                                    Если мы говорим о сайтах, которые только читают (как минимум никакие состояния на сервере пользователями не изменются, кроме технических логов, счётчиков и т. п.), то я вообще сейчас порекомендовал бы какой-нибудь генератор статических файлов, вообще без уровней сервера приложений и хранилища данных, только веб-сервер.

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

                                                                                    Вы исходите из ложного недоказанного тезиса «есть одна задача и есть одна лучшая её постановка». Задачи разные, более того нередко противоречащие друг другу, например, «мы должны всегда иметь возможность идентифицировать пользователя и иметь полный список действий которых он совершил, всего версии всех его данных и т. п.» и «мы не должны иметь возможности при всём желании идентифицировать пользователя, получить доступ к его данным и т. п.».
                                                                                    • 0
                                                                                      Есть конечно такие различия, но я писал, что в SKY большое внимание уделяется потенциальной частоте использования функционала. Ваш первый случай «всегда иметь возможность идентифицировать пользователя» — частый, я бы сказал, его нужно «танцевать» в «чистое облако». Второй «мы не должны иметь возможности при всём желании идентифицировать пользователя» — редкий, может быть получен модификацией кода CLEAR-CLOUD с помощью приложения DEV.SKY. Я бы отдал первому случаю 90% частоты, второму 10% из всех сайтов реально присутсвующих в Итернете. Второй случай, это только некие платежные системы или нечто когда повышенные требования к безопасности или требования закона государств. Таких случаев мало.

                                                                                      Вы «летаете» в абстракциях, в жизни 10% случаев это мало… Нет смысла делать код гибким, чтобы поддерживать их.
                                                                                      • +1
                                                                                        Второй «мы не должны иметь возможности при всём желании идентифицировать пользователя» — редкий, может быть получен модификацией кода CLEAR-CLOUD с помощью приложения DEV.SKY.

                                                                                        И вы, конечно, не в курсе, что модификация кода фреймворка для решения задачи — это плохо?


                                                                                        Вы «летаете» в абстракциях, в жизни 10% случаев это мало…

                                                                                        10% — это 36 дней в году (больше месяца). Это один месяц (больше) из вашей зарплаты за год. Это мало, да?

                                                                                • 0

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

                                                                        • +1
                                                                          «проект packagist» это про композитор речь (менеджер пакетов для PHP), мне особенно понравилось

                                                                          нет папки vendor. Требуется переработка классов на packagist в соответствии с идеологией SKY.

                                                                          примерно ~ 115 тысяч пакетов переработать, coresky, извини, разочарую, но на это ни кто не подпишется.
                                                                          • –1
                                                                            спасибо, что разъяснили, а-то я не понимал о чем пишу…
                                                                        • +4

                                                                          Жесть какая-то. Вы пишете на PHP 3?

                                                                          • –3
                                                                            На главной странице http://ru.coresky.net/ упоминается что нужен PHP 5.4 и выше. Как можно быть таким невнимательным? Просто ужас действительно.
                                                                            • +2
                                                                              А что там из 5.4 используется?
                                                                              • +6
                                                                                [sarcasm]
                                                                                Короткая запись массивов, очевидно же
                                                                                [/sarcasm]
                                                                          • +1
                                                                            Требуется переработка классов на packagist в соответствии с идеологией SKY

                                                                            роутинг страниц, как механизм излишен.

                                                                            Писать код в глобальную область видимости и использовать eval() в коде нужно шире, как это делается в SKY framework

                                                                            Механизм NAMESPACE излишен.

                                                                            автор или толстенный тролль, или не понимает о чем говорит
                                                                            • –3
                                                                              Я честно говорю, я трудился над тем, чтобы в статье не было грамматических и прочих ошибок, материал был легко понятен, несколько (довольно много) часов. Могу я вас попросить, в дань уважения моей работе, давайте не будем здесь употреблять слово «троль» и «велосипед». Я не прошу вас больше не о чем.

                                                                              Мне искренне жаль, что материал показался многим сложен для чтения. А вот большой процент людей, не вникшим ни в какую суть, но желающих покритиковать, огорчает.
                                                                              • –2
                                                                                А вот большой процент людей, не вникшим ни в какую суть, но желающих покритиковать, огорчает.
                                                                                Таков сейчас хабр. Если ваше мнение отлично от мнения большинства — вас минусуют, даже не пытаясь ни в чем разобраться. Причем независимо от того, насколько вы правы/неправы или какие аргументы вы в свою пользу приводите.
                                                                                P.S. Знаю, что за этот комментарий меня тоже скорей всего заминусуют, но хочется вас поддержать. Повторюсь, некоторые ваши идеи (да и сам проект тоже) достаточно интересны и заслуживают должного внимания.
                                                                                • –1
                                                                                  спасибо за смелость
                                                                                  • 0
                                                                                    за «корову», которую вы потеряете — буду должен. А вот другие «зажали свою корову» )
                                                                                • +8
                                                                                  А почему вы решили, что люди не вникли в суть?

                                                                                  Вы предлагаете не использовать PDO и именованные параметры, а экранировать данные вручную.
                                                                                  У вас в коде куча потенциальных SQL-инъекций.
                                                                                  if (sql("+select count(1) from users where email='$data[email]'$or")) return 3;
                                                                                  

                                                                                  Email перед этим проверяется регуляркой. Вы в курсе, что одиночная кавычка в email это разрешенный символ? Кто-нибудь решит привести вашу регулярку в соответствие с RFC, и в запросе появится уязвимость.

                                                                                  Вы предлагаете писать в полупроцедурном стиле с eval() и глобальными объектами. При этом некоторые процедуры с какими-то скрытыми хаками.
                                                                                  function sqlf() {
                                                                                      $ary = func_get_args();
                                                                                      $func = 'global $sky; return is_array($v) ? $sky->join("' . strtolower(substr($sql = array_shift($ary), 0, 1)) . '", $v) : $v;';
                                                                                      return sql(vsprintf($sql, array_map(create_function('$v', $func), $ary)), 2);
                                                                                  }
                                                                                  
                                                                                  function strand($n = 23) {
                                                                                      ...
                                                                                      if ($n != 7) $str .= 'o0Ol1iIB8'; # skip for passwords (9 chars)
                                                                                      ...
                                                                                  }
                                                                                  


                                                                                  Вы предлагаете другим разбираться, поддерживать и развивать ваш код с кучей сокращений и запутанной архитектурой. Все вот эти global $UA, $PVAL, $s_crypt, $p_mem; $this->idc; $this->gpc; $this->qn;. А что означают $sky->s_c_manda и $sky->s_j_manda я даже думать не хочу.

                                                                                  Это правильный путь? Нет уж, спасибо.
                                                                                  • –8
                                                                                    ..cookie mandatory, javascript mandatory

                                                                                    нет никакой кучи потенциальных SQL инъекций, зачем врать? Приведите хоть 1 пример реальный… а не «побурчал, сделал умный вид» и ушел. Да, экранировать надо вручную, это принцип KISS. Если у вас сложности с экранированием вручную, вы не будете способны написать нормальное веб-приложение, даже если фреймворк даст вам функции-методы, где авто-экранирование.

                                                                                    >процедуры с какими-то скрытыми хаками…
                                                                                    настолько сложно, что вы не можете понять работу функции? Три строчки то всего… Что может быть проще? А может просто признаетесь, что не владеете func_get_args и vsprintf в полной мере?

                                                                                    У меня сложная архитектура? Тут я просто «пас»…
                                                                                    • +1

                                                                                      Ручное экранирование (данных, отправляемых в БД) — это бессмысленная трата времени и сил при наличии параметризованных запросов. Более того, параметризованные запросы (обычно) производительнее на сервере. Так кому и зачем может быть нужно ручное экранирование?

                                                                                      • 0

                                                                                        Автор статьи просто не понимает, что KISS требует контекст.


                                                                                        • В юриспруденции важна подробность описания. И чем подробней, тем отсекаются всякие "домыслы"
                                                                                        • Армия (из которой пошел KISS) — важна краткость при передаче информации, чем метче и точнее, чем меньше слов — тем лучше, но все слова и фразы должны быть заранее выучены (чем и занимаются в учебках)

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


                                                                                        Но автор подумал, что 640 Кб хватит всем.

                                                                                        • 0
                                                                                          Автор статьи просто не понимает, что KISS требует контекст.

                                                                                          По моим ощущениям, автор статьи не только этого не понимает.


                                                                                          Если бизнес требует абстракции — пиши абстракции.

                                                                                          Бизнес обычно не требует абстракции, бизнес хочет, чтобы работало.

                                                                                          • 0
                                                                                            Бизнес обычно не требует абстракции, бизнес хочет, чтобы работало.

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

                                                                                            • +1

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


                                                                                              (К сожалению, есть бизнес, который лезет не на свою территорию, и пытается решать, каким образом стоимость сопровождения будет меньше — и, поверьте мне, далеко не всегда это "популярные фреймворки".)

                                                                                              • 0

                                                                                                Иногда дешевле бизнесу поддерживать свое, иногда взять поддерживаемое. В двух вариантах есть достоинства и не достатки. Смотря какие цели (контекст). Тут как всегда серебряной пули нет.


                                                                                                В конечном счете, ему (бизнесу) наверное все равно, главное чтобы соотношение "цена-качество-скорость" или улучшались или хотя бы оставались на том же уровне.


                                                                                                А разработчикам, чтобы непрерывно удовлетворять изменяющиеся требования бизнеса (улучшать скорость, ускорять поддержку), приходится строить абстракции (примеры: ассемблер, Java, виртуальные машины, React: рендер на клиенте или сервере), чтобы добиться заменяемости на уровнях ниже. Вчера компьютер занимал целую комнату, завтра стал квантовым, но программы тех бородатых времен продолжают работать.

                                                                                                • +1

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

                                                                                      • +3
                                                                                        нет никакой кучи потенциальных SQL инъекций, зачем врать? Приведите хоть 1 пример реальный…

                                                                                        «Потенциальная SQL инъекция» означает, что сейчас инъекции нет, но при некоторых условиях она может появиться. Пример я вам привел: меняем регулярное выражение для соответствия RFC — появляется инъекция в запросе.

                                                                                        Да, экранировать надо вручную, это принцип KISS

                                                                                        В запрос передаются 10 значений. Можно 10 раз вызывать escape(), можно 10 раз не вызывать escape(). Минус 80 символов, как минимум. Мне непонятно, почему более громоздкий вариант это по-вашему проще.

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

                                                                                        Почему это? Кстати, раз уж зашел разговор, написанные вами веб-приложения можно где-то посмотреть?

                                                                                        У меня сложная архитектура?

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

                                                                                        настолько сложно, что вы не можете понять работу функции?

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

                                                                                        Прочитайте книжку Макконнелла, если еще не читали. А если читали, то задумайтесь, почему программисты считают ее хорошей.
                                                                                        • –3
                                                                                          сайт из видео — http://ru.coresky.net/download?video1.sky.zip
                                                                                          Можно 10 раз вызывать escape(), можно 10 раз не вызывать escape()

                                                                                          вы фантазируете, это нереальный случай (оч. редкий), но даже в этом случае — просто используйте цикл, если надо. Посмотрите мой реальный код, где запросы к БД и сравните со своим. Что проще?
                                                                                          • +1
                                                                                            eval($me) or die;
                                                                                            
                                                                                            if ('delete' == $PVAL):
                                                                                                sql("delete from $me where id=$WVAL");
                                                                                                jump(me);

                                                                                            Первые строки файла admin/_blog.php.


                                                                                            И да, это ужасно.

                                                                                            • –1
                                                                                              Предлагаю глубоко вникнуть в детали… Это простейший кусочек кода, который, надеюсь, не даст повода много прояснять. Начну разговор так: что ужасного то? Очень просто, это ужасно?
                                                                                              • +7

                                                                                                Ужасно то, что этот кусок кода (а) делает непонятно, что (что такое $me? $PVAL? $WVAL? нет, спасибо, ответ "это переменные" мне не нужен), и (б) то, что из него понятно — ужасно: представьте себе, что случится, если $WVAL будет иметь значение id (просто строка из двух символов).


                                                                                                Веселее всего, конечно, $me — которая сначала исполняемый код, потом имя таблицы, а потом и вовсе непонятно что (что делает jump?).


                                                                                                Поэтому нет, это не простой код. Простой код — это тот, который понятен и не вызывает вопросов. А у вас код… простецкий. Он прикидывается простым, но таковым не является.

                                                                                                • –4
                                                                                                  В том-то и дело, что даже тривиально простой код вам не понятен, а что уж говорить о коде симфони и ларавел? Вы не сможете никогда постичь его глубинного значения. Даже сами авторы таких фреймворк не понимают и «высокие авторитеты» не понимают, по этой причине появился ларавел из симфони.

                                                                                                  Опишу глубинный смысл этого кода:
                                                                                                  1 способ аналитического взлома сайта — это запустить файл, который сам по себе включаем, как точку входа. Такое действие часто может выдать детали кода хакеру. Существует 3 способа защиты от этого взлома:
                                                                                                  1. модный — поместить файлы PHP выше корня веб-сервера
                                                                                                  2. положить файл .htaccess с кодом «deny from all»
                                                                                                  3. написать вначале файла defined('CONST') or die; — хорошо забытый старый способ
                                                                                                  В SKY является стандартным способ номер 3, но можно использовать любой или все.
                                                                                                  Способ номер 3 несет четыре функционала в себе, без добавления (вообще !) нового кода. Во-первых, защита от взлома. Во-вторых, в константе указывается имя точки входа, например там может быть admin или front или cron или… другая… Эта информация используется в коде первого крыла main/sky.php, который всегда (! самый потенциально употребимый код) участвует для потенциальной замены любого сайта в Интернете. Кроме того, канонически веб-приложения всегда (оч. часто) построены так, что есть LAYOUT и код «центрального тела страницы». Таким образом третье функциональное назначение: если написать eval($me) or die; это сработает так-же как и defined('CONST') or die; Если переменная $me неопределена сработает die. Код переменной $me можно найти… Но если нормальная работа $me будет хранить имя файла без подчеркивания и .php Ее можно использовать в запросах SQL. При переименовании файла, запросы менять не надо. Часто удобно, чтобы псевдо-имя файла совпадало с именем таблицы с которой работает. Кроме того в трассировке показывается что «центральный файл страницы» запустился (или нет). В четвертых: открыв любой файл SKY-приложения, всегда сразу видно это включаемый файл или файл-точка входа. Благодаря всему описанному функционалу, выбран способ 3 как базовый и стандартный для защиты от основного способа интеллектуального взлома. Есть стандартный файл admin/_main.php, в котором есть стандартный код, который можно запустить и проверить — есть ли надежная защита от такого взлома…

                                                                                                  if ('delete' == $PVAL): — тут у вас думаю нет проблем в понимании

                                                                                                  sql(«delete from $me where id=$WVAL»); здесь $me выше описана. $WVAL одна из стандартных переменных: $PAGE, $PVAL, $WHAT, $WVAL. Практически всегда (очень часто) первых два ключа-значение из массива $_GET нужны, для обеспечения роутинга страниц, как вы называете (хотя для меня это громкие слова только). Чтобы был проще доступ, эти ключи-значения помещены в эти переменные.… чтобы было тривиально просто.

                                                                                                  Этот файл admin/_blog.php — авто-генерированный утилитой VISUAL из приложения DEV.SKY. Он считается только каркасом. Если вам нужен файл для приложения, которое выполняется только на вашей раб. станции, то и дополнительного «крышевания» не надо. Или если доступ к файлу есть только у вас, у разработчика в аггрессивном Интернете. Но если, вы не доверяете всем вхожим в админку, нужно допистать код крышевания, сделать защиту от SQL инъекции. Этот файл, только каркас!

                                                                                                  jump(me); — это просто редирект. Константа me будет хранить ?blog
                                                                                                  функция редиректа, так же как и sql() — часто используемая. Не нужно ее в класс «пихать»

                                                                                                  все, в общем-то
                                                                                                  • +7
                                                                                                    В том-то и дело, что даже тривиально простой код вам не понятен

                                                                                                    Как уже сказано выше, он совсем не "тривиально простой".


                                                                                                    Вы не сможете никогда постичь его глубинного значения.

                                                                                                    Оу, вы вот так легко делаете рассуждения о моих когнитивных способностях? По юзерпику, наверное?


                                                                                                    Опишу глубинный смысл этого кода:
                                                                                                    1 способ аналитического взлома сайта — это запустить файл, который сам по себе включаем, как точку входа.

                                                                                                    модный — поместить файлы PHP выше корня веб-сервера

                                                                                                    Это не "модный", это простой и эффективный. Нельзя взломать то, к чему нет доступа.


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


                                                                                                    1. написать вначале файла defined('CONST') or die; — хорошо забытый старый способ. В SKY является стандартным способ номер 3,

                                                                                                    То-то у вас там написано eval, а не defined.


                                                                                                    Код переменной $me можно найти…

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


                                                                                                    Но если нормальная работа $me будет хранить имя файла без подчеркивания и .php Ее можно использовать в запросах SQL. При переименовании файла, запросы менять не надо.

                                                                                                    … теперь у вас таблица в БД связана с именем файла. Причем неявно. Как хорошо, что мне никогда не надо будет это отлаживать.


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

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


                                                                                                    $WVAL одна из стандартных переменных

                                                                                                    Которая имеет какую семантику? И почему эта семантика не понятна из названия?


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

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


                                                                                                    Но если, вы не доверяете всем вхожим в админку, нужно допистать код крышевания, сделать защиту от SQL инъекции.

                                                                                                    Я имею привычку не доверять никому. Очень полезно. И если сгенеренный код по умолчанию небезопасен, то зачем он мне такой?


                                                                                                    Константа me будет хранить ?blog

                                                                                                    Угу, отдельное спасибо за то, что отдельно есть $me и me, и не дай б-г их перепутать.


                                                                                                    все, в общем-то

                                                                                                    Угу. Для того, чтобы объяснить пять строчек кода, вам пришлось написать экран текста. Это как раз и ужасно.

                                                                                                    • +3
                                                                                                      Большое спасибо за проделанную работу. Респект и уважуха. У меня напрашивается только один вопрос: и не лень же Вам? :)
                                                                                                      • +3
                                                                                                        и не лень же Вам?

                                                                                                        Неа. Разминка вокруг завтрака.

                                                                                                      • 0

                                                                                                        Или M-A-XG. Кто-то из них.

                                                                                                    • 0
                                                                                                      Вы не сможете никогда постичь его глубинного значения.


                                                                                                      Вот знаете, до этого даже не смотрел код — статья как-то не настроила. Но после такого пойду посмотрю…

                                                                                                      А так-то, постигать «глубинное значение» в коде, когда у тебя дедлайны, заказчик грозит судами-тудами, и какая-нибудь пое*ень страница начинает валить логами вместо красивых каких-нибудь слайдеров и карточек товаров (из 1С, спасите меня от неё), а потом еще три проекта в очереди и там конь не валялся… извините, всё это некогда.
                                                                                                      • –1
                                                                                                        >Вы не сможете никогда постичь его глубинного значения.
                                                                                                        это про симфони и ларавел я писал. Там по контектсту понятно. Но и насчет кода SKY, я писал, что считаю только коллективно можно создать идеальный код.

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

                                                                                                        Я так понимаю, здесь мало кого интересует истинна. Здесь просто арена для развлечений… Что ж вы так невнимательно читаете… (почти все комментаторы)
                                                                                                        • 0
                                                                                                          Да нет, вот, зашел на сайт, поглядел. Скажу вам так: использую Zend и недоволен. Bitrix — терпеть не могу. Wordpress уважаю, хотя годен он далеко не всегда.

                                                                                                          Мысль моего коммента была скорее в том, что инструмент хорош под задачу. Сделать быстро магазин с выгрузкой из 1С? Ну, битрикс, ладно… Сделать корпоративную визитку? Ок, вордпресс. Кастомный каталог? Zend и Doctrine замечательны.

                                                                                                          Не остается места для философии в программировании за деньги. А для души и решений на салфетке я предпочитаю javascript.
                                                                                                          • –1
                                                                                                            А для хобби — попробуйте SKY…
                                                                                                          • 0
                                                                                                            можно создать идеальный код
                                                                                                            Идеального кода не существует, и существовать не может. Вы, видимо, все еще на светлой стороне.
                                                                                                        • 0

                                                                                                          @lair, этот чувак напоминает мне G-M-A-X. Оба «евангелисты» такого подхода к программированию.

                                                                                                          • 0
                                                                                                            Какого подхода?
                                                                                                            Я не евангелист говнокода. Не втягивайте меня в это болото.
                                                                                                            Поищите мой коммент тут.
                                                                                                            А вам всем говна на вентилятор набросили и начался срач.
                                                                                                  • +2
                                                                                                    Это вы, видимо, с разработкой больших приложений не сталкивались. Там и под 50 бывает, и с наследованием таблиц, причем одновременно редактируется как минимум половина. Информация к размышлению: как вы думаете, сколько параметров может быть у обычной городской квартиры?

                                                                                                    В коде у меня, как ни странно, нет ни циклов, ни escape(). Проще не придумаешь.