almost

It's weird how the author writes about all the antisocial and illegal things like they're not responsible for them. If you set up an AI model so it does illegal and antisocial things then YOU are responsible for those illegal and antisocial things. YOU spammed a bunch of strangers. YOU did unsolicited invoice fraud.

LLMs are really good when your primary goal is just to fob people off. So customer support when you don't care about your customers etc. I can imagine it's very appealing when you just want to come up with semi-plausable reasons to deny insurance claims. Who cares if it's wrong? They might give up anyway and you've saved paying out!

Not saying they're not good for other things, but the "waste people's time and make them go away" use is just so perfect for the capabilities of even cheap models.

This is so important. I've been using Django for around 20 years and my current code base is 10 years old. Not having to do major rewrites or stick on outdated versions really matters.

It's probably worth being up front about what your do syntax actually does. A generator is not as general as "do", Python doesn't have call/cc or anything like that. I checked and you (or Claude I guess) do it by rerunning the whole thing each time for things like the list monad which is not something I think anyone would want for anything more than a toy.

Father of the web sure. But HTTP is not the Internet!

Also what I got. Then I tried changing "wash" to "repair" and "car wash" to "garage" and it's back to walking.

For me Northflank have filled this spot. Though by the time I switched I was already using Docker so can't speak directly to their Heroku Buildpack support.

I've been incredibly happy with Northflank since moving over a few years ago after Heroku got unreliable. Felt like an upgrade from Heroku and the support and reliability have been great.

The reason you heard that was probably because they were talking about a more specific circumstance. For example SQLite is often used as a database during development in Django projects but not usually in production (there are exceptions of course!). So you may have read when setting up Django, or a similar thing, that the SQLite option wasn't meant for production because usually you'd use a database like Postgres for that. Absolutely doesn't mean that SQLite isn't used in production, it's just used for different things.

From my experience though I often do make logical errors in my code but not in my tests and I do frequently catch errors because of this. I think thats a fairly normal experience with writing automated tests.

Would having someone else write the tests catch more logical errors? Very possibly, I haven't tried it but that sounds reasonable. It also does seem like that (and the other things it implies) would be a pretty extreme change in the speed of development. I can see it being worth it in some situations but honestly I don't see it as something practical for many types of projects.

What I don't understand is saying "well we can't do the really extremely hard version so let's not do the fairly easy version" which is how I took you original comment.

This sounds very "the perfect is the enemy of good". Tests don't need to be perfect, they don't need to be written by different people (!!!), they don't need to cover 100% of the code. As long as they're not flakey (tests which fail randomly really can he worse than nothing) it really helps in development and maintenence to have some tests. It's really nice when the (frequent) mistakes I make show up on my machine or on the CI server rather than in production, and my (very imperfect, not 100% "done properly") tests account for a lot of those catches.

Obviously pragmatism is always important and no advice applies to 100% of features/projects/people/companies. Sometimes the test is more trouble to write than it's worth and TDD never worked for me with the exception of specific types of work (good when writing parsers I find!).

When it's a library it's fairly important what it's written (or at least written for)

For something this simple that doesn't need to grow or interact with the rest of the system why would you need Backbone or React? And why would you expect any version to be shorter as it's mostly just the HTML and the data.

I remember writing Backbone applications with lots of deeply nested components. Trying to keep all the state in sync and reacting to events. It certainly wasn't simple and straightforward.

This just feels like a very silly article.