Давайте разберем, что такое класс типов. Обратимся к формальному определению:
Класс типов (type class) — это абстрактный параметризованный тип, который позволяет добавлять новое поведение к любому закрытому типу данных без использования подтипов.
Класс типов - это в первую очередь про "поведение". Когда мы определяем класс типов, то неявно заключаем "контракт", в котором описываем желаемое для определяемого класса типов поведение.
В одном из своих предыдущих постов под названием "Эйлер, Чёрч и Мандельброт — этюд о красоте и математике" я немного затронул тему рассмотрения функционального программирования в качестве основы реальности. Под тем постом было оставлено множество интересных комментариев, один из которых, написанный @nickolaym, вдохновил меня на развитие мысли в данном направлении. Так появился этот пост, в котором прямо как во времена пифагорейской школы и платоновской академии философия переплелась с математикой, а математика с философией.
Работа организма состоит из множества процессов в нем происходящих и психических и физических, но любая деятельность задействует не все процессы, а некоторые из них, какие-то сильней, какие-то слабей. (Художник больше использует воображение и работу рукой, певец голос и слух, инженер внимание и концентрацию, боксер реакцию и физику).
Что такое эмоциональное выгорание? Попробуем разобраться в этом вопросе с точки зрения физиологии. А во второй части статьи я поделюсь с вами 13-ю полезными советами, как в нашем современном, бушующем, информационно перегруженном мире не перегореть и не получить эмоциональное расстройство.
Любые новые условия или деятельность вызывает в нашем мозге построение новой, адекватной внешним обстоятельствам функциональной системы, программы по которой будет функционировать организм в данных условиях.
В любой новой, незнакомой ситуации для получения определённого результата и приспособления к окружающим нас условиям мозг решает какие единицы мозга или тела задействовать (к примеру если Вы попали в совершенно незнакомую ситуацию, где вам нужно разрешить конфликт между людьми, то для полноценной работы ваша деятельность будет связана с усилением таких единиц, как мимика, воображение, жестикуляция, эмпатия и.т.д) Если результат достигнут положительный, то такая связка единиц организма фиксируется мозгом в виде комбинации и в дальнейшем, при схожей ситуации активируется именно эта связка, именно эта комбинация.
Если вы при парировании шутки про вас использовали определённый жест и определённый набор фраз и это было успешно, велика вероятность, что в схожей ситуации, схожих обстоятельствах и людях, вы используете тот же алгоритм, стратегию, связку или функциональную систему, в надежде, что она также успешно отыграет.
Привет, Хаброжители!
Преуведомление
Вся нотация, используемая в этой статье, не является общепринятой для представления математических выражений. Возможно, вы ранее изучали эту тему либо продолжаете изучать, поэтому заранее прошу прощения, если допустил какие-либо фактические ошибки или некорректно использовал термины.
Выпуск Java 21 состоялся 19 сентября 2023 года. В этой версии поддерживаются паттерны записи в switch-блоках и выражениях. Такой синтаксис выглядит монументально (как минимум, по меркам Java). Это водораздел, после которого мы вправе говорить, что в Java полноценно поддерживаются паттерны функционального программирования, подобно тому, как это сделано в Kotlin, Rust или C#. Вот и первый пункт, который пробуждает во мне зависть (я Kotlin-разработчик).
Некоторые оптимальные алгоритмы, оказывается, можно вывести из неоптимальных, пользуясь эквивалентными преобразованиями алгоритма. Бёрд и Меертенс разработали формализм, который устанавливает свойства функций высшего порядка map, fold, scan, позволяющие преобразовывать алгоритмы в эквивалентные. (См. также на Вики). Ниже представлен вольный перевод статьи Бёрда.
Рассмотрим задачу поиска максимальной суммы сегмента массива. Эту задачу можно переформулировать в виде математически точного ответа:
Для всех сегментов, которые можно получить из массива, необходимо посчитать сумму чисел, а затем среди всех таких сумм найти максимальную.
Мы так привыкли к типам, что редко задаёмся вопросом, что же они такое на самом деле? А главное - почему возникла необходимость в их использовании? Этот поверхностный обзор сделан для того, чтобы продемонстрировать, как типы и другие связанные абстракции являются следствием из обобщения условий различных задач.
В первой части мы рассмотрели примеры тестов, из которых не все одинаково полезны. Затем попытались определиться, что же такое качество ПО, и предложили "распрямлять" код и выводить программы из требований. Рассмотрели классификацию ошибок. Рассмотрели те задачи, в которых тесты хорошо себя проявляют.
Попробуем разобраться, что получится, если применить все эти соображения к тестам из первой части.
В первой части мы рассмотрели примеры тестов, из которых не все одинаково полезны. Затем попытались определиться, что же такое качество ПО, и предложили "распрямлять" код и выводить программы из требований. Рассмотрели классификацию ошибок.
Видя необоснованные надежды, возлагаемые на юнит-тесты, хотелось бы понять, что в действительности можно ожидать от тестов.
В первой части мы рассмотрели примеры тестов, из которых не все одинаково полезны. Затем попытались определиться, что же такое качество ПО, и предложили "распрямлять" код. Рассмотрели классификацию ошибок.
Теперь рассмотрим, как использовать типы, чтобы реализуемая программа сразу гарантированно соответствовала предъявляемым требованиям.
В первой части мы рассмотрели примеры тестов, из которых не все одинаково полезны. Затем попытались определиться, что же такое качество ПО, и предложили "распрямлять" код.
Теперь посмотрим, от каких ошибок защищают тесты, а от каких — другие инструменты из арсенала разработчика.
В первой части мы рассмотрели примеры тестов, из которых не все одинаково полезны. Затем попытались определиться, что же такое качество ПО, и как подходить к вопросу тестирования с системной точки зрения.
Теперь рассмотрим один из аспектов разработки, позволяющий уменьшить необходимое количество тестов — "прямолинейность" кода (как понятие, противоположное цикломатической сложности).
Сталкивались с тестами, которые толком ничего не тестируют? А тесты, которые что-то тестируют, но при этом всё равно постоянно возникают баги? Может быть, тесты, которые приходится каждый раз исправлять?
Несложно построить тест, обеспечивающий 100% покрытие, но при этом ничего не проверяющий и не гарантирующий. (См., например).
Проблемы юнит-тестов уже затрагивались на Хабре ранее:
В заметке рассматривается несколько разновидностей бестолковых тестов, а также некоторые ограничения самой идеи тестирования. А затем (в следующих частях) предлагаются разумные, на взгляд автора, меры обеспечения качества программ, включающие как уменьшение количества малополезных тестов, так и применение тестов там, где они уместны.
Это обзорная статья, в которой очень поверхностно и не подробно рассказывается о том, что такое формальная верификация программного кода, зачем она нужна и чем она отличается от аудита и тестирования.
Формальная верификация — это доказательство с использованием математических методов корректности программного обеспечения.
Формальная верификация молода. На сегодняшний день, на сайте хабр, например, нет (пока) специализации «Формальная верификация», нет специальности «Proof инженер» или «Специалист по формальной верификации». А люди, работающие по этой специальности — есть.
Программное обеспечение, которое прошло формальную верификацию считается надежным. Формальная верификация дает (с математической точностью) гарантии того, что программный код не будет содержать конкретных ошибок, что функции будут вести себя так, как ожидается.
В основе формальной верификации лежат математические методы. Слово «формальный» в названии - это отсылка к математике. Для доказательства утверждений о программном коде используются формальные методы математики: математическая логика, лямбда исчисление, теория категорий, математический анализ, алгоритмы для работы с функциональными и императивными структурами данных.
Инструменты для верификации — это программные средства для доказательства теорем (Coq, Isabelle ...), а также SAT-solvers.
В 70х годах предки формальной верификации — это доказательства простых утверждений о программе (конкретной функции) с помощью ручки и листка бумаги. Сегодня — это (иногда многолетние) исследовательские проекты для конкретного программного обеспечения, вот некоторые из них:
Привет! В первой и второй частях я поделился историей создания python библиотеки convtools (кратко: позволяет декларативно описывать преобразования данных, из которых генерируются python функции, реализующие заданные преобразования), сейчас расскажу об ускорении частных случаев datetime.strptime и datetime.strftime, а также о том интересном, что встретилось в datetime модуле по дороге.
Статья предлагает взглянуть на опыт разработки парсер комбинаторов для Python, что вылилось в библиотеку PGPC для разработки парсеров на Python. Библиотека была вдохновлена Parsec.
Особый интерес представляет эмуляция do-нотации через Python генераторы, отсюда и название библиотеки: Python Generator based Parser Combinator library.
