It would be invaluable feedback if you could point out what you find so bizarre? I mean, the "let's define some ad-hoc postcircumfix operator" is a weird flex for sure but otherwise? I could only see basic non-magic subroutine definitions and appropriately used operators.
Where would you like me to start? The apparent variance between list syntax accepted by the reader and emitted by the printer, the brambly thicket of special-case operators and grammars ('o' for function composition? Square brackets to reduce over an operator? Square brackets with a backslash to map? - I remember the "Periodic Table of the Operators", but even by that standard this is wild), function signatures as first-class values (...what?)
But honestly, I don't think I can provide actually useful feedback here, because I'm pretty sure nothing I'm doing is similar enough to anything Raku is doing for the conversation to really make sense.
Everything I've just described, and much else about the language, strikes me very much as needless complication for the sake of complication, the sort of thing that earned Perl 5 its "write-only language" sobriquet by encouraging, if not necessitating, the development of idiolects among its users - and Raku if anything seems to do much more of this than Perl 5 ever did.
That's not actually a bad thing for a small codebase maintained by one programmer, for whom the high cognitive complexity imposed by the language design can be managed by mostly working within their idiolect. But my experience has been that the maintainability of such a codebase decreases as at least the square of the number of people working on it, and that quickly becomes a catastrophe in the sorts of very large codebases, shared among tens or hundreds of engineers, in which I've spent the bulk of the last decade working.
That's not a world in which I see Raku being able to survive, and my experience there has led me to value languages and practices that are actively as un-clever as possible - because the cleverer something is, the harder to understand, which becomes a real problem when understanding it is necessary to resolve an outage denying service to millions of users.
That's also not a world in which I would expect Raku to try to survive, because it's obvious to me that that's not what Raku is meant for. Nor should it be; that that's not the place for such carefree, freewheeling weirdness for weirdness' sake isn't the same as saying no such place exists. It's just that that's a place I'm glad I don't live any more.
Isn’t it the same as if to say - “you are given hammer and nails only because anything more complex would make it things harder to the rest of your team”? But Raku, by the way could be that way - very simple and you don’t have to use all it’s capabilities
> The apparent variance between list syntax accepted by the reader and emitted by the printer
Could you provide an actual example for this? I suspect this is a simple misunderstanding.
> 'o' for function composition? Square brackets to reduce over an operator? Square brackets with a backslash to map?
I never used 'o' myself but YES, square brackets to reduce over an operator. Indeed, I see nothing wrong with that (okay, I actually do but not with the principle, rather the parsing). And "square brackets with a backslash" is NOT a map, it's a produce. The blog post got it right.
> function signatures as first-class values (...what?)
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...
So yes, I think what you present here might be the other extreme: rendering anything that might be slightly clever as "weird" or "complicated", even if it clearly reduces the custom tinkering each individual developer would have to do...
The situation is a bit touchy because I think your characterization of the Perl mindset living on in Raku as well (C++ is a similar language in a way) is legitimate but it seems to be based on "fortunate" prejudices and stereotypes rather than a good understanding of the situation. 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 don't think the language will be cleared up anyway but I also wouldn't want to go as "unclever" as you seem to find desirable. Languages like Python and Rust can thrive despite not being completely dumb. Opinionated yes, dumb no.
Also, I have been thinking that maybe the way to find industrial use for Raku (or this broader mindset overall) is to outright reject this framing that all projects need to be monolithic. Yes, you may be right that Raku will never be a language where dozens of people work on millions of lines of code together, for decades. What if your services can be broken down into pieces that CAN be managed by a couple of people tightly co-operating? What if these services can be developed and deployed so efficiently that instead of maintaining them for eternity, you can just start anew and replace them cheaply?
There is the common wisdom "what one person can't fully comprehend, definitely contains flaws". There is some truth to it for sure, and it does seem like with the rise of microservices, there would be place for software developed in a much more distributed manner. Now, there are practical reasons why Raku didn't catch up, at least not yet - but they are absolutely not language philosophy reasons.
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.
> "Produce" is a term I've never seen used this way before, and I assume it is unique to Raku.
More commonly referred to in the functional languages as a `scan`, but yes, it seems that `produce` might be unique to Raku. I've not seen `accumulate` outside of Python, but there's a lot of langs so who knows.
Connor has declared a fondness of APL's where fold and scan show a clear visual relation: `/` & `\`. I suspect Raku was shooting for something similar with it's choices:
I've just found the key exchanges that arrived at "produce" by using the IRC log search[1] and then, er, scanning backwards to where the exchange began[2]:
> TimToady: is it okay to rename the 'reduce' builtin to 'fold' and add one for 'scan'? My understanding is that 'reduce' is the general term for them both.
I recall Larry saying the key visual aspect is the `\` (I don't recall him mentioning the `/`) because `[\` visually echoes the typical shape of results:
> 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
They are different types:
[1,2,3] is an array with mutable elements that can be expanded, shortened
(1,2,3) is a list with immutable elements of fixed length
> find an example of anyone actually using it
A common example of signature introspection is when a routine accepts a lambda as a parameter, and adapts its function depending on the number of arguments the lambda expects (the arity: &foo.signature.arity, see https://docs.raku.org/syntax/Arity).
Two examples:
The "sort" function optionally accepts a lambda: if that takes one argument, then a Schwarztian transform will be done under the hood. If it takes two, then the lambda will be used as the comparator.
The "map" function expects a lambda. Depending on the number of arguments it takes, it will take that many arguments each time from the iterator it runs on.
Okay, we have arrays and tuples in square brackets and parens respectively. Where do the angle brackets come in?
> when a routine accepts a lambda as a parameter, and [via runtime introspection] adapts its function depending on the number of arguments the lambda expects
I note from the article that Raku has explicit multiple dispatch. This appears to be the same thing by other means, but probably much harder to optimize.
If so, this would be an application of the same "TIMTOWTDI" principle that governed much of Perl 5's design. But that takes us back to the encouragement of idiolect and the fanaticism for idiosyncrasy, on which I have said a fair bit already. Beyond impugning "ease of writing poetry in it" as an absurd, counterproductive, and frankly twee desideratum in programming language design, I can find nothing more to add.
> 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.
