Добрый день! Я начинающий фулстек-разработчик, и это моя первая статья.
Сегодня я хочу рассказать, как сделать функциональные компоненты в реакте чуть более функциональными, а именно как сделать каррирование функционального компонента.
Предупреждение: в статье использованы как функциональные, так и классовые компоненты.
Здравствуйте, уважаемые хабровчане. Меня зовут Вадим Писаревский, я являлся лидером OpenCV (Open Source Computer Vision Library) на протяжении примерно 20 лет, и продолжаю участие в этом замечательном проекте. В этой статье я рад представить вашему вниманию результат другого своего проекта, над которым в фоне работаю уже много лет, а последние пару лет как минимум половину своего рабочего времени.
В этой заметке я хочу поделиться элегантным решением одной задачи с сайта-хрестоматии RosettaCode. Речь пойдёт о программе, вычисляющей функцию Минковского — одного из инструментов теории чисел и динамических систем. Несмотря на то, что реализовать эту функцию относительно несложно (её код даже приводится в Википедии), имеет смысл подняться на достаточно высокий уровень абстракции, для того, чтобы увидеть предельно простое решение этой задачи. Ну, и получить удовольствие от красоты математики и языка Haskell.
Этот рассказ может быть интересным тому читателю, кто подобно мне, радуется обнаруживая "автомагические" решения, в которых точно подобранные структуры и абстракции, при помощи содержащейся в них математической основы, решают задачу как бы сами собой, гарантируя корректность этого решения.
Сначала мы обсудим саму функцию Минковского, потом разглядим в её действии изоморфизм между двумя алгебраическими структурами и уже с этих позиций напишем короткую программу на Haskell, и, конечно, обсудим что нам с этого всего будет.
Исключения – это базовый элемент многих языков программирования. Они обычно используются для обработки аномальных или непредусмотренных условий, при устранении которых необходим особый подход, нарушающий нормальный поток задач в приложении. В некоторых языках, например, в C++ или Java, исключения используются повсюду. Но не все языки спроектированы так. В C# или Kotlin нет проверяемых исключений. В других языках, например, Go и Rust, исключений нет вообще.
Думаю, код, выбрасывающий исключение всякий раз, когда произойдет что-то неожиданное, сложен для понимания, и его тяжелее поддерживать. В этой статье я хочу рассказать о типе данных Either как об альтернативном способе обработки условий, приводящих к ошибкам. Примеры в этой статье даны на Kotlin, поскольку, на мой взгляд, за его синтаксисом легко следить. Но сами концепции не уникальны для Kotlin. Их, так или иначе, можно реализовать в любом языке, поддерживающем функциональное программирование.
Надоели нестабильные баги в многопоточном коде? Попробуй воспользоваться модел-чекерами! Ведь больше не надо бояться неверифицированных модел-чекеров, работающих либо за экспоненциальное время, либо неоптимально. Все это в прошлом: в Max Planck Institute for Software Systems разработали новый алгоритм под названием TruSt, который решает эти проблемы и, кроме того, верифицирован на Coq.
Меня зовут Владимир Гладштейн. Этим летом я проходил стажировку в MPI-SWS в группе, которая придумала алгоритм нового модел-чекера для поиска багов в многопоточных программах. Этот алгоритм является оптимальным и truly stateless (вследствие чего работает с линейными затратами по памяти). В этом посте я расскажу, как работают модел-чекеры, в каких случаях их можно использовать, и что за алгоритм придумали мои коллеги. А еще как я проверял доказательства его корректности на Coq.
Современные языки программирования обладают большим набором разнообразных средств и удобных фишек, что позволяет писать совершенно разный код на одном и том же языке для одной и той же задачи.
Парадигма программирования — это в первую очередь стиль мышления: то, как программист думает о представлении данных и процессе их обработки. Другими словами, парадигма живёт в голове программиста, а не является свойством языка. Разные языки могут в той или иной степени поддерживать определённую парадигму. Если сейчас зайти на Википедию и начать читать про самые популярные ЯП, мы увидим, что многие из них заявлены как "мультипарадигменные": на них можно писать в разных стилях, но какие-то из них использовать будет удобнее.
В своей недавней статье мы рассказывали о практических применениях Лиспа и упомянули, что он сильно повлиял на развитие других языков программирования, но не стали вдаваться в детали. Пришло время более подробно раскрыть эту тему и разобраться, какой вклад функциональное программирование в целом (не только Лисп!) внесло в развитие других языков. Поскольку мы используем Haskell как основной язык разработки, и наша команда разработчиков состоит из ФП-энтузиастов, мы не смогли пройти мимо такой темы.
В этом посте рассмотрим несколько механизмов, которые либо зародились в ФП-языках, либо нашли в них наибольшее применение и были ими популяризованы, и в итоге появились в языках, изначально не функциональных.
Облачные сервисы уже давно стали неотъемлемой частью нашей жизни. На данный момент существует большое количество сервисов от разных компаний. Так давайте разберемся в принципах работы простейшего облачного сервиса, подтянем навыки проектирования систем. Данный проект можно постоянно развивать на протяжении длительного времени, и может стать отличным pet project. Созданное облако может пригодится для управления домашними файлами, достаточно его развернуть в локальной сети и с легкостью получать доступ к файлам с разных устройств.
Прыгайте под кат за подробностями.
Haskell это чистый функциональный язык программирования общего назначения со статической типизацией и ленивыми вычислениями. Появился в 1990 году и был назван в честь Хаскелла Карри. На данный момент основной реализацией является компилятор GHC.
Мы в Typeable очень любим этот язык и используем его как основной язык разработки. Хотя Haskell уже достаточно широко используется в индустрии, всё ещё бытует мнение, что это академический язык и применяется исключительно в научных целях. В этой статье я бы хотел рассказать про несколько достаточно популярных инструментов, которые написаны на Haskell и могут оказаться вам полезны.
Привет! В первой части я поделился мыслями, которые побудили к созданию python библиотеки convtools. Кратко о ней: предоставляет примитивы (конверсии), объединяя которые, можно описывать сложные конверсии для обработки данных. Конверсия генерирует узкоспециализированный код, компилирует его и возвращает функцию, решающую конкретную задачу.
В этот раз хотелось бы подробнее остановиться на двух моментах:
1) как pipe позволяет повысить переиспользуемость кода
2) новая часть библиотеки: Table - потоковый обработчик табличных данных
Во многих языках есть специальный механихм для кодогенерации - макросы. Иногда из реализуют на отдельном достаточно примитивном языке, основанном на простой подстановке текста (препроцессоры PL/I и C, m4), но даже в таком варианте удается делать интересные и полезные вещи. Другой популярный вариант - макросы реализуются на том же языке, что и программа, в которой они используются. Такой подход ведет свое начало из Lisp (удобный тем, что формат программ и данных там одинаков), активно применяется в Julia, OCaml(camlp4/5), Scala, Haskell, Rust, а наибольшего развития получил в Nemerle, где макрос может может запускаться как до, так и после проверки и вывода типов, и в последнем варианте иметь доступ к типам.
При этом макросах все возможности языка не нужны, скажем высокая эффективность и безопасность Rust пользы здесь не принесут и могут только затруднить разработку.
На работе я пишу почти исключительно на Python, с университетской скамьи остались некоторые знания C/C++, в одном pet-project использовал Haskell. С таким багажом знаний я взялся за написание компилятора на основе LLVM - зачем и что получилось я уже рассказывал в предыдущей статье.
Эту статью я пишу для тех, кто, как и я, заинтересован в изучении Haskell, создании собственных языков программирования, или хочет поиграться с LLVM - но не знает с какого конца подойти к задаче.
Я кратко расскажу про необходимый минимум знаний Haskell, про свои ошибки и к каким решениям я пришел - а так же про решения, к которым я не пришел, и про которые узнал позже - и как их можно интегрировать в ваш pet-компилятор. На все это я по возможности дам ссылки на изучение.
Современные языки программирования всё чаще становятся мультипарадигменными, и Kotlin не исключение. С появлением Jetpack Compose наблюдается уход от ООП в функциональное программирование. Изучая новые средства разработки, такие как Jetpack Compose, давайте вспомним и те, которым уже около 60 лет. А главное — разберёмся, как их можно применить к современным подходам для получения большей эффективности.
Лисп — второй по старшинству из ныне живых высокоуровневых языков программирования (после Fortran) и первый функциональный язык. Он был разработан в 1958 году и сильно изменился с тех пор, породив множество диалектов и оказав значительное влияние на развитие других языков. На данный момент наиболее известные диалекты: Common Lisp, Scheme, Racket и Clojure.
Слева: Лисп-машина в музее MIT.
Справа: Лисп-машина Symbolics 3640, фото Michael L. Umbricht и Carl R. Friend (Retro-Computing Society of RI)
Лисп стал “первооткрывателем” многих идей, нашедших применение в современных языках программирования: древовидные структуры, динамическая типизация, функции высшего порядка и многое другое. В этом посте мы не будем углубляться во вклад Лиспа в теорию, а сосредоточимся на практической пользе.
Изначально Лисп предназначался для работ в области искусственного интеллекта, в частности как представление математической нотации для символьных вычислений. Но насколько широко диалекты Лиспа используются сейчас и в каких областях применяются?
Мы в Typeable любим и применяем функциональное программирование, а влияние Лиспа на функциональные языки всё ещё сильно, поэтому нам стало интересно разобраться в этом вопросе.
Перед началом хочу позволить себе небольшой, но важный дисклеймер.
Я не стараюсь вам продать этот cпособ как панацею.
Я лишь хочу рассказать вам ещё один способ представлять данные и показать, как его можно использовать, на конкретном примере.
Как и все остальные подходы, этот имеет свои недостатки. И кое-где придётся приседать. С этими приседаниями мы встретимся довольно скоро.
«Не думайте, что я сейчас буду развивать эту концепцию, а затем разочаруюсь в ней. Такой драматургии не будет. Я изначально уже в ней разочарован.»
Роман Михайлов
Ещё хочется заметить, что далее все примеры кода будут приводиться на Haskell. Но в конце я покажу, как можно некоторые из них повторить на Scala.
Конечно, прежде, чем писать этот раздел, я полез в интернет, чтобы посмотреть, как этот термин определяют другие люди. Чёткого определения я не нашёл.
Грубо говоря, HKD — это то, что предоставляет возможность держать в одном типе данных сразу несколько представлений. Давайте посмотрим на примеры.
Привет! Это вторая часть рассказа о том, как мы поддерживали язык Frege в IntelliJ IDEA. Первую часть читайте здесь. Сейчас мы поделимся, как сделали автодополнение, систему сборки, интерпретатор и систему типов. И как все это тестировали.
В этом посте мы расскажем, как реализовывали плагин для поддержки функционального языка Frege в IntelliJ IDEA. Если вам интересно, как IDE от JetBrains работают внутри, или вы хотите поконтрибьютить в языковые плагины (а может даже написать свой!), эта статья для вас. Мы пройдемся по этапам создания языкового плагина для IDEA, расскажем, с какими трудностями столкнулись, и как подружили этот язык с JVM-миром.
В процессе написания программ мы часто сталкиваемся с данными, для которых возможен только ограниченный набор значений. Например, возраст, который не может быть отрицательным или email, который может иметь только определенный формат строки.
Эта статья является переводом материала «Immutable architecture».
В этом посте автор оригинала хотел бы показать общий подход к внедрению иммутабельности в кодовую базу на архитектурном уровне.
Прежде всего, термин «Иммутабельность», применяемый к структуре данных, такой как класс, означает, что объекты этого класса не могут изменяться в течение их жизненного цикла. Существует несколько типов иммутабельности со своими нюансами, но это не являются для нас существенным. По большей части мы можем сказать, что класс является либо изменяемым, что означает, что его экземпляры могут изменяться тем или иным образом, либо иммутабельным (неизменяемым), что означает, что как только мы создадим экземпляр этого класса, мы не сможем изменить его позже.
Автор статьи: klntsky
Property-based testing (PBT) — подход к тестированию ПО, подразумевающий автоматическую проверку свойств функций (предикатов), специфицируемых программистом-тестировщиком. Для проверки, т.е. поиска контрпримеров, используются автоматически сгенерированные входные данные. PBT позвляет разработчикам значительно увеличить тестовое покрытие и эффективно расходовать своё время, не придумывая входные данные для тестов самостоятельно. В общем случае данные, генерируемые во время property-based тестирования, ничем не ограничены, поэтому проверка может быть произведена на тех значениях, про которые разработчик мог забыть или для которых не счёл нужным написать юнит-тесты (действительно, не перебирать же все значения входных параметров вручную).
PBT-подход был популяризован библиотекой QuickCheck, написанной на Haskell, и в этой статье будет показано, как пользоваться этим инструментом эффективно.
Эта статья является переводом материала «What is functional programming?».
В этой статье Владимир Хориков попытается ответить на вопрос: что такое функциональное программирование?
Итак, что такое функциональное программирование? Этот термин возникает довольно часто, и каждый автор, пишущий о нем, дает собственное объяснение. На взгляд автора оригинала, самым простым и в то же время точным определением является следующее: функциональное программирование - это программирование с математическими функциями.
Математические функции не являются методами в программном смысле. Хотя мы иногда используем слова «метод» и «функция» как синонимы, с точки зрения функционального программирования это разные понятия. Математическую функцию лучше всего рассматривать как канал (pipe), преобразующий любое значение, которое мы передаем, в другое значение
