mkleczek

I was more asking to assess the actual gain.

So the question really is: in your experience how much code requires careful review and re-prompting vs leaving it as "not terrible".

Asking because my experience is that in practice LLMs are no better than juniors - ie. it is more effective to just write the thing by myself instead of multiple rounds of reviewing and re-prompting which does not really achieve what I really want.

What is the measured LoC ratio of well-curated to "slop" code?

Looks like we all have to start believing unbelievable: agent Krasnov is real and the tip of an iceberg. Honestly I can't see any other rational explanation of what's happening.

I found https://github.com/cosmos72/schemesh lately and - once you accept LISPism - is pretty nice to use.

Which is evidenced everyday when optimizing database performance by creating indexes /s

There is a fine line between democratic leadership and authoritarianism.

Public consultations and transparency are two crucial and lately very under appreciated parts of democracy.

If a leader cheats the voters it is no longer democracy.

There are two issues with this thinking:

1. It is authoritarian. Democratically elected leader's duty is to present the policies he plans to implement so that voters can decide if they want them implemented.

2. It is based on the "4D chess" myth - that the leader is way smarter than the rest and is capable of outsmarting other countries. The history shows that it is never true. The leaders are normal people. And the institutions are as good as the founding principles that are honored by them.

Function is really a tiny issue comparing to serving static assets (ie. a fronted application) by deploying them as a dedicated Nginx microservice with a couple of files copied to the container image :)

I've had a short discussion with Brian Goetz about a similar case (sealed types in Java): https://mail.openjdk.org/pipermail/amber-dev/2020-April/0058...

I wonder when we are going to re-discover OOP style dynamic dispatch (or even better: multiple dispatch) to deal with software evolution.

> In .NET and Java it costs at least 100x as much time to throw an exceptions as to return an error code.

Don't know about .NET but in Java it is not throwing exceptions that is heavy but filling in stack trace during construction of a Throwable. It can be made much more performant using constructor that disables stack trace: https://docs.oracle.com/en/java/javase/21/docs/api/java.base...

One nitpick. We do have an Open Source SQL implementation as good as commercial ones: PostgreSQL.

I wonder why they didn't use synchronous_commit option. That would eliminate replication lag and allow for real zero-downtime.

Ahh so the difference is in a definition of supply.

You say drilling more oil is something different than building more efficient cars.

I would say in both cases supply of oil increased so there is no real difference.

I fail to see a difference. In both cases demand increased, no?

I use the architecture you described as the go-to architecture for most of so called "business" applications (with PostgreSQL as dbms though).

The missing pieces are:

- incremental materialized view maintenance

- (bi)temporal primary and foreign keys (upcoming in Pg18)

Lately I found out about DBSP and Feldera which looks very promising as it is based on sound theory: https://github.com/feldera/feldera?tab=readme-ov-file#-theor...

Do you have empirical proof any LLM can generate another program that can be trained to simulate it? Otherwise it is science fiction.

The brain can invent formal language that enables unambiguously specifying an algorithm that when provided with a huge amount of input data can simulate the output of the brain itself.

Can these models do that?

> This is why I created an abomination that uses go/ast and friends to generate the OpenAPI spec from the code.

This is against "interface first" principle and couples clients of your API to its implementation.

That might be OK if the only consumer of the API is your own application as in that case API is really just an internal implementation detail. But even then - once you have to support multiple versions of your own client it becomes difficult not to break them.

If that was the case people wouldn't use LLMs to generate long text only to use the same LLMs to generate short summaries of it.

What I am saying is not that good writing is useless - rather that good writing is _hard_ and people are lazy. There is way more bad writing than good in the world. Bad writing will be replaced by LLMs which does not make sense because it is still bad - and useless.

Good writing is going to stay but since it is hard it is (still) going to be rare.

In the end my hope is that bad (and useless) writing is going to be replaced by short, dense and useful format.

Of course - this begs the question: what constitutes good writing? Pretty good estimation is that a good writing is the one that is - generally speaking - as information dense as possible (ie. there is nothing you can take away from it without loosing some important information). And we are back to square one - it does not make sense to write anything longer than necessary :)

I wasn't clear enough and I agree: art cannot be replaced by LLM (although this is heavy disputed by AI believers). Consuming art also precludes reading summaries generated by LLMs.

My comment was about "utility" texts (this is a context of this discussion, I suppose) - my prediction is that we are going to write shorter and more condensed texts to avoid overhead of LLMs use in generating and summarising text.

I meant evolution of writing.

In the age of LLMs there is no point in writing long prose. The more content is generated the more people will move to higher information density formats. Why bother with generating long text if the reader is going to summarise it with a LLM anyway? OTOH - citing Ben Affleck: "why would I bother to read something you didn't bother to write?"

This is a false alternative:

The fact that there are situations when implementing referential integrity is difficult does not mean you shouldn’t do it at all.

Secondly: relational model is based on logical-physical independence. Referential integrity is specified at the logical level and does not dictate any particular implementation. OTOH violating 1NF makes it impossible to even specify RI constraints.

NoSQL databases do not implement RI exactly because it is not possible to even specify it due to the lack of formal data model. And that’s not their strength but one of the many weaknesses.

The story about optimising Oracle performance by giving up data integrity is only an illustration of why you should not use Oracle :) Just use Postgres.

There is no problem with RI in Postgres as long as you remember to have an index on FK columns. Using CTEs allows you to perform data manipulation in a single statement with constraints enforced at the very end.

Similarily: giving up data integrity due to microservice architecture cargo cult is… tail wagging the dog.

It would take a really long time to count all the issues caused by dangling references to nonexistent rows I had to deal with in my career.

So yes - classical enforced FKs are still important - even if practice became „modern” (whatever that means )

That’s a very simplistic view.

For once: you _always_ have to deal with memory hierarchy as there is no way to fit all data to the fastest memory. So you need to design with this in mind.

Secondly: the point of databases is not to implement a single specific task efficiently but:

a) provide means to maintain data so that it is easy to implement many different tasks (both current and future)

b) to safely _share_ data between various tasks/programs/users

There are several issues with this:

1. 4NF is dependent on context. This context is described as dependencies.

In the example of employees, skills and languages the design with two separate "link tables" employee_skills and employee_language is not obvious at all without specifying requirements _first_. If there is a requirement that an employee skill depends on the language (ie. an employee can type in a particular language only) - the design with a single 3 attributes table is the right one.

2. Multivalued attributes discussion is missing several important aspects for example referential integrity. It is not at all obvious what should happen when a language is deleted from languages table. Once you start adding rules and language to specify referential integrity for multivalued attributes you very quickly end up with... splitting multivalued attributes into separate relations.

A very inspiring series on data driven approach to management discusses this: https://commoncog.com/goodharts-law-not-useful/

The point is: art is a means of communicating _between people_. We can appreciate pictures/movies/music generated by machines but at the end of the day we (people) are in a deep need of connection to _other people_.

I don't believe replacing people with machines in this context is possible (one might say: by definition). But if it happens it will be the anti-utopian world of loneliness.

> The answer seems obvious: because it's better.

Define "better".

The point really is that "better" in this context means "made by a human" - not "faked to look like made by a human". People need connection to other people - art is one of the means of communicating _between people_.

"Concepts, Techniques, and Models of Computer Programming" by Peter Van Roy and Seif Haridi is my favourite.