Haskell *

Есть довольно простая идея, высказанная Фейнманом — цель физики найти простейшую теорию, которая сможет объяснить как можно больше явлений природы. Эта та идея, которая стоит за электродинамикой Максвелла или КЭД. Каждая новая большая теория объясняла больше явления природы и при этом была проще предшественников.

Это довольно простая мысль с далеко идущими последствиями. Так почему бы нам (инженерам) не взять ее на вооружение? Почему одни из лучших идей про разработку еще не формализованы и унифицированы, как тот же KISS или DRY? Они что, по сути не формализуемы? Это не может быть так если мы возьмем во внимание тот факт что информатика это раздел математики. Должен быть какой-то способ вывести эти пресловутые лучшие практики. И может, если у нас получиться вывести те что мы знаем по опыту, мы сможем выводить совершенно новые. В других научных дисциплинах именно это и происходило — ярче всего это было в авиации. Сначало, опытным путем, инженерам получилось построить то что хоть как-то да отрывается от земли, и только после физика крыла реально была изучена. С этой новой физикой мы имели просто взрывной рост отрасли.

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

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

В статье [ссылка] было заявлено, что производительность Haskell кода превзошла код на С++. Что сразу вызвало интерес, т.к. и то и другое может генерироваться LLVM компилятором, значит либо Наskell может давать больше хинтов компилятору, либо что-то не так с С++ реализацией. Далее мы разберём, как череда случайностей в действиях автора привела к неправильным выводам, которые описываются таблицей ниже (под катом).

После недавних статей (№10xd34df00d, №2chapuza, №3picul) сравнивающих скорость работы реализаций упрощенной утилиты wc у меня оставался только один вопрос — Как простая реализация на Haskell оказалась быстрее простой реализации на C ?!

2020-02-27: Подтверждены результаты и выводы для ghc 8.8.3 и на текстах Шекспира (в конце под спойлером).

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

В Serokell мы занимаемся не только коммерческими проектами, но стараемся изменить мир к лучшему. Например, работаем над улучшением главного инструмента всех хаскелистов – Glasgow Haskell Compiler (GHC). Мы сосредоточились на расширении системы типов под впечатлением от работы Ричарда Айзенберга "Зависимые типы в Haskell: теория и практика".

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

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

Команда Serokell с богатым опытом разработки крупных блокчейн проектов не могла остаться в стороне. Мы делегировали на конкурс пятерых сотрудников, а уже через две недели они заняли в нем первое место под (не)скромным рандомным ником Sexy Chameleon. В этой статье я расскажу о том, как им это удалось. Надеемся, за ближайшие десять минут вы как минимум прочитаете интересную историю, а как максимум найдете в ней что-то полезное, что сможете применить в своей работе.

Но давайте начнем с небольшого погружения в контекст.

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

Зарегистрировавшись в системе, моё внимание сразу привлекла возможность решать задачи на Haskell. Дело в том, что я хоть и увлекаюсь программированием на этом языке, но не продвинулся дальше реализации задач из различных курсов образовательных on-line платформ. Решив, что их решение может оказаться интересным вызовом и повысит мой уровень, как разработчика, я приступил к их решению.

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

Disclaimer: да, в понедельник мы опубликовали хабрапост с именно таким сравнением языков. Нет, мы не сошли с ума. Всё идёт по плану.

• Преподавание и знакомство с JavaScript;
  
• Зачем выбирать Haskell;
  
• Место функциональных языков в жизни программиста;
  
• Чего хорошего в JavaScript и как он развивается;
  
• Что появится в языках программирования в ближайшие 10-15 лет;
  
• Какие языки программирования вызывают доверие и почему;
  
• В чем разница между научными конференциями и конференциями для разработчиков. Зачем преподавателю вообще на них ходить;
  
• Важно ли читать программисту, устаревают ли книги и какие из них must read.
  

Как я писал в предисловии предыдущей статьи, я нахожусь в поисках языка, в котором я мог бы писать поменьше, а безопасности иметь побольше. Моим основным языком программирования всегда был C#, поэтому я решил попробовать два языка, симметрично отличающиеся от него по шкале сложности, про которые до этого момента приходилось только слышать, а вот писать не довелось: Haskell и Go. Один язык стал известен высказыванием "Avoid success at all costs"*, другой же, по моему скромному мнению, является полной его противоположенностью. В итоге, хотелось понять, что же окажется лучше: умышленная простота или умышленная строгость?

Я решил написать решение одной задачки, и посмотреть, насколько это просто на обоих языках, какая у них кривая обучения для разработчика с опытом, сколько всего надо изучить для этого и насколько идиоматичным получается "новичковый" код в одном и другом случае. Дополнительно хотелось понять, сколько в итоге мне придется заплатить за ублажание хаскеллевского компилятора и сколько времени сэкономит знаменитое удобство горутин. Я старался быть настолько непредвзятым, насколько это возможно, а субъективное мнение приведу в конце статьи. Итоговые результаты меня весьма удивили, поэтому я решил, что хабровчанам будет интересно почитать про такое сравнение.

Введение

Мне стало скучно писать на Python, захотелось чего-нибудь необычного. Решил попробовать Haskell. Языка я не знаю, однако просто писать консольные учебные программы, типа вычисления факториала, не хотелось. После изучения довольно большого числа постов про Haskell и его применения в реальной жизни, я понял, что одна из потенциальных точек роста популярности языка — написание web-приложений. Как ни странно, под Haskell есть довольно много web-фреймворков. Мой выбор пал на Spock, потому что, судя по описанию, это простой и быстрый в разработке фреймворк. У меня есть некоторый опыт написания web-приложений на Flask, поэтому я подумал, что будет интересно сравнить такие непохожие подходы в решении похожих задач. В статье я постараюсь максимально подробно изложить свой путь проб и ошибок в изучении Haskell на примере написания простейшего web-приложения на Spock. Возможно, это будет полезно для тех, кто сомневается, пробовать ли изучать Haskell и будет ли он полезен в реальной жизни.

Предлагаю вашему вниманию перевод замечательной свежей статьи Джастина Ле. В своём блоге in Code этот автор достаточно легким языком рассказывает о математической сути красивых и изящных функциональных решений для практических задач. В этой статье подробно разбирается пример того, как перенос математической структуры, которую образуют данные в предметной области на систему типов программы, может сразу, как писали Джеральд и Сассман "автомагически", привести к работающему решению.

Приведённый на картинке код — это полноценная самодостаточная, расширяемая реализация парсера регулярных выражений, написанная "с нуля". Высший класс, настоящая магия типов!