Raku: A language for gremlins
buttondown.email
buttondown.email
1. How much should the language surprise you?
2. When the language does surprise you, should it delight you or horrify you?
surprising
^
|
|
|
delight <------+------> horrify
|
|
|
v
unsurprising
Raku seems to overtly aim for the mostly-unoccupied top left. It's like the designers and users (two sets with apparently very large overlap) all think, "Yes, it's weird. Isn't that grand!"
But when it does surprise you, it's almost never anything good. Stuff like Duff's device, `3[someArray] = value`, etc. The surprises are always the language's raw machinery showing through in unpleasant ways, and never a delightful bonus feature the designers added for you.
I was reading "Writing Solid Code" by Steve Maguire (though it should really be called "how to write code in C without shooting yourself in the foot"). One thing that surprised me, but which made sense, was that pointers can overflow. It's unlikely, and ANSI non-compliant, but something possible nonetheless. Hence, Maguire said that this code:
void *memchr(void *pv, unsigned char ch, size_t size)
{
unsigned char *pch = (unsigned char *)pv;
unsigned char *pchEnd = pch + size;
while (pch < pchEnd)
{
if (*pch == ch)
return (pch);
pch++;
}
return (NULL);
}
"What range of memory would memchr search when pv points to the last 72 bytes of memory and size is also 72? If you said 'all of memory, over and over,' you're right. Those versions of memchr go into an infinite loop because they use a risky language idiom—and Risk wins."
So, he said that that code should be replaced with this code:
void *memchr(void *pv, unsigned char ch, size_t size)
{
unsigned char *pch = (unsigned char *)pv;
while (size-- > 0)
{
if (*pch == ch)
return (pch);
pch++;
}
return (NULL);
}
Yep; on AMD64, bits 48 through 63 must be identical to bit 47, which can be 1 or 0, akin to sign extension.
In practice, I don't think any sane OS would let you reserve the very last n bytes of memory, especially not with an address space as large as that of AMD64, but you can't assume the architecture, and you don't always have an operating system.
And yeah, you could see the same bug with integer array indices, if signed integers wrap.
/* Endless loop if end == INT_MAX */
for (int i = 0; i < end; ++i)
/* code */;Needs to be unsigned to get this failure mode, any signed loop gets compiled assuming no overflow for a different (though similar!) failure mode.
I'm leaning towards "C is surprising". Didn't have to be but as presently implemented is very full of hazards.
In C and C++, compilers will optimize assuming that signed integer overflow doesn't happen, but that doesn't stop it from actually happening. Unless you set it to trap on overflow, signed integers still wrap; it's just that compilers make (incorrect) optimizations assuming that it doesn't happen.
You know, this makes me wonder whether it's better pointers to be compared with signed or unsigned comparisons. Currently, my compiler emits unsigned comparison instructions for them.
for (SomeStruct * curr = p, * end = &p[N]; curr < end; curr += 2) {
// processing the pair of curr[0] and curr[1], with care
// in case when curr[1] doesn't exist
}
for (SomeStruct * curr = p, * end = &p[N]; curr != end; ) {
// processing the pair of curr[0] and curr[1], with care
// in case when curr[1] doesn't exist
if (++curr != end) { ++curr; }
}Yeah, that's what I meant. Thanks for speaking more clearly.
> Are there actually code patterns where it's preferable to just JE/JNE?
That's a good point, and sidesteps the issue of pointer signedness.
I think sometimes JE / JNE isn't enough. For example, if you want to process a buffer in reverse order using pointer arithmetic:
/* p starts off one past the end of the buffer */
char *p = buffer + bufsize;
while (--p >= buffer) {
/* ... */
}
unsigned char *pchEnd = pch + size;
while (pch < pchEnd)
*depending if you think the compiler would ever allocate so as to put you into this position, for example usually the stack is at the top with the heap underneath it so stack overflow would be your risk, not address overflow.
I (and Steve Maguire) had assumed that if pch were 0xFFFFFFFF - size and pchEnd were 0xFFFFFFFF, then it would run into an infinite loop, but it won't; neither pointer will overflow in that case.
It would only run into an infinite loop if you wrote something like this:
pchEnd = pch + size - 1;
while (pch <= pchEnd)
Not always. It's rare, but eg `o[objects].up[objects].t[textures]` was definitely a delightful bonus feature (where `objects` and `textures` are global arrays).
PHP is often just bland drudge, true horror in PHP land is unexpected when I encounter it.
Also debuggers. Give RR a try some time :)
Had never heard of it, looks pretty amazing, I might actually enjoy debugging now!
I know there are workarounds, but we shouldn't need them.
Yet I only hear other people speaking of it positively, so it seems they don't have that experience.
During my undergrad I implemented a semester-long physics project in about 30 minutes. The supervisor had previously taught the Programming in C module, so I asked if I had to use C; he said I didn't, so I used numpy. The code was literally just repeated matrix multiplication.
Other people I showed it to felt it was more on the horrifying side, but like I said, it's subjective.
The problem with Perl (or, I assume, Raku) in production is that the responsible way to read it is like reading every single footnote in an annotated edition of Shakespeare. It sucks the joy out of it, and joy is the point. Production Perl is joyless and therefore pointless, unless you're some kind of prodigy who understands every obscure political reference and every 16th century pun without any help.
Why? Are you assuming a very particular kind of surprise here?
"Oh, I can replace these five lines with a single builtin." is a surprise, and so is seeing that someone else already did so.
e
|
|
|
-r ------------- r
|
|
|
-e(Don't kill me fanatics)
Here is what I guess makes it hard to read for me: There are many terse keywords (fn, mut) and symbols (&, [], ->) along with some things that look like Java annotations and are equally hard to understand without knowing the language. Array slices look easy enough to understand [a..b] but surprise: b is actually exclusive? The definition of arrays is the most weird one I have ever encountered [u8; n]. To me Rust looks much like C++ with a twist and people rightfully complain about C++ often :)
The documentation about language and libraries was solid for my cases and most of the time it seemed enough to ignore most of the tiny key words and symbols without losing much understanding of what the code intends to do. If I were given the choice I'd probably still prefer Rust's weird syntax with added safety over the clarity of C which offers no safety at all (not talking about obfuscated code contests here).
But would you put C++ next to Perl in terms of difficulty reading? I wouldn't have thought they were particularly close. (In terms of normal code at least, not the implementations of ultra-generic templates.)
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.)
That's how I stay alert in every language. :D
Rust feels like an industrial version of Perl to me.
Keep in mind, this is just what I value in a language. The perfect programming language to me is one that is expressive while also being easy to read. I think Python is nice in that regard, and probably why it's so popular to this day. But there's always room for improvement!
if you want you language to apply a standard discipline, then use Python
There were already several 1M+ Perl LoC code bases by the end of the 1990s, as Perl use exploded at places like Amazon.
One key driver of Raku's design was making it easy to write large, clean, readable code bases, and easy to enforce coding policies if and when a dev team leader chose to.
(Of course, as with any PL, you can write messy unreadable code -- and you can even write articles and record videos that make it seem like a given PL is only for Gremlins. But it's so easy to write clean readable code, why wouldn't you do that instead?)
> type hint ... is never enough if it isn't guaranteed by a compiler or at runtime
Indeed. Type hints are a band aid.
Raku doesn't do hints. Raku does static first gradual typing.[1]
The "static first" means static typing is the foundation.
The "gradual typing" means you don't have to explicitly specify types, but if you do types, they're always enforced.
Enforcement is at compile time if the compiler's static analysis is good enough, and otherwise at run time at the latest.
For example, in the Gremlins article only one example uses a static type (`Int`). But user code can and routinely does include types, and they are enforced. For example:
sub double(Int $x) { $x * 2 }
double '42'
SORRY! Error while compiling ...
Calling double(Str) will never work with declared signature (Int $x)
(Int $x)
I know what you mean, but to be usefully pedantic, the CS meaning of "weak typing" can be fully consistent with excellent typing discipline. Let me demonstrate with Raku:
sub date-range(Date $from, Date $to) { $from..$to }
say date-range '2000-01-01', '2023-08-21';
But it passes and works at run time if the function declaration is changed to:
sub date-range(Date() $from, Date() $to) { $from..$to }
The changed declaration works because I've changed the function to be weakly typed, and the `Date` type happens to declare an ISO 8601 date string format coercion.
But what if you wanted to insist that the argument is of a particular type, not one that just so happens to have a `Date` coercion? You can tighten things up...
sub date-range(Date(Str) $from, Date(Str) $to) { $from..$to }
* The compiler may reject the code at compile time for failing to type check; and, if it doesn't:
* The compiler will reject the code at run time for failing to type check unless it's either a `Date`, or a `Str` that successfully coerces to a `Date`.
Yeah, ok, I see what you mean.
>> 0,2,4...10
> (0 2 4 6 8 10)
>> 1,2,4...10
> (1 2 4 8)
Wait... what? Is it looking the next number up in OEIS or something?
Unable to deduce arithmetic or geometric sequence from: 1,2,5
Did you really mean '..'?See, that doesn't delight me. OEIS is what's needed here.
Then I tried it in OEIS and as you say there are too many sequences that start [1,2,3,4,5,...] - I think we may be stuck with generators and yield. But they're not exactly delightful.
Nice reference, by the way.
Thanks! My build scripts just got that little bit more entertaining (for me. not for the other devs).
(now I want to see it in an esolang precisely because he said that)
Perl has it's own healthy share of "delightful surprises" and Raku was mostly designed to eliminate perl's horrifying surprises.
Good grief, I don't miss working in Perl.
Good and grief in the same sentence about the same language ... Perl.
Delighted and horrified?
;-)
It's not that I regret ever having worked in Perl. It's just that I'm glad to have moved on to bigger and better things.
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.
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
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.
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.
say (1..12).map( -> $a, $b, $c { $a - $b * $c } ) # (-5 -26 -65 -122)
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.
The angle brackets are syntactic sugar for word quoting.
<a b c>
("a", "b", "c")
%foo<a> # the value of key "a" in hash %foo
%foo<a b c> # the values of keys "a", "b", "c" in hash %foo
https://docs.raku.org/language/quoting#Word_quoting:_%3C_%3E
I heard something once about "cancer of the semicolon"...
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.
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.)
> 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.
> "Produce" is a term I've never seen used this way before, and I assume it is unique to Raku.
code_report (Conor Hoekstra) has discussed the difference names of `scan` on a couple occasions, eg: https://twitter.com/code_report/status/1246494250537291776
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:
[f] list # or list.reduce(f)
[\f] list # or list.produce(f)
.say for [\**] 2,3,4
4 # 4
81 # 3 ** 4
2417851639229258349412352 # 2 ** 3 ** 4> 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.
[1] https://irclogs.raku.org/search.html?query=produce+reduce&ty...
[2] https://irclogs.raku.org/perl6/2006-05-15.html#17:10-0001
I clearly remember reading through the synopsis and exegesis documents around fifteen years ago and being excited for what was to come, but I also remember the first bits that gave me pause. Like unspace[1].
I also clearly remember when it started dawning on me that Perl 6 (as it was still called at the time) would never see any real adoption by people that were interested in other people working with them on things, whether that be some open source project or at a company with coworkers. It was when I was reading through the advent calendar exercises for some year and realized that while I couldn't recall half the features used to solve the problems, I had been exposed to them all multiple times before. The reason I couldn't remember them was because there were so many ways to solve the problems, that it felt like just keeping up with the features and syntax was overwhelming, and that unless you used a very strict subset of the language, it would be near impossible to limit the effort requires to understand what you read from others, or even yourself some time previously.
To many detractors of Perl, this won't be an unfamiliar complaint, but I've always felt that while Perl (5) projects could easily devolve into a mess if some care wasn't taken, it wasn't that hard to exercise some restraint and still take advantage of the extra capabilities when more power was needed. Put another way, while there was definitely more than one way to do it, it didn't feel like there were tens of vastly different ways of doing it that might have been sourced from random inclusions anywhere in the codebase because of numerous ways to insert entry points into every block, leaving you scratching your head when you encountered odd behavior.
Now, it's not a problem for a language to want to reside squarely in the "this is for screwing around and trying any feature you can imagine and how they interact together", but that's not necessarily great when you are trying to accomplish something with someone else and you need to have a shared base of understanding to work from. The real problem is that many, many people in the Perl6/Raku community obviously really hoped for it to take over for Perl 5 or at least be useful for projects which might have multiple people working on them, whether they be through github or for some commercial work entity with coworkers, so they could spread its use and have a reason to use it on a regular basis. I think once it became clear that it wouldn't serve that purpose as well, many people lost interest. I know that was the case for me. I was an avid lurker on the project for well over a decade, but eventually I just couldn't convince myself it was a good idea to use the language for anything other than small test programs to satisfy my own curiosity, and eventually not even there, since if I didn't already have it installed the overhead for a small test was quite high.
In the end I guess Raku found its niche, and it's doing okay where it is (I assume, I've fallen so out of date I'm not sure), but it's sad that it seems they had to shed a lot of their original community (as someone who identifies as part of their original community) to do so, whether that's through any concerted effort on their own part or not. That is, I don't think Raku changed to be what it is, I think most people eventually realized what the bundle of features that was originally proposed really means in reality, and realized it didn't fit what they actually wanted.
There's More Than One Way To Do It
timtowdy
And then Python got on the bandywagon :) with:
There should only be one, preferably obvious, way to do it
or such, which, in later years, seems to be not bandied about as much.
https://en.m.wikipedia.org/wiki/Zen_of_Python
There should be one-- and preferably only one --obvious way to do it.
one of my greatest pet peeves is when some words in a list, or diagram, are in their adjectival form and some are in their verbal form. "Surprising" + "horrify"
It really unnerves me. The worst is that nearly every company has this in some form in their promotional or educational materials.
E.g. here at Genericorp, we prioritize the following valurs : integrity, kindness, honest,
Etc
You get my point. Drives me nuts this kind of thing constantly slips through the cracks.
I do agree though, that if a language surprises me, it should be to the left quadrant in this case. If a language is not surprising me, it should be delight as well.
I don't know if I call people who made / use Brainfuck sadists as much as I'd call them very geeky / nerdy.
But that's some incredibly clever stuff! I wouldn't want to use it, for like, anything, but if there was a programming based game or code golf contest or something it would probably be a great choice.
And the original article talks about math, and I have no real experience actually doing nontrivial math IRL, so perhaps it has some useful properties for people who do.
Why so? Raku is practical, I have a solid experience of doing a lot of practical things with it. It has all battery included things - type checking, overloading, named/typed function parameters, oop, functional programming - what else you need? Python seems awkward for me in comparison with Raku with all that features ...
I can't get over some of the idioms, they just don't map nicely in my head. The same reason AppleScript struck me as weird, it trys to use natural language on one hand (e.g. `my`, `say`, `sub`, `gather`) with some oddities like `@` being used for (assuming?) scoped iterations or declaring modules[0] and some other from-an-outsider byzantine syntax decisions. For instance, I can logic this out, mostly, but it would not feel intuitive to me to "discover":
```
my @bottles = (flat ((99...2) X~ ' bottles'),
'1 bottle',
'no more bottles',
'99 bottles');
my @actions = (flat 'Take one down and pass it around' xx 99,
'Go to the store and buy some more');
for flat @bottles Z @actions Z @bottles[1..*] {
say "$^a of beer on the wall, $^a of beer.
$^b, $^c of beer on the wall.\n".tc;
}These idioms don't click for me intuitively. Its a very symbol heavy language and the symbols often appear to be overloaded by context.
All to say, its okay! different languages isn't a bad thing, however I can't say that I'd use Raku even if it was the best fit for something, like say, a natural language parser (which based on all evidence Perl / Raku is really good at building parsers)
[0]: https://examples.raku.org/categories/module-management/Fletc...
By all means though, if folks like it, carry on. I am sure Raku as a runtime is well engineered, I respect that.
I don't know what lineage Raku shares other than Perl, but it seems to be on its own plane if you will, and thats cool.
Having come from a Pascal background, C felt weird with all of its curly braces. Then after getting familiarity with C and its ilk, Python felt weird. In fact one of the reasons I was reluctant to learn Python was because I was good enough at Perl that I didn’t see the need to learn Python. I had a similar repulsion to LISP too, until I learned s-expressions and now I can see beauty in LISPs too.
Bar for esoteric languages, whose goals are typically different from a general purpose language, most languages are designed to be useful. So once you spend a little time in it you do start to appreciate some of syntactical quirks you once perceived as ugliness
…or at least that’s been my experience with most languages (and I’ve learned a lot of programming languages over the years)
> WHAT 1/10
(Rat)
> WHAT 1/100000000000000000000
(Num)
in raku, for example, an Int is not an isa (grand)child of Complex (and so doesn't carry that overload) ... but yes it is a Real
so raku separates Real from Complex and Int from Rat and you can go eg. my $x = 1 ~~ Rat; #False and this is aligned with literals - 1 vs 1.1
and then you play nice if things overflow
See: https://docs.raku.org/language/variables#$*RAT-OVERFLOW*
We could (and have) debate whether FatRat should be the default, but imo the right expectation for an untyped language should be that very large or small numbers are represented with a floating point representation that (i) uses the FPU that's right there and (ii) sacrifices precision in the mantissa for accuracy.
Since Raku has (gradual) types, you can easily specify what you want and throw an error.
`INIT $RAT-OVERFLOW = Exception` will throw an exception whenever a switch to Num would happen.
If you want to define your own behaviour, you can. For instance:
class ZeroOrInf { method UPGRADE-RAT(Int $nu, Int $de) { $nu > $de ?? Inf !! 0 } } INIT $*RAT-OVERFLOW = ZeroOrInf
would either convert the value to `Inf`if too large, or to `0` if too small.
Please bear in mind that in raku (like perl and other untyped scripting languages) it is normal to say:
my $x = 1; say 1 + $x; #2 say 'a' ~ $x; #'a1'
My point is that when the type is automatically inferred/coerced like this, is is very natural that small/whole Numerics are Int, that medium/fractional/decimal Numerics are Rat and that large/exponential Numerics are Num (ie double). And that you can freely perform maths operations mixing the various Numeric types at will.
my $y = 1; say 1 + $y; #2 Int say 1.1 + $y; #2.1 Rat say 1e27 + $y; #1e27 Num
And, in raku, if you want to control the type, then just use the type system like this.
my FatRat $r;
I also think from a 2nd order point of view that a denominator of 2*64 means you are dealing with quite a small number 5e-20 ish), although admittedly that is a matter of taste and machine performance. It makes most sense in my view to go with Rat (which is stored as an Int (uint64) for the numerator and an Int for the numerator.
That way (i) you get to use all those transistors that you bought for your FPU and (ii) you do not get a surprise as Rat operations perform slowly without warning.
--- And yes - @lizmat has pointed out the various pragmas to let you control the behaviour you want if you disagree.
For what it's worth I agree with you when it comes to languages where 50+x overhead isn't an ever-present fact; you should generally have to opt in to using decimal types and the like.
Scheme’s numeric tower has a handled exact expressions with exact representations correctly for decades, so I guess its true that is not “moving away from” unnecessary and error-prone use of inexact floats where not explicitly requested, but only because it was never there to move away from.
> (+ 5/3 4/5)
37/15
> (expt #C(0 1) 2)
-1
> (expt #C(3/2 1/2) 2)
#C(2 3/2)
> (complex (fact 10) (fact 20))
#C(3628800 2432902008176640000)
> (/ (complex (fact 10) (fact 20)) 29)
#C(3628800/29 2432902008176640000/29)
Also, related and recent:
Ask HN: Are you using Raku? Pros / cons?
https://news.ycombinator.com/item?id=36922692
Question inspired by starting to watch this: Raku for Beginners, at TPRC 2023:
> The following built-in types inherit from Cool: Array Bool Complex Cool Duration Map FatRat...
> (/ 1.0 3.0)
0.3333333333333333
> (/ 1 3)
1/3
> (- (+ 0.1 0.2) 0.3)
5.551115123125783e-17Look at the following page as a jumping off point for conceptual stuff. Absolutely top class:
I remember downloading them, as multiple PDF files, one for each broad subsection (like perlsub, perlvar, etc.) under the main TOC or so, over a somewhat slow Internet cafe connection and then reading many of them.
Not only excellent content, but excellent typography and design too, even though they were mainly text. I remember, even now, thinking that the PDFs looked really good.
>https://docs.raku.org/language
Thanks for that.
The worst offender in my experience is the module system. There are docs around it, but they would benefit from a rewrite with a less "technical" audience in mind. The module/package distinction is difficult to wrap your head around just from reading the Modules page. The fact that the declared namespace of what you import can be different from the namespace you used to import, but the directory structure has to match the namespace for the compiler to find it... it's useful and makes sense in a strange way, but I had to learn that by fiddling around.
# in Name/Space/Thing.rakumod
unit class Thing { … }
# in UseCode.rakumod
use Name::Space::Thing;
my Thing $thing .= new: …;Something to note is that there are ASCII equivalents[0] for every cool Unicode operator found in Raku. For example, the equivalents for ∈, ∉, ∋, ∌ are (elem), !(elem), (cont), !(cont).
[0] https://docs.raku.org/language/unicode_ascii#Other_acceptabl...
> Raku has no qualms about using Unicode operators.
You have the option. I have used this option because I want my code to be compact and expressive on screen. A good fit for careful, considered, creative unicode usage.
Or the ever popular (Jeez that's new):
> I hate the sigil thing
For me I have been using Raku/ Perl 6 because I loved the expressiveness of Perl's swiss army chainsaw. Raku is Perl to the power of Perl. It's cleaned up. It's expressive. Some massive piles of features have been built up from the good old Perl. It's great. The documentation is good - and does need some continuing work. (The comparison with Perl is tough. Perl documentation was/is just amazing.)
What's the point: Absolutely not saving typing. The point is to have a more visually distinctive notation. A math blackboard would be full of that. For example, in the code right in front of me I have a U+25C0 e2 97 80 BLACK LEFT-POINTING TRIANGLE as a custom infix operator for two specific data types. I could have overloaded an existing one... but no, the existing one still exists and it should be extra clear which one is used. When that code is in front of me, it's perfectly clear which is which. And now that the symbol is there in the code, it can just be copy-pasted. (For good measure, the unicode code point is specified in the operator's definition - but that's not necessary in day to day editing.)
The about on GitHub reads "slaps roof of [programming language]* this bad boy can fit so much [syntax sugar] into it."
They even used the language in the most recent event Advent of Code and won. https://github.com/betaveros/noulith
The author seems to be unfamiliar with both Perl and Raku's history, given that he immediately comments on the x operator for repeating strings. Which has been the case for many decades of Perl. :)
so it looks like the author has at least passing familiarity.
Perl wasn't following the PCRE standard. It was the PCRE standard. Everything else was following it. Usually with some piece missing--far more implementations should have the /x modifier.
The Perl 6 design process didn't throw it away after 30 years. It threw it away with less than 10 years. There was already widespread knowledge that Perl had gone beyond "regular expressions", and IIRC, that was even before it had implemented recursive expressions. Perl 6 would be "patterns", and they would be good enough to be used as a full grammar. The language itself could be parsed in it, and Raku sometimes is, depending on the implementation.
haha true
> The language itself could be parsed in it, and Raku sometimes is, depending on the implementation.
That's fantastic, didn't realize.
It says that (most) other languages followed the standard set by Perl 5, not that Perl followed the PCRE standard
But it is also true that Raku’s grammars were designed from the start to write real parsers in, whereas Perl 5’s regexes sort of gradually got that way.
Raku is an attempt to design a sane regular expression language from first principles, now that we know what we want them to be able to express. The alternative is being stuck with (?:this|(?>or that)) for the next 30 years.
Agreed, but god-damn is it useful.
Because in Raku, grammars are just a different way to write code. Grammars are really just specialized classes. And tokens / rules / regexes are just specialized methods. It all compiles down to bytecode, rather than something you can feed a statemachine.
This has several advantages: if a grammar doesn't provide functionality you need, you can write it in Raku code as part of the grammar.
It also means that when you improve execution of the bytecode, you will also improve the performance of grammars and regexes.
Finally: Raku grammars are very powerful. They are used to parse the Raku language itself. Which is a testament to its power. But also brings a whole set of challenges for the core developers :-)
I admit that I was partly being facetious, but I also don’t think it is entirely impossible. For example, a hypothetical RCRE could provide hash tables for storing named regexes, or could take function pointers for looking up names so that the library user could implement their own storage for them. And so on, and so forth.
I think that a hypothetical RCRE could be as influential as PCRE was, if someone could find the time to do it.
On the other hand, I am very weary of C these days. A Rust crate with procedural macros to provide compile–time grammar compilation would be a lot more fun. If I had some funding I could easily see spending a year or three on that.
I haven't touched perl in years but I still find myself writing regex often!
But sometimes interfaces could be easier with no loss of ability, because they grew over time and nobody ever fixed them.
Let us wizards have our magic!
But this idea of programming in The Large vs The Small: I disagree with that comparison. A less wise person might assume that means it makes a bad language for The Large work. On the contrary, it's probably just as good as any other language at it, maybe better. The problem, as it was with other gremliny languages, is you need wisdom to use it.
Simplest example: using $x instead of @x. Any person who has used a similar language "enough" would never confuse these. In fact, the sigils actually make your life easier when reading the code, because you now know the type (well, the simple type, or with Raku, the interface) just by looking at that variable anywhere it's used. Now you don't have to go look it up, and you can do useful things with the same variable namespace using different sigils. It looks weird, and it's extra characters you shouldn't need, and you need to know what it means to use it, but it can make life easier. (https://www.perl.com/article/on-sigils/)
The problem comes for people without wisdom. The people who don't really know what they're doing. They will probably find this gremlin language a living nightmare. These people need a lot of bowling-bumpers and floaties and kevlar gloves and hard hats and GPS. Somebody let them into a store full of sharp objects and they need a lot of padding to navigate it without killing themselves.
That doesn't mean you can't build a skyscraper with the gremlin language. It just means the accident-prone unwise non-gremlins can't build a skyscraper with it. But wise gremlins can.
Tooling exist to help you and your team do the required work as good or fast as possible.
If you are using tools to gate keep juniors in your field, or that are unnecessary complex in order to stroke your own ego. Then the tool is more of a weapon against the rest of your organisation instead of something helpful.
Except that no: Many people were not even paying attention to that. And the perl sigil system - which was taught pretty much from the start - was still one of the top objections! It wasn't gatekeeping. It was people refusing to learn the tools they were meant to use.
This is actually cool
https://docs.scala-lang.org/scala3/book/methods-main-methods...
Python has typer[1] to do this with type hints. It's limited and gets ugly quickly, but I love it for simple scripts.
[0] nushell.sh
[1] typer.tiangolo.com
Should this be a fundamental lesson for language designers? Should languages come with a converter to switch back and forth between the "calm, proper english version" and the "compact, expert mode" visual?
(Without mentioning the translated programming languages like BASIC in french and such things which were discussed on HN not long ago.)
$lhs ~~ $rhs
$rhs.ACCEPTS($lhs)
('mostly' because ~~ actually aliases $lhs as $_ and passes $_ as the argument to ACCEPTS)
- 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 ||.
> This isn't weird, lots of languages have multiple dispatch. What is weird is that you can also dispatch based on a runtime predicate of the value.
Is it wrong to think of the predicate itself as a type here?
I’m in a desparate need of a message from Captain Obvious right now. I know nothing about perl