> 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.
About that, huh? It was the author's preference to write <foo bar baz> (syntax sugar) instead of ('foo', 'bar', 'baz'). The REPL uses a simple stringification method for the feedback it gives by default. I wouldn't think too hard about it.
> "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.
The point stands: the author of the post did know what it is for (and called it "accumulation"). You didn't know it and mistook it for a map even with the given output. I don't know if this is all Raku's fault but in your place I would be more humble to jump from a faulty assumption to the next assumption...
> 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.
Likewise: I half expected that somebody, instead of appreciating good features, will outright label them as a reason why the language is bizarre. Indeed, it is a desperate situation and I don't think there could be any way to win over somebody with prejudices this strong. Nor am I certain if "worse is better" is a good paradigm to act upon.
> you repay generosity with insult
> If an honestly bewildered "what?" is something you can't help taking personally
I must be clueless about people really. I gave you `an honestly bewildered "what"`, according to your own words, and that's now labelled as an insult. Frankly, it's not the greatest pleasure to try to reason with somebody who throws around judgements like that.
> Function signatures, as opposed to functions, being first-class runtime values is objectively weird
I mean, how is one supposed to argue declarations like this?
> Deriving one signature from another at compile time via reflection
Reflection is rarely ever a compile time feature. It obviously isn't a compile time feature in dynamic languages but neither is it compile time in VM-native languages like Java or C#. It's the metamodel the VM's provide and means to access that.
> 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.
Arguably, having arguments go into a hash/array in a function, and the other way around: passing individual arguments through hashes/arrays, should qualify: something that has been a part of Python for eternity, and was added to ES2015.
> 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.
My point is that Raku may be legitimately confusing and you may be illegitimately confused. The two things don't contradict. I don't need to be convinced about the former. I was curious about the impression and conclusions this particular article has led to. I'm disappointed to see that the reactions apparently aren't even based on the article. I'm not sure that the Raku community could even change the language enough to break down the prejudices.
> I would've been laughed out of the room for suggesting any of them should be implemented in Raku
Again, that's least about being a "write-only language". Of course there are technical merits.
> 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
If the granularity of your system is small enough for any of this to make sense, then YES, it does mean that. The purpose of microservices is also testability, stability and replacability. The fact that you do not need to keep tinkering the same piece of code after years, because it already does that one thing it was created for, and when the change in requirements makes it unsuited, by all means throw it away and make a new, fitting component. The whole point is that not all software development has to be about reading code more than writing it, and maintaining the same heap of code for eternity. The bus factor also cannot be constantly increased by merely making more people do everything. Once again, I'm not saying that I hold the absolute truth, I am saying, however, that you are neglecting a lot of possibilities.
> 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
Okay, so we have reached there just a couple of paragraphs after you talking about insults. If I knew you would be firing hot takes with a gatling, I wouldn't have asked you in the first place. At this point it's really just a counter-attempt of survivor bias on my side, so that your hot takes don't go unreflected. This particular one will, though.
> I don't think there could be any way to win over somebody with prejudices this strong.
Yes, I have long prior experience of Perl 5 - it was the first non-BASIC language I learned, and from 1995 through about 2010 the language I used for almost everything both at work and at home.
That I have learned from both that experience and what followed, and that not all the conclusions I've drawn from it are favorable to either that language or its successor, you are of course welcome to describe as "prejudice" if you like.
> Nor am I certain if "worse is better" is a good paradigm to act upon.
The phrase was originated by Richard Gabriel during his time as the head of Lucid Inc. Are you at all familiar with the history behind it? Theirs is an honorable enough example, but also one I'd be very concerned to find myself following.
> The whole point is that not all software development has to be about reading code more than writing it, and maintaining the same heap of code for eternity.
You do realize, I hope, that saying stuff like this doesn't really make the "write-only language" cavil that's dogged Perl throughout its history seem any less fair...
> Once again, I'm not saying that I hold the absolute truth, I am saying, however, that you are neglecting a lot of possibilities.
And once again I am saying you have failed as yet to convince me those possibilities might offer productive benefit, especially when I have yet to see the theoretical advantage of language flexibility in microservices materialize in practice.
I'm not saying that means it's impossible it ever will. I am saying that means you have a high bar to clear in making the argument for Raku's particular fitness - but that doesn't seem to be the argument you are trying to make, anyway.
Instead you seem to plead language flexibility in microservices more or less as an excuse, on the idea that niche languages for which knowledgeable engineers are rare as hen's teeth face no barrier here because, after all, you can always throw the code away and write more. And that is not convincing, except inasmuch as I'm finding it hard to imagine by this point you have experience with the costs involved in building production software.
(Also, what's so insulting about being called a partisan? Your partiality is by this point very obvious.)
The problem isn't whether the conclusions you draw are favorable or not, it's that they are not legitimate. It's getting tiresome that I have to repeat it: I'm not at all arguing either in favor of Perl, or against the "write-only" narrative that imo applies to other languages as well, including C++, Scala, Common Lisp, Ruby and whatnot, and I quite clearly know what it means when somebody says Raku is a "write-only" language. Newsflash: it's not about visual appeals, it's about mental portability across people.
> You do realize, I hope, that saying stuff like this doesn't really make the "write-only language" cavil that's dogged Perl throughout its history seem any less fair...
Surprising, right? I frankly cannot parse that sentence but yes, by now I really hope it's clear that I'm not arguing with the "write-only" narrative. I'm arguing that there is a world of things where software doesn't have to be about sticking to the same monolithic code base for decades and pass it around across dozens of people. That there is a world where it is indeed more important to write code than to read it.
> And once again I am saying you have failed as yet to convince me those possibilities might offer productive benefit, especially when I have yet to see the theoretical advantage of language flexibility in microservices materialize in practice.
I hope I suceeded in convincing you about factual things about signatures, reflection and the existence of accumulation. I don't have research studies about the productivity of various programming languages in a microservice-based architecture; if you have something like that, I will be happy to read it.
> Instead you seem to plead language flexibility in microservices more or less as an excuse, on the idea that niche languages for which knowledgeable engineers are rare as hen's teeth face no barrier here because, after all, you can always throw the code away and write more. And that is not convincing
This is not convincing because it's a strawman. Let's throw the "niche language" part away and let's replace "after all, you can always throw the code away and write more" (which is true but indeed no argument) with "a small, single-purpose, well-tested tool of any sort is best replaced when that single purpose wears out". Which is what I stated. And it makes sense, given that it was designed and tested around one single purpose. Maintenance is not a virtue but a common technical necessity. If you don't know when to let go of software, then ironically enough, you might as well have been exposed to too much Perl.
Anyway, considering the topics you did not respond to, one can deduce what points I did nail. Also, it seems we are getting away from the insult motive, that way it may be more useful for somebody who just reads.
About that, huh? It was the author's preference to write <foo bar baz> (syntax sugar) instead of ('foo', 'bar', 'baz'). The REPL uses a simple stringification method for the feedback it gives by default. I wouldn't think too hard about it.
> "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.
The point stands: the author of the post did know what it is for (and called it "accumulation"). You didn't know it and mistook it for a map even with the given output. I don't know if this is all Raku's fault but in your place I would be more humble to jump from a faulty assumption to the next assumption...
> 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.
Likewise: I half expected that somebody, instead of appreciating good features, will outright label them as a reason why the language is bizarre. Indeed, it is a desperate situation and I don't think there could be any way to win over somebody with prejudices this strong. Nor am I certain if "worse is better" is a good paradigm to act upon.
> you repay generosity with insult
> If an honestly bewildered "what?" is something you can't help taking personally
I must be clueless about people really. I gave you `an honestly bewildered "what"`, according to your own words, and that's now labelled as an insult. Frankly, it's not the greatest pleasure to try to reason with somebody who throws around judgements like that.
> Function signatures, as opposed to functions, being first-class runtime values is objectively weird
I mean, how is one supposed to argue declarations like this?
> Deriving one signature from another at compile time via reflection
Reflection is rarely ever a compile time feature. It obviously isn't a compile time feature in dynamic languages but neither is it compile time in VM-native languages like Java or C#. It's the metamodel the VM's provide and means to access that.
> 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.
Arguably, having arguments go into a hash/array in a function, and the other way around: passing individual arguments through hashes/arrays, should qualify: something that has been a part of Python for eternity, and was added to ES2015.
This is mainstream enough but if you are not satisfied, let's roll back to reflection: https://learn.microsoft.com/en-us/dotnet/api/system.reflecti... https://docs.python.org/3/library/inspect.html#introspecting...
Objectively weird?
> 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.
My point is that Raku may be legitimately confusing and you may be illegitimately confused. The two things don't contradict. I don't need to be convinced about the former. I was curious about the impression and conclusions this particular article has led to. I'm disappointed to see that the reactions apparently aren't even based on the article. I'm not sure that the Raku community could even change the language enough to break down the prejudices.
> I would've been laughed out of the room for suggesting any of them should be implemented in Raku
Again, that's least about being a "write-only language". Of course there are technical merits.
> 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
If the granularity of your system is small enough for any of this to make sense, then YES, it does mean that. The purpose of microservices is also testability, stability and replacability. The fact that you do not need to keep tinkering the same piece of code after years, because it already does that one thing it was created for, and when the change in requirements makes it unsuited, by all means throw it away and make a new, fitting component. The whole point is that not all software development has to be about reading code more than writing it, and maintaining the same heap of code for eternity. The bus factor also cannot be constantly increased by merely making more people do everything. Once again, I'm not saying that I hold the absolute truth, I am saying, however, that you are neglecting a lot of possibilities.
> 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
Okay, so we have reached there just a couple of paragraphs after you talking about insults. If I knew you would be firing hot takes with a gatling, I wouldn't have asked you in the first place. At this point it's really just a counter-attempt of survivor bias on my side, so that your hot takes don't go unreflected. This particular one will, though.