adrianmonk
This was a funny sentence to read. I'm reading this article to kill time while, in another window, I'm on a chat with customer service for my credit card because my credit card stopped working in my digital wallet. I've been trying to resolve the issue for weeks.
So I'm glad my car doesn't require anything like that.
If it were built-in, you could even minimize the wasted ink and paper. Just print a single line every few days or something and keep the same sheet of paper in place for weeks or months and add to it instead of using a new sheet of paper. The ink has plenty of time to dry, so you can probably print over the same areas repeatedly.
Alternatively, you could implement it in the driver, but there's more opportunity for things to go wrong if you restart the computer, lose the connection, or have multiple computers sharing a printer.
Basically, there are often different ways of putting a particular idea into words. Sometimes the longer way might be clearer, and the shorter way might be more confusing. If you care about being understood, sometimes you will use the wordy option. This is what humans usually do.
However, LLMs have context windows. All else being equal, verbosity eats up more context. If the LLM is trained (with reinforcement learning) to reason most effectively, it can do that by using terse phrasing. Especially on certain tasks that really need a large context window. Why? Because being terse is like getting a larger context window for free.
But in another sense, it's not really free. You're trading off clarity for context window. Sometimes you have to choose between verbose+clear and terse+unclear. If you're biased toward terse, that will also shift you toward unclear.
I do agree that LLMs are verbose sometimes, though. I think they are also trained to please the user, and they see sharing extra knowledge and insights as a way to do that. I don't think this idea is in conflict with what the paper says. If an LLM's training rewards both spitting out neat bonus info and doing reasoning that requires making the most of its limited context window, then that LLM may generate a large quantity of text which is written in a slightly terse and confusing style.
That claim was ever made. The comment was about actual pieces of software that exist in the real world, not about all possible software that could exist in theory.
In real-world usage, for a user to be exposed, a necessary ingredient was to use a particular piece of software that actually exists and that happens to be vibe coded.
That does not preclude the possibility that a non-vibe-coded piece of software could have been vulnerable. It's just that such a piece of software did not happen to exist.
So why even mention vibe coding? Presumably it's relevant for some other reason. Perhaps the implication is this vibe-coded software is not an established piece of software with lots of users. (Since vibe-coded software is easier to create, maintainers may be less invested in it or committed to maintaining it. Vibe coding changes the economics and opens up the possibility of creating throwaway software.) Or perhaps the implication is that users should be more careful about using vibe-coded software.
That's part of the premise of the movie "The History of Future Folk".
Why did the label on my Fig Newtons get redesigned? It's not because it lacked in usability. It's because the company knows that customers respond to visual updates. If something looks the same year after year, lots of people will see it as old and tired. A redesign makes it feel modern and fresh. At least to enough people that it matters.
I had the same experience on a recent trip to The UPS Store. The color scheme was all different from the previous time I shipped a package. I commented to the clerk that they'd redecorated. He said they do it pretty often.
Software has a visual aspect to it, and the same forces are in effect. Part of a UI designer's job is to be on that treadmill. That's probably not what the job should be, but the people who pay their salary want it to be.
I guessed wrong. I still like my idea, but their solution is simpler and probably more efficient and more durable too.
My local transit agency just stopped allowing rear door boarding, and that was one of the main reasons: https://waypointblog.com/capmetro-is-ending-rear-door-boardi...
Each phrase or sentence is an operation that changes the state. The state is the mind of the reader. For it to work, you have to understand the starting state, and then construct a valid sequence that modifies the state step by step until it reaches the desired state. Every step has preconditions and postconditions. You can't leave important values uninitialized. You can't refer to symbols that haven't been defined. You can't just sit down and blurt out whatever comes to mind; you have to "play computer" (or "play reader") in your head to model the effects of what you're writing. You need to be aware of which "platform" you're targeting (developers, users) and understand quirks of each variation of that platform. Some of your operations might fail, and you may need a way to detect and/or recover.
Obviously don't take it too far and reduce writing to this. But I think it's helpful for getting into a mindset where you are thinking about communication in an end-to-end, closed-loop way. Your mind needs to be engaged and stay engaged with the question of what the experience is like for the reader. It's very easy to default to an open-loop mode where you just have a random string of thoughts about the subject, let your brain translate them into words, write that down, and call it done. There's a big difference between expressing thoughts and communicating ideas effectively.
Thinking about it this way could also maybe help with motivation. It's satisfying to write computer code and really nail it and have it do its job effectively, right? You can get a similar feeling of satisfaction from good writing.
This doesn't totally automate it, but it takes away the need to manage the proceeds from a reverse mortgage between the time you receive a payout and the time you pay your taxes.
But people are definitely going to assume "eXtra Large". Lots of people. I guess a few will think "excel" (as in JPEG XL comes out ahead and is superior).
---
This isn't about the Apple Card. It's about an iOS app called "Cards" which lets you physically mail personal cards straight from your iPhone.
The current situation with AI is that everyone is going as fast as possible. So, we can logically eliminate speeding up because it's impossible by definition. And we can practically eliminate staying the same speed because why make a big fanfare and coin a special term to announce that you're keeping the status quo. By process of elimination, it must mean slowing down.
It's very hard to understand. It doesn't make sense that a criticism of the camera would be an insult to the subjects of the photo.
The criticism is that the image isn't an accurate representation of the subjects. If B is bad, and B != A, it doesn't follow that A is bad.
It creates a new chat which has the conversation up to that point and a link to the conversation you branched it from.
The UI isn't tree-like, though. It's more like Git where each branch name is just mixed in with the rest of the soup of references.
So even on a 56k modem, it might take less than 1 second to load each image.
You could also optimize it so it skips intermediate images if the user types fast. Suppose the user mashes "12345" in a fraction of a second. You start loading "1.jpg" on the first keypress. When you've finished loading "1.jpg", the field contains "12345", so skip straight to loading "12345.jpg".
The demo page's JS doesn't seem to include any optimization code like that. It just updates the img src whenever the text changes. Yet my browser seems to do it automatically! If I mash several keys, the console network log shows only some intermediate images get loaded.
I guess the browser is smart enough to know that, by the time it would have started the download, the resource no longer exists in the page. I'm not sure if browsers ~20 years ago did this, but it would have been worthwhile given how slow networks were.
Practically speaking, I might just allocate an array of 100 pointers. That's only 400 bytes. Then as you encounter each filename, allocate just enough memory for the actual length of the string (plus null terminator) and store the pointer in the array.
OK, but isn't the kernel keeping the directory listing in the disk cache? Won't that prevent extra physical I/O if you do just read the directory twice?
If so, then in the second pass, it's all cache hits, and you're just paying the cost of calling into the file system. Hopefully that's pretty fast. But even if not, it's still absolutely dwarfed by the physical I/O required for the first pass. Windows XP era storage was spinning hard drives, not flash.
And if not, then I'm probably going to put my user icon coding task on the back burner and go ask the kernel team why a seemingly very common usage pattern isn't optimized.
(I realize he's not claiming the performance benefit was significant. I'm just trying to see it in the right perspective.)