nagaiaida

coming back to raku after basically any other language is a breath of fresh air. i haven't even been worrying much about when the ast stuff lands cause i can't think of anything i would even want to mess with that much, even though i seem fundamentally incapable of engaging with lisp/prolog/forth without giving in to the siren song of metaprogramming. to me that's a very strong sign of how much it gets right as a base language.

i do all my automation with one tiny 20 line raku script that manages a thousand things. hell, the entire monitoring site for our frog is basically just a pile of mixins with a neat little pipeline interface unifying everything from request profiling and html templating to reading from and filling that cache in parallel whenever it remotely pulls the sensor data off various things and gets the current webcam frame.

what language do you think the amish speak at home? which schools do you believe they attend?

do you expect this to be the sole example you've failed to consider?

neat how you always have to dig in yourself in order to find out whether or not "sex-dependent" means chromosomal or endocrine differences. good thing those are in perfect lockstep or else we'd have to worry that we habitually gloss over such salient aspects.

this is pretty much exactly how my "forth" handles tail call elimination, and it's the main thing that's added the quotes so far since it shifts the mental burden to being aware of this when writing code to manipulate the return stack.

as you imply towards the end, i'm not confident this is a trick you can get away with as easily without the constraints of concatenative programming to railroad you into it being an easily recognizable pattern for both the human and the interpreter.

thank you for pointing this out! i probably would not have bothered to click through if i hadn't seen this comment, and i would have missed a well-articulated stance on an issue i think about every time i pick a license: whether or not freely sharing my work will have a net positive effect on the world.

on contradiction is an apt choice of essay to look to here.

i wasn't going to speak on twenty enemies because i haven't read it before, but after reading five pages or so i went back to a section that had stuck with me only to discover it was the same one the author had pulled as the first quotation. not exactly where i would have expected to stumble across this, but here we are. again, thank for you calling out that this was more than the milquetoast drivel i had assumed it to be from an uncharitable reading of the title alone.

apl-family languages also often read easier right to left

in the first image you can see the dip in the bottom of the front iroshizuku bottle peeking out below the label

raku's take on gradual typing may be to your taste; i likewise prefer to leave irrelevant types out and use maximally-expressive types where it makes sense¹. i feel this is helped by the insistence on sigils because you then know the rough shape of things (and thus a minimal interface they implement: $scalar, @positional, %associative, &callable) even when you lack their specific types. in the same vein, dynamically scoped variables are indicated with the asterisk as a twigil (second level sigil).

  @foo

is a list (well, it does Positional anyway), while

  @*foo

is a different variable that is additionally dynamically scoped.

it's idiomatic to see

  $*db

as a database handle to save passing it around explicitly, env vars are in

  %*ENV

things like that. it's nice to have the additional explicit reminder whenever you're dealing with a dynamic variable in a way the language checks for you and yells at you for forgetting.

i would prefer to kick more of the complex things i do with types back to compile time, but a lot of static checks are there. more to the point, raku's type system is quite expressive at runtime (that's what you get when you copy common lisp's homework, after all) and helpful to move orthogonal concerns out into discrete manageable things that feel like types to use even if what they're doing is just a runtime branch that lives in the function signature. doing stuff via subset types or roles or coercion types means whatever you do plays nicely with polymorphic dispatch, method resolution order, pattern matching, what have you.

in fact, i just wrote a little entirely type level... thing? to clean up the body of an http handler that lifts everything into a role mix-in pipeline that runs from the database straight on through to live reloading of client-side elements. processing sensor readings for textual display, generating html, customizing where and when the client fetches the next live update, it's all just the same pipeline applying roles to the raw values from the db with the same infix operator (which just wraps a builtin non-associative operator to be left associative to free myself from all the parentheses).

not getting bogged down in managing types all the time frees you up to do things like this when it's most impactful, or at least that's what i tell myself whenever i step on a rake i should have remembered was there.

¹ or times where raku bubbles types up to the end-user, like the autogenerated help messages generated from the type signature of MAIN. i often write "useless" type declarations such as subset Domain-or-IP; which match anything² so that the help message says --host[=Domain-or-IP] instead of --host[=Str] or whatever

² well, except junctions, which i consider the current implementation of to be somewhat of a misstep since they're not fundamentally also a list plus a context. it's a whole thing. in any case, this acts at the level of the type hierarchy that you want anyway.

i only meant that "optimized/eliminated tail call" is more useful terminology than an uneliminated tail call not counting as "a tail call". i find this distinction useful when discussing clojure, for instance, where you have to explicitly trampoline recursive tail calls and there is a difference between an eliminated tail call and a call in tail position which is eligible for TCO

i'm not sure how commonly tail calls are eliminated in other forthlikes at the ~runtime level since you can just do it at call time when you really need it by dropping from the return stack, but i find it nice to be able to not just pop the stack doing things naively. basically since exit is itself a threaded word you can simply¹ check if the current instruction precedes a call to exit and drop a return address

in case it's helpful this is the relevant bit from mine (which started off as a toy 64-bit port of jonesforth):

  .macro STEP                                                                             
    lodsq                                                                               
    jmp *(%rax)                                                                         
  .endm  

  INTERPRET:                                                                              
    mov (%rsi), %rcx                                                                    
    mov $EXIT, %rdx                                                                     
    lea 8(%rbp), %rbx                                                                   
    cmp %rcx, %rdx     # tail call?                                                     
    cmovz (%rbp), %rsi # if so, we                                                      
    cmovz %rbx, %rbp   # can reuse                                                      
    RPUSH %rsi         # ret stack                                                      
    add   $8, %rax                                                                      
    mov %rax, %rsi                                                                      
    STEP

¹ provided you're willing to point the footguns over at the return stack manipulation side of things instead

the call is still in tail position whether or not it reuses the stack frame. there are also more involved ways to do tail call optimization than a direct single-jump compilation when you leave ret behind entirely, such as in forth-style threaded interpreters

Does it not?

>Over the six-year period that had followed the passage of the Family Planning Services and Population Research Act of 1970, physicians sterilized perhaps 25% of Native American women of childbearing age, and there is evidence suggesting that the numbers were actually even higher.

https://time.com/5737080/native-american-sterilization-histo...

>and apparently bluetooth is about as bad.

I thought they made it pretty clear.

>Trans man: Well that's what being a man means. It's transphobic to think anything else.

I don't know what trans men you've met, but this is laughably far from my near-universal experience of hearing them say things like "oh god what if the way I assert masculinity makes someone feel bad or invalidates someone else's feelings or experiences." I have no doubt people have said things akin to that (being trans is by no means an inoculation against horrifically bad takes) but basically every trans person I know explicitly has a model of gender that doesn't invalidate your experience of "I don't experience gender like that, but 'man' works well for me, not least because of my physical body."

People may point out that it could be good to pull on that thread and consider the possibility of being agender or otherwise non-binary, but no one I know would call you transphobic for critically engaging with your gender and coming to the conclusion "nope, still don't get anything new from considering this, 'man' it is". Quite the opposite in fact, as even attempting to do so should be a decent signal for empathy with trans people.

At the end of the day, the label is for you however that manifests; whether it's having a mental model of gender where you finally have a place instead of always being pushed to the side, or having a magic phrase that indicates to someone the broad strokes of how you'd prefer to be addressed, the label is only important insofar as it helps you.

>If we should [talk] about "people who menstruate" rather than "women"

Just to clarify, "people who menstruate" isn't woke code for cis women to make trans women more comfortable. It's explicitly inclusive of trans men since many do menstruate and strongly prefer not to be labeled women as a result of that.

This is what makes Rowling's take on "people who menstruate" as well as the strong chorus of "trans women are women" and much weaker echo of "trans men are men" in response to it that much more tone-deaf. Trans men were the people whose experiences Rowling aimed to invalidate, but as usual trans women became the public face of the issue.

>Taking the "feeling" of being a man/woman as definitive is exclusive because not everyone who has other gendered traits has such feelings just as taking physiology as definitive is exclusive because not everyone who has other gendered traits has the same gendered physiology.

For argument's sake, what if your subjective experience of being a man were just so ingrained in you that you never consciously engaged with it? That could manifest the same way ("i don't 'feel like a man', that isn't how being a man works for me"), but now would you have a place in the "feelings" model you've established as exclusionary.

It seems to me that the fundamental issue you describe comes down to the coexistence of "I'm a man because that's just what I am" and "I'm a man because I feel like a man", and the only conflict inherent to that comes when the former group feels pushed out by the latter. I personally fail to see any way that someone embracing masculinity, especially if it's something that's long been denied to them, invalidates the experience of a man who's comfortable enough being labeled a man even without subjective experience of his gender.

How confident are you that the root cause of that political silence is a shared belief that politics shouldn't come up in the workplace rather than potential concern about the effects of openly discussing the issues that affect them?