HN Theater @HNTheaterMonth

This was superseded by Sonic Pi https://sonic-pi.net/.

The author has said that if he would do it in Erlang if he was starting again now.

Here's a talk with him and the late Joe Armstrong. https://www.youtube.com/watch?v=4SUdnOUKGmo

⬐ hwers

I might be getting this wrong didn't overtone come after sonic pi and was supposed to be an improved version of that?

⬐ david_allison

One of my favourite talks has a demonstration of FizzBuzz in Sonic Pi. It still blows me away

https://www.youtube.com/watch?v=6avJHaC3C2U - whole talk is worth a watch

https://www.youtube.com/watch?v=6avJHaC3C2U#t=42m25s - timestamp

Didn't Joe Armstorng use this to DJ at a Erlang User Conference? Can't find it now, but at least there is this talk from a years ago: https://www.youtube.com/watch?v=4SUdnOUKGmo

⬐ francescoc

It was a keynote he did together with Sam. Loved it....

⬐ francescoc

This is another keynote from CodeMesh in memory of Joe joining together the tiddly wiki and the SonicPi, by Sam, Erlang co-inventor Robert Virding and tiddly wiki inventor Jeremy Rushton: https://www.youtube.com/watch?v=aUji_DlXjm8

⬐ elsurudo

What a fun duo – great presentation overall. I love the way in which they glue different software together in ways that were never intended to get some awesome results.

There's something really satisfying about hearing that Moog play the first note driven by Sonic Pi.

⬐ exabrial

Recently saw this dj live at Java1! Pretty amazing

⬐ rdtsc

I like the idea of teaching distributed programming using music. I imagine some people are more auditory than visual.

Also like that Joe is still experimenting and coming up with outrageous stuff like "Instead of a process playing all the notes, spawn a process for each note and make it play that note and then stop".

It seems like a silly idea, but what he's getting at is with the ability to create independent concurrent building blocks you can start to think about problems in completely a different way. Quite often that models your problem space the closest, and then there is less impedance mismatch between your problem space the implementation.

For example you start with adding items to a shopping cart, and instead of worrying about business logic, you're now stuck debugging locks, threads, futures and promises, etc. At the end of the process you see that there are maybe 10 lines which describe the actual business logic but there are 1000 lines managing the impedance mismatch.

⬐ mikhailfranco

Yes, I might have thought of one process per instrument, but not one per note. Outrageous but fascinating.