jbergens

I was surprised that TFS was not mentioned in the story (at least not as far as I have read).

It should have existed around the same time and other parts of MS were using it. I think it was released around 2005 but MS probably had it internally earlier.

I'm personally on the side that thinks that pg + x != pg.

It might not even be possible to install x on some hosted pg servers.

It is great that you can expand pg and that you and others have but I don't rate it as high as a buil-in solution.

I don't think the example was perfect which explains your wife's reaction.

Think of it more like the first delivery guy/girl left his/her car outside and wrote 123 on it. Then walked back.

The next one sees the car with a sign saying 123 and won't even ring the door bell or leave a package. Now you haven't gotten the package twice, it has not been delivered twice.

Sure you can complain that there's a car outside your home but in digital system you won't even see it. It would also cost the deliver firm a car for every package but that is not your problem and again, in the digital world the cost is a lot less than a car.

There is an argument that the street would be filled up with delivery vans ans there would be no more room for new deliveries to you or your neighbors but that is a limitation you could talk about. You probably can't handle an infinite number of packages delivered at the same time either and you won't wait an infinite amount of time for any specific package.

Try this version with your wife.

I don't see any reason why it shouldn't scale. It also allows you to use any backend language. If you write messy code in php and think it is the language 's fault then you can use something else. Rust, Go, Java, C#, Elixir. Everything should work. Just don't write messy code.

The two parts below means different things. Just thought about it.

> I wonder how much longer until we have a military device that doesn't work killing people...

And

> I wonder how much longer until we have a medical device that doesn't work, killing people...

Do you really want the thousands of bugs that would occur if we shipped a real binary to each device? And all security problems?

Sorry, the FooApp 1.1 does not support your iPhone 12. It also crashes on Samsung Galaxy 21 and lower and has a huge security problem on Windows 10 when using an Intel Core i5.

I remember a client using Graylog. It was good for app logging and is available as open source.

There was/is a state management lib called Mobx that was released years ago and was usually combined with React. It was kind of reactive, very easy to use and fast. It normally only updated the components that was effected by a state change.

It was a bit sad that it didn't get more popular and possibly improved. Some devs liked it but we were a minority compared to those who liked/used Redux.

One strange thing they did was to release a new "version" called Mobx State Tree which was very different. It had a great api but was different and slower.

Did you read the article? The main issue with your idea is that an LLM won't know if the algorithm it created is any good, or even if it works at all. If it can't check that it will never know and never get better. You could ask it to generate a number of algorithms and then yourself choose the best one but then you have worked as a team, the LLM did not plan anything.

In Sweden we have a special authetication system that is owned by the banks. It is called BankID and generally works well but it has flaws, especially that you shouldn't use it if they call you and ask to you do it since that is a security risk by itself.

It works if I call a bank or insurance company or something like that. A robot voice will ask me to authenticate and when I have done so and is transferred to an operator they will see that I authenticated. So it works when I call them but not the other way around. We need a new system.

I know that some of them tried to rewrite large systems but failed. You are right that it is not just a money issue since they could spend hundreds of millions of dollars on the rewrite and then basically scrapping it.

It shows that they did want to switch but it was harder than they thought.

A really, really bad argument in my opinion. That thinking would lead us to Cobol.

I remember it as at that time Windows and Unix was the common systems. I know we collected statistics for our business software offering that could run on multiple types of Unix and on Windows. Around 1998 I think 70% of all customers choose Windows. It was easier and cheaper.

So, I would say that the most common scripting language in the late 90s was VBScript.

I also can't recall any of the Unix gurus at our company using Python. They used bash, zsh or other shells.