> The whole idea of trusting the cloud to manage credentials on your behalf seems like a mistake.
Isn't this what the "trusted" in "trusted publishing" implies? Maybe you're saying that trusted publishing itself seems like a mistake, but if so you don't need to use it: you can publish your packages the old-fashioned way and npm will make you go through the 2fa flow.
- Video games - only feasible because of computers.
- Medical device firmware - hardware control layer for medical devices, which are used to aid in medical procedures.
- Synthesizers - help to make music.
- Detailed universe-scale physics simulations - help to make certain physics problems more tractable.
- Mars rover control software - helps to remote control rovers.
- The Linux kernel - control layer that sits between firmware and actual applications, pretty much just a common shared library so apps don't have to each ship with a full stack.
I don't really see your point here. None of these examples counter the argument that software is created to automate human labour as much as is practical.
Video games are an interesting category since they're entirely enabled by software: I can't imagine anyone driving a video game manually (note I don't consider things like Chess, etc software to be video games in this context; more things like FPS, racing, etc). I do remember as a kid I thought that there were actually little people doing the stuff in video games though.
The parent comment said "to do something that a human does/did", so I tried to come up with a diverse list of software that performs functions humans hadn't/couldn't've done.
> software is created to automate human labour as much as is practical
That's certainly a reason software is created, but not the only reason.
> Medical device firmware - hardware control layer for medical devices, which are used to aid in medical procedures.
I should've been more specific, maybe "MRI scanner firmware". Lots of medical devices could not exist without software.
> Synthesizers - help to make music.
Yes, they "help to make music", but synthesizers can produce sounds that humans cannot produce by themselves. If the upthread comment were about technology broadly rather than software specifically, I could've written "saxophones" here.
> Detailed universe-scale physics simulations - help to make certain physics problems more tractable.
"More tractable", or "tractable at all"? Simulations that would take 100 human lifetimes to compute on paper weren't even attempted before.
> Mars rover control software - helps to remote control rovers.
This clearly wasn't ever done without software, so I don't think I understand your response. I can't even imagine how it could have been done without software (my first ridiculous thought is very long cables going from Earth to Mars mechanically controlling a rover, but even if we had a magical material that'd enable that, the cables would get tangled up as the planets move).
> The Linux kernel - control layer that sits between firmware and actual applications, pretty much just a common shared library so apps don't have to each ship with a full stack.
I thought the pushback on this would be "this is just an implementation detail to let us run other software, so it shouldn't count". I don't think I understand your response here either.
---
I guess my general reaction is: sure, if you broaden the criteria enough then you can interpret most anything as "something that a human does/did". Like: humans "have fun" and therefore video games don't count, or humans can jump therefore they "travel through the air" therefore airplanes are just "doing something that humans do". But I don't think this reading of the upthread comment leads to interesting discussion.
Ah I think I see where things went off the rails. I should've explicitly added "would have to do" to purposes for creating software; it was just on my mind, and left as an implicit.
I don't think there's anything out there that a computer can do but humans can't do per se. Whether it's manually doing what an MRI does, or sending people with the Mars rover. It would be anything from tedious/inefficient through crazy difficult/dangerous to totally impossible at this time (at some point in time it would at least be possible). Though that's just being pedantic, especially re video games.
> "this is just an implementation detail to let us run other software, so it shouldn't count"
That's essentially what I said, but in different words.
The main point in my original reply was to question the point of software creation, if not to stand in for human capability, wholly or partially. I don't see people creating software explicitly to just let it gather dust for example, even though that happens very often.
> The main point in my original reply was to question the point of software creation, if not to stand in for human capability, wholly or partially. I don't see people creating software explicitly to just let it gather dust for example, even though that happens very often.
Are you referring to the developer's/organization's motivations? Maybe this is a proximate-vs-ultimate-cause sort of thing, but people are also motivated to create software by a desire to express themselves, to win competitions, to stave off boredom, to commit crimes, to prove theorems, to earn money, to show off, to learn things, and so on.
I write software to automate away plenty of my own activities (and occasionally others' too), but even when counting things like test suites, build scripts, etc, I'd estimate that less than a third of the code I've written was because I sat down at the keyboard thinking "I want to replace a human capability".
> I don't think there's anything out there that a computer can do but humans can't do per se.
The first thing that comes to mind is complex calculations that need to happen within a certain time budget to be useful. Like, sure, I could "play GTA 5" by sending each of my inputs to a room full of mathematicians frantically doing calculations who then instruct artists how to paint the next frame to send back to me[0], but even if you could somehow get that to run at 1 frame per day, I'd argue that's not really "playing GTA 5" anymore (a core aspect of the game is reacting to things in real time). For a more tangible scenario, imagine trying to pilot a quadcopter by manually controlling each actuator individually (there's no way you could do that quickly/accurately enough to avoid crashing).
[0]: Also this is arguably still "a computer", just one with an unconventional architecture.
My reply in a sibling thread[0] is applicable here too. I'm not sure if you have the same things in mind as skeledrew, but at least this seems probably relevant:
> If you broaden the criteria enough then you can interpret most anything as "something that a human does/did". Like: humans "have fun" and therefore video games don't count, or humans can jump therefore they "travel through the air" therefore airplanes are just "doing something that humans do". But I don't think this reading of the upthread comment leads to interesting discussion.
I'd be happy to discuss specific examples of the "pre computer forms", if you provide some.
Well not really, since the board game itself doesn't need a paid human to work. It's been crafted by a human, but video games are also crafted by (arguably many more) humans. The closest would be escape games, or larger scale games maybe
I note that article seems quite biased against Loeb. For example, they cite USA Today strongly criticizing him, which is not a reputable source in this debate. Wikipedia also doesn't mention that many other astrophysicists think that his 'Oumuamua theory is unlikely but not crazy. They only cite very negative criticism, but not the many more neutral responses. They also don't mention that he is far from the only one believing that 'Oumuamua appears to have a highly unusual shape. Wikipedia tries to paint him in the worst light possible.
I've got no horse in this race, but the great thing about Wikipedia is that you can edit the article[0] to fix anything that you feel is incorrect and/or not adhering to the encyclopedia's policies. You could also bring up your concerns on the talk page[1].
My edit would be reverted, and my talk page complaints would take a large amount of effort that likely ultimately goes nowhere when it's up against established editors. Instead I was telling you here that Wikipedia is not automatically unbiased just because it could theoretically be edited by anyone.
Another reason I can think of is simple disagreement about facts (or, relatedly, disliking the lack of sources/evidence in the comment).
Like it or not, downvoting for mere disagreement is allowed here[0]. I personally think that any such downvotes should at least be accompanied by a reply, but I haven't been able to find official guidance about that.
That was me. Algebra clicked for me so I found the pace of the class to be slow. Ended up creating a few programs to solve tedious things like the quadratic formula incrementally while displaying the intermediate steps so I could write them down on tests.
Authoring programs using the buttons on the calculator was not fun.
Most teachers were not good at checking this. There was an archive mechanism which would compress the file and IIRC, prevent it from showing up in the program list. You could of course just unarchive it.
Even though I never cheated, I never wanted my programs to get erased... I just created an image of the "memory erased" screen and showed that to the teachers.
Why are you starting the clock at the time when you already have a "high level plan that you are extremely familiar with"? I think it's fairer to start from "I received a bug report/feature request" or similar.
Also, haven't you ever had a situation where the prompt you started with ends up being longer than the final code diff? Perhaps a subtle bug that's hard to describe/trigger, but ended up having a simple root cause like an off-by-one error?
Also also, coding agents are infamous for generating way more code than is strictly necessary. The 2000 lines of code that the agent generated may well have been only 200 lines had you written it yourself.
>Why are you starting the clock at the time when you already have a "high level plan that you are extremely familiar with"? I think it's fairer to start from "I received a bug report/feature request" or similar.
Done both. We tag the LLM on slack in a reply and the ticket gets created and forwarded to an agent that automatically works on it. The only time a human is in the loop is review or or queries for changes.
>Also, haven't you ever had a situation where the prompt you started with ends up being longer than the final code diff? Perhaps a subtle bug that's hard to describe/trigger, but ended up having a simple root cause like an off-by-one error?
Sometimes. Getting rarer and rarer.
>Also also, coding agents are infamous for generating way more code than is strictly necessary. The 2000 lines of code that the agent generated may well have been only 200 lines had you written it yourself.
Depends on the agent and it's random. This was mostly true probably 5 months ago. It's much less true now.
Isn't this what the "trusted" in "trusted publishing" implies? Maybe you're saying that trusted publishing itself seems like a mistake, but if so you don't need to use it: you can publish your packages the old-fashioned way and npm will make you go through the 2fa flow.
reply