Haskell *

Здесь просто мысли… даже, скорее, гипотеза, которая давно жила во мне, и в связи со статьёй Типы и тесты нашла, наконец, какой-то выход. Это не первый раз, когда я сталкиваюсь со спором между (условно) "типизаторами" и "тестировщиками", в одном или двух даже участвовал.

И у меня возникла ощущение, что для "типизаторов" центральное место в разработке занимает проблема правильности. Программа, которая "работает правильно" только в некоторых случаях, судя по всему, для них похожа на стоящие часы — да, они пару раз в сутки показывают правильное время, но на самом деле они же не работают!

Отсюда логично выплывает идея разработки как сборки системы из уже доказанно-правильных кусков. Если их ещё и собрать правильно, то и вся программа будет правильной. Такими "кусками" являются типы.

Данная трактовка, возможно, является ошибочной — знатоки Type-Driven Development меня поправят.

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

Но на самом деле суть Test-Driven Development к тестированию имеет очень мало отношения. TDD следует воспринимать как воплощение стратегии "разделяй и властвуй": давайте сначала напишем программу, которая будет правильно вести себя всего в одном случае; потом добавим ещё один и попробуем обобщить реализацию; если результат не удовлетворяет, добавляем ещё один и снова обобщаем… — до тех пор, пока мы не будем вполне уверены в том, что написали практически правильную программу.

Да, здесь ставится немного другая цель — не написать такую программу, которая всегда работает правильно, а такую, которая лишь на практике работает правильно.

Очевидно (для меня), что Test-Driven Development — это построение программной системы по индукции.

Можно ли тогда утверждать, что Type-Driven Development — это построение программной системы по дедукции?

 Привет, Хабр!

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

Наша команда разработки прошла этот путь и основываясь на накопленном опыте, создала структурированную программу обучения. У нас в MetaLamp уже есть успешный опыт создания подобных программ: мы сделали программу обучения для фронтенд и бекенд разработчиков.

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

Сейчас у нас появилась 3-я ветка программы, приглашаем всех, кому интересно обучиться на разработчика смарт-контрактов для EVM-сетей и погрузиться в мир Solidity!

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

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

Welcome!

Представлен выпуск GHC 9.4.6 (Glasgow Haskell Compiler), компилятора для функционального языка программирования Haskell, обеспечивающего эффективное распараллеливание вычислений и поддерживающего программную транзакционную память (STM, Software Transactional Memory). В компиляторе реализована полная поддержка спецификации Haskell 2010 и многочисленных языковых расширений.

Компилятор поддерживает генерацию исполняемых файлов с машинным кодом, формирование байткода или трансляцию в исходные тексты на языке C. Код проекта написан на языке Haskell и распространяется под лиценизей BSD.

Основные изменения в этом выпуске:

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

• исправление ошибок проверки типов, включая семейства экземпляров newtype, улучшение работы сравнения типов и работа над ошибками по представлением по умолчанию переменных с полиморфными типами.

• исправления кодогенерации, в частности для архитектуры aarch64, включая увеличение числа барьеров памяти для операций чтения массивов.

• исправления ошибок сборки под Windows, улучшение надёжности выключения менеджера IO и исправление ошибок для RTS-линковщика под Windows.

• исправление ошибок для корректного учёта выделения мутаторов и неперемещающего сборщика мусора.

• предотвращение некоторых ошибок сегментации связанных с закреплёнными выделениями.

Источник: OpenNET.