2colours

I think the question still deserves a proper answer.

This is indeed not at all about his code. I don't care what he thinks of vaccines and COVID - I just as much don't care what Linus Torvalds thinks about these things. They are damn programmers. Their business is to ship reliable, usable, secure software.

I got permanently banned from the Raku community rather silently. What happened, what is the common history, and honestly, what is the path forward for those who stay.

This post is mostly meant to reach out to the community itself from this exiled state - therefore generic Raku banter isn't very welcome, and neither are further invalidation attempts from the people personally involved in my ban: they have had plenty of representation and there is no reason to assume we can have a meaningful discourse.

It's a bit ironic that now we went down the static rabbit hole so much that we don't realize it's more the opposite: by adding more to your language and compiler to enforce static checks, you turn the compiler itself more and more into a runtime that you are just going to run ahead of time, according to a potentially vastly different set of rules compared to your real runtime. There is no reason why you couldn't do something like this by will but it's just not worth it after a certain point clearly.

I wonder where you got that impression from. For me as well, it's rather the overboard lecturing response that seemed like an invocation of "Trevors axiom".

By the way, what even defines "simply a blog post"? That's just a media format that doesn't say much about the content itself, does it? I do agree with the sentiment that it would have been good to know what the article is even going to be. Not even the paragraphs were very helpful in this regard. It does improve the reception of an article if it meets the intended audience.

In retrospect, this article is mostly about a basic compiler frontend language and how to bootstrap that into a fully-featured concatenative programming language. Which to me personally is a "hm, okay, interesting" kind of thing but I didn't read the article for this premise. I read it for the "new antisyntax language" and feel it was clickbaitish.

Some diversity doesn't hurt, though. On my keyboard, it's actually easier to type than the backslash for starters.

Maybe a fast way but is it a fair or even helpful way, if you recognize that it "quickly became a bad name for the project"?

So following your logic, "some of the worst" includes the vast majority of actually used languages and tools. Must be cool to be on the special side. :)

Taking a look at the bigger picture, it does indeed seem like the Perl philosophy lost to the Python philosophy overall.

Looking at the hip n cool languages, not just Python for scripting but surely Go and to some extent Rust as well for native stuff (Dart for scripting also but it didn't outright "win"), these are mostly languages that deliberately simplified things. Yes, even Rust - it needs to be compared to C++ and its biggest feature is basically that it doesn't let you do all the things C++ does, within a very similar model.

The only language that I heard is going against these trends (but I'm largely clueless what it's actually like) is Julia which sort of has its own "lay" niche like Perl did back in the day, and is mostly winning based on the premise that it's a performant scientific language.

The industry obsesses over costs of adoption, stability, maintenance; in short: how to get the most out of the least actual new development. It does make quite a lot of sense, to be honest, although sometimes it's really demotivating at an individual level.

And frankly, "learn the language, duh" usually comes up when the language is complex or unintuitive for no practical purpose. Of course there will be people who always complain if they have to learn anything but I don't think they make the majority, or even a significant minority, in the software engineering world. "Learning the language" is only as much of a virtue as the language itself serves its purpose, which includes easy of use and the readability of someone else's code.

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.

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.

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.

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.

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.

I don't know, this is "second-hand intel" for me, pretty sure I read it in a very old article from someone of the likes of Carl Mäsak, Moritz Lenz or another early-day Rakudo contributor...

Jonathan Worthington has been much going on and off in the recent years. He still had one big optimization project that got completed in 2021 - the new dispatch mechanism - but I don't know about the benchmarks and I doubt it would help with the shear throughput of basic data processing.

From what I heard, it half inspired Moose actually.

Have to agree with this one, and also, there is something that I think is easy to forget until you actually face code that has been worked on by dozens of people of completely random backgrounds, over decades: your wisdom doesn't necessarily coincide with someone else's wisdom. Context switching across people - and especially people who barely have anything in common - can be really troublesome. You have to know everything that somebody else you work with has ever used.

Yes, and those claims might have even been real (also, Perl still lags behind on Unicode stuff, or so I heard?)... the thing we like much less to talk about is that there just needs to be somebody to make those optimizations happen. Work on the actual bytecode VMs (or rather just MoarVM at this point) has been desperately lacking.

I guess that all depends on what you consider bizarre parts. You of all people must have your own weird reason to say this out of the blue, though.

The difficulty of reading Perl is probably overclaimed and overrepresented. Let's not forget that we are comparing a pretty darn low-level language to a fairly high-level one.

And regarding design principles, I think the comparison is clearly on point. These are languages where the motto is basically "if you can't do it (if you can do it but it's perceived too long that also counts) then the language needs to be horizontally extended to account for this use case".

My vague impression was that Rust is still a (significant) simplification over C++. (Ada is a funny case because it seems to be deliberately designed to be hard to read and hard to write, overall a pain in the arse, in the spirit of "if you never reach flow, you will always be very focused", I guess.)

You probably know it well but let me elaborate a bit more "for the sake of the audience":

- the left handside is evaluated into a value (let's symbolize this value with $lhs) - this value is passed into the expression on the right handside as the $_ (topic) variable - the expression on the right handside gets evaluated, producing an $rhs value - now, $rhs.ACCEPTS($lhs) is called

The funky thing is that the right handside of this operator is an expression, not an evaluated value... it's like an invisible code block. The implementation calls this property of an operator "thunkiness", the expression on one side acting like a thunk rather than something that can be evaluated right away. This is akin to the short-circuiting behavior of && and ||.

Oh yes, Bruce Gray was a major influence for me as well a couple of years ago. He often participates in the "Raku Study Group" meetings as well - these are very broad and informal meetings every second Sunday but around the end, Bruce almost always brings up some Raku (sometimes Perl) solutions for the weekly challenges from https://theweeklychallenge.org/. In case you are interested, the repo of the meetups: https://github.com/doomvox/raku-study

Back to the topic. I picked up Raku a couple of years ago and I mostly use it as a better shell.

The pros are that you can really quickly and swiftly deliver CLI automation tools and scripts; the language has a unique but very practical regex syntax, you have very rich tools for string manipulation and you have good utilities to "drain CPU" if you are willing to spend more resources to make something faster (e.g easy multithreading for operations). Also, the language is very pleasant to use, it makes you feel very clever and powerful.

The cons cannot be neglected, however, the biggest problem probably being the performance and stability of the only actually working compiler, Rakudo, and its most functioning bytecode VM, MoarVM. The rich string-processing system and regex engine can be surprisingly slothful if you have vast amounts of text, same for precise bigint and rational computations (which are the default). Not many people understand Rakudo (and especially the VMs) enough to work on bugs or performance improvements, and there are not many low-hanging fruit remaining. Considering this, I'm sad that there has been little strategy regarding getting new maintainers, or having a release strategy besides "we will not change anything that might break code, and just release new compiler versions every couple of months".

Also, I don't know how much this is a con for you but Raku is not a language you can just "learn", you have to explore it and always be ready for a new journey. It's a horizontally huge language with a lot of corner cases you probably cannot all keep in mind. I think I'm managing pretty well but it is definitely a risk; you should probably either find a small subset you are comfortable working with and stick to it, or be okay with exploration using whatever goes, from asking others and reading the docs to investigating the core library inside Rakudo (which is not as bad as it may sound but not everybody wants to do).

Well I'm saying that "you just didn't bother to learn it, duh" is not an equally valid argument for different languages; it's much less valid for Perl than it would be for Python. It rewards your efforts much less. Perl is notoriously a language that had desperate criticism among its users even by the mid 90's ($[ and $] stuff comes to mind), quickly led to the creation of Ruby and famously "forked itself" with what is now known as Raku.

Now I have barely spent any time with the oldschool Perl but trust me, I have put a lot of effort into learning Raku, the language that was meant to fix Perl. Whenever something that "seemed like a good idea at first but it's actually harmful" shows up, it's usually Perl's legacy. I'm thinking of things like the conceptual mishmash between a single-element list and a scalar value (or in general, trying hard to break down variables arbitrarily into list-alikes, hash-alikes and the rest of the world), the concept of values that try to implicitly pretend they are strings and numbers at will, or the transparency of all subroutines to loop control statements which is some next level spaghetti design. If you ever actually use something like this, you introduce a brand new level of complexity, somewhere inbetween a "goto" and a "comefrom", so I would really think about if this was worth learning at all.

Oh right... from what I remember, it was also Perl that fostered this idiotic idea that a name of a concrete thing could be overloaded to be a namespace as well, and a concrete Foo::Bar could very well be something that has no logical relation to a concrete Foo. Moreover, I'm quite sure Perl invented this nonsensical distribution-module dichotomy where you are supposed to depend on modules, despite the smallest publishable and installable unit being a distribution. There are three outcomes with that: - if the distribution contains only one module: what was the point of drawing the distinction? - if the distribution contains tightly coupled modules: you can pretend to only depend on one of the modules but in fact you are depending on the whole distribution together - if the distribution is a collection of unrelated modules: why are you trying to encouple the metadata when this will make the versioning meaningless?

I can only hope that it's somehow better than Raku but the whole principle is just an anomaly.

And you know, then these people move around in the world, pretending that all of this is just normal and you just have to learn it. Well guess what, there is a reason people might want to put that effort into something else.

Just imagine writing bash incorporating a sed script for something you can do with 20 keystrokes, then migrating the sed part to awk until it reaches 20 lines, then rewrite the whole thing to Python or somehow bridge it to the shell script - when you could have done the whole thing in Perl without feeling that it holds you back...

Well, that's at least an actual argument, even though POSIX regex would have never proven so useful in a variety of use cases.

Other than that, I'm completely shocked that somebody would praise sed or awk in well into the 21st century. Turing-complete languages barely capable of properly solving any problem that has any sort of algorithmic complexity, let alone one that requires proper data types, variables or interacting with any sort of system. Really, you can do that in Perl (even in Raku) without your couple-of-liner horribly breaking down once you need some custom logic to it. Oh, and it will even resemble programming languages, not some hieroglyphs left behind by aliens.

What is the reason for that? I think they should be long gone for the lack of proper data structures, if nothing else.

This topic is akin to "holy wars" and since I used to think the same way (still do to some extent), I would like you to at least consider another aspect: the effort it takes to "grok the language and its idioms" is vastly different depending on the design of the language. Letting people do whatever they want, whatever way they want it isn't only about protecting them from themselves or not.

Just think of C: I'd argue its design is actually more akin to Python than Perl (and it definitely inspired languages like Go and Zig, NOT languages like C++). It's a small language and this is a very important characteristic of it: you can count on being able to actually master it or at least very well comprehend it. Other effects of a simple and literally straightforward language can be: easier implementation and evolvement, less mental load on the developer, easier portability among developers (both for general knowledge and actual code), etc. I'm not saying that C is the way it is for all these reasons but I wouldn't overlook this factor and I do think that languages like Python are deliberately building on these advantages.

Now, I don't dislike C++ at all but back when I studied it at university, I noticed that it was the first language for me that needed to be actually studied, unlike Pascal, C, Python and "oldschool" JS. Ever since, the only languages where I felt the same were Prolog (mostly because it requires a different mindset; other than that, it didn't seem bloated) and Raku. Not C#, not Java, not Erlang. I didn't really have to touch Perl but from all I know, Raku started off as a fresh take on the Perl approach. It seems somewhat more organized but huge nevertheless, to the extent that there literally isn't one person who really "groks the language" all around. In the case of Raku, I wouldn't even say it encourages you to write unreadable code (especially if you have a thing for APL look-alikes, lol) - it's just so rich that there is a good chance you will come across something in someone else's code you have never used before and don't quite remember how it will act in your specific use case.

There are different types of freedom than "do whatever you want". Like, the freedom to feel safe and confident about code. These days, humanity has aggregated an immense amount of knowledge and technology and "I will do it all by myself" is not that much of an option. And even people with such puritanistic tendencies will choose simple and straightforward tools, even if not for the "limitations".