I am not sure if you expect a chaotic answer (if any at all), but let me only focus on the two items I'd like to be heard properly and understood clearly.
Raku++ development is not vibe coding. This is a full-scale software development using the new tools that became available to all of us. It requires an understanding of compiler theory and programming in general, constant review cycles and planning. This changes the whole model of development with big groups and/or with external financial support, but it does not change anything in the expected quality of the product that I want to deliver.
Rakudo is the de-facto reference compiler, as neither Roast, nor the docs define all the corners of the language. In my opinion, to make Raku a useful programming language, all the existing compilers must agree on the language definition. Creating Raku dialects is a less promising strategy.
Having a reference compiler is a normal practice and is not specific to Raku. For example, here's a quote from the "Crafting a Compiler" book:
I honestly have a bad feeling about these answers. It could be that I read them wrong but I think they are more about creating a certain impression or narrative than the facts at hand, which makes me a bit sad.
"vibe coding" is not a value judgement but an established term for iterative development done by prompting coding agents, coined by a proponent of this method. According to you, this definition is perfectly met, and your comment doesn't disprove it either. If there is something I miss, let me be your guest. If you are afraid that people have bad associations with the term "vibe coding", that's not a problem of my article.
For me, it's a very important admission that Roast (and the docs also) does not fully define the language and it's unfeasible to use it as a reference. I'm glad to see this written down. Your opinion of not forking Raku all over also makes sense. However, let's make it clear: Raku does not have a reference compiler, whether it would make sense or not! Rakudo developers themselves never considered Rakudo behavior authoritative, and largely tried to stay away from long term maintenance, versioning or specification for Rakudo. That's the difference the words "de-facto" make: all working "Raku code" was de-facto "Rakudo code", up until now. You have a large list of "potential Rakudo bugs" - if you believed Rakudo was a reference implementation (rather than just a "de-facto", for the moment reference, given by its former monopolous position), you would just take that behavior as normative. I'm happy you don't do that! There is nothing wrong with reference implementations, but if some behavior seems buggy, it's better to not codify that - or come up with design, maintenance and support strategies that spare us from living with suspicious behavior for eternity.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Hi,
I am not sure if you expect a chaotic answer (if any at all), but let me only focus on the two items I'd like to be heard properly and understood clearly.
Raku++ development is not vibe coding. This is a full-scale software development using the new tools that became available to all of us. It requires an understanding of compiler theory and programming in general, constant review cycles and planning. This changes the whole model of development with big groups and/or with external financial support, but it does not change anything in the expected quality of the product that I want to deliver.
Rakudo is the de-facto reference compiler, as neither Roast, nor the docs define all the corners of the language. In my opinion, to make Raku a useful programming language, all the existing compilers must agree on the language definition. Creating Raku dialects is a less promising strategy.
Having a reference compiler is a normal practice and is not specific to Raku. For example, here's a quote from the "Crafting a Compiler" book:
Hi,
I honestly have a bad feeling about these answers. It could be that I read them wrong but I think they are more about creating a certain impression or narrative than the facts at hand, which makes me a bit sad.