mkleczek

Well, increasing temperature (ie. adding some more randomness) for sure is going to magically generate a solution the customer wants. Right? /s

And what do you do with the generated code?

Do you package it in a reusable library so that you don't have to do the same prompting again?

Or rather - just because it is so easy to do - you don't bother?

If that's the later - that's exactly the pattern I am talking about.

It is a self-reinforcing pattern: the easier it is to generate code, the more code is generated. The more code is generated, the bigger the cost of maintenance is (and the relationship is super-linear).

So every time we generate the same boilerplate we really do copy/paste adding to maintenance costs.

We are amazed looking at the code generation capabilities of LLMs forgetting the goal is to have less code - not more.

> The total IQ on the planet remains constant even as the number of people increase

IQ, (from “intelligence quotient”), is a number used to express the relative intelligence of a person.

So for the whole population it is constant by definition :)

This is as long as you don't take _risk_ into account.

RedHat providing OSS licensed software is _less_ risk than RedHat providing proprietary closed source operating system.

I agree. See also my comment in a sibling thread about using LLMs to write tests: https://news.ycombinator.com/item?id=41961214

> I'm hopeful that LLMs can provide guidance in removing useless tests or simplifying things. In an ideal future they may even help in formulating requirements or design documentation

I am very sceptical here as well. The biggest problem with formulating requirements or design documentation is translation from informal to formal language. In other words... writing programs.

LLMs are good at generating content that doesn't provide useful information (ie. have low information content). Their usefulness right now is caused by the fact that people are used to reading lot of text and distill information from it (ie. all the useless e-mails formulated in corporate language, all multi-page requirement documents formulated in human readable form). The job of a software engineer is to extract information from low information content text and write it down in a formal language.

In this context:

What I expect in the long run is that people will start to value high information content and concise text. And obviously - it cannot be generated by any LLM, because LLM cannot provide any information by itself. There is really no point in: provide short high information content text (ie. prompt) to LLM -> receive long low information content text from LLM -> extract information from long text.

How can people (either individuals or groups) assess (or even define) achieving goals without SOME metric?

That's exactly my point :)

I am very sceptical of LLM (or any AI) code generation usefulness and it does not really have anything to do with AI itself.

In the past I've been involved in several projects deeply using MDA (Model Driven Architecture) techniques which used various code generation methods to develop software. One of the main obstacles was the problem of maintaining the generated code.

IOW: how should we treat generated code?

If we treat it in the same way as code produced by humans (ie. we maintain it) then the maintenance cost grows (super-linearly) with the amount of code we generate. To make matters worse for LLM: since the code it generates is buggy it means we have more buggy code to maintain. Code review is not the answer because code review power in finding bugs is very weak.

This is unlike compilers (that also generate code) because we don't maintain code generated by compilers - we regenerate it anytime we need.

The fundamental issue is: for a given set of requirements the goal is to produce less code, not more. _Any_ code generation (however smart it might be) goes against this goal.

EDIT: typos

Not disputing anything you said but... The issue I see is that without notion of time it is difficult to talk about causality (I guess you could only talk about "entanglement"). It is actually difficult to talk about "events" at all - I guess you can only talk about "facts"?

The older I am (and I am at my 50s) the more I have this intuition that entropy is a fundamental force driving not only physical phenomena but also social interactions, economy etc.

Formalising this intuition is another story though...

> Honestly? Because many things are too small to be worth paying a lawyer to write a letter to license violators

That’s a false alternative. You can chose copyleft license and not sue.

This is _especially_ useful for things I don’t plan to monetize. It allows free use but also protects the society from free riders.

Isn't it just a matter of choosing the license properly? To be honest, I find it contradictory:

On one hand OSS authors select permissive license exactly because they want big corps to use their software.

On the other hand - OSS authors are unhappy about big corps using their software in a way that license allows them to.

Just stick to GPLv3 / AGPL.

> You're not the best at everything, and you don't have to be.

As a 50 years old person that some time ago was one of these brightest in class I can say that for most of us, people, it is:

You're not the best at anything, and you don't have to be.

This single comment is the best illustration of why I should finally move to Nix. Thanks!

> However, that's strictly better than the natural PK situation, where you would need to not only add new columns to the key, but also add those columns to all referencing tables.

Foreign keys referencing surrogate key has different semantics than fk referencing natural key - it is a can of worms actually and can lead to unexpected anomalies.

Lets take the example from the article (with surrogate key):

Restaurant(id, name, city)

Now let's add a possibility to record visits:

Visit(restaurant_id references Restaurant(id), user, date)

We have a procedure to register visits to a restaurant:

register_visit(restaurant_name, user_name, date_of_visit) { INSERT INTO visit SELECT id, user_name, date_of_visit FROM restaurant WHERE name = restaurant_name }

I very much enjoy spending time in "Polish Kielbasa" restaurant in Warsaw and I visit it everyday - I don't visit any other restaurant at all.

Now changes of a restaurant name will lead to the database containing misinformation:

register_visit('Polish Kielbasa', 'mkleczek', 2024-6-4); update restaurant set name = 'Old Kielbasa' where name = 'Polish Kielbasa' and city = 'Warsaw'; insert into restaurant ('Polish Kielbasa', 'Warsaw'); register_visit('Polish Kielbasa', 'mkleczek', 2024-6-4);

Question: what restaurants did I visit this year?

This kind of anomalies are avoided using _natural_ keys and - first of all - defining proper _predicate_ for _each_ relation.

The predicate of relation visit(restaurant_name, city, user, date) is quite obvious: "User [user] visited restaurant [restaurant_name] in [city] on [date]"

Question: What is the predicate of relation visit(restaurant_id, user, date)?

The question is: if you have two restaurants having different scores but distinguishable only by their surrogate keys, how do you know which one to go to?

In other words - using surrogate key is an attempt (and the wrong one!) to fix the problem of missing important information in the database.

> The surrogate key uniquely identifies a row in your database, which is an entity just as real and significant as the car or the employee or what-have-you. Don't confuse the two!

But the DBMS already maintains a row identifier (called rowid or ctid or whatever depending on the DBMS). Why do you need an explicit one?

> Exposing the database itself is really just an example of a leaking implementation details.

This is a mistake that a lot of people make - treating database as an implementation detail. Relational model and relational calculus/algebra were invented for _sharing_ data (not storing). The relational model _is_ the interface. Access to data is abstracted away - swapping storage layer or introducing different indexes or even using foreign data wrappers is transparent to applications.

Security and access policies are defined not against API operations but against _data_ - because it is data that you want to protect regardless of what API is used to access it.

> To be clear, different services wouldn't operate on their own duplicated version of the same shared data, in their own database. They'd call a defined API to get that data from another service.

You mean synchronous calls? This actually leads to what industry calls "distributed spaghetti" and is the worst of both worlds.

> The whole point of this is to allow each service to define the interface for their data.

The point is that well defined relational database schema and SQL _is_ a very good interface for data. Wrapping it in JSON over HTTP is a step backwards.

It incurs huge costs though:

1. Costs of API maintenance - rigid APIs need constant change. To mitigate that people create APIs like GraphQL which is a reimplementation of SQL (ie. a query language).

2. Costs of data integration - (micro)systems owning databases need data synchronisation and duplication. What's worse - most of the times data synchronisation bypasses service APIs (using tools like CDC etc.) so all efforts to decouple services via APIs are moot.

A single data platform (a database) with well governed structure enforced by a DBMS is a compelling alternative to microservices in this context.

Ahh... MalformedURLException is checked in Java and is a source of constant backlash from developers - for over 20 years :)

> In order for free will to exist there would need to be some force outside of normal physics that influences the physical world.

I guess this could be something analogous to dark matter... It is as much physics as any other unexplainable "fundamental" concept.

That's why I always raise concerns about JEP 411 - removal of SecurityManager from Java without any replacement.

> I don't think your reply is particularly effective when you are replying to a comment that exhibits a formally verified microkernel.

I would say that one small piece of software (Sel4 is only 9,400 SLOC!) always cited as an example is actually a very small set of programs that can be formally verified. I haven't heard of a formally verified web browser...

> Many useful algorithms can be proven to terminate.

Proving that a program terminates is not that much interesting. Lack of security vulnerabilities would be much better.

> But it is clear for example that if, say a program is recognized by inspection as the concatenation (splicing the final states and initial states together) of two programs that terminate, then this program terminates

But it does not tell us anything about real programs? We don't compose software by concatenating their state machines.

> Even the link you provide gives optimism and claims that

This is a call for empiricism (aka testing) and ad-hoc heuristics exactly because the problem is not solvable in general using formal methods.

1. Unfortunately the set of "some" programs is unknown and most probably really small.

2. Even proving anything about finite state machines is NP hard so the problem is harder than just using weaker model of computation.

3. Proofs are not reuable: proving something about one program does not tell us anything about other programs.

See excellent https://pron.github.io/posts/correctness-and-complexity for more details.

This subject requires mandatory link to the excellent and eye opening talk by Ron Pressler: https://pron.github.io/posts/correctness-and-complexity

That won't cut it as I need a multi-language build.

And don't get me wrong - I know it _can_ be done in Nix (as it is a programming language) - the question is _how easy_ it is to create/maintain it.

Let's say my solution requires a Java Spring Boot application, React client, custom Postgres extension and Python ML code.

What you are describing is a pipe dream of software reuse. People try to do it from the very beginning of IT industry with mixed results.

The devil is in the details - your mixture of features is different than mine. We have constant upgrade of video codecs that offer more capabilities. We have unavoidable security issues that need to be somehow addressed (by version upgrades or replacing some components). Etc, etc, etc...

IMO it is quite arrogant to claim "all problems are the same problem" - they are not even though they might look similar.

It is difficult for me to dispute this as I don't think I am in any way entitled to define what problems are "meaningful".

BTW - lack of an authority deciding what problems are meaningful is the core idea of capitalism. And I'm telling you as a person that lived many years under communism: this is much better for everybody.