demosthanos

Can you please cite the page number where this definition exists? When I search for "extreme" in the standard that the other commenter links to I don't turn anything up, so I'm unclear where that classification is defined.

You can't just point people at a 60-page paywalled standard and say "the supporting evidence to my claim is somewhere in here, I pinky promise". You are the one making assertions, it's on you to prove that the standard actually does reflect the text of TFA. I'm not going to read the whole standard because I'm not the one making the argument and I can't be bothered doing the research needed to refute every piece of nonsense science that shows up on the internet. What I can do is point out when someone is making unsourced claims and insist that they provide their sources if they want to be taken seriously.

Cite the exact page number and quote that you claim justifies the assertion that 246 Hz PWM carries an "extremely high" health risk. Then we can talk.

I am not questioning that certain types of flickering are harmful, so that there's an IEEE standard for how to safely use PWM does not contradict what I said.

What I'm asking for is for articles like this that cite numbers and provide tables purporting to quantify the degree of harm caused by various devices to point to where they're getting their numbers from or, if they can't do that, stop making up numbers and assigning things to "harm" scales that they invented themselves based on vibes.

Either there's a study showing that 246 Hz flickering poses "Extremely High" health risks or there isn't.

If the article said "I find PWM annoying" I wouldn't have commented like I did.

I know that people anecdotally report complaints about flicker and it's plausible to me that there could be an effect, but the way this piece is written reminds me distinctly of similar essays about WiFi sickness, MSG, and GMOs.

It identifies a "health risk", describes the mechanism in terms that sound very convincing, assigns numbers to its cause and effects, provides a table grading health risks of various products, all without linking to a single scientific study demonstrating that the effect is anything other than nocebo. The closest they come is a image of a table that refers to a few institutions that apparently did a study related to PWM (leaving it an exercise to the reader to find the studies they're supposedly referencing) and a link to a Wikipedia page which links to a Scientific American article which says:

> In 1989, my colleagues and I compared fluorescent lighting that flickered 100 times a second with lights that appeared the same but didn’t flicker. We found that office workers were half as likely on average to experience headaches under the non-flickering lights. No similar study has yet been performed for LED lights. But because LED flickering is even more pronounced, with the light dimming by 100% rather than the roughly 35% of fluorescent lamps, there’s a chance that LEDs could be even more likely to cause headaches.

I'm willing to entertain the idea that LED flicker is actually problematic, but I wish essays like this would be honest about the degree of confidence we have given the current state of the evidence. This piece instead takes it as a given that there's a problem, to the point where they confidently label devices on a scale of Low to Extremely High health risks.

> We don't know yet how a modern transformer trained on radiology would perform, but it almost certainly would be dramatically better.

Why? Is there something about radiology that makes the transformer architecture appropriate?

My understanding has been that transformers are great for sequences of tokens, but from what little I know of radiology sequence-of-tokens seems unlikely to be a useful representation of the data.

It's from The Practice of Programming, published 1999. Not a lot has changed in debuggers since then from what I can see.

True, but then you're still left stepping through your breakpoints one by one.

Printf debugging gives you the full picture of an entire execution at a glance, allowing you to see time as it happened. The debugger restricts you to step through time and hold the evolution of state in your memory in exchange for giving you free access to explore the state at each point.

Occasionally that arbitrary access is useful, but more often than not it's the evolution of state that you're interested in, and printf gives you that for free.

Your framing makes it sound like the log is worse in some way, but what the log gives you that the debugger makes you assemble in your head is a timeline of when things happen. Being able to see time is a pretty big benefit for most types of software.

I can always drop an entire state object into the log if I need it, but the only way for a debugger to approximate what a log can give me is for me to step through a bunch of break points and hold the time stream in my head.

The one place where a debugger is straight up better is if I know exactly which unit of code is failing and that unit has complicated logic that is worth stepping through line by line. That's what they were designed for, and they're very useful for that, but it's also not the most common kind of troubleshooting I run into.

There was a good discussion on this topic years ago [0]. The top comment shares this quote from Brian Kernighan and Rob Pike, neither of whom I'd call a young grug:

> As personal choice, we tend not to use debuggers beyond getting a stack trace or the value of a variable or two. One reason is that it is easy to get lost in details of complicated data structures and control flow; we find stepping through a program less productive than thinking harder and adding output statements and self-checking code at critical places. Clicking over statements takes longer than scanning the output of judiciously-placed displays. It takes less time to decide where to put print statements than to single-step to the critical section of code, even assuming we know where that is. More important, debugging statements stay with the program; debugging sessions are transient.

I tend to agree with them on this. For almost all of the work that I do, this hypothesis-logs-exec loop gets me to the answer substantially faster. I'm not "trying to run the code forwards in my head". I already have a working model for the way that the code runs, I know what output I expect to see if the program is behaving according to that model, and I can usually quickly intuit what is actually happening based on the incorrect output from the prints.

[0] The unreasonable effectiveness of print debugging (349 points, 354 comments) April 2021 https://news.ycombinator.com/item?id=26925570

Remember that LLMs aren't trained on all existing programming languages, they're trained on all text on the internet. They encode information about knitting or streaming or whatever other topic you want a DSL for.

So it's not just a question of the semantics matching existing programming languages, the question is if your semantics are intelligible given the vast array of semantic constructs that are encoded in any part of the model's weights.

> To these people, if it's not exposed as a API call it's just some opaque blob of code that cannot be understood or reused.

I think this is correct as an explanation for the phenomenon, but it's not just a false perception on their part: for a lot of organizations it is actually true that the only way to preserve boundaries between systems over the course of years is to stick the network in between. Without a network layer enforcing module boundaries code does, in fact, tend to morph into a big ball of mud.

I blame a few things for this:

1. Developers almost universally lack discipline.

2. Most programming languages are not designed to sufficiently account for #1.

It's not a coincidence that microservices became popular shortly after Node.js and Python became the dominant web backend languages. A strong static type system is generally necessary (but not sufficient) to create clear boundaries between modules, and both Python and JavaScript have historically been even worse than usual for dynamic languages when it comes to having a strong modularity story.

And while Python and JS have it worse than most, even most of our popular static languages are pretty lousy at giving developers the tools needed to clearly delineate module boundaries. Rust has a pretty decent starting point but it too could stand to be improved.

> These comparisons to existing uses of water besides cooling "AI data centers" ignore the fact that water use for "AI data centers" is additive. It is a _new_ use of water not seen before. As such, the comparisons to existing uses are unconvincing.

No, I'm not ignoring that. I'm saying two things:

1) When put next to existing water usage, data center water usage stops looking as crazy large as is implied in TFA. All data centers for all compute purposes in the EU used as much water in 2024 as the creation of a single food product used in 2019. That's important perspective to have when we're talking about additive water usage, because it hints out what percentage increase we're talking about [0].

2) I don't accept the presumption that existing usage has preeminence now and forever by simple virtue of being older. We should be able to look at all water usage that currently stands and decide which usages are worth keeping and which are worth adding.

You're welcome to disagree that data centers (AI and otherwise, because non-AI workloads are included in the numbers) are worth more than chocolate, but it should be as part of a fair comparison between them on the merits, with no grandfathering chocolate and agriculture in just because the chocolate companies and farmers got there before anyone was paying attention to monitoring water usage.

[0] If you can find a percentage increase from data centers figure that would be even better, but I can't find absolute numbers for total water usage in the EU to construct such a figure.

Sure, but then it's silly to throw a fit about data centers which pretty clearly provide a greater benefit to Europe's interests than chocolate does. It's just another example of how the rhetoric gives the established water abusers a free pass while scrutinizing every cubic meter used for tech.

> This shows pretty much what I'd expect: coverage is fine in and around cities and less great in rural areas. (The Dakotas are an interesting exception; there's a co-op up there that connected a ton of folks with gigabit fiber. Pretty cool!)

Just a warning about the screenshot he's referencing here: the slice of map that he shows is of the western half of the US, which includes a lot of BLM land and other federal property where literally no one lives [0], which makes the map look a lot sparser in rural areas than it is in practice for humans on the ground. If you look instead at the Midwest on this map you'll see pretty decent coverage even in most rural areas.

The weakest coverage for actually-inhabited rural areas seems to be the South and Appalachia.

[0] https://upload.wikimedia.org/wikipedia/commons/0/0f/US_feder...

> As the sector grows, consumption is expected to reach 90 million cubic meters by 2030, according to the water sector lobby Water Europe.

People who are trying to organize opposition to particular uses for water have a habit of citing the raw numbers without putting them in context, which works because there's so much water that the numbers are eye-wateringly large.

It's hard to find concrete stats on total water usage (as opposed to percentage changes), but one report I found that helps to put this number in context is this [0]:

> In addition, it takes 17,000 litres of water to produce a kilo of chocolate. According to statistics from 2019, Europe produced 3.7 million tonnes of chocolate, which equates to an eyewatering 63,625,200,000 litres of water.

Since a liter is 1/1000 of a cubic meter, we're looking at 63 million cubic meters for European chocolate alone, which places chocolate in the same ballpark as Europe's data centers.

Obviously data centers can and should work to conserve water (no misting in dry regions would help), but on the surface ~40% more water for data centers than for chocolate doesn't seem like that bad of a balance.

[0] https://www.euronews.com/green/2024/07/09/our-water-footprin...

If that's the distinction you're drawing then it's totally meaningless in the context of the question of where the information is going to come from if not Stack Overflow. We're never in a situation where we're using an open source library that has zero information about it: The code is by definition available to be put in the context window.

As they say, it sounds like you're technically correct, which is the best kind of correct. You're correct within the extremely artificial parameters that you created for yourself, but not in any real world context that matters when it comes to real people using these tools.

This is wrong. I write toy languages and frameworks for fun. These are APIs that simply don't exist outside of my code base, and LLMs are consistently able to:

* Read the signatures of the functions.

* Use the code correctly.

* Answer questions about the behavior of the underlying API by consulting the code.

Of course they're just guessing if they go beyond what's in their context window, but don't underestimate context window!

I spend way more time on YouTube than I ought, but it's on a pull basis, not a push basis. I go to YouTube and go to my subscriptions or to recommendations on the Home screen.

I can't imagine wanting YouTube to be able to push content onto my phone at arbitrary times of its choosing. What benefit does that give you over the subscription feed and home screen?

No, it's a thin wrapper around an API, probably OpenRouter or similar:

https://github.com/ccbikai/ssh-ai-chat/blob/master/src/ai/in...

I mean, it's a thin wrapper around LLM APIs, so it's not surprising that most of the code is rendering. I'm not sure what you're referring to by "handling issues with rendering", though—it looks like a pretty bog standard React app. Am I missing something?

Skimming the source code I got really confused to see TSX files. I'd never seen Ink (React for CLIs) before, and I like it!

Previously discussions of Ink:

July 2017 (129 points, 42 comments): https://news.ycombinator.com/item?id=14831961

May 2023 (588 points, 178 comments): https://news.ycombinator.com/item?id=35863837

Nov 2024 (164 points, 106 comments): https://news.ycombinator.com/item?id=42016639

To name just a few costs that aren't worth it for many businesses:

* A much smaller ecosystem of libraries to draw from.

* Much weaker editor tooling than with more established languages.

* An entirely different paradigm for deployments, monitoring, and everything else that falls under "operations" that may be incompatible with the existing infrastructure in the organization.

* When something does go wrong, using a weird stack means you have less institutional knowledge to lean on and fewer resources from people who've been doing the same thing as you.

* A whole new set of foot guns to dodge and UX problems to solve related to what happens when someone's connection is poor. This has come up repeatedly in discussions of Phoenix LiveView—what you get in reactivity comes at the expense of having to work harder to engineer for spotty connections than you would with a request/response model.

* More difficulty hiring people, and an increased tendency when hiring for selecting people who are really just obsessed with a particular tool and unwilling to see when the situation calls for something else.

There are many more, these are just the ones I can think of without having a concrete application with concrete requirements to analyze. In the end for most apps reactivity is so much a "nice to have" that it's hardly worth sacrificing the stability and predictability of the established option for moderately better support for that one aspect of UX, especially given that you can always add reactivity later if you need to at a slightly higher cost than it would have come at with Erlang.

If reactivity is a core requirement, that's a different story. If it's polish, don't choose your architecture around it.

And if you need that kind of persistent immediately reactive connection and are willing to pay the price, go for it! If that's truly a requirement for you then you're in the subset of web that overlaps substantially with telecoms.

I'm not cautioning against making the calculated decision that realtime is a core requirement and choosing the BEAM accordingly. I'm cautioning against positioning the BEAM as being designed for web use cases in general, which it's not.

Many projects, including GitHub, do not need that kind of immediate reactivity and would not have benefited enough from the BEAM to be worth the trade-offs involved. A single example of a UX flow that could be made slightly better by rearchitecting for realtime isn't sufficient reason to justify an entirely different architecture. Engineering is about trade-offs, and too often in our field we fall for "when all you have is a hammer". Realtime architectures are one tool in a toolbox, and they aren't even the most frequently needed tool.

In the grand scheme of things, if we're considering everything from web to bridge building, yeah, the distinction is small. But within the world of software engineering specifically it's not all that small and it's worth being precise when we're talking about it.

Whatsapp and telecoms have a lot in common, so no one questions that they benefited a ton from the BEAM.

Airbnb, though? The main similarity is that they both send large quantities of signal over wires.

Again, none of this is to stop you from liking the BEAM, but when we're talking about professional software engineering it pays to be explicit about what the design constraints were for the products that you're using so that you can make sure that your own design constraints are not in conflict with theirs.

> is actually designed from the ground up for web dev (being based on the Erlang VM)

Nit: this makes it sounds like the BEAM was designed for web dev, which it was not. Erlang came out of Ericsson and was built for telecoms (OTP stands for Open Telecom Platform), which is where its unique set of trade-offs comes from. Many of those trade-offs make a ton of sense for web but that's not because it was designed for web, it's because there's overlap between the fields.

One way to see the difference between telecoms and web is to ask yourself when was the last time that you were working on a project with an availability SLA of 9 nines (1/3 of a second of downtime per year) or even 6 nines (32s per year). Some web dev has that, but most doesn't come close, and if that's not you then Erlang wasn't built for you (though you may still find you like it for other reasons!).

They DO take the same care if not more care, the problem is that just like with copyrighted content stuff slips through because stochastic text generation is impossible to control 100%.

I've had the most innocuous queries trigger it to switch into crisis-counseling mode and give me numbers for help lines. Indeed, in the original NYT article it mentions that this man's final interactions with ChatGPT did trigger ChatGPT to offer the same mental health resources:

> “You are not alone,” ChatGPT responded empathetically, and offered crisis counseling resources.

> who had previously been diagnosed with bipolar disorder and schizophrenia

The man had schizophrenia and ChatGPT happened to provide an outlet for it which led to this incident, but people with schizophrenia have been recorded having episodes like this for hundreds of years and most likely for as long as humans have been around.

This incident is getting attention because AI is trendy and gets clicks, not because there's any evidence AI played a significant causal role worth talking about.

The same reasoning that would call this consideration of the possibility of machine consciousness "dehumanizing" would necessarily also apply to the consciousness of animals, and I can't agree with that. To argue this is to define "human" in terms of exclusive ownership of conscious experience, which is a very fragile definition of humanity.

That definition of humanity cannot countenance the possibility of a conscious alien species. That definition cannot countenance the possibility that elephants or octopuses or parrots or dogs are conscious. A definition of what it means to be human that denies these things a priori simply will not stand the test of time.

That's not to say that these things are conscious, and importantly Anthropic doesn't claim that they are! But just as ethical animal research must consider the possibility that animals are conscious, I don't see why ethical AI research shouldn't do the same for AI. The answer could well be "no", and most likely is at this stage, but someone should at least be asking the question!

Why not both? Why do people on the internet always act like we can only have one active morality front at a time?

If you're working on or using AI, then consider the ethics of AI. If you're working on or using global supply chains, then consider the ethics of global supply chains. To be an ethical person means that wherever you are and whatever you are doing you consider the relevant ethics.

It's not easy, but it's definitely simple.