nhaehnle

I believe the article exaggerates to make a point. Yes, good engineering can also be assisted with LLM-based agents, but there is a delta.

Good engineering requires that you still pay attention to the result produced by the agent(s).

Bad engineering might skip over that part.

Therefore, via Amdahl's law, LLM-based agents overall provide more acceleration to bad engineering than they do to good engineering.

My thought as well, but the question is: does it matter for what the survey is trying to achieve?

Some people will interpret it one way, some a subtly different way, but is there a reason that people's interpretation changes over time in a way that is more rapid and more significant than the underlying question of how good their life is broadly? Probably not.

There may be cultural differences that make it tricky to do comparisons between cultures / countries, but it should give something useful when looking at the same culture / country over time.

In particular, the bulk of the substantial text of the order has a pretty clear culture war bend with all the talk about how truthful AI is. This is in large part a fight over the political leaning of AI models.

That's the whole point. They aren't law, and they were (probably) never meant to be so far-reaching, and yet the clear purpose of this Executive Order is to tell the states what laws they can enact. The EO doesn't have the legal power to do that directly, but it clearly outlines the intention to withdraw federal funding from states that refuse to toe the line.

That's a fair and good interjection. The truth is probably that at society scale, both approaches are traditional.

The open sharing approach is traditional for research and academia, while the information restricting approach is traditional for business-oriented thinking.

So, a young field will typically start out fairly open and then get increasingly closed down. The long-term trajectory differs by field, and the modern open-source landscape shows that there can be a fair bit of oscillation.

We're seeing the same basic shape of story play out in generative AI.

It is quite interesting to ponder these usage statistics, isn't it?

According to their charts they're at a throughput of something like 7T tok/week total now. At 1$/Mtok, that's 7M$ per week. Less than half a billion per year. How much is that compared to the total inference market? And yet again, their throughput went like 20x in one year, who knows what's to come...

I agree on the first point. I clicked through to the previous blog entry which I also found to be really good.

If you'll look at the Guidelines for HN linked at the bottom of the page, you'll note that whether a submission is productive is not a criterion.

You could perhaps make an argument that among the flood of AI-related submissions, this one doesn't particularly move the needle on intellectual curiosity. Although satire is generally a good way to allow for some reflection on a serious topic, and I don't recall seeing AI-related satire here in a while.

Others have given some answer to who was made poorer by Ballmer holding Microsoft shares, but I'd argue that this is the wrong question. Instead of looking at a specific individual, we should look at systems.

A system that allows this kind of extreme wealth accumulation is quite fundamentally at odds with democracy because extreme wealth can be and is in practice used to influence politics in a way that undermines democracy.

Some people might not care about that, but if your goal is improving the outcomes of the largest number of people, then pretty much everything else is secondary to having a functioning democracy.

I just find it hard to take the 3x claims at face value because actual code generation is only a small part of my job, and so Amdahl's law currently limits any productivity increase from agentic AI to well below 2x for me.

(And I believe I'm fairly typical for my team. While there are more junior folks, it's not that I'm just stuck with powerpoint or something all day. Writing code is rarely the bottleneck.)

So... either their job is really just churning out code (where do these jobs exist, and are there any jobs like this at all that still care about quality?) or the most generous explanation that I can think of is that people are really, really bad at self-evaluations of productivity.

Good on you for having the meta-cognition to recognize it.

I've graded many exams in my university days (and set some myself), and it's exceedingly obvious that that's what many students are doing. I do wonder though how often they manage to fly under the radar. I'm sure it happens, as you described.

(This is also the reason why I strongly believe that in exams where students write free-form answers, points should be subtracted for incorrect statements even if a correct solution is somewhere in the word salad.)

I'm skeptical too, but at least accessibility and usability do show up in those four documents they link to.

I didn't see internationalization and localization, but I don't see anything fundamental about those that would be different.

Security, on the other hand, does feel like a different beast.

Fair point, yeah. The general concept should still apply, you could maybe wrap it in some macros, but it is going to be more awkward mostly because of the lack of operator overloading.

> don't have infinite different copies of the int64_t type

You can make some, though!

Basically, the idea is to define a class template NoAlias<T, Tag> that contains a single value of type T. Implement operators etc. to make the type useful in practice for working with the wrapped value. Type-based alias rules mean that an access to the value wrapped in NoAlias<int64_t, Tag1> can never alias a value wrapped in NoAlias<int64_t, Tag2>. (Tag1 and Tag2 can just be forward-declared structs that are never defined.)

One time, I even encountered a situation where this was mildly useful.

I sincerely hope both of you are just trying to make a joke. I don't think a web forum like this one is the right place for it, though.

Indeed. I wrote a tool for myself to help with that in my reviews: https://github.com/nhaehnle/vctools/tree/main/diff-modulo-ba...

It admittedly doesn't have a lot of polish, but I do use it regularly and I'd be happy to help anybody who is interested in using it.

A tool called "diff modulo base": https://git.sr.ht/~nhaehnle/diff-modulo-base

Given two version (old and new) of a Git change (i.e., individual commit or patch series from a pull request) it produces a diff that is actually useful for reviewing purposes, assuming you've already reviewed the old version of the change.

It's sort of like `git range-diff`, but where `git range-diff` produces a "diff of diffs" that is very hard to impossible to read, this tool gives you a direct diff between old and new versions, but filters out any irrelevant changes that were introduced because the author rebased on a more recent version of the target branch.

I hope that makes sense - I never know quite how to put it into words for somebody to understand who isn't intimately familiar with Git. It is very powerful though if you combine it with a minimal amount of setup e.g. for fetching all PR branches from a GitHub repository. I use it almost daily as part of my code review workflow.

> Every PR/commit merged to master should be a clean logical unit.

The issue is one of review scaling. I wrote a blog post about this a while ago[0], but the gist of it is that those clean logical units are often too small for meaningful high-level reviews of more complex work.

With complex features or refactorings, you're often in a situation where those clean logical units allow reviewers to do a good low-level review (do a check for logic corner cases, style issues, etc.) but they don´t allow a high-level review of how all the pieces of the feature work together.

IMHO the most open-source process friendly solution to the issue is to review patch series, where you can review the series as a whole for the big picture, but also dig into individual commits for the details. Building such a patch series requires an approach as described in the article.

(In closed source environments, you may get a good enough approximation of the result with a separate, disciplined software design process.)

[0] http://nhaehnle.blogspot.com/2020/06/they-want-to-be-small-t...

My understanding is that they're not necessarily asking for the commits to be squashed, they're asking for them to be submitted together as a patch series.

Patch series are an important part of a healthy review workflow because they allow both a micro and a macro view of changes. I have written about this before: http://nhaehnle.blogspot.com/2020/06/they-want-to-be-small-t...

One related aspect that the article doesn't go into too much is that there is a tension in the size of the unit of code review: there are reasons for reviewing big chunks at once, but also reasons for reviewing individual changes that are as small as possible. I've gone into more detail on this in the past.[0]

Stacked diffs make that possible because you can review either individual commits or an entire stack at once.

The irony is that this is largely the way that Linux kernel development works -- and the Linux kernel was the first user of Git! Most projects who later adopted Git seem to have never learned this lesson that was there from the beginning, and have since been reinventing wheels.

[0] http://nhaehnle.blogspot.com/2020/06/they-want-to-be-small-t...

Put uncommitted changes into a WIP commit (or multiple WIP commits), then fetch & rebase.

Putting stuff in commits ASAP locally is good practice anyway, since it guarantees you will never accidentally lose your work.

We have all been part of a massive real world experiment that shows a pretty obvious correlation between the introduction of vaccines and the reduction (and even elimination) of associated diseases.

Saying that a relatively small number of people have done the work to prove the effectiveness of vaccination is really disingenuous.

(Also, there's a pretty big difference between doubting an n=50 sociological study and deciding not to believe the very public historical record of global disease patterns.)

This article is terrible.

> Devalue Venezuela’s currency, the bolivar, by a whopping 95%. The new currency will be renamed the "sovereign bolivar."

> Instead of an exchange rate of 250,000 bolivars per US dollar, it will increase to around 6 million.

This is not a devaluation by 95%. The math doesn't add up.

> The petro is valued by the Venezuelan government at around $60, or 3,600 sovereign bolivars.

So 60 sovereign bolivars are one USD? Previously it said 6 million sovereign bolivars are one USD.

> To make things more complicated, the new sovereign dollar will also be re-denominated, which will remove about five zeros from its unit measurement.

Oh, okay. I assume they mean sovereign bolivar, not dollar (did nobody proofread this?). That makes the above point make more sense.

> At the same time, President Maduro also announced a huge 3,000% increase to the minimum wage.

> So in the new re-denominated currency, a person on the minimum wage will receive around 1,800 sovereign bolivars a month, instead of 1.8 million.

Is that 3000% increase in bolivars? In real terms? And again, I can't see the math adding up, even taking the supposed 95% devaluation.

And I haven't gone into any of the cryptocurrency stuff...

There's probably a lot of stupidity going on in this new Venezuelan policy, but that article makes a total mess of it on top of it. It's context-free reporting, by somebody who doesn't seem to care to understand what they're reporting, and the numbers just don't fit together.

The best I can make of it is:

1. The Venezuelan government still refuses to let the Bolivar float freely, which means that black market currency exchanges will continue to operate.

2. The Venezuelan government is changing the official exchange rate of Bolivar to USD.

3. The Venezuelan government is replacing the bolivar by the sovereign bolivar, where 1 sovereign bolivar = 100,000 bolivar.

4. They're increasing the minimum wage by an effective factor 100 in domestic currency. (The value of the minimum wage internationally will change by a different amount -- and not 3000% -- because of point 2, but any numbers you're getting out of the article are likely moot anyway because of black market exchanges.)

5. They're introducing some weird cryptocurrency gimmick that isn't explained properly.

Edit: And here's a Reuters article with different numbers for the minimum wage (stating a 3 mio baseline as opposed to 1.8 mio.): https://www.reuters.com/article/us-venezuela-economy/venezue...

From what I understand, another disadvantage of monolithic 3D are the yield implications.

When you fabricate several 2D chips and then integrate them, it allows you to test those 2D chips for errors separately before the integration, which should give you better yields overall.

You should look into integer linear programs. They are a much useful "DSL" for discrete optimization. You get a lot of insight into flow problems from studying their LPs, for example, and it's very easy and efficient to solve flow problems with additional constraints using ILPs. Also, the state of the art for solving TSP and related hard path-finding problems uses techniques from integer linear programming.

There's no general answer to your question, it depends on the problems. You can find parameter-preserving reductions between some problems, but this isn't always the case.

Also, instead of looking at fixed parameter tractability, it often makes more sense to look at approximation algorithms (if your goal is to optimize something, rather than getting a strict Yes/No answer).

Integer programming, not linear programming. Linear programming (without the integrality constraint) is in P, so you cannot use it to solve general SAT problems, which are NP-complete (unless a major and highly surprising theoretical breakthrough is found).

The free SAT solvers are very good, and much better than commercial IP solvers at solving problems that are a natural fit for SAT. (Obviously, you can encode any IP as an SAT formula and vice versa, and the IP solvers are better at solving the problems where you actually have meaningful arithmetic.)

There are certain aspects of light which the rendering equation doesn't model, so it's insufficient for true realism (the Limitations sections of the Wikipedia page is a good summary). It's pretty damn close, though.

I feel that the "ray tracing" vs. "path tracing" question is nit-picking for a very specialized audience at best. Most people simply understand ray tracing as being about tracing rays through geometry in some way (so both ray casting and path tracing are a form of using ray tracing). How you combine this tracing to give you pixel values is a higher-level question. If you look at ray-tracing frameworks / APIs like Optix or DXR, it's clear that this combination of tracing is left up to the programmer (for good reasons). What's important for the API to expose is the primitive operation of tracing a single ray, after all.

It didn't take long, but I really forced myself to do all typing in the "proper" way. I would say two weeks at most, maybe four until it really sank in indefinitely. Obviously this is with a lot of typing, and you do need the luxury to be able to suffer through a few slow days.

Ctrl+S does this in most terminal emulators (use Ctrl+Q to resume).