My latest talk, given at Craft Conf in Budapest. There were some technical difficulties, but it should hopefully serve as a reasonable introduction to the virtues of interactive development in Clojure. https://m.youtube.com/watch?v=i_dUvhEIGBQ

radicalizing the youth

Programming languages are just tools that help programmers create machine code. REPL-driven development, GC, etc. are, also, tools that speed up program development. CompSci has become overly-focused on only a single issue - that of polishing the tool called FP (including "type checking"). I vote that we go back to building workflows that allow programmers to do their work faster and to punt niggly issues like "efficiency" and "only-part-of-the-problem-correctness" to specialists who work after-the-fact at honing products before release, in a manner found in other Engineering disciplines that are no longer considered to be cottage industries (like Civil Engineering, etc.)

@Jack Rusher For what kind of audience?

@Konrad Hinsen There was, sadly, almost no audience. It was a ~6 track conference, and they put me in the closing slot against the most well known speakers/after most people had left, so there were only ~10-12 people in the audience. My hope is that the video can carry the message...

It's a nice excuse to wander around Budapest though 🙂 Look forward to watching this later

Wow, thank you. I really appreciate the format, and I'm impressed how you so skillfully created a space where we the audience got invited to take part of an often private/invisible/isolated part of programming. Some thoughts and praise: It can be really hard to communicate the practice, the experience, of a process. To communicate how time passes differently using a particular tool or workflow, when that communication is mediated by a format outside the domain of workshops/courses/participatory practices. In those cases, one of the best ways to communicate these sensations of time, is by actually using time. And it can feel vulnerable to ask for other people's time. To make the choice to not speed up or cut out parts for brevity. I know, because I've studied music composition, where I've both listened to and written music that asks of the listener than what is usually socially acceptable to "require" when communicating ideas. So, because of this I'd like to express my reassurance by saying "yessss". You did great. Such an effective and engaging way to actually get a feel for the differences, not just leave with a "huh, yeah I guess that would be cool in theory". I feel humble and grateful to have been let into and guided through this in real time. Some links/other associations: 1) I had a similar "yesss" feeling when watching Tantacrul's talk on the collision when open source processes and design standards historically have met (my reading) — where he around 20 minutes in takes the time to watch footage of user testing together with the audience. Those minutes spent communicate so much more than any slides of bullet points, statistics or feedback forms. Its such a under-utilized tool in talks, and I'm all for it. 2) I'm also thinking of Andrew Sorensen's — which I feel shares some kind of DNA with your practice. He performs in real time to surface not only qualities of the programming system's "technical" parts and their musical affordances, but also its value as a communication entry point into rather complicated concepts of the domain. 3) And lastly, a bit more esoteric, is that I'm thinking of Grounded Theory's (I've mostly been exposed to Kathy Charmaz Constructivist development of the method) emphasis on embracing the difficulty of describing anything. Favoring taking the time to get acquainted with the subject matter, and being realistic about the difficulty of describing and communicating it. Resisting the status quo that descriptions/theories/models are better communicators than presenting and guiding the reader through the actual data* *_in my understanding_ — with reservation that this is six year old recalled knowledge from discussions during my mother's dissertation