japhb No, I'm saying "Things like uniname(chr(6)) will be unnecessarily slow, because uniname will just have to unwrap the string back to its codepoint anyway." 00:00
The MoarVM Unicode engine works on codepoints. 00:01
nemokosch numbers in general aren't codepoints, though. If you want to work with codepoints, you are more than welcome to come up with a sufficiently explicit way
here is one: uniname-codepoint(6) 00:02
japhb uniname(small-uint) *is* explicit. All hail multi dispatch. 00:03
nemokosch no it's not: it talks about numbers, not codepoints 00:04
my point is that the average user is not served by this footgun of what "the unicode name of number 3", or even Ⅲ is 00:07
sure, this is kind of a meta-design principle that I don't have some sort of measurement for 00:08
but I don't see even similarly strong counter-arguments, let alone stronger
it's just "oh we can deal with this, it's alright". Sure you can, that's why you use Raku at all 00:09
japhb The average user will not be confused by uniname(uint) because they either don't know it exists (and thus won't use it), or is capable of going "Oh, it's a codepoint obviously. *Nothing else makes sense*." 00:10
I think in a meta-sense you are underestimating our userbase.
nemokosch if we talk about numbers, they could just as much stringify
I'm aware that the existing userbase is fond of niche things like this and can deal with them just fine 00:11
but I think these kind of things are a large reason that the existing userbase is small
japhb It's not a niche usage ... that's literally how you would do it in any language that has a unicode database, because the unicode DB is *about* codepoints, not strings. 00:13
nemokosch the niche thing is that the same function handles strings and numbers for no particular gain at all and you are supposed to just know by heart what it's going to do with your number 00:14
the gain is really, just so small
japhb Raku is not about making the programmer do more work for something that has a completely obvious meaning in the context of multi-dispatch. If you want a Raku-like thing that is more pendantic, more wordy, and takes less advantage of multi-dispatch, you are welcome to go and build it. Heck, start with a fork of Raku, rename it something else (to comply with the Artistic License), and rip it up as you 00:19
nemokosch and the main problem is this attitude, not whether Ⅲ.uniprops or uniname(3) returns this or that; that's probably not on the top 100 Raku issues
japhb desire.
nemokosch sacrificing any safety or comfort a mere mortal user could have to flaunt some high-level feature or to save a constant number of keystrokes 00:20
japhb There's nothing unsafe about uniname(uint), nor is there discomfort. It's *the logical use*. 00:21
I get your point about it handling both uints and strings and doing something with both. That's the thing with a multi-dispatch-centric language. 00:22
If you do not want multi-dispatch, *fork the language*.
nemokosch it demonstrably doesn't have a completely obvious meaning - it could stringify, like most string Cool operations do - and on an unrelated note, multi-dispatch is also poorly specified so ironically the dispatch is not "completely obvious" even to the runtime
japhb DWIM is a thing in the Perl-family-languages. And yes, for every DWIM there is a WAT. But if you don't want any WAT, you have to give up all the DWIM, and then *you're not writing Raku anymore*. 00:23
nemokosch not all nonsense has to be accepted on the account of DWIMs and WATs, though, that's just a convenient way to spare actually considering concrete situations 00:25
japhb And again, it's fine if you think the language is filled with nonsense. *SO GO FIX IT.* 00:26
nemokosch there is no way to fix it if each and every controversial choice will be resolved by a fairy tale about DWIMs and WATs 00:27
japhb None of us are sufficiently convinced to go off and make such a change ourselves. If you really believe you're right on a lot of this stuff, *prove us wrong* not with arguments and discussions, but with actual working code.
"Rough consensus and working code". Currently the alternate reality you are talking about has neither. 00:28
nemokosch I had a concrete proposal - type the name of the function out, and don't make the user guess how a number acts with an operation for strings - and then this vague story unfolded about how cool multi dispatch is and DWIM and terseness 00:29
this is not a technical issue, this is an attitude issue
japhb A proposal is not *working code*. 00:30
nemokosch this is getting dishonest
japhb How so?
nemokosch I am to believe that after this obstructive argumentation, if I define a function that has the same implementation as a currently existing multi candidate, that would somehow weigh in differently 00:31
no, you have already made up your mind, we are just wasting time now 00:32
this "working code" objection is meant for cases where an idea is welcome but it's not clear how to implement it, this is the complete opposite 00:33
japhb That's why I said "*Rough consensus and* working code". You need both. 00:34
You have neither.
You can build one or the other first and work on the other, but if you're starting from zero, and you're not getting any movement on one, maybe try the other? 00:35
Again, I *encourage* you to fork the language and make something better.
nemokosch again, my understanding was that the objective is to make a popular general purpose programming language 00:36
this is not the only objective one can have
but if that is the objective, then it's not the right attitude to say that "the club finds this clever" 00:37
if the objective is to please a lot of people, then you rarely want to tell your users "well, perhaps this language isn't for you, then" 00:38
japhb Why are you resistent to forking the language? You are a language designer at heart, and clearly understand enough about the language to find lots of edge cases, and you can start with an already-working base and tweak as you like. So why the resistence?
nemokosch I'm not resistent to it, I just find it pointless. Anyway, why do you ask? 00:43
japhb You have many opinions about what *other people* should change in Raku, and that's fine. But it's not clear to me that you both believe in those opinions strongly enough, and are sufficiently willing to put in the effort, to *do it yourself*. NOT convince us to do it. Just do it. 00:46
nemokosch It's not only about "you", like "you" also aren't a lot of people considering the scope and objectives of the language 00:48
this is not the first time the "we are Raku" vibes are too strong 00:49
shimmerfairy Per the specific thing that started the discussion, right now if you got rid of the codepoint-based versions of the Unicode functions, there are certain codepoints that would be impossible to work with. Any codepoint whose NFC_QC property is N will be impossible to work with, since the NFG process that makes a Str would erase them from existence. If we had a more full-fledged Uni that would be an alternative, but at 08:37
this moment there's no way to get rid of the codepoint-based functions (not that I want to get rid of them anyway).
m: say 0x037E.uniname; say "\x037E".uniname; say "\x037E".ord.base(16) 08:38
Raku eval GREEK QUESTION MARK SEMICOLON 3B
nemokosch This is surely educational but to be clear: never in this conversation did it come up to just eliminate anything with no replacement 11:47
timo something i didn't consider yet yesterday is that it's actually more sensible to have uniname on integers than it is on strings, because strings are more often made up of more than one codepoint, and the behaviour of uniname and uniprop to just give you info about the first codepoint is more of a footgun than uniname(3) not giving the same as uniname("3") 11:53
and since strings in raku allow you to have composed characters that don't have an official codepoint, you'll get the initial codepoint of the decomposition of such a composition, which you could even call a footcannon 11:54
nemokosch this ultimately supports the same point 11:56
it's not properly justified to keep numbers and strings behind the very same interface, more bad can come of it than good 11:57
actually it's debatable whether it's worth calling "the same operation" - the one with raw codepoints as numbers is lower-level 12:00
anyway, I think there are simple and sound arguments for not having all of this hiding behind the same interface, functional or OO 12:04
the important issue is not this concrete issue but the attitude of deflection
lizmat "FOSS is what you make of it. You have the right to make the changes you need from the software yourself, and you are the only person that you can reliably expect to do it. You aren’t entitled to the maintainer’s time, but you are, per the open source definition and free software definition, entitled to change the software, distribute your changes to others, and to sell the software with or without those changes." 12:05
nemokosch This premise itself is wrong. I don't come up with wishes but bring up design considerations that anybody could raise and understand, and you aren't hobbyist maintainers of a pet project but supposed leaders of a large-scale project 12:09
timo that's what something being FOSS "guarantees" you, right? 12:31
I can only speak for myself but I can't dedicate anywhere near my entire time and energy to this project, and when I have energy and time I can dedicate there's still the issue that not every tuit is the same shape, and different topics take different amounts of effort at different times 12:34
nemokosch all of this is perfectly fair and I'm a bit confused whether this is an off-tangent or what "triggered" it 12:36
it's completely different to simply not have time and energy for whatever technical or theoretical issue and to outright say, especially for the supposed leaders, "meh, not interested, cope", and somehow try to deflect the whole thing 12:37
lizmat "It is nice when a maintainer offers you their time, but by no means are they required to." 12:39
nemokosch already said it: this is not "offering you time" but putting proper effort into something (language design) that would be their responsibility to begin with 12:40
it's not that you don't do this "for me", you don't do this at all basically 12:41
timo feels a bit like a false dichotomy 12:42
nemokosch where is the dichotomy?
timo responding to your issue is doing language design, not responding to your issue is doing no language design
though you're probably not basing "you're doing no language design at all" on just this discussion from yesterday 12:43
nemokosch that's just false though
I'm not basing it on that
I reject this whole notion that this is somehow about me
timo I can only tell you what I'm receiving
nemokosch anybody else could have raised 10 other issues like this, I expect the outcome would have been the same 12:44
timo I've seen plenty of issues of a language design nature be addressed in the past
nemokosch past by how many years counting? 12:46
timo to be fair I've been with the project for a pretty long time
nemokosch my fundamental position is that there are certain tendencies and situations that anybody could see and simply most people find it easier to move on or to stay silent 12:47
timo I feel like it's very easy to bring up something you think is weird and start a discussion, but I have the benefit of people already knowing me 12:48
what is not so easy is having other people agree with you, but I feel like that's just universal 12:49
I think the difficulty of convincing is what japhb was addressing, as well as the options of going ahead with your suggestion without needing to convince others first, that's what lizmat also joined in on with her last few messages 12:50
nemokosch imo it's okay to disagree over some clear principle, "axiomatically" 12:51
timo does that seem like a reasonable interpretation?
nemokosch it would be okay to even say "we believe that Raku is this recreational hipster language where we experiment and people are free to do things differently from bigcorp dayjob"
that would be transparent 12:52
timo i think "clear principles" and "axioms" may not be worth as much in a real world setting, though it is desirable to stick to them whenever you can
can you elaborate a bit more on that? 12:53
nemokosch which part? 12:54
timo this description you just suggested would be more transparent than what the raku project's messaging actually is
nemokosch for what it's worth, I think it's also a fundamental problem with a large number of the patterns are taken as isolated cases - this goes for technical topics as much as general workflow and discussion dynamics 12:55
timo since i've been with the project for what feels like forever, I have a very hard time to identify what raku looks like from the outside
"very hard time" may be overstating it a tad, but you get what I mean right? 12:56
nemokosch sure
timo oh, a random thought, just to be sure, edits in discord messages don't propagate through the irc relay, I imagine you are aware of that though
nemokosch yes, I know that 12:57
timo good. as i said, just to be sure
nemokosch that sentence ended up butchered and my solution was... to just leave it that way and hope you can auto-correct it
😅
timo the comment about "isolated cases" refers to the situation where you said "3.uniname is weird" and we discussed mainly the issue of codepoints as numbers vs codepoints inside of strings, and "my side" (for lack of a better term?) not going to the more general idea of how Cool makes things that aren't very number-like into numbers? 12:58
nemokosch well, my point is, and I think I basically said the same thing 3 years ago in a zoom meeting as well: Raku exists in a limbo between a pet project/sandbox and a serious striving-to-be-mainstream project
I think this is a real dichotomy 12:59
with implications and consequences going both ways
lizmat ok, I'll bite on this one: what will *you* do to make it a mainstream project?
timo ok, I haven't been to any of these zoom meetings to be fair
nemokosch who is to say which one is Raku? I suppose the steering council, for the lack of anything else
timo to be fair, in the world we have, going from "pet project" to "mainstream project" can happen as more or less an accident 13:00
this example is a little old in the tooth, but the rise of ruby through ruby on rails is what i'm thinking of with that comment 13:01
nemokosch that's true but I feel this is compatible with everything said so far 13:02
no contradiction
timo my thought is, "a pet project" doesn't communicate too much 13:03
nemokosch it also doesn't strategize 13:04
timo "sandbox" suggests to me something like "everything is toppled over and re-made every now and then", where as far as I can tell we do care about backwards compatibility
nemokosch a pet project is like "I do what is useful/fun for me, if you like it, you are welcome to enjoy the advantages, if you don't, you are free to move on" 13:05
timo: backwards compatibility also exists in a halfway state
timo but raku as a language is very malleable, so "if you don't" doesn't have to be "you are free to move on", it can be "you can make it yours as well if you want"
nemokosch there is like a "declaration of intent" about not breaking code but there are no strong guarantees 13:06
timo i'm not sure there can be
nemokosch then let me put it this way: there are breaking changes that everybody knew were breaking changes but "Roast doesn't include them so it's fine", basically 13:07
the most hot topic recently was this div mod situation
timo OK, that's something I can work with 13:08
I haven't actually followed that closely
can you give me a short summary or would it be better if I go fully read github issues related to it?
nemokosch there are a lot of layers but the objective minimal description of the status quo would be: 13:09
roughly 4 years ago somebody opened an issue that div (and mod) doesn't coerce to integers, mostly meaning doesn't coerce from strings to numeric in practice, there was a discussion 13:10
(that somebody was me, for what it's worth xd) 13:11
then roughly two years later somebody concluded this issue by committing a "fix" in Rakudo that made div coerce to Int whenever it can, and mod be calculated as $a - ($a div $b) * $b 13:12
turns out this has funny consequences for numbers that aren't integers, for example 10 mod 1.9 ends up -9 13:13
but again, this is just an example 13:15
there were multiple breaking changes with meta-operators, especially reduction and production
or the equality of pairs, or the boolification of the empty range... 13:16
timo sorry had to be afk for a bit there 13:20
13:21 librasteve_ left
timo it's definitely tricky to navigate fixing bugs vs breaking existing code vs deciding that existing code that relies on the buggy behaviour should be considered wrong, right? 13:23
if you want strogn backwards compatibility guarantees, you'd need bug-for-bug compatibility 13:24
I guess that's just freezing your exact rakudo version? 13:25
nemokosch how to put it. I think almost all of these cases (save the empty range) were considered right at some point, not clear bugs
timo a language with a lot of stuff in it necessarily means you get an incredible amount of possible interactions between things, and someone finding an interaction that puts existing consensus into question is not unlikely 13:26
the difficulty of combining reduction with operators that operate on lists is one spot I'm not sure can really be made fully consistent, for example 13:27
nemokosch that is for sure, and in my thought process this is a reason why language design needs to be taken very seriously 13:28
we actually have the advantage that the "predecessors" didn't have for the longest time: there is Raku code in the open wild and a relatively mature Rakudo
timo how do you suggest taking language design more seriously should be approached? maybe more formalised processes or something? 13:29
nemokosch well, the question is, who has a say and by what means 13:30
currently there are two ways: somebody just commits, like in the case of div and mod 13:31
or everybody is waiting, perhaps for the steering council, to govern the outcome
now, these are the people who are visibly uninterested and mostly sick of the whole thing 13:32
timo what, the steering council?
nemokosch yes 13:33
timo I'm not sure I can judge that comment at all 13:34
I just know that the steering council is meant to be invoked when the broader community needs steering, and not for everything
nemokosch for the lack of any other process, language design is certainly such topic 13:36
but again, I think it's even more important than language design to have some sort of vision of the project 13:37
timo I don't think "language design" is a very sharply defined topic such that you can easily judge whether an issue fits that or not
nemokosch I think the Perl 6 RFC process itself showed pretty well that "the community" won't have the same vision 13:38
timo you would say there should be a team that focuses primarily on questions of language design
nemokosch eventually somebody will just have to decide it
timo the Perl6 RFC process had a very different target audience though 13:39
nemokosch I don't think that matters for the point in case
timo i'm not sure if the people who submitted RFCs were also discussing the RFCs amongst themselves 13:40
IIUC they were just sent to larry directly?
nemokosch could be but again, I'm not sure this makes that much of a difference, not everything can be reconciled or negotiated 13:41
timo then it's just an odd thing to base that on, but i don't disagree on the last thing you just said
the perl 6 RFC process had a lot of "I want a faster horse" in it, which is completely unsurprising 13:42
nemokosch I don't think this has changed much 13:43
what changed is the "demographics", if anything
there was a kind of natural selection of people interested
timo the benefit of having a lot of raku code out in the open already that you mentioned makes a big difference in this, i feel like
I thought that's why you brought that up 13:44
nemokosch my point with that is a counter-argument to raiph's perpetual argumentation that "Raku was designed by very clever people who foresaw everything 20 years ahead" 13:45
timo do you feel like raiph is trying to bring up original design ideas as dogma or something like that? 13:48
nemokosch to have this straight: I have no personal problems with raiph, I don't even know him after all 13:50
timo I didn't mean to imply that
nemokosch but the walls of texts he writes to 80% of design-related issues are basically all about "no, Raku was designed by clever people, there must be a reason that this is the best solution"
everything blows up into some biblical explanation 13:51
timo it feels like raiph's comments are valuable insights into how everything fits together, for a bird's-eye-view if you will 13:52
nemokosch while my general sentiment is that this is the best position ever to have any judgement of individual features and interfaces
timo i'm not sure i understand how this and your previous sentence connects 13:53
nemokosch timo: maybe a weird parallel but I think raiph's comments are like tsoding's live streams
very educational but you basically have to skip through the opinions
because you get something you didn't necessarily ask for 13:54
timo i've only half-watched a small portion of one of his videos so far, i think
but as long as you can skim past the opinion-y bits in raiph's comments, that's fine? 13:55
nemokosch the problem comes when a comment is really only that 13:57
and it's 3 screens long
but anyway, this is at least the fourth topic we are talking about xD 13:58
you know, to return to the more general sentiment 13:59
I'm not even really a "stakeholder" of Raku, I've read way more Rakudo sources and snippets of other people than I have written Raku code myself, for at least 3 years 14:00
I don't even have a set stubborn vision of what Raku must become
I just want it to become something
and be good at that certain something
I want it to be decided what we are cooking for dinner, rather than just throwing everything that appears to us in the bowl 14:01
lizmat yet you don't want to spend effort / time on gathering foodstuffs, or do any cooking 14:02
but keep commenting on what the cooks do 14:04
" I'm not even really a "stakeholder" of Raku, I've read way more Rakudo sources and snippets of other people than I have written Raku code myself, for at least 3 years"
nemokosch that's simply not true
lizmat if you're not a stakeholder, then you don't have a lot to say about it 14:05
nemokosch and the uncomfortable truth is: you know it's not true
lizmat so to me the question is really:
nemokosch it's a lie
lizmat do you want to put in the effort to become a stakeholder or not
timo I can emphasize with the thought "this could be great, but they're doing it wrong and they're not going to make it without changing how they do it" even from essentially a "bystander" perspective 14:06
... empathise?
understand.
nemokosch it's convenient to pretend that I'm just some sort of bored troll but the fact is that I made pull requests for Rakudo, analysed quite a lot of user-reported issues, created a raku.org toolchain that was discarded eventually, made at least 3 doc PR's just this week 14:07
timo not quite like passing by someone sitting on a branch who is currently sawing the branch they're sitting on off
but vaguely related to that thought 14:08
nemokosch not like any of this should matter but if personal arguments are so popular around here
I really don't know why these personal remarks are okay from people who are basically sitting on the language 14:11
lizmat would it help if I would no longer be sitting on the language ? 14:13
timo I'm not sure "sitting on the language" is a fair description for anyone 14:14
nemokosch they aren't just any members of the community, they are the most privileged
and then they play this "we work, you don't" card 14:15
like have some pride
timo they do not rule by the divine right of kings
they serve the community
nemokosch that's a way to put it
they work as they wish 14:16
while I know by examples that my work still depends on the judgement of these people
it's simply not good taste to play "we work and you don't" from this position at all, even if it were true 14:17
lizmat "FOSS is what you make of it. You have the right to make the changes you need from the software yourself, and you are the only person that you can reliably expect to do it. You aren’t entitled to the maintainer’s time, but you are, per the open source definition and free software definition, entitled to change the software, distribute your changes to others, and to sell the software with or without those changes."
"It is nice when a maintainer offers you their time, but by no means are they required to."
I'll keep repeating that
nemokosch then why don't you start your language?
lizmat actually, been there, done that (way before Perl / Raku, for that matter) 14:18
timo how about we all take an hour, because I'd like to go on a walk
nemokosch don't let us ruin your walk 😛 14:19
timo i'm not sure your characterization of the steering council holds true, but I don't know about your particular examples that make you believe that
nemokosch that part that they just do what they want should be pretty obvious 14:20
timo well, I'm asking yall to take a break from the conversation as well so I don't have to worry about getting back and seeing stuff having turned sour...er
they do what they think is the right thing that the greater community expects from them, and if they get shit wrong, we expect the community to bring it up and things to be corrected 14:21
nemokosch I'm also quite sure it has happened at least once that even my PR got hijacked and reworked by lizmat without saying a word
timo that's what i mean by "divine right of kings"
nemokosch there was the raku.org rework that basically just rotted until there was something else (objectively better - gotta give you that - but two years later, totally unrelated) 14:22
timo that comes back to the "nobody owes you their labour" thing from FOSS that lizmat posted 14:23
it's unfortunate for sure that it rotted for a long time 14:24
nemokosch you cannot simultaneously say "do your work" and "I'm not obliged to acknowledge it or support it"
timo but at the same time, almost all, if not entirely all, work on raku is by volunteers
nemokosch not without looking egoistic
timo it's an unfortunate truth that "doing your work" is more than just writing the code 14:25
I can't tell what exactly you could have done to get that landed 14:26
lizmat github.com/rakudo/rakudo/pull/5169 ?
nemokosch it's not just unwelcoming, it disregards the community, the users, all those people who gave something to the project
lizmat github.com/rakudo/rakudo/pull/5152
nemokosch if you want to do whatever you want, then surely a community project is not the right place
timo now i'm confused though 14:27
you seem to simultaneously be asking for stuff you do to be accepted as quickly as possible, and that people can't just do whatever they want to the language as a whole 14:28
lizmat FWIW, all closed PR's that didn't get merged as is, ar referred to in the commit message that *did* do a fix
so I resent the comment that I've been hijacking PRs
(and I *DO* take that personally) 14:29
so please retract that statement
nemokosch I'm not "asking for stuff you do to be accepted as quickly as possible" at all
lizmat: what do you think what you did was, then? 14:30
"let me do something else without even explaining the idea beforehand" 14:32
the way we can "work" is just different
lizmat what I think I did was fix the problem that the PR referred to 14:34
which is what we want in a language: problems fixed 14:35
and if that hurts someone's ego because the PR did not get accepted, then you probably shouldn't be here
because this is *not* about ego, but about the project 14:36
with the limited manpower that we have
nemokosch then it really wouldn't hurt for you to acknowledge that you are privileged
and that it's dishonest to act like you leaders "work" while I "don't work"
you do what you want, I either do or do not what you want 14:37
these are our choices
lizmat you mean: having a commit bit is being privileged
sheesh
timo with lizmat's extensive knowledge of the core and the different layers, we do tend to place more weight on her opinion, but that's not her "being privileged"
her opinion on core matters, in this case
nemokosch it shouldn't be about opinions at all
lizmat and also note: that I have been wrong in the past, and most likely will make errors in the future 14:38
nemokosch her opinions are often like what you can see here
personal beef
lizmat *sigh*
timo i don't agree on that
nemokosch fwiw yes, pushing to "prod" is privilege 14:39
but it's even more privilege that any discussion escalating ends up arbitrated by you
timo we expect very few users to run rakudo's main branch. it is not in any way comparable to pushing to prod
it's not uncommon for commits pushed to the main branch to be reverted later on 14:40
nemokosch these are small technicalities when these commits do usually end up in releases
lizmat I ask the question again: would it make things better if I would quit the Raku project ? 14:41
nemokosch anyway, "not about ego": would it hurt to acknowledge that the circumstances are simply not the same? that somebody does what they want themselves, while others have to adapt to the very same people?
lizmat I ask the question again: would it make things better if I would quit the Raku project ? 14:42
14:42 ShimmerFairy joined
nemokosch I don't think that would address the systemic problems 14:43
but perhaps you could refrain from the dishonest framings of others
lizmat then I ask the question: would it make things better if *you* would no longer be involved in the Raku project 14:44
nemokosch I don't think so right now 14:46
this is mostly a distraction for any substantial discussion
timo I find your accusations of liz in particular hard to stomach 14:47
nemokosch what accusations?
that she does whatever she wants?
timo the assertion that the steering council is an untouchable entity that does what they want and "sits on the language" and that liz is the one who decides on everything that gets escalated upwards
nemokosch the latter is not an accusation but personal experience 14:48
the same people who made remarks like "you are just too bitter because you live in an authoritarian country" 14:49
were the same people to judge this case
timo I haven't seen myself what you're refering to, so I can't speak to the exact things 14:50
nemokosch that's fair but please don't just assume I'm pulling things from my finger
I never intended to call the steering council out because I know already that nothing good comes of that 14:52
timo I'm positive that if the decision from the judges was not in accord with what the community would accept, then it would be possible (and safe) to ask for changes
nemokosch but the audacity to discredit the content of my criticism by "you just expect us to do the work"
that's such bad taste
it surely must be the fault of my supposed trolling that there was no language release for over 7 years 14:54
timo i'm not sure how that has anything to do with what we've been talking about 14:55
nemokosch that these people have no business in pretending they are the restless guards of the project
protecting against us trolls
timo that makes no sense to me 14:56
nemokosch how not?
they just take it as an axiom that they are the language 14:57
that they do the work
when do they reflect on the results?
where does the audacity come from?
timo sorry I don't follow your meaning one bit 14:58
nemokosch okay, then this must all be perfect
timo "the language" can only exist by virtue of people bringing it into existence
nemokosch I won't disturb them
timo I don't feel like anyone is actually claiming anything like "it's all perfect" 14:59
nemokosch then what is anyone claiming? 15:00
apparently it's good the way it is, "do not disturb"
timo what's the alternative to the people who have so far been putting work into implementing and moving forward the language being considered "the language", but also that "the language" is not nearly as important or powerful a concept as you seem to think? 15:01
nemokosch what does this mean? 15:02
timo I'm not sure, I'm having trouble understanding what you mean when you say people "are the language" 15:03
nemokosch that so far it has been two leaders who basically just said "we don't mind, if you don't like it then fork it"
timo I can't help but feel you're going quite a few steps past "trying to make your stance clear" towards just being unnecessarily abrasive
nemokosch invoking pseudo-representation rather than logic 15:04
timo: I can't help but feel that everybody is pouring emotions all over rather than ever listening to an argument for what it is
timo I can't help but think I'm understanding the "fork if you want" comment drastically differently from how you interpret it, which probably means one of us is understanding it differently from how it was meant 15:05
nemokosch does it challenge my patience? probably
what are the different ways of understanding it?
it feels like saying "there is a whole parallel world where all of this makes perfect sense" 15:06
timo "if you want this change, fuck off" vs "if you want this change, you can experiment on your own and share your results"
nemokosch I honestly think even the latter is mostly a distraction
a more polite distraction
when I said "the main issue is the attitude", I didn't mean "woah, rude", I meant "you don't want to deal with things like this at all, do you" 15:10
timo I dunno what to tell you, honestly 15:13
maybe you're the only one who experiences this amount of difficulty getting change proposals to stick? 15:14
nemokosch I don't think many people even try to do it these days, to be frank
but if you look at the suggestion of SawyerX at Raku/doc, you can also see something that didn't go anywhere and basically concluded the opposite 15:15
timo I'll take a look, I assume I can find it easily? otherwise I would appreciate an url 15:16
I'll go for that walk now
nemokosch I can put the url here
github.com/Raku/doc/issues/4732 15:17
Monty Python-esque arc
timo it'd be cool if no one else jumps in on the discussion in the mean time, it doesn't really feel like a productive discussion on the topic you originally wanted can happen without a full reset
nemokosch yeah, I don't think anybody wants to continue this
I'm already watching handball, that's nervy enough in itself 😄 15:18
timo handball, superior to both handegg and football 15:19
this also implies the existence of a fourth sportsgame called "footegg"
nemokosch what's handegg? NFL type stuff? 15:21
timo yes, american football 15:23
nemokosch 😂 15:24
it would be funny to throw that in a goal 15:25
17:13 librasteve_ joined
librasteve my motto: don’t argue with idiots… 17:21
nemokosch are you saying that I'm an idiot? 17:49
the principle is great for what it's worth 17:50
17:54 [Coke] left, [Coke] joined, [Coke] left
timo i would prefer we don't actually call people idiots 18:09
i think we can call out behaviour we find counter-productive in other ways than that 18:10
nemokosch oh some people are routinely allowed to do that 18:17
timo i don't exactly keep tabs on that particular thing 18:19
nemokosch it's better if one doesn't have to
timo i'm not even sure i live up to that myself 18:20
nemokosch for some reason, this not-even-micro aggression just passes, the accusations, manipulative statements pass 18:22
timo it's obviously trivial to spot an instance of a single unkind word, compared to understanding something like a pattern of behaviour over time 18:24
nemokosch I don't care about the personal remarks and opinions made here but I'm strongly convinced there are certain roles that come with certain responsibilities and one is expected to play along
not many people would even be willing to struggle through this amount of indifference, personal discrediting and occsasional insults 18:26
timo I'm not sure I'll understand what you mean even with more explanation. I'll disengage from this topic now 18:27
nemokosch I don't think there is anything very complicated here anyway 18:29
this "only you" argument is largely because most people care less or are wiser than to go through all this trouble
there have been other "only you" people over time 18:30
18:40 ChanServ sets mode: +o lizmat 20:38 Pixi left 20:43 Pixi joined 20:58 finanalyst joined 21:54 finanalyst_ joined 22:38 coleman left 23:02 finanalyst_ left 23:03 finanalyst left

Powered by Cro and the Raku® Programming Language.

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

Thank you!