MurphyA/hacker-news huggingface dataset:
by 90s_dev | 2025-07-27 02:15:44+00:00
Shorter description:

It's like love2d but with a pico8 style screen and the code is entirely asm.

Download at https://hram.dev/hram-110.zip for version with hot code reloading.

Write event handler function in native assembly at appdata\hram\hsig.s that interacts with keyboard/mouse and 128x72 8-bit screen (red/green only).

Uses native jit, no interpreter. So if you write bad assembly it will segfault! But it's okay, just restart hram.exe (~360 kb) and try again.
by FpUser | 2025-07-27 02:17:11+00:00
>"Still, it's a great first language. You can make small tools within a month. C isn't nearly as forgiving."

If C and Python are the only options I would strongly vote for C being the first. It will weed out those who are unfit.

Myself I use many languages including Python but I started programming by entering machine codes in hex. Obviously I do not do it now but I think it did benefit me in general.
by anonym29 | 2025-07-27 02:17:27+00:00
“if Baltimore moved from street corners to online services, oh my god, do you know how much fewer shootings we'd have every year? Which equates to fewer homicides.”

- Neill Franklin, 34-year law enforcement veteran of the Maryland State Police and Baltimore Police Department

https://www.theodysseyonline.com/the-war-on-drugs-this-revol...

p.s. sorry for taking so long to find the reference I was thinking of
by ryandamm | 2025-07-27 02:17:53+00:00
This is actually even more puzzling than it seems, because the green part of the spectrum is the most energetic.

I've read elsewhere that photosynthesis is partially limited by dealing with free radicals, and at peak light flux, many plants would be damaged by the monoatomic oxygen species that light-capturing complexes would create. Hence pigments that reflect some green light.

Article:

https://www.quantamagazine.org/why-are-plants-green-to-reduc...
by 90s_dev | 2025-07-27 02:18:56+00:00
Got one report on reddit that it's not creating the default file in appdata and just using the one in memory that it thinks it's writing. If you have the same issue, here's the whole sample asm file that you can write to appdata\hram\hsig.s before you open hram.exe:

; switch on arg cmp cl, 4 je MouseDown cmp cl, 5 je MouseUp ; if mouse not down then just skip mov al, byte [0x33000] test al, 1 jz Skip ; draw green at mouse mov rax, 0 mov rbx, 0 mov al, [0x30007] mov bl, 128 mul bl add al, [0x30006] mov byte ptr [rax+0x30100], 0x0f ; call blit() sub rsp, 24 call [0x30030] add rsp, 24 Skip: ret ; store mouse-down info MouseDown: mov byte ptr [0x33000], 1 ret MouseUp: mov byte ptr [0x33000], 0 ret

Fwiw I do not know assembly! This is the most complicated asm I've ever written! So if it's got dumb errors, please let me know and I'd be glad to fix them in the sample code!
by a_t48 | 2025-07-27 02:21:24+00:00
uv is still pretty young, a year and a half since initial public release? It's gotten a lot of traction but yes, it hasn't eaten the "market" for python package management, quite yet. I'd bet that there are users and developers of those ML projects that use uv to manage their environment, but aren't checking in a lockfile (depending on what kind of project it is, it might not make sense to check in the lockfile, I guess).

A project should blow up if you attempt to use system python. It should not work.

Disagree here - an environment is an environment. Yes, the system python environment is kind of shit, but it does provide one - if a package cares about where exactly it gets dependencies, other than "here's a directory with packages", it's doing something wrong. I'm not sure how you'd enforce that, as nice as it sounds from the point of view of getting system python to go away.

`python main.py` should handle all of this for you.

Have you seen https://docs.astral.sh/uv/guides/scripts/ ?

Just to be clear - I agree with you. My impression of the python packaging ecosystem has been that it's kind of shit, various tries have been made at fixing it with various tools, all of them have had issues with one workflow or another. But things are now trending in a much more positive direction.
by zahlman | 2025-07-27 02:21:33+00:00
"make depending on system python an antipattern" is a social problem, not a technical one. uv's virtualenvs are not special (aside from not bootstrapping pip; bootstrapping it is already optional, although it's the default); the standard library `venv` writes `pyvenv.cfg` files that tell Python whether or not to use the system `site-packages`.

Pip has attempted to resolve and install transitive dependencies since even before 2020. That's just when they introduced a new, backtracking resolver (which can be slow because it is thorough and simple-minded about its backtracking).

"hermetic builds" sounds to me like it's referring to packages that don't depend on system binaries being present, by the magic trick of separately providing them (even if redundant). That's... just a wheel.

But also: currently, Python 4 is out of the question, and even if it were in play, "we should take this opportunity to integrate package management into the language" would be completely out of the question. That's just not how Python's politics work internally. There is generally pretty broad agreement anyway that the reasons packaging problems are hard to solve in Python (in the places where they actually are) are: 1) people don't agree on the design for a solution; 2) all that code in other programming languages that people want to interface with from Python (which, to be clear, is not something they're trying to get rid of); 3) backwards compatibility concerns. Making a clean break is not going to help with the first two and is directly opposed to the third.
by fc417fc802 | 2025-07-27 02:22:09+00:00
> you just have a different constant factor which is irrelevant for scalability.

So then why bother with cities at all? High rises are just a different constant factor relative to 40 acre farms after all.

I feel like this is analogous to a case where someone says that an algorithm only differs by a constant factor but it turns out that because of that difference it hits the cache for 99% of use cases and as a result you see better than 100x speedups for all real world workloads.

Cities with cars obviously work up to some size. The sheer number of personal vehicle trips that a single rail line can replace is huge. And just to give you an idea of how large the scale factor here is, consider that you can pack at least 3 rail lines into the width of a typical two lane road, and that large cities commonly have 4 lane arterials.

If the political will existed to reallocate the space it could be done and the viable density would scale accordingly. On the extreme end we have Tokyo as a practical example, and even they are far from saturating all the available space for building rail lines.

> moving goods instead of people scales logarithmically

This is obviously false. There's some average parcel size, and an associated maximum capacity for a delivery van. Thus any given delivery run has a limit on the number of shipments it can service. Obviously that scale factor is significantly larger than the one for passenger rail versus cars, but it's still "just" a constant factor and thus irrelevant for scalability by your own logic.

In fact by your own logic I'm fairly certain that you will find that life as a whole is unscalable. Better nuke the planet I guess.
by II2II | 2025-07-27 02:22:16+00:00
These books shouldn't be dismissed since they provide people with a foundation for further learning. They also offer a friendly introduction to programming, rather than imposing an intimidating wall that will keep people away. It is also important to note that these books break the learning into 24 one hour modules, or something similar, so they can have reasonable coverage of a programming language.

If these books have a failing, it has little to do with the concept and everything to do with being poorly written.
by kragen | 2025-07-27 02:22:41+00:00
Further down on the page, it says:

> The mine sets a chemical-grade specifications benchmark of 6.0% Li2O minimum and 0.8% Fe2O3 maximum.

Spodumene is 0% iron. How much lithium does it contain on a Li2O basis? 8%, I think:

You have: lithium + aluminum + 2(silicon + 3 oxygen) You want: Definition: 186.089 You have: (2 lithium + oxygen) / 2 _ You want: % * 8.0282762 / 0.12455974

That suggests that the rock (pegmatite?) being mined there is about 75% spodumene. Is it possible that this is a misinterpretation, perhaps describing a standard for the output of the froth flotation process or similar, and the rock being dug up really is just a few percent spodumene?

No, as it turns out. The paper linked just before that says that none of the rock is quite that lithium-rich https://pubs.geoscienceworld.org/segweb/economicgeology/arti...:

> The lithium ore zones comprise mainly spodumene, apatite, and quartz, with some ore zones returning upward of 5 percent Li2O.

OTOH, that paper is from 01995, so maybe there are new findings since 30 years ago. It says the reserves there were 4% Li2O. Later in the paper, it explains:

> The hanging-wall lithium zone in the main pegmatite is generally richer (up to 5% Li2O, equivalent to 60–80% spodumene) than the footwall lithium zone

That seems to contradict adrian_b's strong statement:

> Spodumene is dispersed among other minerals into rocks and it only forms a few percent at most of those rocks, if not only fractions of a percent.

It could still be true at other mines.
by zzless | 2025-07-27 02:22:42+00:00
On the other hand here is a Long-EZ that gets 40 mpg flying at over 250 mph (so not quite 250 knots but still). The actual savings will be higher since one can fly in a straight line most of the time. It also avoids congestion and ... is simply more fun than driving. Also an auto-pilot in aircraft has been a real thing for quite some time while same in a car ... is still quite pathetic. I have eaten plenty of lunches comfortably while flying a plane while I would not be comfortable doing it while driving.

Long EZ reference: https://generalaviationnews.com/2016/05/25/going-fast-on-les...
by owenversteeg | 2025-07-27 02:22:44+00:00
Blood diamonds are terrible, but the overwhelming majority of diamonds produced these days are not blood diamonds relying on slave labor, they're mass-mined products relying on colossal-scale industrial machinery. That's why Russia is #1 and Canada is #3 in worldwide diamond production today: even the world's largest diamond mines have 1-3k employees vs. massive production.

That's not to paper over the issues with the industry (environmental, poor working conditions, poor pay etc) - but those are more generally applied to any mined product. I'd be willing to bet that your average set of modern electronics cause far more suffering than your average diamond: see conflict resources such as tantalum, tin, tungsten, gold.
by rvrb | 2025-07-27 02:24:34+00:00
oh, man! you made my day with this comment. those days are long behind me. we were young, dumb, and inebriated. if you're looking for the bands we were trying to sound like, there was a resurgence of this surf/girl group sound in the early 2010s. look for bands like Shannon and the Clams, Hunx and His Punx, Nobunny, Harlem, Ty Segall, Thee Oh Sees.. basically anyone on the now defunct Burger Records
by jjmarr | 2025-07-27 02:25:34+00:00
Not a geologist but Mohs hardness is an ordinal scale so the distance between 10 and 9 isn't well-defined. The numbers are defined as being specific minerals.

Diamond (10) is 4x as hard as corundum (9) which is 2x as hard as topaz (8).

https://en.wikipedia.org/wiki/Mohs_scale#Reference_minerals
by travisgriggs | 2025-07-27 02:25:53+00:00
> Note that not having runtime-known stack allocations is a key piece of the puzzle in Zig's upcoming async I/O strategy because it allows the compiler to calculate upper bound stack usage for a given function call.

Sigh. So I have to choose between something I think might be useful, for something that too many languages have already soiled themselves with. Hopes that Zig has a better solution, but not optimistic.

Our stack compels me to work in Swift, Kotlin, Elixir, and Python. I use the async feature of Swift and Kotlin when some library forces me to. I actually preferred working with GCD before Swift had to join the async crowd. Elixir of course just has this problem solved already.

I frequently ask others who work in these languages how often they themselves reach for the async abilities of their languages, and the best I ever get from the more adventurous type is “I did a play thing to experiment with what I could do with it”.
by smeej | 2025-07-27 02:25:58+00:00
They're missing the key feature I'm looking for: Decentralized backup to the same devices owned by people I choose. That's the "someone else's computer" part of what I want in a "cloud."

I can already easily run such things on my home computer. It's having remote (encrypted) backups and redundancy if my own system goes down that I'm looking for.
by trailbits | 2025-07-27 02:26:40+00:00
A website in the US doesn't deliver anything to the UK, it hands off some packets to a router in the US. Why is the website responsible for what all the interconnecting routers do? If a person from the UK were to visit an adult bookstore in the US, the bookstore owner isn't at fault if the customer decides to move certain material across national boundaries.
by parsimo2010 | 2025-07-27 02:26:56+00:00
I was picking random numbers to try and spell out that cruising speed isn’t a huge safety risk, but landing speed is. Notice that the slow speed (55 kts) I picked is legal under MOSAIC but the higher unsafe speed (80 kts) isn’t legal, and this illustrates that the FAA kept a fairly sane stall speed limit.

The fact that the stall speed limitation closely matches the existing limits for light singles shows where the FAA draws the safety lines. Although MOSAIC apparently allows twins, they keep the stall speed limitation at a sane number.

The only thing I don’t fully understand is them differentiating between 59 kts for a sport pilot, and 61 kts for a light sport aircraft. It feels a little arbitrary to draw those lines differently.
by andrewpolidori | 2025-07-27 02:27:08+00:00
Let's leave the analogy in it's grave. The point is that the responsibility for delivery falls to the provider of the internet service not the proprietor of the content in another country, who is not a business in the country and not subject to it's laws, the isp can ban connectivity to whoever they want to protect themselves from criminal liability. It's like saying the uk can criminally punish anyone for any content on the internet in any country because their citizens accesed it. It's ridiculous.

Agree with the point that it's mostly to extort larger firms who do in fact operate businesses there.
by ausbah | 2025-07-27 02:27:38+00:00
with this and the recent Windsurf “acquisition”, what’s even the draw to startups anymore? 25% base pay increase for 80% more hours (not even considering overtime) with equity that is tantamount to useless (with or without Windsurf being the new norm)? super hard pass and I hope everyone with half a brain does the same

AI is being used as an excuse to strip away every labor norm and law in the name of “not being left behind”, with a product that has yet to truly be earth shattering on the scale it’s been predicted to be. hard not to see the current slate of VCs and founders as leechs
by dr_dshiv | 2025-07-27 02:27:49+00:00
Most of the green reflectance is an illusion because the human retina amplifies green light as much as 25× more than red (think of a green 5mw laser vs red).

On the other hand, leaves do absorb green light: nearly 75% is absorbed, in contrast to 85% of non-green light. See https://www.researchgate.net/figure/Reflectance-spectra-of-g...
by joemazerino | 2025-07-27 02:28:18+00:00
GrapheneOS "had" to reply to this article because they weren't happy with it's portrayal of events and LWN refused to edit a live article.

Par for the course with GrapheneOS. They always seem to take a good thing said about them and not be satisfied.

https://x.com/GrapheneOS/status/1948811620047536316
by hollerith | 2025-07-27 02:28:39+00:00
I see that as a positive, not a negative. Since the pellets can be sold, investors are more likely to invest in the development of the process. And the extra volume of production tends to increase the efficiency, i.e., to reduce the cost (paid by altruists and governments) of producing the pellets that do end up in the ground or in ocean trenches.
by SR2Z | 2025-07-27 02:29:16+00:00
A Toyota Camry hybrid does not move 110mph at 22mpg with a 700mi range. Once you start moving fast the fact that it's a hybrid is irrelevant since the engine must provide 100% of the power.

I personally don't see the point of comparing a car at 50mph with a small plane at 120mph, but if you really want to, I bet that easily doubles fuel efficiency. No one flies at Vg because that's stupid, but you COULD, and then you're basically the same fuel efficiency as a car but flying in a straight line.

Even that 22mpg is not a 1:1 comparison because of that inconvenient "as the crow flies" thing. We can build more efficient aircraft in theory, but in practice the regulation gets too expensive.
by GCA10 | 2025-07-27 02:29:33+00:00
That's actually the point. Yahoo in 2005 had the financial muscle -- and an interesting starting point via Flickr's user base -- to spin up its own version of YouTube without needing to do an acquisition. Stronger Yahoo leadership would have stomached the get-started costs of an internal build-out, because of a sense of what this could become.

Yahoo just lacked the imagination and nerve necessary to see how its own assets could lead to the next big thing.
by ciabattabread | 2025-07-27 02:30:47+00:00
> but the old servers still worked until the AOL outage 2 days ago.

So that explains why my dad's email suddenly couldn't send outgoing messages (the configuration, for years, was outgoing.yahoo.verizon.net with normal password). After what felt like an hour, what worked was changing it to smtp.mail.yahoo.com and using OAuth.
by pansa2 | 2025-07-27 02:30:47+00:00
> I like `gevent` but I think it may have been too hacky of a solution to be incorporated to the main runtime

gevent's monkey-patching might be hacky, but an official implementation of stackful coroutines (similar to Lua's) need not have been.

Instead, stackless coroutines were chosen - maybe on merit, but also maybe because C#'s async/await keywords were in-vogue at the time and Python copied them.
by throw0101d | 2025-07-27 02:31:39+00:00
> https://www.youtube.com/watch?v=twzmflIdYmw

I have a CD of Hillier's album (one of the first ways I was exposed to Pärt):

* https://www.youtube.com/playlist?list=OLAK5uy_lmpgHbTQHjWV6o...

See Summa (Credo) and perhaps Seven Magnificat Antiphons in it.
by zahlman | 2025-07-27 02:32:03+00:00
Setuptools comes to around 100kloc now (per a naive search and `wc` of the .py files in a new environment) and installs without a hitch for everyone. Pip, nearly double that. Yes, both of those are heavily using vendoring, but because of bootstrapping problems because they are the default build tool and package installer respectively. (And quite a bit of devendoring would be possible if some system maintainers didn't insist on "building from source" when there is only Python code. Yes, technically pre-compiling .py to .pyc can be considered "building", but pip would already do that during installation.) If they didn't have to worry about those issues (or the additional Pip issue of "how do you get the packages for Pip's dependencies if you don't already have Pip?"), they would install and run just fine from a series of wheels that are all pure Python code.

For that matter, one of those dependencies, `pyparsing`, is around 10k lines installed (and the repository is much larger with tests etc.). That's with it not having any dependencies of its own.

There is no real barrier anywhere around the 1k loc mark. The problems large projects run into have more subtle causes.
by gshulegaard | 2025-07-27 02:32:12+00:00
I feel like this started/greatly accelerated when Guido stepped down as BDFL. Python at is on a path where the essence of what made it popular (readable, well designed, productive) is being crushed under the weight of it’s popularity. The language now feels bloated and needlessly complex in areas that were previously limited, but simple.

I recently chased down a bug where something was accidentally made a class variable because a type hint was left off it by accident and it clicked for me that Python is not the same language I loved at the start of my career.
by parsimo2010 | 2025-07-27 02:32:46+00:00
No, leaded fuel will continue for several years as they haven’t found a drop-in replacement that will work in the entire existing fleet, and the financial burden of modifying engines is too high for them to mandate the change. Some existing planes are approved to run unleaded fuels but not all.

But MOSAIC probably will result in more aircraft being announced that are designed to run unleaded fuel because you won’t have to use a certified engine and can use something more modern.
by johncolanduoni | 2025-07-27 02:32:49+00:00
WebGPU has been supported in stable Chrome for over 2 years. I'm also really not sure what about it is much like Vulkan 1.0 (or any other version). No manual allocations, no manual state transitions, almost no manual synchronization. If I had to pick another graphics API to compare it to in terms of abstraction level and exposed primitives, Metal 1 is probably the closest.
by pizlonator | 2025-07-27 02:33:35+00:00
I would take the FP zealots more seriously if they stopped asserting that FP makes things more correct.

Zero evidence that this is the case.

I can tell you that debugging a compiler written in ML is a dumpster fire compared to debugging a compiler written in C++. If take C++ over any FP language for compilers any day of the week.
by zdragnar | 2025-07-27 02:34:34+00:00
I suspect the GP meant the working class are being tricked into thinking the "illegals, poors and ethnics" are the evils that are holding the working class back by Republicans.

Nevermind the fact that casual bigotry against working class people (blue collars and uneducated are too dumb to know what is good for them) is just as repugnant as what you thought they meant.
by zahlman | 2025-07-27 02:34:58+00:00
If you have access to f-strings then you have had to change quite a few things that are mutually incompatible between 2.x and 3.x. Perhaps you feel like your Python 3 code (which requires at least 3.6) is "basically still 2.7" because you aren't using things like type annotations (and actual tooling to check them), or the walrus operator, or the match statement. But all of these things are entirely optional, and plenty of people feel that they're actually un-Pythonic.
by rkagerer | 2025-07-27 02:36:30+00:00
over-the-air avionics updates

I was on board up until this phrase. I don't want my plane behaving as flakey as my Tesla, and my gauges shifting their location around every update at the whim of some junior designer.

Not saying there couldn't be a manufacturer that does OTA properly, I just haven't seen that as the trend in any other space (cars, smartphones, etc). The OTA part always seems to benefit the manufacturer, not the user. ("Watch this ad to take off....")
by do_not_redeem | 2025-07-27 02:36:55+00:00
I'd be curious if you expanded your reasoning, your comments in that thread never explained anything for me.

> It's too tempting to use incorrectly.

A compile-time-determined upper bound would solve this.

> The stack is allocated based on a compile-time-determined upper bound.

A compile-time-determined upper bound would solve this too.

Shouldn't a performance-oriented language give the programmer tools to improve memory locality? And what's wrong with spexguy's idea?