🦋 Welcome to the MAIN() IRC channel of the Raku Programming Language (raku.org). Log available at irclogs.raku.org/raku/live.html . If you're a beginner, you can also check out the #raku-beginner channel!
Set by lizmat on 6 September 2022.
00:00 reportable6 left 00:02 reportable6 joined 00:12 mtj left, mtj joined 00:36 perryprog left, perryprog joined 00:54 ProperNoun left 01:19 Manifest0 left 01:31 stanrifkin left 02:11 ProperNoun joined 03:11 nativecallable6 left, notable6 left, sourceable6 left, greppable6 left, benchable6 left, committable6 left, squashable6 left, statisfiable6 left, bloatable6 left, coverable6 left, bisectable6 left, linkable6 left, unicodable6 left, quotable6 left, tellable6 left, reportable6 left, releasable6 left, evalable6 left, shareable6 left, bisectable6 joined, linkable6 joined, notable6 joined, shareable6 joined, committable6 joined, greppable6 joined 03:12 statisfiable6 joined, sourceable6 joined, reportable6 joined, unicodable6 joined, bloatable6 joined, releasable6 joined 03:13 quotable6 joined, nativecallable6 joined, benchable6 joined, tellable6 joined, coverable6 joined 03:14 squashable6 joined, evalable6 joined 04:14 unicodable6 left, greppable6 left, benchable6 left, reportable6 left, shareable6 left, committable6 left, bloatable6 left, evalable6 left, squashable6 left, sourceable6 left, tellable6 left, notable6 left, bisectable6 left, coverable6 left, nativecallable6 left, quotable6 left, statisfiable6 left, releasable6 left, linkable6 left, tellable6 joined, notable6 joined, evalable6 joined, nativecallable6 joined 04:15 shareable6 joined, unicodable6 joined, coverable6 joined, linkable6 joined, bisectable6 joined, statisfiable6 joined, committable6 joined 04:16 sourceable6 joined, releasable6 joined, bloatable6 joined, benchable6 joined 04:17 greppable6 joined, reportable6 joined, squashable6 joined, quotable6 joined 05:17 shareable6 left, tellable6 left, nativecallable6 left, squashable6 left, bloatable6 left, notable6 left, greppable6 left, statisfiable6 left, linkable6 left, reportable6 left, unicodable6 left, committable6 left, coverable6 left, quotable6 left, evalable6 left, benchable6 left, bisectable6 left, releasable6 left, sourceable6 left, reportable6 joined, coverable6 joined 05:18 nativecallable6 joined, greppable6 joined, evalable6 joined, bloatable6 joined, notable6 joined, committable6 joined 05:19 squashable6 joined, sourceable6 joined, bisectable6 joined, statisfiable6 joined, shareable6 joined, linkable6 joined, quotable6 joined, benchable6 joined, tellable6 joined, unicodable6 joined 05:20 releasable6 joined 06:00 reportable6 left 06:03 reportable6 joined 06:27 swaggboi left 06:40 jpn joined, abraxxa-home joined 06:50 swaggboi joined 07:29 abraxxa-home left 07:49 merp left 07:54 merp joined 08:22 jpn left 08:23 tea3po left, tea3po joined 08:24 tea3po left 08:25 tea3po joined, jpn joined 08:39 andinus joined 08:54 jpn left 09:12 wayland left, wayland joined 09:16 jpn joined 10:03 Manifest0 joined 10:22 Sgeo left 10:59 raiph joined 11:10 jpn left 11:13 leah2 left 11:26 leah2 joined 11:50 jpn joined 11:51 derpydoo left 11:54 jpn left 12:00 reportable6 left 12:03 reportable6 joined 12:15 jpn joined 12:20 jpn left 13:20 evalable6 left, linkable6 left 13:21 evalable6 joined 13:23 linkable6 joined 13:32 jpn joined 13:38 jpn left
leont Is it by accident or on purpose that \:foo doesn't do the same as \(:foo)? 13:41
The former creates a capture with a pair as its only positional argument, the latter creates a capture with a named argument. 13:42
Frankly, the former confuses the hell out of me
lizmat feels like a case of DIHWIDT 13:43
leont In what way? 13:47
lizmat well, I never manually create captures like that, let alone a fixed \:foo one 13:48
but I guess that's me then :-)
leont Oh I know I do something weird here, but weird isn't wrong.
lizmat anyways, not sure if it is an accident or intentionally so
leont I can't think of any reason for the former behavior, so I'm kind of assuming it's an accident. 13:49
(I'm using captures as a syntax for some complicated stuff in SQL::Abstract)
lizmat bisectable6: dd \:foo 13:54
bisectable6 lizmat, Will bisect the whole range automagically because no endpoints were provided, hang tight
lizmat, Output on all releases: gist.github.com/4e4c727b69e228c0e9...eeeb4ad74d 13:55
lizmat, Bisecting by output (old=2021.12 new=2022.02) because on both starting points the exit code is 0
lizmat, (2022-01-05) github.com/rakudo/rakudo/commit/27...4fbbe6f9fa
lizmat, bisect log: gist.github.com/bb336c79e6b5867910...9d46368b8e
lizmat, Output on all releases and bisected commits: gist.github.com/cf35b1a3beca8b6144...f6c53bf273 13:56
lizmat seems to have been the same always? 13:57
bisectable6: .say for (\:foo).hash 13:58
bisectable6 lizmat, Will bisect the whole range automagically because no endpoints were provided, hang tight
leont The latter case is because List.Capture, the former case I don't fully understand yet
bisectable6 lizmat, ¦6c (68 commits): «»
lizmat, Nothing to bisect!
lizmat hmmm 13:59
nemokosch so, is this the way to create a Capture where a pair is a positional? 14:00
leont nemokosch: why would you want that? 14:01
nemokosch for destructuring
if your data happens to be a Pair for whatever reason, you basically can't retrieve it via destructuring because it will be faked as named 14:02
leont Right, because List.Capture 14:03
nemokosch it doesn't even matter that your pair doesn't have string keys but honestly, that's still better than downright having different behavior based on the type of the keys of your data... 14:06
I think this is the actual meaning of "strangely consistent" - high-order data is used for faking a lot of syntax, and whenever you want to use them as generic data, it will cause problems 14:08
confer smartmatching, confer the ... operator, confer pairs and argument passing
leont Things in this area aren't quite optimal 14:10
nemokosch: I don't think it solves your problem either, unless you want to pass a single argument 14:16
In which case you're probably not using destructuring
nemokosch yes, true 14:17
lizmat fwiw, I wouldn't be against making :colonpair syntax for named args only, and fatarrow syntax for Positional Pairs in a future language version 14:18
nemokosch I'm kinda sorry for the fatarrow syntax because I don't like the colonpair syntax at all... but if that's the sacrifice to be made... 14:21
My "evolutional cycle" with Pairs went from "Pairs are kinda cute and exotic for 2-tuples" to "Pairs are fundamentally asymmetric and should only be used for associating keys with values" and eventually "Pairs shouldn't be used in user code at all" 14:23
leont I find them useful but a little too magical at times 14:30
nemokosch and then there are people around Raku doing sort of promotional stuff on various platforms - I don't think there is any point in naming them, and I do think they act in good faith - who practically make novice users feel gaslighted by stubbornly sticking to the ideals that everything in the language is thoroughly planned and for the greater benefit 14:31
it's rather the ideal that is harmful and hard to escape 14:32
14:38 linkable6 left, evalable6 left, evalable6 joined, linkable6 joined 14:45 xinming left 14:47 xinming joined 15:02 ab5tract joined 15:04 jpn joined 15:11 jpn left 15:35 jpn joined 15:39 jpn left 16:17 jpn joined 16:27 jgaz joined 16:40 tea3po left 16:44 [Coke] left 17:11 teatime joined 18:00 reportable6 left 18:01 reportable6 joined
japhb m: sub foo($p (:$key, :$value)) { dd $p, $key, $value }; foo("a" => "pair"); 18:54
camelia :a("pair")
"a"
"pair"
japhb Of *course* you can destructure a pair. ^^
19:01 evalable6 left, linkable6 left 19:02 linkable6 joined 19:04 evalable6 joined
nemokosch m: ((1 => 2, 5 => 4), ).map(-> ($first, $second) { say "The second horse is $second" }) 19:11
Raku eval Exit code: 1 Too few positionals passed to '<anon>'; expected 2 arguments but got 0 in sub-signature in block <unit> at main.raku line 1
nemokosch tough luck
this is what I meant, not that you can't look into a Pair when you know you got one 19:12
19:17 ab5tract left 19:19 andinus left 19:21 jpn left 19:26 ab5tract joined
japhb What are you even trying to accomplish there? That looks like a lot of confusion. 19:30
19:30 jpn joined 19:44 jpn left
nemokosch it's not that difficult 19:45
m: (<1 2>, ).map(-> ($first, $second) { say "The second horse is $second" })
Raku eval The second horse is 2
nemokosch say, you have an indefinite amount of n-tuples and want to destructure each one of them
if the n-tuples happen to contain Pairs, you are suddenly screwed 19:46
japhb If you know the n-tuples *might* contain Pairs, you just don't handle them that way. I'll grant you that Pairs with string keys are handled specially by binding (which is what destructuring is actually doing). 19:58
m: ((1 => 2, 5 => 4), ).map(-> $t { say "The second horse is $t[1]" })
camelia The second horse is 5 4
japhb Especially since that ^^ works perfectly well 19:59
m: ((1 => 2, 5 => 4), ).map(-> $t { say "The second horse's key is $t[1].key()" })
camelia The second horse's key is 5
japhb As does that ^^
nemokosch well yes, that's the problem. The values provided can sabotage the structure. If Pairs are so special that they can break the expectation that you get positionals back as positionals, maybe they are not suited for user space. This is not something that should ever happen 20:01
japhb Do you feel similarly about Junction and Mu and other such special cases?
nemokosch I think these comparisons usually derail the topic too much 20:05
For Junction, it can be argued that it's both a structure and something abstracted away from the users, who probably should only use it as structure, not as a value in the traditional sense. If the same stands for something that is called simply "Pair", then the name itself is a trap. 20:07
japhb Wasn't trying to derail. I'm asking "Do you dislike having certain types that carry semantic value *to Raku itself*, and that thus have behaviors that are not exactly like "plain old objects"?"
Because all abstractions eventually leak, so having abstractions over such special types simply means that eventually they'll leak and people will be surprised. 20:09
Junction, Mu, Seq, Pair, ... they all leak.
nemokosch Well, I don't know if we can just push Junction and Pair into the same bag like that 20:10
What I don't like - or it would be more accurate to say, I deem problematic for writing reliable code and understanding it - is this pattern that a lot of apparent syntax is special handling of data types, which looks clever and all as long as you only use hardcoded literals but will cause serious headaches once you want to use the exploited types as mere data to be passed around 20:11
I can stand by the three examples I've given: 1. this behavior of Pairs 2. the special casing of Boolean and especially Match in smartmatches 3. the special handling of Callables and everything that can create a list, in the ... operator 20:13
japhb It's very valuable to be able to pass around Capture and Signature. I can totally understand if you want a true Tuple type. So ... make one?
nemokosch oh right, Callables themselves are a special case in smartmatches 20:14
japhb Callables are a special case for most things, because the DWIM outweighs the WAT for most of us. 20:15
nemokosch and this is why Raku is damned to be a "90% language" 20:16
90% of times, it will do the right thing. But 90% is usually not enough for serious work
japhb The whole point of Raku's design was to be mutable. If you don't like it, mutate it! :-)
20:16 El_Che left
japhb Are you claiming that other languages do not have WATs in them? 20:17
20:17 El_Che joined
nemokosch they have a disproportionally smaller amount of it, and I have Javascript in mind right now, not a language praised for visionary design 20:18
japhb actually boggles 20:19
nemokosch I do enjoy writing Raku code for little scripts, don't get me wrong
japhb I was expecting you to pull out Rust or Haskell or some language praised for its design, but JS?
nemokosch but after 2 years of using it, I can actually feel the difference, even when using JS
there are just disproportionally fewer things that can go wrong, it's that simple 20:20
japhb I don't even know how to respond to that. I'm flummoxed. 20:22
nemokosch In Raku, I can write the "most clever" (subjectively speaking, of course) piece of code - but I would never have the confidence that a user won't break it with certain unexpected input
and that is a really bad thing
20:22 teatime left 20:23 teatime joined
and not to be arrogant but I think I have learned the way Raku works more than the vast majority of people would - this is why I am even aware of these problems 20:23
japhb "Clever" and "secure" don't go well together in *any* language. 20:24
And no one should write code that has security requirements if they don't understand it.
nemokosch the problem is that Raku has been designed around cleverness, and never around understandability 20:26
japhb As for the arrogance question ... what level of skill do you think most of the inhabitants of #raku-dev have? Note how many of them are also here.
You can speak plainly in English. And you can be obfuscated in English too. Same with C, for example. And Raku. 20:27
nemokosch or how to put it... it's not like Raku could not be understandable, it's much rather that it's designed in a way that discourages understanding it, because it will "magically do the right thing" 90% of cases
The vast majority of people will only notice something was there to be thought of when they hit the 10% when something else happened that they would have never even dreamed of 20:28
japhb So this comes full circle -- it sounds like you would rather have vastly less DWIM if you also got less WAT. 20:29
nemokosch it took me some time to understand this layer of the philosophy... that DWIM itself created DIHWIDT, as a means to escape a lot of WATs 20:30
"if it didn't do what you meant, surely you couldn't have really mean it"
japhb DIHWIDT means "Well, you continued trying to find the breaking point of the magic, and you eventually found it. Congratulations, here's your Raku Darwin award. We're not fixing it." 20:32
It does *not* mean that we don't recognize that said person did in fact find the breaking point.
nemokosch The tough part is to be able to tell what sort of breakage is really "illegitimate" 20:33
and with JS as well, I think what needs to be realized and come in terms with, is that these questions are considerably less common for an average mainstream language (even without any theoretical purity) 20:34
japhb And that's fair. But that's why you *ask* about it, rather than *gripe* about it. 20:35
JS went through a period (around ES6 IIRC) where the language was vastly improved and regularized. It's not at all the giant mess it was back in the 90's.
nemokosch JS6 mostly extended the existing JS and "strict mode" allowed certain common mistakes to be signalled as errors. It's true that it was easy to make mistakes in "old JS" but it was also pretty easy to understand them, there was not a lot to learn 20:37
japhb (Though I suppose if you tried to swim upstream, you could probably recreate that hellscape and get it to "run" on a modern JS runtime. But that's just saying that old stuff will still compile, not that it represents JS as it is taught now.)
nemokosch By the way, can we agree that DWIM is practically the antithesis of Python's "explicit is better than implicit"? 20:39
japhb Well ... if Python actually *kept* to that, I'd agree. But I'd perhaps say that those two *statements* are in opposition, rather than that the two *language implementations* are in opposition on that point. 20:41
nemokosch Well, it's always kind of vague 20:42
even the staments aren't very "explicit", and also they kind of convey a bias 20:43
the word "implicit" is more stigmatic than the phenomenon itself, thinking of C++ for example 20:44
teatime speaking aloud in a human language is a lot like typing with your mouth 20:45
wrong window, apologies
nemokosch 😂
also, for what it's worth, I still haven't reached the point of the "late" AlexDaniel to completely prefer a simplistic and opinionated language 20:48
in fact, more of these problems could be addressed by introducing certain distinctions, rather than removing behavior. Like, the distinction of a named argument, a named parameter and a pair 20:50
21:09 dustinm` left 21:10 dustinm` joined 21:17 jpn joined 21:23 jpn left 21:24 raiph left 21:35 Sgeo joined
tonyo go is pretty boring/verbose to write and about as simple as they come 22:15
22:29 kk joined, kk is now known as DeVol, DeVol is now known as DeVoL 22:38 DeVoL left
coleman Go in the streets, Raku in the sheets 22:48
nemokosch Go is the polar opposite of Raku, pretty much 22:56
it's a self-proclaimed counter-revolutionary of C++ 22:57
leont tonyo: neoclassical is my favorite description 23:01
nemokosch: the problem isn't even pairs itself, it's literally List.Capture that makes this weird translation 23:03
nemokosch github.com/rakudo/rakudo/issues/4534 I suspected
this issue will soon have its second birthday
anyway... neoclassical? is that for Go? 23:04
leont Yeah, that's for go 23:05
And I didn't know that ticket, but I should follow it
Literally changing that one method would change everything in this area, but I have no idea what relies on this currently and how to fix it 23:06
nemokosch well, vrurg didn't really say anything cheerful about it
I would rather say neoclassicist for Go, neoclassical reminds me of progressive rock and stuff, usually baroque-ish 23:07
leont The sensible thing is a List always turns into a positional Capture, and a hash a named capture. Anything else it just madness. 23:08
It has the smell of a quick-fix
nemokosch youtu.be/05k8DgEXZXM?t=166 this sounds more Raku to me than Go lol
leont (as in, it came about as a quick fix instead of actual design)
nemokosch "just learn the instrument" xD 23:09
23:20 wayland left 23:37 charsbar left, charsbar joined
leont The operation it performs is essential in some places, function calls being the obvious one, but it should have been wired differently. 23:57
nemokosch makes sense 23:59

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!