As an R developer, I can deeply relate to this. People that use R as the mother language are probably from academia. They can be very good at data analysis and scripting, but usually have no idea of software development. They have few knowledge about versioning, modularization, documentation, and testing, which can lead to issues when they develop production-level R packages and Shiny applications.
On the flip side, R developers with strong software development skills can be incredibly valuable in academic settings.
I have a friend who left tech after 15 years to go back and get a CS phd. He ended up with a permanent job being the only "software guy" on a team of like exclusively math and physics post-docs. I'm still a little fuzzy on his day-to-day but I think it's basically just having enough of a handle on the research math to effectively product manage all the gnarly research code they produce. It sounds both frustrating and fun.
It can be frustrating if those post-docs underestimate the time cost and engineering complexity of software development. They would complain why it takes so long for your friend to "just" change a button in some app.
Everything you say explains why R is a great language in academia, and why people in research will stay away from "software engineering"-oriented languages like Java and JavaScript. Researchers already have too much to worry about.
I agree that researchers usually don’t need to worry about software engineering because their code is often simple, used only for one paper, and intended for personal use. But for large-scale research involving multiple researchers, users, and datasets, software engineering mindset can be beneficial in the long term.
In creating a music score, you literally "add" components to the score. So it's natural to implement this operation this way. From the OOP perspective, it's just method overloading. Not uncommon in R development.
Here are my responses to some comments on Hacker News.
Limitations
To be completely automatic, ch0p1n should be able to
1. analyze
2. generate
3. manipulate
4. select
musical materials to generate music.
Specifically, it should be able to analyze musical structures, generate core musical materials, manipulate these materials to produce more, and select musically good materials to make semantically rather than syntactically correct music.
For now, ch0p1n can at best provide only a framework for manipulating given materials to generate music.
Deep Learning
I have only very general knowledge of deep learning, but I think it is more promising than any other manual approach in automatic composition. I will spend time study it.
Terrible Result?
Some comments say the final generated music sounds terrible, which I can only partially agree.
All music pieces in this blog are generated with MuseScore. To make the music sound less mechanical or less terrible, you need to carefully adjust dynamics, tempos, pedals, etc. And even so, the music may still sound unsatisfactory. The original Beethoven’s sonata generated with MuseScore sounds bad even with dynamics and articulations added.
However, ch0p1n can only deal with pitch and durational aspects of music for now, but to make music sound good, you need to adjust a lot of variables. This is also why I said deep learning is more promising.
Some comments think the terribleness results from that ch0p1n can only generate syntactically correct music which may be musically meaningless. While I agree that ch0p1n has this limitation, I do believe in most cases, syntactically correct music is good enough to sound good.
I will generate more convincing music with ch0p1n in the future.
Is "the end result" the Beethoven's sonata in Japanese scale?
If so, the most important reason that it sounds terrible is the music is generated with MuseScore, without adjusting dynamics, tempos, etc. Actually, the Beethoven's original sonata in this blog is also generated with MuseScore, and it sounds not so good even with dynamics added.
However, this is why I agree that deep leaning is more promising than this manual approach, since too many variables you need to adjust to make music sound good rather than syntactically correct.
On the flip side, R developers with strong software development skills can be incredibly valuable in academic settings.