choeger

Soo, if and when this "AI" is applied to suggestions, will it stop to suggest washing machines to me after I just bought one the other day in the same shop? Or the same article I just read this morning? As long as this very simply case is not covered, I consider these algorithms cow manure.

What I find intriguing here is that in the past century, breakthroughs in physics (relativity, quantum mechanics) followed from earlier insights in mathematics (linear algebra, stochastics). Yes, mathematics can be very, very abstract and sometimes it appears to be more like poetry then science. But when an insight allows to generalize and simplify many different problems it's quite possible that we will see the fruits of that insights for decades to come.

Now even reading ML and compiling in the title is not a guarantee for ML the language. I hate overloading.

We might simply be a society in decline. Bureaucracy, Idiocracy, Cleotocracy all effect productivity negatively - and they're all present to various degrees around the world.

We have bullshit jobs, virtual economies, ideological education, inept politicians, and a shrinking IQ. So what else is supposed to happen to productivity.

The only possible improvement is in energy, where the incredible cheapness of PV and battery storage might massively drive down energy prices over the next decades. But even then, it's notably not the complex and marvelous nuclear power that would save the day, but a cheap mass-produced good made mostly from sand.

Uh, does that imply boars are more radioactive elsewhere, too? Northern Germany, Poland, France ...

Could it be that they simply aren't tested elsewhere?

But how does one even buy significant quantities of gold?

I am waiting for someone publishing the theoretical limits of these "AI" systems. They're certainly impressive language models - don't get me wrong on that. But every algorithm and every model has its limits. To know the limits turns their application from hype into engineering. And of course, the hype-sellers will try to keep that from happening as long as possible.

Naturally everyone does waterfall, just at different points. Even if I did the leanest form of Kanban, I have to check the requirements of each ticket, understand them, translate them to maybe a prototype/discovery phase, come up with tests and an implementation strategy and verify the result somehow. That's just waterfall at the finest possible granularity.

Waterfall doesn't mean not to iterate. It also doesn't mean to not build prototypes or MVPs. It just pushes the risky decisions back to people that are actually paid to make these decisions. Scrum is not just a framework for micromanaging, it also conveniently removes any domain responsibility from management. It's always "the team decides". (Of course, just on paper. Try to decide to do tech debt only for a couple of sprints with your team and see how management reacts.)

Besides, waterfall is just the straw man of scrum zealots. I once proposed a new team structure where frontend and backend wouldn't be mixed because I observed that most stories didn't have an overlap but where rather mostly one or the other. The scrum master was shocked that I wanted to get rid of "cross functional" teams: "What do you want to do instead, waterfall?". For them it was inconceivable that cross functionality was not equivalent to scrum.

Sigh. Releasing more often is not an ideal situation. Yes, being able to release every single change on its own, fully tested, is a nice to have tool. But the real world works in office days, weeks, and quarters. And whatever amount of work you put into your test suite and automation, sometimes you cannot test some things. Sometimes you have to wait for a real day (or God forbid a real quarter) to pass.

Yes, testing, especially unit and integration tests, are a sine-qua-non for quality work. But so are automatic proofs of absence of certain errors (vulgo type checks) and non-functional tests.

But all this has been at least partially resolved. What we are still sorely lacking is simulation. Everyone who ever worked with a staging environment knows how limited this usually is. What I would like to work with before I retire is a tool that lets me standup a complete copy of the production environment, isolated from the real world of course, with all external services automatically mocked. Now that would help to improve the quality.

Let's see if white hydrogen turns into something real. Could be bad for anyone invested in electrolytes, but great for fuel cells, etc.

What an amazing time we live in. It took weeks for the world to investigate this "discovery". Weeks. Not months, years, or decades.

We will see spectacular results from this kind of global scientific collaboration. I am confident that there will be an actual scientific breakthrough confirmed like this report got debunked.

Program synthesis by a language model is certainly cool, but I don't think it's really novel. After all, the mutator could as well just be a random AST transformer.

So what's the real deal here? Does the mutator end up with a usable program much quicker? Or does it cheat by looking at the test cases?

As an example, if I specify a md5 hash function on strings, what will that tool produce?

Investors are the landlords, if indirectly. To be honest, I always wondered how much of the venture capital would turn into revenue for other investments.

Assume, you own Microsoft stock and are a venture capitalist. How do you react to your latest investment considering to buy AWS vs. Azure? The same pattern might apply in many more direct forms. Where does that fruit basket come from? What headhunting agancy do you trust with your top-level hiring?

I wouldn't be surprised if most VCs would mitigate their risks by funneling a startup's expenses back to their own investmentsnin one way or another. Vacant office space is just another such investment.

They aren't banning cars. They're requiring special permits. That's a difference. In effect, they're banning cars for the masses and keep them for a small group (the wealthy, all sorts of delivery drivers, officials).

Yeah right. "Don't worry, the leash you'll be wearing is a public standard.".

You're either paid or delusional.

So we have to accept control through Google or Apple or otherwise we will be controlled by Alibaba or Huawei? I don't want my devices to be controlled by neither company.

> what does Google have to do with how websites choose to treat their users or what solution they would propose

Google owns YouTube. Is it so hard to imagine that some product manager at YouTube counted the losses due to adblockers and asked a team in Chrome to prevent them?

What about Earth's magnetic field?

That's neat, but it misses the point. LK-99 is not even available for engineering, yet. You might be able to use one of the existing designs. Maybe you need to come up with a new design. But you cannot do that just yet.

That's a physics-based assumption, not an engineering-based one.

Unlike the effect on nuclear fusion, the idea of using SC as storage devices is pretty much pure theory.

Edit: it's currently leaving the theory part at MW scales as pointed out below. That makes using LK-99 much more likely. But using LK-99 in a SC storage device is still theoretical.

Let's face it: People don't want to pay for the software they're using. They don't want to pay for their phone apps and they don't want to pay for the maintenance of their Linux Server stack. Even just installing security updates seems to be too much for many, let alone paying for their creation.

So what we get is bitrot, plain and simple.

The obvious alternative is to rent software. But now we have the offering party who doesn't want to pay for maintenance, either and, again, we end up with bitrot.

What we'd need is a way to visualize bitrot and have everyone regularly pay for a renovation.

Obviously, the Atlantic Ocean closer to the equator.

We need legislation that clarifies who owns a device and what consequences this ownership has. But we won't ever get it as governments and corporations feel that they should own the device. If they ever agree on a separation of ownership, it's game over. Our devices will become our biggest enemies.

There are two cases where such a tool could be useful:

1. You have no clue about what "boilerplate" is required or why.

2. You know what's required but you need to generate the boilerplate often.

In the first case, just stop. Using a tool might give you some kind of result, but the quality of what you do is already subpar from the beginning. Learn your effing tools.

In the second case, stop, too. Work with a higher abstraction layer, instead.

> I know for a fact that at least one FANG has a couple of internal tools to create projects and CICD infrastructure from scratch using project templates.

Imagine what that means for the ICs in that FANG: They don't know why the boilerplate is what it is or what part they could or should replace with something more modern .

Unpopular opinion: If such a tool is useful for you, you are doing something wrong. There is maybe a valid exception for use cases that intentionally create projects that require manual work (university and other trainings), but generally if you spend time by creating the same folder structure over and over again, you're probably working at the wrong level of abstraction. (And if you are creating so many micro services: please stop!)

It can't. They're talking out of their backend.

So what does make (the took is not called Makefile, btw) "wrong". Where could one improve on it?

1. Syntax. Makefiles aren't parseable and have some at least unexpected syntactic properties.

2. Dependency detection: AFAIK any make will always use a timestamp and the precision varies a lot. A checksum or at least guaranteed resolution would be great. Also, you can't depend on directories.

3. Dynamics (this is going to be contested): Changing dependencies and tasks at runtime is possible with GNU make, but not ideal.

Taskfile improves on problem 1 but probably worsens everything else.

Fascinating.

And isn't it great that our ancestors left all these bi- and trilinguals? Imagine: They only did this because the elite was multi-lingual in those early empires.

Germany is extremely well positioned to rise again economically in the next five years or so. It's attracting migrants from all over Europe, it's located quite nicely in the middle of the continent and it's currently building a massive capacity of renewable energy.

The only real problem right now is efficiency of spending. Nearly all public sectors (defense, housing, transportation, education, healthcare) bemoan significant lack of financing and workers. Yet, Germany spends enormous amounts of money and employs record levels of workers there. It's like all the money and workers just vanish. This leads to the situation that it's currently difficult to hire in Germany.

This process leads to the attraction of skilled workers especially from eastern Europe. I don't know where this ends, but I doubt the spending and employment will get significantly more efficient. Instead, Germany might very well attract additional millions of well-educated Poles, Ukrainians, Romanians, etc.

I wouldn't be surprised if by 2030 we see a Germany with a population of 90M people absolutely dominating the European market.

It's important to note the other side of the medal: Today's inflation is to a large degree caused by the expansionist money policy that was necessary to prevent a Greece financial collapse (which would have undermined the Euro as a whole). Greece financial problems were, at least to a significant degree, caused by debt-financed social expenses that are unheard of in Germany. So the conclusion that German workers are financing Greek's early retirements is not completely bullocks.

It's very important to understand that Greek's government also played the "Germany is at fault" or "Germany has to pay" card very effectively, when Germany's government played the "Lazy Greeks" card to justify their own fiscal policy.