Сохряню тут, раз уж старался, писал. Это из чата про #elm.

--
Хаскелисты Rust ругают частенько за недофункциональность - изначально императивный язык, да-да! Но в Rust есть многое, что присутствует в больших ФП-языках, и это не "эти ваши академические штучки", а исключительно полезные вещи - я про traits и ограниченный параметрический полиморфизм говорю. Да, в Rust нет HKT и не будет никогда, скорее всего. Но даже то, что есть, очень сильно помогает управлять сложностью через абстракцию.

И именно средства для управления сложностью кода делают язык пригодным для реализации на нём действительно больших проектов!

С этой точки зрения плох Go - абстрагирование там не в чести и встроенные средства для построения абстракции очень бедны (из, можно сказать, нет). А это означает, что большие проекты состоят из копипаст (в т.ч. и из копипаст ошибок!) и местных велосипедных ренеший (в Go тоже не принято переиспользовать чужой опыт, культура поощряет "скопировать к себе если уж сам не хочешь писать"). Процедурные языки имеют инструмент, созданный для управления сложностью - ООП. Да, "правильно готовить" его умеет не каждый, но инструмент очевидно работает - иначе его бы выбросили на свалку истории. В Go нет ООП но и нет альтернативы.

Теперь смотрим на ФП. Было когда-то сказано "лучше иметь один тип и сто функций для работы с ним, чем десять типов и по десять функций для работы с каждым" - сказано это было в контексте Lisp, но работает и для ФП в целом. И если "один тип на все случаи жизни", это странная идея, то вот единый вокабулярий для работы с разыми типами, это отличная вещь!

И вот тут мы подходим к Elm. Единый вокабулярий отнюдь не означает "у нас везде map, просто это List.map, Maybe.map и т.п." - это разные функции для работы с разными типами. Т.е. нет возможности писать обобщённый код. И абсолютно не важно здесь, как эти функции называются (пусть даже и понятно и "читаемо")! Нельзя написать "библиотеку, которая обобщённо работает с коллекциями" и подобные сугубо полезные в реальных проектах вещи!

И всё только осложняется тем, что в Elm типизация статическая. Потому что в динамически типизированном ЯП мы можем хотя бы ad hoc полиморфизм силами "утиной типизации" сделать или на крайний случай прямо в функции решить, как с переданным типом работать (не сильно гибко и точно не особо расширяемо, но относительно обобщённый код писать позволяет). А при старической типизации в Elm мы имеем лишь "неограниченный" параметрический полиморфизм: мы всегда всё знаем о структуре, но никогда о "содержимом" типа. А значит мы не сможем без привнесения излишней сложности написать, скажем, функцию sort : List a -> List a - мы по построению не знаем ничего об a и не можем знать при текущей модели. Да, местный ad hoc есть в виде comparable, но с чего это автор решил, что ad hoc полиморфизм нужен только в тех местах, где он сейчас есть? Примеров могу привести много - и все из реальной жизни.

Так что же хорошего в том, что мы имеем ФП, но такой, где функции (и типы) пользователя - объкты второго сорта; где автор решил, что такие-то типы comparable, а пользовательские - нет; где автор stdlib может писать обобщённый код - внутри stdlib - а пользователи не могут?! И не нужно говорить о "сложности для новичков" и "те, кому надо, пойдут в другие языки" и в этом же контексте "у нас - успешный язык для решения реальных задач!". Это лукавство. Потому что зрелый язык помогает решать проблемы, а не создаёт искуственно препятствия для решения оных.
--

P.S. Это похоже на "нытьё", но я правда так считаю. Часто бываю непонят или неуслышан.

Отличное короткое объяснение "что есть ADSR": https://www.youtube.com/watch?v=JT6rixgu4s4
Прекрасно подходит для того чтобы сослаться на него, если вдруг кто спросит. Поэтому "заложу" сюда :)

P.S. Канал, кстати, отличный, если вам нравится синтез звука (мне - нравится).

#music #synth

Внезапная минутка лёгкого красноглазия: https://lpicentral.blogspot.com/2018/08/10-useful-ncat-nc-command-examples-for.html
По ссылке набор рецептов для использования netcat так и эдак. Присутствуют и обычные сценарии вида "поднимаем чатик мужду двумя машинами", но есть и поинтереснее варианты, например двунаправленное проксирование (через fifo-девайс).

Сам я netcat пользую редко, но иногда с немалой пользой. Однажды я даже передавал по сети видео-поток (с embedded компутера формата PC104), а на принимающей стороне воспроизводил силами mplayer - стриминг, однако! Не то чтобы это было очень нужно, но работало и как минимум было забавно!

#unix #cli #networks

Меллотрон в деталях: https://www.youtube.com/watch?v=ByD8gH7kYxs
Именно такой The Beatles использовали в "Strawberry Fields Forever"
Очень своеобразная железка, люблю такое.

#music #synth

Захотелось недавно #generative_art потворить.

Сначала взял #elm. Наткнулся на проблему с фатальным недостатком подхода к генерации случайных значений в стандартной библиотеке (которую можно решить сторонней либой, но я тогда про неё ещё не знал). Потом ещё и 0.19 вышла, где "всё сломали". И на package.elm-lang.org теперь меня не пускает без проксирования.

Решил, "хватит с меня Elm, слишком сложно для простой задачи погенерировать картинки".

Вспомнил про Quil - это такая надстройка над Processing/ProcessingJS, которые как раз и предназначены для generative art. Подумал, "Пусть без типов, но и результат сразу виден, так что проживу как-нибудь". "Расчехлил" lein, создал проект из шаблона, запускаю REPL. Внутренняя ошибка внутри либы.

Пошел смотреть в Issues. Оказалось, что проблема с #processing: оный не работает на Java 9+. Что-то у них сломалось из-за изменений в рантайме. Но чинить совместимость с Java 9 смысла нет, потому как она уже не поодерживается. А в последующих версиях уберут (убрали уже?) средства для работы с GUI - по крайней мере те, которые используются в Processing. Авторы Processing не знают, когда получится сделать поддержку какой-то из более поздних версий рентайма. Вот такая вот стабильная платформа с долгим сроком поддержки...

Может быть я ещё вернусь к Quil - #clojurescript-версия использует ProcessingJS. Но эта библиотека отстаёт по фичам от "старшего брата". ClJS не умеет макросы в рантайме. Есть и пачка других ограничений. Да и toolchain вокруг ClJS не вызывает у меня приятных воспоминаний. А когда хочется "быстренько покреативить", то отвлекаться на настройку инструментария не хочется совершенно...

В итоге я взял #racket. И там просто всё работает :) Да, есть своя специфика и язык менее красив, чем #clojure. Но графическая библиотека 2htdp/image - отличная. В JS не скомпилить, поэтому в браузер генераторы картинок уже не экспортируешь. Но жажду творчества утоляет :)

Обычно #racket я пользую через DrDacket - родную среду разработки с отличным REPL и возможностью "копипастить картинки из интернета" :)

Выглядит этот REPL так (котика я скопипастил из интернетов - это маскот языка Scratch)

В моём любимом #emacs тоже есть поддержка #racket, и даже картинки в #repl можно выводить (копировать-вставлять нельзя, увы). И как редактор кода, Emacs значительно мощнее чем редактор, встроенный в DrRacket (тот прекрасен, но в области интергированности в среду и язык).

Теперь я креативлю на Racket в Emacs :)

Вот вам #daily_art (минут 20 экспериментов в REPL, четыре строки кода (в отформатированом виде побольше, конечно)) :)

Ещё #daily_art на #racket (исходник) :) (наверняка в какой-то момент мне надоесть это постить)

Самоповтор с самоповторяющимся #daily_art (исходник) :)

Сделал на своём #web сайтике-долгострое раздел для #daily_art.

Индекс и странички генерируются с помощью shake-скрипта из mustache-шаблонов (это всё на #haskell). Подсветка синтаксиса для Racket-кода делается вызовом CLI-утилитки из пакета pygments (это уже #python). А картинки рендерятся непосредственно вызовом #racket. Вот такой вот монстр Франкенштейна :)

Загружал первую версию контента через web interface редактора сайтов прямо на NeoCites (на нём сайтик хостится). Но в будущем воспользуюсь из API - или сам реализую клиентскую часть, или официальный CLI-tool возьму (который на Ruby написан - ещё один зверь в зоопарк). А в конце это всё можно будет упаковать в Docker-контейнер для красоты и модности :)

В кои-то веки выходные провёл как настоящий программист - оба дня кодил что-то (по паре часов всего в день, но всё же ;)).

****************

В Субботу ходил во второй раз на Dojo по #clojure. В этот раз на команды разбивались случайным образом, что, на мой взгляд, значительно интереснее. И полезнее для networking - на clojure-тусовки я попадаю редко, поэтому лишний шанс познакомиться с людьми, которым небезразлично ФП, меня однозначно радует :)

В прошлый раз мы писали Conway's Game of Life: получилось это. Работали двумя парами и та, в которой был я, отвечала за логику. Сделали всё на множествах через операции над ними (пересечение, объединение). Всем понравилось.

В этот же раз писали игру 2048 втроём, поэтому решили не делиться - за одним компьютером вместе творили. Решили сделать упор на логику, а интерфейс пользователя (который сразу решили сделать текстовым ;)) оставить на потом. Логика игровая получилось довольно компактной: сделали только "сдвиг влево", а остальные операции получили через транспонирование и отражение матрицы! Тесты делать было лень, поэтому разработка проходила "по локти" в REPL, что тоже добавило веселья. В установленное время мы уложились и наша реализация 2048 вышла вполне играбельной :) У "соперников" были вариант на #clojurescript в браузере и реализация с "текстовым UI" в отдельном графическом окне (на этой штуке рогалики бы писать!).

P.S. Понравилось, планирую продолжать посещать.

****************

В Воскресенье я к генератору подсайтика с #daily_art прикрутил генерацию миниатюр. А потом решил, что текущие правила для #shake "костыльноваты" и решил переписать :) Получившийся вариант генерации динамических правил мне нравится и важные фишки shake, вроде кэширования результатов сборки, так же работают. Результат можно посмотреть тут, а здесь можно глянуть на исходники.

P.S. Надо бы написать статейку про Shake для ruHaskell.

Ещё #daily_art

https://astynax.neocities.org/daily-art/2019-09-24-circuit-board.html

Этот простенький, но мне показался интересным

Оказывается, для #racket в teachpack'е для курса HTDP, помимо библиотеки 2htdp/image, с помощью которой я свой #daily_art рисую, а также 2htdp/universe, с помощью которой можно нарисованные картинки анимировать и даже превратить в игру(!), есть библиотечка тайлов (tiles) Planet Cute в виде racket-библиотеки 2htdp/planetcute!

Сам "Planet Cute", это набор изображений "строительных блоков", с помощью которых можно делать игры. И сами изображения и исходные макеты свободно доступны. Каждый блок представлен отдельным изображением. Все изображения имеют одинаковый размер и отлично (и очень просто!) компонуются (не нужно возиться с tileset'ом). На мой взгляд, это отличный стартовый набор для начинающего игростроителя :)

P.S. Мне уже не терпится что-то написать с использованием images/universe/planetcute. М.б. даже законченную игру :)

#gamedev

Вчера поигрался с planetcute, получилось это (исходник).

Челендж #daily_art продолжается, почти каждый день "рисую"! Но проблема придумывания подписей уже начинает напрягать. Нынешнюю картинку, впрочем, поименовал сразу. Знакомьтесь, "кунжутная халва" :)

Кстати, пока я искал альтернативы для pygments, мне подкинули интересный вариант на замену: bat

bat, это такой cat(1), только написанный на #rust, и умеющий красиво подсвечивать синтаксис разных форматов файлов с помощью схем подсветки от SublimeText (использует библиотеку syntect).

Приятно, что таких проектов становится больше: rq, ripgrep, fd, а теперь ещё и bat (автор тот же, что и у fd, кстати). Я считаю, что нам нужны современные версии "рабочих лошадок", работающие быстро и стабильно - да такие, в которые и поконтрибутить приятно!

https://www.youtube.com/watch?v=y-xgWLYQc4g

Simon Peyton Jones как весгда прекрасен! И тема доклада лично меня равнодушным не оставила - всегда чувствовал в себе тягу к образованию других :) Доклад касается обучения CS в целом, также повествует про подвижки образовательной машины Великобритании в сторону правильного преподавания CS ученикам прямо со школы. Саймон призывает делать упор не на технологии, как это было в прошлом (оказывается, там тоже детей учили использованию MS Office), а на основы и идеи. В конце доклада можно найти кучу ссылко на расличные инициативы в озвученной области, а частности на Project Quantum - попытку сделать единый вопросник для тестирования изучающих CS.

Настоятельно рекомендую к просмотру!

#education #talk

Минутка #retrogaming

На Internet Archive теперь доступна библиотека игр для C64. В общей сложности 10К игр. Всё как обычно работает прямо в браузере (на обраузереном силами emscripten эмуляторе Vice).