1. the functional/immutable nature of Elixir makes read and writes much more explicit and there is no need to magically track deep mutations of nested objects to translate them back into UPDATE/INSERT queries
2. Elixirs support for lisp-like macros allows for an ergonomic embedded query languages that is syntax and schema checked, mirrors raw SQL really well and, frees you from string-oriented query building
3. the query builder DSL addresses one of the main weaknesses of SQL query statements not being composable
4. The automatic conversion between JOINed tables (on the DB side) and nested structs (on the Elixir side) is done on the right abstraction level to work reliable and and being explicit enough to generate predictable queries.
If the comment above is correct, he was only added to the credits after he had to ask for it after the fact.
So the ONLY thing the license asked for is to be named and that was supposedly violated. So a multi million dollar company can just violate a generous license and then after a fact cling to this exact license while arguing to not pay a single cent more than the license asked for. Alright...
Very cool! I did a similar (but much simpler!) experiment by implementing perspective projection via SQL, storing meshes (vertices, edges, faces), the camera position and the screen size in tables and building a single query that generates the SVG paths (including backface culling). Running via WASM SQlite inside the web browser. [1]
SELECT project(...) as x, project(...) as y
FROM model, vertex, camera, transform
WHERE clockwise AND clipped IN BETWEEN -1 AND 1
"I would like my child to not be deaf" -> "Many (most?) people would prefer their child to not be deaf" -> (3) "Deaf community shrinks" -> "Social support for deaf people is reduced/seen as not necessary" -> "Parents of deaf children are blamed for carrying out the child" -> "Parents are nudged (forced) to terminate the pregnancy" -> goto (3)
In a some way this is already happening (eg Judges forcing cochlea implants on babies while denying the parents support in learning/teaching sign language to the child)
Many people see this as an attack on the deaf community and their culture - and I have to agree.
In terms of slippery slopes, this argument is climbing atop one. Where does that end? Should we ban doctors from performing surgeries that would save someone's hearing? Should we ban protective gear that might diminish the size of the deaf community?
It's simply a horrible argument to suggest that you have to protect a disadvantaged community by making sure they don't shrink. There's much better ways to be respectful of the great human beings these people are.
Who shows them in "bad light"? Sane people see the condition itself in "bad light" not the people affected, who deserve compassion, help, accommodations etc.
Twisting things around to make people seem bigoted for saying that disability is bad (not that disabled people are bad) is just evil.
It has to be turned around 180 and we have to point out that this push is moral corruption and evil. Even if it comes in part from deaf people it is evil. It doesn't matter what mental acrobatics is developed around this, to wish for other people to become disabled is evil and morally outrageous.
It's the same with the "obesity is actually not unhealthy" crowd, all part of the same ideological matrix.
But then the same enlightened crowd turns around and pushes to legalize euthanasia for depressed people in their 20s...
A shrinking deaf community has nothing at all to do with ethnic cleansing, and social support does not shrink for less common diseases - it's usually the opposite, with support proportional to how rare and inconvenient the disability is.
Let's try a small thought experiment: Some birth defects stem from dietary issues in the mother during pregnancy, like folic acid deficiency or alcohol consumption.
Let's imagine that we discover that deaf children are primarily caused by a particular vitamin deficiency during pregnancy. We can then either spread the information so parents can supplement, or even fortify foods and cause the community to massively decline or even disappear - or we could withold the information on the vitamins to artificially maintain the population of the deaf community.
You could even extend it to a scenario where we end up relying more and more on artificial insemination or other early processing - the impact of many dietary deficiencies happen extremely early, so to maintain the community we would then have to artificially cause said deficiency to maintain the population of the deaf community.
Heck, we can always just make people deaf later if you wanted to maintain their community. We could also make more people get into "accidents" so that the quadriplegic community is maintained. Sounds absolutely insane when you start to discuss maintaining the population of disabled communities, doesn't it?
Back to the topic, cleansing of the deaf in this context implies a hatred for deaf people in general and wanting to remove all deaf people, which is an emotion entirely unrelated to sympethesizing with the disability of being deaf and wanting to avoid causing more such disability.
Many people see the deaf community as something that should ideally disappear by curing them.
I wonder if 100 years ago, the same activists would fight for survival of the leprosy community and its specific culture.
I can understand glorifying pathology if nothing can be done about it. It is a form of coping, similar to the coping that we usually engage in with regard to death. But once the underlying condition starts being curable and the glorifiers attempt to block treatment of children in the name of maintaining the pathology for future generations, they IMHO cross the line to outright evil.
Deafness is a huge handicap, in many ways significantly worse than blindness. That the victims of this horrible ailment start to self identify with it isn't a reason to subject new humans to it.
I have previously had to install simple things like doorbells for deaf people, which is done through a very strobe light that can be seen from almost the entire apartment... if you're not behind a closed door at least.
The idea of it being genuinely difficult for a person to be warned or notified is terrifying. Put your phone in your bag and you might as well have left it at home. Honking, people yelling or screaming for you to move out of harms way, even air sirens... You'll have no idea.
Then maybe install the strobe lights in all important rooms? Most people have there phone on silent/vibration anyway and recently everybody uses noise-canceling headphones outside to not be bothered by other people...
All the infrastructure that would support deaf people (like additional signal lights, vibration signals, subtitles...) are also very helpful for everybody else in specific situations.
> Then maybe install the strobe lights in all important rooms
What are important rooms?
> Most people have there phone on silent/vibration anyway and recently everybody uses noise-canceling headphones outside to not be bothered by other people...
> Everybody is handicapped part of the time
A phone on silent still blasts public safety warnings at full volume. A phone on vibrate can still be heard. Noise-cancelling headphones still let the outside through at a lower volume.
I know nothing about the detailed technical differences between X11 and Wayland but with Hyprland for me the PIP is working as expected so I assume its not just a Wayland issue but specific to the window manager you are using? Maybe somebody else can explain?
As far as I know, there are multiple Wayland implementations. Which is also not good because it creates fragmentation and potential inconsistencies (some subtle differences in behavior, differences in bugs, etc). Maybe Hyprland solves the issue, but I don't want to use this DE just because it solves this particular issue. I have tons of other needs and preferences.
Isn't that usually how it goes? Wayland is a million little optional protocols, which in the abstract is a lovely idea but in practice means which things work depends on which grab-bag of features your compositor supports.
It's a bit like the web. You have a pretty slow moving list of "protocols" that are well-supported by everyone, and some "new experimental" ones that are only supported by one or two.
Gnome has a "Always on Top" toggle for each window. I imagine there's a protocol for an application to set it by default but the OP's window manager might not implement it or there might be an incompatibility.
I can't speak for Gnome, but KDE makes it pretty easy to create rules that apply automatically to any new window that meets whatever arbitrary criteria you set.
That's terrible. That's an "unbreak my software" preference. User's shouldn't have to mess with that; things should just work in ways they expect, out of the box.
I disagree. With how KDE handles this, I'm not at the mercy of the software vendor's whims on what windows stay on top and which ones don't. I have complete control through a standardized interface that can even be automated if I wish.
Does it require a little more knowledge on the part of the user? Yes, but it's worth it because with that knowledge comes power.
Semi-honest question:
What do you need a window manager, code editor, chat app, etc for if claude is so awesome that it can do everything for you?
Why spend 400$ on making tools that you wont use in any workflow because the only workflow that will be left is prompting and agent to run in a loop
Recursion schemes are a topic too few people know about in my opinion. I wrote two simple and interactive introductions. One in Javascript [1] and one in Elixir as Livebook [2]. The Elixir version contains a few more practical examples.
1. the functional/immutable nature of Elixir makes read and writes much more explicit and there is no need to magically track deep mutations of nested objects to translate them back into UPDATE/INSERT queries
2. Elixirs support for lisp-like macros allows for an ergonomic embedded query languages that is syntax and schema checked, mirrors raw SQL really well and, frees you from string-oriented query building
3. the query builder DSL addresses one of the main weaknesses of SQL query statements not being composable
4. The automatic conversion between JOINed tables (on the DB side) and nested structs (on the Elixir side) is done on the right abstraction level to work reliable and and being explicit enough to generate predictable queries.