V + CLAP could be a match made in heaven

[Architeuthis]

https://vlang.io/

I got realtime debugging working in VSCode easily (I'm willing to guide people on this over discord). That's a game changer for me already. JUCE + Visual Studio C++ is so cumbersome compared to my V & CLAP environment

It features hot reloading but I couldn't get it to work, but it should be simple. It's VERY simple in terms of coding, all you do is put `[live]` in front of a function and then you can edit that function while the program is running, so you could develop DSP in Vlang in realtime!

Vlang overall is looking like a great alternative to JUCE, because it has so much already, including UI stuff, opengl.

I love the syntax of Vlang, very concise and readable.

I'm trying to convert or make compatible the CLAP header/CLAP implementation code right now. But if the creator of CLAP wants to take a stab at it, that would be better!

Edit: What if I or someone made a repository? We can call it VCLAP.
Edit: Or maybe no need to do that if the CLAP repository wants to contain a V translation

[Super Piano Hater 64]

Oh no

[Architeuthis]

To CLAP creator: not sure if this is original code I'm looking at, but if so: please name your enums or use const.

imagine not naming your enums. bahahaha

[Architeuthis]

Do these have to be defines rather than const? V doesn't like define, although I could allow V to compile it with C-related flags.

[camsr]

These typecasted constants can be rewritten like, 1ul, 0ul, 2ul

[] Peter:H []

V seems to be an interesting language.
There's already one or two Rust bindings. In order to be able to use V somebody has to do a binding for it as well I guess...

[mystran]

To CLAP creator: not sure if this is original code I'm looking at, but if so: please name your enums or use const.

"const" alone would not compile as C++ which requires explicit types for every variable declaration.

Additionally, if you declare variables like that in headers without "static" qualifier, then the linker will complain about duplicate symbols as soon as you try to include the headers from multiple translation units, so you need "static const unsigned" or something similar, instead of just "const".

edit: Also not sure about what named enums would do here, since the enum isn't really a type, just a container. This sort of thing is fairly common C syntax, so if some tool has trouble parsing them it should really be the tool that's fixed.

[Architeuthis]

edit: Also not sure about what named enums would do here, since the enum isn't really a type, just a container. This sort of thing is fairly common C syntax, so if some tool has trouble parsing them it should really be the tool that's fixed.

My argument for this change: Named enums means a translator tool can do EnumName.Enum. It's better form, better code.

Without the named enum that is... impossible? or maybe the tool could just guess what the enumname is based on seeing `MY_ENUM_NAME_` at the beginning of every entry... but that's dangerous.

Now, I don't need any changes to the original code, I'm just throwing it out to the creator anyway.

[Architeuthis]

TO THE CREATOR, OUR CLAP GOD

...that's what I hear in my head when I say creator...

[mystran]

edit: Also not sure about what named enums would do here, since the enum isn't really a type, just a container. This sort of thing is fairly common C syntax, so if some tool has trouble parsing them it should really be the tool that's fixed.

My argument for this change: Named enums means a translator tool can do EnumName.Enum. It's better form, better code.

Right... except it's not really an enumerated type in the usual sense, because they are flags that you can combine together. In other words.. it's just abusing C enum syntax to define a bunch of constants, yet this is actually a somewhat idiomatic way to do it in C (groups them together in the source code so it's easier to visually see that they are related).

[Super Piano Hater 64]

Sorry to bring this back on topic, but V is a terribly immature language and will likely always be a poor fit for DSP work, or any productive work at all, really. Its design philosophy is incoherent on a good day and its maintainers have a history of advertising future plans as current features. They have repeatedly promised the sky and delivered a half-eaten potato.

Here's an article from a few weeks ago examining some of the problems with V. The first paragraph contains links to prior criticism.

https://mawfig.github.io/2022/06/18/v-lang-in-2022.html

[Architeuthis]

and will likely always be a poor fit for DSP work

Give one reason.

[Super Piano Hater 64]

and will likely always be a poor fit for DSP work

Give one reason.

Memory leaks

[Architeuthis]

and will likely always be a poor fit for DSP work

Give one reason.

Memory leaks

huh. Even though V language specifically states that memory leaks are taken care of and demonstrates this in video. I guess I'll keep an eye out and let peeps know if I run into it.

[Super Piano Hater 64]

and will likely always be a poor fit for DSP work

Give one reason.

Memory leaks

huh. Even though V language specifically states that memory leaks are taken care of and demonstrates this in video. I guess I'll keep an eye out and let peeps know if I run into it.

Again: Many of their advertised features are actually future plans. When they say "V prevents memory leaks" they really mean "we plan for V to prevent memory leaks someday" and they can't reliably tell you when "someday" will be.

They have plenty of confidence and ambition. I don't know that they have the technical chops to back it up, but I'll be patient and wait a few years before making stronger accusations.