> The other side is those people who do not find those kind of bugs annoying
Anecdotally, I find these are the same people who work less effectively and efficiently. At my company, I know people who mainly use Notepad++ for editing code when VSCode (or another IDE) is readily available, who use print over debuggers, who don't get frustrated by runtime errors that could be caught in IDEs, and who opt out of using coding assistants. I happen to know as a matter of fact that the person who codes in Notepad++ frequently has trivial errors, and generally these people don't push code out as fast they could.
And they don't care to change the way they work even after seeing the alternatives and knowing they are objectively more efficient.
I am not their managers, so I say to myself "this is none of my business" and move on. I do feel pity for them.
Well, using print over debuggers is fairly common in Rust and other languages with strong type systems because most bugs are, due to the extreme lengths the compiler goes to to able to detect them even before running the program, just lacks of information of the value of an expression at a single point in the program flow, which is where dbg! shines. I agree with all the other points though.
Anecdotally, I was just writing a generic BPE implementation, and spend a few hours tracking down a bug. I used debug statements to look at the values of expressions, and noticed that something was off. Only later did I figure out that I modified a value, but used the old copy — a simple logic error that #[must_use] could have prevented. cargo clippy -W pedantic is annoying, but this taught be I better listen to what it has to say.
I didn't say print is bad. There is a ton of problems where debuggers alone are not enough and print is required. I meant choosing print when the debugger is readily available and allows developers to get what they need without constantly changing the code to insert "print" and recompile/rerun the code.
>these people don't push code out as fast they could.
Well, one of my coworkers pushes code quite fast, and also he is the one who get rejected more often because he keep adding .tmp, .pyc and even .env files to his commits. I guess "git add asterisk" is faster, and thus more efficient, than adding files slowly or taking time to edit gitignore.
Not so long ago I read a history here in HN about a guy that first coded in his head, then wrote everything in paper, and finally coded in a computer. It compiled without errors. Slow pusher? Inefficient?
> Not so long ago I read a history here in HN about a guy that first coded in his head, then wrote everything in paper, and finally coded in a computer. It compiled without errors. Slow pusher? Inefficient?
I've read and heard stories about these folks too, apparently this was more common decades ago.
To be clear, I don't think I could pull it off with any language. It's quite impressive and admirable to get things right on the first try.
Having said that, the thing is, languages were a lot simpler back then too. I'm not convinced this is realistically even possible with today's languages unless you constrain yourself to some overly restrictive subset. Like try this with C++, and I would be shocked if you can write nontrivial programs without getting compiler errors. Like to give a trivial example, every time I write my own iterator class for a container, I miss something when I hit compile: like either a comparison operator, or subtraction, or conversion to const iterator, or post-decrement, or subscript, or some member typedef. Or try it with python, and I bet you'll call .get() on something and then forget to check for null somewhere.
I would love to be proven wrong though. If anyone knows of someone who does this with a modern language, please share.
They invented .gitignore to prevent those files to get checked in into the repository.
Head, paper, keyboard is what we did in the 80s when compilers were too slow to afford throwing code at them and fix the errors later. Was that code in the HN story a substantial piece of code or some 100 lines program? Our programs used to be small.
.gitignore doesn't prevent you from committing unwanted files if a pattern is missing. This is a real example: .gitignore had ".sqlite3" extension ignored, but this coworker created a test database as ".dbsq3" or something like that for some reason. He forgot to add the pattern to .gitignore and the file was commited.
Also you can have .env in the .gitignore, yet someone create their file as .env.local and escape the .gitignore pattern. It's easy to come after and lecturing about creating a better .gitignore pattern, but it's even easier to at the very least take a little care of your commits even if it means slower speeds.
I think you missed the point. It doesn't matter if people used paper or anything. They can do whatever they want, as long as their they can commit code to the source control with high quality.
This makes a lot of sense and glad to see it (don't have to rely on ROCm adoption for Apple). Apple is smart to use under-valued hardware. Nvidia with its hold on CUDA have inflated hardware pricing/performance. Nvidia still leads in the largest scale SKUs but Apple's usage on pro/consumer devices is certainly below those needs.
This pattern follows how Apple would switch from PowerPC to Intel, SCSI to IDE, or between Nvidia/AMD for GPUs. It diversifies their supply chain and forces suppliers to compete on performance/price.
Yeah, we’re using it a lot at Sourcegraph. There are some extra APIs it offers beyond what MCP offers, such as annotations (as you can see on the homepage of https://openctx.org). We worked with Anthropic on MCP because this kind of layer benefits everyone, and we’ve already shipped interoperability.
Interesting. In Cody training sessions given by Sourcegraph, I saw OpenCtx mentioned a few times "casually", and the focus is always on Cody core concepts and features like prompt engineering and manual context etc. Sounds like for enterprise customers, setting up context is meant for infrastructure teams within the company, and end users mostly should not worry about OpenCxt?
Most users won't and shouldn't need to go through the process of adding context sources. In the enterprise, you want these to be chosen by (and pre-authed/configured by) admins, or at least not by each individual user, because that would introduce a lot of friction and inconsistency. We are still working on making that smooth, which is why we haven't been very loud about OpenCtx to end users yet.
But today we already have lots of enterprise customers building their own OpenCtx providers and/or using the `openctx.providers` global settings in Sourcegraph to configure them in the current state. OpenCtx has been quite valuable already here to our customers.
> In mathematics and computer science, an algorithm is a finite sequence of mathematically rigorous instructions, typically used to solve a class of specific problems or to perform a computation.
Looks good to me.
And did you just question "WHERE" and "ORDER BY" in SQL? I wouldn't do that. There are probably a ton of algorithms and optimizations done there. In my very naive understanding, quick sort is at least worth something.
Exactly. I would use the same logic and argue that it is not fair for CEOs flying in private jets when other workers commute in car traffic. If the day comes when Elon Musk, Andy Jassy and alike fly commercial, I wouldn't complain a word about going to office five days a week.
Well, I wouldn't. Teleportation wouldn't even be necessary in my case as it takes 5 minutes for me to get to my office. I just don't see any point in being in office on days when I am focusing on writing code to push features out.
Anecdotally, I find these are the same people who work less effectively and efficiently. At my company, I know people who mainly use Notepad++ for editing code when VSCode (or another IDE) is readily available, who use print over debuggers, who don't get frustrated by runtime errors that could be caught in IDEs, and who opt out of using coding assistants. I happen to know as a matter of fact that the person who codes in Notepad++ frequently has trivial errors, and generally these people don't push code out as fast they could.
And they don't care to change the way they work even after seeing the alternatives and knowing they are objectively more efficient.
I am not their managers, so I say to myself "this is none of my business" and move on. I do feel pity for them.