Cmajor

[julianstorer]

Hello, and well done on getting onto the Hacker News front page for something that doesn't actually exist!

I saw it there, and thought I'd send you a few thoughts from the perspective of someone who has made one or two things that do actually exist (SOUL and Cmajor)

First point that sprung to mind is: Many projects work really well as open-source bazaar models, but having designed language, I'm pretty sure that trying to crowd-source one is not going to generate anything decent. Open source and committees are great for maintaining and growing existing languages, but not creating them.

So you said this about Cmajor:

Cmajor STILL isn't free and open source. The tools provided as binaries are still opaque and closed source.
Cmajor still is focused on audio, while Chata is for all DSP.
Cmajor looks better regarding boilerplate, but still could do even better.
Cmajor's readme leaves a lot to be desired because there's almost no information on it.
Cmajor is STILL owned by some company which could go bust like the Challenger space shuttle.

We're in the process of spinning it off from Native Instruments into an independent company, so it'll be owned by myself and Cesare. When that paperwork is done, our next move will be to open-source it fully.

So that should address your independence and openness moans. And FWIW this was always our plan.

No, Cmajor is not just for audio. Sure, we focus on audio because a) that's our industry, b) we want to use it for audio ourselves, and c) focusing on one use-case is what you do to launch any new product.

But you could of course use it for any DSP, and we deliberately avoid any audio-specific terms in the language itself. Not that we can think of many other use-cases.... the only one we've spotted would be to write i/o control systems for small embedded hardware sensor/controllers etc. If you know some other amazing use-cases, or have spotted a massive flaw in our design that limits us to only audio, then we'd love to hear about it.

Not really sure what you mean about boilerplate. Nobody likes boilerplate, but with language design, a lot of the UX comes from knowing how to walk the line between implied and explicit functionality, and the trade-offs between readability, compactness etc. It's not always the right choice to remove boilerplate at the expense of language complexity, but sometimes it is, so would be interesting to know exactly what is bugging you about it, as there might be a very good reason for it.

And our readme has almost no information... hmm, ok.. I guess that's because we took the "short readme about something that exists" rather than the "long readme about something that doesn't exist" approach :)
..but it does have links to our website and documentation, which is the important bit, right...?

Anyway, good to see that there's interest out there in this kind of area. We're aiming to nail this, so hearing people find problems with our approach is all interesting feedback for us to take on board!