> Could you provide an actual example for this?
Lists are given to the reader in angle brackets and printed in parentheses, or at least that's how it looks. I suppose the other possibility is that these are actually different types, but I'm not sure that's better.
"Produce" is a term I've never seen used this way before, and I assume it is unique to Raku. It appears to be a special case of reduction, not at all common in my experience, but presumably very common where Raku is used.
> Okay, now give me a break... this... is a "what"? Are you real now? A perfectly sensible and useful feature, a "what"? To be able to investigate function signatures and pass them around appropriately without constant hacking, is that bizarre? I guess airplanes are also bizarre to some...
That I half expected something in this nature is what had me in two minds over whether to reply to your prior comment at all. I suppose I'm glad there's not more of it, but really, this kind of attitude adds nothing to the discussion, and it certainly doesn't help make anyone's case that Raku has a community worth trying to be part of.
Beyond all that, asking people for feedback you claim to value and then behaving so badly when they take the time to honor your request is a great way not to get any more feedback, not only from that person, but also from everyone else who sees you repay generosity with insult.
(Before you complain that I gave the first insult - yes, I found this very surprising and frankly weird and I was not shy about saying so, nor need I have been. If an honestly bewildered "what?" is something you can't help taking personally, then the task of soliciting feedback may best be delegated to someone who has thicker skin - I have been in this line of work for a long time now, from which experience I can with certainty say that as user feedback goes, "what?" is nothing.)
Function signatures, as opposed to functions, being first-class runtime values is objectively weird. Deriving one signature from another at compile time via reflection is unexceptionable and occasionally useful, sure. But the idea that a function's signature in isolation has meaning enough to treat as a runtime value in its own right is something I don't recall ever having seen in close to forty years of programming across a widely varied range of languages.
I did some looking around the docs; this seems to be referring to values that might be returned from
$?ROUTINE.signature
and if so, then the use cases for it appear to be in line with what I'd expect to see done via reflection, although I admit I have struggled in the time available to find an example of anyone actually using it. So in the context of a language without a clearly defined concept of "compile time" this does make sense.
It might have done so more quickly, had you been more inclined to consider perspectives other than your own - the lack being again not something that does much to commend the community you've chosen to represent as one worth joining. Your problem to solve or not just as you choose, of course, but do perhaps consider that behaving as if an adolescent in a tantrum fails to leave a good impression.
As for the rest of it, I think that can be boiled down to two points:
> You haven't seen the bad parts yet and you apparently called some of the good parts bad. Not sure if it can be helped.
I'm not sure it can either, but you would do well to consider that the confusion you describe may have occurred because Raku is legitimately confusing.
Perl 5 has the same problem, and so did I in growing past it: there are not actually all that many novel concepts here or anywhere in programming, but this universal fanaticism for idiosyncrasy necessarily incurs as a side effect that if you want any of your stuff to make sense to someone who isn't already familiar with it, you have to spend a hell of a lot of time explaining the correspondences first. The incoherent farrago of syntax is just the most obvious example of this, and Raku does it a lot more than Perl 5 did! Not for nothing was the older language so often derided as line noise, or the first two letters of its name glossed as "Pathologically Eclectic" - jokingly perhaps, but many a true word is said in jest, and at some point you really have to admit that you are trying people's patience. If whatever you're getting in exchange for that is worth it to you, well and good, but you do yourself no favors by refusing to acknowledge the tradeoff that's been made.
- Microservices aren't an answer here. I have worked in such architectures, at scale sufficient to support billions in annual revenue with tens of engineers, and I would've been laughed out of the room for suggesting any of them should be implemented in Raku. Decomposing an architecture into services doesn't mean those services do not themselves need to be maintainable under the constraints I earlier described, including if both of your "couple of people tightly co-operating" die in the same plane crash. Modern engineering organizations work hard to increase the bus factor, and this approach not only militates directly against that but makes it practically impossible, not least because where else are you going to find anyone who can understand the code? (I am reminded strongly at this point of "The Bipolar Lisp Programmer" [1].)
If nothing else, I see in Raku a language of which specifying and enforcing a remotely maintainable subset, if possible at all, would require a whole lot of effort that could be better placed elsewhere - such as serving the needs of the business that as an engineer in industry is inevitably your client, even if that client happens also to be you.
I don't know why you would want Raku to "catch up", since a Raku capable of doing this would long since have ceased to be a Raku that an obvious partisan such as yourself would recognize or appreciate. But if that is what you want, you need above all else to show - quickly, clearly, and in a way that's compelling - how Raku is uniquely capable of making engineering organizations able to ship fast and ship well, in ways that can't be matched by anything among the very large set of more approachable, more supportable alternatives.
From what I've seen thus far, there's a lot of work ahead to get there. If it really means that much to you, I confide you'll find a way to spend your time on that, rather than fruitlessly argue any further at me.
[1] https://www.marktarver.com/bipolar.html