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

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

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

Исследуем пакетный менеджер Nix и операционную систему NixOS.
В этой статье разбираемся с тем, как работает утилита nix-shell.

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

В далеком 2011 году в Ульяновске я начал создавать филиал широко известной в узких кругах компании Undev, той самой, которая писала софт для трансляции выборов президента, проведения ЕГЭ и многих других мероприятий. Основным стеком компании на тот момент был Ruby. Как известно, в регионах рубистов крайне мало, и на тот момент во всем Ульяновске это был десяток человек, которых все знали по именам.

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

Первоначально идея развития состояла в том, что мы используем Руби почти везде (и js, конечно). Ведь это дает столько возможностей.

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

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

Исследуем пакетный менеджер Nix и операционную систему NixOS.
Ранее мы разработали универсальный скрипт сборки для проектов autotools.

Сегодня мы обратимся к программе GNU hello, чтобы исследовать зависимости времени сборки и времени выполнения.

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

Вот тут-то и приходит на помощь наш добрый друг — Rust, а точнее его функции map, filter и fold. Они помогают не только приручить самых неугомонных data-котиков, но и сделать это без компромиссов по производительности.

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

Изначально этот материал планировался как урок в 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#.