Функциональное программирование *

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

Напомню, что модель классов PHP взята из Java. Наличие интерфейсов и всех сопутствующих элементов очень сильно влияет на способ организации кода в PHP. Этот способ часто отличается от того, как организуется код в JavaScript, Ruby или Python. И ещё больше отличается от таких языков, как Clojure или Elixir. И всё это на фоне того, что в каждом из этих языков есть ООП.

ООП в этих языках настолько разное, что PHP-программисты, попадающие в Ruby или JavaScript, не понимают, как так можно писать, ведь многие подходы противоречат их представлениям о мире. То же самое происходит и в обратной ситуации.

Так где же правда? Правда в том, что есть вещи, которые действительно определяют архитектуру кода. И это не структура классов, не наличие интерфейсов и не использование полиморфизма.

Возьмём тот же MVC. В нём говорится о слоях, об их задачах (зонах ответственности) и способе взаимодействия друг с другом. Это крайне важно для модульности. В модульной системе отсутствуют циклические зависимости. В MVC ничего не говорится про классы и ООП в целом, потому что между этими понятиями нет связи. Реализовать MVC можно в любом языке общего назначения, каким бы он ни был. То же самое можно сказать обо всех других архитектурных шаблонах.

Архитектура опирается на особенности среды, в рамках которой она применяется, а не на конструкции языка. Например, в вебе господствует HTTP, который построен вокруг концепции "запрос-ответ". Именно поэтому микрофреймворки разных языков выглядят так похоже, независимо от того, есть там ООП или нет: в каждом микрофреймворке есть запрос, ответ и обработчик ответа.

Подробнее о разработке я пишу в своем телеграм-канале организованное программирование. Присоединяйтесь если статья понравилась :)

В данной статье рассматривается подход к созданию пользовательских функций (UDF) в Scala, специфически в контексте использования в Apache Spark. Автор исследует проблему динамической генерации и передачи лямбда-выражений через JSON, обсуждая ограничения сериализации функций в Spark и возможные решения с использованием типа Any для универсальной обработки различного числа аргументов. Статья призывает к дискуссии и поиску альтернативных подходов, не претендуя на единственно верное решение, и представляет предложенный метод лишь как один из возможных вариантов решения задачи.

Обработка арифметических выражений с AST в Scala

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

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

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

Если вы хотите получить фундаментальные знания по разработки  iOS приложений с помощью SwiftUI, вам следует пройти стэнфордский курс CS193P. Предложенные в весеннем семестре 2023 года лекции Стэнфордского курса CS193P «Developing  Application for iOS with SwiftUI» («Разработка приложений для iOS с использованием SwiftUI») — это уже 3-я реинкарнация курса CS193P с фреймворком SwiftUI.

В настоящий момент действуют Xcode 15 / iOS 17, которые были представлены на WWDC 2023 уже после завершения курса CS193P, наиболее значимое обновление внесено в механизм реактивного UI в SwiftUI (макрос @Observable против протокола ObservableObject).

В иллюстрированных  русскоязычных конспектах этого курса сделаны пометки, касающиеся изменений в iOS 17. Для большинства Лекций представлена версия с  использование макроса @Observable вместо протокола ObservableObject, в ряде случаев это потребовало нетривиальных решений. 

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

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

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

«Python декораторы на максималках. Универсальный рецепт по написанию и аннотированию от мала до велика»

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

В этой статье мы разберём, как реализовано функциональное программирование в Groovy.

Я не понимаю, как на это реагировать. Некий товарищ полгода спрашивает у меня советы как начать с Verilog/FPGA/ASIC, но при этом ничего не начинает, хотя его вопросы становятся все более экзотическими. Чтобы было понятнее, опишу как бы это выглядело для программирования. Предположим к вам пришел молодой человек и спрашивает как научиться программировать. Вы ему говорите что-нибудь типа:

"Сесть за компьютер, написать и запустить программу Hello, world. Одновременно скачать книжку с описанием языка и базовых приемов и читать ее в общественном транспорте, перед сном и в приемной у зубного врача. Периодически садиться за компьютер, написать и отладить программы: сортировки массива, игры Жизнь, ханойских башень итд. С выводом на текстовый терминал, окно в GUI или веб-страницу - по вкусу. Далее вы поймете в какую сторону копать или не идти в это дело вообще."

Молодой человек вас горячо благодарит и уверяет как он сильно хочет стать настоящим программистом. Потом он Hello, world не пишет и никакой книжки читать не начинает, но последовательно спрашивает у вас:

За годы прошедшие с их появления в Java8 у меня набралась коллекция полезных решений и шаблонов, которые я переносил из проекта в проект, и которые в стандартной версии так и не были осуществлены. Недавно я решил собрать все вместе в небольшом проекте с открытым кодом. В первом релизе проекта расширения охватывают следующие аспекты:

В статье описывается механизм создания собственного модифицированного варианта монады IO в Haskell, с ограничениями операций ввода-вывода.

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

Чтобы добавить в программу интерактивность, но при этом максимально сохранить математическую целостность функций, применяется примерно такой подход:

Продолжаем знакомство с Nix и NixOS. В прошлых статьях мы научились собирать пакеты Nix (деривации), а теперь попробуем написать универсальный скрипт сборки, который можно было бы использовать для сборки множества пакетов.

Люка Бруно продолжает свой захватывающий рассказ.

Скотт Влащин продолжает рассказ о вычислительных выражениях в F#. Вычислительные выражения очень похожи на монады из Haskell, но у них есть свои особенности.

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

Но если очень хочется, то можно. В этой статьей Скотт рассказывает, как сделать ленивые вычислительные выражения в F#.

В прошлой пилюле мы собрали свою первую деривацию. Правда, она не делала ничего полезного, и эту оплошность надо исправить.

В очередной — седьмой — пилюле от Люка Бруно создадим деривацию, которая реально собирает и устанавливает программу в хранилище Nix.

Вычислительные выражения — поистине неисчерпаемая тема. Мы научились возвращать пустые значения, а теперь нам предстоит разобраться, как возвращать множественные. Скотт Влащин рассказывает, как использовать метод Combine.

Медленно, но верно мы добрались до шестой пилюли, посвящённой пакетному менеджеру и чистому функциональному языку Nix.

Попробуем создать нашу первую деривацию.

Шестая статья из цикла про вычислительные выражения. Скотт Влащин начинает рассказывать детали реализация, и это в два раза интереснее, чем раньше.

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

Пятая часть в цикле статей Люка Бруно рассказывает о функциях в языке Nix. Оказывается, у них не бывает имени и только один параметр. Как такое может быть?

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

Пятая статья из цикла про вычислительные выражения, написанная популяризатором Скоттом Влащиным.

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

Можно ли внедрить в Haskell постфиксный калькулятор?

begin push 1 push 2 add end
begin push 1 push 2 push 3 add mul end

На первый взгляд такой код на Haskell не может работать. Функция begin должна иметь произвольное количество аргументов, а Haskell является языком со статической типизацией. Но на самом деле, для написания вариативных (polyvariadic) функций достаточно полиморфизма.