[CM] What motivated the change from CL to Scheme?

[Iain Duncan]

I'll throw my two cents in. Like Mike, I have done both work code and music
code in a whack of languages, though professionally for 20 years and not
forty! However, I fancy I  have some valuable insights from my last 5 years
of doing technical due diligence for software acquisitions, in which I talk
to companies ranging from startups to billion dollar things on everything
tech related including the ramifications of their technical choices.. The
50+ diligences have provided very interesting insights - especially because
we get the real goods as opposed to what people say publicly.

In one sense, it doesn't matter too much - I have seen roaring success in
all kinds of languages. At the end of the day, if you have a super smart
team with deep experience in a language that can easily outweigh other
concerns, and they are all pretty capable now.

In another sense, it matters a great deal, in that every language is
optimized for different things and if those optimizations match your needs,
strengths, weaknesses, and priorities, that can make a very big
productivity difference. Optimizations can be over code base size, short
term vs long term goals, safety versus expressiveness, performance vs
flexibility, verbosity, readability, etc.

What I have come to the conclusion on though is that what *really matters*
is dependency management. I believe you can use all kinds of languages well
provided you make sure the way you are building software does not
inextricably wed you to a certain language or platform. This, done wrong,
has resulted in the silent death of countless startups who wrote products
on overcoupled vendor-lock-in frameworks and were completely screwed when
they outgrew some of their original assumptions.

So that is a major reason I use the tools I do, and the way I do, which
includes Scheme, C/C++, Max, and some csound and Python. If Max, or Pd
became poor options, whether because things happened to them or my
priorities changed, I can move work to a new host in short order. If s7
went away, I could move it to a new Scheme implementation. If csound went
away, I could move that element to Faust, or Gen, or Chuck. Like Mike, I
(generally) avoid things that put one in a walled garden. I think Nyquist
and SAL are cool, but code in those languages isn't going to be useful
absent their hosts. While one could say the same thing about Csound, the
way I use it is very minimal and is part of a larger stack.

Scheme (particularly s7) is also optimized for MY tradeoffs. I am
specifically doing work for small teams, small code bases (pieces), that
build on libraries (implemented in DSLs) and that I use to compose
interactively *while the music plays* inside a host app. Essentially
live-coding but not on stage. For this use case, I don't think you can beat
Scheme. If the interactive live-coding aspect were not a priority, I don't
know if I would have arrived here. For me, this significantly outweighs
ease of using other people's code, but YMMV!

hope that is marginally interesting.. :-)


On Fri, Nov 10, 2023 at 6:07 AM Michael Gogins <michael.gogins at gmail.com>
wrote:

> I'm taking the liberty to also reply to your question for Rick.
>
> I have experience doing algorithmic composition since 1983 in
> (alphabetical order, * means I have compositions on streaming music
> services or Web sites realized using that language): Basic*, C, C++*, CMix,
> Csound, Common Lisp, Fortran, Java*, JavaScript*, Lua and LuaJIT*,
> Mathematica, Pascal, Python*, Quickbasic, Reaktor, Strudel*, Tidal Cycles,
> and Visual Basic.
>
> I have worked professionally as a software engineer on trading systems
> using C, C++, C#, Java, and Python.
>
> In my opinion, there are too many systems for doing algorithmic
> composition in too many languages. This has fragmented the field of
> algorithmic composition and skilled people have wasted a great deal
> of their time re-inventing the wheel. You can see from my list that I,
> myself, have wasted a lot of that time. Currently, I use mostly JavaScript
> and C++, compiled to WebAssembly (WASM) to be used by JavaScript.
>
> The choice of language is secondary. The important things are community
> and history. Look for the largest and most diverse community of composers
> that you can find, with the longest history of compositions and the biggest
> library of shareable code.
>
> As far as actual programming languages go, if at all possible use industry
> standard languages that have proved themselves in the real world and have
> deep support. If we count only standard languages that feature algorithmic
> composition software, that's essentially just C/C++, Python, and
> JavaScript.
>
> But I also include Common Lisp, because although it's not a standard
> language it does have a deep history in algorithmic composition and an
> important community, especially around OpenMusic.
>
> And I include Scheme because the WASM implementation of s7 brings Scheme
> into the Web browser or NPM world where it can be used with JavaScript.
>
> In fact, I think WASM will become increasingly important because anything
> compiled to WASM can be used from JavaScript, which thus serves to glue
> together many different systems and packages in one environment.
>
> Good luck,
> Mike
>
>
>
>
>
>
>
>
> -----------------------------------------------------
> Michael Gogins
> Irreducible Productions
> http://michaelgogins.tumblr.com
> Michael dot Gogins at gmail dot com
>
>
> On Fri, Nov 10, 2023 at 7:37 AM Rochus Keller <me at rochus-keller.ch> wrote:
>
>> @ Rick:
>>
>>
>> Thank you very much for your response. So it was mostly a technical
>> reason to switch from CL to Scheme, not because of the language. It's also
>> amazing to learn, that you even ported the system to Python.
>>
>>
>> Since you therefore have experience in algorithmic composition in at
>> least four languages - Common Lisp, Scheme, SAL and Python - the question
>> arises which of these languages you consider most useful to represent
>> compositions and musical information.
>>
>>
>> I'm also curious whether you think object-orientation brings added value
>> to algorithmic composition. In your papers and book you emphasized CLOS; in
>> the Scheme version of Common Music object-orientation doesn't seem to be of
>> importance, and - as far as I understood - SAL doesn't support
>> object-orientation at all. Am I right to conclude from this that
>> algorithmic composition has little benefit from object-orientation?
>>
>>
>> Thanks
>>
>> R.K.
>> _______________________________________________
>> Cmdist mailing list
>> Cmdist at ccrma.stanford.edu
>> https://cm-mail.stanford.edu/mailman/listinfo/cmdist
>>
> _______________________________________________
> Cmdist mailing list
> Cmdist at ccrma.stanford.edu
> https://cm-mail.stanford.edu/mailman/listinfo/cmdist
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cm-mail.stanford.edu/pipermail/cmdist/attachments/20231110/feffdb08/attachment.html>