I think the worst case is actually that the LLM faithfully implements your spec, but your spec was flawed. To the extent that you outsource the mechanical details to a machine trained to do exactly what you tell it, you destroy or at least hamper the feedback loop between fuzzy human thoughts and cold hard facts.
Unfortunately even formal specifications have this problem. Nothing can replace thinking. But sycophancy, I agree, is a problem. These tools are designed to be pleasing, to generate plausible output; but they cannot think critically about the tasks they're given.
Nothing will save you from a bad specification. And there's no royal road to knowing how to write good ones.
Right, there’s no silver bullet. I think all I can do is increase the feedback bandwidth between my brain and the real world. Regular old stuff like linters, static typing, borrow checkers, e2e tests… all the way to “talking to customers more”
Turn off your watch history. It disables the front page and shorts, but you can still watch any video you want and also follow your subscriptions. You still get recommendations next to each video but I find those much less problematic personally.
Unfortunately, with watch history off, YouTube still pushes Shorts in the subscriptions page (at least on mobile web, which is where I primarily use YouTube).
I find that a lot less problematic as there's just very few shorts on my feed, I've never been able to scroll through more than 5 or so without just going into ones I've seen before.
Based on my experience writing many games that work great barring the occasional random physics engine explosion, I suspect that trigonometry is responsible for a significant proportion of glitches.
I think over the years I subconsciously learned to avoid trig because of the issues mentioned, but I do still fall back to angles, especially for things like camera rotation. I am curious how far the OP goes with this crusade in their production code.
Yes, for physics engines I think that's a very good use case when its worth the extra complexity for robustness. Generally I think if errors (or especially nan's) can meaningfully compound, ie if you have persistent state, that's when its a good idea to do a deeper investigation
thanks for the HN community - the video is how I ended up here and its one of the few social media-esque sites I bother visiting. Taught me a pile of things about coding and CS that weren't in my mechanical engineering degree.
I thought this video was a lot better than the Veritasium video. The Veritasium video was awkward. I think they tried to follow the formula from the (excellent) blue led video that performed so well, but it just didn't work.
Disagree, I thought the Veritasium video was fantastic. You understand how the machine works in depth, the history of its development and challenges it encountered, and hear from people actively working on it. It’s a science lesson and history lesson. Like usual, they keep the video engaging and focused on the story, while still keeping a lot of depth with the science. It’s a great format
The whole “exploding tiny drops of metal” in the middle of this is just Loony Toons. This machine is literally insane and two of the companies I am long-long on would be completely fucked without it.
IIRC from the Veritasium video[0] there is actually some hydrogen gas flowing at quite a high speed though the laser chamber to carry away the tin debris so that it does not accumulate on the mirrors.
Seeing this news story made me briefly fear that they’d found a way to replace this glorious mechanism. Thankfully not. In fact, they’re going to shoot more droplets, more often!
Yes it was crazy when I first heard about it "wait what? they shoot it in mid-air?" and that was before I found out they did that like 30k times a second.
But now 100k times a second apparently. Humans are amazing.
You have a machine that’s basically a clean room inside and one of the parts is essentially electrosputtering tin but then throwing all the tin away and using the EM pulse from the sputter to do work.
Oh and can you build it so it can run hundreds or thousands of hours before being cleaned? Thanks byyyyyyyyeeeeee!
The thing I didn't understand after watching that video was why you need such an exotic solution to produce EUV light. We can make lights no problem in the visible spectrum, we can make xray machines easily enough that every doctors office can afford one, what is it specifically about those wavelengths that are so tricky.
The efficiency of X-ray tubes is proportional to voltage, and is about 1% at 100kV voltage. This is the ballpark for the garden variety Xray machines. But the wavelength of interest for lithography corresponds to the voltage of only about 100V, so the efficiency would be 10 parts per million.
The source in the ASML machine produces something like 300-500W of light. With an Xray tube this would then require an electron beam with 50 MW of power. When focused into a microscopic dot on the target this would not work for any duration of time. Even if it did, the cooling and getting rid of unwanted wavelengths would have been very difficult.
A light bulb does not work because it is not hot enough. I suppose some kind of RF driven plasma could be hot enough, but considering that the source needs to be microscopic in size for focusing reasons, it is not clear how one could focus the RF energy on it without also ruining the hardware.
So, they use a microscopic plasma discharge which is heated by the focused laser. It "only" requires a few hundred kilowatts of electricity to power and cool the source itself.
The issue isn't in generating short wavelength light, it's in focusing it accurately enough to print a pattern with trillions of nanoscale features with few defects. We can't really use lenses since every material we could use is opaque to high energy photons so we need to use mirrors, which still absorb a lot of the light energy hitting them. Now this only explains why we need all the crazy stuff that asml puts in it's EUV machines to use near x-ray light, but not why they don't use x-ray or higher energy photons. I believe the answer to this is just that the mirrors they can use for EUV are unacceptably bad for anything higher, but I'm not sure
Photoresist too. XRays are really good at passing through matter, which is a bit of a problem when the whole goal is for them to be absorbed by a 100 nanometer thick film. They tend to ionize stuff, which is actually a mechanism for resist development, but XRay energies are high enough that the reactions become less predictable. They can knock electrons into neighboring resist regions or even knock them out of the material altogether.
It really is the specific wavelength. Higher or lower is easier. But euv has tricky properties which make it feasible for Lithography (although just barely it you have a look at the optics) but hard to produce with high intensities.
Specifically, what makes x-rays easy to generate are these: https://en.wikipedia.org/wiki/Characteristic_X-ray In essence, smashing electrons into atoms allows you to ionize the inner shell of an atom and when an electron drops down from an outer shell, the excess energy is shed as high-energy photons. This constrains the energy range of X-ray tubes ("smash electron into metal") to wavelengths well below 13.5nm.
(These emission lines are also what is being used in x-ray spectroscopy to identify elements)
There are no normal x-ray mirrors. The only way to focus them is to use special grazing mirrors where the x-rays hit them almost parallel to the surface.
As I understand it, primarly because due to the high energy level of x-rays, light x-ray interacts very differently with materials[1]. Primarily they get absorbed, so very difficult to make mirrors or lenses, which are crucial for litography to redirect and focus the light on a specific miniscule point on the wafer.
The primary method is to rely grazing angle reflection, but that per definition only allows you a tiny deflection at a time, nothing like a parabolic mirror or whatnot.
All of these problems or equivalent still exist in EUV. Litho industry had to kind of rethink the source and scanner because it went from all lenses to all mirrors in EUV. This is also why low NA and high NA EUV scanners were different phases.
As I hear it, the decision had large economic component related to Masks and even OPC.
100%. EUV barely works. XRay litho takes all the issues with EUV and cranks them up to 11. It will take comparable effort to EUV, if not more, to get XRay litho up and running, and I'm not aware of anyone approaching this to anywhere near the level of investment that ASML (and others) have pumped into developing EUV tech. We may get there eventually as a species, but we're a ways off.
If you think it barely works now, you should've seen it when we first started. Availability of a machine was "fuck you"% and the whole system was held together by duct tape, bubblegum and hope. Compared to that the current system is entirely controllable.
Oh, for sure, via herculean effort and investment we have created ourselves a functioning and economical process!
We do actually have functioning processes for XRay litho today, but we'll need that same level (or more) of investment and effort to make it economical.
Stochastic effects become a bigger and bigger problem. At some point (EUV) a single photon has enough energy to ionize atoms, causing a cascade that causes effects to bloom outside of the illumination spot.
> The key advancements in Monday's disclosure involved doubling the number of tin drops to about 100,000 every second, and shaping them into plasma using two smaller laser bursts, as opposed to today's machines that use a single shaping burst.
This is covered in that video. Did they let him leak their Q1 plans?
That has been covered before in other videos[0] that this is their roadmap to higher power, so I'm also not sure what they have announced now that wasn't previously announced.
From the first video I thought they had already shipped this, but it sounds like they were describing what their new model was.
This seems like a product with a very very long sales pipeline, so I wonder if they work on pre-orders with existing customers but announce delivery milestones only as they come?
A personal finance app called “Predictable” that takes chaotic sloshes of money and turns them into steady streams of cash. You tell it “I receive this much money weekly/monthly/on the first and fifteenth/when Mercury is in retrograde, and I have these expenses at other various intervals” and it evens everything out into a constant weekly flow of cash by, essentially, buffering. Any overflow or underflow goes to a “margin” bucket which basically tells you how much you could spend right now and still have enough for all your recurring expenses.
Currently making it just for myself but curious if anyone else would find it useful.
I'd love something like that, with the added ability to basically split the margin bucket into multiple buckets (one for me, one for the wife).
The main issue I've had with budgeting apps continues to be pulling in up-to-date transaction data, which is necessary to know how much I can spend right now. There always seems to be problems with the data syncing. Apple Card is the worst, as you can only pull transactions via wallet on device.
I wish we could just use a single bank account at the Fed. The banking network is absolutely shit and there's basically a 1% tax on everything that goes to the rich for no good reason.
Budgeting was soooo much easier with cash – it's maddening all the data is there for real-time personal finance but it can't be accessed.
I don't see how this article could possibly support the argument that C# is slower than GDScript
It compares several C# implementations of raycasts, never directly compares with GDScript, blames the C# performance on GDScript compatibility and has an strike-out'ed section advocating dropping of GDScript to improve C# performance!
Meanwhile, Godot's official documentation[1] actually does explicitly compare C# and GDScript, unlike the the article which just blames GDScript for C#'s numbers, claiming that C# wins in raw compute while having higher overhead calling into the engine
My post could have been a bit longer. It seems to have been misunderstood.
I use GDScript because it’s currently the best supported language in Godot. Most of the ecosystem is GDScript. C# feels a bit bolted-on. (See: binding overhead) If the situation were reversed, I’d be using C#. That’s one technical reason to prefer GDScript. But you’re free to choose C# for any number of reasons, I’m just trying to answer the question.
At least in my case, I got curious about the strength of /u/dustbunny's denouncement of Godot+C#.
I would have have put it as a matter of preference/right tool with GDScripts tighter engine integration contrasted with C#'s stronger tooling and available ecosystem.
But with how it was phrased, it didn't sound like expressing a preference for GDScript+C++ over C# or C#++, it sounded like C# had some fatal flaw. And that of course makes me curious. Was it a slightly awkward phrasing, or does C# Godot have some serious footgun I'm unaware of?
Makes sense! I think dustbunny said it best: C# is “not worth the squeeze” specifically in Godot, and specifically if you’re going for performance. But maybe that’ll change soon, who knows. The engine is still improving at a good clip.
I tried it for a while, it was fun explaining it to people, but didn’t actually help much. I ended up blocking all time wasters except HN, which is almost monochrome anyway.
I set grayscale in my phone's quiet hours settings. It's to help me sleep, rather than to reduce my phone usage. It means if I wake in the night and look at my phone, I'm not blasted by colors. Or if I stay up a bit later than usual. I find it beneficial although probably not revolutionary.
I did try setting my phone to grayscale during the day but didn't see much if any benefits there.
This was my experience as well. While it is less straining on the eyes, that was the only benefit I saw. I didn't see a reduction in screen time or less anxiety about notifications.
They mean the dependencies. If you’re testing system A whose sole purpose is to call functions in systems B and C, one approach is to replace B and C with mocks. The test simply checks that A calls the right functions.
The pain comes when system B changes. Oftentimes you can’t even make a benign change (like renaming a function) without updating a million tests.
Tests are only concerned with the user interface, not the implementation. If System B changes, that means that you only have to change your implementation around using System B to reflect it. The user interface remains the same, and thus the tests can remain the same, and therefore so can the mocks.
I think we’re in agreement. Mocks are usually all about reaching inside the implementation and checking things. I prefer highly accurate “fakes” - for example running queries against a real ephemeral Postgres instance in a Docker container instead of mocking out every SQL query and checking that query.Execute was called with the correct arguments.
> Mocks are usually all about reaching inside the implementation and checking things.
Unfortunately there is no consistency in the nomenclature used around testing. Testing is, after all, the least understood aspect of computer science. However, the dictionary suggests that a "mock" is something that is not authentic, but does not deceive (i.e. not the real thing, but behaves like the real thing). That is what I consider a "mock", but I'm gathering that is what you call a "fake".
Sticking with your example, a mock data provider to me is something that, for example, uses in-memory data structures instead of SQL. Tested with the same test suite as the SQL implementation. It is not the datastore intended to be used, but behaves the same way (as proven by the shared tests).
> checking that query.Execute was called with the correct arguments.
That sounds ridiculous and I am not sure why anyone would ever do such a thing. I'm not sure that even needs a name.
reply