In theory I would expect them to be able to ingest the corpus of the new yorker and turn it into a template with sub-templates, and then be able to rehydrate those templates.
The harder part seems to be synthesizing new connection from two adjacent ideas. They like to take x and y and create x+y instead of x+y+z.
Most of the good major models are already very capable of changing their writing style.
Just give them the right writing prompt. "You are a writer for the Economist, you need to write in the house style, following the house style rules, writing for print, with no emoji .." etc etc.
The large models have already ingested plenty of New Yorker, NYT, The Times, FT, The Economist etc articles, you just need to get them away from their system prompt quirks.
I think that should be true, but doesn't hold up in practice.
I work with a good editor from a respected political outlet. I've tried hard to get current models to match his style: filling the context with previous stories, classic style guides and endless references to Strunk & White. The LLM always ends up writing something filtered through tropes, so I inevitably have to edit quite heavily, before my editor takes another pass.
It feels like LLMs have a layperson's view of writing and editing. They believe it's about tweaking sentence structure or switching in a synonym, rather than thinking hard about what you want to say, and what is worth saying.
I also don't think LLMs' writing capabilities have improved much over the last year or so, whereas coding has come on leaps and bounds. Given that good writing is a matter of taste which is beyond the direct expertise of most AI researchers (unlike coding), I doubt they'll improve much in the near future.
Someone here mentioned a whole ago that the labs deliberately haven't tried to train these characteristics out of their models, because leaving them in makes it easier to identify, and therefore exclude, LLM-generated text from their training corpus.
But it's odd that these characteristics are the same across models from different labs. I find it hard to believe that researchers across competing companies are coordinating on something like that.
im actually getting so tilted that people can't just be forthcoming about when they used AI to write something. 99% of readme.mds i run into now on github piss me off. out of all the things people could cede to automation, they foolishly went and self-owned their ability to communicate. smfh.
if you've worked on something diligently and understand it and have novel insight to share, let's hear _your_ damn voice.
yeah I don't hate LLM docs if they're labeled as such. but if someone wants me to use their code or read their README.md they are going to have to make it sound like a human cared about writing it, and right now Claude can't do that
What exactly is making you shudder - the writing style, or the fact that AI was used at all? Because if it's the latter, just so you know, you're going to be shuddering for the rest of your life.
Couldn’t it just as easily be equivalent to saying “you grew this year, so contribute some money back to society for enabling you to have the educated hiring base/financial infrastructure/physical infrastructure that enabled you to grow”?
Like, sure, you don’t owe growth taxes for a quarter when you didn’t grow. But why should you be refunded just because prior taxable growth isn’t denominated in money in a bank account?
> you grew this year, so contribute some money back to society for enabling you to have the educated hiring base/financial infrastructure/physical infrastructure that enabled you to grow
Apparently paying for gas, water, electricity, property taxes, taxes on everything you buy isn’t enough, now you have to “contribute for enabling”. What’s next? Pay because they “enable you to breathe”?
Postgres is simpler. Get your cloud to manage it. Click to create instance, get failover with zero setup. Click button 2 to get guaranteed backups and snapshot point in time.
I would argue it is not resilient enough for a web app.
No one wrote the rules in stone, but I assume server side you want the host to manage data recovery and availability. Client side it is the laptop owners problem. On a laptop, availability is almost entirely correlated with "has power source" and "works" and data recovery "made a backup somehow".
I was especially thinking about a program running on a server. I wouldn't statically link everything for a desktop program, because it just causes incompatibilities left-and-right. But for a server, you don't have external vendors, so this is a good option, and if you use SQLite as the database, then this means that deploying is not more complicated than uploading a single executable and this is also something, that can be done atomically.
I don't see how this has worse effects on recovery and availability. The data is still in a separate file, that you can backup and the modification still happens through a database layer which handles atomic transactions and file system interaction. The availability is also not worse, unless you would have hot code reloading without SQLite, which seems like an orthogonal issue.
Don't agree. Getting managed postgress from one of the myriad providers is not much harder than using sqlite, but postgress is more flexible and future proof.
I use Postgres for pretty much everything once I get beyond "text in a database with a foreign key to a couple of things".
Why?
Because in 1999 when I started using PHP3 to write websites, I couldn't get MySQL to work properly and Postgres was harder but had better documentation.
It's ridiculous spinning up something as "industrial strength" as Postgres for a daft wee blog, just as ridiculous as using a 500bhp Scania V8 for your lawnmower.
Now if you'll excuse me, I have to go and spend ten seconds cutting my lawn.
You always get a comment like this. I don't particularly agree. There are pros and cons to either approach
The tooling in a lot of languages and frameworks expects you to use an ORM, so a lot of the time you will have to put up a fair bit of upfront effort to just use Raw SQL (especially in .NET land).
On top of that ORM makes a lot of things that are super tedious like mapping to models extremely easy. The performance gains of writing SQL is very minor if the ORM is good.
This. So much this. Of course, at one point you start wanting to do queues, and concurrent jobs, and not even WAL mode and a single writer approach can cut it, but if you've reached that point then usually you a) are in that "this is a good problem to have" scalability curve, and b) you can just switch to Postgres.
I've built pretty scalable things using nothing but Python, Celery and Postgres (that usually started as asyncio queues and sqlite).
Yeah, we run a fairly busy systems on sqlite + litestream. It's not a big deal if they ae down for a bit (never happened though) so they don't need failover and we never had issues (after some sqlite pragma and BUSY code tweaking). Vastly simpler than running + maintaining postgres/mysql. Of course, everything has it's place and we run those too, but just saying that not many people/companies need them really. (Also considering that we see system which DO have postgres/mysql/oracle/mssql set up in HA and still go down for hours do a day per year anyway so what's it all good for).
I rebuild from HEAD using homebrew quite regularly and have maybe had a single crash in years using Helix, so I'm shocked to see Julia report she's had crashes.
But because I run HEAD, I can tell you what's actually merged which might not be released yet:
> Code actions on save
There are command on save hooks which solve the problem for Go, but I could see this being not as applicable for other languages.
> Fuzzy search
Man, I'm pretty sure this shipped before telescope was particular stable or popular. Although, I don't recall if Helix originally used the ripgrep backend at first. They reworked it earlier this year and it was a massive improvement.
> Automatically updating buffers
+1 to this. I constantly suspend (ctrl+z) my editor and sometimes forget about it and could really use this prompt.
> File tree in browser
Space+e or Space+E opens a hierarchical file explorer on HEAD, but this is definitely relatively new
Totally disagree. I find having both extremely useful. Once I start to get to know a code base jumping through files with telescope is super useful. But when I'm getting spun up on a project and don't know what files I'm looking for, a file tree is super nice.
> I tried to switch from neovim to helix for a couple weeks
I bounced off after a couple of hours because 35 years of muscle memory for vim commands meant I was making constant infuriating mistakes[0]. Which is a shame because I'd really like to use helix and avoid the neovim config faff.
[0] I did try one of the "vim keybindings for helix" but they were only partially correct and that annoyed me even more.
I have the same issue with Helix not watching and reloading modified files automatically, as I sometimes run external programs modifying those files (templ and sqlc are good examples). Curious about how experienced Helix users are addressing this.
[keys.normal.space.f]
f = "file_picker_in_current_directory"
F = "file_picker"
b = "file_picker_in_current_buffer_directory"
"." = ":toggle-option file-picker.git-ignore"
g = "global_search"
e = "file_explorer"
r = ":reload-all"
x = ":reset-diff-change"
w = ":echo %sh{git blame -L %{cursor_line},+1 %{buffer_name}}"
>No reasoning. No capability. Just exploitation of how the score is computed.
shudder
reply