7,259 karma · joined February 19, 2019
So, I don't think it's entirely valid to talk about pixels as if they are pure, one dimensional units..
They're _things_ and you can talk about how many things wide or tall something is, and you can talk about how many things something has. Very much the same way you can with bricks (which are mostly never square) (though tiles are, you never talk about how many kilotiles is in your bathroom either, yet you can easily talk about how many tiles wide or tall a wall is).
So, no, pixels is not a unit in the mathematical sense.. it's an item, in the physical sense.
There are also things like scanners, that may have only one row of pixels on the scanner sensor, it does not have an area of zero, and you don't need to specify that there's one pixel on the other axis, because it's an inherent property of pixels that they have both width and height and thus area in and of themselves.
This reminds me of an excellent article I read a while back, the gist of it was that, given sufficient success, there's no such thing as a private API.
The hammer stands out.. because there's a relationship between the tree, saw and axe, in that you can cut down and shape the tree with either an axe or saw, while you can't do much with the hammer (since there are no nails), a kid who would answer that way should probably be considered at least as smart as his peers.
I've generally always hated these "multiple perfectly valid answers, but only one counts, but we won't tell you which of the multiple valid perspectives we want you to take" type of questions.
But honestly, it didn't feel so different from any other after-effect of intensive out-of-the-ordinary stimuli.. Think about the evening after a day of snowboarding, as you drift asleep, your brain starts to work its way down imaginary slopes, everything becomes transformed through the lens of snowboarding, rooftops becomes candidates for drops, piles of snow becomes ramps..
or when you've intensely learnt a new concept, your brain tries around it, to see if it somehow fits into what you've learnt.. Like how people learning about neural networks, can't help but go through at least a phase, where the idea of brains being computers are very appealing.
I don't think this "Game Transfer Phenomenon" is that novel or interesting, and most importantly, not related to games in particular.
It's just what the brain does when it engages in something.. it attempts to map and transfer concepts and relations, it's how we learn and grow..
https://llvm.org/docs/tutorial/MyFirstLanguageFrontend/index...
It's not a new practice, and it's not exclusive to Microsoft either, it's something every developer should be acutely aware of, in case they're interested in avoiding it.
I'm watching them now with our son, and I guess I was just born with a strong appreciation for melancholia.
I changed my mind, when I was a kid I thought they were good, now I think they are great!
In many ways, what makes moomin dark is that it shows us what we already know, the world _just_is_ and in the big picture, does not care about you, you might die, someone you care about might go away, and everyone is, fundamentally, alone, and what makes a person who they are, is partly how they deal with, if at all, being alone in this world of loners.
Moomin is very real and very direct in its dealings with the pain of the meaninglessness of life.
Snufkin, as a child, I took him for a cynic and disliked him, but he taught me something about the world, I think he is a stoic and a nihilist, and I very much like him now, he simply _IS_ in the world, and he accepts, and so appreciates that which also simply is, and which he cannot control.
Yeah, Moomin is dark, but life is dark, life is pleasure and pain, and we will all die, everyone we ever loved will suffer and die, but they will also experience pleasure and life, one could chose only suffering and death, one cannot chose only pleasure and life, and must come to terms with the fact that the underpinnings of pleasure and life is indeed suffering and pain. That's it, the world just is, and we're just in it.
I feel like a lot of the cartoons and tv shows of my childhood was like this, life.. it kinda has bad parts.. and back then, they showed them to kids, and what do I know.. maybe it prepared us to take it on ?
It means "this gonna get dead" and the argument will be "oh, nobody uses it" yeah, because, you can only want a nice thing back if you knew it existed to begin with, eventually, most users either never knew it was there, or assumed it went away, and eventually, forget it entirely, and then it's gone.
I'm scared, they already started messing with the toolbox stuff (putting multiple icons under the same button and then changing the icons too to make it entirely impossible to find anything).. "modern desktop" has taken on a different meaning for me, it's all about making it look neat at first glance, then entirely undiscoverable, removing any affordance in sight, burger menus, ribbon menus.. f...
In my version, the entrypoint is not uploading your file (where would it go??) but establishing the connection between two devices, then bidirectional transfers between them.
To quote a wise guy "I prefer my Nazis in uniform" (so I can properly identify and punch them in the face without them having any "oh but you misunderstood my good intentions sir"-kind of excuse).
But honestly, I don't get what the big deal is with either preference, it's not a big deal really.. black or white.. it's fine!
I wrote a small script that renders the file in HTML and CSS, does code highlight and so on, but the goal is that blog-posts should look just fine in raw text, so that it is also usable on Gopher.
Here's how it look when it's rendered: https://dusted.dk/pages/phlog/2024-05-23.txt
And you can ask for the raw version: https://dusted.dk/pages/phlog/2024-05-23.txt?raw
I primarily use this method as a step preceding the actual production-quality implementation. It’s not like a prototype—I don’t throw everything away when I’m done. Instead, I extract the valuable parts: the learned concepts, the finished algorithms, and the relevant functions or classes. Unit tests are often written as part of setting up the problem, so I lift those out as well.
I’ve greatly enjoyed this approach, particularly in JavaScript&|TypeScript. Typically, I solve the difficult parts in a live environment and extract the solutions when I find them. I used to use my own "live environment" (hedon.js), but I eventually reversed the approach and built an environment around the built-in Node.js REPL (@dusted/debugrepl). I include this, at least during debugging and development builds, allowing me to live-code within a running system while having access to most, if not all, of the already-implemented parts of the program.
This approach lets me iterate at the function-call or expression level rather than following the traditional cycle of modifying code, restarting the program, reestablishing state, and triggering the desired call, something that annoys me to no end for all the obvious reasons.