<div dir="ltr">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.<div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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. </div><div><br></div><div>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.</div><div><br></div><div>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!</div><div><br></div><div>hope that is marginally interesting.. :-)</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Nov 10, 2023 at 6:07 AM Michael Gogins <<a href="mailto:michael.gogins@gmail.com">michael.gogins@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div dir="ltr" class="gmail_signature"><div dir="ltr"><div>I'm taking the liberty to also reply to your question for Rick.<div><br></div><div>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.</div><br><div>I have worked professionally as a software engineer on trading systems using C, C++, C#, Java, and Python.</div><div><br></div><div>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.<br></div><div><br></div><div>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. <br></div><div><br></div><div>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. </div><div><br></div><div>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. </div><div><br></div><div>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. </div><div><br></div><div><div>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.</div><div><br></div></div><div>Good luck,<br></div><div>Mike</div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div></div><div>-----------------------------------------------------</div>Michael Gogins<br>Irreducible Productions<br><a href="http://michaelgogins.tumblr.com" target="_blank">http://michaelgogins.tumblr.com</a><br>Michael dot Gogins at gmail dot com</div></div></div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Nov 10, 2023 at 7:37 AM Rochus Keller <<a href="mailto:me@rochus-keller.ch" target="_blank">me@rochus-keller.ch</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><u></u>
<div style="font-family:"Droid Sans";font-size:8pt;font-weight:normal;font-style:normal">
<table border="0" style="margin:2px">
<tbody><tr>
<td style="border:none">
<p style="margin:0px;text-indent:0px"><span style="font-family:Arial;font-size:10pt">@ Rick:</span></p>
<p style="margin:0px;text-indent:0px;font-family:Arial;font-size:10pt"><br></p>
<p style="margin:0px;text-indent:0px"><span style="font-family:Arial;font-size:10pt">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.</span></p>
<p style="margin:0px;text-indent:0px;font-family:Arial;font-size:10pt"><br></p>
<p style="margin:0px;text-indent:0px"><span style="font-family:Arial;font-size:10pt">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.</span></p>
<p style="margin:0px;text-indent:0px;font-family:Arial;font-size:10pt"><br></p>
<p style="margin:0px;text-indent:0px"><span style="font-family:Arial;font-size:10pt">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?</span></p>
<p style="margin:0px;text-indent:0px;font-family:Arial;font-size:10pt"><br></p>
<p style="margin:0px;text-indent:0px"><span style="font-family:Arial;font-size:10pt">Thanks</span></p>
<p style="margin:0px;text-indent:0px"><span style="font-family:Arial;font-size:10pt">R.K.</span></p></td></tr></tbody></table></div>_______________________________________________<br>
Cmdist mailing list<br>
<a href="mailto:Cmdist@ccrma.stanford.edu" target="_blank">Cmdist@ccrma.stanford.edu</a><br>
<a href="https://cm-mail.stanford.edu/mailman/listinfo/cmdist" rel="noreferrer" target="_blank">https://cm-mail.stanford.edu/mailman/listinfo/cmdist</a><br>
</div></blockquote></div>
_______________________________________________<br>
Cmdist mailing list<br>
<a href="mailto:Cmdist@ccrma.stanford.edu" target="_blank">Cmdist@ccrma.stanford.edu</a><br>
<a href="https://cm-mail.stanford.edu/mailman/listinfo/cmdist" rel="noreferrer" target="_blank">https://cm-mail.stanford.edu/mailman/listinfo/cmdist</a><br>
</blockquote></div>