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 <[email protected]> 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 <[email protected]> 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 >> [email protected] >> https://cm-mail.stanford.edu/mailman/listinfo/cmdist >> > _______________________________________________ > Cmdist mailing list > [email protected] > https://cm-mail.stanford.edu/mailman/listinfo/cmdist >
_______________________________________________ Cmdist mailing list [email protected] https://cm-mail.stanford.edu/mailman/listinfo/cmdist
