greggyb

I don’t see how it could be that bad (incorrect, specifically), considering bun is probably the most widely-used production use case of zig.

That may be the case, but the bun project only needs zig to correctly compile bun. The zig project needs to be able to correctly compile all existing and possible zig programs.

I haven't reviewed things, but it's possible and even likely (at least based on my own experience with LLMs) that the validation is mostly focused on bun compilation.

Title is annoying and the article doesn't bear it out. This is not "reverse" game theory. It's just game theory and incentives: something you'd learn in any course of study of economics.

But yes, if you change incentives, you can change behavior. And if you can find a way to create and enforce incentives that push toward an outcome you want, then you get more of that outcome. This is a good lesson to remind people of: incentives matter. So often---especially in discussion of public policy---we see conflation of stated desires with incentives, and of incentives with "cash paid to someone". The former is fallacy, and the latter myopic.

ALL OF IT is meaningless. It's a pointless discussion.

That is a nihilistic take. That it's pointless and everything about the domain (measurement of productivity) is meaningless.

"Productivity" is no more made up of a concept than "good work". The fact that many attempts to measure it are quite dumb (e.g., the idea of using LOC as a metric) does not mean the whole idea is not worth considering or discussing.

I've had a large project recently which has biased my view on unit testing from LLMs. It includes a lot of parsing and other workflows that require character-specific placement in strings for a lot of tests. Due to how tokenization works, that is a gnarly use case for LLMs. I am trying not to form too many strong opinions about LLM-driven-TDD based on it. My forays into other domains show better results for unit tests, but the weight of my experience is in this particular low point lately.

Yes, but it comes up in conversations of LLMs a lot. Thus, the rant in question. I think we are in agreement, or at least we lack disagreement, because that is the only stance I endeavored to take in the post.

Measuring productivity in software development is a hard problem, beyond the typical categorizations used in computer science. Unfortunately, I think my best answer is to go read the book I linked in the conclusion: https://link.springer.com/chapter/10.1007/978-1-4842-4221-6_...

That is an unsatisfying answer. I can point to anecdotes that suggest AI is hurting productivity or improving it, but those don't make an argument. And the extremes on either side make it very difficult to consider. How do you weigh "An LLM deleted my production database" against "I built a business on the back of AI-assisted software"?

I think we have to wait and see. And we should revisit questions of cost and value continuously, not just about LLMs, but generally in life. Most of my motivation (though not an overwhelming majority) around using LLMs right now is a mix of curiosity and wanting to avoid the fate of the steam shovel.

The post is about using LOC as a metric when making any sort of point about AI. Nowhere do I suggest someone shouldn't use it, nor that they should expect negative results if they opt to.

I'd recommend you read the book referenced in the conclusion: https://link.springer.com/chapter/10.1007/978-1-4842-4221-6_...

The full PDF is available for download. It's mostly a series of essays, so you can pick and choose and read nonlinearly. It's worth thinking about beyond nihilistic takes.

https://www.antifound.com/atom.xml

As stated in the article, I have unlimited access to multiple frontier models and I use Claude Code, among other harnesses. The rest of your list is not directly addressed in the post, because it is irrelevant to the point being made, but I do all of those things and more. You will note that in the appendix on LLM usage, some of the things I constantly have to correct in LLM-generated code are testing mistakes. And if you care to ask, yes I have context files to address these mistakes, and I iterate them to try to improve the experience.

I would honestly appreciate constructive feedback on LLM usage, because, as I stated, I am constantly having to rework code that LLMs generate for me. The value I get from LLMs is not in code generation.

The complaints about LLM's that lack any information about the domains being worked in, the means of integration (deep in your IDE vs cut and paste into vim) and what your asking it to do (in a very literal sense) are the critical factors that remain "un aired" in these sorts of laments.

I'm not sure if this is a direct response to the article or a general point. The article includes an appendix about my use of LLMs and the domains I have used them in.

I didn't set out to teach you anything, change your behavior, or give you practical takeaways, so it's a rant (: Emotions can be expressed with citations.

I am fully on board with gen AI representing a paradigm shift in software development. I tried to be careful not to take a stance on other debates in the larger conversation. I just saw too many people talking about how much code they're generating as proof statements when discussing LLMs. I think that, specifically---i.e., using LOC generated as the basis of any meaningful argument about effectiveness or productivity---is a silly thing to do. There are plenty of other things we should discuss besides LOC.

I actually consider that the claim is not that bold, and in fact has been common in our industry for most of the short time it has been around. I included a few articles and studies with time breakdowns of developer activity that I think help to illustrate this.

If an activity (getting code into source files) used to take up <50% of the time of programmers, then removing that bottleneck cannot even double the throughput of the process. This is not taking into account non-programmer roles involved in software development. This is akin to Amdahl's law when we talk about the benefits of parallelism.

I made no argument with regard to threat to the profession, and I make none here.

Unfortunately, this post was published at the puked out phase (;

(author here)

Hey, author here. Never thought I'd see my pokey little blog on HN and all that.

Happy to discuss further.

https://archive.md/N3BZV

What nasty comments? There are three visible at the time i see your own comment, none nasty.

I would imagine most large-scale data center construction projects will include electrical engineers to design the electrical subsystem. A rack's floor footprint is a few square feet. You can put several million dollars of hardware into that rack. A data center will have at least a few racks. It's a very reasonable investment to bring someone in to do electrical design.

Any wire---of any non superconducting material---will be hotter at higher current flows. You size the wire to the application.

I've had the experience of getting to sit beside several categories of people across my career and watch them attempt to do something which is causing issues or errors. The pattern I have seen the most is what I can only describe as speedrunning the error. People will try to do the thing they (think they) know how to do. When information or error comes available on the screen, they completely ignore it; if it is a popup, it is closed as quickly as possible and if it is shown somewhere on the screen that doesn't interrupt their flow, then it is completely ignored.

I have given instructions to repeat, but more slowly, and people will still click through errors without a chance to read. I have asked people to go step by step and pause after every step so we can look at what's going on, and they will treat "do thing and close resulting error" as a single step, pausing only after having closed the error.

The only explanation I have that I can understand is that closing errors and popups is a reflex for many people, such that they don't even register doing it. I don't know if this is true or if people would agree with it.

I've seen this with programmers at all levels of seniority. I've seen it with technically capable non-programmers. I've seen it with non-technical people just trying to use some piece of software.

The only thing that's ever been effective for me is to coach people to copy all text and take screenshots of literally everything that is happening on their screen (too many narrow screenshots that obscure useful context, so I ask for whole-screen screenshots only). Some people do well with this. Some never seem to put any effort into the communication.

One avenue, couched in specifics of US law, but I presume the ideas have analogs in Germany's legal system:

A battery occurs when a harmful physical contact occurs. Contact with a weapon is pretty much by definition battery.

The use of such a drug in the commission of rape or other violent crimes would then be a very easily proven case. If the substance is present in a victim's body, then battery has occured, basically by definition.

Given that rape and other violent crimes that are committed with the use of such drugs may not leave other physical signs on the body of the victim, then this may be the only physical evidence.

The examination for presence of such a drug in the bloodstream is also much less intrusive than for a typical rape kit exam.

There's nothing binary or black and white in such investigations, so this is an additional avenue to provide evidence to support the prosecution of these violent criminals.

I'd argue pipes are even more powerful with multi-core machines. You get parallelism for absolutely free. No thread pools to manage, no async, no channels, no new abstractions. Just the same pipe that works in the same way it did 50 years ago.

But because each step of the pipeline is a separate process, you get the N executables of the pipeline all able to run on separate cores.

I am not trying to say that every workload will benefit from this, or that such coarse parallelism is optimal for all use cases. But the fact that it is free with no changes to the pipe, the pipeline, or any of the executables is incredible.

Yes, I agree with that preference. I don't love the verbiage of "structured" / "unstructured" in either usage (the article's or that which I shared).

Coming from a data engineering and business analytics background, the terms "structured" and "unstructured" seem to be swapped in meaning here.

I'd expect to talk about anything in a DB as "structured data". Flexible serialization formats such as JSON or XML are "semi-structured". And something from e.g., an office document is "unstructured".

This is not a complaint or criticism. I understand the article just fine. It's just interesting how different perspectives can affect what words mean (:

ML, the language heritage from which OCaml derives, was explicitly designed with interpreters and compilers in mind.

Coming from an educational background of imperial units, I sometimes catch flak from ... most of the world about this.

I take joy in exuberantly pushing back on their insistence of clinging to such archaic time units as "minutes", "hours", and "days", telling them to come back when they embrace kiloseconds. It is telling that most of my friends accept this with equal joy and laughter (:

It probably doesn't hurt that I've also spent time drilling metric conversions so that I can code-switch pretty seamlessly among units. Neurotic tendencies can have payoffs.

Perhaps you'd like to share a slightly more specific reference?

After all, these books treat many topics. Without specific reference, one might uncharitably assume that you are attempting to simultaneously misdirect and appeal to authority.

Yet "whomever" is also the object of the preposition, "to".

Certainly, if we took the primary clause of the sentence and substite in any number of pronouns, you'd agree that the objective forms are correct:

The book belongs to whomever. Not "whoever".

The book belongs to her. Not "she".

The book belongs to us. Not "we".

I don't know the English grammatical rule for this situation, but it certainly seems reasonable to say that the dependent clause does not get to dictate the form of an independent clause.

Bike lane congestion is wholly unlike car congestion. It happens, and for busy routes, you do need affordances in the bike lanes and infrastructure.

That said, I've never missed a light cycle while bicycling, even in rush hour in major metro areas with many people on bikes. The busiest bike intersection in the world, in Copenhagen, devotes less space to bikes than most US streets devote to one lane of vehicle traffic.

Every single US city I have seen has ample space for bicycle infrastructure. Many have lots of roads with sufficient space for dedicated transit lanes, and bicycle lanes, and widened sidewalks while still maintaining space for personal vehicles.

Even if we take your hypothetical to the extreme, with only bicycles and no personal vehicles, every US city has enough space for the bike traffic on its existing streets.

...continued...

* You are much safer being in a car when hit by another car than when not being in a car. This is something a lot of bike commute advocates sweep under the rug. They talk about how biking is overall safe, but then you ask them if they've ever had an accident and so many have been hit by cars and broken bones.

And you are much safer not having an accident in the first place. If we want to observe the world, there are cities that have done a great job at reducing all vehicle related fatalities and injuries: those injuries to drivers and passengers in any vehicle involved, and also those injuries to anyone outside of the vehicle.

There are two commonalities in these cities: 1) they have many viable options for transportation, including high quality bike infra, pedestrian areas, trains, buses, metros, trams, and personal vehicles; and 2) they reduce traffic and speed in all areas where personal vehicles are potentially in conflict with other forms of transportation.

You'll recognize in the first point the same refrain I have been repeating: optimizing a transportation system does not mean optimizing primarily on just one mode of transit. It's not about forcing one mode or banning another. It is about options. There is a near universal observation about transit times within and into/out of urban areas that the time for car travel tends toward the time for public transit. This is generally understood to be because humans optimize their transport, and if one option is faster or more convenient, enough people choose that until it is not.

The second thing those cities do, though, is the leading cause for the reduction in accident frequency, lethality, and severity of injury: the reduction in traffic quantity and speed.

The road-street distinction is very important here. If you are not familiar with it, the distinction is this: roads are high speed connections between places, optimizing for vehicle throughput; streets are complex environments where a wide assortment of destinations are, where living is done, businesses exist, and the general activities of life and city happen. If you want more detail, this video is a good primer (linked to a relevant portion: https://youtu.be/ORzNZUeUHAM?t=536); the video is coming from a very strong place of opinion. I am not asking you to accept all the opinions, but am simply sharing the video, because it provides lots of good real-world examples in laying out the distinction.

It is essential that, within a city, there are affordances for people out of cars and people in cars. This is simple reality. If we recognize this reality, and we understand that humans are imperfect and prone to failure, then the conclusion is that if we want to reduce the injuries and deaths associated with traffic, we must build systems that tend toward this outcome. The practical implementations of such systems that are proven to be effective in achieving this outcome are:

1. separate through-traffic 2. ensure mixed-mode areas force low volumes and speeds of cars

The first is by designing transportation networks that force through-traffic to roads designed for it.

The second takes many forms, generally known as traffic calming. I have mentioned a few already. You can search for more. The other side of this is recognizing that cities are for people (the people in the cars and the people out of the cars, though at some points the people in the cars become people out of cars). There must be areas where people want to go. And those areas where people are must minimize the risk of negative interactions with vehicles. Again, traffic calming and pedestrianizing.

Regarding injury: the most likely cause of death and severe injury for a shockingly wide swath of adults in the US is a car accident, whether in the car or out of it. I do not make this as an argument against cars. I make this as an argument for design of car infrastructure in ways that makes me safer regardless of which side of the steel I am on.