Even Google itself is now just asking AI. Usually the AI summary Google returns is more useful than the links. I get really annoyed when I query something and no AI summary is given as the links it returns these days are trash.
It’s interesting that people claimed the exact same thing when computers were being introduced to the work place int the 80s and 90s. Lots of papers showing how productivity didn’t go up at all and using a paper and pen seems to be just as efficient as using a PC.
Even in the 19th century, when electricity became widely available, there was no productivity gain for 30 years at least. This is a well understood phenomenon.
Ah you must be referring to this off the cuff comment by Robert Solow in a book review: "You can see the computer age everywhere but in the productivity statistics" (1987)
It's an interesting question and very much not resolved. It indeed led to a flurry of studies in the 1990s, and more recently to several updates and meta-analyses.
The problem of "does computer technology investment causes increased productivity" is an interesting issue in economics and statistics. It is far from clear that the (immense) investment in computers over the past several decades has caused a corresponding excess growth in productivity.
Some of the literature published after 2015 that I have read on this topic:
"Information technology (IT) productivity paradox in the 21st century"
> Thus we are still unable to confirm or reject the existence of an IT
productivity paradox
"Benchmarking the IT productivity paradox: Recent evidence from the manufacturing sector"
(This one was published in 2006 but I find it relevant because it does a very well scoped analysis in manufacturing firms thus addressing the oft-mentioned argument that computer technology may leverage task productivity in a way that is hard to measure in aggregate)
> However, many scholars from both sides of the IT paradox debate agree that difficulty still exists in specifying how to assess the IT contribution, and the availability of reliable data sets
> Regardless of the final decision to differentiate or conform, our results make a compelling argument that more spending does not necessarily mean better IT productivity.
"Lessons from three decades of IT productivity research: towards a better understanding of IT‑induced productivity effects"
(This is one of the most inclined to disagree with the existence of the paradox, and still very cautious in the language used for writing the conclusion, e.g.:)
> But to not at least consider the ongoing technological change as an important determinant of the deceleration in productivity growth seems ill-advised."
(This I'm quoting from the submitted manuscript. I haven't gotten around to reading the published version yet, but:)
> Since the size of the effect helps make the right decision in business-related investments, our result of ICT elasticity being very close to zero with values, about 0.3% for productivity and no effect on profitability, supports the argument that there are better forms of investment to be made
Without tools LLMs can do nothing more than emit text. You are probably assuming a harness is provided to the LLM with shell access but that is absolutely not necessary for LLM usage depending on the use case. For interesting stuff, you do want to provide some tools, but nothing with the power of a terminal if you are worried about security. A MCP server is perfect to securely provide the LLM with some controlled power exactly because it can do nothing at all other than call tools that go through the MCP server and can therefore be scrutinized, audited and ensure credentials are not visible to the LLM.
They have a UI which is pretty good! That explains why JS , they can run that in Electron and in TUI. I only use the UI now since it is do damn useful with its management of worktrees and multiple sessions, including ones running remotely via ssh devcontainers.
I would think that with agentic coding they’d be able to have a shared core and an interface native to the system, I.e. not react in the terminal and a swift or C# front end for the desktop app
They have a feature where they open a browser right in the app for Claude to use! They also use browser rendering for displaying various graphical formats. For once an Electron app that can actually justify shipping a whole browser in it.
Bob also knows how to quickly check things with a little bash scripting and tests. Can quickly switch branches to confirm regressions and consult documentation if something requires more information. His twin can also quickly scan for all the common security vulnerabilities in any code, and will do it without complaining as many times as you want him to.
I’ve come to trust Bob with code more than any human.
Yep! We run security reviews on our pull requests now and are shocked at how it stops a lot of vulnerabilities being shipped. We've had a couple of high score CVEs from the before-LLM times, and when the AI reviews the code that introduced the CVEs, it easily picks them up. We had 2 humans reviewing every PR, and both missed the issues. It's far too easy to miss security issues when you manually review them, but LLMs are exceptionally good at finding them. Unfortunately for me, I admit, I just can't get myself to push code anymore without an LLM checking my work (or writing much of it when I'm at work, I try to write code by hand in my own time to make sure I don't rust away, but at work there's no way to justify doing it the "slow" way anymore).
You just misinterpreted what NSArray is. It’s not an immutable type, it’s a read-only type. As others already mentioned that’s different things. If you have a read-only variable and exclusive access to it, then you can rely on immutability as well. This is what Rust has, for example. Many languages use this definition as well as it’s much more useful than having some sort of pure immutable type guarantee (which some languages do have with const).
Another language that uses this is Kotlin: List is a read-only type. MutableList is a subtype of List. You can get a “const” List by only keeping a reference to the value via a List binding. This can be worked around via casting and reflection, but even in Haskell you can do unsafe things that mutate a immutable value, so I don’t think that undermines the idea.
> I've been doing low-level programming professionally for 25 years
You haven't been doing any Rust though. You seem to think you can extrapolate your C++ experience to Rust. That's preposterous. The actual Rust programmers can't recognize this theoretical problem in their Rust programs.
It's not theoretical, it's one of the main reasons many large applications abandoned C++, and there's absolutely no reason for it to not exist in Rust. All low-level languages suffer from expensive evolution for fundamental reasons - the reliance on an AOT compiler and the lack of movable pointers impose serious performance tradeoffs in large programs. Optimising JITs and moving GCs were invented, in large part, to address this very real problem, familiar to many low-level programmers who have maintained large codebases for a long time. It's also why large runtimes like TCMalloc were invented to assist as much as they can.
Most actual Rust programmers haven't maintained a large Rust program for a long time. Now, don't get me wrong - there are many C++ programmers who are fine with it, but many who aren't. What I find annoying is people without much experience in Rust assuming that everyone or almost everyone should like it, even though that's never been true for any language. I'm not saying Rust is bad by any means; in fact, I think it's better than C++ in a few ways. I'm explaining why I don't like it.
Could that be because the language is fairly young? You don't see the "20-year-old legacy system" in Rust because it doesn't exist yet ;)
And if you look at other comments in this thread, many engineers have this mentality of "just use a crate, it's probably optimised already". They might not have performance problems immediately or obviously but it's more like ten thousand papercuts - a few allocations here and there, a few extra copies here and there and you've got a way slower program than it should have been.
Well, the problems don't start after 20 years but after 5 or so (depending on the size of the codebase and the rate of the application's evolution), and the reason there aren't many large and oldish Rust codebases isn't because the language is too young for that (work on it began twenty years ago, and it's been stable for over a decade); that's middle-aged for a programming language. When C++ was of a similar age, there were thousands of >1MLOC programs written in it. One reason is obviously because when C++ was of the same age, there weren't as many suitable high-level alternatives, and people just don't pick a low-level language for most large applications anymore. But most Rust fans at least on social media, have not actually had much experience with it or with low-level programming in general; I'm guessing most haven't worked on Rust projects with more than 10 full-time people on them (this isn't normal in the industry, BTW, as a lot of software lives in large programs). And again, there are people who can certainly live with these issues, but they are real, and many certainly find them troubling.
reply