Call for Interest: Clojure (or Lisp?) Code Camp with BLM focus

Wed Dec 2 16:47:02 UTC 2020

Hi all,

This isn't really replying to Pascal specifically -- his was just teh 
last message I received.

I guess none of you pros are also on the music-dsp list out of Columbia, 
or look around ccrma at Standford much.

Why not start with what's already out there for CL?

http://ccrma.stanford.edu/planetccrma/software/soundapps.html#SECTION00042400000000000000

Neil Gilmore
raito at raito.com

On 2020-12-02 09:28, Pascal Costanza wrote:
> Hi,
> 
> I would also consider Go. It’s actually a really good language in my
> opinion. It’s one of the few “modern” languages that gets lambda
> expressions correct. (No funky exceptional behavior, you can assign to
> variables in the lexical environment, and the correct thing happens.)
> 
> It has a “general” type called interface{} that holds values of
> any type. This is not a kludge like in Java, or so, where
> java.lang.Object holds any object except for “primitive” types,
> but interface{} actually stores any type. (Including int8, int16,
> int32, etc., etc., and if I remember correctly, avoids storing on the
> heap if possible.)
> 
> It has an extremely good parallel, concurrent garbage collector that
> deals well with pretty large heaps. (Up to 256 GB in our experience.)
> 
> Variables are stored by value by default (like in C or C++), but are
> automatically moved to the heap if necessary, for example if you take
> the address of the variable and pass it around. This avoids major
> memory issues that you can easily get in C or C++, but remains
> efficient by default.
> 
> The concurrency model is pretty good, and also works well to a large
> extent for parallel programming. Parallelism is based on a
> work-stealing scheduler, which are known to be “optimal,” (except
> if you program against the lowest level of a CPU, but for portable
> parallelism, work stealing is pretty hard to beat).
> 
> When moving our elPrep software away from Common Lisp, we evaluated
> C++, Go and Java as potential candidates, and Go turned out to provide
> the best balance between performance and memory use. See
> https://bmcbioinformatics.biomedcentral.com/articles/10.1186/s12859-019-2903-5
> 
> We are still using Common Lisp for prototyping, and then translate to
> Go. These two languages are actually much more similar than it appears
> at first. For example, dynamic dispatch feels a lot more like generic
> functions than OOP-style methods. (Methods are defined outside of the
> corresponding record definitions, and can actually be defined on any
> type, including your own variants of “primitive” types, which can
> be extremely handy.)
> 
> We also planned to evaluate Rust for elPrep, but Rust didn’t provide
> type-safe atomic compare-and-swap, at least not back then. This is a
> deal breaker for an important part of our software. You can cast away
> the types and express this with “unsafe” types, but that defies
> the main purpose of using Rust. We also expect that the performance
> will be equally bad as that of C++, which suffers a lot from the lack
> of a proper garbage collector. (Details are in the paper.)
> 
> Pascal
> 
> Sent from my iPad
> 
>> On 2 Dec 2020, at 16:15, Scott McKay <swmckay at gmail.com> wrote:
> 
>> 
>> Rust is C++ done right. At this point, I have several stacks based
>> on what I'm doing:
>> * Web back end – Python/Django
>> * Web front end – Javascript/React
>> * ML/AI (as a "client") – Python
>> * Systems programming – Rust
>> 
>> On Wed, Dec 2, 2020 at 9:57 AM Marco Antoniotti
>> <marco.antoniotti at unimib.it> wrote:
>> 
>> I second what Scott said.  Julia is not "fringe" and I am thinking
>> that - too late probably - that is a Very Good Thing (tm)
>> 
>> Apart from that, Rust was described in "Nature".  You cannot get
>> more mainstream than that.
>> 
>> Ciao
>> 
>> Marco
>> 
>> PS Me, I am checking out PL/I
>> 
>> On Wed, Dec 2, 2020 at 8:52 AM Scott McKay <swmckay at gmail.com>
>> wrote:
>> 
>> I can't argue with that. My point was, if you're gonna use a fringe
>> language (*),
>> use a _good_ fringe language.
>> 
>> (*) I don't think Julia is "fringe" any more.
>> 
>> On Wed, Dec 2, 2020 at 5:45 AM Bob Cassels <bobcassels at netscape.net>
>> wrote:
>> 
>> Hey Scott,
>> 
>> Go with Julia. It’s enough like Dylan (multi-argument generic
>> function dispatch, expression-oriented, macros), but better in
>> important ways (better type system, package system, better
>> compilation model, cross-language integration).
>> 
>> It has warts (kludgy, messy syntax), but mostly it has traction
>> (active, growing user community, increasing library support,
>> libraries are cutting edge).
>> 
>> If you long for Dylan, Julia is where you want to be. It’s where
>> the smart cool kids are.
>> 
>> Bob
>> 
>> On Jul 7, 2020, at 8:24 AM, Scott McKay <swmckay at gmail.com> wrote:
>> 
>> I cannot hold my tongue on Pyret – why not Dylan? Pyret breaks no
>> new ground,
>> and does not have as good a language designer as Dave Moon. It's
>> macro system
>> can be trivially used to add the test-ish stuff that Pyret puts in
>> its core language.
>> 
>> Dylan remains the best language I've seen that never got traction.
>> 
>> —S
>> 
>> On Tue, Jul 7, 2020 at 4:41 AM Ken Tilton <kentilton at gmail.com>
>> wrote:
>> 
>> Hey, Daniel.
>> 
>> Thanks for the +1, as the kids today say!
>> 
>> Yeah, what we developers deal with must somehow be avoided until the
>> students have felt the thrill of programming, if they will. This
>> programme will not be for everyone. But for those who light up as
>> much over algorithms as they do the music, _then_ we can let them
>> see a two thousand line Clojure backtrace on every error. Grrrr. :)
>> 
>> I like the section contrasting Pyret with other languages that are
>> considered clean syntactically. Pyret makes them look like Java. :)
>> We devs put up with such garbage. One reason I want Clojure or CL
>> for this is because the macros will make it easy to deliver a super
>> friendly yet powerful new music DSL.
>> 
>> Looking at Pyret also reminded me of Logo, another super clean yet
>> powerful language aimed at noobs of any age.
>> 
>> Thx for the Pyret pointer!
>> 
>> -hk
>> 
>> On Mon, Jul 6, 2020 at 11:23 PM Daniel Herring
>> <dherring at tentpost.com> wrote:
>> Hi Ken,
>> 
>> I think music is a great way to engage a wider audience of potential
>> 
>> developers.  It has a wider appeal and lower barrier to entry than
>> many
>> other programming activities.
>> 
>> Having seen kids fire up a web browser to do "Scratch programming",
>> I'm
>> convinced that a web-based platform is the most accessible.  People
>> can
>> use almost any computer to create accounts, create projects, and
>> share/publish projects.  Only seasoned developers are comfortable
>> with the
>> concept of "install this editor, compiler, and Git".  :)
>> 
>> Here's an interesting language, though it may not have a audio
>> library
>> yet.
>> 
>> https://www.pyret.org/
>> 
>> - Daniel
>> 
>> On Mon, 6 Jul 2020, Ken Tilton wrote:
>> 
>>> "actively under development"! Music (sorry) to my ears! The Lisp
>> and ADD genes must overlap seriously. I started one of the videos.
>> Really nice live coding.
>>> 
>>> I'll make sure our code camp grad school uses CL.
>>> 
>>> Thx!
>>> 
>>> -hk
>>> 
>>> On Mon, Jul 6, 2020 at 8:11 PM Andy Peterson
>> <andy.arvid at gmail.com> wrote:
>>> https://github.com/byulparan/cl-collider "A SuperCollider
>> client for CommonLisp"
>>> 
>>> Never tried this but I've been following it for a few years and it
>> is actively under development.
>>> 
>>> Andy
>>> 
>>> On Mon, 6 Jul 2020 at 13:57, Ken Tilton <kentilton at gmail.com>
>> wrote:
>>> Thanks for the seconding motion! But part of the plan is
>> high accessibility, and low cost. I just noticed the pricing on
>> OpusModus, bit of a showstopper there.
>>> 
>>> We would use Clojure Overtone https://overtone.github.io/ but that
>> sits atop Supercollider, not sure if that would make installation a
>> PITA. Ideally we would have sth built atop Web Audio, but
>>> then we really are super low-level. I think! Have to look into
>> that.
>>> 
>>> We would want to hook the students with solid music before taking
>> them down to the basics, so existing effects etc would be great to
>> have, but again, this is about coding in general, not music
>>> generation. That is just the hook.
>>> 
>>> Thx again! If some campers get more turned on by music than coding
>> that will be a great next step.
>>> 
>>> On Mon, Jul 6, 2020 at 1:43 PM dbm at refined-audiometrics.com
>> <dbm at refined-audiometrics.com> wrote:
>>> 
>>> Yes, I was also going to suggest OpusModus. I see little
>> purpose in reinventing any portion of what they have done.
>>> 
>>> I have been a user for about 2 years now. It seems to be the
>> defacto replacement for an earlier product done in Lispworks, from
>> Italy, called Symbolic Composer. OpusModus is very good, and
>>> getting better every day. They just implemented live MIDI
>> recording in the latest version.
>>> 
>>> - David McClain
>>> Refined Audiometrics Laboratory, LLC
>>> Tucson, AZ, USA
>>> refined-audiometrics.com [1]
>>> 
>>> 
>>> On Jul 6, 2020, at 8:11 AM, Ken Tilton <kentilton at gmail.com>
>> wrote:
>>> 
>>> Sounds great, I will keep it in mind if we loosen the
>> web/mobile-native constraint. Or maybe as a direction for campers
>> who take off -- no need then to fret over platform,
>>> power will matter.
>>> 
>>> Thx!
>>> 
>>> 
>>> On Mon, Jul 6, 2020 at 10:54 AM Stonewall Ballard <stoney at sb.org>
>> wrote:
>>> Ken,
>>> 
>>> Are you familiar with Opusmodus?
>>> <http://opusmodus.com [2]>
>>> 
>>> It’s written in Clozure ccl, and besides providing an incredible
>> array of music manipulation functions and structures, it’s got a
>> beautiful window system. Mac only.
>>> 
>>> Your idea of using music as a hook to learn Lisp sounds plausible.
>> Good Luck!
>>> 
>>> - Stoney
>>> ————Stonewall Ballard    stoney at sb.org
>> http://stoney.sb.org [3]
>>> 
>>> On Monday, July 6 at 8:15:31 AM, Ken Tilton (kentilton at gmail.com)
>> wrote:
>>> 
>>> So I got to thinking about creating an approachable pathway to IT
>> careers for anyone really, but in the spirit of today one focused on
>> creating career opportunities for
>>> African Americans.
>>> 
>>> The idea would be a code camp developed around algorithmic
>> generation of music. I know nothing about music theory, except that
>> there is prolly enough there to introduce
>>> most if not all fundamental programming concepts.
>>> 
>>> For those campers that accidentally get hooked on programming
>> itself, which is how many of us ended up in IT careers, away they
>> go!
>>> 
>>> The idea is to:
>>> *  use music as the hook;
>>> *  defer as long as possible the annoying things about
>> programming (I am looking at you, node.js);
>>> *  part of that ^^^ will be using a powerful language with the
>> parentheses in the right place, prolly ClojureScript since that
>> could run where JS runs;
>>> *  keep programming as the focus, as tempting as the music will
>> be. Sonic Pi comes with all sorts of built-in sound capabilities,
>> but we want to develop those in the
>>> code camp;
>>> *  tailor the program to specific musical genres, to maximize the
>> musical hook.
>>> I am dropping this here since I know many Common Lispers have a
>> strong musical bent. My questions are:
>>> *  Could we use CL instead? I do think this almost has to be a
>> web app, perhaps even mobile. Hmmm, we could CL-ify CLJS with
>> sufficent clever macrology.
>>> *  What do you think? Can a solid programming fundamentals course
>> be expressed in music theory? Hint: HTTP is not a programming
>> fundamental.
>>> *  If there is any interest, what would be a good place for an
>> ongoing discussion? Google groups?
>>> Ideas, comments, suggestions all welcome.
>>> 
>>> -hk
>>> 
>>> 
>>> 
>>> --
>>> Kenneth Tilton
>>> http://tiltontec.com/
>>> 
>>> 
>>> 
>>> 
>>> --
>>> Kenneth Tilton
>>> http://tiltontec.com/
>>> 
>>> 
>>> 
>>> --
>>> Kenneth Tilton
>>> http://tiltontec.com/
>>> 
>>> 
>> 
>> --
>> 
>> Kenneth Tilton
>> http://tiltontec.com/
> 
> --
> 
> Marco Antoniotti, Associate Professor         tel. +39 - 02 64 48 79
> 01
> DISCo, Università Milano Bicocca U14 2043
> http://bimib.disco.unimib.it [4]
> Viale Sarca 336
> I-20126 Milan (MI) ITALY
> 
> 
> Links:
> ------
> [1] http://refined-audiometrics.com/
> [2] http://opusmodus.com/
> [3] http://stoney.sb.org/
> [4] http://bimib.disco.unimib.it/