I’m probably going to be downvoted for this but this thread doesn’t really reflect well on the promises of Generative AI and particularly the constantly reiterated assurance that we’re on the verge of a new industrial Revolution.

Agreed. Many of the suggestions are pretty much code it yourself, but without actually tapping the individual keys.

Furthermore, and more generally, one of the great things about (traditional) coding is that it allows 'thinking through making' - by building something you learn more about the problem and thus how best to solve it. Code generation just leaves you with reviewing, which is less powerful in this way I believe. See also 'thinking through writing [prose]'.

I said it since the very first video of somebody who built a login page with it. They kept adding more and more constraints and at some point it's just coding but with extra steps.

It doesn't mean those tools do not have value though but they're not capable of "coding ", in the sense we mean in the industry, and generating code isn't coding.

I'm feeling the same way. It's quite the contrast from all the hype posts that make it sound like you give the AI a rough idea of what you're looking for and then it will build it from start to finish on its own.

Yes. I’m trying it, it’s too early for me to state a conclusion, but it’s not clear what the point is of an interface that requires magic touch best described as je ne sais quoi.

The alternative to this isn’t even necessarily no AI, just not using it this way.

I don't think the OP gave enough information for us to really have any honest conversation about this one way or the other.

That said: I suspect that OP is providing low-detail prompts.

These tools cannot read your mind. If you provide an under-specified prompt, they will fill in all the details for things that are necessary to complete the task, but that you didn't provide. This is how you end up with slop.

This looks like a solution in search of a problem already solved by SQLite

I think the problems with sqlite:

- sqlite can't do concurrent writes, which is a performance bottleneck for certain workflows

- sqlite is synchronous, which isn't ideal in applications that are async

- while sqlite itself is open source, the test suite is proprietary, which means forking it and adding your own features or bug fixes isn't really practical. Of course, that is also a significant barrier to turso having sqlite compatibility.

Does turso really solve those problems? IDK. Does it introduce new problems? Almost certainly. But those are real problems that people have.

Proprietary? Are you referring to the test suite they created for avionics that last I checked they've never really sold? I think it's highly misleading to make that claim if so.

I thought most of the test cases were proprietary, but it looks like you are right and it actually is just the TH3 test suite, and the fuzzer.

I’m not entirely sure this is the silver lining you seem to think it is

I would be interested in hearing a plausible scenario of how a large scale voting machines hack could potentially happen

This looks super useful, but I was wondering if I'm the only one bothered by this recent trend of overloading completely unrelated operators (here the `/` operator) in the name of legibility.

I do agree overloading / is an odd choice in this instance, but it’s a shame “is” can’t be overloaded! Realistically wat(foo) would be fine though.

I had an adjacent idea a few weeks ago, but centered more around the idea that it may be difficult for new open-source contributors to find appropriate issues to work on. Suggesting and allowing to discover interesting issues across multiple repositories would allow the prospective user to get a nice view of what interesting issues are available to make a first / second / third contribution to a project, and possibly to also track contributions / pull requests etc.

Seems to have been layoffs at Mozilla today

This is such a great, simple, almost obvious idea. This type of ideas is getting more and more rare, so it is great to see one popping here and there.

Granted, this article is 15 years old but it is interesting to find that the landscape seems not to have changed much. I was wondering how much domain logic a modern application should put at the database layer.

This is an interesting article. Native Apps deployment constraints seem so different than a typical web continuous deployment process.

As an aside, here's a look at Etsy's Continuous deployment process: https://www.slideshare.net/mrtazz/development-deployment-and...