leecommamichael

I was surprised that the author didn’t translate the piped representation of the first program to a procedural program with explicit calls to subprocedures. It’s bigger, but it’s dead-simple and easy to slip instructions in the middle of.

I'm having a very hard time finding mention of token-generation speed.

Everything's a drum. https://www.youtube.com/watch?v=Q2T7oLbmvx4

How could there even be an xkcd which is so applicable? Wow.

In addition to this, I think one gets even more from reading after having tried to write. There's a unique feedback loop that starts happening once you start creating.

> This also lead to more arguments with the wife (which leads to a decrease in other things... ;)

I love the subtlety of the dual-use closing-parenthesis here.

It's interesting how this plays out with C/C++. There's not really a package manager, and so the host system has to have vetted packages. It moves the burden on to the system maintainer.

Ultimately I think devs need to think about their dependencies and decide which ones get pinned and a serious review before pulling. If the thing has got binaries, it gets a serious review. If it does anything with cryptography, it gets a serious review... etc.

I don't think automatic updating is a good idea at all. It's just the honor-system, and trust is a security flaw.

Thanks for the thorough reply. I personally haven't experienced brittleness/unfriendliness, but I have only written around 10k lines of Go. Not exactly a power user, but I like to think I understand it.

> If you’ve added the package to your imported then odds are your next step is going to build it. Thus negating any benefit.

I actually think this is the benefit! I don't need to go to a website to see what changed, I can just have a look at the code. The best dependencies have a changelog. Ideally I can look at a diff.

> I think you’re being too charitable here. I think Russ Cox just didn’t want a package manager because C doesn’t have one. But ended up relenting after everyone nagged the Go team for years afterwards.

That's entirely possible.

> So how do you know if a Go package has been compromised when the only source of truth is the compromised origin?

Fair point, and probably worse in this future we're in now that NIST is drowning in CVEs and has turned away from some share of them.

Here's a suggestion, do you think it could be this simple? If you write a package-manager, don't execute any of the downloaded code in an automated fashion. No hooks, no build-time metaprograms. If your language _needs_ metaprogramming to function, it's a huge secondary issue that I don't know how to solve. You can try to make a meta-program annotation which disables side-effects, but the metaprogram ultimately must write memory which expands the amount of code generated. All risk is introduced when the person downloading cannot preview the content in a safe place.

Has Go not had the most secure ecosystem?

What is your critique of their approach? Is it not the case that `go get` is the only one which doesn't even provide a way for the person downloading to run the downloaded code until it is actually executed by the consuming codebase? That seems pretty sound by comparison.

I guess you're saying, "they had to" meaning they should've seen the need and provided it? I'll say this to that (imagined) take; plenty of useful software was made without it, and they got the job done when they knew the absolute most about what a good solution would need. I totally understand being annoyed at the fact that this is the story of every evolution in Go, but I genuinely think they're picking good implementations when they decide on them.

NPM came along in 2010, Javascript was huge before that.

It was only when people wanted a common approach to shipping both in browser and "native" that this glitch happened. I believe a standard library and "batteries" would have abated it entirely or resulted in a slightly less-bad situation. I do think Cargo is a slightly less-bad situation in many ways, and that it can be done better.

The Odin programming language does this! It has also decided not to provide a package manager.

"HP" "obscure"

Cool nonetheless.

... and then there's me. I know it's capable, but I have not yet found a good heuristic to decide when to write or generate code. A good heuristic would comfort me. It would assure me that I'm not missing chances to improve the system.

I've been getting curious about LLM code generation lately. I've been doing experiments over these past 4 years to try to adopt them at my own discretion. My codebase is around 25,000 lines of a popular C-like language.

I decided to race Opus 5 High the other day. I asked it to add a grid to help me perceive depth in the 3D space of my application. There were some clear flaws, it took several prompts and ~32 minutes. I did not inspect the code for quality, I did not read closely. I then stashed the change and implemented it myself. It took me 35 minutes to get happy with my results (I chose to do analytical filtering to reduce jaggies and moiré.) Upon inspecting both diffs, I had added about 60 lines of code (including comments) and Opus added 500. It looked like just under half of what Opus generated was comments, fine, I expect that... I ended up liking the way I went about things. Opus tried to reuse just about every little utility in the codebase, and actually duplicated the definition of some in-line (an alpha premultiply comes to memory.)

My conclusion is; two is better than one. I wouldn't be super upset if I had a junior on my project and they submitted this code. I'd be sure to tell them they could've done it with a lot less, so they get an eye for simplicity. I can't do that for Opus, and I find that a bit sad. But ultimately, it got the job done. How much of this kind of complexity can I let rack up? Is that what I ought to do? This is an interesting comparison, but that strategy reminds me of garbage collection but for code instead of data. Do I just let the mess pile up and go clean it up every week or so? Maybe that's what I'll try next, I don't know. I do think I can accomplish more using this as a tool, but I am just finding it to be a bit of a problem figuring out how I'll do that in a manner that is authentic to myself.

I wish LLMs were more boring.

> In this case, the cost is dynamic dispatch and pointer-chasing.

To sharpen your statement, the cost is missing the CPU caches, which is often caused by failing to pool allocations and reading indirectly.

> But the argument is you're trading some of that performance optimization for maintainability.

Right, but exactly how much? I would argue "very OOP" design styles neuter your ability to optimize the system, and sometimes necessitate that you are kept at arms-length from the system, only capable of "customizing" it via more abstract API layers. I do believe certain OOP practices can make maintaining software easier, but I also believe we have not figured out how to retain control over the computer in the face of these abstractions.

As an example, Clean Coders advocate for "separation of responsibilities" and often speak in terms like "ownership" or what a function/class "knows about" or "should have to know about." When different classes are given different data-fields in the pursuit of making it clearer (what should exist in that scope,) you are creating a constraint which is virally spread through the codebase which runs counter to what the CPU wants. The CPU wants an array, but you can't have an array because the FileManagerFile can't "know about" the FileManagerFileCache, and the FileManagerFileCache can't known about the FileCache, so now each FileManager "owns" its own cache, which is an entirely separate heap allocation.

> you'll wish you had a conceptual entity that encapsulated the operations on the type of workflows so you just had to implement them in one place.

Why have you drawn the conclusion that the author is against this? A function with a switch-statement can do this.

> I have to think about everything, everywhere, all the time.

I think this is familiarity speaking, which is what you're expressing earlier in the comment anyway. The reality is that we have to think of everything when telling a machine what to do. Exactly how we get that done is preference.

I wonder how long it takes to build, and how quickly it builds executables, compared to the new stuff.

I don't feel that the way you are paraphrasing me represents what I am trying to say at all, and I feel misunderstood. I do think the phrase "appeal to civility" was fine, but the negation of that phrase doesn't exactly equate to an accusation of being "uncivil," if you know what I mean. I don't disagree with what you're saying in the abstract, and I've had this conversation elsewhere in the thread.

There has got to be a way to be strong against a cause without being strong against the people who represent it. I believe this devolves to violence otherwise.

I appreciate the response, and I can relate. Perhaps I'm too sensitive to some rumblings I'm perceiving in the US at the moment. I don't know. I genuinely do not know.

When you say "listen before rejecting," what would you have me do differently? To call what I'm saying "rejection" seems a bridge too far from what I am intending to say, also. I am making an appeal to civility and compassion in the event that he intended to say what he said knowing that people might feel badly by it.

After reading some other comments on what I wrote, I guess I'm just surprised if/that he doesn't know this will offend people, and I see a simple way to make his point without doing so.

When you put it that way, I have no issue agreeing wholeheartedly. He’s making an example of incel culture as it appears to him to apply to software culture. After I describe it that way, I think he didn’t have to stoke the religious right in doing so. Something that hadn’t occurred to me until your reply (thank you) was that he might not be aware he’s doing that, and that is where I may be wrong in assessing the “taste” of the messaging. But I will be firm in my initial reason to post: knowingly aggravating each other is a problem in this country. We need compassion and mutual respect. Cooling the temperature of discourse will require a surplus in patience. Maybe even faith. (I am not religious, this is not a dog-whistle.)

I was so pre-occupied with someone being offended by what he was saying that I didn't see the clear positive angles you're showing. I appreciate that.

> “I almost fell into this trap (...) I was raised by conservative Christian parents and thereby had so, so much to learn, and unlearn, in order to date comfortable and confidently.

Is this engagement bait? Is this a cultural critique? What is meant to be said here? At any rate, this is the kind of speech which will alienate a lot of people. Look, I'm more on the progressive end of things, I get it, but I think this just feels mean and divisive from the perspective of a conservative OR a Christian, and I find that to be a message made in poor taste... which is difficult because this is such a potentially inspiring and positive talk. I lost the energy to be inspired by the talk due to this style of messaging, but I don't think you should have to. I'm just a bit thrown off, I guess.

The OP is not citing their claims, but their commentary. Do you understand why I find that to be different than citing their findings? We're not talking percentages here.

At this point GL is an interface, implementations will come and go, but the interface refuses to die. It's still the simplest way to get started, and the browser (WebGL) demands portability for code written against the API.

Don't let the downvotes get you down. They don't know who funds or constitutes METR. If you actually read these papers, you'll find they cite themselves 4-5 times each publication. They also consider "hosting an HTTP server using Python" to be a "long time horizon" task.